[02:53] Hi guys is it possible to build an ubuntu image using local snaps defined in the model assertion instead of having to go through the snap store? [03:30] Bug #1635101 opened: /snap/bin is not added to path for "sudo su" [05:04] mwhudson: most of the devs are in Europe so they would be asleep [05:05] mwhudson: and I agree the documentation is very patchy with lots of different components being constantly rewritten with out of date instructions. I'm almost at the point of giving up on Snappy and going with something easier like ResinOS. [06:18] rharper, we do not purge, but snap prepare-image has a function that disables it if there is no cloud-init config in the gadget snap [07:10] jdstrand, hmm, didnt you recently say you addded linux-generic-bbb to the kernel exceptions so it auto-lands ? https://myapps.developer.ubuntu.com/dev/click-apps/5912/review/rev/5/ is in manual review now [07:14] ogra_: I did but the store doesn't have it yet [07:14] ah [07:14] ogra_: approved but not published [07:15] yep, got the mail, thanks :) [07:15] np [07:16] and published too ... :) [07:28] PR snapd#2192 opened: snap: fix FTBFS because the buildds do not allow writing to syslog [07:56] PR snapd#2192 closed: snap: fix FTBFS because the buildds do not allow writing to syslog [07:59] ogra_: ah maybe i need to update my snapd then === King_InuYasha is now known as Son_Goku [08:23] pitti: yo [08:23] hey mwhudson, how are you? [08:24] pitti: i'm ok [08:24] pitti: netplan and nameservers, how much work does that sound? [08:24] mwhudson: ok, jumping back :) [08:25] mwhudson: not that much, I just moved it to the top of my list as it seems to become a blocker RSN? [08:25] pitti: seems so if https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1634540 is critical [08:25] Bug #1634540: Configuring a static IP address generates a netplan file without a gateway [08:25] because if you configure static addresses and no nameserver you're going to have a hard time talking to the store.. [08:26] i guess we *could* put login.ubuntu.com's ip address in /etc/hosts :-) [08:26] mwhudson: well, if you don't configure a nameserver, resolved defaults to 8.8.8.8, so it shoudln't completely fail [08:26] pitti: oh huh [08:26] mwhudson: but it's better to be able to configure it of course [08:26] pitti: it definitely failed for me in qemu [08:27] pitti: is that user mode networking being odd? [08:27] mwhudson: it would only work if you ... oh crap, this is xenial, so no resolved [08:27] nevermind :) [08:27] ha [08:27] * pitti just doesn't live in stable releases [08:28] well we already backported netplan itself for this... [08:28] backporting resolvd does feel a bit large-hammer [08:29] nah [08:29] we really don't want to do that [08:30] mwhudson: both networkd and NM support manual nameservers, so it's just a matter of adding the glue to pass it on, and writing tests [08:30] mwhudson: I'll start on that now [08:30] yeah, networkd looked pretty straightforward at least [08:30] mwhudson: getting that into xenial-updates will take a bit longer, but you can park it in your PPA in the meantime [08:30] (i know nothing about NM really) [08:30] yeah ppas r us [08:31] mwhudson: is yakkety a thing for snappy at all? or just x (and zesty/devel of course)? [08:31] * pitti hopes not -- please no non-LTS releases any more, EVAR [08:31] just xenial + ppas i think really [08:32] and of course xenial implies devel release first, not that that rule is being stuck too 100% [08:32] I just don't want to repeat the vivid pain :) [08:33] xnox is in the hague, he can attack anyone who suggests anything like that [08:34] pitti, sure.... would you like to maintain yakkety, or whould you like to SRU everything from yakkety to xenial? [08:34] mwhudson, i was just wondering, is VPN support in console-conf on the roadmap ? [08:34] people are talking about SRUing all of systemd user session work, and all of perfonal/unity8 as SRUs into xenial for ever. [08:34] xnox: I want to forget that yakkety exists :) I want to backport necessary stuff from devel (i. e. z now) to x [08:35] i'd better get on with the ui for nameservers... [08:35] xnox: uh, ambitious :) [08:35] ogra_: noone has mentioned it to me [08:35] xnox, we should really just SRU zesty altogether :P [08:35] it works great! [08:35] ship it [08:35] mwhudson, yeah, just came to my mind that IoT setups might want to use it [08:35] ogra_: is openvpn-client even in core [08:35] ? [08:36] urgh, happy typing of X.509 certificates into your serial console :) [08:37] mwhudson, nops, apparently not [08:37] sounds like using telnet to debug http/2 [08:37] Hey, has anyone experienced a situation where building a snap in a yakkety container is different to a snap built from in a VM ? As the snap i've built from the container doesn't work on the host, whereas the one from the VM does and they both have the same size but a different md5sum [08:37] ogra_: i guess the gadget snap can provide it somehow? [08:38] yeah, well, i will try to discuss it with the team here [08:38] ogra_: anyway, sounds like a medium term thing ... [08:38] right, not super urgent ... definitely not for the release ... for that getting wifi to work on the pi3 would be a bit more important ;) [08:39] ogra_: do you have any idea what's actually going wrong there? [08:46] mwhudson, not the slightest .... wlan doesnt work at all ... when you try to configure it it times out ... when you *then* try to do anything else network related ... i.e. try to set up wired, that doesnt work either anymore .... [08:47] ogra_: but if you run through console-conf on wired, then wlan works? [08:47] btw, i just talked to mvo, we'll seed openvpn stuff so you have something you can later attach to [08:48] iirc (have to test that again) if you configure both, iit doesnt work [08:48] it only works if i use wired only [08:48] it also works if i manually bring up wlan after booting [08:48] fgimenez might be able to give more details, he tests that stuff all day atm [08:51] pitti: http://paste.ubuntu.com/23352576/ <- does that match planned syntax [08:52] mwhudson: looks good; I'm writing test cases like this: [08:52] enblue: [08:52] addresses: ["192.168.1.3/24"] [08:52] nameservers: [08:52] search: [lab, kitchen] [08:52] addresses: [8.8.8.8]''') [08:52] mwhudson: which is the same thing, just different YAML syntax [08:52] ogra_: can you do something like create /var/log/journal so the journal persists and then see what ends up in there [08:52] pitti: wait, it's per interface? [08:52] mwhudson: NM seems to have trouble with multiple search domains, argh [08:53] mwhudson: yes, it is; nameservers usually are [08:53] pitti: ok fine, but that's not what https://git.launchpad.net/netplan/tree/doc/netplan.md has :) [08:54] mwhudson: right, I'll fix that [08:54] that was obviously an error [08:54] thanks for pointing out [08:55] * mwhudson rebases :) [09:01] mwhudson: http://paste.ubuntu.com/23352599/ [09:02] pitti: looks plausible at least [09:03] mwhudson: as I said, NM does not actaully seem to properly configure multiple search domains (I just see "search lab" in /etc/resolv.conf), but I hope that won't block you [09:03] pitti: i don't think that's important here no [09:03] maybe morphis could say more [09:05] pitti: you're probably not the ideal person to ask this but do you think it makes sense to allow configuring nameservers when using DHCP for an interface? [09:06] mwhudson: it's technically possible to configure this; my gut feeling is that it doesn't make much sense to expose this corner case in the UI, though [09:06] pitti: ok [09:09] pitti, mwhudson, seeding the openvpn package is enough for you guys to have everything you need to later implement something in netplan and console-conf ? [09:10] ogra_: i don't think that's something i can answer off the top of my head [09:10] ogra_: probably; but doesn't make much sense to seed it until we actually can use it [09:11] well, we release in two weeks, i just want to have all the requirements there so you can get to it later [09:11] we can seed it if/once we support it; until then, it's just dead weight [09:11] also, I don't think we want to abstract this in any form [09:12] if you want to configure openvpn, then add an openvpn config file [09:12] this isn't related to different backends like networkd vs. ifupdown vs. NetworkManager [09:12] ok [09:13] I mean, maybe we want to put it into the yaml some day, but that shouldn't be a blocker [09:15] Bug #1631791 changed: ubuntu-core/core unconditionally switches to the stable channel on all-snap images [09:22] pitti: http://paste.ubuntu.com/23352666/ <- better? [09:27] ppisati, hmm, the uart oops on pi3 is supposed to be fixed with todays -security/-update kernels, right ? === drizztbsd is now known as timothy [09:28] ppisati, the QA team just showed me an oops that looks suspiciously like it [09:28] ppisati, https://rocket.ubuntu.com/file-upload/E5QyRTm7Xq6nojq3E/photo_2016-10-20_10-39-04.jpg [09:31] PR snapd#2162 closed: interfaces: add shutdown interface [09:33] Son_Goku: hey [09:33] Son_Goku: I pushed some small change [09:33] Son_Goku: let's try to run that for real [09:33] I just pulled and it built [09:33] don't know if it works, though === drizztbsd is now known as timothy [09:34] ah, I'm missing that patch [09:34] * Son_Goku pulls again [09:34] Son_Goku: I'm just rebuilding both to install now === drizztbsd is now known as timothy [09:37] ogra_: cannot open that image [09:37] ogra_: anyhow, >= 4.4.0-1028.34 should be fine [09:38] 4.4.0-1029 is what we (should) have in the store [09:42] hmm, https://launchpadlibrarian.net/290063684/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz [09:42] -1028 actually :) [09:43] cyphermox: https://github.com/CanonicalLtd/subiquity/pull/175 [09:43] PR CanonicalLtd/subiquity#175: add UI for entering nameservers [09:43] ah, wrong log [09:43] https://launchpadlibrarian.net/290161189/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz [09:43] that has actually -1029 [09:44] ppisati, hmm, but only: [09:44] Get:5 http://ftpmaster.internal/ubuntu xenial-security/universe armhf linux-image-raspi2 armhf 4.4.0.1029.29 [2324 B] [09:44] ppisati, where is .34 ? [09:44] (also it would amke sense if you could come over to the snappy room, we are discussion uboot watchdog) [09:44] *discussing [09:45] ogra_: i'm here actually [09:47] Son_Goku: hmm, I dont see the snapd-selinux package === drizztbsd is now known as timothy [09:49] Son_Goku: ah, I'm a dork, noatch [09:49] noarch* === drizztbsd is now known as timothy [09:51] PR snapd#2193 opened: add raw-usb iterface === drizztbsd is now known as timothy [09:55] Son_Goku: I need to redo the systemd units a little [09:55] Son_Goku: fingers crossed [09:56] okay [09:56] PR snapd#2194 opened: store: retry readyToBuy request [10:32] Son_Goku: trying more [10:38] Son_Goku: so I see stuff that seems to imply the selinux policy is not loaded [10:38] Son_Goku: how do I reload it? [10:45] Son_Goku: I need a few more binaries, iterating [12:32] PR snapd#2195 opened: interfaces/builtin: add dcdbas-control interface [12:38] hello, I've installed libreoffice 5.2 via snap in xenial, then removed libreoffice 5.1 with synaptic [12:39] however now the dash does not show LO icons [12:40] how to fix this? [12:41] I was thinking that the LO snap provides icons too [12:42] Can anyone tell me how I'm supposed to verify that a snap package, made availible by some random developer I don't know, is the real deal, and not some sneaky way of installing a modified version of the program that sends all my data to haxx.ru? [12:43] alevipri, well it is distributed by chanonical, so you would thing they have included everything. Have you tried restarting, to see if it is something that just needs to be reinitialized? [12:45] Simooon already restarted [12:45] alevipri, okay, I just started using snap yesterday, so I'm probably not the right person to help :-P [12:46] before to remove LO 5.1 with synaptic, I notices icone were available for both deb and snap installed applications [12:46] noticed* icons* [12:47] so I can imagine I removed something with synaptic [12:48] alevipri, I don't think synaptic is supposed to be able to touch the snaps [12:48] however I was expected to install a snap containing all dependencies, icons too [12:48] that seems to be the general idea [12:49] Simoon yeah I think it too, however now LO launchers don't show icons [12:52] if synaptics touched the snap by some weird bug or other interaction I don't understand, you can probably restore it to it's original form with the "snap refresh" command, however I think it is unlikely that synaptics have been able to touch it. [12:52] worth a try though [12:55] Bug #1635251 opened: /boot/efi/EFI/boot/ is writable as sudo [12:56] Simooon tried but nothing changed [12:57] alevipri, Well that is what I expected :-/ [12:58] alevipri, Have you tried other applications where it worked? [13:03] PR snapd#2195 closed: interfaces/builtin: add dcdbas-control interface [13:06] pitti: ping [13:06] morphis_: pong [13:07] pitti: while you're working on the DNS fix for netplan can you include https://launchpadlibrarian.net/290162595/nplan_0.12~16.04+ppa1_0.12~16.04+ppa2.diff.gz in your next upload as well (if you agree with that change)? [13:08] morphis_: no problem -- it's just a small change within that hack, so that doesn't make it any worse [13:08] pitti: I can submit a proper MP as well if you want [13:08] pitti: :-) [13:08] morphis_: we don't have the xenial version in VCS [13:08] ah ok [13:08] then nevermind :-) [13:08] morphis_: how far are we with dropping that hack? [13:09] pitti: not much further, we're trying to hit deadlines for the final product right now [13:09] but I wanted to check with mvo while being on the sprint in the hague what we can do about this [13:10] Bug #1635258 opened: File system should 5% Ubuntu-image [13:11] Simooon for example krita (snap) works with the correct icon [13:13] alevipri, just installed the telegram app myself, and the icon shows up in the launcher, however the systray (or whatever that thing in the upper right conor is called) does not show the correct icon, but an error message icon instead. Perhaps there are just some general issues with icons still? [13:14] alevipri, anyway I will reboot my system to see if that changes this minor issue [13:14] Simooon the telegram-sergiuseng missing icon on the systray is a old bug [13:14] s* [13:15] alevipri, okay, will not reboot then :-P [13:16] Simooon the point is, why before to remove LO 5.1 (deb) the icons os LO 5.2 (snap) were available? [13:16] I suspect something is missing from the LO snap package [13:17] PR snapd#2191 closed: boot: do not set boot to try mode if the revision is unchanged [13:22] alevipri, and it launched 5.2 before you removed 5.1? [13:35] Hi. This is my first outing with Snappy and I'm trying to include a couple of libraries (.so files) to my snap package using the dump plugin, but having no joy. [13:36] Paz_: Where did the library files come from? [13:36] Currently, they are pre-built. The final aim is to build them via snappy [13:36] Paz_: This is my long way of asking, why use the "dump" plugin? Are you sure that's what you need? [13:36] Hmm. [13:37] No I'm not sure. Was using 'copy' plugin, but this is deprecated [13:37] Paz_: Okay, let's start at the beginning. What is the error message? [13:39] During the Priming of the library I get the following message... [13:39] No such file or directory: '/home/celldev/Development/snap-telegram-app/stage/moc_sessionmanager.cpp [13:39] awe_, https://docs.google.com/document/d/1a8eydCb_55M6FQdrdZDXZ1Figkh6rLrERMbWO2v2KzI/edit [13:40] Simooon there were 2 .desktop launchers per app, i.e. 1 for calc-deb and 1 for calc-snap [13:40] Paz_: Pastebin the entire output, starting after "snap clean". [13:40] Bug #1635264 opened: ufw rules created even though there is no ufw on the system [13:41] ok, give me a sec... [13:41] Simooon both worked launching both LO versions and both showed LO icons correctly [13:46] Simooon re-installed libreoffice-gtk with its dependencies [13:46] now icons are shown again [13:47] Simooon my conclusion is that something is missing from the LO snap package [13:49] pitti, are you around? [13:49] Chipaca: yes [13:50] qengho: http://pastebin.com/Cpj3xpeq [13:50] pitti, hiya. Do you know anything about https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ (and in particular about requirements around the shutdown executable) [13:50] pitti, i mean, do we disable it or anything? [13:51] qengho: This is my YAML file http://pastebin.com/T3ukAnyD [13:53] Chipaca: we don't use systemd in the initrd; you can by using dracut instead of initramfs-tools, but I don't have much experience with it [13:54] pitti, this isn't to use systemd in the initrd; it's a way for systemd to hand control back to initrd on shutdown [13:54] Paz_: Does this print two entries? $ ls -ld snapcraft.yaml telegram/app/deps/libqtelegram-ae/build_desktop [13:54] Chipaca, hmm, i think we throw away the initrd after boot [13:55] so if you expect to do anything with the initrd itself that will likely not work [13:56] ogra_, one problem at a time :-D [13:56] heh, k [13:56] Chipaca: I don't think it actually uses that in Ubuntu; AFAIK pid 1 just exec()s systemd-shutdown (to make sure that all open fds to the root fd are closed), which then unmounts everything (or rather, remounts r/o) [13:56] and then falls over :P [13:58] pitti, the prob we have here is that we have a mount inception ... the readonly bit of the fs sits inside the rw bit ... both are mounted on shutdown so the writable bit can not be unmounted because the ro bit inside keeps the fd open [13:59] qengho: Yes it does, one for the .yaml file and the other is the directory [13:59] Cool. [14:01] Paz_: Comment-out your line31, "stage: [...]" [14:01] qengho: OK, then run clean and snapcraft again? [14:02] Yes please. [14:03] Paz_: I don't understand that "stage: " list any more. I can't explain what it's supposed to be doing there. [14:05] qengho: I was playing around, so understand if some stuff is nonsensical. Basically, I have 2 pre-built .so files which are needed to build the 'telegram' part. How do I make this visible to that part? [14:08] qengho: I was manually moving these .so files into /lib before to make them visible, but now need this to be done via the YAML file [14:19] PR snapd#2195 opened: interfaces/builtin: add dcdbas-control interface [14:20] ogra_: right; I'm not yet building an image; I'm building a new core snap pointed to my PPA so I can get an updated cloud-init into the core snap; last week the core snap build ended up with my cloud-init in the .manifest; the last two days the build no longer has it; trying to understand why. [14:21] can you show me your ppa ? [14:22] yeah [14:23] https://code.launchpad.net/~raharper/+snap/core [14:23] those are the snaps; the PPA I point to is here: https://launchpad.net/~raharper/+archive/ubuntu/snapbuilds/+packages [14:23] pitti, ogra_, so the good news is, it works [14:23] and the bad news ? [14:24] pitti, ogra_, /run needs to lose the noexec flag, and now i need to figure out if i can write shutdown as a shell script or not :-D [14:24] ogra_, I'll write it in python just to keep you happy [14:24] * pitti watches ogra explode in anger [14:25] Chipaca, it doesnt need to "lose the noexec" completely though, have a shutdown unit that remounts it "exec" right before shutdown [14:25] true dat [14:25] ogra_, BTW we have /lib/modules and /lib/firmware mounted twice [14:25] which shutdown did you use ? busybox ? [14:26] yeah, thats a bug i guess [14:26] ogra_, mksh-static [14:26] ah [14:26] anyone here use the libreoffice snap? [14:26] ogra_, because the binary needs to be called "shutdown"; imagine what happens if I put busybox there [14:27] ogra_, (spoiler: nothing; the busybox i tried didn't have that applet) [14:27] well, if you put busybox there and create a link called shutdown, it should DTRT [14:27] ah [14:27] right, i was assuming we have the applet enabled [14:27] qengho: Here is the latest snapcraft output with the 'stage' key commented out. http://pastebin.com/4MaLq7qK [14:27] ogra_, busybox will try to run as the applet even when symlinked [14:27] hurricanehrndz, perhaps you get better results asking in #ubuntu-desktop (where the libreoffice maintainer tends to hang around) [14:28] Chipaca, indeed ... i was assuming the applet is enabled [14:28] qengho: As you can see, it is unable to find the 2 libs, qtelegram-ae and telegramqml [14:29] qengho: I can see the .so files in my parts/.../src directory, however [14:31] anyhow, has anyone else noticed spell checking does not work in libreoffice snap [14:31] ogra_: the build on 10-13 has cloud-init from my PPA in the .manifest, but 10-14 and newer don't; [14:32] comparing the build logs, when it's not included, there is an explicit purge of cloud-init* locales* ubuntu-core*; I we see a 'Removing cloud-init; Purging configuration, and finally Del cloud-init' [14:33] rharper, hmm, your livecd-rootfs is the wrong one [14:33] in the working case; there's only the 'Del cloud-init' line; but the files remain present in the core snap (and cloud-init is listed in the manifest) [14:33] rharper, just throw it out [14:33] ogra_: I have an older version in my PPA but the logs show I'm picking up the one from the snappy-dev PPA [14:34] ogra_: which version of livecd-roofs should I be using? [14:34] Get:2 http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial/main amd64 livecd-rootfs amd64 2.420+ppa46 [14:34] is that not the right one ? [14:35] yeah [14:35] do you also see it getting the ubuntu-core meta package from our PPA ? [14:35] let's see [14:36] Get:65 http://ppa.launchpad.net/snappy-dev/image/ubuntu xenial/main amd64 ubuntu-core amd64 1.7.2 [2274 B] [14:36] that looks good [14:36] that has a hard dependency on cloud-init [14:36] huh [14:37] and indeed it pulls it in; I see it get installed [14:37] it's the purge part that's new [14:39] well, grab the livecd-rootfs package and take a look at the changelog ... but we ship cloud-init by default in the normal core image ... so i wouldnt see why in your builds it gets removed [14:40] alevipri, You are probably right. [14:40] rharper, do you add/change any dependencies vs the archive cloud-init in your package ? [14:41] that removal looks like you have a dependency on something added [14:41] (and your package gets removed along with this) [14:41] ogra_: interesting [14:41] we've been updating it to be more explicit about dependencies (for example the ssh-import-id package) [14:42] I wonder which dep triggered it ? [14:42] the removal ? [14:42] note that new dependencies require really thoourough discussion ... we are at the edge of our size restrictions of the image (actually there is quite a bugnch that will soon be dropped) [14:42] ssh-import-id ids definitely nothing we want in the image [14:42] oh, right [14:42] like lsb-release (which recently got in by accident but will soon be removed again) [14:43] i just didnt get to do another cleanup yet [14:44] ogra_: this was quite helpful; thank you for pointing me in the right direction [14:44] ogra_: is there a list of packages in the livecd-rootfs build that it explicitly purges? [14:46] well, we make sure that we initially dont seed that stuff usually ... livecd-rootfs calls apt autoremove at some point ... the packages we explicitly remove are only apt, dpkg and locales [14:46] there are scripts for these three in livecd-rootfs in the live-build/hooks/ubuntu-core dir [14:48] ogra_: great; I'll look at that [14:48] thanks again [14:48] np [14:48] anyhow, has anyone else noticed spell checking does not work in libreoffice snap [14:49] Opps sorry for the spam [14:54] pitti: you already finished the work? [14:54] morphis_: yes; I built a xenial package, lcoal autopkgtests just succeeded, so I'll upload to the SRU queue and update the bug [14:54] morphis_: I included your path change [14:55] pitti: awesome, does it include the mkwifi driver bind fix as well? if yes I can ask mvo to push that package directly to our ppa [14:55] * Blacklist mwifiex_pcie from rebinds (work around LP: #1630285) [14:55] Bug #1630285: mwifiex_pcie crashes after several bind/unbind

