[06:24] <mborzecki> morning
[06:27] <mvo> hey mborzecki ! good morning!
[06:27] <mvo> mborzecki: did you had a good weekend?
[06:28] <mborzecki> mvo: tried to watch some streams from fosdem, but kids didn't give me much chance
[06:29] <mvo> mborzecki: heh
[06:30] <mborzecki> lots of snow today :/
[06:30] <mvo> mborzecki: no snow anymore here - the kids are disappointed
[06:34] <mborzecki> mvo: any news from zyga yet?
[06:35] <mup> PR snapd#6387 closed: client, daemon: introduce helper for querying snapd API for the list of slot/plug connections <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6387>
[07:01] <mborzecki> mvo: do we need to cary any patch for https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814355 in snapd?
[07:01] <mup> Bug #1814355: snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression) <regression-update> <verification-done> <verification-done-bionic> <snapd (Ubuntu):Confirmed> <snapd (Ubuntu Bionic):Fix Released> <https://launchpad.net/bugs/1814355>
[07:01] <mvo> mborzecki: yes, PR coming any second
[07:01] <mborzecki> ok
[07:01] <mvo> mborzecki: also we broke postgresql which uses /var/lib/postgresql
[07:01] <mup> PR snapd#6470 opened: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
[07:01] <mvo> mborzecki: most unfortunate
[07:01] <mborzecki> heh
[07:02] <mvo> mborzecki: the PR for the generator fix took a little bit longer because of the spread fix
[07:02] <mborzecki> mvo: on the upside, once we gather all the workarounds now, these problems won't appear in future relases (hopefully)
[07:11] <zyga> Hey
[07:12] <mborzecki> zyga: congratulations!
[07:12] <zyga> mvo: I will be able to work for half of today
[07:13] <zyga> I’m pretty tired, not much sleep due to all the emotions :-)
[07:13] <zyga> Thank you, the mother and the baby are doing great :-)
[07:13] <mborzecki> zyga: great news :)
[07:14] <zyga> mvo: how can I help?
[07:14] <mvo> zyga: hey, good morning
[07:15] <mvo> zyga: CONGRATS
[07:15] <mvo> zyga: take it easy and enjoy this very special time
[07:17] <zyga> I will have some time for work so I would like to focus on whatever matters the most
[07:17] <zyga> Do we need another patch for postgresql?
[07:19] <mvo> zyga: yes, I push something shortly
[07:19] <zyga> Ok
[07:22] <mvo> zyga: I push somehting minimal in 5min for review (would love your opinion) and then force-push a spread test once I'm done with it
[07:23] <zyga> Ok
[07:24] <zyga> mvo: silly question? How did we break Postgres? Is it classic Postgres running snaps or snapped Postgres?
[07:31] <mup> PR snapd#6471 opened: [RFC] snap-confine: fix classic snaps for users with /var/lib/* homedirs <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
[07:31] <mvo> zyga: its a classic snap
[07:32] <mvo> zyga: ^- this should explain things
[07:38] <pedronis> zyga: congratulations!
[07:39] <pedronis> mvo: we are getting this in spread tests (which are also very flaky):  The following packages have unmet dependencies:
[07:39] <pedronis>  snap-confine : Depends: snapd (= 2.32.5+18.04) but 2.37.1+18.04 is to be installed
[07:39] <pedronis> E: Unable to correct problems, you have held broken packages.
[07:39] <pedronis> https://api.travis-ci.org/v3/job/488175953/log.txt
[07:39] <zyga> pedronis: thank you :-)
[07:40] <mvo> pedronis: hm, that might be a short glitch when the mirrors got updated, is that recent? let me quickly check
[07:40] <mvo> pedronis: there was a bit of turmoil over the weekend because the snap generator for systemd broke things (because of bugs in systemd )
[07:41] <pedronis> mvo: that seems very unfortunate
[07:41] <mvo> pedronis: archive.u.c seems to be fine, just checked
[07:41] <mvo> pedronis: it is
[07:41] <mvo> pedronis: this is why we have 6470 now
[07:42] <pedronis> mvo: anyway I worked a bit over the weekend, some PR's up, but sprea tests are flaky
[07:43] <mvo> pedronis: I saw the PRs, thank for those
[07:43] <mvo> pedronis: yeah, we need to make another push on the tests to make them more robust
[07:43] <mborzecki> mvo: left a comment in #6470 i can test it locally and push a fix there
[07:43] <mup> PR #6470: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
[07:43] <mborzecki> pedronis: morning
[07:44] <mvo> mborzecki: excellent point, yeah, feel free to push
[07:44] <mborzecki> mvo: ok
[07:44] <mvo> mborzecki: then the above exit 0 needs to go as well
[07:44] <mborzecki> mvo: yup
[07:45] <mvo> mborzecki: also we are probably fien with [ "18.04" = "$..." ] (no need for bashim with [[ and == here AFAICT - sorry, this is like a hyper nitpick :/ OCD or something on my part)
[07:45] <mborzecki> mvo: hahah ok :)
[07:47] <zyga> mvo: ah, indeed, classic
[07:47]  * mvo hides a bit
[07:47] <mvo> zyga: yeah, the mount we added in snap-cofine.c I think is actually not needed
[07:47] <zyga> Hold on
[07:47] <mvo> zyga: in the original fix
[07:47] <zyga> For classic snaps /var/lib is the host /var/lib
[07:47] <zyga> How is it broken?
[07:47] <mvo> zyga: exactly
[07:48] <mvo> zyga: we prevent snap-confine to write to it
[07:48] <mvo> zyga: thats all we need to fix
[07:48] <mvo> zyga: which is what the new PR is doing
[07:49] <zyga> I see
[07:49] <zyga> +1
[07:49] <zyga> Good idea
[08:03] <zyga> mvo: your patch looks good
[08:04] <zyga> mvo: over weekend I iterated on the service regression
[08:12] <mvo> zyga: thanks
[08:31] <pstolowski> mornings
[08:33] <mvo> hey pstolowski - good morning
[08:36] <pedronis> mvo: anything that I need to review?
[08:36] <pedronis> in particular
[08:37] <mvo> pedronis: nothing particular, anything tagged with 2.37 will help
[08:37] <mborzecki> pstolowski: hey
[08:43] <marcustomlinson> Happy Birthday pstolowski!
[08:43] <pstolowski> marcustomlinson: hey marcustomlinson! thanks! :)
[08:48] <pedronis> mvo: does https://github.com/snapcore/snapd/pull/6470 means that 18.04 will not have /snap/bin in the PATH for a while?
[08:48] <mup> PR #6470: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
[08:50] <mvo> pedronis: correct
[08:50] <pedronis> :/
[08:53] <pedronis> mvo: is this a systemd  change? is there a systemd bug for this?
[08:53] <pedronis> I just see snapd bugs
[08:53] <pedronis> not systemd bugs
[08:54] <pedronis> mvo: do we need to revert to what we were doing before the generator?
[08:54] <pedronis> the new situation is not really acceptable
[08:54] <mvo> pedronis: it was all rather hectic yesterday, there is a reference to a systemd bug (1771858 which has both snapd and sytemd tasks)
[08:55] <pedronis> mvo: but that's very old
[08:55] <mvo> pedronis: what is not acceptable?
[08:55] <pedronis> and most systemd says fix commited
[08:55] <pedronis> mvo: that we lose /snap/bin
[08:55] <mvo> pedronis: yes, we need to add a systemd task now
[08:55] <mvo> pedronis: we never had it on 18.04
[08:55] <pedronis> heh
[08:55] <mvo> pedronis: the generator only got added via the SRU and we had trouble getting one in for a while
[08:56] <mvo> pedronis: so this generator works on 18.10 (there we were successful)
[08:56] <pedronis> mvo: so /snap/bin was always broken in 18.04 ?
[08:56] <mvo> pedronis: but the generator never made it to 18.04 until last thursday
[08:56] <mvo> pedronis: correct for *service* in systemd
[08:56] <pedronis> but it works here
[08:56] <pedronis> mvo: this is only about services?
[08:56] <mvo> pedronis: it works fine for anything that has a shell or uses /etc/environment or /etc/login.defs
[08:56] <mvo> pedronis: correct, *only* services
[08:57] <mvo> pedronis: and its also an issue on 16.04 where there are no generators
[08:57] <mvo> pedronis: so in a sense its not terrible but still quite unfortunate
[08:57] <mvo> pedronis: also it reminded me how much of a mess the system environment is (or has been, systemd is improving things here)
[08:58] <mvo> pedronis: should I clarify that in the PR? I will add a systemd bug next
[08:58] <pedronis> mvo: so this will never work, until we get a newer systemd in 18.04
[08:58] <pedronis> which will not happen?
[08:59] <pedronis> mvo: fwiw  the description in https://github.com/snapcore/snapd/pull/6470 is very confusing
[08:59] <mup> PR #6470: packaging: disable systemd environment generator on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6470>
[08:59] <pedronis> that's also why I'm asking this silly questions
[09:00] <mvo> pedronis: well, apparently there is work to port the fixes to the systemd in 18.04 and SRU them, no not quite never but not right now
[09:01] <pedronis> ok
[09:01] <mvo> pedronis: let me fix the description then, sorry for the confusion
[09:01] <pedronis> mvo: is mostly pointing at bugs
[09:01] <mvo> pedronis: well, after my meeting
[09:01] <pedronis> but those bugs are confusing in themselves
[09:02] <pedronis> mvo: thanks, np, I have a bit issue fatigue atm
[09:02]  * mvo hugs pedronis 
[09:29] <Chipaca> pedronis: o/
[09:30] <Chipaca> pedronis: have you thought of a better name than "rerefresh" for the handler?
[09:30] <sparkiegeek> re²fresh ?
[09:30] <pedronis> Chipaca: not so far, too many other things :(
[09:31] <Chipaca> what the handler does, ideally, is check whether the store thinks anything further needs doing
[09:31] <Chipaca> "check-pending"? :-/
[09:44] <pedronis> Chipaca: check-rerefresh ?
[09:45] <Chipaca> pedronis: is it going to change in any way when it's no longer just rerefresh?
[09:46] <pedronis> Chipaca: well, in a sens is also checking the refresh
[09:46] <pedronis> it's doing many things
[09:57] <mvo> pedronis: I updated the description now (had a meeting before that)
[09:58] <mvo> pedronis: I hope this is clearer now?
[09:59] <pedronis> mvo: yes, thank you, I fixed a couple of typos in it
[10:05] <mvo> pedronis: ta
[10:11] <pstolowski> pedronis: hey, have you seen my message re ensure-before from friday evening?
[10:17] <pedronis> pstolowski: no, I saw it now, the fix seems wrong, we already are reading the channel somewher else
[10:17] <pedronis> so we probably need something a bit different than the default code
[10:17] <pedronis> suggested
[10:17] <pstolowski> pedronis: yes, we do in Loop
[10:18] <pedronis> I tought we discussed that
[10:18] <pedronis> before
[10:23] <mborzecki> phew, my rspi3 looked dead for a while
[10:27] <pedronis> pstolowski: what happens if we simply do  if !Stop() { return }  else { Reset }
[10:30] <pstolowski> pedronis: i'll check. for now if i only Reset (with slightly modified conditionals)", it works (no slowness with the reproducer scenario).
[10:37] <mborzecki> need to go out for while, back in ~2h
[10:54] <pedronis> mvo: thanks for the reviews, I tried to answer some of your comments, but one I'm not sure I'm understand what you are asking
[10:54] <pstolowski> pedronis: that seems to work
[10:54] <pedronis> mvo: https://github.com/snapcore/snapd/pull/6467/files#r253412999
[10:54] <mup> PR #6467: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/6467>
[10:55] <pedronis> Chipaca: btw maybe you could review this ^ as well when you have a moment?
[10:55] <pedronis> pstolowski: ah
[10:56] <pedronis> pstolowski: to be clear the idea is that in the !Stop() case, the Loop will do <-C and Reset anyway
[10:56] <mvo> pedronis: sure, looking
[10:57] <pstolowski> pedronis: yes, i understand this now, thanks! i'm going to propose what i've right now
[11:04] <mup> PR snapd#6472 opened: [RFC] overlord: fix ensure before slowness on Retry <Created by stolowski> <https://github.com/snapcore/snapd/pull/6472>
[11:05] <pedronis> mvo: if we want to change how it looks like it would be a change under snap/seed_yaml.go
[11:06] <pedronis> there's a Write there and the yaml encoding metadata
[11:08] <mvo> pedronis: yeah, looking at it again I think its not relevant, just curiosity on my part
[11:09] <pedronis> about the tests, I'll see once I get a 2nd review, it's also a mixture of two tests, I need to double check if it's not missing some checks
[11:12] <pedronis> mvo: are we going to cut 2.38 this week? or next at this point?
[11:13] <mvo> pedronis: probably monday next week, we will do 2.37.2 today (if we get reviews)
[11:13] <Chipaca> pedronis: in that PR, why is --classic-arch needed?
[11:14] <Chipaca> pedronis: why can't it be --architecture?
[11:14] <pedronis> Chipaca: because on core an architecure is mandatory in the model
[11:14] <pedronis> but in a classic model is optional
[11:15] <mvo> hrm, hrm, we run into timeouts in travis again
[11:15] <Chipaca> this is a classic arch: https://upload.wikimedia.org/wikipedia/commons/b/b8/Arc_de_triomphe_frontsimple.jpg
[11:15] <mvo> Chipaca: lol
[11:15] <pedronis> Chipaca: --classic-architecture is very long
[11:15] <Chipaca> pedronis: so just call it --architecture :-)
[11:15]  * mvo hands the "mr smarty pants" award to Chipaca 
[11:16] <pedronis> indeed
[11:16] <pedronis> Chipaca: it's not needed at all for core
[11:16] <Chipaca> pedronis: so error out if it's provided without classic (or if provided and different from the model?)
[11:16] <Chipaca> --classic-arch is nasty :-/
[11:17] <Chipaca> you'll be saying classic twice, for one
[11:17] <pedronis> Chipaca: we do error out if it's provided without --classic
[11:17] <Chipaca> alternatively, --classic[=<arch>]
[11:17] <pedronis> Chipaca: the reverse is that if it's architecure people will give it anyway
[11:17] <pedronis> tough people are not really meant to call this directly for core
[11:19] <Chipaca> pedronis: what happens if you use --classic without --classic-arch?
[11:20] <pedronis> Chipaca: it fails if you model has snaps but not architecture
[11:20] <pedronis> Chipaca: you can read the code as well
[11:20] <Chipaca> pedronis: so it's required for classic
[11:20] <pedronis> no
[11:20] <pedronis> Chipaca: architecure is in a classic model is optional
[11:20] <pedronis> not prohibited
[11:20] <Chipaca> i'm reading the code, seven function calls deep and still don't know if this will error without it
[11:21] <pedronis> Chipaca: here:  https://github.com/snapcore/snapd/pull/6467/files#diff-da07f373046a0a24e67b18699dc15a70R197, it's actually one level deep
[11:21] <mup> PR #6467: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/6467>
[11:22] <Chipaca> dammit, missed that
[11:28] <pedronis> Chipaca: more seriously, if we had to pass architecture to other commands would you spell it --arch or --architecture , I'm in favor of the shorter one
[11:29] <Chipaca> pedronis: I'm objecting to the repetition of classic, more than to the shortening of architecture
[11:29] <Chipaca> pedronis: writing as much on the pr
[11:29] <pedronis> Chipaca: ok
[11:57] <pstolowski> is Sergio going to be back today?
[12:00] <mvo> pstolowski: next week iirc
[12:00] <pstolowski> mvo: ah, ok, thanks
[12:15] <mborzecki> re
[12:57]  * Chipaca ⇝ lunch
[13:01] <pedronis> pstolowski: did a first pass over #6465
[13:01] <mup> PR #6465: overlord/ifacestate: hotplug-add-slot handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
[13:01] <pedronis> let me know if you have questions
[13:02] <pstolowski> pedronis: thanks!
[13:47] <mup> PR snapd#6451 closed: tests: update smoke/sandbox test for armhf <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6451>
[13:58] <pedronis> Chipaca: I will reconsider the --classic-arch things in a follow up, landing the PR as is for now
[14:00] <mup> PR snapd#6467 closed: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6467>
[14:11] <Chipaca> pstolowski: pedronis: https://forum.snapcraft.io/t/serial-port-hotplug/9773
[14:56] <kjackal> Hi snappy people, this is driving me crazy. I am trying to find documentation on what happens to SNAP_DATA during a refresh. In particular, is it preserved or not?
[14:57] <kjackal> I read that is backed up and restored, but it does not say that the contents are preserved/not changed during a refresh
[15:09] <pedronis> jdstrand: hi,  there is a couple of review of 2.37 PRs https://github.com/snapcore/snapd/milestone/22 that needs your review (first two there)
[15:15] <jdstrand> I thought I did the 2nd one. anyway, ack
[15:16] <pedronis> jdstrand: no, I see still voting pending for you in those
[15:19] <pedronis> jdstrand: I'm referring to: https://github.com/snapcore/snapd/pull/6471
[15:19] <mup> PR #6471: [RFC] snap-confine: fix classic snaps for users with /var/lib/* homedirs <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
[15:20] <pedronis> and https://github.com/snapcore/snapd/pull/6466
[15:20] <mup> PR #6466: cmd/snap-confine: handle death of helper process <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
[15:27] <mup> PR snapd#6468 closed: image: bootstrapToRootDir => setupSeed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6468>
[15:35] <jdstrand> pedronis: ok, I reviewed 6471 but please see https://github.com/snapcore/snapd/pull/6471#pullrequestreview-199638498
[15:35] <mup> PR #6471: [RFC] snap-confine: fix classic snaps for users with /var/lib/* homedirs <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6471>
[15:41] <pedronis> pstolowski: https://github.com/snapcore/snapd/pull/6472 is red,  real issue or just fluke ?
[15:41] <mup> PR #6472: [RFC] overlord: fix ensure before slowness on Retry <Created by stolowski> <https://github.com/snapcore/snapd/pull/6472>
[15:47] <pstolowski> pedronis: Successful tasks: 4012 and 2 failures to prepare on s390x ;)
[15:48] <pstolowski> cheksum errors from apt
[15:51] <pedronis> jdstrand: I took a note pointing to those comments, yes, sadly we don't have time to design how this should work, it was working by chance so far
[15:51] <pedronis> and it's a big regression atm
[15:58] <jdstrand> pedronis: yep, I understand
[16:04] <greyback> hi folks, I'm experiencing a snap daemon that refuses to die, even after I've removed the snap! I've no idea how it might still be alive, anyone see something obvious https://pastebin.ubuntu.com/p/QPNWGXkxpZ/
[16:05] <greyback> how is snapfuse mounting a snap if its snap file is missing?
[16:06] <greyback> this even persists after reboot
[16:17] <Chipaca> greyback: anything interesting in systemctl list-units --type mount ?
[16:19] <greyback> Chipaca: nothing referring to multipass anyway (the snap in question)
[16:20] <Chipaca> greyback: how is that mount surviving reboot, then?
[16:20] <greyback> Chipaca: no idea
[16:24] <mup> PR snapd#6473 opened: snap-confine: remove special handling of /var/lib/jenkins <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
[16:26] <greyback> Chipaca: oh I'm an idiot, ignore me. It was running inside an lxd instance
[16:26] <Chipaca> greyback: and you were checking outside?
[16:26] <greyback> Chipaca: yeah
[16:26] <Chipaca> greyback: it's multipass all the way up
[16:26] <greyback> :)
[16:26] <greyback> sorry about the noise
[16:26] <Chipaca> the logo needs to be a turtle seen from underneath
[16:27] <sil2100> cwayne: hey! I see the latest core18 snap has all the testflinget checkboxes checked, can I promote it to candidate then? ;)
[16:28] <sil2100> cwayne: (the Ready for Candidate checkbox is not yet checked, which is why I'm asking)
[16:28] <cwayne> sil2100: can you give us like an hour? We're in the process of adding a new system
[16:28] <cwayne> Which is why we didn't check it off yet
[16:56] <sil2100> cwayne: sure!
[17:16] <Chipaca> mvo: https://forum.snapcraft.io/t/snapd-2-37-1-refresh-broke-layouts-snap-remove-install/9803
[17:27] <mborzecki> heh, the release just keeps on giving
[17:27] <pedronis> it doesn't look like a regression tough
[17:27] <pedronis> more a layout related bug
[17:37] <sil2100> mvo, pedronis, zyga: hey! With the bionic .2 close, wanted to touch base on the snapd snap - is 2.37.1 the version we want to ship for core18 .2?
[17:43] <pedronis> sil2100: there is no snapd inside core18
[17:43] <pedronis> you mean the images ?
[17:44] <sil2100> pedronis: in the images I mean, for the point-release
[17:44] <sil2100> We're releasing new images with each point-release
[17:44] <pedronis> probably need mvo (which is afk) for that discussion
[17:44] <sil2100> Just wanted to know if we're good to go with the current snapd
[17:46] <zyga> hey mvo
[17:46] <zyga> back from the hospital now
[17:46] <zyga> I noticed https://github.com/snapcore/snapd/pull/6473
[17:46] <mup> PR #6473: snap-confine: remove special handling of /var/lib/jenkins <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6473>
[17:46] <zyga> and I was thinking if we need to drop it
[17:46] <zyga> if you have a strictly confined snap used in jenkins
[17:46] <zyga> you will see issues
[17:46] <zyga> I would keep this patch for now
[17:46] <zyga> and only drop it in 2.38 cyckle
[17:46] <zyga> *cycle
[17:47] <pedronis> zyga: there are other issues with it
[17:47] <pedronis> I mean it fails later
[17:47] <zyga> I see
[17:47] <pedronis> in some cases
[17:47] <zyga> cannot create user data directory: /var/lib/jenkins/snap/test-snapd-tools/6: Read-only file system
[17:47] <zyga> this means that /var/lib/jenkins was not mounted from classic world
[17:48] <zyga> anyway
[17:48] <zyga> just a quick comment
[17:49] <zyga> mvo: the bind mount failed because apparmor permissions are incorrect
[17:49] <zyga> mvo: I think we should fix that rather than undo it
[17:49] <pedronis> zyga: somebody hit some kind of layout / stale namespace issue: https://forum.snapcraft.io/t/snapd-2-37-1-refresh-broke-layouts-snap-remove-install/9803
[17:49] <zyga> as otherwise you will still break people using jenkins and using snaps inside the CI loop
[17:49] <pedronis> zyga: ?
[17:51] <ijohnson> pedronis, zyga: that was me that hit the layout issue. let me know if you need any more info on it, but since it went away after a reboot it's not a problem for me anymore
[17:52] <zyga> ijohnson: I just asked in the forum thread
[17:52] <zyga> ijohnson: sorry, I'm not working in full capacity so my responses may be spotty
[17:53] <ijohnson> ah got it. No problem, I think this issue is pretty low priority as it seems like an edge case of something
[17:53] <pedronis> zyga: are you saying that our special-home tests don't do enough
[17:53] <pedronis> related to keeping the jenkins hack
[17:53] <zyga> pedronis: the denial seems to suggest the mount mode is incorrect, though this is odd as the test is supposedly exercising this
[17:54] <zyga> I can recheck to be sure
[17:54] <pedronis> zyga: do the test try to do something with the accessible bits of HOME ?
[17:54] <pedronis> you probably need a snap with the home interface
[17:54] <pedronis> to notice I suppose
[17:55] <zyga> pedronis: no, since before snap-confine would fail early on permission error; perhaps it should do something more elaborate (e.g. access $SNAP_USER_DATA)
[17:55] <zyga> ijohnson: thanks
[17:56] <pedronis> that's my question, do we have not good enough tests?
[17:56] <zyga> ijohnson: //deleted is a thing done by the kernel
[17:56] <pedronis> and would have they passed with 2.36
[17:56] <ijohnson> zyga: interesting, I've never seen that before
[17:56] <zyga> pedronis: I don't know yet, I haven't tried running that test against 2.36
[17:56] <zyga> ijohnson: it is also annoying since it's a super weird special state
[17:57] <pedronis> anyway spread tests are not helping either atm (lot of red from very different reasons)
[17:57] <zyga> I see
[17:59] <zyga> ijohnson: https://lwn.net/Articles/265920/ look for //deleted
[17:59] <zyga> ijohnson: you can get a directory that has been removed
[17:59] <zyga> ijohnson: it is super annoying
[17:59] <ijohnson> huh that's so odd
[18:00] <zyga> ijohnson: because then it is a black hole that cannot be used normally
[18:00] <pedronis> jdstrand: reminder about #6466
[18:00] <mup> PR #6466: cmd/snap-confine: handle death of helper process <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
[18:01] <jdstrand> pedronis: I'm looking at it now
[18:01] <zyga> ijohnson: I will look at this but no promises (baby born yesterday)
[18:01] <ijohnson> zyga: yeah it's really odd that the directory didn't even have references for "." and ".." in it
[18:01] <pedronis> jdstrand: thx
[18:01] <zyga> ijohnson: it's a very weird thing that AFAIK is not documented anywhere
[18:01] <zyga> (read the fine source they said)
[18:01] <ijohnson> zyga: no rush at all, it can certainly wait as long as needed, and congrats!
[18:01] <zyga> ijohnson: I don't think this is a new issue though
[18:02] <zyga> ijohnson: at leas a quick feeling about the scope of changes in 2.36
[18:09] <sil2100> cwayne: can you give me a poke once the core18 snap is good to go? ;)
[18:09] <sil2100> Thanks!
[18:13] <cwayne> Yep
[18:24] <pedronis> zyga: the quirks never mounted anything from the host except lxd, I'm looking at the patch that removed them
[18:26] <zyga> that's correct but it seems that the new code for jenkins doesn't run in practice because of an apparmor denail; I can be wrong, I will check calmly
[18:26] <zyga> just eating supper, I was starving since noon
[18:26] <pedronis> zyga: just saying afaik quirks would not have made snap touching home running under a special home dir work
[18:27] <pedronis> because nothing like a mount of the special home into the snap namespace
[18:27] <pedronis> was there
[18:27] <zyga> mmm
[18:27] <zyga> I see
[18:27] <zyga> though /var/lib was a tmpfs
[18:27] <pedronis> yes
[18:27] <pedronis> filled with bits from core
[18:27] <pedronis> not the host
[18:27] <pedronis> except for lxd
[18:27] <zyga> so it was ephemeral but writable
[18:27] <pedronis> if I read the code
[18:27] <pedronis> correctly
[18:27] <zyga> yes, correct
[18:28] <pedronis> nothing would bind mount /var/lib/jenkins
[18:28] <pedronis> except maybe some layout bug
[18:28] <pedronis> afaict
[18:29] <zyga> sure
[18:29] <zyga> but it would create one for ci run
[18:29] <zyga> maybe that was enough?
[18:29] <pedronis> the snap itself?
[18:29] <pedronis> not a lot of code does mkdir $HOME
[18:29] <zyga> yeah
[18:30] <zyga> snap-confine mkdir's snap user data
[18:30] <zyga> mkdirs
[18:30] <pedronis> inside the the namespace?
[18:30] <pedronis> or from outside?
[18:31] <pedronis> if you know from memory
[18:31] <pedronis> (I can check otherwise)
[18:31] <zyga> no
[18:31] <zyga> i think inside
[18:31] <zyga> but not sure
[18:32] <pedronis> that would be allowed by the new "fix"
[18:32] <pedronis> so you would have a wrong home
[18:32] <pedronis> but some home
[18:32] <pedronis> inside
[18:32] <pedronis> if it was from outside
[18:32] <pedronis> then nothing changes
[18:33] <zyga> yeah
[18:33] <zyga> I will look at how 2.36 behaved in reality
[18:33] <zyga> maybe classic snaps were used
[18:33] <zyga> like go
[18:33] <zyga> anyway
[18:33] <zyga> I'll check what was happening
[18:33] <zyga> just need a little break
[18:34] <zyga> no much sleep last night
[18:34] <zyga> 2.36 + classic snap was probably "working" enough
[18:34] <zyga> since it would run in real /var/lib/jenkins
[18:34] <zyga> and since there was no blocking error from snap-confine
[18:35] <pedronis> yes, classic there is no name space
[18:49] <pedronis> zyga: yes, it's created after we pivot afaict
[19:05] <jdstrand> pedronis and zyga: commented on PR6466
[19:05] <jdstrand> PR 6466
[19:05] <mup> PR #6466: cmd/snap-confine: handle death of helper process <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
[19:05] <hunterk> Hi, I posted on the snapcraft forum a few days ago asking for info/tips on getting vulkan to work with my snap: https://forum.snapcraft.io/t/problem-with-vulkan-support-in-snaps/9744
[19:05] <hunterk> but I figured I'd ask here, too :)
[19:06] <zyga> jdstrand: it is from siginterrupt man page
[19:06] <zyga> jdstrand: signal vs sigaction, no specific reason, I can use sigaction
[19:06] <zyga> but SIG_ITG is just shorter
[19:06] <zyga> IGN
[19:06] <zyga> hunterk: ask mborzecki here tomorrow morning european time
[19:07] <jdstrand> zyga: there are a lot of questions in my comments, please ponder and respond in the PR
[19:08] <zyga> jdstrand:  think you misread the code
[19:08] <zyga> the parent is where the change is relevant, we don't undo it until after any communication with the child is finished (after we wait and close the pipes)
[19:09] <hunterk> zyga: okay, will do
[19:09] <zyga> jdstrand: I will respond in the PR as well, just wanted to bring that up quickly
[19:09] <jdstrand> maybe I didn't see where you put teardown
[19:09]  * jdstrand looks again
[19:10] <pedronis> jdstrand: the tear down is not in the same function
[19:10] <jdstrand> I did misread that. jeez
[19:10] <pedronis> the diff artifcat as such is not very clear
[19:11] <zyga>   jdstrand your comment about read of size zero is, i think, valid but I need to recheck things, I did change it in one of my earlier branches that included more changes but then I dropped that after reading how signals would be delivered (I think we do get EPIPE, not read of size zero then)
[19:12] <zyga> oh, I noticed mvo changed the branch as well
[19:13] <pedronis> zyga: we reverted some bits related only to the tests
[19:13] <zyga> yeah, I see now
[19:14] <pedronis> zyga: afaiu only write returns EPIPE,  read would indeed return 0
[19:15] <zyga> pedronis: correct
[19:21] <jdstrand> pedronis, zyga: ok, I corrected myself and added a new comment
[19:23] <zyga> thank you
[19:25] <kenvandine> jdstrand: some of the gnome snaps are getting new app ids upstream so the dbus name is changing
[19:25] <kenvandine> jdstrand: just FYI
[19:25] <kenvandine> triggering some manual reviews
[19:26] <kenvandine> jdstrand: of interest though, the dbus name is changing in the edge channel but not in the candidate/stable channels yet
[19:27] <kenvandine> jdstrand: we have builds triggered by git commits for quite a few things now.  So master -> edge and gnome-3.30 -> candidate (promoted to stable after QA)
[19:27] <kenvandine> jdstrand: so both old and new names will need to be allowed for a bit until gnome-3.32
[19:42] <jdstrand> kenvandine: ack
[19:44] <jdstrand> kenvandine (cc willcooke): we should be looking at this too: https://gitlab.gnome.org/GNOME/glib/merge_requests/450 / https://blogs.gnome.org/mclasen/2019/01/28/whats-new-in-flatpak-1-2/ (the dconf changes)
[19:44] <jdstrand> "This will become useful with the next GLib release, when GSettings will no longer be using the dconf backend, allowing us to close an all-to-common sandbox hole"
[19:54] <kenvandine> jdstrand: interesting, not using d-conf
[19:54] <kenvandine> we want the new settings portal for sure
[19:54] <kenvandine> that will help with wayland and themes
[19:56] <jdstrand> yeah, and being able to not require gsettings forever is a good thing
[19:56] <kenvandine> yeah
[20:12] <jdstrand> roadmr: sorry, but can you queue up r1187. that has the 2.37 interfaces in it, among other things
[20:12] <roadmr> \o/ jdstrand no worries, can do
[21:29] <mvo> zyga: hey, sorry was away, we can discuss the jenkins thing tomorrow - but confined snaps have never worked for the jenkins user AFAICT, I tested this to double check with an older snapd too. only classic snaps worked and will still work with 6471 - or am I missing something?
[21:30] <zyga> mvo: that's good, let's discuss tomorrow
[21:31] <mvo> zyga: yeah, get some rest
[21:31]  * mvo is also super tired
[21:33] <mup> PR snapcraft#2460 opened: build providers: recreate instance if base changed <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2460>
[21:37] <roadmr> jdstrand: ah, can you confirm a new block-devices superprivileged interface was added between 1179 and 1187?
[21:38] <jdstrand> roadmr: it was in 1180
[21:38] <roadmr> thanks jdstrand ! It made one of my tests fail, I'll add it to our expected list. No biggie
[22:02] <jdstrand> roadmr: fyi, https://bugs.launchpad.net/snapstore/+bug/1814592 is probably pretty high priority and low hanging. may want pedronis input though
[22:03] <mup> Bug #1814592: cannot compile personal-files/system-files snap declaration constraints <Snap Store:New> <https://launchpad.net/bugs/1814592>
[22:03] <roadmr> jdstrand: ah fun, this might need an update to the assertions service which will be fun.
[22:04] <jdstrand> roadmr: not that you would do it personally, but just trying to make it visible :)
[22:04] <roadmr> jdstrand: it's a separate service fwiw, but yes, need pedronis's input on what to do
[22:04] <jdstrand> ack, thanks