ijohnsonjdstrand: thanks!00:09
mborzeckibrb, new kernel06:22
mborzeckiand back, 5.4.106:25
mupPR 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:25
mupPR 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:27
mborzeckinot sure what the purpose of tests/main/install-store-laaaarge is06:44
mupPR snapd#7743 closed: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7743>06:55
zygamborzecki: that we don’t buffer snaps in memory perhaps?07:06
zygaGood morning07:06
zygaStill sleepy07:06
zygaFought mould in the office late las night07:07
mborzeckizyga: ayy, not good, make sure to remove all of it07:12
zygagood morning mvo07:30
mvohey zyga07:31
mborzeckimvo: hey07:36
mvomborzecki: good morning!07:37
mborzeckiok, off to the bank, back ~12 hopefully07:42
* zyga jumps into https://github.com/snapcore/snapd/pull/782507:43
mupPR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>07:43
sdhd-saschaon 19.04, when i run the test-suit, i get:09:03
zygaso, snap run --explain, there's a small twist in I/O sync across all the interacting programs09:03
sdhd-sascha-               {"", time.Time{}},                           // zero time default09:03
sdhd-sascha+               {"", time.Time{}}, // zero time default09:03
zyganeed to think how to make that all work cleanly09:03
sdhd-saschain the formattting test09:03
zygasdhd-sascha: ignore it, it's busted09:04
zygasdhd-sascha: we format with a fixed gofmt version09:04
zygasdhd-sascha: unless you happen to have that it will always differ09:04
sdhd-saschawell, on 18.04 it works and go's on...09:04
sdhd-saschais there a workaround09:04
zygaformat with that version09:06
sdhd-saschaOn 18.04, it ./run-checks stops, with  "Crushing failure and despair."09:06
zygayou can install it as a snap :)09:06
zygayeah, it's silly09:06
zygamvo: ^09:06
sdhd-saschai installed go as snap09:06
Chipacasdhd-sascha: just run the unit tests? ./run-checks --unit09:07
sdhd-sascha:-) i will09:08
sdhd-saschaWhat gofmt version i should install ?09:08
zygabrb, I'm starving09:11
Chipacasdhd-sascha: try SKIP_GOFMT=1 ./run-checks09:20
Chipacasdhd-sascha: i think it's the gofmt from go 1.10 but i might be wrong on this09:21
Chipacasdhd-sascha: if you're running go from a snap, snap refresh --channel=1.10 go09:21
sdhd-saschaChipaca: SKIP_GOFMT works. I need this, because in the night i have to shutdown my noisy server ;-) thanks09:22
Chipacanoisy stuff in the home needs to die09:27
sdhd-saschaChipaca: right09:39
pedronismvo: what UC20 bits need reviewing?09:45
sdhd-saschaWhat is best pratice? Build and install master branch? Is master mostly compatible with snapcraft store, or test this seperatly ?09:45
zygasdhd-sascha: master is compatible with the store09:46
zygasdhd-sascha: we take backwards compatibility seriously09:46
* zyga breaks branch iteration to review stuff for 2.3409:47
zyga43 even09:47
mvopedronis: 7831 should be ready, 7832 too, I'm just adding a spread test09:47
pedronismvo: 7831 has two +109:56
mupPR 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:00
mvopedronis: thanks, merged and I updated 7832 against master plus it has a spread test now10:10
mvopedronis: that should unblock 7762 :)10:10
zygapedronis: reviewed https://github.com/snapcore/snapd/pull/7228#pullrequestreview-32671909910:36
mupPR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>10:36
zygapstolowski: about your work on the label bug10:36
zygapstolowski: do you think we can chop it into parts so that the several bugs this uncovered can be addressed in isolation10:37
pedronismvo: it's Ubuntu Core not Ubuntucore, so UC not Uc10:37
pstolowskizyga: i think so yes, nb i think i see the issue, just trying a tentative fix10:37
zygaoh, while are are at naming, why do we have Grubenv and not GrubEnv10:37
zygait's rubbing salt into my eyes10:37
mvopedronis: thank you, I keep this in mind10:37
zygapstolowski: super, thank you for taking this10:37
pedronismvo: thanks, not the most important thing in the world but well10:38
mvopedronis: yeah, we should be consistent!10:38
pedronismvo: is that right that cmd/snap-bootstrap/bootstrap is mostly tested via spread?10:41
zygathey are shooting an episode next door again10:52
zygamvo: https://github.com/snapcore/snapd/pull/7832#pullrequestreview-32675717710:54
mupPR #7832: snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>10:54
mvozyga: thank you, looking11:05
mvo(was in a meeting)11:05
zygano worries11:05
pstolowskizyga: ok, wrt to the label issue.. another problem confirmed and fix works, it's implicit stuff biting again11:08
pstolowskizyga: we bind implicit hooks when reading the yaml, but implicit slots arrive later to the picture :/11:09
pstolowskiwe should probably tear all that apart and redo at some point, but this needs a good plan11:10
zygapstolowski: as expected the, no disagreement there11:22
zygashort coffee break11:23
zygait's not so cold today somehow11:24
mupPR snapd#7835 opened: gadget: add missing test for duplicate detection of roles <Simple πŸ˜ƒ> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7835>11:44
cachiomvo, hey11:55
mvohey cachio11:55
cachiodid you fix the test uc20-snap-recovery ?11:56
cachioin the last PR merged?11:56
cachiomvo, I see the tests passed during last execution on travis11:59
cachiobut I see it is failing on master when I execute it11:59
mupPR 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>11:59
pstolowskizyga: ^12:01
mvocachio: it seems racy12:02
mvocachio: it's strange, I wonder what broke it12:02
mvocachio: do you know when it started failing?12:03
cachiomvo, yesterday the bionic image was updated12:03
cachioperhaps something new is breaking it12:03
cachioI ran the tests yesterday for the new image and that test passed12:04
mvocachio: there are also changes in the sfdisk code12:04
mvocachio: 7743 landed12:05
mvocachio: 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 now12:05
cachiomvo, nice12:06
mvolooks like we also need to improve the error, i.e. what exactly is not compatible12:06
cachiomvo, hehe, I'll try to reproduce the error using the previous image12:06
cachioso if I'm able to do it the problem should be in the code12:06
* Chipaca needs to lie down for a while12:07
zygapstolowski: reviewed12:09
pstolowskizyga: thank you; please also see my comment under 1st PR12:10
mvocachio: thanks!12:11
pstolowskizyga: as touched briefly yesterday, remaining 3rd issue is peer=snap.core.configure now generated for e.g. modem-manager plug on classic12:12
sdhd-saschahey, 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:14
sdhd-saschaBut now my application needs a socket-filename12:15
sdhd-saschai want with emacsclient securly connect to server (tramp plugin didn't work like expected...)12:15
pedronispstolowski: do we really need to bind hooks fore core, given that the only hook there is hijacked anyway?12:23
mvocmatsuoka: hey, good morning12:25
pedronispstolowski: I'm basically wondering whether we can cut/simplify somehow differently this area12:25
cachiomvo, the test fails with the old image as well12:25
mvocmatsuoka: "fun" - right now master is unhappy, it looks like 7743 sometimes works and sometimes does not.12:26
mvocmatsuoka: it looks like adding "blockdev --rereadpt" fixes it12:26
mvocmatsuoka: well, "fixes"12:26
mvocmatsuoka: I wonder if we need our own code afterall :/12:26
pstolowskipedronis: if we don't then label generation would need some other logic / special casing for core i think (for the reference - #7830)12:26
mupPR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>12:26
cmatsuokamvo: is it failing on the gadget vs device  consistency checking?12:27
pedronispstolowski: I would like us to explore that12:27
pedronispstolowski: it's a bit silly to generate profiles for something we never run12:27
pedroniscore is anyway special cases in various ways12:27
pedronisbut I might be missing something12:28
mupPR snapd#7837 opened: devicestate: implement creating partitions in "install" mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/7837>12:29
mvocmatsuoka: yeah12:29
mvocmatsuoka: exactly the issue you describe in the gdoc12:29
mvocmatsuoka: seems to break master right now :(12:29
mvocmatsuoka: do you think you could try just adding "blockdev --rereadpt" as a workaround?12:30
mvocmatsuoka: need to get lunch in a wee bit but would love to have someone look at this while I'm away :)12:30
cmatsuokamvo: yes, at which point you tried this rereadpt?12:30
cmatsuokamvo: the error pattern is very odd, last night I couldn't reproduce it anymore after ~10PM UTC12:31
pstolowskipedronis: okay, i need to take a step back, and clear my mind. but lunch first12:32
mvocmatsuoka: fun! I can reproduce it in gce12:33
pedronispstolowski: ok, we ignored the silly work because it didn't have consequences so far, but if it starts to give trouble we need to consider12:33
mvocmatsuoka: but not in qemu12:33
mvocmatsuoka: I see it in my PR everytime in gce and also when running manually I hit it right away12:33
mvocmatsuoka: I did run "blockdev --rereadpt" after the failure manually i nthe shell and suddently things went away12:34
mvocmatsuoka: thanks for looking into this, if you have further question please use tg, I will go to lunch now12:34
mvocmatsuoka: but happy to help as good as I can12:34
cmatsuokamvo: 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
mvocmatsuoka: after the test failed I just ran it manually in a shelll12:35
mvocmatsuoka: which is obviously not that great of an answer12:36
* mvo really is away now12:36
* cmatsuoka earns the "breaking master" badge 😱12:39
mupPR 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:40
mupPR 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:53
* Chipaca _really_ needs to lie down for a while, now12:54
mupPR snapd#7839 opened: tests: prevent partitioning test errors <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7839>13:08
cmatsuokamvo: issued a quick workaround atempt, but also working on a more definitive solution that drops lsblk entirely and uses blkid instead13:24
pedronismvo: I removed the 2.43 milestone from snap run --explain, seems a bit unlikely to make it13:27
zygapedronis: I just pushed an update there13:37
zygawith spread tests and more things that it does13:37
zygabut it can be added in later if you feel like it's not ready13:37
pedroniszyga: for one it needs a jdstrand review, 2nd it needs careful review of each output line13:38
zygapedronis: https://github.com/snapcore/snapd/pull/7728/files#diff-771e057220c48a44a34166289f5339f4R1 is the starting point13:39
mupPR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>13:39
zygawe 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 review13:41
pedroniszyga: ?13:42
zygaI'm saying we should not go over the output with a fine comb and not ship it13:42
pedroniszyga: machine parsing is not my worry here13:42
zygawe should ship it and improve it after people use it13:42
pedroniszyga: we should start from a good place, atm the are open questions and the output formatting not very consistent13:44
zygapedronis: open questions?13:44
zygapedronis: what is not consistent?13:44
pedroniszyga: the usage of colons for once13:45
zygapedronis: what about it?13:45
zygahonestly, that's the last thing anyone using this for real will care about13:45
zygabut I don't think it's inconsistent now, maybe you are looking at the older version13:46
pedroniszyga: maybe, it needs review either way13:46
zygathat's true13:46
pedronisfrom me13:46
zygaI'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 someone13:47
pedronisnot more than any other snapd output13:49
pedronisanyway jdstrand review is still the main blocker atm13:49
pedroniszyga: the open questions is the remark Maciej made about separator, and also how that matches or not the original sketch plan13:51
zygapedronis: the separator probably cannot be used if we want wrappers and other layer to handle explain-like output13:52
zygapedronis: because while there's a clear start, there is no clear end13:53
pedroniszyga: I agree but the last output had still missing bits vs the original sketch13:53
pedronisnot sure if your last pass fixed this or not13:53
zygapedronis: 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 does13:53
zygapedronis: I'll double check what's going on in the code and if there's something to add based on the original sketch13:54
pedroniszyga: yes, but the sketch has a separator just before the start of the app command itself13:54
zygapedronis: but my point is that it's meant to be realistic, not idealistic13:54
pedroniswhich partly addressed Maciej worry13:54
pedronisanyway my point stand that still need a proper review after jdstrand one13:55
zygas/after// but yeah13:55
zygaI think we don't need to wait for jamie13:55
jdstrandyou touch snap-confine13:55
jdstrandI'd like to review at least those bits13:56
pedroniszyga: well I plan to wait, given I have also other things13:56
zyganot wait for the other review13:56
=== hunterk_ is now known as hunterk
pedroniszyga: I suppose I could to a quick pass over the output in the spread test when I have a moment13:58
zygaI can quickly adjust it after initial output review13:58
pedronisis the output up-to-date ATM in tha test?14:00
pedronisok, thx14:00
zygacannot join standup14:02
zygaI'll join when I xan14:02
=== ricab is now known as ricab|lunch
zygaoh my14:26
zygasorry guys14:26
zygachrome love14:26
pedronismvo: there is, snap find mumble14:30
pstolowskijdstrand: hey, question about modem-manager interface14:30
pedronismvo: ijohnson: can we do it 30 mins before standup tomorrow?14:31
jdstrandthat interface is pretty ancient14:31
ijohnsonpedronis: mvo: yes that's fine for me14:31
pstolowskijdstrand: is this intended that AppArmorConnectedPlug always adds modemManagerConnectedPlugAppArmor snippet, and on classic in addition appends modemManagerConnectedPlugAppArmorClassic ? should there be if classic - else core?14:33
jdstrandpstolowski: I'm looking at it14:36
pstolowskijdstrand: that extra snippet gets label=snap.core.* on classic in the generated profile14:38
jdstrandpstolowski: 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.*") rule14:40
jdstrandpstolowski: 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
jdstrandbut, we've handled this better lately14:42
jdstrandpstolowski: eg, in avahi-control14:42
jdstrandpstolowski: PermanentSlot and ConnectedSlot could also be updated14:44
jdstrandpstolowski: 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:45
ijohnsonjdstrand: but you are definitely expected to install the network-manager and bluez snap on UC?14:46
mvopedronis, ijohnson sure, let me schedule something14:46
ijohnsonand modem-manager snap too actually14:46
ijohnsonahhh yes that makes much more sense +114:46
jdstrandijohnson: I totally typoed that :)14:46
jdstrandpstolowski: ^14:46
ijohnsonit's still early :-)14:47
jdstrandpstolowski: is this something you are thinking of fixing or should I add it to the list for the next batch of updates?14:47
jdstrandijohnson: not sure you saw, but nice job on the lib caching forum topic :)14:47
ijohnsonI think I did see, but thanks again :-)14:48
pstolowskijdstrand: 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 #783014:49
mupPR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>14:49
jdstrandpstolowski: ack, I'll add it to my list then14:50
pstolowskijdstrand: i though a simple if-classic-else-core in modem manager would do it, but sounds like you envison to streamline it more14:51
pstolowskijdstrand: thanks, and thanks for explaining14:51
jdstrandyeah, they just need updating. they're a bit crufty14:52
pedronismvo: thx, I see it in your cal but not mine14:56
mvopedronis: 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 early14:58
mvopedronis: or the 5pm slot14:58
mupPR 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
mvopedronis: after the certbot meeting14:58
pedronismvo: well the first slot overlaps with the certbot one, after the cerbot is fine with me if it works for you14:59
mvopedronis: I would have to skip/move one meeting15:00
ijohnsonmvo: it's ok, it's not too early15:00
pedronismvo: no strong preference, except I think I need to be at the certbot meeting15:00
zygabrb, lunch15:01
mvoijohnson: it could either be 30min before the meeting or 2h later15:18
ijohnsonmvo: 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 me15:18
zygaLunch over but I’m looking after Lucy now15:28
zygaI will return in about an hour15:29
* cachio lunch15:39
=== ricab|lunch is now known as ricab
mupPR 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:03
Chipacaxnox: ^16:04
pedronisijohnson: thanks for the review16:18
jdstrandmvo, 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 that16:18
ijohnsonpedronis: np16:18
mupPR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>16:18
pedronisijohnson: about the confusing code, it copied and just slightly modified from some code where the error can happen or not16:19
jdstrand(in any case, obviously I'll what for the tests to pass)16:19
pedronisbut I agree is confusing if the error is expected16:19
pedronisjdstrand: let me look16:19
ijohnsonpedronis: 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 way16:20
pedronisjdstrand: you probably want a 2nd review from some of the people that looked at it already, doesn't need to be me tough16:21
jdstrandpedronis: ok16:22
pedronisI actually didn't look at it, just did a meta-comment at some point16:23
zygajdstrand: I meant "from my pov it is ok" but I don't think I have the power to merge with one review16:24
jdstrandthat's fine16:25
* zyga fights snap security tag hydra16:25
jdstrandI didn't want to assign anyone to review it, so I asked in a comment if Ian or Maciej wants to do it16:25
ijohnsonjdstrand: I can take a look today probably16:29
jdstrandijohnson: thanks. it is only as urgent as cleaning out old PRs is16:30
zygajdstrand: merge master into it if you haven't done that recently please16:32
cmatsuokamvo: 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 filesystems16:34
jdstrandzyga: yep, already done16:35
jdstrandI learned from last time16:35
zygasuper, just wanted to double check after recent old-branch-post-merge-fixups16:35
zygaI think we all learned, it's a shame CI is too costly to run on each master change16:36
mupPR 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:39
mupPR 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:41
mvocmatsuoka: cool, thanks for digging into this16:46
jdstrandijohnson and bloodearnest: fyi, https://github.com/sergiusens/snapcraft-preload/pull/3917:22
mupPR 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 jdstrand17:22
zygaI feel cold getting me17:32
zygaNeed a break17:32
mupPR snapcraft#2830 opened: elf: properly handle corrupted ELF files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2830>17:56
mupPR snapcraft#2828 closed: Appstream <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828>18:29
mupPR snapcraft#2831 opened: appstream extractor: add support for code <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2831>18:44
zygacold meds are working so I'm back18:45
zygawondering how to proceed with snap security tag validation18:45
zygasecurity tag are super diverse18:45
zygaand it feels like something to make tidy now18:45
mupPR snapd#7839 closed: tests: prevent partitioning test errors <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7839>18:49
mupPR snapd#7841 opened: tests: fix partitioning test debug message <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>19:39
cmatsuokacachio: PR #7841 fixes a silly shell error in the previous PR20:02
mupPR #7841: tests: fix partitioning test debug message <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>20:02
cachiocmatsuoka, taking a look20:04
cmatsuokacachio: when the udev fstype error happens, grep fails and the test was aborted20:05
cachiocmatsuoka, ah, ok20:05
cachiothanks for the explanation20:05
cmatsuokacachio: I was expecting ID_FS_TYPE to be there with an empty value when it fails, but in fact the key is not listed20:07
cachiocmatsuoka, nice, thanks for the fix20:08
ackkmvo, hi around?20:08
cmatsuokacachio: sorry for the basic error in the first attempt20:11
mupPR 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:11
cachiocmatsuoka, no problem, this happens often20:12
mvoackk: a bit, it's rather late already - what can I do for you :) ?20:13
ackkmvo, 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:13
mupBug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>20:14
mvoackk: that's correct, it should be much better with this version20:14
mvoackk: I think I got one positive report already20:14
ackkmvo, I still see it use 100% cpu at times20:14
mvoackk: is it not helping for you :/ ?20:14
ackkmvo, well it's better for sure20:14
ackkbut I guess under heavy I/O cpu usage is expected?20:15
mvoackk: 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 before20:15
ackkmvo, yeah it's definitely much better. I wasn't sure if it was supposed to be entirely gone20:16
ackkmvo, anyway, thanks for the info, don't let me keep you :)20:16
mvoackk: aha, right. it's still fuse currently so a certain degree of slowness is expected unfortunately20:17
mvoackk: but again - if it's a problem we could talk about options (which would be hackish at this point :(20:17
mvoackk: but let's do this tomorrow :)20:17
ackkmvo, I haven't tested it extensively, yet20:17
ackkmvo, yeah, good night, thanks again :)20:18
mupPR 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
mvoackk: my pleasure - good night to you too!20:19
mupPR snapd#7841 closed: tests: fix partitioning test debug message <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>23:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!