[00:09] <ijohnson> jdstrand: thanks!
[06:14] <mborzecki> morning
[06:22] <mborzecki> brb, new kernel
[06:25] <mborzecki> and back, 5.4.1
[06:25] <mup> PR snapd#7834 closed: tests: move the watchdog timeout to 2s to make the tests work in rpi <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7834>
[06:27] <mup> PR snapd#7833 closed: HACKING.md: add nvidia options to configure example <Documentation> <Simple 😃> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7833>
[06:44] <mborzecki> not sure what the purpose of tests/main/install-store-laaaarge is
[06:55] <mup> PR snapd#7743 closed: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7743>
[07:06] <zyga> mborzecki: that we don’t buffer snaps in memory perhaps?
[07:06] <zyga> Good morning
[07:06] <zyga> Still sleepy
[07:07] <zyga> Fought mould in the office late las night
[07:12] <mborzecki> zyga: ayy, not good, make sure to remove all of it
[07:30] <zyga> good morning mvo
[07:31] <mvo> hey zyga
[07:36] <mborzecki> mvo: hey
[07:37] <mvo> mborzecki: good morning!
[07:42] <mborzecki> ok, off to the bank, back ~12 hopefully
[07:43]  * zyga jumps into https://github.com/snapcore/snapd/pull/7825
[07:43] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[08:02] <pstolowski> morning
[09:03] <sdhd-sascha> Hello,
[09:03] <zyga> hey
[09:03] <sdhd-sascha> :-)
[09:03] <sdhd-sascha> on 19.04, when i run the test-suit, i get:
[09:03] <zyga> so, snap run --explain, there's a small twist in I/O sync across all the interacting programs
[09:03] <sdhd-sascha> -               {"", time.Time{}},                           // zero time default
[09:03] <sdhd-sascha> +               {"", time.Time{}}, // zero time default
[09:03] <zyga> need to think how to make that all work cleanly
[09:03] <sdhd-sascha> in the formattting test
[09:04] <zyga> sdhd-sascha: ignore it, it's busted
[09:04] <zyga> sdhd-sascha: we format with a fixed gofmt version
[09:04] <zyga> sdhd-sascha: unless you happen to have that it will always differ
[09:04] <sdhd-sascha> well, on 18.04 it works and go's on...
[09:04] <sdhd-sascha> is there a workaround
[09:06] <zyga> format with that version
[09:06] <sdhd-sascha> On 18.04, it ./run-checks stops, with  "Crushing failure and despair."
[09:06] <zyga> you can install it as a snap :)
[09:06] <zyga> yeah, it's silly
[09:06] <zyga> mvo: ^
[09:06] <sdhd-sascha> i installed go as snap
[09:07] <Chipaca> sdhd-sascha: just run the unit tests? ./run-checks --unit
[09:08] <sdhd-sascha> :-) i will
[09:08] <sdhd-sascha> What gofmt version i should install ?
[09:11] <zyga> brb, I'm starving
[09:20] <Chipaca> sdhd-sascha: try SKIP_GOFMT=1 ./run-checks
[09:21] <Chipaca> sdhd-sascha: i think it's the gofmt from go 1.10 but i might be wrong on this
[09:21] <Chipaca> sdhd-sascha: if you're running go from a snap, snap refresh --channel=1.10 go
[09:22] <sdhd-sascha> Chipaca: SKIP_GOFMT works. I need this, because in the night i have to shutdown my noisy server ;-) thanks
[09:27] <Chipaca> noisy stuff in the home needs to die
[09:39] <sdhd-sascha> Chipaca: right
[09:45] <pedronis> mvo: what UC20 bits need reviewing?
[09:45] <sdhd-sascha> What is best pratice? Build and install master branch? Is master mostly compatible with snapcraft store, or test this seperatly ?
[09:46] <zyga> sdhd-sascha: master is compatible with the store
[09:46] <zyga> sdhd-sascha: we take backwards compatibility seriously
[09:47]  * zyga breaks branch iteration to review stuff for 2.34
[09:47] <zyga> 43 even
[09:47] <mvo> pedronis: 7831 should be ready, 7832 too, I'm just adding a spread test
[09:56] <pedronis> mvo: 7831 has two +1
[10:00] <mup> PR snapd#7831 closed: gadget: extract and export new DiskFromPartition() helper <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7831>
[10:10] <mvo> pedronis: thanks, merged and I updated 7832 against master plus it has a spread test now
[10:10] <mvo> pedronis: that should unblock 7762 :)
[10:36] <zyga> pedronis: reviewed https://github.com/snapcore/snapd/pull/7228#pullrequestreview-326719099
[10:36] <mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
[10:36] <zyga> pstolowski: about your work on the label bug
[10:37] <zyga> pstolowski: do you think we can chop it into parts so that the several bugs this uncovered can be addressed in isolation
[10:37] <pedronis> mvo: it's Ubuntu Core not Ubuntucore, so UC not Uc
[10:37] <pstolowski> zyga: i think so yes, nb i think i see the issue, just trying a tentative fix
[10:37] <zyga> oh, while are are at naming, why do we have Grubenv and not GrubEnv
[10:37] <zyga> it's rubbing salt into my eyes
[10:37] <mvo> pedronis: thank you, I keep this in mind
[10:37] <zyga> pstolowski: super, thank you for taking this
[10:38] <pedronis> mvo: thanks, not the most important thing in the world but well
[10:38] <mvo> pedronis: yeah, we should be consistent!
[10:41] <pedronis> mvo: is that right that cmd/snap-bootstrap/bootstrap is mostly tested via spread?
[10:52] <zyga> they are shooting an episode next door again
[10:54] <zyga> mvo: https://github.com/snapcore/snapd/pull/7832#pullrequestreview-326757177
[10:54] <mup> PR #7832: snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>
[11:05] <mvo> zyga: thank you, looking
[11:05] <mvo> (was in a meeting)
[11:05] <zyga> no worries
[11:08] <pstolowski> zyga: ok, wrt to the label issue.. another problem confirmed and fix works, it's implicit stuff biting again
[11:09] <pstolowski> zyga: we bind implicit hooks when reading the yaml, but implicit slots arrive later to the picture :/
[11:10] <pstolowski> we should probably tear all that apart and redo at some point, but this needs a good plan
[11:22] <zyga> pstolowski: as expected the, no disagreement there
[11:23] <zyga> short coffee break
[11:24] <zyga> it's not so cold today somehow
[11:40] <zyga> back
[11:44] <mup> PR snapd#7835 opened: gadget: add missing test for duplicate detection of roles <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7835>
[11:55] <cachio> mvo, hey
[11:55] <mvo> hey cachio
[11:56] <cachio> did you fix the test uc20-snap-recovery ?
[11:56] <cachio> in the last PR merged?
[11:59] <cachio> mvo, I see the tests passed during last execution on travis
[11:59] <cachio> but I see it is failing on master when I execute it
[11:59] <mup> PR snapd#7836 opened: o/ifacestate: fix binding of implicit hooks to implicit slots on core snap <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7836>
[12:01] <pstolowski> zyga: ^
[12:01] <zyga> nnn
[12:02] <mvo> cachio: it seems racy
[12:02] <mvo> cachio: it's strange, I wonder what broke it
[12:03] <mvo> cachio: do you know when it started failing?
[12:03] <cachio> mvo, yesterday the bionic image was updated
[12:03] <cachio> perhaps something new is breaking it
[12:04] <cachio> I ran the tests yesterday for the new image and that test passed
[12:04] <mvo> cachio: there are also changes in the sfdisk code
[12:05] <mvo> cachio: 7743 landed
[12:05] <mvo> cachio: and after that I see an error on master and I also seen an error in my own stuff - but not in qemu so far (but only ran twice). runing on google now
[12:06] <cachio> mvo, nice
[12:06] <mvo> looks like we also need to improve the error, i.e. what exactly is not compatible
[12:06] <cachio> mvo, hehe, I'll try to reproduce the error using the previous image
[12:06] <cachio> so if I'm able to do it the problem should be in the code
[12:07]  * Chipaca needs to lie down for a while
[12:09] <zyga> pstolowski: reviewed
[12:10] <pstolowski> zyga: thank you; please also see my comment under 1st PR
[12:10] <zyga> ack
[12:11] <mvo> cachio: thanks!
[12:12] <pstolowski> zyga: as touched briefly yesterday, remaining 3rd issue is peer=snap.core.configure now generated for e.g. modem-manager plug on classic
[12:14] <sdhd-sascha> hey, can i ask a off-topic question? i want to forward a unix-domain socket via ssh & netcat. With "ssh <host> -- nc -q0 -U </path/to/socket>" i got a connection.
[12:15] <sdhd-sascha> But now my application needs a socket-filename
[12:15] <sdhd-sascha> i want with emacsclient securly connect to server (tramp plugin didn't work like expected...)
[12:16] <sdhd-sascha> :-)
[12:23] <pedronis> pstolowski: do we really need to bind hooks fore core, given that the only hook there is hijacked anyway?
[12:25] <mvo> cmatsuoka: hey, good morning
[12:25] <pedronis> pstolowski: I'm basically wondering whether we can cut/simplify somehow differently this area
[12:25] <cachio> mvo, the test fails with the old image as well
[12:26] <mvo> cmatsuoka: "fun" - right now master is unhappy, it looks like 7743 sometimes works and sometimes does not.
[12:26] <mvo> cmatsuoka: it looks like adding "blockdev --rereadpt" fixes it
[12:26] <mvo> cmatsuoka: well, "fixes"
[12:26] <mvo> cmatsuoka: I wonder if we need our own code afterall :/
[12:26] <pstolowski> pedronis: if we don't then label generation would need some other logic / special casing for core i think (for the reference - #7830)
[12:26] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
[12:27] <cmatsuoka> mvo: is it failing on the gadget vs device  consistency checking?
[12:27] <pedronis> pstolowski: I would like us to explore that
[12:27] <pedronis> pstolowski: it's a bit silly to generate profiles for something we never run
[12:27] <pedronis> core is anyway special cases in various ways
[12:28] <pedronis> but I might be missing something
[12:29] <mup> PR snapd#7837 opened: devicestate: implement creating partitions in "install" mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/7837>
[12:29] <mvo> cmatsuoka: yeah
[12:29] <mvo> cmatsuoka: exactly the issue you describe in the gdoc
[12:29] <mvo> cmatsuoka: seems to break master right now :(
[12:30] <mvo> cmatsuoka: do you think you could try just adding "blockdev --rereadpt" as a workaround?
[12:30] <mvo> cmatsuoka: need to get lunch in a wee bit but would love to have someone look at this while I'm away :)
[12:30] <cmatsuoka> mvo: yes, at which point you tried this rereadpt?
[12:31] <cmatsuoka> mvo: the error pattern is very odd, last night I couldn't reproduce it anymore after ~10PM UTC
[12:32] <pstolowski> pedronis: okay, i need to take a step back, and clear my mind. but lunch first
[12:33] <mvo> cmatsuoka: fun! I can reproduce it in gce
[12:33] <pedronis> pstolowski: ok, we ignored the silly work because it didn't have consequences so far, but if it starts to give trouble we need to consider
[12:33] <mvo> cmatsuoka: but not in qemu
[12:33] <mvo> cmatsuoka: I see it in my PR everytime in gce and also when running manually I hit it right away
[12:34] <mvo> cmatsuoka: I did run "blockdev --rereadpt" after the failure manually i nthe shell and suddently things went away
[12:34] <mvo> cmatsuoka: thanks for looking into this, if you have further question please use tg, I will go to lunch now
[12:34] <mvo> cmatsuoka: but happy to help as good as I can
[12:35] <cmatsuoka> mvo: where did you insert the blockdev that fixes the problem? (I'm afraid it's more like it's disturbing the system enough to make a racy situation work again)
[12:35] <mvo> cmatsuoka: after the test failed I just ran it manually in a shelll
[12:36] <mvo> cmatsuoka: which is obviously not that great of an answer
[12:36]  * mvo really is away now
[12:39]  * cmatsuoka earns the "breaking master" badge 😱
[12:40] <mup> PR snapcraft#2829 closed: store cli: push title and license on push-metadata <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2829>
[12:53] <mup> PR snapd#7838 opened: cmd/snap-bootstrap: stub out snap.SanitizePlugsSlots for real <Bug> <Simple 😃> <UC20> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7838>
[12:54]  * Chipaca _really_ needs to lie down for a while, now
[13:08] <mup> PR snapd#7839 opened: tests: prevent partitioning test errors <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7839>
[13:24] <cmatsuoka> mvo: issued a quick workaround atempt, but also working on a more definitive solution that drops lsblk entirely and uses blkid instead
[13:27] <pedronis> mvo: I removed the 2.43 milestone from snap run --explain, seems a bit unlikely to make it
[13:37] <zyga> pedronis: I just pushed an update there
[13:37] <zyga> with spread tests and more things that it does
[13:37] <zyga> but it can be added in later if you feel like it's not ready
[13:38] <pedronis> zyga: for one it needs a jdstrand review, 2nd it needs careful review of each output line
[13:39] <zyga> pedronis: https://github.com/snapcore/snapd/pull/7728/files#diff-771e057220c48a44a34166289f5339f4R1 is the starting point
[13:39] <mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
[13:41] <zyga> we can tweak it all the way we want but I think, since it's not meant to be parsed by machines, it should go in after jdstrand's review
[13:42] <pedronis> zyga: ?
[13:42] <zyga> I'm saying we should not go over the output with a fine comb and not ship it
[13:42] <pedronis> zyga: machine parsing is not my worry here
[13:42] <zyga> we should ship it and improve it after people use it
[13:44] <pedronis> zyga: we should start from a good place, atm the are open questions and the output formatting not very consistent
[13:44] <zyga> pedronis: open questions?
[13:44] <zyga> pedronis: what is not consistent?
[13:45] <pedronis> zyga: the usage of colons for once
[13:45] <zyga> pedronis: what about it?
[13:45] <zyga> honestly, that's the last thing anyone using this for real will care about
[13:46] <zyga> but I don't think it's inconsistent now, maybe you are looking at the older version
[13:46] <pedronis> zyga: maybe, it needs review either way
[13:46] <zyga> that's true
[13:46] <pedronis> from me
[13:47] <zyga> I'd just hate to blow it out of proportion as to what it  needs to be - it's a tool, not a designer hat; it's good to ship it if it's 80% there and can benefit someone
[13:49] <pedronis> not more than any other snapd output
[13:49] <pedronis> anyway jdstrand review is still the main blocker atm
[13:51] <pedronis> zyga: the open questions is the remark Maciej made about separator, and also how that matches or not the original sketch plan
[13:52] <zyga> pedronis: the separator probably cannot be used if we want wrappers and other layer to handle explain-like output
[13:53] <zyga> pedronis: because while there's a clear start, there is no clear end
[13:53] <pedronis> zyga: I agree but the last output had still missing bits vs the original sketch
[13:53] <pedronis> not sure if your last pass fixed this or not
[13:53] <zyga> pedronis: I didn't check it against the sketch but I think the sketch is just that, there are TODOs to add more things based on what snap run really does
[13:54] <zyga> pedronis: I'll double check what's going on in the code and if there's something to add based on the original sketch
[13:54] <pedronis> zyga: yes, but the sketch has a separator just before the start of the app command itself
[13:54] <zyga> pedronis: but my point is that it's meant to be realistic, not idealistic
[13:54] <pedronis> which partly addressed Maciej worry
[13:54] <pedronis> addresses
[13:55] <pedronis> anyway my point stand that still need a proper review after jdstrand one
[13:55] <zyga> s/after// but yeah
[13:55] <zyga> I think we don't need to wait for jamie
[13:55] <jdstrand> you touch snap-confine
[13:56] <jdstrand> I'd like to review at least those bits
[13:56] <pedronis> zyga: well I plan to wait, given I have also other things
[13:56] <zyga> not wait for the other review
[13:58] <pedronis> zyga: I suppose I could to a quick pass over the output in the spread test when I have a moment
[13:58] <zyga> thanks!
[13:58] <zyga> I can quickly adjust it after initial output review
[14:00] <pedronis> is the output up-to-date ATM in tha test?
[14:00] <zyga> yes
[14:00] <pedronis> ok, thx
[14:02] <zyga> cannot join standup
[14:02] <zyga> sorry
[14:02] <zyga> I'll join when I xan
[14:26] <zyga> oh my
[14:26] <zyga> sorry guys
[14:26] <zyga> chrome love
[14:30] <pedronis> mvo: there is, snap find mumble
[14:30] <pstolowski> heh
[14:30] <pstolowski> jdstrand: hey, question about modem-manager interface
[14:31] <jdstrand> ok
[14:31] <pedronis> mvo: ijohnson: can we do it 30 mins before standup tomorrow?
[14:31] <jdstrand> that interface is pretty ancient
[14:31] <ijohnson> pedronis: mvo: yes that's fine for me
[14:33] <pstolowski> jdstrand: is this intended that AppArmorConnectedPlug always adds modemManagerConnectedPlugAppArmor snippet, and on classic in addition appends modemManagerConnectedPlugAppArmorClassic ? should there be if classic - else core?
[14:36] <jdstrand> pstolowski: I'm looking at it
[14:38] <pstolowski> jdstrand: that extra snippet gets label=snap.core.* on classic in the generated profile
[14:40] <jdstrand> pstolowski: so, like I said, this interface is ancient and doesn't benefit from the moderm thinking around app snaps, classic, etc. looking at it, if you install the snap on a classic system, you get a weird peer=(label="snap.core.*") rule
[14:42] <jdstrand> pstolowski: iirc, on or the other was tacked on later with the understanding that "you're not expected to install the modem-manager snap on a core system"
[14:42] <jdstrand> but, we've handled this better lately
[14:42] <jdstrand> pstolowski: eg, in avahi-control
[14:44] <jdstrand> pstolowski: PermanentSlot and ConnectedSlot could also be updated
[14:45] <jdstrand> pstolowski: basically, it and most likely bluez and network-manager would likely benefit from being updated to model after avahi-control. though, still, "you're not expected to install the * snap on a core system" with all of these :)
[14:46] <ijohnson> jdstrand: but you are definitely expected to install the network-manager and bluez snap on UC?
[14:46] <jdstrand> erf
[14:46] <mvo> pedronis, ijohnson sure, let me schedule something
[14:46] <ijohnson> and modem-manager snap too actually
[14:46] <jdstrand> s/core/slassic/
[14:46] <jdstrand> classic*
[14:46] <ijohnson> ahhh yes that makes much more sense +1
[14:46] <jdstrand> ijohnson: I totally typoed that :)
[14:46] <jdstrand> pstolowski: ^
[14:47] <ijohnson> it's still early :-)
[14:47] <jdstrand> pstolowski: is this something you are thinking of fixing or should I add it to the list for the next batch of updates?
[14:47] <jdstrand> ijohnson: not sure you saw, but nice job on the lib caching forum topic :)
[14:48] <ijohnson> I think I did see, but thanks again :-)
[14:48] <jdstrand> :)
[14:49] <pstolowski> jdstrand: no, at least not now; it just popped because of this weird label (in one of the spread tests), which becomes even more weird with my #7830
[14:49] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
[14:50] <jdstrand> pstolowski: ack, I'll add it to my list then
[14:51] <pstolowski> jdstrand: i though a simple if-classic-else-core in modem manager would do it, but sounds like you envison to streamline it more
[14:51] <pstolowski> *thought
[14:51] <pstolowski> jdstrand: thanks, and thanks for explaining
[14:52] <jdstrand> np
[14:52] <jdstrand> yeah, they just need updating. they're a bit crufty
[14:56] <pedronis> mvo: thx, I see it in your cal but not mine
[14:58] <mvo> pedronis: yeah, sorry, was wondering if we should just use the 4:30 slot I have with ian tomorrow anyway - this would mean that ian does not have to get quite so early
[14:58] <mvo> pedronis: or the 5pm slot
[14:58] <mup> PR snapd#7733 closed: tests: disable nova from install-snaps test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7733>
[14:58] <mvo> pedronis: after the certbot meeting
[14:59] <pedronis> mvo: well the first slot overlaps with the certbot one, after the cerbot is fine with me if it works for you
[15:00] <mvo> pedronis: I would have to skip/move one meeting
[15:00] <ijohnson> mvo: it's ok, it's not too early
[15:00] <pedronis> mvo: no strong preference, except I think I need to be at the certbot meeting
[15:01] <zyga> brb, lunch
[15:01] <zyga> (late)
[15:18] <mvo> ijohnson: it could either be 30min before the meeting or 2h later
[15:18] <ijohnson> mvo: whatever is most convenient for you, I don't have any other meetings except our 1:1 and the SU and it's only 7:30 so that's doable for me
[15:28] <zyga> Lunch over but I’m looking after Lucy now
[15:29] <zyga> I will return in about an hour
[15:39]  * cachio lunch
[15:58] <zyga> re
[16:03] <mup> PR snapd#7838 closed: cmd/snap-bootstrap: stub out snap.SanitizePlugsSlots for real <Bug> <Simple 😃> <UC20> <⚠ Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7838>
[16:04] <Chipaca> xnox: ^
[16:18] <pedronis> ijohnson: thanks for the review
[16:18] <jdstrand> mvo, pedronis: hey, fyi, zyga gave his approval on PR 7228 and I incorporated his feedback. He said to feel free to merge, but I wasn't sure if that meant after another +1 or right away. I think there is a question in my mind since this PRs only adds spread tests and doesn't touch code, and not sure if 2 approvals is required for that
[16:18] <ijohnson> pedronis: np
[16:18] <mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
[16:19] <pedronis> ijohnson: about the confusing code, it copied and just slightly modified from some code where the error can happen or not
[16:19] <jdstrand> (in any case, obviously I'll what for the tests to pass)
[16:19] <pedronis> but I agree is confusing if the error is expected
[16:19] <pedronis> jdstrand: let me look
[16:20] <ijohnson> pedronis: yeah that's kinda what I thought but still seems like either a comment explaining that or not doing it that way would be good, because I could see myself needing to write a similar test and taking this one as a template and then being very confused about why it was written this way
[16:21] <pedronis> jdstrand: you probably want a 2nd review from some of the people that looked at it already, doesn't need to be me tough
[16:22] <jdstrand> pedronis: ok
[16:23] <pedronis> I actually didn't look at it, just did a meta-comment at some point
[16:24] <zyga> jdstrand: I meant "from my pov it is ok" but I don't think I have the power to merge with one review
[16:25] <jdstrand> that's fine
[16:25]  * zyga fights snap security tag hydra
[16:25] <jdstrand> I didn't want to assign anyone to review it, so I asked in a comment if Ian or Maciej wants to do it
[16:29] <ijohnson> jdstrand: I can take a look today probably
[16:30] <jdstrand> ijohnson: thanks. it is only as urgent as cleaning out old PRs is
[16:30] <ijohnson> ack
[16:32] <zyga> jdstrand: merge master into it if you haven't done that recently please
[16:34] <cmatsuoka> mvo: the empty filesystem bug seems to be a race involving node creation and the udev event queue, I'll test a queue flush after partitioning and before creating the filesystems
[16:35] <jdstrand> zyga: yep, already done
[16:35] <jdstrand> I learned from last time
[16:35] <zyga> super, just wanted to double check after recent old-branch-post-merge-fixups
[16:35] <zyga> :)
[16:36] <zyga> I think we all learned, it's a shame CI is too costly to run on each master change
[16:39] <mup> PR snapd#7826 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 1 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826>
[16:41] <mup> PR snapd#7840 opened: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7840>
[16:46] <mvo> cmatsuoka: cool, thanks for digging into this
[17:22] <jdstrand> ijohnson and bloodearnest: fyi, https://github.com/sergiusens/snapcraft-preload/pull/39
[17:22] <mup> PR sergiusens/snapcraft-preload#39: preload.cpp: use setgroups()/initgroups() in sandbox-compliant manner <Created by jdstrand> <https://github.com/sergiusens/snapcraft-preload/pull/39>
[17:22] <ijohnson> \o/ yay thanks jdstrand
[17:32] <zyga> I feel cold getting me
[17:32] <zyga> Need a break
[17:32] <zyga> Sleepy
[17:56] <mup> PR snapcraft#2830 opened: elf: properly handle corrupted ELF files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2830>
[18:29] <mup> PR snapcraft#2828 closed: Appstream <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828>
[18:44] <mup> PR snapcraft#2831 opened: appstream extractor: add support for code <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2831>
[18:45] <zyga> cold meds are working so I'm back
[18:45] <zyga> wondering how to proceed with snap security tag validation
[18:45] <zyga> security tag are super diverse
[18:45] <zyga> and it feels like something to make tidy now
[18:49] <mup> PR snapd#7839 closed: tests: prevent partitioning test errors <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7839>
[19:39] <mup> PR snapd#7841 opened: tests: fix partitioning test debug message <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>
[20:02] <cmatsuoka> cachio: PR #7841 fixes a silly shell error in the previous PR
[20:02] <mup> PR #7841: tests: fix partitioning test debug message <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>
[20:04] <cachio> cmatsuoka, taking a look
[20:05] <cmatsuoka> cachio: when the udev fstype error happens, grep fails and the test was aborted
[20:05] <cachio> cmatsuoka, ah, ok
[20:05] <cachio> thanks for the explanation
[20:05] <cachio> +1
[20:07] <cmatsuoka> cachio: I was expecting ID_FS_TYPE to be there with an empty value when it fails, but in fact the key is not listed
[20:08] <cachio> cmatsuoka, nice, thanks for the fix
[20:08] <ackk> mvo, hi around?
[20:11] <cmatsuoka> cachio: sorry for the basic error in the first attempt
[20:11] <mup> PR snapd#7842 opened: tests: cache snaps also for ubuntu core and add new snaps to cache <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7842>
[20:12] <cachio> cmatsuoka, no problem, this happens often
[20:13] <mvo> ackk: a bit, it's rather late already - what can I do for you :) ?
[20:13] <ackk> mvo, sorry, just checking if https://bugs.launchpad.net/snapd/+bug/1817276 is supposed to be fixed in 2.42.1+18.04 (deb package in bionic)
[20:14] <mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
[20:14] <mvo> ackk: that's correct, it should be much better with this version
[20:14] <mvo> ackk: I think I got one positive report already
[20:14] <ackk> mvo, I still see it use 100% cpu at times
[20:14] <mvo> ackk: is it not helping for you :/ ?
[20:14] <ackk> mvo, well it's better for sure
[20:15] <ackk> but I guess under heavy I/O cpu usage is expected?
[20:15] <mvo> ackk: yes - ish - I mean, if it's still not good enough we need to talk again. the performance should be in the order of 10x better than before
[20:16] <ackk> mvo, yeah it's definitely much better. I wasn't sure if it was supposed to be entirely gone
[20:16] <ackk> mvo, anyway, thanks for the info, don't let me keep you :)
[20:17] <mvo> ackk: aha, right. it's still fuse currently so a certain degree of slowness is expected unfortunately
[20:17] <mvo> ackk: but again - if it's a problem we could talk about options (which would be hackish at this point :(
[20:17] <mvo> ackk: but let's do this tomorrow :)
[20:17] <ackk> mvo, I haven't tested it extensively, yet
[20:18] <ackk> mvo, yeah, good night, thanks again :)
[20:19] <mup> PR snapd#7843 opened: tests/cmd/snapctl: unset SNAP_CONTEXT for the suite <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7843>
[20:19] <mvo> ackk: my pleasure - good night to you too!
[23:03] <mup> PR snapd#7841 closed: tests: fix partitioning test debug message <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>