=== chihchun_afk is now known as chihchun === JoshStrobl is now known as JoshStrobl|zzz === chihchun is now known as chihchun_afk [04:16] Bug #1652262 changed: subiquitycore exception in controller.run [04:51] PR snapcraft#1552 opened: tests: replace the mosquitto demo test with a snapd integration test [07:25] ppisati: could you please trigger a new kernel build for edge? I pushed a bugfix for ubuntu-core-initramfs-tools recently [07:35] ogra_: you showed me a bunch of empty revision dirs under /snap/core some days ago (iirc). could you pastebin that again? I was looking into this this morning but I haven't managed to reproduce it yet (and the code seems to be doing the right thing). so I'm curious to learn more how this is happening [07:38] zyga-ubuntu: I wonder if we need to look at the issue that we need to make /snap shared again for lxd. iirc there was this issue that the mounts happen before we run snap-confine for the first time to do the shared mount magic [07:38] zyga-ubuntu: you wanted to look if we can do something with namespace, we may need a brute force approach with an early mount unit [07:44] mvo: right, I was thinking about it last night; I wanted to mention that it also happens on 14.04 so it's relateively easy and painless to interate on [07:44] mvo: I haven't had the time to try though, I'm iterating on the feedback from jamie now [07:48] zyga-ubuntu: ok - my approach would be a mount unit similar to the one we have in 14.04 - but that is very heavy handed and may get tricky as we need to run it after /snap is mounted but before anything under /snap/* is squashfs mounted, so the right before= is tricky [07:49] zyga-ubuntu: also please check https://github.com/snapcore/core-build/pull/21 and https://github.com/snapcore/core-build/pull/22 if you have a moment, should be painless [07:49] PR core-build#21: Release 0.7.43+ppa23 [07:49] PR core-build#22: unit testing for sync_dir() [07:49] mvo: maybe we need After on actual units? [07:49] (mount units we create) [07:49] mvo: ok [07:50] zyga-ubuntu: yeah, that would work I think, we just need to make sure we rewrite existing ones (I don't think we do this currently) [07:50] mvo: no, we don't [07:51] mvo: I'd strongly enourage us to try SyncDir thing for that [07:51] sergiusens: hey, so you know, we are still following up on the deployment of the latest dn, I'll ping you when it's resolved [07:51] PR core-build#21 closed: Release 0.7.43+ppa23 [07:51] mvo: as it has the "ensure" property of patching up broken state [07:52] * mvo nods [07:53] mvo: the tests look ok, I'm wondering if you tried using the VM-based tests that would run this in the real initrd [07:54] zyga-ubuntu: I did, but got stuck seting up the right environment for this [07:54] mvo: I see, what was the main difficulty? [07:54] zyga-ubuntu: also travis is broken since the VM based tests got merged, I'm looking at this right now [07:54] mvo: oh? It passed earlier [07:54] mvo: (I mean, it did go green before this was merged) [07:55] zyga-ubuntu: maybe I did not try hard enough, but I need to simulate the /writable and core snap changes so that sync dir can be tested, setting up changes in the core snap in /etc was were I got stuck [07:56] test init process did not signal boot-ok [07:56] zyga-ubuntu: please check https://travis-ci.org/snapcore/core-build/builds [07:56] zyga-ubuntu: maybe coincidence, I just started looking at this [07:57] zyga-ubuntu: aha, did you retrigger it? [07:57] zyga-ubuntu: the first actual failure is much later in #41 [07:57] PR #41: add X-Ubuntu-Wire-Protocol to the headers [07:57] core#41 [07:57] PR core#41: limit the version string to 32chars (this is what the store allows) [07:57] mvo: I re-started older test jobs that got cancelled [07:57] zyga-ubuntu: and please don't get me wrong, the iqemu tests are nice, just seems to be not nice for my particular test [07:57] mvo: we'll see when it stated failing (hopefully) [07:58] zyga-ubuntu: aha, nice [07:58] core-build#41 [07:58] mvo: no worries, I just wanted to understand what was hard. I agree that it would be easier to do some of those tests with more of the system around (writable disk or SD card) [07:58] thanks pedronis, looks like mup does not know about core-build [07:59] zyga-ubuntu: I also looked briefly at the gpt regression bug and how to test that but that looks really tricky to unit test :( [07:59] zyga-ubuntu: *but* I think we should have a spread test for this, I will ponder a bit how to test it [07:59] mvo: yes [07:59] mvo: I think both would not hurt :) [07:59] +1 [08:00] zyga-ubuntu: silly question, but do you know why the tests did not run on core-build? [08:01] (or why they were canceled) [08:01] mvo: no, no idea [08:02] mvo: I just did a test on my machine, clean tree, VM tests passed [08:02] mvo: everything does fail with: test init process did not signal boot-ok [08:02] mvo: let me push a pr that runs tests in verbose mode [08:05] mvo: hmmmm, why there's no travis here: https://github.com/snapcore/core-build/pull/23 ? [08:05] PR core-build#23: tests: treat --verbose as -v [08:05] PR core-build#23 opened: tests: treat --verbose as -v [08:06] ah, it just showed up [08:07] zyga-ubuntu: interessting [08:08] mvo: i guess, every kernel [08:09] mvo: https://travis-ci.org/snapcore/core-build/builds/275784391?utm_source=github_status&utm_medium=notification ??! [08:10] zyga-ubuntu: "test init process did not signal boot-ok" - at least it is concistent, ie #27 also failed with the same error [08:11] zyga-ubuntu: is it supposed to show more output? maybe its just slow? how much time does it have for this signal? [08:11] mvo: I found the issue [08:12] ppisati: thank you, please let me know when new edge kernel is available and I will test right away [08:12] https://travis-ci.org/snapcore/core-build/builds/275784391#L2178 [08:12] mvo: fixing that now [08:13] mvo: cpio was in the middle of a pipe so the erorr was silent [08:13] mvo: ack [08:13] mvo: I pushed it back to my PR [08:18] mvo: it passed now [08:19] mvo: so whatever caused cpio to get yanked from the image we chroot into won't affect us anymore [08:19] mvo: please merge https://github.com/snapcore/core-build/pull/23 for happiness [08:19] PR core-build#23: tests: treat --verbose as -v [08:23] @zyga-suse, @zyga-ubuntu, @zyga: great accomplishment with Manjaro and Snappy [08:23] phil_m: No such command! [08:24] phil_m: I'm still working on opengl support but snapd proper works ok [08:24] ok, so what was the problem? [08:25] if some is needed to be changed within the kernel, we can do that also [08:25] phil_m: so far none, the patch I cherry picked had different sum than the one from the URL, maybe it was corrupt there? [08:25] phil_m: would you be interested in cherry-picking apparmor support into the manjaro kernel like solus did? [08:25] ah ok. [08:25] phil_m: this would give you apparmor confinement [08:26] I've to see about appamor [08:27] phil_m: the patch against 4.14 should be small now, 4.15 will have everything but I think we missed the window with some patches [08:28] phil_m: do you have the apparmor userspace tools packaged? [08:29] well, we had apparmor in our distro but removed it: https://github.com/manjaro/packages-core/issues/49 [08:29] zyga-suse: ta [08:29] phil_m: I see I have to add one more patch to cmd.go, [08:29] PR core-build#23 closed: tests: treat --verbose as -v [08:30] since you have full write access to our community packages git repo you can also add the needed patches directly if you like. [08:31] phil_m: thank you, should I discuss this with other manjaro developers before proposing PRs? [08:32] na, not needed [08:32] phil_m: thank you, I'll plan what is the best course of action [08:32] we are open and since you know better about snapd you can push it directly [08:32] however one of our maintainers has to package it. [08:32] phil_m: please stick around and let's chat periodically about what else might be needed [08:32] sure, no problem in that. [08:33] phil_m: that's great, I'd love to co-maintain the package if that's okay [08:33] sure, why not. we have to see how we can do that properly. [08:33] phil_m: and if the main packager could be here or on the forum (or both) for release coordination, that would be perfect [08:34] you can always ping me via email if needed or write in github that a new release needs to be packaged [08:34] phil_m: thank you! I'll definitely stay in touch [08:34] it should be packaged then on the same day with a small delay [08:35] since we are not Arch we are more open for new packages if they make sense. [08:35] yes, we have a release cycle that has a moment when the package is in testing and once we are happy across the spectrum of systems we mark it as stable [08:35] thank you :-) [08:35] we also have some kind of release cylce with each package. we use branches and move them when ready to the next one. [08:36] where can I read about that? [08:37] I noticed we never marked this https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 as backlog, fixed now [08:37] more or less in our forum or wiki [08:37] https://wiki.manjaro.org/index.php?title=Repositories_and_Servers [08:37] testing gets updated mostly every second day. [08:37] unstable daily and stable in weekly basis [08:41] phil_m: I think this matches snapd release cycle well, we are trying to (still trying though) make a reliable mothly cycle [08:42] https://manjaro.github.io/homepage/public/features/background/ [08:42] this is a simply page explaining how we manage our packages [08:43] mvo: let me when you want to chat about what's left for repairs [08:48] pedronis: I'm finishing a small branch, then I should be ready so ~30min or so (depending a bit on how tests look) [08:49] zyga-suse: looking good so far according to your screens ;) [08:49] mvo: ok [08:49] yes :) [08:49] phil_m: though I need to investigate two things before I call it good [08:50] na, no pressure [08:50] take all the time you need [09:03] mvo, http://paste.ubuntu.com/25539231/ [09:05] ogra_: and all empty except the last ~3 ones, right? [09:05] PR snapd#3920 opened: snap-confine: improve error message if core/u-core cannot be found [09:07] mvo: nice, thank you [09:07] zyga-ubuntu: thanks for the quick review! [09:08] darn [09:08] mvo, hi, I'm not really sure what failed on https://github.com/snapcore/snapd/pull/3916, is it just flakiness in tests setup? [09:08] PR #3916: add support for socket activation in apps [09:09] a bird just landed next to my window and I even have a camera standing by for that occasion but it ... flew away before I got the shot [09:18] ackk: yeah, the test failure looks not related to your code [09:18] mvo, can you restart just that build? or it doesn't matter for the review? [09:18] PR snapcraft#1553 opened: lxd: instructions for /etc/sub{u,g}id after failed start [09:22] Hey, I see that GPIO pins cannot be accessed via a snap. Is this correct? I have a sensehat (https://www.raspberrypi.org/products/sense-hat/) connected a Pi3 via GPIO pins. I would like to obtain readings from those sensors via a python application. If this possible with a python app captured in a snap? [09:24] ashwind: hey, is your snap using the right interfaces? is it a service running as root or a command running as your user? [09:25] I haven't fully implemented to snap yet. [09:25] I just saw that gpio pin access is restrcted [09:25] https://snapcraft.io/docs/reference/interfaces [09:26] ashwind: using the right interface you can definitely use GPIOs [09:26] oh awesome, please advise [09:26] ashwind: the way this works is that a given snap can be given rights to use a restricted interface [09:26] ashwind: implement your snap as you would normally [09:27] ok done [09:27] ashwind: installation instructions for a given device should show how to connect the right GPIO pins correctly [09:27] ashwind: for specific devices this will be available as a gadget feature (the gadget can pre-connect things correctly) [09:27] ashwind: auto-connect is not that useful for GPIOs because there are typically plenty of them [09:28] (and you get access to specific pins, not to all of them in general) [09:28] and because this differs from device to device and auto-connect logic is not smart enough to know which one is the right one [09:32] mvo, yeah [09:33] mvo, well, actually *all* empty ... [09:34] ogra_: hm? even current? [09:34] yes [09:35] ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current [09:35] lrwxrwxrwx 1 root root 4 Sep 13 22:59 /root/snap/core/current -> 2925 [09:35] ogra@anubis:~/datengrab/pi3$ sudo ls -l /root/snap/core/current/ [09:35] insgesamt 0 [09:35] ogra_: ok, so there is something else going on, that explains why I can't reproduce it probably [09:36] thhis system has been usinng snaps since day one, but there is no ubuntu-core dir theer [09:36] ogra_: and this is on the running system? [09:36] thats my desktop macine [09:36] *machine [09:37] ogra_: ohhhh, these are your data dirs [09:37] (so yes) [09:37] ogra_: sorry, I misunderstood [09:37] right [09:37] well ... roots data dirs [09:37] didn't we have a complicated discussion about removing those [09:37] not hamful, just wasting inodes ... but still ugly [09:38] they are not easy to find across distros [09:38] and root indeed in a special case [09:38] I think we look only for /home/* atm [09:38] you mean /root isnt root in soome distros ? [09:38] no that homedirs are not quite in the same place [09:38] (why do we even create them ?) [09:39] are they relevant for anything ? [09:39] probably they get created when we run the configure hook? [09:39] zyga-ubuntu: so i implemented my snap to be of type "app", do i need to change it to "gadget"? I see a pi3-gadget git repo https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml, how does this relate? [09:39] i dont think core would ever wite to them [09:39] or maybe we are not lazy at all [09:39] don't remember [09:41] mvo: I'm around if you want to chat btw, let me know [09:41] looking at /root/snap core os the only snap with that behaviur [09:41] *core is [09:41] pedronis: yeah, one minute and I'm ready [09:42] ogra_: I suspect it's a consquence of running the configure hook [09:42] all other packages remove the dirs on uninstall/refresh [09:42] atm [09:42] might be that this is what creates them ... but the bug seems to be in te emove code [09:42] *remove [09:42] as I said the remove code does only /home/*/snap/... [09:43] afaik [09:43] we discussed improving it [09:43] but I think it was postponed [09:43] and root ends up like this [09:43] yeah, it isnt critical or anything [09:43] pedronis: I have a look, looks trivial to include /root as a speical case [09:43] even if not perfect [09:49] zyga-ubuntu: hmm let me read up, thanks! [09:50] zyga-suse: I'd to go. Keep me updated via email on the snappy progress on Manjaro. If needed I can package it, when done. [09:57] re [09:58] ashwind: no, you should keep your snap as "app" [09:58] sorry i was on the phone [10:07] hmm, do we have any dir in /run that a dameon can write to and that i can see as normal user ? [10:08] ogra_: $XDG_RUNTIME_DIR perhaps but not sure [10:10] zyga-ubuntu, well, that seems tio be hidden from the otside world (or being deleted when i exist "snap run --shell" [10:10] ) [10:11] but i found a solution ... === JoshStrobl|zzz is now known as JoshStrobl [10:39] zyga-ubuntu, your initrd tests make everything in core-build explode ... [10:39] $ $CHROOT_RUN sh -c 'cd build/initramfs/testing; LC_ALL=C.UTF-8 ./aaa-tests.py --verbose' [10:39] warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] [10:39] test init process did not signal boot-ok [10:44] mvo, so one thing I'm not totally sure about that PR for socket activation is whether it's better to keep the socket-mode as a string or an integer [10:44] ogra_, pedronis: fwiw, I am poking a bit at the user data thing for root/ and I think I'm on a good course [10:44] yay [10:45] mvo, declaring it as an int in the snapcraft schema makes it render in the snap as decimal, not octal [10:45] ackk: yeah, I would prefer a string for this reason, unless there is yaml magic to make it render in the natural 0xxx notation [10:46] mvo, ok, then I can just revert the last commit (I had initially it as a string) [10:46] ogra_: I think its even buggy in the forward-data copy case for root :/ anyway, I am looking [10:46] * zyga-ubuntu -> lunch [10:46] ackk: sounds good, we will also need input from niemeyer on your socket activation PR as it touches the yaml and we need sign off for that :) [10:46] ogra_: pull master [10:47] ogra_: it was fixed now [10:47] mvo, ok [10:48] zyga-ubuntu, well, i'm looking at master tests ... but if it is fixed now it is fine [10:49] zyga-ubuntu, mvo how did you guys get travis to do anything again ? it hasnt even started tests for a while [10:50] ogra_: it started instantly for me [10:50] ogra_: no idea [10:50] ogra_: maybe it hasn't been merged, there should be a PR open [10:50] ogra_: please look, I'm trying not to starve today [10:50] well it timed uot waiting fr starting the tests fr like 2 months now [10:51] unrealated to the tests ... travis never started at all [10:51] so someone has done something too make travis actually start again [10:51] ogra_: I started about a dozen jobs on core-build today [10:52] zyga-suse, right i did that nce a week for the last few weeks but travis only timed uot before even starting [10:52] something has changed that suddenly allows it to run tests again ... did we pay extra $$$ ? [10:52] nope, perhaps just smaller load [10:53] well, then better watch snapd now ... if it is load related we migth steal cycles from other snapcore trees [10:53] :) [10:54] (this is not what i understand as reliable CI :P ) [10:55] free, reliable, nice, [10:55] pick two [10:55] haha [11:08] PR snapd#3866 closed: many: implement fetching sections and package names periodically [11:08] * Chipaca dances [11:08] also, glad to have been into london yesterday and not today [11:08] * Chipaca dances a bit more [11:14] * zyga-ubuntu hugs Chipaca [11:14] barbaric times we live in [11:25] * zyga-ubuntu resumes coding [11:47] mvo, updated that PR, fwiw [11:54] mvo: added a couple comments, some we already discused to the snap-repair list/show PR [12:03] zyga-ubuntu, mvo, can we agree that "release" PRs in core-build simply get merged (i saw you guys did an actual review, i think this is pointless given it is only a changelog entry, the actual changes have been reviewed before anyway) [12:03] (and if the changelog is broken the loacla dpkg-buildpackage would error anyway and you couldnt upload) [12:03] *local [12:04] i.e. https://github.com/snapcore/core-build/pull/21 [12:04] PR core-build#21: Release 0.7.43+ppa23 [12:04] (reviews just waste time here IMHO) [12:05] indeed only if it is just the changelog bump :) [12:06] ogra_: well, I think it's good for spotting typos but I agree in general; given that those should be reviewed very quickly I wouldn't change much thoug [12:07] well, lets say they are "optional" then :) [12:11] mvo, hi [12:11] in rc3 it is failing to uninstall the network-manager [12:11] for db and pi3 [12:12] I can reproduce it running test tests/regression/lp-1606277 and then any other test [12:13] cachio: thanks, what is the error output? [12:14] mvo, https://paste.ubuntu.com/25540183/ [12:14] it works fine for example on pi2 [12:14] but for pi3 and db we get the same error [12:15] well, both have wlan [12:15] while pi2 doesnt [12:16] the log isnt really helpful since it only shows the final timeout after snap remove n-m [12:16] did you check what happens when you manually install/configure/remove n-m on such a device ? [12:16] cachio: hm, I would bet syscall filtering related, could you paste the dmesg output? [12:16] mvo, give me 5 please [12:16] cachio: oh, hold on, its dying on rmeove, right? [12:17] mvo, yes [12:17] cachio: in this case ogra_ may have a better theory, still the dmesg/syslog output will be helpful [12:17] i guess it cant deconfigure the wlan device properly [12:18] cachio: also, does reverting core fix it? wonder if it might be n-m related but the last stable is ~5 weeks old it seems so that is unlikely [12:20] mvo, give me 5 please, I am running the tests with -debug [12:21] cachio: thank you, no rush :) [12:24] PR snapd#3921 opened: interfaces: updates for default, browser-support, desktop, opengl, upower and stub-resolv.conf [12:26] mvo: fyi, ^ [12:26] mvo: and hi! :) [12:28] jdstrand: nice, thank you. and good morning! [12:35] mvo, dmesg https://paste.ubuntu.com/25540261/ [12:37] ogra_, for you too :) [12:40] this is the syslog when the error happened https://paste.ubuntu.com/25540285/ === cachio is now known as cachio- [12:47] cachio_, can we get the full syslog without the tail -50 ? [12:48] yes [12:48] "Failed to initialize control interface '/run/wpa_supplicant'.#012You may have another wpa_supplicant process already running or the file was#012left by an unclean termination of wpa_supplicant" [12:48] PR #12: Bugfix/lp1480248 test reenable [12:48] that looks suspicious [12:49] boo ... mup [12:50] PR snapd#3922 opened: snapstate: deal with snap user data in the /root/ directory [12:51] * Chipaca reads http://schd.ws/hosted_files/ossna2017/91/Linuxcon%202017%20NERF.pdf and doesn't know if he should show it to ogra_, or hide him from it [12:52] ogra_, https://paste.ubuntu.com/25540337/ [12:53] zyga-ubuntu: the error in 3920 is very confusing [12:53] zyga-ubuntu: no /snap/core/current on core [12:53] sergiusens: http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/ [12:53] cachio_, there you go ... the wlan got configured by systemd-networkd already (via some netplan setup i guess) ... i assume that is why n-m gets confused [12:53] sergiusens: could/should snapcraft warn about that? [12:53] PR snapd#3923 opened: asserts,cmd/snap-repair: represent RepairID internally as an int [12:53] mvo: ^ [12:53] mvo: are we hit by a bad build of core? [12:55] pedronis: nice [12:55] zyga-ubuntu: not sure, I try to reproduce now [12:56] Chipaca about what? [12:57] * sergiusens doesn't know who anyone is with lacking avatars ;-) [12:57] it is at all possible to install a lxd local snap? I get permission denied messages when it starts about reading /proc/self/attr/current and running aa-exec [12:57] (I did connect the lxd-support plug) [12:58] ogra_, that could be the reason, do you need any other log' [12:58] '' [12:58] ? [12:59] cachio_, well, not sure what to do here ... did your testing change that it leaves the wlan netplan config in place before installing nm where it didnt do that before or some such ? [12:59] nothing should have changed on core or in n-m in that area in ages [13:00] sergiusens: about a list of evil fake/typo packages in pypi [13:00] ogra_, no [13:00] zyga-ubuntu: base-ish snaps for Fedora, openSUSE, and Mageia on demand: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap/pipelines/11803392 :D [13:06] * zyga-ubuntu hugs Son_Goku [13:06] one small step for snap [13:06] I need to rewrite the tool to use the DNF API instead of the CLI (better control over the solver) [13:07] but it's a doing it [13:08] Chipaca oh, I think pip and PyPI itself should warn about that! [13:11] zyga-ubuntu: note that it won't produce bootable core snaps either :( [13:12] cachio_, as a hack/workaround you could simply try to remove the file in /run or kill wpa_supplicant before installing n-m or some such [13:12] this is clearly not a use case we support (having two config mechanisms manage the same device) [13:12] mvo, ^^^ ? [13:14] it is either netplan or network-manager ... (netplan has a specific config option for this to hand off management of the device to n-m) [13:18] https://wiki.ubuntu.com/Netplan has info about this [13:19] you will need to switch the renderer option before installing n-m [13:29] ogra_: thanks, I was in a meeting. btw, PR with the fix for your /root/snap/ stuff is up. unfortunately it will not cleanup the past but at least it should stop doing so from now on (well, $now==when-it-gets-merged) [13:30] mvo, well, it is just cosmetic anyway [13:30] ogra_: sort of, there is a real bug there too, the userdata of /root does not get copied forward on refresh - so its good that you brought it up [13:31] heh, great [13:31] mvo: I'm super confused, in my branch go vet seems to think the RepairID() is still a string in some places but test pass [13:32] ogra_, ok, i'll see how to rewrite that test in this case [13:32] thanks [13:32] cachio_, well, it shouold have failed before, interesting that it did not [13:33] also ... the n-m snap should probably be fixed to not steal an already otherwise managed interface [13:33] ogra_, perhaps it is a new test [13:33] i'll research a bit on that [13:33] ah [13:34] Son_Goku: bootable snaps are further down the line [13:34] Son_Goku: I would be happy with a working base === Guest28588 is now known as ^arcade_droid [13:56] mvo: niemeyer: I'm getting this (stalled run/no ouput): https://travis-ci.org/snapcore/snapd/builds/275875794?utm_source=github_status&utm_medium=notification [13:56] there is nothing super interesting in the PR [13:58] afaict [13:58] PR snapd#3924 opened: asserts,cmd/snap-repair: introduce a mandatory summary for repairs [13:58] pedronis: strange, I saw this in some other PR recently too but it seems to be very rare [13:58] mvo: I got it twice in a row [13:59] pedronis: Can't think of any reasonable reason [14:00] pedronis: Ah, now I can [14:00]