=== Eickmeyer is now known as studiobot === studiobot is now known as Eickmeyer === Eickmeyer is now known as studiobot [06:12] morning [07:43] mvo: morning [07:44] mborzecki: hey, good morning [07:48] mborzecki: how are things? tests look pretty unhappy still :/ [07:48] mvo: restarted some jobs [07:48] mvo: i'd think about landing #6422 to see if it helps with random mount errors on core-18 [07:48] mborzecki: did you notice any patterns? [07:48] PR #6422: tests/prepare: prevent console-conf from running [07:49] mvo: hi, last night we had lots of runs >50mins [07:49] mborzecki: good idea [07:49] but unclear what changed [07:49] mborzecki: lets see if it helps [07:49] mvo: some kill timeouts, (one in snap run --strace test), some network issues (go get from github fails) [07:49] PR snapd#6422 closed: tests/prepare: prevent console-conf from running [07:49] pedronis: yeah, I noticed that too [07:49] pedronis: usual time is ~35min these days it seems [07:49] mvo: I re-run things a bit, but failed, then I gave up [07:50] mvo: I'm landing #6471 and will update #6473 [07:50] PR #6471: snap-confine: fix classic snaps for users with /var/lib/* homedirs <⚠ Critical> [07:50] PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> [07:51] mvo: jdstrand asked for tweaks to #6466 [07:51] PR #6466: cmd/snap-confine: handle death of helper process <⚠ Critical> [07:51] pedronis: certainly, looking [07:52] PR snapd#6471 closed: snap-confine: fix classic snaps for users with /var/lib/* homedirs <⚠ Critical> [07:55] mvo: I'm a bit confused by the test change in #6473 [07:55] PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> [07:56] I think we still want both tests [07:57] PR snapd#6474 opened: snap-confine: fix classic snaps for users with /var/lib/* homedirs (2.37) [08:00] pedronis: you mean we want both "special-home" and "special-home-run-classic-snaps" tests? [08:00] yes [08:01] pedronis: jenkins can no longer run confined snaps after the change [08:01] pedronis: and it never could before [08:01] pedronis: it was only ever able to run classic snaps [08:02] mvo: that is true, but I tought they would run partially at least? [08:02] they break already in snap-confine? [08:02] pedronis: let me double check [08:02] pedronis: I think so, let me quickly boot my test vm === pstolowski|afk is now known as pstolowski [08:02] mvo: the issue is that they will not have a home dir [08:02] good morning [08:03] but it might well be that snap-confine is unhappy [08:03] (it does some things related to home after the pivot) [08:04] pedronis: I will double check again, give me 2min [08:04] mvo: thx === phoenix_firebrd is now known as murthy [08:13] pedronis: https://github.com/snapcore/snapd/pull/6473#issuecomment-460548241 I will dig a bit into the snap-confine code to double check my empirical findings too, I have the vm running if you have any further questions [08:13] PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> [08:15] mvo: ok [08:15] thx [08:21] mvo: I updated 6473 [08:22] pstolowski: spent some time looking at your pr, feels tricky [08:25] pedronis: thanks, did I made a dirty merge? [08:25] mvo: ? [08:25] pedronis: I noticed you force pushed 6473, was there anything wrong in the original push? [08:26] mvo: no, but I squash merged the previous one [08:26] so I had to === murthy is now known as phoenix_firebrd_ [08:26] pedronis: aha, ok [08:26] mborzecki: yes i can see that. perhaps we should just reduce retry timeout, unless there is some other more obvious fix [08:26] mvo: so we get 1 commit each [08:26] pedronis: +1 [08:26] mborzecki: tricky in which sense [08:27] pedronis: I think I did the same earlier but its fine :) [08:27] pedronis: maybe fiddly, had to spent some time figuring out what's happening there [08:28] mborzecki: I think the tricky bit is that we need to trust what go says about timers [08:28] (which has already changed over time) [08:28] pedronis: that's another story [08:28] that indeed is a bit uncomfortable [08:29] pedronis: I added a comment to 6473 about the code and how things worked before and why strict snaps for non /home users never worked, hope this makes things clear. ideally zyga would double check 6473 but I'm pretty confident in the findings [08:30] mvo: I gave a +1 to #6470, it needs a 2nd review [08:30] mborzecki: 6470 needs a second review [08:30] PR #6470: packaging: disable systemd environment generator on 18.04 <⚠ Critical> [08:30] pedronis: thank you! [08:31] mborzecki: you looked at this before so hopefully easy :) === phoenix_firebrd_ is now known as murthy [08:33] mvo: your comment in 6473 about strict confinement is not ture, we never copied the host into var/lib [08:33] we copied core plus host lxd [08:33] pedronis: we create a writable mimic of the original host, let me search [08:34] mvo: no, it's a writable mimic of core plus host lxd [08:34] (it's all confusing) [08:37] pedronis: yeah, re-reading it now [08:39] PR snapd#6470 closed: packaging: disable systemd environment generator on 18.04 <⚠ Critical> [08:39] mvo: squash merged ^ [08:39] let me prep a backport [08:44] done [08:45] PR snapd#6475 opened: packaging: disable systemd environment generator on 18.04 (2.37) [08:56] pedronis: thanks you [08:56] pedronis: if 6470 can be cherry picked I can just do that, we only need the backport when there are conflicts [08:56] pedronis: you are right of course, its just the core /var/lib that goes into the namespace [08:57] mvo: ah [08:57] pedronis: which means my testing with jenkins was not ideal as this is now availalbe in the core snap. i retested using postgres and got also a failure but a different one [08:57] mvo: ah, we should remove jenkins from the cores [08:57] pedronis: +1 [08:57] pedronis: if this branch lands, then yes [08:58] pedronis: https://github.com/snapcore/snapd/pull/6473#issuecomment-460558531 hopefully solves the mystery [08:58] PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> [08:58] mvo: btw I'm *not* working on 6466 because I will need to review it [08:59] pedronis: I can work on that now [08:59] mvo: thx [08:59] mvo: one of the backports got red [08:59] 6474 :/ [09:02] mvo: +1 to #6473 [09:02] PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> [09:02] pedronis: the red is 'protocol' error in mount again :( [09:02] mvo: hey, quick question about apt wrt to nested vm. i'm having an issue where apt install -y ... as part of the test triggers an interactive debconf prompt and hangs there till kill timeout - https://pastebin.ubuntu.com/p/R35sJvhfWH/ ; i'd have though -y takes care of that, i cannot find anything obvious in apt man [09:03] pedronis: thanks for the review [09:03] pstolowski: try DEBIAN_FRONTEND=noninteractive in your environment [09:04] mvo: ack, thanks! [09:16] mvo: we are back with 50+ mins runs [09:16] not sure what changed [09:17] pedronis: its strange, the results are uneven it seems, some finish in 35min but others overrun quite a bit [09:17] I'd put 2¢ on it being images now being old and having to update a lot of stuff [09:18] Chipaca: mmh, how do we get the 35 mins run tough? [09:18] shouldn't image updating be a constant [09:18] or are we saying network perf is very uneven? [09:18] pedronis: I am [09:18] I'm not sure if it accounts for the whole of it, but it's an important chunk when doing qemu runs [09:19] (and my network at home is pretty good at not being variable) [09:19] pedronis: yeah, that seems plausible - I think Chipaca is on something, iirc cachio was doing the updates only semi-automatic [09:20] "Chipaca is on something" only coffee i swear [09:20] and maybe too little sleep [09:20] mvo: yes, we need to find a way to have both automatic and safe [09:20] I think the "safe" part was why they aren't automatic [09:20] * mvo nods [09:21] Chipaca: you are working on the epochs PR, right? [09:21] pedronis: yes [09:21] ok [09:21] pedronis: the "have one refresh fail and two others succeed" test is failing all of them [09:21] pedronis: so i'm having "fun" [09:22] we all having "fun" I fear, different sort of "fun" [09:23] indeed, so much fun [09:23] signal handling in unix ftw [09:25] mvo: you sound like the lispers from the unix hater's handbook :-) [09:27] Chipaca: thats how I feel! [09:28] mvo: old and crusty and smelling slightly of pizza? [09:28] that's what my copy of it was at least [09:28] :-) [09:28] Chipaca: hahahaa [09:29] Chipaca: yeah, except the smell is more of tea but otherwise quite close [09:29] * Chipaca hugs mvo [09:29] mvo: you'll get through it, i'm sure [09:29] * mvo hugs Chipaca [09:29] Chipaca: yeah, its just … oh well [09:30] yeah [09:30] * mvo drinks more to get through it [09:30] * mvo really likes his tea today [09:33] signal handling and threads are no fun [09:33] and go means mandatory threads [10:17] mvo: Is snapd installing the apt integration on all releases? I think the apt side is only available in bionic+ now, but it will probably migrate back to older releases shortly; though, I don't think it will work correctly for snapd purposes on trusty [10:18] (IIRC, on the the trusty backport, it can't figure out which packages were not found, but I'll have to do some digging) [10:22] juliank: we install the hook everywhere, I can disable it on trusty if that is a problem [10:23] I think it will just do nothing, but I'll test it before doing any SRUing [10:31] juliank: thank you [10:35] Wondering if someone could help me get snaps working on Gentoo. I've had it going before, but now setting it up on a new machine and have some kind of issues with apparmor profiles [10:36] I'm getting the following message: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks [10:38] i see /snap/core/6350/user/lib/snapd/snap-confine and **snap-confine//mount-namespace-capture-helper listed ad being in enforce mode when running "aa-status" [10:38] snap version is 2.36.1, series 16, kernel 4.20.6 [10:40] only errors I see in journalctl for snapd is: Apparmor is enabled but some features are missing, dbus, netwok [10:41] and some stuff about the executable not containing a buildid [10:45] zigford: I'd suggest using the forum for this [10:45] zigford: for one, because the people that can help you might be busy right this instant [10:46] zigford: for two, because then people can find it written down the next time :-) [10:46] pedronis: wrt to ensureUniqueName/proposedName bit, are you ok if in the existing PR i only extract this code into a helper as you suggested, and we will iterate on the details in a followup? [10:47] I'm okay with waiting, I can leave IRC open for a few days. But i agree with you on the second point. [10:47] pstolowski: yes, assuming we can iterate relatively quickly [10:47] I will update my 'Snaps on Gentoo' blog post when I find the answer for others too. But the forums are probs way more discoverable than my little blog [10:48] zigford: forum.snapcraft.io is the forum i meant fwiw [10:48] gotcha [10:52] pedronis: yes, should be quick [10:52] ty [10:53] pstolowski: https://forum.snapcraft.io/t/log-snapd-and-btrfs-message/9809 [10:53] pstolowski: is that something you know about? udevmon.go thing [10:54] Chipaca: yes. i was wondering if it's going to create a lot of noise. not a bug, just noise for virtual devices that get removed and that we didn't know about [10:55] maybe it should be DEBUG, although initially i wanted to be sure we are not missing something important [10:56] mvo: not urgent, when will edge contain prepare-image --classic that landed yesterday? [10:57] Chipaca: i'll reply [10:58] mvo: #6474 is green [10:58] PR #6474: snap-confine: fix classic snaps for users with /var/lib/* homedirs (2.37) [11:05] zyga pedronis Please, can you remind me what the status of layouts is in snapd? [11:05] pedronis: hm, depending on timing either today or tomorrow its trivial for me to kick it [11:10] Wimpress: they are not behind a flag anymore, they might not be supported directly (without passthrough) in snapcraft for something without tough, that's a snapcraft question, it's one of our most complex features so I do expect some bugs still [11:10] *without base: [11:10] So layouts require `base:`? [11:11] Wimpress: as I said, may be, you can passthrough them tough [11:11] if you don't have one [11:11] Wimpress: a question for snapcraft [11:13] https://forum.snapcraft.io/t/troubleshooting-snap-confine-and-apparmor-on-gentoo/9812 [11:13] zigford: <3 [11:14] zigford: where does that funky version string come from? [11:14] degville: See my question above regarding layouts. Is there documentation for how to use layouts? [11:15] mvo: no, not urgent just wondering [11:15] zigford: asked in the forum to keep the conversation in one place :-D [11:16] Wimpress: https://docs.snapcraft.io/snap-layouts/7207 [11:16] degville: Excellent! Thank you :-) [11:17] troubles with the store? [11:18] https://status.snapcraft.io doesn't seem to work here [11:20] degville: fyi, I just ninjaed the 'snap version' out of https://forum.snapcraft.io/t/installing-snap-on-opensuse/8375 [11:20] because no other distro install guide has it, seemed unnecessary [11:20] mborzecki: All green from here. Store appears to be working for me. [11:21] popey: yep, ok. makes sense. maybe the colon too :) [11:21] Chipaca: What's funky about the version string? What should it look like? [11:21] on it [11:21] thanks! [11:21] np [11:33] pedronis: I updated 6466 - I added some more comments there, for me the sanity timeout thing is dubious, details in the PR [11:34] pedronis: but also not relevant for the particular PR [11:35] pedronis: addressed/responded to your 1st pass feedback on #6465 ; now working on a followup for the slot naming [11:35] PR #6465: overlord/ifacestate: hotplug-add-slot handler [11:44] pedronis: added another comment to 6466 and will stop for now on this one [11:53] PR snapd#6475 closed: packaging: disable systemd environment generator on 18.04 (2.37) [12:04] PR snapd#6474 closed: snap-confine: fix classic snaps for users with /var/lib/* homedirs (2.37) [12:19] mvo: I reviewed #6466 [12:19] PR #6466: cmd/snap-confine: handle death of helper process <⚠ Critical> [12:37] pedronis: thank you [12:39] pstolowski: thx, I queued to re-review hotplug-add-slot , have some other (older) things to review first plus 2.37.x stuff [12:40] though [12:44] mvo: did you see the thing about wekan? [12:46] PR snapcraft#2459 closed: catkin plugin: describe how to build all packages [12:51] mvo, niemeyer, zyga, uhh [12:51] we have a problem [12:51] nah ... [12:51] you have a "challenge" [12:51] MongoDB is being removed from Fedora is a bit of a problem [12:52] the mgo driver currently depends on it [12:52] which is a snapd dependency [12:53] * ogra wonders why snapd would depend on a database driver [12:53] * Son_Goku shrugs [12:53] sounds like a failure [12:53] I think it uses the mgo driver's bson and json code [12:54] ah [12:54] and it's only in one place: errtracker [12:54] time to vendor bson [12:55] well, niemeyer wrote the driver [12:55] Son_Goku: why's mongo being removed from fedora? the licensing thing? [12:55] yes [12:55] Debian is doing the same thing, btw [12:55] and this will affect snapd in the same manner [12:55] yeah, the license [12:56] Son_Goku: mgo wrote it but afaik no longer maintains it [12:56] this is the year of the mongodb snap ! [12:56] fuck mongodb [12:56] Son_Goku: er, i meant gustavo, not mgo. I wish mgo wrote things. [12:56] haha [12:56] that "mongodb is webscale" youtube thing never ever got old [12:56] Yeah, that was part of the problem.. I was trying to convince it to write itself but didn't work [12:57] XD [12:57] https://www.youtube.com/watch?v=b2F-DItXtZs [13:04] off to pick up the kids [13:06] mvo: hey! Once you're back from lunch, just a quick question: we'll be spinning .2 bionic core18 point-release images soonish, is snapd 2.37.1 from stable good-enough for the new images? [13:10] sil2100: I don't have an answer, but I absolutely love that question === ricab is now known as ricab|lunch [13:17] Hi, I’m looking for a description of the default snap update frequency. is there anything clearer than the “within 6 hours” on ? [13:19] LOL the snap man page gets narrower and narrower until it’s one word per line [13:23] It does? I don't see that here [13:24] (up-to-date bionic) [13:25] mpt: https://forum.snapcraft.io/t/system-options/87 maybe? [13:26] sparkiegeek: thank you for reminding me about how much license sucks [13:26] mpt: which manpage where? [13:26] Chipaca: you're not wrong [13:27] sparkiegeek: i commented on the bug, mostly with a "yeah sucks" [13:27] sparkiegeek: but it's a whole-stack suckage, if that helps ¯\_(ツ)_/¯ [13:27] cjwatson, perfect, thanks [13:27] Chipaca: well... it doesn't :D [13:27] Chipaca, “man snap” for snap 2.37.1 on Ubuntu 14.04 [13:27] I’m reporting a bug now [13:28] mpt: could you also do [13:28] mpt: snap help --man | man -l - [13:28] mpt: and report whether that looks any better? [13:28] Chipaca, same result [13:29] mpt: https://i.redd.it/yl57urxpoje21.jpg [13:29] * sparkiegeek reloads https://twitter.com/mptbugs [13:30] 🔜 [13:31] Super-confused; extracting the man page manually on pepo and piping to man -l - doesn't show that [13:32] ooh ooh [13:32] mpt: snap help --man < /dev/null | man -l - [13:32] mpt: how does that one work [13:33] Chipaca, same result [13:33] aww [13:33] mpt: I'm all out of "thanks i hate it" images [13:34] cjwatson: 14.04? [13:34] Yes. Trying a container now [13:35] cjwatson: 2.37.1? [13:35] Yes. Trying a container now :) [13:35] cjwatson: trying a container now? [13:35] * Chipaca runs [13:35] I sure am [13:35] Chipaca: if you want to help move the license handling forward, I believe we still need a response to https://forum.snapcraft.io/t/snap-license-metadata/856/52 [13:36] sparkiegeek: dang [13:36] sparkiegeek: let's blame niemeyer [13:36] Chipaca: we all do :D [13:37] pedronis: could you pick that up ^ ? [13:38] https://bugs.launchpad.net/snapd/+bug/1814767 [13:38] Bug #1814767: “man snap” gets narrower and narrower until it’s 1 word/line [13:39] Oh yes, now I see it [13:39] Chipaca: we had a discussion in december how to go a bit forward, but no work on it is planned for right now [13:42] This is surely a groff bug or something, but how was I previously unaware of something like that [13:43] So this is the kind of Postel’s Law thing that turns into two bugs? [13:43] Oh, it's due to the doubled .TP lines [13:43] One on groff and one on the man page [13:43] I think the meaning of two .TP lines in a row is probably not especially well-defined [13:44] https://git.savannah.gnu.org/cgit/groff.git/commit/?id=49abd7a9093ae903bb0032eb74d647fb481d2acb [13:45] mvo: #6473 is green, I do think we do want it [13:45] PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> [13:45] mvo: the description/commit needs updating tough [13:45] left a diagnosis in 1814767 [13:46] cjwatson: thank you [13:46] * mpt applauds [13:46] we already do nasty things to get that manpage, I guess removing excess TP won't be that bad [13:47] For good measure I manually stripped out the doubled .TP requests and confirmed that that fixes it [13:48] zyga pedronis We discussed GPU issues when building snaps against core18. I've been testing the last few days, and so far can't reproduce the issues using snapd 2.37.x [13:49] So far xonotic and ffmpeg migrated to core18 and tested using nvidia and intel on the host. [13:50] Just letting you know, because that bug I said I would file might not be required now. [13:50] Wimpress: ah, I was wondering, I don't see anything we did that actively would have fixed something [13:50] but not sure [13:51] when zyga is around he might chime in on this [13:51] We do have some failures, but we're investigating because it may not be snapd related. [13:52] Getting ffmpeg working gives me good confidence since it uses all the accelerated capabilities. [13:52] Chipaca: Might be easier to just fix it in go-flags? [13:52] mvo: hey, do you have any experience with aborted tasks from spread? I get aborted, I understand the reason from the docs on why it is good, I just cannot find a reason for it happening [13:53] cjwatson: go-flags author is burstily responsive, and getting the right version everywhere is very slow [13:53] Oh :( [13:54] cjwatson: I'm also wanting to give go-flags support for generating manpages in sections other than 1 [13:54] need to revisit the pending PRs and see why they haven't been merged [13:56] Chipaca: btw, could you do a first pass over https://github.com/snapcore/snapd/pull/6079 when you have a bit of time [13:56] PR #6079: cmd/snap: `snap connections` command [14:24] "Channel latest/beta for multipass is closed; temporarily forwarding to beta." - huh? I guess snapd is not resolving the "lack of track == 'latest'" when interpreting closed channels [14:25] sparkiegeek: that should be fixed in … 2.37? 2.38? [14:25] one of those [14:33] Chipaca: ok, well that was from 2.37.1 [14:34] * sparkiegeek fights Chipaca in #1814640 [14:34] Bug #1814640: snap info showing "unset" license for snaps [14:39] mborzecki: are you available for a couple of questions about getting vulkan working in snaps? === ricab|lunch is now known as ricab [14:44] PR snapcraft#2457 closed: lifecyle: avoid installation of snaps in docker [14:46] hunterk: i'm hardly an expert, but feel free to ask [14:47] kk, no worries :) I'm just trying to get the vulkan renderer in my snap, RetroArch, to work: https://forum.snapcraft.io/t/problem-with-vulkan-support-in-snaps/9744 [14:47] as it is, I always get "failed to open vulkan loader", which is the same error I get outside of the snap if I don't have the right libs installed [14:48] but I have them listed in the build and stage packages, so I'm not sure if there's anything else I need to do to make them visible/accessible to the snap [14:53] pedronis: fyi, https://bugs.launchpad.net/snapstore/+bug/1814592/comments/5 [14:53] Bug #1814592: cannot compile personal-files/system-files snap declaration constraints [14:53] jdstrand: I answered [14:54] pedronis: I just pressed Enter on my comment to your answer... [14:54] pedronis: ie, look at comment $5 [14:54] #5 [14:54] jdstrand: we cannot do that change [14:54] jdstrand: you need a regexp using | for the multiple entry case [14:55] jdstrand: as I said for a list attribute the regexp needs to much all entries [14:56] pedronis: I know that is the current implementation, but do you acknowledge the awkwardness of the current situation? [14:56] pedronis: this should've come up in PR review for the interfaces. We've never had an attribute that is a list of strings [14:57] pedronis: I mean, we can mark it Won't Fix and just use the awkward syntax if you want [14:57] jdstrand: no, we thought about lists [14:57] PR snapd#6476 opened: cmd/snap: tweak man output to have no doubled up .TP lines