[01:54] PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil [01:54] PR # closed: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2514, snapcraft#2518, snapcraft#2527, [01:54] snapcraft#2539, snapcraft#2544, snapcraft#2560, snapcraft#2564, snapcraft#2569, snapcraft#2570, snapcraft#2571, snapcraft#2574, snapcraft#2575, snapcraft#2576 [01:54] PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition [02:04] Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129 [02:04] PR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127 [02:05] Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129 [02:05] PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127 [02:08] PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38 [02:08] PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil [02:08] PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil [02:09] PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708, [02:09] snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, [02:09] snapd#6909, snapd#6913, snapd#6919, snapd#6922, snapd#6923, snapd#6924 [02:09] PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38 [02:09] Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129 [02:09] PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127 === iMadper is now known as iMadper|AAFFFKKK === iMadper|AAFFFKKK is now known as WhatsGoingOn [06:07] morning [06:24] zyga: when you're around, can you take a look at #6924? [06:24] PR #6924: packaging/fedora: force external linker to ensure static linking and -extldflags use [06:30] Hey [06:30] Sure [06:33] zyga: thanks [06:33] zyga: spent a while rebuilding go toolchain and sprinkling soem debug messages around the linker [06:33] zyga: actually, quite an interesting exercise [06:39] I'm sure :) [06:39] I'm thinking about taking today off [06:39] I'm not feeling very well [06:39] my back is not happy today [06:44] zyga: day off is always a good idea [06:47] ok, got some comments to address in my PRs [06:48] PR snapd#6924 closed: packaging/fedora: force external linker to ensure static linking and -extldflags use [06:48] mvo: hi, and thanks! [06:56] mborzecki: hey, good morning and thank *you* :) [06:56] mborzecki: nice fix and it unblocks another pr iirc? [06:56] mvo: yes, the one from jdstrand [06:56] mvo: about user.LookupGroup() [06:56] mborzecki: ha! two even, how nice is that :) [06:57] mvo: other distros build with PIE enabled and that's enough to trigger the use of external linker [06:58] hey mvo [06:58] I'm not feeling good, my back is acting up [06:58] I was thinking about taking that swap day today if you don't mind [07:02] zyga: sure [07:02] zyga: get well! [07:02] I'll exercise a bit more today, that usually helps === pstolowski|afk is now known as pstolowski [07:05] heyas [07:06] pstolowski: hey [07:27] PR snapd#6909 closed: spread.yaml,tests: change MATCH and REBOOT to cmds [07:28] zyga: so, are you off today? :) [07:30] pstolowski: fwiw, i keep gofmt from 1.10 around for 'changes' like you had [07:31] mborzecki: good idea, thanks [07:36] mborzecki: yeah, though I may send a patch for ! bug now that no blockers remain [07:45] PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708, [07:45] snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, [07:45] snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#6923 [07:46] PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708, [07:46] snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, [07:46] snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#6923 [07:50] https://paste.ubuntu.com/p/YhDjqdmxnK/ 'Catalog update is doing verbose http logging (it should not).' huh? [07:51] a race of some sort? [07:58] pedronis: hey, can you merge master in #6841? [07:58] PR #6841: overlord: make changes conflict with remodel [07:59] pstolowski: it's now based on 6855, that needs to go in first [08:02] ok, looking at it now [08:18] pedronis: mvo: do you think we need an experimental flag for gadget update for a while? [08:22] mborzecki: I don't think so, its up to the vendor to use it and they should know what they do (but pedronis may be of a different opinion) [08:22] mborzecki: is opt in anyway also in most cases there is no user to make that decision per machine [08:23] pedronis: mvo: sounds fair [08:24] mborzecki: if you are worried though about bugs in the opt in logic, we can have a flag for a bit [08:29] There was an unexpected problem serving your request // Please try again and contact us if the problem persists including EAC6:168A1:B024F2C:10BFCA12:5CEE42BE in your message [08:29] ^^ github OOPSing [08:29] fun fun [08:30] mvo: I was trying to add a comment to #6804: in all new code we really should be calling Context() on the *http.Request instead of adding context.TODO()s [08:30] PR #6804: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() [08:31] Chipaca: oh, thanks, let me fix this [08:32] yes, github is not having good days [08:32] PR snapd#6925 opened: devicestate: disallow removal of snaps used in booting early [08:34] Chipaca: should I still keep the todo as is or adjust? [08:34] mvo: where? [08:36] mvo: I meant: in searchStore, instead of ctx := store.WithClientUserAgent(context.TODO(), r.Header.Get("User-Agent")), do ctx := store.WithClientUserAgent(r.Context(), r.Header.Get("User-Agent")) [08:37] Chipaca: yeah [08:37] ah ok [08:37] Chipaca: I did that :) mostly wondering about the "//TODO" above [08:37] Chipaca: if that is still accurate (enough)? [08:37] mvo: heh :) [08:38] mvo: no, it's no longer accurate (if it ever was :) ) [08:38] Chipaca: glad that I asked :) [08:38] Chipaca: suggestions? or shall I simply remove it [08:38] mvo: what's 'the common layer that calls the handlers'? [08:38] maybe i'm misunderstanding something [08:39] mvo: Chipaca: notice that my proposal was ctx := store.WithClientUserAgent(r.Context(), r) [08:39] pedronis: where? [08:39] Chipaca: my signature is not what mvo implemented [08:40] ah [08:40] Chipaca: mvo: it seems my missed that Request now has Context [08:40] pedronis: mvo's is probably a lot easier to test :) [08:40] pedronis: oh, did I misread, let me double check [08:40] Chipaca: marginally [08:41] Chipaca: notice that I'm not proposing to make that thing take only Request [08:41] pedronis: indeed, silly me! [08:42] * mvo needs more tea [08:42] Chipaca: mvo: as I was saying, I missed that Request now has Context, so the my other todo is not relevant anymore for now, until there is something we would like to stick everywhere, though UA might be almost that [08:43] pedronis: cool, I will update the PR and also use your suggested signature [08:44] Chipaca: my todo was about doing something in Command.ServeHTTP [08:47] we might want to do that anyway [08:54] pedronis: ah [08:56] pedronis: I didn't know they were your TODOs :) [08:56] pedronis: you mean something like http://paste.ubuntu.com/p/sDv8YcrNBc/ ? [08:56] mvo: yes, something like that [08:56] mborzecki: https://github.com/snapcore/snapd/pull/6926 [08:56] PR #6926: tests: stop using ! for naive negation in shell scripts [08:57] PR snapd#6926 opened: tests: stop using ! for naive negation in shell scripts [08:57] mvo: then the rest of the work would teach store to take more contexts, and use r.Context more [08:57] pedronis: do you think its worth doing the above pastebin with the rest of the work? or do you think we should hold it? either way is fine for me [08:57] mvo: I don't think it's a blocker for this PR [08:58] I still think is not the best use of your time to work on this :) [08:58] pedronis: yeah, I know :( [08:58] pedronis: I stop and get to the other things [09:02] mvo: need to look quickly but this one can problably land and Chipaca can pick up ther others/from there [09:02] pedronis: yeah, that would be cool [09:29] PR snapd#6759 closed: osutil: now that we require golang-1.10, use user.LookupGroup() [09:32] yay [09:32] pstolowski: Chipaca: mvo: thank for the reviews to my remodel PR, I'll try to clean it and land it today, worst case it will happen on Monday [09:38] pedronis: yeah, its super close, its really nice to see how things fit together. given how complicated this topic is it was a joy to read [09:46] pedronis: today is eow for you? [09:47] Chipaca: yes [09:47] pedronis: nice [09:56] PR snapd#6804 closed: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() [10:02] Chipaca: so if you need something in particular to be unblocked let me know [10:10] pedronis: you self-requested a review on #6848 so if you had the time to do that it'd be nice [10:10] PR #6848: introduce healthstate, run check-health post-(install/refresh/try/revert) [10:10] that'd unblock its followup [10:11] Chipaca: it's on my list of trying to get to it today [10:14] Chipaca: worst case there's the context/snap-client-user-agent stuff to pick up [10:14] Chipaca: mvo has a couple more PRs open about that, I think there is still a bit more todo [10:14] pedronis: and cohort-in-info [10:14] Chipaca: yes, that too [10:14] pedronis: and context-in-all-the-things [10:15] :) [10:15] pedronis: i'm not going to be bereft of things to do [10:15] for the latter, it would be best if my PR landed [10:16] given it has tests/signature changes in snapstate [10:16] pstolowski: do you have PR about --startup for timings ? [10:16] noted [10:16] *a PR [10:17] PR snapcraft#2577 opened: [cli] Add --destructive-mode to clean [10:18] pedronis: oh yes i have, forgot to propose it. probably needs some small deconflicting now, will do [10:18] thanks for reminding [10:18] pstolowski: np [10:21] pstolowski: btw before 2.40 it would be good to have a forum topic with some explanation of snap debug timings and maybe example output from a pi or something [10:22] pedronis: yes, i need to repeat my test, have some old samples [10:22] thank you [10:47] mvo: https://github.com/snapcore/snapd/pull/6926 [10:47] PR #6926: tests: stop using ! for naive negation in shell scripts [10:47] and that's my contribution of the day [10:47] I'm really swapping now [10:48] PR snapd#6927 opened: release: 2.39.1 [10:51] zyga: thank you! [11:03] * pstolowski lunch [11:03] tests that look at journalctl seem to fail erratically on opensuse 15 [11:10] mvo: hey i should tell you about the things i had to do to make your "build empty package on powerpc" hack actually work :) [11:10] mvo: (mostly this https://github.com/tianon/debian-runc/commit/22d7b5c648bcac9969d6d02067b0eddcc52af4af ) [11:11] mwhudson: oh, interessting [11:12] mwhudson: you are using it (or something similar) in some other package ? [11:12] mvo: yeah, runc [11:13] mvo: i think you also need to fix the build deps [11:15] mwhudson: yeah, just noticed the ftbfs in the ppa, slightly sad about this [11:15] mwhudson: I have a look, should I apply your patches basicly? [11:16] mvo: well the things i remember are: check for build-arch as well; fix build deps [11:16] mvo: the other stuff i did was add a preinst that yelled at the user but well [11:18] mvo: the whole change to build the empty package is https://github.com/tianon/debian-runc/compare/70957b315f82170dc2ab7085d39c23835c0fa996...xenial [11:18] mwhudson: nice, thank you! I check it out and update the snapd packaging [11:19] mvo: thanks for the basic idea :) [11:19] mwhudson: my pleasure! hm, `golang-1.10-go [!powerpc]` does not work? [11:19] mvo: i think it does actually, i forgot you can do that :) [11:20] mwhudson: cool, thanks! I will give it a go [11:29] PR snapd#6928 opened: packaging: fix build-depends on powerpc [11:34] mvo, hi [11:34] hey cachio [11:34] cachio: finally, we have 2.39.1 in beta :) [11:34] mvo, yes, finally [11:34] mvo, :) [11:35] about that, changes not generated on https://people.canonical.com/~mvo/core-changes/html/beta/ [11:35] cachio: aha, yeah, I think its just slow, let me give it a gentle kick [11:35] mvo, ah, ok, tx [11:40] Chipaca: want a fun bug? :) [11:40] Chipaca: run (exactly as written) snap install go --classic --channel=12/stable [11:40] (a typo, so it presents a list of channels that do actually exist) [11:41] the list is sorted incorrectly, with 1.10 and 1.11 coming before 1.12 [11:42] Chipaca: https://paste.ubuntu.com/p/t3Z9kbpMny/ === ricab is now known as ricab|lunch [11:51] PR snapd#6929 opened: gadget: record gadget root directory used during positioning [11:52] off to pick up the car and heading home [11:52] back for standup [12:00] mvo, pedronis: what can cause settle not to converge? [12:03] zyga: where? it depends, malformed changes, too little timeout and missing EnsureBefore, tasks that retry [12:04] so, there's a test that reliably fails when I build a suse package [12:05] I added some debugging to show tasks and changes, [12:05] all changes and tasks are done: [12:05] the test is managers_test.go:3511: mgrsSuite.TestHappyDeviceRegistrationWithPrepareDeviceHook [12:06] I added this patch as otherwise debugging is pretty hard [12:06] DEBUG patch https://www.irccloud.com/pastebin/hGnLDEOP/ [12:06] when the test fails the output is: [12:06] failing test output https://www.irccloud.com/pastebin/PHXiVyeZ/ [12:09] are they clean though? [12:09] settle wait for clean too [12:09] not that I remember it should matter here [12:09] good hint, checking [12:10] also print if you hit the done clause at all [12:10] or not [12:14] pedronis: curious [12:14] none of the tasks or changes are clean [12:15] so we must be running the cleanups, correct? [12:18] looking at the debug log that contains errors from failed cleanup tasks... [12:21] doh [12:21] it's all a big fluke [12:21] GOPATH messed up [12:41] zyga: fyi, I'm not sure about jj's plans, but I got tasked on something with priority today (a USN publication) and will not be looking at the apparmor issue (or other PRs) until that is done (targetting eod today) [12:43] jdstrand: that's okay [12:43] jdstrand: note, thre's no apparmor issue [12:43] jdstrand: it was a bug in our test setup [12:43] zyga: oh, does jjohansen know that? [12:43] I said so yesterday but based on what you just said I must have been vague [12:43] jjohansen: ^ please don't look at the apparmor bug jdstrand mentioned, it's not a bug, test setup was wrong [12:44] sorry for not communicating that clearly before [12:44] zyga: maybe I was slow on the uptake but jjohansen wasn't. jjohansen, no apparmor issue ^ [12:44] pinged him just in case [12:53] PR snapd#6930 opened: tests: make more robust how we check the journal log is ready to start a test [12:58] hmmmmm [12:58] something totally bogus is going on [12:59] TestHappyDeviceRegistrationWithPrepareDeviceHook is not present in 2.39.1 [12:59] yet that test fails [12:59] something along the way is getting snapd master? [13:00] mvo: uh [13:00] mvo: 2.39.1 tarballs are wrong? [13:00] mvo: it's master, not a .1 branch [13:00] mvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in master [13:00] mvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in the 2.39.1 branch [13:00] mvo: and grep for it in the tarball! [13:00] we need a .2 [13:03] zyga: I took the tarballs down and will investigate [13:10] zyga: I have had a bit of a heart attack but it seems https://github.com/snapcore/snapd/blob/release/2.39/overlord/managers_test.go#L3511 shows that we have this TestHappyDeviceRegistrationWithPrepareDeviceHook - or are you saying things changed there? [13:11] oh my god, I'm sorry, I was on 2.*29* not 39 [13:11] so the bugs I saw are real but the tarbralls are okay [13:11] sorry for the red flag [13:12] zyga: thanks === ricab|lunch is now known as ricab [13:23] pedronis: I debugged the issue now [13:23] osc build sets a proxy and we choke on that [13:23] better debug log https://www.irccloud.com/pastebin/Pws7SmMF/ [13:24] pedronis: I read your answer about the Syncplay classic confinement [13:24] From a technical point of view, we would need access to the binary and to a TCP port on localhost from both VLC and Syncplay [13:25] Your solution would rule out mpv and all users that do not use snap VLC, though [13:30] pedronis: this is with this patch https://github.com/zyga/snapd/commit/b6e38391e35d1634375a0675e6050e8192aa2cf6 [13:38] mvo: whatever causes this I will adjust the unit tests to run in an offline network namespace [13:38] mvo: so we will not hit this by surprise the next time [13:39] zyga: thank you! [13:53] 6926 is green and needs a second review [13:55] albertosottile: hi, I understand, but I'm very reluctant to give classic to this, so we are looking at options, there is also a mpv snap I think, but is didn't reach stable yet [13:58] pedronis: we understand your concerns, and we also would like to address them [13:59] however, we invested a lot of time in preparing a snap for Syncplay and we do not see a way to avoid the use of classic confinement in a short time and/or without noticeable drawbacks... [14:08] abeato: I understand, but even if we granted classic temporarily (which is not very common), it's definitely the case that a story how to get out of that as soon as possible is valuable. We are really relucant to give classic to anything that serves outside requests, that guideline hasn't really changed/varied [14:08] sorry, albertosottile ^ [14:09] mvo: did you do something strange with 6899, I got a strange email about it, listing tons of commits [14:10] pedronis: no idea why you got an email but I did update "20" to master and updated this PR to master as well [14:10] pedronis: should be all normal in this PR again though [14:11] I see, seems github already the merge [14:11] for this case [14:11] at least in terms of email [14:11] s/already/unrolled/ [14:11] pedronis: to be honest, I did not find this guideline written somewhere in the documentation. The description of the classic confinement basically says that the app would be allowed to run as close as possible as unrestricted [14:11] pedronis: so no harm except this stange email? [14:12] I understand your concerns, but Syncplay is a seven years old software with a good user base on Linux [14:14] Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15 [14:14] PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30 [14:17] Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15 [14:17] PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30 [14:19] pedronis: would it be reasonable to expose snapstate.switchSummary (given it's dupe'd in daemon right now), and if so would that be a reasonable name for it? [14:21] PR snapcraft#2576 closed: [legacy] catkin plugin: remove default rosdistro [14:33] PR snapd#6931 opened: tests: force removal to prevent restore fails when directory doesn't exist on lp-1801955 test [14:44] Chipaca: we could but it's a bit unclear where it should live [14:49] pedronis: or I could grab it from the task :-) [14:51] mvo: https://github.com/snapcore/snapd/pull/6927 failed building the package on sid [14:51] PR #6927: release: 2.39.1 [15:04] PR snapd#6932 opened: tests: run unit tests without networking [15:11] PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil [15:11] PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil [15:11] PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition [15:12] PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil [15:12] PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil [15:12] PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition [15:13] Chipaca: did a pass on 6848 [15:15] pedronis: thanks [15:16] mvo: draft https://github.com/snapcore/snapd/pull/6932 [15:16] PR #6932: tests: run unit tests without networking [15:16] it fails, I'll see what to do about the failures [15:18] zyga: woah [15:18] zyga: nice [15:19] cmatsuoka: re uc20> I pushed a hack that should avoid the stray reboot, with that you should be unblocked for the tmpfs work [15:19] cmatsuoka: its a pr against your core-build git repo [15:29] mvo: ack, thanks! [15:32] * cachio lunc [15:32] * cachio lunch [15:50] pstolowski: looked at #6923 [15:50] PR #6923: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) [15:51] pedronis: FYI, I opened a draft PR that reproduces two unit test failures when network is isolated [15:51] zyga: thanks, at this point I will look on monday morning [15:52] thanks, hopefully by then it will be all fixed :) [15:52] pedronis: thanks! [15:54] zyga: maybe, anyway please don't hack the tests to much to fix them. At least the one you shown before should have a couple line fix [15:54] just a matter of finding the right couple lines [15:54] yeah, I'm sure that's true [15:57] actually not, the code is eager there [16:07] mmh [16:07] cmatsuoka: mostly fyi - I started with launchpad.net/snap-core20 [16:10] zyga: I commented in the PR about the 2nd [16:10] thanks! === pstolowski is now known as pstolowski|afk [16:27] Pedronis/jdstrand: Hi, I've been a core Syncplay developer since 2013. We do our best to be responsive to user feedback, and so we've been trying to add Snapcraft support in line with the requests that we have received. It'd be great if you could help make this happen so that our shared userbase who want to use Syncplay via Snapcraft can do so and I am grateful for you exploring this with my [16:27] colleague albertosottile. As far as I can see the only way to accommodate this functionality would be for Syncplay to be granted Classic status or something equivalent. Anything you can do to progress this matter would be appreciated. [16:43] jdstrand, zyga: thanks, I was down the rabbit ole on the other bug I was trying to finish first yesterday, so I didn't spend much time on this yet. [16:57] PR snapd#6933 opened: [RFC] snapd: ensure GOMAXPROCS is at least 2 === ricab is now known as ricab|bbl [17:10] mvo, hey https://paste.ubuntu.com/p/t7ZwjJzW6F/ [17:10] at some point running beta validation for i386 it starts showing errors saying [17:11] Cannot allocate memory [17:13] cachio: woah, interessting [17:13] cachio: reproducible? [17:13] yes [17:14] mvo, I ran twice the suite [17:14] both times failed with same error [17:14]