[05:40] PR snapd#11638 opened: tests: skip interfaces-many-core-provided on 14.04 <⚠ Critical> [05:54] morning [06:17] 'morning! [06:56] PR snapd#11614 closed: seed,many: allow to limit LoadMeta to snaps of a precise mode [06:56] PR snapd#11621 closed: tests: allow ubuntu-image to be built with a compatible snapd tree [07:03] morning [07:56] PR snapd#11635 closed: many: fix failing golangci checks [09:17] PR snapd#11446 closed: asserts: extend optional primary keys support to the in-memory backend [09:17] PR snapd#11625 closed: tests: update the lxd-no-fuse test <⚠ Critical> [09:36] pstolowski: hi! Can "snapctl refresh --proceed" be run from within a snap (not as a hook) to trigger the update of the invoking snap? [10:03] mardy: it is but the snap needs to have snap-refresh-control interface [10:22] pstolowski: yep, thanks. Just to be sure I understood correctly, can this also be used to ask snapd to check if a new release of the snap is available? [10:27] mardy: do you want to check or trigger an update? because for checking there is 'snapctl refresh --pending' command [10:30] pstolowski: if I understood the use-case from the customer, this is about triggering an update [10:30] pstolowski: or maybe both :-) [10:31] mardy: nb this is behind experimental feature flag [10:31] pstolowski: so, if I run "snapctl refresh --pending", this will check the availability of an update with the snap store? [10:34] mardy: kind of. it doesn't query the store. it uses cached data from "refresh-candidates" in the state, we periodically update it [10:40] ok, thanks [10:40] mardy: there is a doc: https://forum.snapcraft.io/t/refresh-control/27213 [11:02] PR snapd#11634 closed: overlord: add missing grub.cfg assets mocks in manager_tests.go <⚠ Critical>

[12:12] PR snapd#11638 closed: tests: skip interfaces-many-core-provided on 14.04 <⚠ Critical> [12:34] is there any way to have alacritty to work ? is the snap package bugged? [12:38] PR snapd#11639 opened: asserts,store: complete support for optional primary key headers for assertions [12:47] dob1: hi! I never used it, but if you explain the problem we might be able to help [12:48] when I run it I get this error: "Error creating GL context; Received multiple errors. Errors: `[OsError("eglInitialize failed"), OsError("GL context creation failed")]`" [12:48] asked time ago on the official #alacritty channel, I don't remember technical details, but they said the problem is in the snap package [12:49] dob1: if you check the journalctl output, do you see some lines that might be related, like some apparmor denials? [12:49] mardy, no errors on journalctl [12:52] dob1: what does `snap connections alacritty` say? [12:52] mardy, nothing [12:53] PR snapd#11202 closed: tests: Test initrd systemd configuration refactoring [12:53] PR snapd#11244 closed: tests: Test initrd systemd configuration refactoring (alternative patch set) <⛔ Blocked> [12:54] dob1: that might be part of the issue; I think that the alacritty snap needs to declare at least an "opengl" plug, if it needs to use OpenGL [12:55] mardy, this is something that the package have to do, right? not me [12:55] dob1: correct [12:55] dob1: but here I see that they recommend install it with the --classic flag: https://github.com/snapcrafters/alacritty [12:56] sudo snap install alacritty --classic [12:56] I used the snapstore [12:57] that might be the problem, try running a `sudo snap remove alacritty` and then the command above (it worked for me, I tried now) [13:27] dob1, FYI https://github.com/snapcrafters/alacritty serems to be the bugtracker they use [13:28] mardy, but classic is just a workaround "Put snap in classic mode and disable security confinement" because the maintainer didn't declared what the app need, or am I wrong? [13:28] classic is not a workaround for anything [13:28] classic is a packaging mode ... you can not use --classic on confined snaps [13:29] a snap has to be specifically packaged for classic mode [13:29] (and making a classic snap also means you need to get a full manual review of the ubuntu security team before being able to upload [13:29] ) [13:30] classic snaps are massively hard to get right though, sicne oyu need to ship all libraries inside and need to make sure nothing leaks into your snap from the host [13:31] but same error [13:31] one of the hardest bits is to get GL right in that context btw [13:32] as https://github.com/tunix/alacritty-snap/issues/20 shows to for alacritty ... [13:32] *too [13:33] I read some time ago before asking, this one too, never found a solution so I just let time pass but unfortunately it's the same [13:33] time pass for a new relase I mean [13:34] yes, that is the issue i described above ... libs leaking in and out of the snap environment and the app not finding the correct bits [13:35] though the debug output in teh issue looks like it is simply missing some bits in the shipped libs [13:36] (i.e. the ryzen renoir drivers) [13:36] in my case is an intel gpu card [13:37] that should be fine with standard mesa libs ... [13:37] but ok nevermind, thanks anyway for the help, I will retry after some time [13:37] either way, you should comment on that bug [13:38] to be honest, nonthing against people work and this project, but I hope they release they classic deb... [13:39] no more problems and more simple [13:39] ask them 🙂 [13:39] surely not more simple fo the developer ... 🙂 [13:40] I premis, I am not arguing, but as soon as they continue to create the snap package they will not create the deb one [13:40] so when they stop, no need to ask, they will create it [13:40] well, as long as they fix the snap this should be fine 🙂 [13:42] imho is the classic linux problem: a lot of projects for the same goal. snap is a good idea, but then there is at least 3 similar projects for the same goal (flat, appimage, another one that I don't remember), and so people will spend time around different projects... at least deb are more common used [13:44] don't take it polemic :) [13:45] well, i dont, but debs are rather limiting in your scenario ... only a small margin of distros supports debs [13:45] so to support them all you'd at least need deb and rpm ... [13:46] now ... different distros will have different versions of libs ... so you will need multiple debs and rpms to support all of them ... [13:46] the are pro and cons, for sure [13:47] and at some point you wont have the manpower anymore to test all of them in all their differebnt scenarios [13:47] ok but on che cons you are shipping a program with all the libs, all its requirements and so on, good and bad [13:47] this is why tehse "three diferent projects" as you called it exist [13:48] all of them allow you to only having to care for one package that runs everywhere [13:49] if you dont care for security at all, appimage is probably the way to go ... but it is also the one thing that none of the software apps in the distros support ... so your package is hard to discover for users [13:49] for example, I use intellij idea, snap is nice for it, for other ides too. I like how simply is to install it and it will be not so easy as a deb. but not all program can be a snap package imho [13:49] correct [14:28] PR snapd#11640 opened: boot,bootloader: add missing grub.cfg assets mocks in some tests [15:13] PR snapd#11637 closed: interfaces/u2f-devices: add Solo V2 [15:28] PR snapd#11620 closed: i/b/kernel_module_load: expand $SNAP_COMMON in module options [15:39] PR snapd#11605 closed: cmd/snap,wrappers: fix wrong implementation of zero count cpu quota [16:04] PR snapd#11574 closed: o/snapstate: rename XDG dirs during HOME migration [18:09] PR snapd#11641 opened: cmd/snap-update-ns: apply content mounts before layouts [18:39] PR snapd#11632 closed: tests: skip the test interfaces-many-snap-provided in trusty <⚠ Critical> [21:30] PR snapd#11642 opened: Update README.md