[00:19] series_16 = lp.snappy_serieses.getByName(name='16') [00:19] series_16.preferred_distro_series is now None [00:19] what changed there? [00:20] i guess i should forum this, noone is going to be listening now :) === JoshStrobl is now known as JoshStrobl|zzz [07:21] * davidcalle back from hol, morning all o/ [07:23] davidcalle: elo, should've disabled your IRC bouncer for when you were not around ;) [07:23] Saviq: hehe :) [07:26] davidcalle: when you have time, please let us know if you need anything more from us on https://github.com/canonical-websites/developer.ubuntu.com/pull/305 [07:28] Saviq: I'm going to do a round of testing on this before merging, but hopefully today [07:52] zyga-suse: o/ [07:52] zyga-suse: did you see https://forum.snapcraft.io/t/updating-snapd-in-debian/1645 [07:52] hey hey [07:52] no, just waking up and checking things [07:52] agreed on all the exclusions [07:52] looking at pastebin [07:54] replied [07:54] thanks [07:55] * zyga-suse just edited the list to remove the obvious paste mistakes [07:56] i think the fedora packaging ships some of those files in the snap-confine package, unless i'm missing something [07:56] that's legacy [07:56] they should be merged into one package [08:05] zyga-suse: are we reasonably sure 2.27 fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872071 ? [08:05] zyga-suse: that's the 'hang on configuring core snap' thing [08:05] mwhudson: no, it doesn not [08:05] zyga-suse: boo [08:05] mwhudson: we have not identified the reason yet, I believe [08:06] but chose not to block on it because it is an existing bug, not a regression [08:06] zyga-suse: it looked like mvo had a favoured theory, did that not turn out to be it? [08:07] mwhudson: not sure I know the theory [08:07] zyga-suse: https://forum.snapcraft.io/t/debian-core-configure-hang-on-first-snap-install/1586/6?u=mwhudson [08:07] mwhudson: i think he posted about it [08:07] ah [08:07] * zyga-ubuntu reads [08:07] i guess i can add that to the changelog after i actually test the debs :) [08:07] ah [08:08] I hope it is asimple as that [08:08] oh haha this debian vm called 'debian-stretch-amd64' is actually sid [08:08] yes [08:08] the qemu one is realyl stretch [08:08] that saves a step [08:08] the linode one is sid [08:08] zyga-suse: no this is a local one [08:08] ah, I see :) [08:09] zyga-suse: i need to test https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851473 again too [08:09] I think it will still be the same [08:09] I don't think we took any action on it [08:09] probably [08:11] well it does this with 2.26.14 from the core snap: [08:11] debian@debian:~$ hello.universe [08:11] snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks [08:14] that's a new bug, where snapd sees unpatched apparmor and choses not to enable the apparmor backend [08:15] and thus snap-confine does not get its own profile [08:15] but then snap-confine sees the kernel has apparmor enabled [08:15] and it is setuid root [08:15] but the profile is nowhere to be found, so it bails out [08:21] US seems to be a troubled land recently :/ === ShalokShalom_ is now known as ShalokShalom [08:53] zyga-suse: the hang on configure does indeed seem to be fixed \o/ [08:54] root@debian:~# hello.universe [08:54] /usr/lib/snapd/snap-confine: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory [08:54] wtf!! [08:54] that is great news!! [08:54] the libcap one is interesting [08:54] is snap-confine linking libcap dynamically? [08:55] whut [08:55] mwhudson: note that one way to test the hang reliably is to snap install hello while *not* having core [08:55] oh [08:55] no wait [08:55] zyga-suse: http://paste.ubuntu.com/25311128/ [08:56] zyga-suse: could this be caused by the core that i just downloaded being older than the snapd i have installed? [08:56] no [08:57] open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) [08:57] i guess this is apparmor being potty again [08:57] yea [08:57] Aug 14 20:56:57 debian kernel: [ 3608.590506] audit: type=1400 audit(1502701017.760:10): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/lib/x86_64-linux-gnu/libcap.so.2.25" pid=2365 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [08:57] lets turn apparmor off for now... [08:58] mwhudson: ah, I think this *is* apparmor [08:58] but wait, didn't you say you disabled apparmor? [08:58] ah, no you enabled it sorry [08:58] * zyga-suse is really sleepy still [08:59] so, with older core you will not re-exec [08:59] i've disabled it *now* and it works [08:59] and you will use snap-confine from debian [08:59] and you may see profile incompatibility [08:59] ah yeah, i think i knew that once [08:59] since snap-confine profile is written for more recent apparmor behavior === JoshStrobl|zzz is now known as JoshStrobl [09:02] zyga-suse: any ideas for things i should test on this vm? [09:04] mwhudson: did you try the "I have no core and I snap install hello" use-case? [09:05] zyga-suse: yes [09:05] that was the first thing i tried :) [09:06] hmm, not sure then, just a random collection of snaps perhaps: ... one sec [09:06] https://github.com/snapcore/snapd/pull/3692 [09:09] zyga-suse: is there some easy way to run this on the vm? [09:10] not sure, I think if you can just hand install the top three it would be a good test [09:10] heh heh good to see my only important snap on there :) [09:14] which one is that? [09:14] :) [09:14] mvo: welcome back [09:14] hey zyga-ubuntu [09:16] * zyga-ubuntu needs 2nd coffee [09:16] head.ache() [09:17] zyga-ubuntu: I get a cup of tea now too - I looked briefly at backporting asic control to 2.27.1 but there are quite a few changes to common interfaces that would also need backporting, it seemed overly broad for the scope of a .1 [09:18] mvo: if you want I can make a simpler backport, with a custom interface type [09:18] zyga-ubuntu: lets [09:18] zyga-ubuntu: sorry, let see if we need a .2 and only do it if we do [09:18] mvo: ok, when will we know? [09:19] zyga-suse: go [09:19] zyga-ubuntu: hopefully soon, I will ask cachio to do the 2.27.1 validation today [09:19] ok [09:20] I'll do some more reviews for garry and work on 2.27.1 packaging [09:20] +1 [09:22] heh i appear to have rocketchat installed on debian sid [09:22] the funny thing is it would also install on debian *stable* === ikey|zzz is now known as ikey [09:42] hmm, mup is not reporting PRs [09:49] ok so github is seriously tripping right now [09:49] oh, while you mention github ... [09:50] zyga-ubuntu, https://ibin.co/3Wq1GWrSnkGi.png [09:50] hey [09:50] hmmm [09:50] I merged master into your branch [09:50] that should fix the fedora failures [09:50] yeah but look where you pushed [09:50] that shouldnt be possible [09:50] thats the forked repo [09:50] yes [09:51] it is, that's a github feature [09:51] then github is on crack [09:51] because repo permissions [09:51] lol [09:51] I pushed that *into* your branch because when there's an active PR contributors can do that [09:51] it's an opt-out feature for about 3 months [09:51] * ikey calls crack [09:51] it does makes sense :) [09:51] meth then [09:51] :p [09:51] it's weird but when you think about it [09:51] people close the PR and reopen with more things [09:52] but that's just a time waste [09:52] rebase/force push [09:52] why? [09:52] i mean in response to "people close the PR" [09:52] ah [09:52] PR snapd#3724 opened: wrappers: symlink completion snippets when symlinking binaries [09:52] no, I mean people close the PR because they cannot push to it [09:53] oh others [09:53] contributor comes along and makes a PR but then looses interest [09:53] ah [09:53] maintainers are willing to fix so they close and reopen with their fixes [09:53] this just cuts one step [09:53] not saying that it happens all the time [09:53] but even inside the core team we do that all the time [09:53] esp timezones [09:53] it helps [09:54] btw, I'm curious -- what was that UI that showed me doing this? [09:54] is that something I can use? [09:55] PR snapd#3702 closed: interfaces: add missing test for camera interface [09:56] zyga-suse, that was just on my github front page [09:56] aha [09:56] interesting theme :) [09:56] * mwhudson uploads snapd_2.27.1-1_source.changes [09:56] https://ibin.co/3Wq3LA9vK99y.png [09:59] ikey: nice, is that a custom theme applied somehow or something I can toggle just on github? [09:59] i use userstyles extension in chrome [09:59] ah, right [09:59] or stylish [09:59] or h/e you call it .. lol [10:00] "GitHub Dark" [10:00] wth gdk-pixbuf [10:00] what kind of a mad man statically links libtiff [10:00] * zyga-suse ventures into /usr/lib/rpm [10:01] i feel i should say "It's dangerous to go alone!" and offer you a sword. [10:02] I think I'm already out, I was looking at how /usr/lib64/go vs /usr/lib/go can be abstracted [10:03] ah [10:08] mvo: hi, snapd#3710 is the thing that needs a review for 2.28 btw [10:08] PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand [10:09] pedronis: thanks, I have a look [10:09] zyga-ubuntu: any luck with a branch to disable sync in tests? [10:10] Chipaca: nope, I left it on a hanger last week [10:10] Chipaca: let me refresh it [10:18] zyga-ubuntu: no worries, just curious [10:22] huh, the autopkgtests run without a core snap [10:27] jospoortvliet, hey ho ... why does this section if the nextcloud install doc tell you to install debs alongside the snap ? https://docs.nextcloud.com/server/12/admin_manual/installation/source_installation.html#example-installation-on-ubuntu-16-04-lts-server [10:28] ogra: it is meant to be a choice [10:28] either install the snap [10:28] or go the 2nd way: install things manually [10:28] it isn't very clear [10:28] not at all :D [10:28] yeah :) [10:29] ogra: I would suggest to have a header "option 1" and "option 2" [10:29] if you want, you can propose the change: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/source_installation.rst [10:29] edit the source of the documentation there [10:30] jospoortvliet, FYI https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291222.html [10:31] ogra: if you happen to be on that list, replying to explain the problem would be welcome, I'm not a member... [10:32] and mention me ( @jospoortvliet ) if you make a pr for the documentation. Just use the web UI of github... or let me know if you can't figure out how to, I'd be happy to help! [10:34] * zyga-suse focuses on suse package again [10:35] +1 for that zyga-suse - I have moved to using the tarball but as openSUSE user I'd consider moving back to packages. Though then I can't help test RC's etc so easily. choices, choices... ;-) [10:35] hmm? [10:35] I mean suse package of snapd [10:36] aaah zyga-suse that is also cool :D [10:36] zyga-suse: esp on small devices that you don't want to maintain I think the snap is super useful [10:36] so +1 on that, too :D [10:38] jospoortvliet, https://github.com/nextcloud/documentation/pull/554 [10:38] PR nextcloud/documentation#554: make clearer that it is either snap or deb in the example [10:57] * zyga-suse ponders [10:57] https://paste.gnome.org/pasc7ndpu [11:04] * zyga-ubuntu -> lunch [11:07] zyga-ubuntu, thanks for merging the spi stuff in the pi3 gadget (i thought you said you wanted manual tests in your last comment on the PR, this is why i had not merged it yet) [11:07] it looked ok [11:08] yeah, and it goes to edge first anyway :) [11:10] ok, time for me to take a break (run + lunch + etc [11:10] ) [11:30] * zyga-ubuntu resumes hacking [11:53] can someone please do a 2nd review for 3714 [11:57] PR snapd#3705 closed: interfaces: convert lxd_support to common iface [12:03] i updated my PR to remove the mkversion changes [12:04] (and rebased it on master to drop the 30 odd pull requests on top of it :P) [12:05] ikey: ok, [12:05] it seemed to be the main sticking point of the PR [12:05] and it means changing all of 2 lines in my package.yml [12:05] so its a silly thing to keep around [12:06] actually no it just means adding one line, easier again [12:06] Thank you! [12:06] I asked jdstrand to review that PR [12:06] s'all good dude [12:06] i like streamlined :p [12:12] ikey: notice that we tend to frown upon rebases once a PR has got comments [12:13] at least that's what I always heard from niemeyer [12:13] * ikey blinks [12:13] i didnt exactly have a choice :p [12:13] zyga-ubuntu pushed a merged master on top of it, and the only way to edit my own patch was to rebase it back on top of master [12:14] that's fine [12:14] i wasn't going to dig through 30 merged PRs for my patch and then reapply them lol [12:14] ikey: You can just merge master in those cases, I believe [12:14] it was already merged [12:14] thats the problem [12:14] i couldnt amend my commit [12:15] ikey: You can just continue changing the content of the PR further.. no need to amend [12:15] This way reviews continue to make sense on the timeline [12:15] which means you would need to cherry-pick my commits and would lose my gpg signature [12:15] Otherwise all previous references to commits are lost [12:15] idk maybe we just git differently [12:16] github shows when a comment is for an outdated diff [12:16] we have a slightly messy mainline [12:16] but we don't care it seems, so yes we make different git choices I think [12:16] well, i know for future [12:17] The mainline is pretty clean, mainly because we squash merges [12:17] which then loses gpg signatures, etc [12:17] often but not always [12:17] It does, yes [12:17] debian has been pushing for signed commits for some time [12:17] as well as signed tags [12:18] Thanks for the changes, and good morning btw :) [12:18] morning! [12:18] at times github is enough to make me miss gerrit [12:18] which is an awful thing to say [12:20] GitHub is pretty reasonable these days in terms of code reviews.. it used to be unacceptable for anything non trivial [12:20] yeah [12:21] at least its no longer trying to hide all the things [12:21] beh [12:21] signed commits and tags cause issues [12:21] update your git client? [12:21] dont use gitkraken? [12:21] etc. :p [12:21] if GitHub throws 500 errors, there's not a lot I can do [12:22] github makes no attempt to verify signatures [12:22] it's a known issue with how GitHub's gpgverify works [12:22] yes it does [12:22] only that the issue belongs to an account [12:22] it actually *does* attempt to verify them [12:22] because you have to upload your gpg key to github for it to do so [12:22] not to a keyserver [12:22] well, yeah, not to hkp [12:22] but it does actually attempt to verify them [12:22] right so its not doing **normal** verification is what im saying :p [12:23] mvo, have you attempted to get this fixed yet? https://github.com/golang/go/issues/20556 [12:29] woo, someone fixed mongodb ftbfs on s390x :D [12:29] that means I can finally build snapd on rawhide [12:29] someone *cares* :D [12:29] how is that related? [12:33] snapd -> go mongodb driver -> mongodb-libs -> mongodb [12:34] zyga-suse: it's really silly that snapd depends on mongodb transitively, but whatever [12:36] god, I hate arm: https://koji.fedoraproject.org/koji/taskinfo?taskID=21222949 [12:36] it takes FOREVER... [12:43] "god, I hate arm" - which one? :trollface: [12:43] * ikey legs it [12:43] Son_Goku: how is that possible? [12:43] ah [12:43] Son_Goku: mongodb driver is a part of golang? [12:43] no, it's the mgo driver the niemeyer wrote [12:47] "the niemeyer" ... there can be only one, my friend [12:47] :) [12:49] How would snapd depend on it transitively? It definitely doesn't in general [12:52] https://koji.fedoraproject.org/koji/rpminfo?rpmID=10629107 [12:52] if this is an error, then tell me, so I can poke someone to fix it [12:53] Son_Goku: thanks for the reminder, mwhudson offered to help me with pushing the patch from https://github.com/golang/go/issues/20556 to upstream, I had some problems with the account creation [12:53] niemeyer: o/ [12:53] niemeyer: we are using mgo.v2/bson seems to bring in stuff on distros [12:53] mvo, well, I noticed it when I audited the source tree to update dependencies [12:54] when I see weird forks and stuff like that, I want to be sure I can avoid them :) [12:55] Son_Goku: that's because you hate freedom [12:55] oh wait no that was us [12:55] :) [12:56] is spread on linode having a bad day? [12:57] pedronis: I see.. that doesn't make a lot of sense, in quite a few ways [12:58] First, it's a build dependency.. [12:58] Then, it's a driver.. building something with a driver shouldn't bring in a database [12:58] yeah, as a result, I can't build snapd [12:59] Son_Goku: How come? [12:59] pulling that godep causes it to try to install mongo, and mongo wasn't rebuilt for new boost successfully because borkiness in test suite on s390x [13:00] niemeyer: yea, but it's a problem in the mgo packages , not in snapd afaiu [13:00] I interrupt this fascinating documentary about how all packaging is broken all the time to bring you this bit of news: it's standup o'clock [13:00] Chipaca: :) [13:00] pedronis: yep [13:00] Son_Goku: That makes no sense on itself, even despite anything else, right? [13:01] unless you expect to run the mgo unit tests in your build, I think it doesn't make sense to be a hard dep [13:02] after all, the server could exist somewhere else, in theory [13:02] unless the driver requires the mongodb C libs to build correctly [13:10] mvo, did you see the discussion on https://forum.snapcraft.io/t/in-progress-snapd-2-27-1/572 ? [13:11] (i guess we should pull the xdg fix into 2.27.1) [13:15] morphis: hey [13:15] morphis: around? [13:15] zyga-ubuntu: hey! [13:16] zyga-ubuntu: what's up? [13:16] morphis: would you have a moment for a opensuse package review? [13:16] sure [13:16] excellent, I'll put the sync request up soon [13:31] Chipaca: that's for you: https://github.com/snapcore/snapd/pull/3725 [13:31] PR snapd#3725: osutil: honor SNAPD_UNSAFE_IO for testing [13:31] PR snapd#3725 opened: osutil: honor SNAPD_UNSAFE_IO for testing [13:33] zyga-suse: https://people.canonical.com/~john/howmanyvmsdoesittake [13:33] hehe [13:33] zyga-suse: (also it's curl-able) [13:34] Chipaca: oh, lovely, how did you do that? [13:34] zyga-suse: apache is magic [13:34] ah, via apache [13:34] :-) [13:35] I didn't know we can do that on p.c.c [13:36] mvo: ok, I'll do your backport now [13:45] * zyga-ubuntu actually goes to eat something [13:48] zyga-ubuntu: \o/ [13:48] damn, I really should go to work now [13:49] Son_Goku: thank you for the updates! [13:49] np [13:49] I suspect I'm going to have 2.27.2 soon, aren't I? [13:50] yed [13:50] yes* [13:50] I need to backport one thing [13:50] and we need two cherry picks from master [13:50] sorry about that :( [13:50] * Son_Goku shrugs [13:51] I'm only really annoyed when it's really close to making it into the repository [13:51] because each update resets the counter [13:52] we feel it the same way for ubuntu and elsewhere :/ [13:55] and because no one ever tests the Fedora snapd updates, it's aggravating [13:55] I will start doing that again, sorry for letting you down there :/ [13:55] because I have to wait the full five days, and then it has to be reset :/ [13:55] what is the average rate of tests for a package? [13:56] * Son_Goku shrugs [13:56] in bodhi I mean [13:56] the stats are in Bodhi itself [13:56] https://bodhi.fedoraproject.org/metrics [13:56] https://bodhi.fedoraproject.org/releases/F26 [14:16] mvo: Do we have a topic for the known issue with snapd reverts? [14:16] mvo: core revert leaving snapd unrestarted, that is [14:18] niemeyer: not yet, let me add it [14:18] mvo: Thanks! [14:30] mvo: https://github.com/snapcore/snapd/pull/3726 [14:30] PR snapd#3726: interfaces: backport broadcom-asic-control interface [14:30] morphis: ^^ [14:31] PR snapd#3726 opened: interfaces: backport broadcom-asic-control interface [14:31] niemeyer: https://forum.snapcraft.io/t/snapd-not-restarting-on-revert/ [14:33] PR snapd#3727 opened: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go [14:33] mvo_: anything else I can help with wrt 2.27? [14:34] PR snapd#3728 opened: tests: adding more debug information for the interfaces-cups-control test [14:35] PR snapd#3728 closed: tests: adding more debug information for the interfaces-cups-control test [14:35] * zyga-ubuntu reboots [14:36] PR snapd#3729 opened: store: do not resume a download when we already have the whole thing (2.27) [14:36] i think the arch nvidia code might be broken [14:37] https://ibin.co/3WrQ0U7eu5Ao.png [14:37] getting the undefined symbol issues .. which i shouldnt be getting [14:37] unless its mercilessly copying across host side GL libs regardless of whether or not its nvidia [14:37] zyga-suse: I think we are good otherwise [14:39] PR snapd#3730 opened: tests: adding more debug information for the interfaces-cups-control … [14:40] PR snapd#3731 opened: interfaces: allow /usr/bin/xdg-open in unity7 [14:40] PR snapd#3732 opened: interfaces: allow /usr/bin/xdg-open in unity7