[01:51] PR snapd#3061 opened: Renamed thumbnailer interface to thumbnailer-service interface [02:23] hm [02:27] hello [02:27] so on debian, if you install snapd then install (say) hello, the install of the core snap fails [02:28] (hangs at "run configure hook") [02:34] the configure hook has a defunct snapctl subprocess [02:39] running snap install core by itself works [02:39] ah well off to lp for this i think [02:55] Bug #1674193 opened: core snap's configuration hangs on debian === carlolo is now known as clobrano === Oer is now known as OerHeks [09:14] o/ [12:13] PR snapd#3046 closed: many: merge release/2.23 into master [12:14] PR snapd#3062 opened: many: merge release/2.23 branch back to master === cachio_afk is now known as cachio [12:30] PR snapd#3063 opened: tests: re-enable tests for /dev/pts on core [12:32] jdstrand: hey! [12:33] jdstrand: one partner snap was using sysctl -w net.ipv4.ip_forward=1 [12:34] jdstrand: oh actually sorry, I read wrong [12:34] jdstrand: I was about to ask that sysctl be allowed to run [12:34] but I see that's correctly already part of network-control [12:38] jdstrand: (I thought writes to proc/sys were allowed but not running sysctl, but it is allowed - sorry for the bother) [12:38] it's just that the snap was lacking network-control [12:40] actually this might miss rw on forwarding [13:22] lool: use firewall-control for ip_forward. I agree this should also be in network-control and have added a todo for that [13:22] jdstrand: I think it's actually in network-control [13:22] it isn't (I just checked) [13:23] @{PROC}/sys/net/ipv{4,6}/** rw, [13:23] lool: No such command! [13:23] oh, yes, ok, good [13:23] I only grepped for ip_forward [13:23] * jdstrand removes todo [13:24] jdstrand, do you remember if apparmor had issues with all overlay filesystem variants, or was that overlayfs specific [13:24] JamieBennett: hey, fyi, I drove the store reviews down such that the only things that are left are classic confinement snaps from non-Canonical employees [13:24] (i remember that was discussed at some sprint) [13:24] I had initially thought sysctl was missing because the ordering of the files wasn't the same (sysctl mentioned just before proc entries in https://github.com/snapcore/snapd/blob/master/interfaces/builtin/firewall_control.go but in separate listing in https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go) [13:25] ogra_: it's mostly overlay and overlayfs. iirc, aufs is mediatable to a large extent (but our policy isn't written for it). I'm going to defer to tyhicks and jjohansen on the details === JanC is now known as Guest30327 === JanC_ is now known as JanC [13:29] jdstrand: OK, let me take a look, thanks [13:30] Hi guys! [13:31] I have two pull requests https://github.com/snapcore/snapd/pull/3045 and https://github.com/snapcore/snapd/pull/3051 [13:31] PR snapd#3045: interfaces: add random interface [13:31] PR snapd#3051: interfaces: add consoles interface [13:31] Unit tests pass for them, but other tests fail=( [13:31] Could you, please, take a look? [13:45] niemeyer, see above ... seems aufs could be made working for your ideas [13:45] ogra_: Problem is it's not in mainline, which means cross-distro headaches [13:46] yeah, indeed [13:46] same for ubuntu-core kernels etc ... [13:55] niemeyer, hi=) === hikiko is now known as hikiko|bbl [13:57] renat: Heya [14:04] niemeyer, could you please look at my pull requests related to consoles an random interface. Test failed because of the timeout [14:06] renat, uhm ... tty0 isnt always the system console ... you should better read it from /proc/cmdline [14:06] (in fact tty0 is very rarely the system console on actual ubuntu-core images) [14:11] renat: Will do! We've been rotating over the open PRs two or three times a week [14:12] niemetyer, thanks! [14:12] niemeyer, sorry [14:12] renat: np, pinging is fine as well [14:13] ogra_, we need an interface to access that file) [14:13] renat, even if it isnt your console device at all ? [14:14] renat, i'd keep /dev/console and dynamically allow whatever is defined in console= from 7proc/cmdline [14:14] */proc [14:18] ogra_: re overlay variants> I think aufs has an issue similar to ecryptfs (they're both stacked filesystems) where the policy has to grant permissions to two different filesystem paths [14:19] ogra_: that's something that can be worked around in policy [14:21] ogra_ thanks. I need to read more about it) [14:35] PR snapd#3056 closed: overlord: when shutting down assume errors might be due to cancellation so retry [14:39] PR snapd#3062 closed: many: merge release/2.23 branch back to master [15:08] PR snapd#3057 closed: systemd: mount the squashfs with nodev === JanC_ is now known as JanC [15:59] mcphail, you asked me about the nextcloud snap notifying you. I'm not sure when you pinged me, but I was out last week [16:00] mcphail, from talking with oparoz, it sounds like there's an app I might be able to tie into for notifications (we have a bug for it), but I haven't had a chance to look into it yet === hikiko|bbl is now known as hikiko [16:10] ogra_: ping, are you around? Could you please review https://github.com/snapcore/snapcraft/pull/1198/files ? [16:10] PR snapcraft#1198: tests: add manual tests for the kernel snaps [16:10] elopio, i looked yesterday already buit there wasnt much there ... checking againg [16:10] -g [16:12] elopio, i think sergiusens' comment still applies, i'm not sure where they maintain the Makefile tree nowadays, most likely not under lp:pc-kernel-snap anymore ... bjf would knwo [16:13] ogra_: I thought you maintained the make. This makes a lot of sense, because it's not booting :) [16:13] bjf: ping, where do you have the snapcraft.yaml for the pc kernel? [16:13] elopio, i used to and then handed over to the kernel team ... since it is their realm after all [16:14] elopio, the instructions look fine to me [16:15] elopio, you dont need the --image-size 3G, that way you also test the auto-resize on first boot alongside ;) [16:15] -image-size 3G is really only needed for kvm [16:15] I'll remove it. Thanks. [16:16] elopio, https://launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial [16:18] oh, interesting, so master only has the makefile and the snapcraft.yaml's are in branches ... such a setup had never struck me [16:18] * ogra_ now knows why he handed it over ;) [16:23] bjf: thank you! If you have some minutes, it would be nice to also get a review from you: https://github.com/snapcore/snapcraft/pull/1198 [16:23] PR snapcraft#1198: tests: add manual tests for the kernel snaps [16:24] i wonder if you cant actually force-sideload a kernel on an existing image to test ... [16:25] (surely breaks the auth stuff in the end but probably a lot less work for a one-shot test to see if it still boots) [16:28] ogra_: this is not a lot of work, as we do it only if we change the kernel plugin, a couple of time before the release. [16:30] elopio, hmm, so you test the kernel plugin by building a kernel that doesnt use the kernel plugin ? [16:32] ogra_: the 96boards example uses the kernel plugin. That's the test we wanted. [16:33] elopio, right, then you dont want bjf's branch [16:33] I added pc only for completeness. I'm not yet sure what we win by running it, as we almost never change the make plugin these days, so I'm not yet sure when we should run it. [16:33] since that uses binaries from the archive [16:33] like all our offical kernel snaps do [16:34] (to get the signing key for potential secure boot solutions) [16:34] yup. Ideally as we discussed some days ago, the signing could be done with scriptlets and we could use the kernel plugin for all our plugins. [16:35] but that's not something we are in a hurry to do, I think. [16:35] elopio, i think ppisati has trees for all kernels that can use the kernel plugin directly [16:35] the signing cant be done with scriplets ... because you dont have the secret key [16:35] ogra_: I'm trying to add those to our nightlies. https://github.com/elopio/snapcraft-de-noche/pull/21/files [16:35] PR elopio/snapcraft-de-noche#21: Add the kernels [16:36] with some errors there still to investigate. [16:36] afaik the secret part of the archive key is spread across multiple people and split ... and parts of that live in a safe somewhere [16:36] so signing something with it manually will be quite a challenge [16:37] elopio, yeah, that one looks more correct for testing the plugin [16:39] elopio, just ignore the Makefile stuff then and use https://github.com/elopio/snapcraft-de-noche/pull/21/files ... that will definitely test the right thing [16:39] PR elopio/snapcraft-de-noche#21: Add the kernels [16:40] testing the Makefile side should simply be done by installing the latest official snap from edge ... [16:41] (or beta ... or wherever brad lands this by default) [16:41] right, and that shouldn't be part of snapcraft's release process, that sounds good to me. [16:41] yeah [16:42] i'm not sure how well or how often the snapcraft.yaml based builds get tested at all though ... i knwo paolo recently tested dragoboard due to a mailing luist discussion ... but since we dont use these kernels by default i wouldnt count on regular testing [16:43] so your results might vary [16:43] (i.e. the kernel plugin might DTRT but the resulting kernel might not boot etc) [17:13] kyrofa: cool! Was wondering if there was something built into snpad which can send notifications on updates? Would be a nice feature to have [17:13] mcphail, not that I know of anyway [17:13] mcphail, probably a better question for niemeyer [17:13] kyrofa: ta. I'll maybe file a bug/feature request === lazyPwr is now known as lazyPower [17:41] ogra_, its still not working right for me, date reports the correct time and zone, but timedatectl does not [17:52] ogra@dragonboard:~$ date [17:52] Sat Feb 18 13:09:41 UTC 2017 [17:52] ogra@dragonboard:~$ sudo timedatectl set-timezone Europe/Berlin [17:52] ogra@dragonboard:~$ timedatectl [17:52] Local time: Sat 2017-02-18 14:10:08 CET [17:52] Universal time: Sat 2017-02-18 13:10:08 UTC [17:52] RTC time: Fri 1970-01-09 07:49:18 [17:52] Time zone: Europe/Berlin (CET, +0100) [17:52] Network time on: no [17:52] NTP synchronized: no [17:52] RTC in local TZ: no [17:52] ogra@dragonboard:~$ date [17:52] Sat Feb 18 14:10:12 CET 2017 [17:52] pmcgowan, works fine here [17:52] ogra_, wait 5 mins [17:53] or watch journalctl for when the daemon runs [17:53] actually 2 mins should do [17:54] pmcgowan, well, iu see the log warning, but thats just a warning ... [17:54] ogra_, run timedatectl now [17:54] to see whats set [17:55] oh, you are right [17:55] funny [17:55] the problem I started with is snapweb calls that over dbus [17:55] well its becuase of the logic I mentioed int he bug [17:55] the daemon resolves the link and gets the wrong file [17:55] why doers snapweb not use date [17:55] it displays the tz [17:55] there is no guarasntee we will even keep timedatectl around [17:56] so does date [17:56] date must get it from somewhere else [17:56] we can change snapweb, now that we understand [17:56] it just asks libc [17:57] yeah, we migth decide to drop timedatectl and ship ntp or whatnot ... dont rely on any tools being here [17:57] hmm ok [17:57] let me repurpose the bug [17:57] shell and libc (and recently a basic python interpreter) is the only stuff we guarantee [17:57] everything else can always change [17:58] understood [17:58] ogra_, oh we also set time with that api [17:58] will open a new bug [17:58] the old one I guess can be marked fixed [18:02] Bug #1650688 changed: timedatectl set-timezone fails on UC16 [18:15] If I have a simple daemon in a snap that sets some files in /proc, how I would unset those on removal? [18:16] stop-command doesn't seem right since its not a long running service [18:24] coreycb: from what I am seeing, the latest versions of pip and setuptools ignore entry_points in setup.cfg [18:25] we use 9 in our plugin, xenial in the distro has 8.1 and zesty has 9 [18:25] sergiusens, that's not very nice of them [18:25] coreycb: python distribution is a mess [18:25] coreycb: but I already ranted about this [18:26] sergiusens, is that a bug upstream then with pip or setuptools? [18:26] still need to look into it a bit, but I might workaround the problem with a flag you can probably use [18:26] coreycb: haven't pin pointed it yet; elopio asked barry for some guidance [18:26] sergiusens, ok cool [18:26] an attribute I mean, to seup the version of pip you need [18:26] sergiusens, thanks [18:27] sergiusens, that'd be a nice work around [18:41] PR snapd#3064 opened: packaging: rename the file shipping snap-confine AA profile [18:42] jdstrand: hello [18:42] jdstrand: can you please review 3064 [18:42] jdstrand: if possible we'd like to use that as the fix for all the issues (including those that block the kernel) [18:43] jdstrand: I just made it, didn't run any tests yet [18:52] jdstrand: thank! [18:52] thanks! [18:54] np [19:02] jdstrand: I'm considering _not_ removing the old conffile in this release [19:02] jdstrand: so that we can just relase it with minial risk [19:02] jdstrand: and unblock the kernel and snapd [19:02] jdstrand: and if this works we can remove it in 2.24 [19:03] (the stale conffile) [19:10] zyga: there isn't really any more risk with removing it, and I'm pretty sure the sru team is going to require it (you don't ship the old one any more after all) [19:10] zyga: perhaps discuss it with them before you prepare an upload [19:10] jdstrand: are you sure? I don't have a way to test this (to see if this explodes dpkg) [19:10] ? [19:10] yes, that's very smart [19:14] gosh I hate dpkg [19:15] conf-file handling is just so annoying and hard to get right [19:21] jdstrand: is this sufficient? [19:21] http://paste.ubuntu.com/24216924/ [19:25] zyga: :P [19:25] Pharaoh_Atem: hey [19:25] dpkg is kind of braindead with conffiles :) [19:26] zyga: you know what I'm going to bug you about :) [19:26] Pharaoh_Atem: yes, I know [19:26] Pharaoh_Atem: I have some good news [19:26] Pharaoh_Atem: looks like I finally managed to reserve some time for !ubuntu work [19:26] thank god [19:26] Pharaoh_Atem: details when I can release that :) [19:27] Pharaoh_Atem: but not tonight [19:27] people are getting bitchy at me about it :( [19:27] I really undestand, I'm sorry about it [19:27] Pharaoh_Atem: I really wish we had less fires and less other things [19:27] just get a fireman :) [19:28] well, don't look, here I come [19:33] zyga: you can't be the only fireman...? [19:34] zyga: I've not done this for a while, but it should be, yes. you can perform an upgrade to 2.23.4 or higher and verify the removal. you should also run lintian on the deb [19:35] jdstrand: sounds like a plan, thank you [19:35] Pharaoh_Atem: the main fireman is on sick leave so I'm taking the honors [19:35] ah [19:38] * davmor2 pictures zyga like this now https://en.wikipedia.org/wiki/Fireman_(steam_engine)#/media/File:Baureihe52Heizer.jpg what do you mean wrong fireman [19:41] davidcalle: wow, that guy is dressed better than me for the 99.9% of my life ;) [19:41] gee [19:41] I should have become a train driver [19:41] zyga: wrong da ;) [19:43] ah, always [19:44] is there a way to tell irssi to do longest comon prefix and then stop? [19:44] like in vim [19:44] set wim=longest,list [19:49] zyga: I think there is a way to set last replied or something like that can't remember how though [19:49] nah, I don't want last replied [19:49] I want consistency among differenet programs :/ [19:50] zyga: no idea then [19:53] jdstrand: I see /etc/apparmor.d/usr.lib.snapd.snap-confine.dpkg-old [19:53] ah but that file is ancient [19:53] ok, all good otherwise [19:53] I'm going to upload to the PPA now [20:18] Bug #1674468 opened: More than 36% overhead running tests for dbus interface in snap === mwhudson_ is now known as mwhudson [20:27] zyga: hi [20:27] zyga: did you see https://bugs.launchpad.net/snappy/+bug/1674193 ? [20:27] Bug #1674193: core snap's configuration hangs on debian === StoneTable is now known as aisrael === Saviq_ is now known as Saviq === iahmad_ is now known as iahmad === robru_ is now known as robru === diddledan_ is now known as diddledan [20:31] hi guys -- what am I doing wrong? http://paste.ubuntu.com/24217290/ [20:32] dpb1_, what is the output of `snap --version`? [20:33] http://paste.ubuntu.com/24217297/ [20:33] kernel update? [20:34] dpb1_, can we also see the output of `snap interfaces`, please? === madprops_ is now known as madprops [20:34] error: no interfaces found [20:35] dpb1_, huh, that doesn't sound good. How about `snap list`? [20:35] No snaps are installed yet. Try "snap install hello-world". [20:36] I just cleared out all my snaps trying to get the 'ubuntu-core' snap upgraded to 'core' === ulkesh_ is now known as ulkesh [20:36] dpb1_, ah, okay. Does the same thing happen if you just try to `snap install core`? [20:36] kyrofa: yes, both with and without sudo [20:37] dpb1_, not sure what's happening there. I'll refer you to zyga [20:37] kyrofa: I'm running apt-get dist-upgrade now just to remove uncertainty. [20:37] will reboot as well [20:47] PR snapd#3065 opened: Allow seeding a snap with classic confinement [20:48] hi all i exchange some words with @pedronis and @mvo about a future feature for autoconnecting snap plug to core slot from gadget: is there some information more specific about the feature, the roadmap and chances to collaborate? [20:51] NicolinoCuralli: We don't have the feature in place yet, but it does make sense for it to exist [20:51] NicolinoCuralli: Gut feeling is that this should live in the model assertion, and be restricted to snaps present in the assertion as well [20:52] NicolinoCuralli: I need to catch up with pedronis to brainstorm on this, but I can see us extending the snap-declaration logic we have today to consider entries specified in the model [20:53] NicolinoCuralli: We have existing language today which is very flexible and defines when exactly to connect certain things automatically [20:54] ogra_: gentle reminder that packageproxy still breaks if your pc reboots and leaves a stale lock around :) [20:55] So it is a one-shot enabling mechanism: is it possibile to extend during the lifetime of device this trust for other interface or snaps? [20:55] @niemeyer So it is a one-shot enabling mechanism: is it possibile to extend during the lifetime of device this trust for other interface or snaps? [20:55] NicolinoCuralli: No such command! [20:56] NicolinoCuralli: It's not one-shot.. declarations can be updated over time [20:56] NicolinoCuralli: Including the model one [20:57] NicolinoCuralli: As a first idea, we should probably restrict these declarations to snaps that are shipped with the model itself [20:57] NicolinoCuralli: Having them in one of the two ends (either as plug or slot) [20:58] We may lift that resitriction, but then we need to think about social consequences more broadly, and it's good to buy time before we take that sort of decision [21:02] NicolinoCuralli: e.g. developers would be pretty unhappy to find out that their snaps are broken because of custom declarations on particular devices === jkridner|pd is now known as jkridner [21:03] I need to step out for a moment.. back soon [21:11] mwhudson: hey [21:11] mwhudson: I saw that [21:11] zyga: that's a start :) [21:11] zyga: any ideas what's going on, or how to start debugging? [21:12] mwhudson: with so many things not working lately I don't have any ideas [21:12] mwhudson: I heard that mvo reproduced it by just installing anything [21:12] @niemeyer: I understand the danger for other snaps but in a contest where installed snap are from only one developer sounds very useful to have the changes to enabling trust between core and other snap in a more relaxed way [21:12] NicolinoCuralli: No such command! [21:13] mwhudson: I'm too tired with the constant fires to help with this tonight [21:13] zyga: eh, that's not very reassuring :/ [21:13] zyga: fair enough [21:13] zyga: mvo reproduced it on debian? or on ubuntu? [21:13] niemeyer : the picture with the autoconnection built by model assertion seems good to me [21:13] mwhudson: on debian [21:13] ok [21:13] yes, that's my impression too [21:14] mwhudson: looks like snapctl or something like it explodes and doesn't die [21:14] (maybe one thread dies) [21:14] zyga: yeah, does it log anywhere? [21:14] never tried it though [21:14] nope, not that I know of [21:14] or i can hack it so it does i guess [21:14] i found a bug saying "the output of running hooks is not shown anywhere" [21:14] mwhudson: it's tricky as snapd consumes the output [21:15] mwhudson: but I think snapctl just explodes [21:15] no need for the hook logic [21:15] (maybe) [21:15] but also, I should shut this down and go to sleep [21:15] zyga: can i fake up the environment the hook runs in somehow? [21:15] zyga: tell me on the bug report tomorrow, sleep now :-) [21:15] mwhudson: maybe but I don't know how [21:15] mwhudson: I mean snapd verifies it [21:16] mwhudson: maybe some full system thing can look [21:16] mwhudson: or if you reproduce it just look at what's left of snapctl [21:16] mwhudson: this is especially odd if debian has no confinement [21:16] hm i wonder if i had confinement enabled [21:16] some of my debian vms do [21:17] check if it happens on vanilla [21:17] actually [21:17] my debian 9 system is ok [21:17] so perhaps confinement [21:17] if confinement we never probably expect that to work [21:18] so yeah this vm did have security=apparmor apparmor=1 on kernel command line [21:18] booting without that now [21:18] mwhudson: it's not worth debugging that case IMHO, it's not even meant to work, snap-confine doesn't work on debian-9 with apparmor [21:19] mwhudson: and the generated profile probably doesn't work really [21:19] mwhudson: all in all, good luck :) [21:20] oh ffs why is the vm fscking [21:20] zyga: thanks :) [21:22] er i have a godd running and i can't kill it with SIGKILL [21:22] maybe i should just give up on computers for today [21:22] haha, nice [21:22] mwhudson, haha, I hate days like that [21:22] mwhudson: probably it's apparmor preventing the signal to arrive [21:22] s/probably/maybe/ [21:24] Mar 21 10:24:21 aeglos kernel: [ 1310.730799] Buffer I/O error on dev sdd, logical block 139859, lost async page write [21:26] PR snapcraft#1201 opened: demos: make ROS demos support exiting after success [21:26] unplugging the card reader made godd die [21:28] maybe i just hate sd cards [21:31] yeah different sd card worked fine [21:34] and now libvirt has stopped working? [21:35] definitely a computers day [21:55] kyrofa: what appears to be failing on that sudo snap install core: http://paste.ubuntu.com/24217781/ === daniel1 is now known as Odd_Bloke [21:56] I'm not sure what those are signaling to me [21:56] dpb1_, indeed. Me neither [21:57] dpb1_, would you mind logging a bug? [21:57] (against snapd) [21:57] doing [22:01] I'm having a problem with the keepassXC snap (but I think that it's not related to the application): I installed the snap with --classic confinment, but even then I can't access NFS mounted directories from the app, does anybody know why? [22:01] kyrofa: thx: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1674484 [22:01] Bug #1674484: snap install core failure: permission denied (apparmor)

[23:43] Bug #1674505 opened: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build