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