[06:03] <mborzecki> morning
[06:05] <mvo> hey mborzecki
[06:06] <mborzecki> mvo: hey
[06:07] <mup> PR snapd#7782 closed: osutil: handle "rw" mount flag in ParseMountEntry <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7782>
[06:09] <mup> PR snapd#7778 closed: seccomp: allow chown 'snap_daemon:root' and 'root:snap_daemon' <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7778>
[06:34] <zyga> good morning
[06:34] <zyga> wow, everyone is up early
[06:39] <mvo> hey zyga - welcome to the right TZ!
[06:41] <zyga> mvo: ... :D
[06:41] <zyga> mvo: I took Bit for a walk at 1:30AM
[06:41] <zyga> mvo: but I feel okay now
[06:42] <zyga> mvo: I try to take a nap mid-day to compensate
[06:42] <zyga> mvo: I'll jump into the fray soon
[06:43] <mborzecki> zyga: hah 1:30am ;P sounds like a different tz to time
[06:43] <mvo> zyga: cool
[06:45] <mborzecki> mvo: regarding https://github.com/snapcore/snapd/pull/7772#pullrequestreview-322085662 maybe something the generators could do, but those run before local fs mounts, so it'd have to be in the core snap if i understand it correctly
[06:45] <mup> PR #7772: wrappers: write and undo snapd services on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
[06:53] <mvo> mborzecki: aha, interessting idea
[07:29] <pedronis> mborzecki: mvo: hi, should we have a chat about the snapd configure issues?
[07:30] <mborzecki> pedronis: hi, sure
[07:31] <pedronis> mborzecki: mvo: standup?
[07:32] <mvo> pedronis: ok
[08:02] <pstolowski> morning
[08:09] <mborzecki> pstolowski: hey
[08:28] <mup> PR snapd#7765 closed: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7765>
[08:44] <pedronis> mvo: I did a pass on #7746
[08:44] <mup> PR #7746: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>
[08:54] <mup> PR snapd#7789 opened: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7789>
[08:59] <tomwardill> hi all, store team here. Downloads might see some errors atm, we're working on it
[09:00] <pstolowski> tomwardill: hi, thanks for heads up!
[09:02] <mvo> pedronis: thank you!
[09:10] <BjornT> mvo: hi! how can i try out this snapfuse fix on bionic? https://bugs.launchpad.net/snapd/+bug/1817276
[09:10] <mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
[09:11] <BjornT> mvo: it seems like the snapfuse binary comes from the snapd deb, which is still 2.40
[09:15] <mvo> BjornT: we have a updated it in bionic-proposed
[09:16] <mvo> BjornT: I think the sru was actually validated so it's mostly a matter of getting this released
[09:16] <mvo> BjornT: I can poke foundatoins
[09:21] <BjornT> mvo: cool, i'll install it from -proposed then
[09:26] <mborzecki> mvo: pedronis well, the spread test seems to be working now with the tweaks in configstate
[09:28] <BjornT> mvo: nice. confirmed that the fix is a major improvement. after upgrading snapd to 2.42, my load average isn't constantantly growing anymore and back to normal levels
[09:29] <mvo> BjornT: yay! if you could give me numbers from your workload that would be awesome
[09:31] <BjornT> mvo: what kind of numbers? i haven't done any performance tests yet. but before snapfuse was taking 100% constantly, probably while syncing images, which requires a lot of writing. now it still can burst up to 90%, but it quickly goes down again.
[09:32] <BjornT> mvo: and the load average just kept growing. it was up to 900 before i upgraded snapd
[09:33] <zyga> 900?!
[09:34] <mvo> BjornT: thanks, that was what I was looking for, some details :)
[09:35] <pedronis> mborzecki: great
[09:41] <pedronis> mvo: reviewed 7789
[09:52] <pedronis> pstolowski: thanks for the review, I applied the suggestion
[09:52] <pstolowski> yw
[09:53] <mvo> pedronis: thank you!
[09:57] <pedronis> Chipaca: is #7671 ready for review ?
[09:57] <mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels 🏷️> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
[09:58] <Chipaca> pedronis: AFAIK :)
[09:58] <pedronis> Chipaca: ok :)
[10:05] <pedronis> mvo: now that I remembered how the current bootloader.Options flag is used by lk, I think we do want a 2nd flag, probably just InstallMode bool (would be false for UC 16 / 18)
[10:06] <pedronis> mvo: doesn't block the current PR but would be relevant for next step
[10:07] <mvo> pedronis: I was thinking about a "Recovery" flag that could be used by "bootloader.Find()" and "InstallBootConfig()" to tell the system to install bootconfig for recovery or real-boot. That should also address this, but I'm happy with InstallMode as well
[10:07] <pedronis> mvo: that works too, Recover = true = InstallMode
[10:07] <pedronis> Recovery
[10:08] <mup> PR snapd#7746 closed: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7746>
[10:08] <pedronis> Chipaca: does #7671 need a master merge?
[10:09] <mup> PR #7671: overlord/patch: normalize tracking channel in state <Channels 🏷️> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>
[10:09] <Chipaca> pedronis: ah, maybe; i'll look in a bit
[10:11] <pedronis> Chipaca: I see things that I thought I reviewed already, but maybe I'm confused (that's possible)
[10:20] <zyga> sil2100, ogra: do you know who is maintaining the pi gadgets today
[10:22] <zyga> degville: I was looking at https://snapcraft.io/docs/gadget-boot-assets and noticed it's not linked from https://snapcraft.io/docs/gadget-snap - just wanted to check with you if I should edit and make the connection or is there another path somewhere
[10:23] <degville> zyga: I think you're right - I'd not added the link yet pending the boot assets edits and final changes, but it makes better sense to link it now.
[10:24] <degville> (as doc and boot assets are in pretty good shape)
[10:45] <mup> PR snapd#7787 closed: many: share single implementation to list needed default-providers <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7787>
[10:52] <mup> PR snapd#7790 opened: boot: add boot.Modeenv that can read/write the UC20 modeenv files <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7790>
[10:53] <mup> PR snapd#7789 closed: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7789>
[10:53] <mvo> pedronis_: hopefully simple and then I can build on top of this
[10:55] <pedronis> mvo: commented
[10:59] <mvo> pedronis: thank you!
[11:18] <Chipaca> pedronis: ok if i rebase 7671?
[11:23] <Chipaca> pedronis: i've rebased 7671
[11:24] <Chipaca> pedronis: it looks a lot more like a patch patch now
[11:32] <mvo> pedronis: addressed your comments, thanks again
[11:35] <sil2100> zyga: hey! That's us (foundations), but it's basically waveform mostly
[11:39] <zyga> sil2100: thanks, I'll reach out to him
[11:44] <pedronis> Chipaca: thx, I will look in a bit
[11:44] <pedronis> mvo: that's not the rename I proposed, I proposed to match what we use in the file (up to format)
[11:44] <pedronis> :)
[11:45] <pedronis> mvo: ah, not the code is right, but the commit says another thing
[11:51] <pedronis> mvo: +1 with some more comments, mostly about the tests
[11:53] <mvo> pedronis: thank you, on it!
[11:53] <mup> PR snapd#7791 opened: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7791>
[12:05] <mborzecki> mvo: pedronis: i've updated #7788 please take a look
[12:05] <mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[12:05] <mborzecki> need to sort out my flights
[12:06] <pedronis> mborzecki: thanks, will look in a bit
[12:07] <pedronis> Chipaca: reviewed, maybe pstolowski can give a look too
[12:07] <zyga> mborzecki: about flights, I looked at trains
[12:08] <zyga> mborzecki: but it's a no-go because it's impossible to get tickets for a ride this distant
[12:08] <zyga> mborzecki: assuming that train schedules don't change it's a whole-day trip with one stop in Berlin
[12:08] <mborzecki> zyga: and it's probably half a day
[12:08] <zyga> mborzecki: and the price is very competitive with flying
[12:08] <zyga> mborzecki: even if you consider first class actually
[12:09] <zyga> mborzecki: but I decided not to use it because << 2 hours is meh-good-enough
[12:09] <pstolowski> pedronis, Chipaca will do
[12:09] <zyga> mborzecki: there are a number of connections, some take over half a day and involve many stops, some are fast
[12:15] <pedronis> mborzecki: done, thank you
[12:16] <pedronis> mborzecki: have you looked at the other issue (installing core on a snapd-only system with defaults) or not yet?
[12:17] <mborzecki> pedronis: not yet, spent silly amount of time fighting the configstate handlers test
[12:18] <mvo> 7790,7791 should be simple reviews and unblock some more of the early boot work
[12:18]  * mvo considers lunch
[12:18] <pedronis> mborzecki: lots of setup needed
[12:18] <mborzecki> pedronis: might have overdone it a little
[12:18] <zyga> jdstrand: good morning
[12:20] <mup> PR snapd#7759 closed: devicestate: add reading of modeenv to uc20 firstboot code  <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7759>
[12:24] <pstolowski> pedronis, Chipaca will do
[12:25] <pstolowski> ups, wrong window
[12:40] <zyga> mborzecki: 2nd +1 on https://github.com/snapcore/snapd/pull/7788#pullrequestreview-322948196
[12:40] <mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[12:41] <mborzecki> zyga: thanks
[12:50] <zyga> I'll make coffee and resume patches
[12:59] <mborzecki> cmatsuoka: hi, quick question about #7743, in the real world scenario, we wouldn't need sfdisk --force, because snap-bootstrap will be running off initramfs right?
[12:59] <mup> PR #7743: snap-bootstrap: force partition table operations <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
[13:07] <cmatsuoka> mborzecki: it's likely that it will be needed in the real case, I added snap-bootstrap to the spike and it required --force
[13:08] <cmatsuoka> mborzecki: --force was completely under my radar until I tested it in a real scenario
[13:09] <cmatsuoka> mborzecki: the same happened with the udev node creation, for some reason partx -u triggers node creation but blockdev --rereadpt doesn't
[13:10] <cmatsuoka> mborzecki: I started to check the partx source code to see what exactly it's doing there, but it does quite a lot
[13:13] <mborzecki> cmatsuoka: interesting, i would guess that sfdisk handles that when it triggers the kernel to reread the partition table
[13:14] <mborzecki> cmatsuoka: afaiu that's what partx does by doing a bunch of ioctls() though it passes an actual partition number there
[13:15] <mborzecki> cmatsuoka: either way, this goes through the kernel -> devfs, and in parallel to udev which does symlinking under /dev/disk/by-*/, that's probbaly why the extra delay is needed
[13:15] <cmatsuoka> I also tried to manually run udevadm trigger but it didn't do anything
[13:16] <mborzecki> cmatsuoka: was any paritition from taht device mounted at the time when sfdisk ran?
[13:16] <cmatsuoka> According to a comment in the partx source code, it needs a few ms to settle after the operation
[13:18] <cmatsuoka> mborzecki: hmm, yes, it's possible that we had partitions mounted in initramfs
[13:18] <cmatsuoka> mborzecki: ah, I guess core was mounted from seed directly at that point
[13:18] <mborzecki> cmatsuoka: that would explain why the disk was seen as 'used'
[13:19] <cmatsuoka> mborzecki: yes, indeed. but we can't unmount everything, we need seed an boot
[13:19] <cmatsuoka> and boot
[13:22] <mborzecki> cmatsuoka: right, i guess there's no way around that, so --force seems ok
[13:22] <mborzecki> cmatsuoka: perhaps that's why you needed to call partx
[13:23] <cmatsuoka> mborzecki: about the partx -u, I don't like the idea that we're relying on a side effect of a specific utility -- ideally I'd like to redo whatever partx is doing there
[13:23] <cmatsuoka> but that would take some time to analyse
[13:23] <mborzecki> cmatsuoka: was there any mesage from fdisk? specificaly thinking https://github.com/karelzak/util-linux/blob/master/libfdisk/src/context.c#L833-L840
[13:25] <cmatsuoka> mborzecki: no such message, the PT re-read was apparently successful
[13:25] <mborzecki> heh, fun ;)
[13:26] <cmatsuoka> those real life problems are very annoying!
[13:27] <cmatsuoka> also I hope that kernel 5.4 doesn't crash in firstboot, 5.3 did but I still didn't check why
[13:31] <cmatsuoka> mborzecki: I think I should add an XXX note there
[13:32] <mborzecki> cmatsuoka: yup, sounds like a good idea
[13:32] <cmatsuoka> mborzecki: doing that
[14:23] <mup> PR snapd#7790 closed: boot: add boot.Modeenv that can read/write the UC20 modeenv files <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7790>
[14:35] <mborzecki> anyone know of a tool that lists what desktop files are visible?
[14:41] <mup> PR snapd#7760 closed: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7760>
[14:47] <zyga> pedronis, mvo: I'll check if there are any open bugs that are related to nested mimics and see if they have regression tests
[14:49] <mup> PR snapd#7792 opened: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7792>
[14:58] <mup> PR snapd#7671 closed: overlord/patch: normalize tracking channel in state <Channels 🏷️> <Needs Samuele review> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7671>
[14:59] <Chipaca> *gasp* i was supposed to wait for pstolowski :-(
[14:59] <mvo> pedronis: 7792 should also be easy hopefully
[14:59] <pstolowski> Chipaca: i'm finishing it atm..
[14:59] <Chipaca> pstolowski: please tell me it's not on fire :-|
[15:01] <mborzecki> mvo: pedronis: #7788 is green
[15:01] <mup> PR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[15:18]  * cachio lunch
[15:21] <thresh> hi.  cant launch chromium anymore, on debian: https://paste.debian.net/1118076/
[15:21] <thresh> installed:   78.0.3904.108            (958) 160MB -
[15:22] <thresh> any ideas? thank you.
[15:23] <Chipaca> thresh: can you pastebin 'snap version' please?
[15:24] <Chipaca> who was it that was looking at the /sys/kernel/mm/transparent_hugepage/hpage_pmd_size thing
[15:24] <thresh> sure thing.  there you go Chipaca: http://paste.debian.net/1118077/
[15:24] <Chipaca> mvo: you do remember, offhand?
[15:24] <Chipaca> yeah, 42 on a 5.3
[15:25] <Chipaca> there was somebody looking at this, but i don't remember what the conclusion was
[15:26] <Chipaca> jdstrand: is it expected that chromium tries to do things that would require hardware-observe?
[15:26] <pedronis> Chipaca: I saw some chromium related stuff in some of recent jdstrand PRs
[15:27] <pedronis> not sure it relates or not
[15:27] <pedronis> maybe he can say
[15:27] <jdstrand> Chipaca: what things?
[15:27] <Chipaca> jdstrand: looks like it's trying to read /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
[15:27] <Chipaca> as per the pastebin above
[15:27] <Chipaca> jdstrand: https://paste.debian.net/1118076/
[15:28] <zyga> mvo: can you double check https://github.com/snapcore/snapd/pull/7773 please
[15:28] <mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
[15:28] <zyga> mvo: it has +2 and as soon as it's green I'd like to merge it and open a backport for 2.42.3
[15:29] <jdstrand> Chipaca: seems like we need something added to PR 7779
[15:29] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[15:29] <jdstrand> Chipaca: I'll do that in a bit
[15:29] <Chipaca> jdstrand: is there something thresh can do to get unblocked?
[15:30] <Chipaca> i'm guessing 'reboot into pre-5.3 kernel' would work but not be a nice way out
[15:30] <jdstrand> Chipaca: oh, actually, that is snap-update-ns.chromium
[15:30] <zyga> o/
[15:30] <thresh> It's not a big deal.  I use firefox mainly anyway.  Just something that is probably best reported & fixed :)
[15:30] <Chipaca> thresh: <3
[15:31] <pedronis> jdstrand: mvo is looking at doing a 2.42.3, it would be good to know if we need things in it for this
[15:32] <jdstrand> I'll look into that access. one could modify /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium
[15:32] <jdstrand> thresh: ^
[15:33] <jdstrand> eg, add '/sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,' then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium'
[15:33] <jdstrand> that only works until snapd refreshes the policy of course (then you'd have to do it again)
[15:33] <jdstrand> pedronis: ack
[15:35] <Chipaca> jdstrand: thank you
[15:35] <thresh> jdstrand, huh.  well that worked to remove the apparmor denial line from dmesg indeed.
[15:35] <thresh> but chromium still crashes with the same message
[15:35] <thresh> so maybe those are not related.
[15:36] <Chipaca> oSoMoN: ^ is that a 'you' thing?
[15:37] <Chipaca> thresh: at this point i'd say it's probably best to open a topic in forum.snapcraft.io, so it can be looked at async
[15:37] <thresh> right
[15:37] <Chipaca> either that or a good ol' bug :)
[15:38] <Chipaca> but forum is probably easier
[15:38] <thresh> I'm going to try a different user / clean profile etc
[15:38] <oSoMoN> thresh, mind filing a bug at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+filebug ?
[15:38] <mup> PR snapd#7793 opened: devicestate: read modeenv early and store in devicestate <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7793>
[15:39] <oSoMoN> Chipaca, the chromium snap is a 'me' thing indeed
[15:39] <thresh> oSoMoN, I will, thanks!
[15:39] <mup> PR snapd#7791 closed: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7791>
[15:39] <Chipaca> oSoMoN: :)
[15:39] <mvo> zyga: sure, looking now
[15:39]  * Chipaca grabs a cuppa tea and tries to stop eating biscuits
[15:40] <Chipaca> I visited my mum on sunday and cam back with a metric ton of chocolate chip
[15:40] <Chipaca> send help
[15:42] <mup> PR snapd#7773 closed: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <⚠ Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7773>
[15:42] <zyga> Chipaca: send chocolate :)
[15:43] <zyga> Chipaca: we should take preorders on treats for Fra
[15:43] <Chipaca> Fra is three months away
[15:43] <zyga> Chipaca: with everyone taking trains we can bring anything :)
[15:44] <Chipaca> in fact, fra is two weeks before i run the lisbon half
[15:44] <Chipaca> so no treats!
[15:47] <mvo> mborzecki: I think we can merge 7788 - do you want to squash merge or do you prefer the commits and then we open a 2.42 version ? either way is fine with me. if squash I think it would be great if you could do it yourself so that you can decide on the commit message
[15:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/7794
[15:49]  * zyga goes for lunch
[15:50] <mup> PR #7794: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>
[15:50] <mup> PR snapd#7788 closed: overlord/snapstate: pick up system defaults when seeding the snapd snap <Squash-merge> <⚠ Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[15:50] <mup> PR snapd#7794 opened: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>
[15:55] <mup> PR snapd#7795 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap (2.42) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7795>
[15:57] <mborzecki> mvo: ^^
[15:58] <ackk> zyga, hi, I just ran again into the issue with the maas snap reporting that the command is not there, when the snap is installed. this time it happened right after installing the snap from the store
[15:58] <ackk> zyga, any useful info I can gather ?
[16:03] <zyga> ackk: oh my :D
[16:03] <zyga> ackk: what what the exact error message?
[16:04] <ackk> $ maas
[16:04] <ackk> execv failed: No such file or directory
[16:04] <zyga> ackk: this is worrying, so it was not a "snap try" version
[16:04] <ackk> zyga, it's odd because every time I've seen it happen, it was just after I ran maas init
[16:04] <zyga> ackk: did you have a snap-try version before though?
[16:04] <zyga> and then installed from the store on top of that?
[16:05] <ackk> zyga, that's a good question, I'm not sure
[16:05] <mvo> mborzecki: \o/
[16:05] <zyga> ackk: that might explain why
[16:05] <mvo> pedronis: you mentioned another potential thing we need for .3 ?
[16:05] <zyga> ackk: we actually landed a feature that might help
[16:05] <ackk> zyga, can I check somehow?
[16:05] <zyga> ackk: it fixes a whole class of issues
[16:05] <zyga> ackk: try edge when it builds please,
[16:06] <ackk> zyga, I would have an x1 dir if I had upgraded from try right?
[16:06] <zyga> yes
[16:06] <zyga> or x$something
[16:06] <ackk> zyga, then no, I only have one revision
[16:06] <ackk> /o\
[16:06] <zyga> ackk: any ideas on how to reproduce are welcome
[16:07] <zyga> ackk: to finish that thought though: https://github.com/snapcore/snapd/pull/7773 is what I was referring to
[16:07] <mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <Squash-merge> <⚠ Critical> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7773>
[16:07] <zyga> ackk: it introduces snap set core experimental.robust-mount-namespace-updates=true
[16:07] <zyga> ackk: which changes how mount namespace is updated
[16:07] <ackk> zyga, that's not yet in edge though?
[16:07] <zyga> ondra: ^ btw, it landed, we're going to be good for release soon
[16:07] <zyga> ackk: no, it's just in for a few minute
[16:08] <ackk> zyga, so, snapd edge ?
[16:08] <ondra> zyga cool, I will run edge on one of the devices and confirm it is updating ( and I will also give customer heads up)
[16:08] <ackk> zyga, and that snap set
[16:08] <ackk> zyga, is that valid for core18 as well?
[16:09] <zyga> ackk: snapd edge or core edge once it builds
[16:09] <zyga> ackk: it works across all versions
[16:09] <ackk> cool
[16:10] <mborzecki> pedronis: mvo: yeah, looks like we have a problem with subsequent install of core on a core18 device
[16:10] <mvo> thanks zyga and mborzecki
[16:10] <mvo> mborzecki: meh, do you have more details?
[16:11] <zyga> oh
[16:11] <zyga> mborzecki: so more fixes for 2.42.x required?
[16:11] <zyga> mvo: do you want to cherry-pick any of jdstrand's recent interface fixes?
[16:11] <zyga> mvo: I can cherry-pick them back to offload you
[16:11] <mborzecki> mvo: pedronis: https://paste.ubuntu.com/p/mpV9Nr8v9H/
[16:11] <mborzecki> zyga: yes, think so
[16:12] <mup> PR snapd#7761 closed: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7761>
[16:13] <zyga> ijohnson: hey
[16:13] <zyga> ijohnson: I'd like to land https://github.com/snapcore/snapd/pull/7783
[16:13] <mup> PR #7783: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>
[16:13] <zyga> ijohnson: I explained why the suggestion doesn't work (ordering)
[16:14] <ijohnson> sure let me take a look
[16:14] <zyga> ijohnson: I'm happy to iterate on ideas but I'd like to merge this and unblock another PR
[16:14] <zyga> ijohnson: so that the useful improved debug output from snap-update-ns doesn't get stuck/lost
[16:16] <mup> PR snapd#7796 opened: tests/main/ubuntu-core-config-defaults-once: make sure configuration defaults are applied once <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7796>
[16:21] <zyga> dot-tobias: hey
[16:21] <zyga> dot-tobias: please check out updates to https://bugs.launchpad.net/snapd/+bug/1844496
[16:21] <mup> Bug #1844496: “Device or resource busy” error during snap refresh when using layout with variable <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1844496>
[16:22] <mup> PR snapd#7797 opened: devicestate: make /var/lib/snapd/seed available in install mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7797>
[16:23] <mvo> zyga: only if we really need them for .3
[16:23] <zyga> mvo: ok
[16:24] <mvo> mborzecki: aha, so this is the defaults that get reapplied?
[16:31] <pedronis> mborzecki: bad but expected
[16:31] <pedronis> the fix should be simple as discussed
[16:31] <pedronis> in snapstate
[16:32] <mvo> pedronis: that's not .3 criticial, is it?
[16:32] <ijohnson> zyga: approved, but please note my response :-) thanks
[16:32] <zyga> looking
[16:32] <zyga> and thank you :)
[16:32] <mvo> pedronis: did you mention earlier anything else criticial for .3?
[16:34] <pedronis> mvo: jdstrand was looking into chromium failing in some places with denials
[16:34] <jdstrand> mvo: when do you expect 2.43 to go out? I ask cause ondra needs raw-volume soon and PR 7779 is also interesting
[16:34] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[16:34] <jdstrand> mvo: (these might be candidates for .3)
[16:35] <mvo> jdstrand: we do a .3 today/early tomorrow, once that is in candidate I will branch 2.43
[16:36] <jdstrand> mvo: so, a couple of weeks?
[16:36] <jdstrand> mvo: https://github.com/snapcore/snapd/pull/7777 would be nice for people to have
[16:36] <mup> PR #7777: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7777>
[16:36] <jdstrand> mvo: that is a real clean cherrypick
[16:37] <mup> PR snapd#7783 closed: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7783>
[16:37] <mvo> jdstrand: 2.43 is ~4 weeks away
[16:37] <zyga> ijohnson, mborzecki: https://github.com/snapcore/snapd/pull/7784 is no longer stacked. It's not urgent though
[16:37] <mup> PR #7784: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
[16:38] <ijohnson> zyga: yes will review after I submit a PR changing that to a list for you :-)
[16:38] <mvo> jdstrand: 7777 is merged
[16:38] <zyga> ijohnson: sounds great :)
[16:38] <zyga> mvo: let's cherry pick it
[16:39] <jdstrand> mvo: ah, cool
[16:39] <mvo> zyga: cherry pick which one?
[16:39] <mvo> zyga: I cherry picked 7777
[16:39] <jdstrand> pedronis: I added the comment to https://github.com/snapcore/snapd/pull/7779
[16:39] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[16:40] <zyga> mvo: ah, perfect
[16:40] <zyga> yeah, that one
[16:40] <zyga> it's just a pair of denials for something that is not allowed
[16:40] <jdstrand> pedronis: assuming you are happy with it, this would be a candidate for 2.42.3 for mvo imho
[16:40] <zyga> mvo: and cuts logging
[16:41] <pedronis> jdstrand: which one?
[16:41] <pedronis> 7779 ?
[16:41] <jdstrand> ondra: how fast can you switch over to raw-volume in that snap? trying to figure out if this must be in 2.42.3 or waiting for 2.43 as planned (at least a week more if 2.43)
[16:42] <jdstrand> pedronis: 7779 has the comment change, yes. that I think would be good in .3 and is ready to go once you do final review (you have a request changes)
[16:42] <ondra> jdstrand it's not time critical as they are using system-files. And switching would need to be added to customers dev cycle
[16:42] <ondra> jdstrand so I'd not gate 2.43 with it
[16:43] <jdstrand> pedronis: I also updated PR 7768 (raw-volume), but per ondra, this is not critical for 2.42.3
[16:43] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[16:43] <ondra> jdstrand and thank you for working on it. I really like the PR
[16:45] <jdstrand> ondra: cool, yw
[16:45] <pedronis> jdstrand: looking at 7779 in a short bit, having parallel discussions
[16:45] <jdstrand> mvo: I'm investigating thresh' denial, but it isn't critical and will be in a separate PR
[16:46] <jdstrand> mvo: ie, I might have a small PR. I'm not changing 7779
[16:46] <jdstrand> mvo: in case it wasn't clear. ignore PR 7768 (raw-volume) for 2.42.3
[16:46] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[16:47] <pedronis> jdstrand: done with 7779, it's ok for .3 for me, if you are comfortable with that yourself
[16:49] <mvo> jdstrand: thanks! ok, please tag everything you want for 2.42 with the 2.42 milestone
[16:49] <pedronis> jdstrand: thanks for the work on raw-volume, I will re-review it,  not today though given is not a blocker
[16:50] <jdstrand> mvo: ok, https://github.com/snapcore/snapd/pull/7779 updated, though it has to run through spread for the comment update that was requested
[16:50] <jdstrand> (that is happening now)
[16:50] <mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>
[16:57] <mup> PR snapcraft#2822 opened: xattrs: ignore errors if SNAPCRAFT_BUILD_INFO is unset <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2822>
[16:57] <mup> PR snapcraft#2823 opened: xattrs: switch to python's os package for reading/writing xattrs <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2823>
[17:01] <mup> PR snapd#7798 opened: interfaces/browser-support: allow reading status of huge pages <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>
[17:01] <jdstrand> mvo: ok, PR 7798 milestoned for 2.42.3
[17:01] <mup> PR #7798: interfaces/browser-support: allow reading status of huge pages <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>
[17:02] <zyga> jdstrand: FYI, there's a corresponding launchpad milestone, if there are bugs you can have them target that release
[17:03] <jdstrand> zyga: ack
[17:04] <mvo> jdstrand: thank you
[17:08] <zyga> brb, tea
[17:11] <pedronis> mvo: what are the next UC20 PRs that need review?
[17:15] <mvo> pedronis: 7792 should be an easy one
[17:15] <mvo> pedronis: then 7793 which is also easy
[17:15] <mvo> pedronis: and 7797 should also be easy, I tried to make them all bite-size :)
[17:16] <mvo> pedronis: once 7793 is in I will do one more and then help with 7762
[17:21] <pedronis> mvo: thanks, not sure how much more I will do tonight, but at least I know where to start tomorrow
[17:31] <mup> PR snapd#6436 closed: interfaces: add system-backup interface <Needs Samuele review> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6436>
[17:40] <ijohnson> zyga: alright here you go https://github.com/snapcore/snapd/pull/7799 I even benchmarked it for you :-)
[17:40] <mup> PR snapd#7799 opened: osutil/mount: de-duplicate code to use a list <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
[17:40] <mup> PR #7799: osutil/mount: de-duplicate code to use a list <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>
[17:58] <jdstrand> degville: hey, fyi, I took a crack at https://forum.snapcraft.io/t/the-system-backup-interface/14348 and updated https://forum.snapcraft.io/t/supported-interfaces/7744
[18:21] <mup> PR snapd#7800 opened: tests: add Ubuntu Eoan to google-sru backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7800>
[18:34] <jdstrand> ogra: hey, are there some official (or at least, something you use) docs for booting a rpi off of usb hard drive?
[18:34] <jdstrand> ogra: googling finds me stuff, but I don't know if I should trust it
[18:39] <zyga> ijohnson: how would it perform if you added a break on flags == 0?
[18:39] <ijohnson> zyga: hmm, let me see
[18:40] <ijohnson> zyga: well looking at it before I even write the code, none of the benchmarks I have will result in that because flags isn't 0 with any of the test cases
[18:41] <ijohnson> zyga: is 0 a common case for mounts we do? if so I can add it to the test case, but it feels like that wouldn't happen "in the wirld"
[18:41] <ijohnson> s/wirld/wild/
[18:42] <zyga> ijohnson: zero mid-loop
[18:42] <zyga> It will usually have one or two flags
[18:42] <ijohnson> ah I see what you mean
[18:44] <zyga> ijohnson: we could even reorder flags to put most common first
[18:44] <zyga> ijohnson: thank you for doing that
[18:44] <ijohnson> yes good point if we are going to break early then putting most common flags first makes a lot of sense
[18:45] <zyga> ijohnson: sorry for being absent
[18:45] <zyga> ijohnson: I'll show you what I was doing
[18:45] <ijohnson> zyga: don't worry about it
[18:46] <thresh> oSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1854091 there you go
[18:46] <mup> Bug #1854091: [snap] traps on start <chromium-browser (Ubuntu):New> <https://launchpad.net/bugs/1854091>
[18:46] <thresh> oSoMoN, let me know if I can provide any more information.  thank you!
[18:46] <zyga> ijohnson: https://twitter.com/zygoon/status/1199399096399859712
[18:47] <ijohnson> :-) seems like a better use of time than looking ay my silly optimizations of a couple nanoseconds
[18:52] <mvo> pedronis: thank you!
[18:53] <zyga> mvo: gadget update pc fails on the release branch
[18:53] <zyga> mvo: I think we need to backport the fix for that one first
[18:53] <mvo> zyga: uh, right. are you on this or shall I have a look?
[18:53] <zyga> I'll find it and send it
[18:53] <zyga> mvo: just woke up :)
[18:56] <zyga> done
[18:56] <mup> PR snapd#7801 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml (#7785) <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
[19:01] <murthy> why mojo video decoder is not enabled for chromium snap?
[19:13] <mvo> zyga: thank you!
[19:26] <mup> PR snapd#7802 opened: update system-backup tests to not check for sanitize errors related to os <Simple 😃> <⚠ Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7802>
[19:27] <jdstrand> mvo: erf, ^ needed for master
[19:29] <jdstrand> mvo: basically, something changed out from under the system-backup PR and the tests weren't re-run before committing. this fixes that
[19:31] <murthy> Reference article: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-73-Linux-Mojo-Video-Dec
[19:32] <murthy> according to the above article chromium has enabled mojo video decoder by default on windows
[19:33] <murthy> and chromium provides hardware acceleration for video playback via mojo video decoder
[19:33] <murthy> This is the bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=522298
[19:35] <murthy> According to the Comment 51 in the bug tracker you can enable mojo decoder by setting the gn arg of "use_vaapi" to true
[19:35] <murthy> during compilation I mean
[19:35] <Chipaca> oSoMoN: ^
[19:39] <pedronis> jdstrand: yes, our CI is fragile to that, it's a good idea to merge master in any long lived PR
[19:40] <jdstrand> pedronis: yeah, that is what I was thinking :\
[19:45] <oSoMoN> thresh, Chipaca: thanks
[19:48] <mvo> jdstrand: thank you
[19:49] <mup> PR snapcraft#2824 opened: Support for go.mod <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2824>
[19:49] <mvo> thanks zyga for 7801
[19:49] <zyga> :)
[19:52] <ijohnson> oh zyga btw adding a check in the loop slows everything down oddly enough :-(
[19:53] <ijohnson> https://www.irccloud.com/pastebin/F2LyBHTL/
[19:55] <vidal72[m]> murthy: do you know any distro that enabled that option? I assume it's disabled for a reason
[19:57] <murthy> vidal72[m]: probably fedora
[19:58] <vidal72[m]> murthy: nope, see comment https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_1810
[19:58] <vidal72[m]> https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_23
[20:00] <vidal72[m]> I don't think it's worth hitting all regressions others had with vaapi
[20:00] <vidal72[m]> without upstream support this is hopeless
[20:04] <vidal72[m]> murthy: Arch linux also disabled vaapi after trying it https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=493cb5bf7b8453f628ee74ae75add8699ad244f0
[20:04] <murthy> vidal72[m]: It only enables mojo video decoder, users have to enable the "Override software rendering list" flag to enable hardware acceleration using vaapi
[20:05] <murthy> checking
[20:09] <murthy> It seems they had specifically reverted that patch
[20:09] <vidal72[m]> heh
[20:10] <vidal72[m]> RIP vaapi :(
[20:10] <murthy> Its just that I tried a chromium build from an an unofficial ppa and it seems stable
[20:10] <murthy> vidal72[m]: Intel is not doing a good job for Linux
[20:10] <vidal72[m]> I think it depends on hardware
[20:11] <murthy> right
[20:11] <murthy> Mine is a kabylake
[20:11] <vidal72[m]> intel is still miles ahead of amd and nvidia :)
[20:11] <murthy> what?
[20:12] <vidal72[m]> I heard that most vaapi issues come from amd
[20:13] <murthy> vidal72[m]: also downstream packaging restrictions
[20:14] <murthy> This is the article that said vaapi was enabled in fedora https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snaps-Chromium-VA-API
[20:14] <murthy> phoronix fellows know how to get the clicks
[20:14] <vidal72[m]> murthy: then enabled it then disabled, same as Arch
[20:14] <vidal72[m]> *they
[20:14] <murthy> ya
[20:16] <murthy> Do you know this ppa? Can I trust it? https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-beta
[20:16] <vidal72[m]> I don't know it
[20:18] <murthy> ok
[20:18] <murthy> vidal72[m]: Thanks for the support
[20:33] <zyga> mvo: is master still broken
[20:34] <zyga> I can jump into that
[20:35]  * zyga checks
[20:38] <zyga> heh
[20:38] <zyga> funny
[20:42] <mvo> zyga: didn't jamie fix this?
[20:42] <zyga> ah, I see
[20:42] <mvo> zyga: unit test failure it seems, fun
[20:42] <zyga> I'll send a useful patch nonetheless
[20:43] <zyga> we have some leftover junk
[20:43] <mvo> zyga: invalid title
[20:43] <mvo> zyga: fun!
[20:43] <mvo> zyga: restarted the build
[20:43] <zyga> eh
[20:43] <zyga> :D
[20:43] <zyga> must be OMG RELEASE DAY
[20:44] <mvo> zyga: haha yes
[20:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/7803
[20:49] <mup> PR #7803: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
[20:49] <mvo> zyga: nice, thank you
[20:49] <mup> PR snapd#7803 opened: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>
[20:50] <zyga> mvo: meanwhile https://github.com/snapcore/snapd/pull/7801 is still yellow
[20:50] <mup> PR #7801: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
[20:50] <mvo> zyga: yeah, it's a bit sad
[20:50] <zyga> about 20 minutes left
[20:51] <zyga> if it passes
[20:51] <mvo> zyga: I call it a day, hopefully in 8h when I'm up again the world is less red
[20:51] <zyga> yeah
[20:51] <zyga> I'll merge and restart anything I can
[20:51] <zyga> mvo: can I merge stuff into the release branch with one review?
[20:51] <zyga> mvo: it could be all merged for you in the morning
[20:51] <mvo> zyga: I think that's fine, strict backports just need one review
[20:51] <zyga> ok
[20:51] <zyga> technically https://github.com/snapcore/snapd/pull/7801 is not reviewed
[20:52] <zyga> that's the fix to unbreak others :)
[20:52] <mup> PR #7801: tests/main/gadget-update-pc: use a program to modify gadget yaml (2.42) <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/7801>
[20:52] <mvo> zyga: refresh please
[20:52] <zyga> \o/
[20:52] <zyga> thanks!
[20:52] <zyga> I had a nap so I can work for the next 45 minutes
[20:53] <zyga> if that helps tomorrow that's useful
[20:53] <zyga> tomorrow I'm back to feature work
[20:53] <zyga> I have some follow ups for the update-ns that pedronis suggested
[20:53] <zyga> but we have enough open PRs now
[20:53] <mvo> zyga: thank you ! much appreciated. just make sure you don't overdo it, if you feel sleepy/want-to-do-something-else just do it :)
[20:53] <zyga> yeah
[20:53] <zyga> I totally will :)
[20:54]  * mvo hugs zyga and vanishes 
[20:54] <zyga> o/
[21:03] <sdhd-sascha> Chipaca: i have trouble with upload to the store. But yesterday i could start sway in classic mode. It's on github
[21:17]  * cachio afk
[21:31] <zyga> oh for crying out loud ....
[21:32] <zyga> timeout
[21:39] <ijohnson> hey zyga, looks like I missed some stuff that happened while out to lunch, what can I help review to unbreak master/critical things?
[21:40] <zyga> ijohnson: it's all fixed now, jdstrand sent a followup PR
[21:40] <zyga> we're just waiting for things to be less red
[21:40] <ijohnson> zyga: ack ok
[21:50] <zyga> another one failed
[21:50] <zyga> I'll call it a day
[21:52] <ijohnson> good night zyga, see you tomorrow
[22:25] <mup> PR snapd#7802 closed: interfaces: update system-backup tests to not check for sanitize errors related to os <Simple 😃> <⚠ Critical> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/7802>
[22:25] <jdstrand> ijohnson: ^
[22:26] <ijohnson> Right, nice
[23:04] <cmatsuoka> devicestate tests are very intersting, but it's time to call it a day