[00:00] What is the command to install two snaps in sequence ? [00:01] kyrofa snapcraft#1719 [00:01] PR snapcraft#1719: many: account for python shebang args in rewrite [00:01] sergiusens, that didn't restart, it's been going for two hours [00:01] kennyloggins: not sure i understand? `sudo snap install ; sudo snap install ` ? [00:01] bummer, why did it start only two hours ago? [00:01] sergiusens, I had to start it because snapd toasted my local adt runs [00:02] sergiusens, https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/12 [00:02] sergiusens, also, I did comment in the PR :) [00:03] kyrofa yeah, that I did see; do we need this though? [00:04] sergiusens, up to you, I'm fairly confident given that I had successful runs before the rebase, but they were on zesty [00:04] kyrofa elopio we need less tests, or broader ones; how many of the catkin tests could be merged into one? [00:05] same for all the other components [00:05] they could be condensed into on with multiple parts/apps [00:05] unless it warrants a separate one [00:05] but I am going to be pragmatic here, many are only separate because it looks good on paper [00:06] sergiusens, remember we're still not re-using the cache [00:07] Simpler tests are way easier to maintain [00:07] But yeah, we can definitely combine some catkin ones if that's the direction we want to go [00:09] This normally doesn't hurt quite so badly, we simply need to get in the habit of running them more often and paying attention to the result. I suggest caution in making decisions about our tests in our current state of pain [00:11] kyrofa well, tonight is your night and tomorrow is your morning, right? [00:11] :-) [00:11] Indeed [00:11] What is test-snapd-cups-control-consumer , exactly ? Is it for printers ? [00:13] kennyloggins: you can read it's description in `snap info test-snapd-cups-control-consumer` [00:13] but as the name implies, it's a test snap for snapd to test the cups-control interfcase [00:13] *interface [00:14] > A basic snap declaring a plug on cups-control [00:14] so its for printers ? [00:15] kennyloggins: it doesn't do anything, afaict [00:15] kennyloggins: it's a test snap [00:15] okay thanks [00:15] kennyloggins: to test an interface's functionality, in this case the cups-control interface (which is an interface for printing, yes) [00:22] nacc, thanks by the way - can now install 15 snaps ; one after another in one command, cheers pal. [00:22] kennyloggins: sure, that's not really snap specific :) [00:22] kennyloggins: i'm not sure if instll can take multiple snap names or not [00:22] seems like it probably could [00:28] elopio, another PR to snappy-m-o [00:29] nacc, `snap remove` certainly can [00:29] Haven't tried on install [00:29] kyrofa: yeah, me neither :) [00:29] kyrofa: never had a reason, tbh [00:29] nacc, me neither [00:46] nacc: that kinda worked ( http://paste.ubuntu.com/25971109/ ) Althou, I think I may have boken pastebin (on the right) :( [00:50] kennyloggins: not sure what you mean by 'right'? it's just a long linne [01:45] snappy-m-o, github subscribe 1719 [01:45] elopio: I'll send you a message if a test fails in the pull request #1719 (many: account for python shebang args in rewrite). [01:45] PR #1719: firstboot: add firstboot assertions importing [01:47] snappy-m-o, github subscribe 1719 [01:47] snappy-m-o, github subscribe 1719 [01:47] elopio: I'll send you updates as tests complete in pull request snapcraft#1719 (many: account for python shebang args in rewrite). [01:47] PR snapcraft#1719: many: account for python shebang args in rewrite [01:50] snappy-m-o github subscribe 1719 [01:50] sergiusens: I'll send you updates as tests complete in pull request snapcraft#1719 (many: account for python shebang args in rewrite). [01:50] PR snapcraft#1719: many: account for python shebang args in rewrite [02:01] PR snapcraft#1719 closed: many: account for python shebang args in rewrite [02:08] sergiusens: hmm, so just noticed something funny... "version: 2.20" results in a snap of version "2.2" rather than "2.20" [02:08] sergiusens: updating now to be 'version: "2.20"' which hopefully will fix that issue :) [02:10] stgraber oh, yaml; pyyaml parses that as a number; we should probably just update our jsonschema (commented) and enforce the type [02:11] kyrofa elopio take a look at snapcraft#1650 again please and I'll merge and tag after the travis tests are done [02:11] PR snapcraft#1650: Release changelog for 2.35 [02:37] sergiusens, bug #1732076 will still bite us [02:37] Bug #1732076: Plainbox snapd test failure [02:55] kyrofa I'll skip the install part in packaging [02:58] kyrofa fwiw, i386 runs on lxd [03:04] kyrofa actually, I won't skip it, just document it as part of the SRU [03:04] at this point I am more interested in releasing a snap [03:22] PR snapcraft#1740 opened: tests: add the home plug to the plainbox snap [03:22] snappy-m-o autopkgtest 1740 zesty:amd64 [03:22] elopio: I've just triggered your test. [03:23] snappy-m-o github subscribe 1740 [03:23] elopio: I'll send you updates as tests complete in pull request snapcraft#1740 (tests: add the home plug to the plainbox snap). [03:23] PR snapcraft#1740: tests: add the home plug to the plainbox snap [03:29] snappy-m-o autopkgtest 1740 artful:amd64 [03:29] elopio: I've just triggered your test. [05:57] morning everyone [05:57] hey [05:57] how are things? [05:57] zyga: hey [05:58] things are good, the conference was very nice [05:58] did you watch the video streams? [05:59] no, but I'd like to later [05:59] fighting release stuff [05:59] https://forum.snapcraft.io/t/2-29-release-cycle-started/2562/7 [05:59] uhh [05:59] what else have i missed? [06:02] mborzecki: not much I'd say [06:02] mborzecki: we could use some help debugging lxd issues today [06:02] mborzecki: I know about one issue that I'll try to finally address but it seems we have one more [06:02] https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850 [06:03] looking [06:04] I'm slowly waking up, I was working past midnight [06:04] after kids are in school I'll probably take a nap [06:05] * zyga is grumpy because everything fails and needs to be restarted [06:06] we could use some time on stabilizing those tests [06:06] travis again? [06:06] mborzecki: some of our spread tests are flaky [06:07] mborzecki: https://github.com/snapcore/snapd/pulls/ all they yetllow ones failed on some random thing [06:11] i'll quickly look through those and see if there's anyting with the tests or just the CI was flaky [06:13] zyga: will artful cloud image be good enough for reproducing lxc problem that kyrofa reported? [06:14] mborzecki: I think so [06:14] ok [06:14] mborzecki: not sure if he used 16.04 or 17.10 [06:41] mvo: good morning [06:41] mvo: some ungood news: https://github.com/snapcore/snapd/pull/4228 [06:41] PR #4228: interfaces,tests: skip unknown plug/slot interfaces (2.29) [06:43] mvo: though please look at the diff, we need to see if this actually makes sense [06:43] (I made it after midnight so not super sure) [06:43] I was under the impression that the new load-time validation would handle this [06:43] this is a regression caused by that patch [06:43] it seems we validate a snap and then say "yeah it's broken but I'll load it anywy" [06:44] and this is probably a wider hole to fill [06:45] mvo: other than that we also have the LXD regression, mborzecki and I will look at that (though I'm so sleepy I plan to take a nap for an hour as soon as kids leave) [06:45] zyga: god morning [06:45] mvo: hey [06:46] zyga: thanks for the update [06:46] and good morning mborzecki [06:46] zyga: do we know anything more about the lxd issue? does it affect every snap ? [06:46] zyga: I also wonder why our lxd-test did not catch it :/ [06:47] mvo: I have some ideas [06:47] mvo: the namespace didn't exist so snap-update-ns just bailed out [06:47] mvo: and there were no content changes to apply [06:47] mvo: this really requires the content interface test [06:48] zyga: and plainbox is using that iface? [06:48] mvo: I'm very convinced that we need to try to run the full test suite on lxd and see what is broken [06:48] mvo: I don't know actually, [06:48] mvo: it's possible [06:48] kissiel: ^ [06:49] kissiel: is the checkbox/plainbox snap using content interface? [06:49] mvo: though AFAIK this was a test in snapcraft so perhaps an artificial one [06:49] and obviousl I could be wrong and there's something lurking deeper about why this failed [06:50] zyga: thanks, that is already quite helpful! [06:53] zyga: hm, kyrofa reproduced it for hello-world in lxc so I doubt its the content iface [06:53] zyga: it works via sudo [06:53] zyga: which is also strange but it explains why our test did not catch it, it means a regression test should be simple at least [06:54] mvo: sudo will fix it because the denial was on cap_read_search [06:54] mvo: we are apparently trying to traverse a directory that is not readable to us [06:54] mvo: and then fail on the missing capability [06:54] mvo: sudo will just give us that [06:54] mvo: (not the capability but the read permission) [06:55] mvo: the freezer cgroup setup insie containers is something worth looking at [06:57] zyga: right, I'm trying to modify the lxd test so that we have a reproducer/regression test [07:00] I feel like it's time to crash now, I'll be back closer to 10AM [07:00] zyga: sleep well [07:11] PR snapd#4230 opened: tests: add test to run snap inside lxd as a user [07:46] mvo: can i force remove core snap? [07:59] mborzecki: unfortunately not, you can "dpkg --purge snapd" (or fedora has a snap-mgr.sh script that does the same) to remove all snaps [08:01] zyga: just fyi, adding "capability dac_read_search" is not sufficient to fix the lxd issue [08:01] hmm cgroup freezer directories are left behind once a snap runs (is that ok?), anyways, when a snap is run with sudo, it will be possible to create a directory under /sys/fs/cgroup/freezer [08:01] mborzecki: yeah, see 4230, we have a lxd test but unfortunately it runs as root so it did not catch the bug [08:13] omg, broke lxd [08:14] i restarted an ephemeral container, now i can't remove it nor stop if [08:14] exec doesn't work either [08:24] PR snapd#4231 opened: interfaces: add "refresh-schedule" attribute to snapd-control [08:50] re [08:52] mvo: any news? [08:56] zyga: snap-confine is setuid root right? [08:56] zyga: not much, we have a reproducer [08:56] zyga: in spread [08:57] mborzecki: yes [08:57] mvo: aha, that's good [08:57] https://paste.ubuntu.com/25973100/ [08:57] i build this, make it chown root:root, u+s, and cannot create a frezer group [08:58] zyga: and the apparmor denial is not it, I added it for testing to snap-confine.appamor.in and it still fails [08:59] zyga: with permission denied but no apparmor denial anymore [09:00] mvo: I'm running your test locally now [09:00] zyga: cool [09:11] PR snapd#4232 opened: store: add support for flags in ListRefresh() [09:12] zyga: silly question, could we revert the freezer group in 2.29? or would that cause havoc? [09:13] mvo: I think a bit havoc, I'd have to look [09:14] zyga: hm, then lets see if we can do a proper fix === JoshStrobl|Away is now known as JoshStrobl [09:18] mvo: hmm, the container is weird [09:18] I cannot switch to "ubuntu" user [09:20] * kalikiana coffee [09:20] mvo: I know what the problem is, I think [09:20] stgraber: around? [09:23] mvo: http://pastebin.ubuntu.com/25973198/ [09:24] mvo: so two ideas for quick "solution": [09:24] mvo: 1) make that step optional and let it fail, this means mount changes are not atomic in lxd [09:24] mvo: 2) talk to stgraber and figure out why lxd sets up containers this way and what we can do about it [09:26] mvo, mborzecki: opinions? [09:26] hmm that's why g+s works i guess [09:27] mborzecki: correct [09:29] mvo: it's actually a deeper problem: [09:29] root@my-ubuntu:~# ls -ld /sys/fs/cgroup/devices/ [09:29] drwxrwxr-x 5 nobody root 0 Nov 16 09:13 /sys/fs/cgroup/devices/ [09:29] mvo: unless we somehow disabled all udev tagging inside containers [09:30] mvo: it will break on when creating the device cgroup [09:30] s/on// [09:31] that's perhaps silly, but could we g+s snap-confine too? we're dropping both anyway right after setting up [09:32] mborzecki: that's another option, indeed [09:32] though I'd like to understand the motivation behind lxd choices [09:33] moin moin [09:33] Chipaca: hello [09:33] Chipaca: hey [09:33] Chipaca: welcome to the fire dept [09:33] Chipaca: pick your hose and let's put out the fires ;) [09:34] oh dear [09:34] zyga: what's on fire? [09:34] Chipaca: lxd [09:34] https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/12 [09:36] Chipaca: also snapd crashes: [09:36] https://bugs.launchpad.net/snappy/+bug/1732555 [09:36] Bug #1732555: Installing bad snap has snapd crashing [09:37] Chipaca: that one needs some love from pstolowski and perhaps you, something went south very much whe we switched to "validate on load" [09:37] zyga: hm, reading backlog. sorry, my laptop came back from repair just now (doorbell and all that) [09:37] Chipaca: I'm a bit sleepy still [09:37] mvo: great, did they hide that cable? [09:37] zyga: both of those claim to have a fix in a pr; is the fire putting out effort needed from me to review those prs? [09:38] mvo: btw I opened mine and I think I know why your cable was sticking out, there's a compartment for that cable where it's supposed to be held and be attached, if that part is loose it can easily slide through the hinge [09:38] zyga: yeah, its not longer visible, I wonder where they put it, I'm inclined to open the machine to see what happend to it. but opening the modern ones is a pita (IMO) so I probably won't [09:38] Chipaca: lxd is not fixed yet [09:38] zyga: aha, nice [09:38] Chipaca: and the snapd crash is just fixing the immediate problem, the deeper problem is not addresed [09:38] Chipaca: it seems the validate-on-load concept is validate-and-log-but-continue-anyway [09:39] zyga: I had it open before and tried to figure out where it belonged but couldn't find an obvious place and was too impatient then [09:39] mvo: I bought a x240 for a family member and I opened it to clean it and replace the heatsink thermal glue [09:39] mvo: (interestingly no internal battery there) [09:40] anyway [09:42] zyga, i'll look into this, thanks for the intermediate fix [09:43] pstolowski: thank you [09:54] PR snapd#4229 closed: interfaces,tests: skip unknown plug/slot interfaces [10:03] * zyga is doing code reviews [10:04] mvo: offtopic, do you remember that zesty issue with the repair systemd unit? [10:04] mvo: is that something that needs love? [10:04] pstolowski: FYI: https://github.com/snapcore/snapd/pull/4228 [10:04] PR #4228: interfaces,tests: skip unknown plug/slot interfaces (2.29) [10:05] pstolowski: 2.29 backport of that PR [10:05] zyga: I remember it, I thought it was conditionally dislabed and that would not put things into degraded state [10:06] PR snapd#4228 closed: interfaces,tests: skip unknown plug/slot interfaces (2.29) [10:06] zyga: iirc I checked on a fresh VM [10:06] mvo: aha, thank you [10:06] mvo: I requested your review on https://github.com/snapcore/snapd/pull/4227 as you looked into framebuffers on pi recently [10:06] PR #4227: tests: add test for frame buffer interface [10:12] zyga: sure, I have a look [10:15] Chipaca: https://github.com/snapcore/snapd/pull/4225 [10:15] PR #4225: cmd/snap-update-ns: tweak changePerform [10:21] zyga: +1 [10:25] zyga, addressed all your comments on https://github.com/snapcore/snapd/pull/4219 [10:25] PR #4219: snap/validate: extend socket validation tests [10:27] ackk: thank you, I'll look now [10:28] PR snapd#4225 closed: cmd/snap-update-ns: tweak changePerform [10:30] PR snapd#4185 closed: interfaces/builtin/account_control: use gid owning /etc/shadow to setup seccomp rules [10:40] zyga, i think i've a proper fix for the bad plugs/slots. interestingy it uncovered an small issue with api tests after all these change [10:40] s [10:41] pstolowski: interesting [10:42] pstolowski: I'll gladly review the PR [10:58] a second review for 4232 and 4231 would be great [10:58] mvo: I could use a few reviews [10:59] i can take a look [10:59] mvo: this one is interesting: https://github.com/snapcore/snapd/pull/4224 [10:59] PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes [10:59] mvo: the code change is tiny in one function, the rest are just tests [11:00] zyga, ok, looking. was about to jump to reviews anyway while me laptop restores its backup [11:06] PR snapcraft#1740 closed: tests: add the home plug to the plainbox snap [11:10] PR snapd#4233 opened: interfaces: remove invalid plugs/slots from SnapInfo on sanitization [11:10] zyga, ^ [11:14] pstolowski: looking [11:20] ok, conference report sent, back to snapd now [11:20] pstolowski: reviewed [11:20] zyga: so what do we do with lxd? [11:21] I'd like to discuss this with stgraber [11:21] setuid is problematic in itself [11:21] zyga, thanks! [11:30] * Chipaca ~> haircut, and lunch [11:42] popey: hey, what GUI snaps would you recommend to try out? [11:42] What's the goal? [11:47] * Chipaca aborts haircut plans [11:51] TestExecInCoreSnapUnsetsDidReexec fails on me with arch [11:51] mborzecki: maybe it assumes ubuntu and lacks mocking? [11:51] mborzecki: thank you for running that on arch [11:51] let me try on solus [11:51] in ExecInCoreSnap(), should SNAP_DID_REEXEC be unset in all early exit paths? [11:52] mborzecki: I don't know, sorry [11:52] ikey: any chance for F57 soon? ^_^ [11:53] popey: evaluating X11 over SSH [11:53] its in unstable zyga-solus [11:54] we sync on fridays [11:54] ikey: thank you! :) I cannot wait to see that [11:54] its pretty banging [11:54] mvo: you fixed the bug, so I assume ou know something about SNAP_DID_REEEXEC ;) [11:54] ikey: so I heard [11:54] https://plus.google.com/+Solus-Project/posts/LGDbWGGnGs2 [11:54] mborzecki: FYI, that test passes on solus [11:55] unfortunately we couldn't do a simple cherry-pick for firefox to get it in early [11:55] depends on new stuff like dbus + xcb + x11 + co [11:55] big chain [11:55] and right now im rebootstrapping the solus toolchain [11:55] zyga-solus: thx for checking [11:55] Saviq: pycharm-community, mailspring, wavebox, ohmygiraffe, chromium.. good enough to get on with? [11:59] * zyga-solus sees one unit test failing on solus, let's fix that [11:59] but while tests run, it's tea time! [12:15] popey: sure, thanks [12:27] pstolowski: +1 [12:27] pstolowski: can you please do a 2.29 backport as well, feel free to rebase+squash this PR for simplicity [12:27] mvo: can you do a 2nd review of 4233 with the extra changes, for sanity please? [12:28] jdstrand: good morning :) [12:31] zyga-solus: SnapMountDir must be /snap in solus apparently [12:31] mborzecki: yes, that's right [12:31] the test should fail on fedora too then [12:31] mborzecki: perhaps neal patched it, I haven't used fedora actively lately [12:33] SnapMountDir never wasn't /snap in our snapd [12:33] * ikey is confused [12:33] * ikey also can't english today [12:33] ikey: it's all good [12:33] ikey: just chasing an unit test without mocking that mborzecki found while running arch [12:33] ah [12:37] ikey: English you good done! [12:37] thanks much they have do [12:38] * diddledan looks to see what podcasts he has waiting to be heard [12:38] ah there we go. a nice shiny new bad voltage [12:41] * ikey occupies himself with watching llvm build [12:41] ooh, that sounds almost like Gentoo :-p [12:42] nah gentoo is for newbs [12:42] :P [12:42] someone else has already done the packaging for you at that point :p [12:42] * ikey wouldn't object to someone else doing this for him though. [12:46] 12:46:18 up 13:26, 1 user, load average: 10.95, 9.48, 6.76 [12:46] ow. xD [12:49] ikey: are you on gentoo now? :D [12:50] nah on solus [12:50] the laptop is taking offence to being used as a build machine [12:51] ikey: maybe get one of those $9 chip clusters ;) [12:51] heh [12:51] fwiw ive already built gcc on this thing today as well [12:52] running out of compilers to compile.. [12:52] ikey: think about the gcc CI machine [12:52] poor thing :) [12:52] lo, ya [12:52] *lol [12:53] then again they use SVN [12:53] so they kinda bring pain on themselves [12:53] again?!? [12:53] next up: more shards of glass under our fingertips [12:53] yeah i was checking out https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248032 earlier [12:54] zyga-solus: good morning :) [12:54] zyga-solus: or rather, good afternoon :) [12:54] jdstrand: we had some drama in the morning, the interface part seems to be addressed now but we are still in the red in lxd [12:54] yeah, saw that [12:55] is https://forum.snapcraft.io/t/snapd-fails-to-update-lxd/2858 the same lxd issue? [12:55] * ikey adds appropriately topical and dramatic musical backdrop to zyga-solus's words [12:55] emerge glibc binutils gcc && emerge glibc binutils gcc <-- back in the day that was the required encantation to ensure Gentoo consistency (IIRC) [12:55] https://www.youtube.com/watch?v=Wmc8bQoL-J0 [12:55] incantation* [12:55] diddledan, yeah ive done binutils already lol [12:55] \o/ [12:55] 2.29.1 [12:55] ikey: just say everything I write with hollywood trailer voice [12:55]