A potential project needs to launch chromium snap with certain launch flags. Currently it seems this requires forking the snap, which seems like heavy lifting for this.
Can this be made configurable for the snap?
Can’t you just add the flags right after the command-line?
It’s not going to be launched from the command line. It is a kiosk/appliance style project (probably for Core). So chromium should auto launch on boot.
chromium-mir-kiosk is not in stable, and as I understand it is not intended to be in stable. It is a test/proof-of-concept snap. So no.
But if the project turns out to be UCore, then the chromium snap will need to work with mir-kiosk snap (via Xwayland and GL).
@kyleN additional command-line flags are passed through the snap launcher to chromium, so this should just work. See the launcher’s code.
1 Like
Can the snap auto launch as a daemon with specified additional flags on boot on Core? (to support the kiosk mode use case)
Not sure how that would be done. That’s not a chromium-specific question though, any app snap would qualify for such a use case, right?
My limited understanding is that for an app to be managed as a daemon, there needs to be a corresponding declaration in snapcraft.yaml, so you would need to modify and rebuild the snap (possibly just unpack, modify and repack, to avoid the very long build times).
One potential way may be by adding an app (daemon) that always runs but that it does the right thing depending on a snap config. So for example, there could be chromium config called “daemon”. The actual daemon script (always launched at boot) would use snapctl to check the chromium config and if “daemon” is set, chromium is launched. If not, chromium is not launched.
This being said this project may need to make its own chromium snap for the following reasons:
- we need raw-usb interface
- we probably need to stage a mesa package that includes a userspace mesa lib required by the Mali GPU (to work with mir-kiosk)
- and launch as a daemon.
Out of curiosity (if that is something that can be disclosed), what requires that interface? Isn’t it something that may benefit other chromium snap users in general?
The project requires webusb, which in strict confinement will need access to USB devices.
https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
This is certainly something that would benefit other users. Granted, the interface wouldn’t be connected by default. Can you confirm that with the interface the WebUSB API just works to communicate with real hardware?
I have not yet been able to test this (I’d like to though) because I can’t yet build the chromium snap by running ‘snapcraft’ in the root of the stable branch of launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source on a xenial amd64 system. Can you help? it fails with:
subprocess.CalledProcessError: Command '['ninja', '-C', '/home/apath/chromium-2/parts/chromium/build/out/Release/gn_build', 'gn', '-w', 'dupbuild=err']' returned non-zero exit status 1
Failed to run 'override-build': Exit code was 1.chromium is a core18-based snap, you’ll need to build it on bionic.
That said, if all you need is to add a plug, I’d recommend not rebuild the whole thing: compiling chromium takes many hours, even on a beefy machine.
You can take an existing snap, unpack it, add the plug to the snap’s metadata, and repack it like so:
snap download chromium
unsquashfs chromium_*.snap
# edit squashfs-root/meta/snap.yaml to add the plug and save
snapcraft pack squashfs-root
1 Like