[05:24] <mborzecki> morning
[05:58] <zyga> Good morning
[06:17] <mborzecki> zyga: hey
[06:23] <mborzecki> zyga: have you seen https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c3 ? my best bet is that he's running oracle linux :)
[06:29] <mborzecki> zyga: btw. this one can probably be closed https://bugzilla.redhat.com/show_bug.cgi?id=1706020 but I have no clue whether we need to do anything special to have the whole BZ/notification machinery do its thing (Pharaoh_Atem maybe?)
[06:38] <zyga> Checking
[06:42] <zyga> ha
[06:42] <zyga> that's some automaton catching up with CVEs
[06:42] <zyga> but that's all fixed for a while now
[06:43] <zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1706013 is closed already so probably nothing more needed
[06:43] <zyga> but I don't know for sure
[06:46] <zyga> mborzecki: I made spread.zygoon.pl refresh yesterday
[06:46] <zyga> mborzecki: no longer backed by my server, this time backed by CDN
[06:47] <zyga> mborzecki: I tried to make debian images by my cloud init foo was insufficient and I only recalled jdstrand's post late in the evening
[06:47] <mborzecki> zyga: nice
[06:57] <zyga> mborzecki: I learned that qemu can use qcow images that are not real images but instead contain an embedded https reference
[06:57] <zyga> mborzecki: perhaps spread could keep "embeded" images that point to spread.zygoon.pl :)
[06:58] <zyga> mborzecki: I don't know the caching story though, would depend on being usable this way
[06:59] <mborzecki> zyga: qcow can reference http? interesting
[07:02] <zyga> yeah
[07:02] <zyga> stuff we learn
[07:02] <zyga> probably full of CVEs pending ;D
[07:04] <zyga> ok, quick pass through PRs
[07:11] <pstolowski> heya
[07:12] <zyga> hejka
[07:13] <mborzecki> pstolowski: hey
[07:18] <mborzecki> only 2 pages of reviews
[07:46] <pstolowski> yay
[08:05] <mborzecki> pstolowski: added a comment https://github.com/snapcore/snapd/pull/7052#discussion_r300276495
[08:06] <mborzecki> pstolowski: in Commit() you could probably do `purgeNulls(t.pristine)` too, but maybe doing it per snap is less work in the end
[08:11] <mborzecki> heh, 17C, while last week it works 30C this time of day
[08:15] <mborzecki> heh s/works/was/
[08:16] <zyga> is mvo off today?
[08:16] <zyga> mborzecki: woow
[08:16] <zyga> envy
[08:16] <zyga> it's so hot here already
[08:16] <zyga> 28 in the morning
[08:17] <Chipaca> zyga: iirc mvo is off yes
[08:17] <Chipaca> and ijohnson
[08:17] <zyga> I dismissed his needs changes review on https://github.com/snapcore/snapd/pull/7053
[08:18] <zyga> I would love to get a 2nd review to be sure it's ok
[08:18] <zyga> the only thing I'm not sure about is the modprobe mechanism
[08:18] <zyga> where I suspect the comment is incorrect but ... we're not sure
[08:22] <Chipaca> zyga: no, you need two reviews
[08:22] <zyga> Chipaca: I said this already but https://spread.zygoon.pl/
[08:23] <zyga> Chipaca: I know, I dismissed mvo's -1 review after addressing the requests
[08:23] <Chipaca> zyga: i mean, you dismissed one of mvo's reviews, you should dismiss the other one too?
[08:23] <zyga> Chipaca: why? jamie was ok with the review :)
[08:23] <zyga> Chipaca: and mvo only commented on the commit message
[08:24] <mborzecki> is https://elixir.bootlin.com flaky for you too?
[08:24] <Chipaca> hm, fair
[08:24] <zyga> Chipaca: review it if you can, it's relatively short
[08:24] <zyga> it's just comments and two new lines
[08:24] <zyga> home and tmp
[08:24] <Chipaca> i'll try
[08:24] <zyga> mborzecki: yes
[08:24] <zyga> mborzecki: still negotiating ssl stuff
[08:24] <zyga> it's loading a little now
[08:25] <mborzecki> hmm
[08:25] <zyga> loaded
[08:25] <zyga> hey pedronis
[08:25] <zyga> pedronis: just sharing https://spread.zygoon.pl/
[08:26] <zyga> (now backed by proper CDN and stuff, not my pico-server)
[08:37] <pedronis> did I mention, did people see, this? https://forum.snapcraft.io/t/remodeling-devicectx-refactoring-and-new-test-helpers/12114
[08:38] <pedronis> Chipaca: hi, is 6878 ready for re-review?
[08:40] <Chipaca> pedronis: I didn't change the struct yet, but other than that yes
[08:40] <Chipaca> pedronis: the struct order i mean
[08:40] <pedronis> understood
[08:40] <Chipaca> that shouldn't break anything else :-)
[08:49] <Chipaca> pedronis: found another merge issue, fixing that
[08:49] <Chipaca> :-/
[08:50] <pedronis> Chipaca: ok, anyway need to look at some other PRs and forum topics first, but wanted to know if to look at it after
[08:50] <Chipaca> pedronis: ah ok
[08:50] <Chipaca> pedronis: it's no biggie, i'll have it fixed and push it and the struct reorg in no time
[08:59] <pedronis> zyga: not urgent, but I was looking at spread tests set to manual, and wondering if the test here can be reenabled now:  https://github.com/snapcore/snapd/pull/3076/files
[09:00] <zyga> oh, good catch
[09:00] <zyga> I think so
[09:00] <zyga> let's see
[09:26] <zyga> breakfast
[09:34] <mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7063
[09:41] <Chipaca> the interface-calendar-service test is rather flaky
[09:41] <Chipaca> or rather its restore
[09:56] <zyga> brb
[09:59] <Chipaca> zyga: note #7061 has two +1's
[10:00] <Chipaca> niemeyer: can you add anonymouse64 to snapd-committers?
[10:05] <zyga> mmm
[10:05] <zyga> oh indeed
[10:05] <zyga> thank you
[10:05] <zyga> I asked about this and mvo said he did add him
[10:05] <zyga> but perhaps my question was misunderstood
[10:10] <Chipaca> zyga: there's a maze of groups, all different
[10:10] <zyga> aha
[10:10] <zyga> sucky
[10:15]  * Chipaca notes it is Time For A Break, and complies
[10:24] <Eighth_Doctor> zyga: are we going to be dead in the water for Fedora 31?
[10:24] <Eighth_Doctor> with the cgroupsv2 switch
[10:25] <zyga> hopefully not, we want to support it but it's not on the roadmap as an item for us
[10:25] <zyga> perhaps pedronis can advise since he's running the  schedule with mvo
[10:37] <Chipaca> zyga: https://github.com/snapcore/snapd/pull/7062#issuecomment-508434440  http://i.imgur.com/eTic1wS.jpg
[10:38] <zyga> interesting
[10:38] <zyga> it _feel_ more like a different bug though
[10:38] <zyga> about the fact we build snapd incorrectly in testing
[10:38] <zyga> because we build it on the host
[10:38] <zyga> and  then happily stick it into 16.04 world
[10:38] <zyga> 18.04+ has some incompatibility it seems
[10:39] <zyga> the error is  /usr/lib/snapd/snap-confine: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by /usr/lib/snapd/snap-confine)
[10:39] <zyga> so...
[10:39] <zyga> it's not the test
[10:39] <zyga> it's all the tests
[10:39] <zyga> we discussed  this in the past
[10:39]  * Chipaca adds more http://i.imgur.com/eTic1wS.jpg
[10:49] <mborzecki> fedora repos are down?
[11:05] <zyga> mborzecki: dunno
[11:05] <zyga> mborzecki: small update to mountinfo-tool
[11:06] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7064
[11:08] <zyga> mborzecki: I have a  few more patches after this one
[11:08] <Chipaca> mborzecki: #7063 GTG
[11:10] <mborzecki> yay
[11:11] <Chipaca> zyga: what's the status of all the per-user mount ns work?
[11:13] <zyga> Chipaca: it's paused after MS_SHARED bug which will also include extra  new tests, this is coming off that pipeline
[11:13] <zyga> Chipaca: mountinfo-tool needs to grow a few more patches to be useful here
[11:13] <zyga> Chipaca: one of them is interesting
[11:13] <zyga> Chipaca: rest are pretty boring and obvious
[11:14] <zyga> Chipaca: (renumbering that keeps peer group IDs in sync across more than one file, so that we can test parent/slave relationship between per snap and per-user nses)
[11:14] <Chipaca> zyga: is there a reason #6341 isn't labelled with the per-user ns thing?
[11:15] <zyga> no, not really
[11:15] <zyga> perhaps it pre-dates that?
[11:15] <zyga> not sure
[11:16] <zyga> some changes are bound to come that way
[11:16] <zyga> based on the feedback I have already
[11:16] <Chipaca> mborzecki: what's blocking #6708 ?
[11:16] <zyga> but I want to properly test properties of each ns before proceeding
[11:16] <zyga> Chipaca: nobody fixed https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824384
[11:17] <Chipaca> zyga: ISTM that a lot of that work is too early to actually be reviewed
[11:17] <mborzecki> Chipaca: let me check
[11:18] <mborzecki> Chipaca: apparmor packages in ubuntu are built without -fPIE  https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824384
[11:18] <Chipaca> so much stuff is blocked or whatnot, it seems like we'd all make lousy gardeners
[11:18] <mborzecki> Chipaca: -fPIC
[11:18] <Chipaca> mborzecki: -fCAKE
[11:18] <mborzecki> Chipaca: -fLONGFLAG, as a result we can't build s-c as a (sweet-cherry)PIE binary
[11:18] <zyga> ISTM?
[11:19] <zyga> ah
[11:19] <zyga> it  seems to me
[11:19] <zyga> Chipaca: 6341?
[11:19] <Chipaca> zyga: and the rest of per-user-ns
[11:20] <mborzecki> hm mvo is off today, maybe someone else can take a look at https://github.com/snapcore/snapd/pull/7041 ?
[11:20] <zyga> I it's not early, it was ready to  be  reviewed for a long time before we realized sharing was broken, but was very slow to  review or got stuck on prerequisites. e.g. https://github.com/snapcore/snapd/pull/6347 is a chunk of  the bigger WIP  branch and the bigger WIP branch was reduced tenfold since it was first opened
[11:21] <zyga> I wish there was a "parked" label that would let us keep a PR open and not lose state but not worry reviewrs
[11:21] <zyga> *reviewers
[11:21] <Chipaca> zyga: closing it doesn't lose state though
[11:21] <zyga> yeah, except finding  it is harder
[11:22] <zyga> I can consider that if you want to run the numbers down
[11:22] <zyga> but then again https://github.com/snapcore/snapd/pull/5644 is close to its first anniversary :)
[11:24] <pedronis> mborzecki: I will look at 6939 today (have to read some things first though)
[11:24] <mborzecki> pedronis: thank you!
[11:25] <mborzecki> zyga: hm oracle linux is missing from your os-release-zoo
[11:26] <zyga> mborzecki: do we need special casing in snapd?
[11:26] <zyga> I don't recall running it ever
[11:26] <Eighth_Doctor> pedronis: https://fedoraproject.org/wiki/Changes/CGroupsV2
[11:26] <mborzecki> zyga: i'm trying to come up with possible reasons for https://bugzilla.redhat.com/show_bug.cgi?id=1726382
[11:26] <zyga> we reexec
[11:26] <zyga> and then all stuff breaks?
[11:27] <mborzecki> zyga: other than oracle linux or some old centos, or rexec (but that's off by default on non ubuntu?)
[11:27] <mborzecki> zyga: but it's snapd trying to call snap-seccomp from /usr/lib/snapd, even with reexec that path isn't baked into snapd
[11:28] <Eighth_Doctor> mborzecki: we should _never_ be attempting re-exec
[11:28] <Eighth_Doctor> unless someone broke the override
[11:29] <pedronis> Eighth_Doctor: thanks, we'll have to reevalute this, as zyga said is not in our immediate plans atm
[11:29] <mborzecki> Eighth_Doctor: i'm wondering what could possibly be the system that guy has, he's clearly getting the package from epel
[11:29] <Eighth_Doctor> pedronis: well, at least we had two years heads up...
[11:30] <Eighth_Doctor> mborzecki: right, I'm confused too because I don't have that problem on my rhel or centos systems
[11:30] <pedronis> Eighth_Doctor: is there somewhere where I can see the timeline, like when is beta freeze etc
[11:30] <Eighth_Doctor> there are a lot of CentOS derivatives though
[11:30] <Eighth_Doctor> pedronis: https://fedoraproject.org/wiki/Releases/31/Schedule
[11:31] <Eighth_Doctor> pedronis: the discussion in devel@ makes me think that there will be almost no chance it'll get reverted
[11:31] <Eighth_Doctor> all the container tools in Fedora are cgroupsv2 ready
[11:32] <mborzecki> i suppose once fedora does the switch, arch will follow
[11:32] <mborzecki> bc bleeding edge and such ;)
[11:35] <Eighth_Doctor> Yep
[11:35] <Eighth_Doctor> openSUSE will switch at the same time as well
[11:35] <Eighth_Doctor> Richard is trying to beat Fedora to "breaking everything" with a cgroups v2 switchover
[11:35] <mborzecki> hahah
[11:36] <Eighth_Doctor> my estimation is that basically all major upstream distros except Debian (well, because Debian :( ) will be switched to cgroups v2
[11:38] <zyga> Break
[11:39] <ogra> Continue
[11:45] <mborzecki> zyga: hm that --self-test makes me uneasy, but so does `mv mountinfo-tool mountinfotool.py && ln -s mountinfotool.py mountinfo-tool && python -m unittest ./mountinfotool.py`
[11:46] <zyga> Why does it make you uneasy?
[11:47] <zyga> I like it because you can copy it around as a single file
[11:47] <zyga> And it works pretty much anywhere
[11:47] <mborzecki> zyga: feels a bit off, otoh it's nice to have some tests there, so maybe if there's no other way we'll do it like you prooposed
[11:54] <pedronis> mborzecki: which PR is that ?
[11:54] <mborzecki> pedronis: https://github.com/snapcore/snapd/pull/7064/
[11:58] <pedronis> made a couple of comments about this there
[11:59] <pedronis> I'm not particurly against given the nature of the tool
[12:00] <zyga> Replied, will tweak after lunch
[12:08] <pedronis> zyga: read bzr help selftest, I stand that is not a great name for that, indeed the help is confusing, it never clarifies what these tests are
[12:24] <zyga> pedronis: I’ll gladly rename it
[12:34] <cachio> pstolowski, hey
[12:35] <pstolowski> cachio: hi, what's up?
[12:36] <cachio> pstolowski, I am debugging the test auto-refresh-retry which is failing on beta validation
[12:36] <cachio> and I see this
[12:36] <cachio> https://paste.ubuntu.com/p/g58SRvmZhZ/
[12:37] <cachio> pstolowski, it never shows "state ensure error: persistent network error"
[12:37] <pstolowski> cachio: where are you seeing this?
[12:38] <cachio> in jenkins logs
[12:39] <cachio> pstolowski, I am using a vm inside real hardware
[12:39] <cachio> to validate the image
[12:39] <cachio> beta image
[12:40] <pstolowski> cachio: and it's core 16?
[12:40] <cachio> pstolowski, yes
[12:43] <pedronis> mborzecki: sorry for noticing this late, where is the verb "position" coming from in the gadget work? is it a ubuntu-image term?
[12:45] <mborzecki> pedronis: positiona as in gadget.PositionVolume()? this one is from reviews, iirc the first version was LayoutVolume()
[12:45] <pedronis> mborzecki: because we have already layouts ?
[12:45] <pstolowski> cachio: ok, it seems that it fails much earlier at device registration (because of no network), before even reaching the logic of auto refresh that we're trying to test there
[12:45] <mborzecki> pedronis: yeah, not to confuse people
[12:46] <pedronis> mborzecki: but the new verb create messages that are to relate to
[12:46] <mborzecki> pedronis: also, the structures are named PositionedSomething, as in positioned within the volume
[12:46] <pedronis> that's what I'm noticing reading the last PRs
[12:46] <pedronis> there is no general sense of what "positiong a volume" means
[12:46] <pstolowski> cachio: is this run with no network at all?
[12:46] <pedronis> mborzecki: "cannot position volume" is a fairly obscure message
[12:46] <cachio> pstolowski, it has network
[12:47] <mborzecki> pedronis: we can go back to LayoutVolume(), then `cannot layout volume contents` or something similar
[12:47] <cachio> pstolowski, the test is executed in a vm indice a machine (real hardware)
[12:47] <cachio> like the nested suite
[12:48] <pstolowski> cachio: okay; maybe we need to wait for registration before entering network namespace in the test. i'll see. is it possible for me to run tests from my local branch there?
[12:48] <pstolowski> cachio: or can i give you a diff to try out?
[12:49] <cachio> pstolowski, sure
[12:49] <pstolowski> okay, i'll try to tweak the test a little bit
[12:50] <mborzecki> pedronis: hmm https://www.thesaurus.com/browse/lay%20out verb synonyms are even more confusing
[12:50] <pedronis> mborzecki: yes, I think  the expected verb here is "lay out"
[12:50] <pedronis> and we just have to live with the double use
[12:50] <pedronis> the context is fairly different anyway
[12:51] <mborzecki> pedronis: LayOutVolume() then? caps are different since it really stands for 'lay out'
[12:51] <pedronis> yes, or VolumeLayout (more functional)
[12:52] <pedronis> and then  s/Positioned/LayedOut/  and s/Positioning/Layout/
[12:52] <pedronis> sorry LaidOut
[12:52] <mborzecki> mhm
[12:53] <pedronis> I mean for Positioned
[12:56] <pedronis> mborzecki: anyway I commented on this also in 6939, don't know if you prefer to fix everything in master and update that one
[12:57] <pedronis> or do it after
[12:57] <pedronis> 6939 needs a 2nd review anyway ATM tough
[12:58] <mborzecki> pedronis: probably after mounted updater lands, there's fewer conflicts with each PR that lands
[12:58] <pedronis> mborzecki: anyway I have some other comments about external message terminology in 6939 (and probably previous code)
[12:59] <pedronis> that I put there
[12:59] <mborzecki> pedronis: ok, will check that, thanks!
[13:02] <pedronis> Chipaca: standup?
[13:02] <Chipaca> trying to :)
[13:35] <Chipaca> mborzecki: question, why partx instead of losetup?
[13:35] <Chipaca> mborzecki: (for after the standup)
[13:35] <Chipaca> um
[13:35] <Chipaca> mborzecki: not you
[13:35] <mborzecki> cmatsuoka: ^^
[13:35] <Chipaca> cmatsuoka: you ^ :)
[13:36] <Chipaca> silly people having same-length nicks
[13:36] <zyga> in the past losetup could not do partitions
[13:36] <zyga> perhaps kpartx just because
[13:37] <Chipaca> yes, but it can now, since 16.04 at least
[13:38] <zyga> mkcoffee ---no-sugar
[13:38] <Chipaca> oh wait, partx and kpartx are different animals
[13:38] <zyga> Chipaca: muscle memory
[13:39] <Chipaca> I don't know partx
[13:39] <Chipaca> kpartx was poison
[13:40] <cmatsuoka> Chipaca: partx was available inside the image and I used it because it was there. I don't know if losetup uses the same call or not, but we can test it
[13:41] <zyga> Chipaca: can you look at python bit
[13:41] <zyga> pretty please
[13:41] <zyga> https://github.com/snapcore/snapd/pull/7064
[13:42] <zyga> I will push two more but they depend on this test setup
[13:42] <cmatsuoka> anyway, the bio race in kernel seems to be a real bug
[13:49] <Chipaca> can somebody with an 18.04 server do an uname -r just to confirm something for me please?
[13:51] <cmatsuoka> Chipaca: 4.15.0-54-generic
[13:51] <Chipaca> cmatsuoka: thanks
[13:52] <cmatsuoka> (and my 18.04 desktop says 4.15.0-52-generic)
[13:53] <Chipaca> cmatsuoka: thanks²
[13:54] <cmatsuoka> yaw
[14:00] <pstolowski> cachio: can you grab 'snap changes' of that failing autorefresh retry test?
[14:07] <cachio> pstolowski, sure
[14:07] <pstolowski> thanks
[14:07] <cachio> pstolowski, it will take a time to run
[14:08] <pstolowski> ok
[14:19] <mborzecki> zyga: we got our answer https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c5
[14:23] <zyga> Interesting
[14:23] <zyga> Oh well
[14:23] <zyga> Needs a well made answer
[14:23] <zyga> I’m AFK with dog now
[14:36] <zyga> mborzecki: do you think the question warrants a FAQ response from us
[14:36] <zyga> mborzecki: like "we want to have one codebase, we want to support reexec, etc'
[14:57] <cachio> pstolowski, I think it is related to the model issue
[14:57] <cachio> pstolowski, because I cannot reproduce it when I run console conf and register the user
[14:58] <pstolowski> cachio: right, i thought so as you discussed that on standup
[14:58] <pstolowski> cachio: snap changes would help confirm it
[15:02] <cachio> pstolowski,  yes, I'll add that to the test
[15:02] <cachio> thanks
[15:02] <pstolowski> cachio: good idea
[15:09] <pedronis> cachio: I created the card I discussed
[15:09] <cachio> pedronis, nice, thanks
[15:16] <zyga> mborzecki: one more small review perhaps?
[15:16] <zyga> https://github.com/snapcore/snapd/commit/cbf0afae9c43716f2c9ef73b849947163769091d
[15:16] <zyga> I'll open it in a sec, just waiting for travis
[15:21] <zyga> eh portal test..
[15:35]  * cachio lunch
[16:03] <zyga> https://github.com/snapcore/snapd/pull/7065 is ready now :)
[16:03] <zyga> and now I can work on the rest, because base has landed
[16:03] <zyga> whee
[16:56] <icey> sergiusens: I don't mind you making that change in the rust PR, or I can get to it tomorrow
[17:01] <sergiusens> icey: thanks, i might do it late tonight
[17:02] <icey> I'll look before I start on it then :-)
[17:15] <zyga> https://github.com/snapcore/snapd/pull/7065 anyone?
[17:15] <zyga> sergiusens: ^ python, wanna see?
[17:25] <ogra> geez, was the store just down ??
[17:26] <ogra> (i'm just hacking on a new architecture and spent the last hour debugging because i got "error: unable to contact snap store" ... now it started working out of the blue)
[17:26] <ogra> bad timing i guess
[17:52] <ogra> ogra@pi4:~$ sudo hdparm -tT /dev/sda1
[17:52] <ogra>  Timing cached reads:   1508 MB in  2.00 seconds = 754.22 MB/sec
[17:52] <ogra>  Timing buffered disk reads: 1106 MB in  3.00 seconds = 368.64 MB/sec
[17:52] <ogra> hmm, not to bad for a pi ...
[18:49] <zyga> Wow
[18:50] <zyga> Will you have models soon?
[18:51] <ogra> you wish ... no u-boot port yet
[18:52] <ogra> i'm running classic on a USB3.1 SSD with the raspbian kernel currently
[18:54] <ogra> still ... makes a nice build machine ;)
[18:56] <bulldog68> hi am running into a problem with my application when it is snap packaged :(  , the issue is with reading the data from fifo file
[18:56] <bulldog68> https://forum.snapcraft.io/t/no-read-from-fifo-device-in-snap-packaged-app/12150/4
[18:57] <bulldog68> am getting apparmor denials when i try to read from fifo file
[18:57] <bulldog68> Uploaded file: https://uploads.kiwiirc.com/files/fd0e794c69323a8d5976f6d3a6a544c3/pasted.txt