/srv/irclogs.ubuntu.com/2019/11/26/#snappy.txt

mborzeckimorning06:03
mvohey mborzecki06:05
mborzeckimvo: hey06:06
mupPR 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:07
mupPR 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:09
zygagood morning06:34
zygawow, everyone is up early06:34
mvohey zyga - welcome to the right TZ!06:39
zygamvo: ... :D06:41
zygamvo: I took Bit for a walk at 1:30AM06:41
zygamvo: but I feel okay now06:41
zygamvo: I try to take a nap mid-day to compensate06:42
zygamvo: I'll jump into the fray soon06:42
mborzeckizyga: hah 1:30am ;P sounds like a different tz to time06:43
mvozyga: cool06:43
mborzeckimvo: 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 correctly06:45
mupPR #7772: wrappers: write and undo snapd services on core <Remodel πŸš‹> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>06:45
mvomborzecki: aha, interessting idea06:53
pedronismborzecki: mvo: hi, should we have a chat about the snapd configure issues?07:29
mborzeckipedronis: hi, sure07:30
pedronismborzecki: mvo: standup?07:31
mvopedronis: ok07:32
=== pstolowski|afk is now known as pstolowski
pstolowskimorning08:02
mborzeckipstolowski: hey08:09
mupPR snapd#7765 closed: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7765>08:28
pedronismvo: I did a pass on #774608:44
mupPR #7746: snap-bootstrap: implement "snap-bootstrap initramfs-mounts" <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7746>08:44
mupPR snapd#7789 opened: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7789>08:54
tomwardillhi all, store team here. Downloads might see some errors atm, we're working on it08:59
pstolowskitomwardill: hi, thanks for heads up!09:00
mvopedronis: thank you!09:02
BjornTmvo: hi! how can i try out this snapfuse fix on bionic? https://bugs.launchpad.net/snapd/+bug/181727609:10
mupBug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>09:10
BjornTmvo: it seems like the snapfuse binary comes from the snapd deb, which is still 2.4009:11
mvoBjornT: we have a updated it in bionic-proposed09:15
mvoBjornT: I think the sru was actually validated so it's mostly a matter of getting this released09:16
mvoBjornT: I can poke foundatoins09:16
BjornTmvo: cool, i'll install it from -proposed then09:21
mborzeckimvo: pedronis well, the spread test seems to be working now with the tweaks in configstate09:26
BjornTmvo: 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 levels09:28
mvoBjornT: yay! if you could give me numbers from your workload that would be awesome09:29
BjornTmvo: 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:31
BjornTmvo: and the load average just kept growing. it was up to 900 before i upgraded snapd09:32
zyga900?!09:33
mvoBjornT: thanks, that was what I was looking for, some details :)09:34
pedronismborzecki: great09:35
pedronismvo: reviewed 778909:41
pedronispstolowski: thanks for the review, I applied the suggestion09:52
pstolowskiyw09:52
mvopedronis: thank you!09:53
pedronisChipaca: is #7671 ready for review ?09:57
mupPR #7671: overlord/patch: normalize tracking channel in state <Channels 🏷️> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>09:57
Chipacapedronis: AFAIK :)09:58
pedronisChipaca: ok :)09:58
pedronismvo: 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:05
pedronismvo: doesn't block the current PR but would be relevant for next step10:06
mvopedronis: 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 well10:07
pedronismvo: that works too, Recover = true = InstallMode10:07
pedronisRecovery10:07
mupPR 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
pedronisChipaca: does #7671 need a master merge?10:08
mupPR #7671: overlord/patch: normalize tracking channel in state <Channels 🏷️> <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7671>10:09
Chipacapedronis: ah, maybe; i'll look in a bit10:09
pedronisChipaca: I see things that I thought I reviewed already, but maybe I'm confused (that's possible)10:11
=== arnatious_ is now known as arnatious
zygasil2100, ogra: do you know who is maintaining the pi gadgets today10:20
zygadegville: 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 somewhere10:22
degvillezyga: 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:23
degville(as doc and boot assets are in pretty good shape)10:24
mupPR 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:45
mupPR 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:52
mupPR snapd#7789 closed: bootloader: add new bootloader.InstallBootConfig() <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7789>10:53
mvopedronis_: hopefully simple and then I can build on top of this10:53
=== pedronis_ is now known as pedronis
pedronismvo: commented10:55
mvopedronis: thank you!10:59
Chipacapedronis: ok if i rebase 7671?11:18
Chipacapedronis: i've rebased 767111:23
Chipacapedronis: it looks a lot more like a patch patch now11:24
mvopedronis: addressed your comments, thanks again11:32
sil2100zyga: hey! That's us (foundations), but it's basically waveform mostly11:35
zygasil2100: thanks, I'll reach out to him11:39
pedronisChipaca: thx, I will look in a bit11:44
pedronismvo: that's not the rename I proposed, I proposed to match what we use in the file (up to format)11:44
pedronis:)11:44
pedronismvo: ah, not the code is right, but the commit says another thing11:45
pedronismvo: +1 with some more comments, mostly about the tests11:51
mvopedronis: thank you, on it!11:53
mupPR snapd#7791 opened: snap-bootstrap: make cmdline parsing robust <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7791>11:53
mborzeckimvo: pedronis: i've updated #7788 please take a look12:05
mupPR #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
mborzeckineed to sort out my flights12:05
pedronismborzecki: thanks, will look in a bit12:06
pedronisChipaca: reviewed, maybe pstolowski can give a look too12:07
zygamborzecki: about flights, I looked at trains12:07
zygamborzecki: but it's a no-go because it's impossible to get tickets for a ride this distant12:08
zygamborzecki: assuming that train schedules don't change it's a whole-day trip with one stop in Berlin12:08
mborzeckizyga: and it's probably half a day12:08
zygamborzecki: and the price is very competitive with flying12:08
zygamborzecki: even if you consider first class actually12:08
zygamborzecki: but I decided not to use it because << 2 hours is meh-good-enough12:09
pstolowskipedronis, Chipaca will do12:09
zygamborzecki: there are a number of connections, some take over half a day and involve many stops, some are fast12:09
pedronismborzecki: done, thank you12:15
pedronismborzecki: have you looked at the other issue (installing core on a snapd-only system with defaults) or not yet?12:16
mborzeckipedronis: not yet, spent silly amount of time fighting the configstate handlers test12:17
mvo7790,7791 should be simple reviews and unblock some more of the early boot work12:18
* mvo considers lunch12:18
pedronismborzecki: lots of setup needed12:18
mborzeckipedronis: might have overdone it a little12:18
zygajdstrand: good morning12:18
mupPR 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:20
pstolowskipedronis, Chipaca will do12:24
pstolowskiups, wrong window12:25
zygamborzecki: 2nd +1 on https://github.com/snapcore/snapd/pull/7788#pullrequestreview-32294819612:40
mupPR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>12:40
mborzeckizyga: thanks12:41
zygaI'll make coffee and resume patches12:50
mborzeckicmatsuoka: 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
mupPR #7743: snap-bootstrap: force partition table operations <Simple πŸ˜ƒ> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>12:59
cmatsuokamborzecki: it's likely that it will be needed in the real case, I added snap-bootstrap to the spike and it required --force13:07
cmatsuokamborzecki: --force was completely under my radar until I tested it in a real scenario13:08
cmatsuokamborzecki: the same happened with the udev node creation, for some reason partx -u triggers node creation but blockdev --rereadpt doesn't13:09
cmatsuokamborzecki: I started to check the partx source code to see what exactly it's doing there, but it does quite a lot13:10
mborzeckicmatsuoka: interesting, i would guess that sfdisk handles that when it triggers the kernel to reread the partition table13:13
=== ricab is now known as ricab|lunch
mborzeckicmatsuoka: afaiu that's what partx does by doing a bunch of ioctls() though it passes an actual partition number there13:14
mborzeckicmatsuoka: 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 needed13:15
cmatsuokaI also tried to manually run udevadm trigger but it didn't do anything13:15
mborzeckicmatsuoka: was any paritition from taht device mounted at the time when sfdisk ran?13:16
cmatsuokaAccording to a comment in the partx source code, it needs a few ms to settle after the operation13:16
cmatsuokamborzecki: hmm, yes, it's possible that we had partitions mounted in initramfs13:18
cmatsuokamborzecki: ah, I guess core was mounted from seed directly at that point13:18
mborzeckicmatsuoka: that would explain why the disk was seen as 'used'13:18
cmatsuokamborzecki: yes, indeed. but we can't unmount everything, we need seed an boot13:19
cmatsuokaand boot13:19
mborzeckicmatsuoka: right, i guess there's no way around that, so --force seems ok13:22
mborzeckicmatsuoka: perhaps that's why you needed to call partx13:22
cmatsuokamborzecki: 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 there13:23
cmatsuokabut that would take some time to analyse13:23
mborzeckicmatsuoka: was there any mesage from fdisk? specificaly thinking https://github.com/karelzak/util-linux/blob/master/libfdisk/src/context.c#L833-L84013:23
cmatsuokamborzecki: no such message, the PT re-read was apparently successful13:25
mborzeckiheh, fun ;)13:25
cmatsuokathose real life problems are very annoying!13:26
cmatsuokaalso I hope that kernel 5.4 doesn't crash in firstboot, 5.3 did but I still didn't check why13:27
cmatsuokamborzecki: I think I should add an XXX note there13:31
mborzeckicmatsuoka: yup, sounds like a good idea13:32
cmatsuokamborzecki: doing that13:32
=== ricab|lunch is now known as ricab
mupPR 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:23
mborzeckianyone know of a tool that lists what desktop files are visible?14:35
mupPR 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:41
zygapedronis, mvo: I'll check if there are any open bugs that are related to nested mimics and see if they have regression tests14:47
mupPR 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:49
mupPR 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:58
Chipaca*gasp* i was supposed to wait for pstolowski :-(14:59
mvopedronis: 7792 should also be easy hopefully14:59
pstolowskiChipaca: i'm finishing it atm..14:59
Chipacapstolowski: please tell me it's not on fire :-|14:59
mborzeckimvo: pedronis: #7788 is green15:01
mupPR #7788: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>15:01
* cachio lunch15:18
threshhi.  cant launch chromium anymore, on debian: https://paste.debian.net/1118076/15:21
threshinstalled:   78.0.3904.108            (958) 160MB -15:21
threshany ideas? thank you.15:22
Chipacathresh: can you pastebin 'snap version' please?15:23
Chipacawho was it that was looking at the /sys/kernel/mm/transparent_hugepage/hpage_pmd_size thing15:24
threshsure thing.  there you go Chipaca: http://paste.debian.net/1118077/15:24
Chipacamvo: you do remember, offhand?15:24
Chipacayeah, 42 on a 5.315:24
Chipacathere was somebody looking at this, but i don't remember what the conclusion was15:25
Chipacajdstrand: is it expected that chromium tries to do things that would require hardware-observe?15:26
pedronisChipaca: I saw some chromium related stuff in some of recent jdstrand PRs15:26
pedronisnot sure it relates or not15:27
pedronismaybe he can say15:27
jdstrandChipaca: what things?15:27
Chipacajdstrand: looks like it's trying to read /sys/kernel/mm/transparent_hugepage/hpage_pmd_size15:27
Chipacaas per the pastebin above15:27
Chipacajdstrand: https://paste.debian.net/1118076/15:27
zygamvo: can you double check https://github.com/snapcore/snapd/pull/7773 please15:28
mupPR #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
zygamvo: it has +2 and as soon as it's green I'd like to merge it and open a backport for 2.42.315:28
jdstrandChipaca: seems like we need something added to PR 777915:29
mupPR #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
jdstrandChipaca: I'll do that in a bit15:29
Chipacajdstrand: is there something thresh can do to get unblocked?15:29
Chipacai'm guessing 'reboot into pre-5.3 kernel' would work but not be a nice way out15:30
jdstrandChipaca: oh, actually, that is snap-update-ns.chromium15:30
zygao/15:30
threshIt's not a big deal.  I use firefox mainly anyway.  Just something that is probably best reported & fixed :)15:30
Chipacathresh: <315:30
pedronisjdstrand: mvo is looking at doing a 2.42.3, it would be good to know if we need things in it for this15:31
jdstrandI'll look into that access. one could modify /var/lib/snapd/apparmor/profiles/snap-update-ns.chromium15:32
jdstrandthresh: ^15:32
jdstrandeg, 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
jdstrandthat only works until snapd refreshes the policy of course (then you'd have to do it again)15:33
jdstrandpedronis: ack15:33
Chipacajdstrand: thank you15:35
threshjdstrand, huh.  well that worked to remove the apparmor denial line from dmesg indeed.15:35
threshbut chromium still crashes with the same message15:35
threshso maybe those are not related.15:35
ChipacaoSoMoN: ^ is that a 'you' thing?15:36
Chipacathresh: at this point i'd say it's probably best to open a topic in forum.snapcraft.io, so it can be looked at async15:37
threshright15:37
Chipacaeither that or a good ol' bug :)15:37
Chipacabut forum is probably easier15:38
threshI'm going to try a different user / clean profile etc15:38
oSoMoNthresh, mind filing a bug at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+filebug ?15:38
mupPR snapd#7793 opened: devicestate: read modeenv early and store in devicestate <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7793>15:38
oSoMoNChipaca, the chromium snap is a 'me' thing indeed15:39
threshoSoMoN, I will, thanks!15:39
mupPR 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
ChipacaoSoMoN: :)15:39
mvozyga: sure, looking now15:39
* Chipaca grabs a cuppa tea and tries to stop eating biscuits15:39
ChipacaI visited my mum on sunday and cam back with a metric ton of chocolate chip15:40
Chipacasend help15:40
mupPR 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
zygaChipaca: send chocolate :)15:42
zygaChipaca: we should take preorders on treats for Fra15:43
ChipacaFra is three months away15:43
zygaChipaca: with everyone taking trains we can bring anything :)15:43
Chipacain fact, fra is two weeks before i run the lisbon half15:44
Chipacaso no treats!15:44
mvomborzecki: 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 message15:47
zygamvo: https://github.com/snapcore/snapd/pull/779415:49
* zyga goes for lunch15:49
mupPR #7794: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>15:50
mupPR 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
mupPR snapd#7794 opened: many: backport pull request #7773 from zyga/fix/lp-1852361 <Created by zyga> <https://github.com/snapcore/snapd/pull/7794>15:50
mupPR 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:55
mborzeckimvo: ^^15:57
ackkzyga, 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 store15:58
ackkzyga, any useful info I can gather ?15:58
zygaackk: oh my :D16:03
zygaackk: what what the exact error message?16:03
ackk$ maas16:04
ackkexecv failed: No such file or directory16:04
zygaackk: this is worrying, so it was not a "snap try" version16:04
ackkzyga, it's odd because every time I've seen it happen, it was just after I ran maas init16:04
zygaackk: did you have a snap-try version before though?16:04
zygaand then installed from the store on top of that?16:04
ackkzyga, that's a good question, I'm not sure16:05
mvomborzecki: \o/16:05
zygaackk: that might explain why16:05
mvopedronis: you mentioned another potential thing we need for .3 ?16:05
zygaackk: we actually landed a feature that might help16:05
ackkzyga, can I check somehow?16:05
zygaackk: it fixes a whole class of issues16:05
zygaackk: try edge when it builds please,16:05
ackkzyga, I would have an x1 dir if I had upgraded from try right?16:06
zygayes16:06
zygaor x$something16:06
ackkzyga, then no, I only have one revision16:06
ackk/o\16:06
zygaackk: any ideas on how to reproduce are welcome16:06
zygaackk: to finish that thought though: https://github.com/snapcore/snapd/pull/7773 is what I was referring to16:07
mupPR #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
zygaackk: it introduces snap set core experimental.robust-mount-namespace-updates=true16:07
zygaackk: which changes how mount namespace is updated16:07
ackkzyga, that's not yet in edge though?16:07
zygaondra: ^ btw, it landed, we're going to be good for release soon16:07
zygaackk: no, it's just in for a few minute16:07
ackkzyga, so, snapd edge ?16:08
ondrazyga 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
ackkzyga, and that snap set16:08
ackkzyga, is that valid for core18 as well?16:08
zygaackk: snapd edge or core edge once it builds16:09
zygaackk: it works across all versions16:09
ackkcool16:09
mborzeckipedronis: mvo: yeah, looks like we have a problem with subsequent install of core on a core18 device16:10
mvothanks zyga and mborzecki16:10
mvomborzecki: meh, do you have more details?16:10
zygaoh16:11
zygamborzecki: so more fixes for 2.42.x required?16:11
zygamvo: do you want to cherry-pick any of jdstrand's recent interface fixes?16:11
zygamvo: I can cherry-pick them back to offload you16:11
mborzeckimvo: pedronis: https://paste.ubuntu.com/p/mpV9Nr8v9H/16:11
mborzeckizyga: yes, think so16:11
mupPR 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:12
zygaijohnson: hey16:13
zygaijohnson: I'd like to land https://github.com/snapcore/snapd/pull/778316:13
mupPR #7783: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple πŸ˜ƒ> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>16:13
zygaijohnson: I explained why the suggestion doesn't work (ordering)16:13
ijohnsonsure let me take a look16:14
zygaijohnson: I'm happy to iterate on ideas but I'd like to merge this and unblock another PR16:14
zygaijohnson: so that the useful improved debug output from snap-update-ns doesn't get stuck/lost16:14
mupPR 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:16
zygadot-tobias: hey16:21
zygadot-tobias: please check out updates to https://bugs.launchpad.net/snapd/+bug/184449616:21
mupBug #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:21
mupPR 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:22
mvozyga: only if we really need them for .316:23
zygamvo: ok16:23
mvomborzecki: aha, so this is the defaults that get reapplied?16:24
pedronismborzecki: bad but expected16:31
pedronisthe fix should be simple as discussed16:31
pedronisin snapstate16:31
mvopedronis: that's not .3 criticial, is it?16:32
ijohnsonzyga: approved, but please note my response :-) thanks16:32
zygalooking16:32
zygaand thank you :)16:32
mvopedronis: did you mention earlier anything else criticial for .3?16:32
pedronismvo: jdstrand was looking into chromium failing in some places with denials16:34
jdstrandmvo: when do you expect 2.43 to go out? I ask cause ondra needs raw-volume soon and PR 7779 is also interesting16:34
mupPR #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
jdstrandmvo: (these might be candidates for .3)16:34
mvojdstrand: we do a .3 today/early tomorrow, once that is in candidate I will branch 2.4316:35
jdstrandmvo: so, a couple of weeks?16:36
jdstrandmvo: https://github.com/snapcore/snapd/pull/7777 would be nice for people to have16:36
mupPR #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
jdstrandmvo: that is a real clean cherrypick16:36
mupPR 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
mvojdstrand: 2.43 is ~4 weeks away16:37
zygaijohnson, mborzecki: https://github.com/snapcore/snapd/pull/7784 is no longer stacked. It's not urgent though16:37
mupPR #7784: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>16:37
ijohnsonzyga: yes will review after I submit a PR changing that to a list for you :-)16:38
mvojdstrand: 7777 is merged16:38
zygaijohnson: sounds great :)16:38
zygamvo: let's cherry pick it16:38
jdstrandmvo: ah, cool16:39
mvozyga: cherry pick which one?16:39
mvozyga: I cherry picked 777716:39
jdstrandpedronis: I added the comment to https://github.com/snapcore/snapd/pull/777916:39
mupPR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>16:39
zygamvo: ah, perfect16:40
zygayeah, that one16:40
zygait's just a pair of denials for something that is not allowed16:40
jdstrandpedronis: assuming you are happy with it, this would be a candidate for 2.42.3 for mvo imho16:40
zygamvo: and cuts logging16:40
pedronisjdstrand: which one?16:41
pedronis7779 ?16:41
jdstrandondra: 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:41
jdstrandpedronis: 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
ondrajdstrand it's not time critical as they are using system-files. And switching would need to be added to customers dev cycle16:42
ondrajdstrand so I'd not gate 2.43 with it16:42
jdstrandpedronis: I also updated PR 7768 (raw-volume), but per ondra, this is not critical for 2.42.316:43
mupPR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>16:43
ondrajdstrand and thank you for working on it. I really like the PR16:43
jdstrandondra: cool, yw16:45
pedronisjdstrand: looking at 7779 in a short bit, having parallel discussions16:45
jdstrandmvo: I'm investigating thresh' denial, but it isn't critical and will be in a separate PR16:45
jdstrandmvo: ie, I might have a small PR. I'm not changing 777916:46
jdstrandmvo: in case it wasn't clear. ignore PR 7768 (raw-volume) for 2.42.316:46
mupPR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>16:46
pedronisjdstrand: done with 7779, it's ok for .3 for me, if you are comfortable with that yourself16:47
mvojdstrand: thanks! ok, please tag everything you want for 2.42 with the 2.42 milestone16:49
pedronisjdstrand: thanks for the work on raw-volume, I will re-review it,  not today though given is not a blocker16:49
jdstrandmvo: ok, https://github.com/snapcore/snapd/pull/7779 updated, though it has to run through spread for the comment update that was requested16:50
jdstrand(that is happening now)16:50
mupPR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7779>16:50
mupPR snapcraft#2822 opened: xattrs: ignore errors if SNAPCRAFT_BUILD_INFO is unset <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2822>16:57
mupPR snapcraft#2823 opened: xattrs: switch to python's os package for reading/writing xattrs <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2823>16:57
mupPR 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
jdstrandmvo: ok, PR 7798 milestoned for 2.42.317:01
mupPR #7798: interfaces/browser-support: allow reading status of huge pages <Simple πŸ˜ƒ> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7798>17:01
zygajdstrand: FYI, there's a corresponding launchpad milestone, if there are bugs you can have them target that release17:02
jdstrandzyga: ack17:03
mvojdstrand: thank you17:04
zygabrb, tea17:08
pedronismvo: what are the next UC20 PRs that need review?17:11
mvopedronis: 7792 should be an easy one17:15
mvopedronis: then 7793 which is also easy17:15
mvopedronis: and 7797 should also be easy, I tried to make them all bite-size :)17:15
mvopedronis: once 7793 is in I will do one more and then help with 776217:16
pedronismvo: thanks, not sure how much more I will do tonight, but at least I know where to start tomorrow17:21
=== pstolowski is now known as pstolowski|afk
mupPR 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:31
ijohnsonzyga: alright here you go https://github.com/snapcore/snapd/pull/7799 I even benchmarked it for you :-)17:40
mupPR 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
mupPR #7799: osutil/mount: de-duplicate code to use a list <Simple πŸ˜ƒ> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7799>17:40
jdstranddegville: 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/774417:58
mupPR snapd#7800 opened: tests: add Ubuntu Eoan to google-sru backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7800>18:21
jdstrandogra: hey, are there some official (or at least, something you use) docs for booting a rpi off of usb hard drive?18:34
jdstrandogra: googling finds me stuff, but I don't know if I should trust it18:34
zygaijohnson: how would it perform if you added a break on flags == 0?18:39
ijohnsonzyga: hmm, let me see18:39
ijohnsonzyga: 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 cases18:40
ijohnsonzyga: 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
ijohnsons/wirld/wild/18:41
zygaijohnson: zero mid-loop18:42
zygaIt will usually have one or two flags18:42
ijohnsonah I see what you mean18:42
zygaijohnson: we could even reorder flags to put most common first18:44
zygaijohnson: thank you for doing that18:44
ijohnsonyes good point if we are going to break early then putting most common flags first makes a lot of sense18:44
zygaijohnson: sorry for being absent18:45
zygaijohnson: I'll show you what I was doing18:45
ijohnsonzyga: don't worry about it18:45
threshoSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1854091 there you go18:46
mupBug #1854091: [snap] traps on start <chromium-browser (Ubuntu):New> <https://launchpad.net/bugs/1854091>18:46
threshoSoMoN, let me know if I can provide any more information.  thank you!18:46
zygaijohnson: https://twitter.com/zygoon/status/119939909639985971218:46
ijohnson:-) seems like a better use of time than looking ay my silly optimizations of a couple nanoseconds18:47
mvopedronis: thank you!18:52
zygamvo: gadget update pc fails on the release branch18:53
zygamvo: I think we need to backport the fix for that one first18:53
mvozyga: uh, right. are you on this or shall I have a look?18:53
zygaI'll find it and send it18:53
zygamvo: just woke up :)18:53
=== ricab_ is now known as ricab
zygadone18:56
mupPR 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>18:56
murthywhy mojo video decoder is not enabled for chromium snap?19:01
mvozyga: thank you!19:13
mupPR 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:26
jdstrandmvo: erf, ^ needed for master19:27
jdstrandmvo: basically, something changed out from under the system-backup PR and the tests weren't re-run before committing. this fixes that19:29
murthyReference article: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-73-Linux-Mojo-Video-Dec19:31
murthyaccording to the above article chromium has enabled mojo video decoder by default on windows19:32
murthyand chromium provides hardware acceleration for video playback via mojo video decoder19:33
murthyThis is the bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=52229819:33
murthyAccording to the Comment 51 in the bug tracker you can enable mojo decoder by setting the gn arg of "use_vaapi" to true19:35
murthyduring compilation I mean19:35
ChipacaoSoMoN: ^19:35
pedronisjdstrand: yes, our CI is fragile to that, it's a good idea to merge master in any long lived PR19:39
jdstrandpedronis: yeah, that is what I was thinking :\19:40
oSoMoNthresh, Chipaca:Β thanks19:45
mvojdstrand: thank you19:48
mupPR snapcraft#2824 opened: Support for go.mod <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2824>19:49
mvothanks zyga for 780119:49
zyga:)19:49
ijohnsonoh zyga btw adding a check in the loop slows everything down oddly enough :-(19:52
ijohnsonhttps://www.irccloud.com/pastebin/F2LyBHTL/19:53
vidal72[m]murthy: do you know any distro that enabled that option? I assume it's disabled for a reason19:55
murthyvidal72[m]: probably fedora19:57
vidal72[m]murthy: nope, see comment https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_181019:58
vidal72[m]https://src.fedoraproject.org/rpms/chromium/blob/master/f/chromium.spec#_2319:58
vidal72[m]I don't think it's worth hitting all regressions others had with vaapi20:00
vidal72[m]without upstream support this is hopeless20:00
vidal72[m]murthy: Arch linux also disabled vaapi after trying it https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=493cb5bf7b8453f628ee74ae75add8699ad244f020:04
murthyvidal72[m]: It only enables mojo video decoder, users have to enable the "Override software rendering list" flag to enable hardware acceleration using vaapi20:04
murthychecking20:05
murthyIt seems they had specifically reverted that patch20:09
vidal72[m]heh20:09
vidal72[m]RIP vaapi :(20:10
murthyIts just that I tried a chromium build from an an unofficial ppa and it seems stable20:10
murthyvidal72[m]: Intel is not doing a good job for Linux20:10
vidal72[m]I think it depends on hardware20:10
murthyright20:11
murthyMine is a kabylake20:11
vidal72[m]intel is still miles ahead of amd and nvidia :)20:11
murthywhat?20:11
vidal72[m]I heard that most vaapi issues come from amd20:12
murthyvidal72[m]: also downstream packaging restrictions20:13
murthyThis is the article that said vaapi was enabled in fedora https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Snaps-Chromium-VA-API20:14
murthyphoronix fellows know how to get the clicks20:14
vidal72[m]murthy: then enabled it then disabled, same as Arch20:14
vidal72[m]*they20:14
murthyya20:14
murthyDo you know this ppa? Can I trust it? https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-beta20:16
vidal72[m]I don't know it20:16
murthyok20:18
murthyvidal72[m]: Thanks for the support20:18
zygamvo: is master still broken20:33
zygaI can jump into that20:34
* zyga checks20:35
zygaheh20:38
zygafunny20:38
mvozyga: didn't jamie fix this?20:42
zygaah, I see20:42
mvozyga: unit test failure it seems, fun20:42
zygaI'll send a useful patch nonetheless20:42
zygawe have some leftover junk20:43
mvozyga: invalid title20:43
mvozyga: fun!20:43
mvozyga: restarted the build20:43
zygaeh20:43
zyga:D20:43
zygamust be OMG RELEASE DAY20:43
mvozyga: haha yes20:44
zygamvo: https://github.com/snapcore/snapd/pull/780320:49
mupPR #7803: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>20:49
mvozyga: nice, thank you20:49
mupPR snapd#7803 opened: interfaces: remove reservedForOS from commonInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/7803>20:49
zygamvo: meanwhile https://github.com/snapcore/snapd/pull/7801 is still yellow20:50
mupPR #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
mvozyga: yeah, it's a bit sad20:50
zygaabout 20 minutes left20:50
zygaif it passes20:51
mvozyga: I call it a day, hopefully in 8h when I'm up again the world is less red20:51
zygayeah20:51
zygaI'll merge and restart anything I can20:51
zygamvo: can I merge stuff into the release branch with one review?20:51
zygamvo: it could be all merged for you in the morning20:51
mvozyga: I think that's fine, strict backports just need one review20:51
zygaok20:51
zygatechnically https://github.com/snapcore/snapd/pull/7801 is not reviewed20:51
zygathat's the fix to unbreak others :)20:52
mupPR #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
mvozyga: refresh please20:52
zyga\o/20:52
zygathanks!20:52
zygaI had a nap so I can work for the next 45 minutes20:52
zygaif that helps tomorrow that's useful20:53
zygatomorrow I'm back to feature work20:53
zygaI have some follow ups for the update-ns that pedronis suggested20:53
zygabut we have enough open PRs now20:53
mvozyga: 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
zygayeah20:53
zygaI totally will :)20:53
* mvo hugs zyga and vanishes 20:54
zygao/20:54
=== heather is now known as hellsworth
sdhd-saschaChipaca: i have trouble with upload to the store. But yesterday i could start sway in classic mode. It's on github21:03
* cachio afk21:17
zygaoh for crying out loud ....21:31
zygatimeout21:32
ijohnsonhey zyga, looks like I missed some stuff that happened while out to lunch, what can I help review to unbreak master/critical things?21:39
zygaijohnson: it's all fixed now, jdstrand sent a followup PR21:40
zygawe're just waiting for things to be less red21:40
ijohnsonzyga: ack ok21:40
zygaanother one failed21:50
zygaI'll call it a day21:50
ijohnsongood night zyga, see you tomorrow21:52
mupPR 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
jdstrandijohnson: ^22:25
ijohnsonRight, nice22:26
cmatsuokadevicestate tests are very intersting, but it's time to call it a day23:04

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