[00:25] PR # closed: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5714, snapd#5717, snapd#5727, snapd#5739, snapd#5759, snapd#5768, snapd#5771, [00:25] snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5805, snapd#5809, snapd#5811, snapd#5813, snapd#5822, snapd#5823, snapd#5824, snapd#5825, snapd#5832, snapd#5833, snapd#5835, snapd#5840, snapd#5845, snapd#5847, snapd#5849 [00:26] PR # opened: snapd#5170, snapd#5234, snapd#5271, snapd#5346, snapd#5395, snapd#5451, snapd#5469, snapd#5497, snapd#5583, snapd#5596, snapd#5623, snapd#5644, snapd#5672, snapd#5680, snapd#5696, snapd#5712, snapd#5714, snapd#5717, snapd#5727, snapd#5739, snapd#5759, snapd#5768, snapd#5771, [00:26] snapd#5777, snapd#5782, snapd#5789, snapd#5791, snapd#5792, snapd#5805, snapd#5809, snapd#5811, snapd#5813, snapd#5822, snapd#5823, snapd#5824, snapd#5825, snapd#5832, snapd#5833, snapd#5835, snapd#5840, snapd#5845, snapd#5847, snapd#5849 === chihchun_afk is now known as chihchun [06:07] PR snapcraft#2287 closed: meta: support relocatable prime for path verification [06:10] PR snapcraft#2288 closed: build providers: use multipass automatically when on darwin [07:32] PR snapcraft#2286 closed: config: change default outdated action to clean [07:46] Wait sergiusens, you need to land the legacy vendor or that ^ WILL hit people [08:11] PR snapcraft#2285 closed: snapcraft snap: vendor legacy snapcraft [08:20] Is it possible to manually remove an old version of a snap? [08:21] I have one snap installed who's N-2 revision was accidentally very big, and would like to be rid of it. [08:23] popey: mind helping Odd_Bloke ^? [08:24] hello [08:24] sudo snap remove "$snapname" --revision="$revision" [08:24] where you fill in the snapname and revision gaps [08:24] Odd_Bloke: ^ [08:25] Perfect, thanks! [08:27] As a side note, that says "$snapname removed" when it's complete, even though $snapname is still installed; perhaps a little UI nit that could be fixed? [08:28] Odd_Bloke: yeah, should be an easy fix [08:38] PR snapd#5850 opened: cmd/snap: improve UX when removing specific snap revision [09:29] PR snapd#5849 closed: Have a minimal smokescreen test on osx [09:55] PR snapd#5851 opened: tests: don't fail interfaces-bluez test if bluez is already installed [09:56] PR snapd#5852 opened: tests: fix listing to allow extra things in the notes column [10:02] PR snapd#5850 closed: cmd/snap: improve UX when removing specific snap revision [10:04] Odd_Bloke: ^^ a nicer remove message should appear in next core update in the edge channel [10:07] PR snapd#5853 opened: daemon, snapstate: consistent snap list [--all] output with broken snaps [10:44] hmm, is snapctl from a hook allowed to call "disable" on itself ? [11:44] PR core18#68 closed: Install rsyslog in core18 [11:48] Hi guys, newb question but is there a way to put epoch on the snap filename? [11:49] why would you do that (note that the version string is totally shallow anyway, it is just for enduser convenience but not used for anything else) [11:51] It’s just for me to know that it’s a different from the one I build before. Say, the program version is the same but I decided to change some configuration for the build. [11:52] Or is there something inherently wrong with that? [11:53] not really, you can indeed use the version for your own convenience and bump it with every build, but snaps are managed by their store revision number [11:53] so whatever you put into the version field is pretty much up to you ... as long as it doesnt contain any weird chars [11:54] Does that still work if I don’t publish to the store? [11:54] i think many people just add the git commit number to the end of an upstream version [11:54] that way you can easily map your code commit to the snap in use [11:56] Hmm what should I do if I don’t touch the code but modify the script in snapcraft.yaml? [11:56] fi you dont publish you will only get a local fake revision ... it is typically an x with an iterating number that counts up for each "snap install --dangerous ..." you do [11:57] i.e.: [11:57] $ snap list uboot-tools [11:57] Name Version Rev Tracking Publisher Notes [11:57] uboot-tools 0.1 x1 - - - [11:57] that s a snap i only have installed locally with the --dangerous option [11:57] Ahh yes, I remember seeing that. [11:58] Is there any advantage to snap if I want to treat them like standalone .deb packages? [11:58] if you dont touch the upstream code but only snap related stuff you can use $upstream_version-$your_snap_iteration [11:59] and iterate the part after the dash if that makes you feel better :) [11:59] you can not "treat a snap like a standalone deb package" [11:59] they are quite different things :) [12:00] a snap typically bundles all dependencies for example [12:01] you could rather compare a snap to a PPA that contains a metapackage that in turn depends on all packages inside the PPA ... thats probably the closest if you compare deb to snap [12:01] Yes, I’m actually bundling everything ala AppImage. [12:01] (with the exception that the snap is not bound at all to the release or distro of the host system you install it on) [12:07] I see. In that case, does snap allow creation of your own store? [12:07] I think PPA allows self-hosting [16:55] PR snapd#5852 closed: tests: fix listing to allow extra things in the notes column [17:01] PR snapd#5853 closed: daemon, snapstate: consistent snap list [--all] output with broken snaps [17:06] PR snapd#5835 closed: tests: find snaps just for edge and beta channels === chihchun is now known as chihchun_afk [17:50] PR snapd#5854 opened: docker_support.go: add rules to read apparmor macros [18:00] mir-kiosk 1.0 snap does not seem to have the wayland-socket-dir interface, what replaced that ? [18:02] ah, found https://github.com/MirServer/mir-kiosk/commit/01fe16ca90eff5408c44f9448f4da8d7d27d296c#diff-5fde7a6d86053f0e1d88c0a2a238941f [18:02] om26er, wayland [18:03] the socket now lives in XDG_RUNTIME_DIR (/run/user/0 for kiosk apps) and is accessible via the normal wayland interface [18:12] PR snapcraft#2262 closed: schema: add "legacy" adapter type [18:17] ogra: So that above change I posted breaks the desktop launcher [18:17] https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L204 [18:21] i dont think i have ever seen the desktop-launcher being used with mir-kiosk ... 90% of the stuff that does will not even exist on a core install [18:22] (and i dont think anyone expects the desktop launcher to work in that context since mir-kiosk is typically not used on desktop systems) [18:22] ... but file a bug anyway :) [18:22] ogra: I use desktop-glib-only part for my Qt application, which otherwise wouldn't start [18:23] i guess we'd need a kiosk-glib-only premote part one day ... [18:24] the desktop launchers expect fonts, themes and icons to exist ... all that stuff you dont really want on a minimal kiosk system [18:26] in our specific case our app is supposed to run both on the Desktop (X11, Wayland) and on UbunutCore (kiosk more) [18:26] did you try to simply use QT_QPA_PLATFORM=wayland for your app ? [18:26] that should just work === pstolowski|sprnt is now known as pstolowski|afk [20:34] hey folks! I'm looking at some automated deployment of ubuntu-core and am working on automating the system user part first. I read on the forums there's a snap called make-system-user which I've installed, but I get an error when I try to use it [20:35] it looks like this: [20:35] https://paste.ubuntu.com/p/hgjRnDHr7S/ [20:38] it sort of looks like a python error [20:39] should i just 'pip install snapcraft'? [20:40] i guess I naively assumed the snap would include all the deps [22:06] solved it by refreshing the snap to the edge channel..