[14:55] morphis_: I suppose you meak that one [14:56] morphis_: yes, that landed upstream too (in 0.13/zesty), so it's included in the backport [14:59] morphis_: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=nplan [14:59] PR snapd#2161 closed: interfaces/builtin: add dcdbas-control interface [14:59] PR snapd#2195 closed: interfaces/builtin: add dcdbas-control interface [14:59] morphis_: I think the "edge" (or whatever) snappy images are built including -proposed, so if that gets reviewed/accepted soon, you might not even need a PPA upload [15:00] apw: ^ if you have a minute, maybe you can review the nplan xenial SRU [15:00] pitti, sure [15:17] pitti: I've justed checked with niemeyer and mvo and we decided to leave it out of RC [15:17] pitti: so no hurry [15:17] morphis_: apw just accepted it, anyway [15:17] pitti: so it will be in xenial-updates in a bit? [15:18] morphis_: in a week (assuming it gets verified in time, so please report back to the bug); but as I said, I believe snappy images are built with -proposed, so the next image should pick it up [15:18] aye [15:48] morphis_: leave it out of RC> but is this a requirement for GA? [15:49] slangasek: yes [15:49] ok [15:49] otherwise static IP configuration does not make sense inside console-conf [15:49] as you can never reach the SSO service [15:59] PR snapd#2196 opened: debian: run our udev rule before the snap udev rules [15:59] Bug #1635335 opened: main.go warning to stderr about syslog [16:31] PR snapd#2196 closed: debian: run our udev rule before the snap udev rules [16:45]