[05:20] <mborzecki> morning
[05:50] <mup> PR snapd#8868 closed: interfaces: add system-source-code for access to /usr/src <Needs Samuele review> <Reviewed> <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8868>
[05:55] <mup> PR snapd#8909 closed: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs Samuele review> <Needs security review> <Reviewed> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8909>
[06:22] <zyga> hello
[06:23] <mborzecki> mvo: zyga: hey
[06:23] <mvo> mborzecki: good morning
[06:24] <zyga> FYI we ran out of memory yesterday at 14:00
[06:24] <zyga> I've set memory caps on each node now
[06:24] <zyga> we are a bit over-comitted still though
[06:24] <zyga> gp + node + c# can peak at 500MB for processing text
[06:24] <zyga> go*
[06:25] <mborzecki> zyga: gh action runner uses go and node too?
[06:25] <mup> PR snapd#8955 closed: tests/lib/pkgdb: do not use quiet when purging debs <Precious Logs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8955>
[06:28] <zyga> mborzecki: it's worse
[06:28] <zyga> mborzecki: it uses node to "supervise" a c# app
[06:28] <zyga> which embeds a js intepreter for actions
[06:28] <zyga> it's like the worst of the ideas together as far as memory goes
[06:29] <zyga> each container is now running with a hard limit of 512M
[06:29] <zyga> I will also enable swap as the memory usage is bursty, peak is <500 but average is just 250
[06:30] <zyga> at the time when it happened we had pretty much the worst case scenario, all workers woke up to process things
[06:30] <zyga> and at the time they all use the most memory
[06:32]  * zyga will start in 30
[06:32] <zyga> meds still kicking in
[06:34] <mborzecki> zyga: 'enterprise grade'
[06:35] <zyga> don't give them ideas to add java for logigng
[06:35] <mborzecki> hahah log4j ftw
[06:59] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/8961#pullrequestreview-441396255
[06:59] <mup> PR #8961: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8961>
[06:59] <mborzecki> oh, if you have open PRs, try merging master, some changes that could  help debugging the purge problem landed in the morning
[07:03] <pstolowski> morning
[07:09] <mvo> good morning pstolowski
[07:13] <zyga> mborzecki: ok
[07:13] <zyga> mborzecki: thank you for the review
[07:40] <mup> PR snapd#8954 closed: tests: tweak comments/output in uc20-recovery test <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8954>
[07:58] <zyga> brb, reboot
[08:02] <zyga> re, had to reboot because touchpad went crazy
[08:58] <mborzecki> pedronis_: https://github.com/snapcore/snapd/pull/8569 is still blocked on the store side?
[08:58] <mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <⛔ Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
[08:59] <pedronis> mborzecki: yes, still blocked
[08:59] <mborzecki> ack
[09:00] <mborzecki> time to read about validation sets
[09:09] <mborzecki> mvo: quiet swallowed up purge errors? https://paste.ubuntu.com/p/49jNNMjb4P/
[09:10] <mvo> mborzecki: in a meeting still but will look in a sec
[09:11] <mvo> mborzecki: wuut, why is this not a real error?
[09:11] <mup> PR snapd#8963 opened: tests: rename invariant-tool to tests.invariant <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8963>
[09:11] <zyga> maybe quiet bug
[09:11] <zyga> or bug in our packaging helper functions
[09:12] <mborzecki> i mean a trvial `quiet sh -c 'echo foobar; false'` works as expected, prints the error output
[09:14] <zyga> mborzecki: maint script -e ?
[09:15] <mborzecki> heh, so more than one prepare failed: https://paste.ubuntu.com/p/j9wsRWHxJw/
[09:15] <mborzecki> one purge succeeded in the snse that apt did not return an error but /var/lib/snapd was still there
[09:16] <mup> PR snapd#8964 opened: tests: rename version-tool to version-compare <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8964>
[09:16] <mborzecki> this is nice: dpkg: warning: while removing snapd, directory '/var/lib/snapd/apparmor' not empty so not removed
[09:16] <mborzecki> and that's right after purge
[09:18] <zyga> mborzecki: rm -f
[09:19] <zyga> I cannot do that Dave
[09:21] <mup> PR snapd#8965 opened: tests: rename memory-tool to memory-observe-do <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8965>
[09:31] <zyga> popey: o/
[09:31] <mup> PR snapd#8966 opened: tests: rename mountinfo-tool to mountinfo.query <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8966>
[09:31] <zyga> popey: do you know who should I talk to so to get browser snaps to adopt a new interface?
[09:34] <zyga> popey: they context is this bug https://bugs.launchpad.net/snapd/+bug/1875860/comments/3
[09:34] <mup> Bug #1875860: local documentation is not accessible from the chromium snap <regression> <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1875860>
[09:41] <mup> PR snapd#8967 opened: tests: rename apt-tool to apt-state <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8967>
[09:54]  * zyga found a bug in apt-state (nee apt-tool)
[09:54] <zyga> drat, I'm out of disk space
[09:54] <zyga> sight
[09:55] <zyga> sigh even :)
[10:00] <mborzecki> mvo: merged master and pushed a little tweak to #8883
[10:00] <mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
[10:00] <mvo> mborzecki: thank you
[10:03] <zyga> pedronis: since README was added we grew one more helper, cleanup-state, I'm inclined to keep it off of PATH and just keep the current name, WDYT?
[10:04] <pedronis> zyga: seems fine at least for now
[10:04] <zyga> ok
[10:04] <zyga> it's used in one file in three places IIRC
[10:10] <popey> zyga oSoMoN maintains chromium, kenvandine can help with firefox.
[10:10] <zyga> popey: superb, thank you!
[10:10] <popey> np
[10:10] <zyga> do you know anyone from brave?
[10:11] <zyga> oSoMoN, kenvandine: can you please look at https://bugs.launchpad.net/snapd/+bug/1875860/comments/3 or point me to the sources, I'm happy to send PRs that edit the snapcraft.yaml
[10:11] <mup> Bug #1875860: local documentation is not accessible from the chromium snap <regression> <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1875860>
[10:16] <oSoMoN> zyga, cool, I'll add the plug to chromium, thanks! how will this work for earlier versions of snapd, are unknown plugs silently ignored?
[10:17] <zyga> oSoMoN: unknown interfaces are sliently ignored
[10:17] <zyga> *silently
[10:17] <zyga> but please ask jdstrand to ensure that the interface is recognized by review-tools
[10:24] <zyga> mvo: that's something for you, just one line, https://github.com/snapcore/snapd/pull/8968
[10:24] <mup> PR #8968: tests: fix call to apt.Package.mark_install(auto_inst=True) <Bug> <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8968>
[10:26] <mup> PR snapd#8968 opened: tests: fix call to apt.Package.mark_install(auto_inst=True) <Bug> <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8968>
[10:28] <mvo> zyga: thanks, in a meeting
[10:29] <zyga> sure
[10:29]  * zyga will return to reviews and push forward on branches after a small break
[10:31] <mup> PR snapd#8853 closed: asserts: introduce the concept of sequence-forming assertion types <Simple 😃> <validation-sets :white_check_mark:> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8853>
[10:32] <mborzecki> pedronis: since 8853 landed, i've merged master to #8906
[10:32] <mup> PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
[10:33] <zyga-x240> mborzecki: do you think we can do something about the centos8 failing test
[10:33] <zyga-x240> maybe mark it as xfail
[10:33] <zyga-x240> and only fail if it passes, so that we know
[10:33] <mborzecki> zyga-x240: let me look at that test today, wanted to tweak it to make the calls to ausearch smarter
[10:33] <zyga-x240> thanks!
[10:52] <ogra> xnox, here is another one forwarded from my custmer https://github.com/snapcore/core18/issues/158 (i'd pay your beer/drinks for the whole next sprint we meet if you'd have an idea how we get rid of all that timedatectl hackery once and for all btw)
[10:54] <mup> Issue core18#158 opened: quoting fix for timedatectl wrapper got lost between core16 and core18 <Created by ogra1> <https://github.com/snapcore/core18/issues/158>
[10:54] <mup> PR core18#159 opened: 030-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <https://github.com/snapcore/core18/pull/159>
[11:00] <mup> Bug #1886033 opened: end.psplash.service results in failed state on UC18 devices <Snappy:New> <https://launchpad.net/bugs/1886033>
[11:04] <xnox> ogra:  customers must use salesforce, and escalate to foundations using that.
[11:05] <xnox> ogra:  pinging me directly is not the right process.
[11:05] <xnox> ogra:  plus i don't maintain systemd =/ and most of srus are handled by sts anyway.
[11:05] <xnox> ogra:  what is the correct process for escalations?
[11:05] <ogra> well, sorry ... deadline is near and customer works directly with me on a daily basis
[11:06] <ogra> this is a general bug though, affecting all core18 users, ignore that i'm saying "customer" all the time
[11:06] <xnox> ogra:  ok, so there is no SLA for it, right?
[11:07] <ogra> well, they are probably the first user we have not using the network at all, so this went unnoticed until someone needs to set the time manually ... there are SLAs but i'm helping them to work around the issues ... but along the way i capture them in bugs
[11:08] <ogra> ... so we get general fixes ...
[11:10] <xnox> ogra:  also i don't even have commit access to core18
[11:10] <xnox> ogra:  so really i'm not the droid you are looking for
[11:10] <xnox> =(
[11:10] <ogra> wow
[11:10] <ogra> i thought you're da man for core18 onwards
[11:10] <ogra> sorry then 😞
[11:11]  * xnox only did core20 & ubuntu-core-initramfs => but even that I can't really release much, as it's kernel team that vendorize my initrds.
[11:11] <ogra> while i get why we do this it would really be halpful to have one master person owning it ...
[11:12] <ogra> someone who supervises the whole of UC
[11:12] <pedronis> mborzecki: thanks
[11:45] <zyga-x240> rere
[11:46] <mborzecki> damn, can't seem to be able merge any of my PRs today, random tests failing
[11:47] <zyga-x240> thank you for the reviews everyone!
[11:47] <zyga-x240> mborzecki: use the force, ask mvo
[11:47] <zyga-x240> but yeah, I have some failures in each PR
[11:47] <mborzecki> duh, last one: rror restoring google:ubuntu-core-20-64:tests/lib/tools/suite/tests.session:root (jul021038-575770) : read tcp 10.113.57.72:47444->34.73.187.217:22: use of closed network connection
[11:48] <mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/8930 ?
[11:48] <mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
[11:48] <zyga-x240> hmmm
[11:51] <zyga-x240> mborzecki: nothing in logs, maybe just bad day wrt traffic?
[11:56] <mborzecki> zyga-x240: idk, maybe the host just died (?)
[11:56] <zyga-x240> mborzecki: maybe we did run out of memory but this time i a more reliable way
[11:57] <zyga-x240> mborzecki: let's see how it behaves, I can tweak things later today
[11:57] <zyga-x240> mborzecki: I'm still thinking if I should add swap
[11:58] <mborzecki> zyga-x240: oom again?
[11:58] <zyga-x240> mborzecki: well, it's a heavy stack
[11:58] <mborzecki> heh
[11:58] <zyga-x240> mborzecki: but I have no proof of that, no oom in logs
[11:58] <zyga-x240> mborzecki: we're at 4.35/8GB now
[11:59] <zyga-x240> so hardly oom
[11:59] <zyga-x240> mborzecki: can you do a pass over the green rename PRs pleaes
[11:59] <zyga-x240> I'd love to merge them and they have mostly one review
[11:59] <zyga-x240> er, only one green tick
[12:00] <zyga-x240> woah, core20 tests took 104 minutes
[12:00] <zyga-x240> https://github.com/snapcore/snapd/pull/8965
[12:00] <mup> PR #8965: tests: rename memory-tool to memory-observe-do <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8965>
[12:00] <zyga-x240> I'm sure glad we're not with the enforced 60 minute limit anymore
[12:06] <mup> PR snapd#8930 closed: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8930>
[12:06] <mborzecki> mvo: thank you!
[12:28] <mvo> mborzecki: my pleasure
[12:36] <mup> PR snapd#8967 closed: tests: rename apt-tool to apt-state <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8967>
[12:37] <mborzecki> https://github.com/snapcore/snapd/pull/8956 is no longer blocked and needs reviews yay
[12:37] <mup> PR #8956: tests/core/gadget-update-pc: port to UC20 <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8956>
[12:38] <pstolowski> cachio: hi, is nested/preseed test happy these days?
[12:39] <cachio> pstolowski, hi
[12:39] <cachio> let me check
[12:40] <cachio> pstolowski, yes, at lest last night passed
[12:41] <cachio> 19.10 and 20.04
[12:41] <pstolowski> ok, ty
[12:44]  * zyga-x240 is dizzy after meds
[12:46] <mborzecki> cmatsuoka: hi, is https://github.com/snapcore/snapd/pull/8919 ready for reviews?
[12:46] <mup> PR #8919: gadget/install,secboot: test if the tpm can be provisioned <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8919>
[12:48] <cmatsuoka> mborzecki: I'm verifying if the status flags are correct, the results on the real tpm are a bit strange
[12:48] <cmatsuoka> mborzecki: I would expect the EK bit to be set, but I get the DA bit instead after clearing the tpm
[12:49] <cmatsuoka> mborzecki: also chris is considering to change the way the status is reported
[12:54] <mup> Issue core18#160 opened: end.psplash.service results in failed state on UC18 devices <Created by jocave> <https://github.com/snapcore/core18/issues/160>
[12:57] <zyga-x240> random test panic on master: https://paste.ubuntu.com/p/jQVhDFFnjm/
[12:57] <zyga-x240> ... Panic: cannot add test assertions: model assertion timestamp outside of signing key validity (key valid since "2020-07-02 12:20:44 +0000 UTC") (PC=0x42F2F4)
[12:58] <zyga-x240> Thu, 02 Jul 2020 12:25:16 GMT PANIC: api_users_test.go:734: userSuite.TestPostCreateUserFromAssertionNoModel
[12:58] <zyga-x240> (note that the first timestamp is from github and uses GMT while the second one uses UTC)
[12:58] <zyga-x240> are those the same?
[12:59] <zyga-x240> the failure comes from https://github.com/snapcore/snapd/pull/8964/checks?check_run_id=830484471 which is entirely unrelated
[12:59] <mup> PR #8964: tests: rename version-tool to version-compare <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8964>
[13:02] <zyga-x240> pedronis: ^ perhaps something you are interested in
[13:23] <Psil0Cybin> hey folks, quick question i have an app i want to install, seems like the app creators do not have atar.gz file or anything similar they require people to install the software via snapd, does it make sense to install snapd just for one piece of software?
[13:24] <oerheks> Psil0Cybin, yes, if you want this software
[13:25] <Psil0Cybin> ok since im new to this concept of snap is it just a repo, or if its running a daemon is it communicating with the web 24/7?
[13:26] <oerheks> snapd just checks one a day for updates, in the background when you start a snap.
[13:26] <oerheks> nothing funny about that.
[13:29] <mborzecki> mvo: the failures in prepare are in https://github.com/snapcore/snapd/pull/8883/
[13:29] <mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
[13:32] <Psil0Cybin> oerheks, okay thanks
[13:32] <Psil0Cybin> Just wanted to learn, I mostly like to keep my linux box's as minimal as possible , thats why I just got confused what "snapd" is technically since we already have repos, or the software center in terms of Ubuntu.
[13:33] <mvo> mborzecki: thank you, looking in a bit. fwiw quiet.sh looks a bit suspicous, I would not be surprised if it mishandles exit
[13:33] <oerheks> see snapd as the new PPA, but for all distros that support snapd
[13:33] <oerheks> easier distribution, maor control.
[13:33] <mborzecki> mvo: othing obviously wrong there though
[13:34] <mvo> mborzecki: uh, it looks all wrong actually
[13:37] <mup> PR snapd#8963 closed: tests: rename invariant-tool to tests.invariant <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8963>
[13:42] <zyga-x240> I've reproduced the connection dropping issue now
[13:42] <zyga-x240> the only mystery is why we have broken core
[13:42] <mvo> mborzecki: it's not all wrong, I misread
[13:42] <zyga-x240> I will look at how that works next
[13:56] <zyga-x240> opensuse 15.2 is released
[14:05] <zyga-x240> mborzecki, mvo: so is quiet.sh buggy?
[14:05] <zyga-x240> can we rewrite it in python yet?
[14:06] <mborzecki> zyga-x240: i'm not quite sure it's buggy, doesn't look like it
[14:06] <mborzecki> but hey, it's shell, so who knows ;)
[14:06] <zyga-x240> haha, right :)
[14:06] <zyga-x240> I'm just curious to learn what it was in the end
[14:06] <zyga-x240> I'm digging another issue
[14:07] <mborzecki> zyga-x240: from what i can tell, is that we do systemctl stop  ... snapd.service .. in prerm (with a batch of services in one go), but later when postrm runs, snapd appears to be still running
[14:09] <zyga-x240> hmmm
[14:14] <luisp> :sp
[14:14] <luisp> (sorry, wrong window)
[14:17] <mup> PR snapd#8965 closed: tests: rename memory-tool to memory-observe-do <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8965>
[14:36] <mborzecki> time to run some errands
[14:53] <jdstrand> pstolowski: hey, just checking that my comment on PR 8939 made sense
[14:53] <mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
[14:53] <jdstrand> (about static devices)
[14:55] <zyga-x240> jdstrand: thanks for that, I missed this
[14:56] <zyga-x240> jdstrand: the rewrite I did handled that case differently and I didn't remember how it worked here before
[14:56] <zyga-x240> jdstrand: I will spend some time to polish the rewrite so that we can merge it
[14:57] <pstolowski> jdstrand: yes, thank you! i looked at systemd/udevd code with hope of finding something special about these devices but couldn't find anything. your suggestion sounds very sensible, i'll change this
[14:57] <jdstrand> cool :)
[14:58] <jdstrand> pstolowski: fyi, I made a teensy update to the initialization suggestion (see https://github.com/snapcore/snapd/pull/8939#pullrequestreview-441127367)
[14:58] <mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
[14:58] <pstolowski> jdstrand: ack, thanks for that
[14:58] <jdstrand> pstolowski: their not special in the sense of the system, but they are special in how snapd handles them, since we expect every snap to have them, we don't need to tag them
[14:59] <jdstrand> their? they're*
[15:00] <jdstrand> pstolowski: and since we aren't tagging them, we don't need the udev lookup up either and https://www.kernel.org/doc/Documentation/admin-guide/devices.txt defines these for everyone, so we can just hard code
[15:00] <jdstrand> anyhoo, thanks! :)
[15:00] <pstolowski> jdstrand: yes, your suggestion makes sense regardless of the race problem
[15:01] <jdstrand> pstolowski: I got bonus points! :)
[15:02] <jdstrand> I mean, if the sys path udev lookup was not racy (like we thought it was), it's fine, but yeah, I like not having to hit the library for those 8 devices
[15:02] <zyga-x240> https://github.com/snapcore/snapd/pull/8966 needs a second review
[15:02] <mup> PR #8966: tests: rename mountinfo-tool to mountinfo.query <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8966>
[15:02] <jdstrand> oh, I can now say I contributed to performance speedups :)
[15:03] <zyga-x240> jdstrand: about this, do you think you will have time to spend with me next week on this?
[15:03]  * jdstrand shaved 0.0037 seconds off of startup
[15:04] <jdstrand> zyga-x240: I'm sorry, what is 'this'?
[15:04] <jdstrand> zyga-x240: the snap-device-helper rewrite?
[15:04] <zyga-x240> jdstrand: ah, sorry, I mean the rewrite of snap-confine that changes how we use snap-device-helper:
[15:04] <zyga-x240> https://github.com/snapcore/snapd/pull/7614
[15:04] <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
[15:04] <zyga-x240> I kind of left it there but I think it's close and should be resurrected
[15:06] <jdstrand> zyga-x240: next week? doubtful due to the sprint. I also need to help joedborg, et al (eg, maybe Ian) on figuring out why microk8s isn't working right in devmode and to help the openstack team with microstack interfaces
[15:07] <zyga-x240> jdstrand: ok, in that case I'll just polish it and refresh a bit and try to grab you after the sprint
[15:08] <jdstrand> zyga-x240: iirc, PR 7614 is not roadmapped so it is going to have to fall behind these other two... unless you can convince amurray to work with you on it (amurray, if so, recall that I'd like to do a final review before committing)
[15:08] <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
[15:09] <jdstrand> zyga-x240: note, I'm off Mon and Tue the week after the sprint and will be focusing on microk8s and microstack at least into the next week. if the snap-device-helper stuff is roadmapped and/or this is blocking other stuff, please talk to mvo and we can all discuss with joeubuntu and amurray the next steps
[15:18] <pstolowski> zyga-x240: what version of clang-format do you use for snap-confine? v10 isn't happy about our .clang-format
[15:19] <zyga-x240> pstolowski: hmmm, good question
[15:19] <zyga-x240> pstolowski: try make fmt
[15:19] <zyga-x240> it's not one formatter
[15:19] <zyga-x240> some files use indent, others use clang-format
[15:20] <zyga-x240> pstolowski: it's not perfect so I gave up on it somewhat
[15:20] <zyga-x240> pstolowski: I think using clang-format would be good but I don't want to force re-format everything
[15:20] <pstolowski> zyga-x240: that's fine. i was worried about tests failing on format, but it seems we don't do that for C code
[15:20] <zyga-x240> no, it's disabled now
[15:27] <zyga-x240> https://github.com/snapcore/snapd/pull/8966 needs a second review
[15:27] <mup> PR #8966: tests: rename mountinfo-tool to mountinfo.query <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8966>
[15:46]  * cachio lunch
[15:50] <oSoMoN> jdstrand, does the system-packages-doc plug need to be added to review-tools for snaps using it to pass review?
[15:50] <pstolowski> zyga: i've requested your re-review of #8939 due to ths change
[15:50] <mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
[15:56] <zyga-x240> re
[15:56]  * zyga-x240 put his thinkpad into the freezer 
[15:56] <pstolowski> zyga-x240: it seems #8961 can land
[15:56] <mup> PR #8961: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8961>
[15:57] <mup> PR snapd#8961 closed: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8961>
[15:57] <mup> PR snapd#8966 closed: tests: rename mountinfo-tool to mountinfo.query <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8966>
[15:57] <mup> PR snapd#8968 closed: tests: fix call to apt.Package.mark_install(auto_inst=True) <Bug> <Simple 😃> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8968>
[16:01] <cachio> pedronis, hey, I already updated the #8949, could you please take a quick look to see if we can unblock it? thanks
[16:01] <mup> PR #8949: tests: new fs-tool which replaces the files.sh helper <⛔ Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8949>
[16:13] <pedronis> cachio: I don't have time to do a full review but the name is good, so unblocking it
[16:16] <pedronis> cachio: I made a comment also in #8950
[16:16] <mup> PR #8950: tests: new str-tool which replaces the strings.sh helper <⛔ Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8950>
[16:20] <cachio> pedronis, thanks
[16:22] <mup> PR snapd#8969 opened: tests: fix argument handling of apt-state <Created by zyga> <https://github.com/snapcore/snapd/pull/8969>
[16:42] <mup> PR snapd#8970 opened: tests: rename user-tool to user-state, fix --help <Created by zyga> <https://github.com/snapcore/snapd/pull/8970>
[16:42] <mup> PR snapd#8971 opened: tests: rename lxd-tool to lxd-state <Created by zyga> <https://github.com/snapcore/snapd/pull/8971>
[16:53] <zyga-x240> all the tools are converted now, we just need to land this
[16:53] <zyga-x240> then we can drop tests/lib/tools from PATH
[16:54]  * zyga-x240 will EOD soon
[17:25] <jdstrand> oSoMoN: it does, yes. I can add it (note, system-packages-doc will be 2.46 (ie, it isn't in stable yet)
[17:27] <oSoMoN> jdstrand, I know, zy_ga pinged me earlier about it, and I'm preemptively adding the plug to the chromium snap, under the assumption that it will be silently ignored with older versions of snapd
[17:27] <jdstrand> oSoMoN: we can do maunual approvals in the meantime, but if it is for something with a lot of revisions, we might want to wait
[17:28] <jdstrand> oSoMoN: I can add it today and request a store pull, but that likely won't happen until late next week
[17:28] <oSoMoN> jdstrand, I'm happy to revert the change until review tools are ready for it
[17:29] <jdstrand> 'that' meaning, it won't be in prod until late next week at the earliest, with it being a sprint, that is probably actually the week after
[17:29] <jdstrand> oSoMoN: I'll add it and get the ball rolling
[17:32] <oSoMoN> jdstrand, cheers!
[17:33]  * zyga-x240 adds a highlighter for zy_ga -- just in case ;-)
[17:37] <oSoMoN> jdstrand, I reverted the change in the chromium snap, please ping me when I can revert the revert (when the updated review tools are in prod), thanks!
[17:38] <mup> PR snapd#8964 closed: tests: rename version-tool to version-compare <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8964>
[17:41] <jdstrand> oSoMoN: ok, thanks :)
[17:51]  * cachio afk
[18:00] <zyga-x240> mvo: I will EOD now but
[18:00] <zyga-x240> https://github.com/snapcore/snapd/pull/7825 is ready for another review
[18:00] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[18:00] <zyga-x240> I think we could land it and I will iterate, there are some TODOs for more spread tests
[18:00] <zyga-x240> but having it in master will let us get closer to what we wanted
[18:01] <zyga-x240> plus would look nice next week
[18:01] <zyga-x240> https://github.com/snapcore/snapd/pull/7700 and https://github.com/snapcore/snapd/pull/8573 also need reviews
[18:01] <mup> PR #7700: cmd/snap: wait while inhibition file is present <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
[18:01] <mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
[18:02] <zyga-x240> mvo: lastly from refresh app awareness pipe, https://github.com/snapcore/snapd/pull/8941 is simple and needs a 2nd review
[18:02] <mup> PR #8941: sandbox/cgroup: avoid parsing security tags twice <Created by zyga> <https://github.com/snapcore/snapd/pull/8941>
[18:03] <zyga-x240> with that, I'll EOD now
[18:03] <pedronis> zyga-x240: not sure I will get to review #7825 this week
[18:03] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[18:03] <zyga-x240> take care everyone!
[18:03] <zyga-x240> pedronis: I understand
[18:03] <zyga-x240> pedronis: I have things to do so after you're back in a week there will be lots of snapctl PRs for the missing bits
[18:04] <zyga-x240> pedronis: and I'll complete spread tests for hooks and services as ewll
[18:04] <zyga-x240> *well
[18:06] <zyga-x240> have a good evening everyone!
[18:10] <zyga-x240> pedronis: it would help more if you give me guidance on the other two PRs
[18:10] <zyga-x240> pedronis: as those are more of an open direction still
[18:11] <zyga-x240> pedronis: but again, I understand if that needs to wait until after next week
[18:48] <mup> PR snapd#8941 closed: sandbox/cgroup: avoid parsing security tags twice <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8941>
[19:05] <mup> Issue core18#161 opened: mknod: /home/ubuntu/core18/parts/boostrap/install/dev/null: Operation not permitted <Created by WillNilges> <https://github.com/snapcore/core18/issues/161>
[19:11] <mup> PR snapcraft#3186 closed: Riscv64 support <enhancement> <Created by xnox> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3186>
[19:46] <mup> PR snapcraft#3196 opened: cli: unset false boolean flags in environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3196>
[20:06] <mup> PR snapcraft#3197 opened: experimental extension support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3197>
[21:49] <mup> PR snapd#8972 opened: gadget/install,secboot: use snapcore/secboot luks2 api <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8972>
[22:50] <mwhudson> hm why are all the snapd developers in europe :)
[23:07] <oerheks> mwhudson, how do you tell ? https://snapstats.org/
[23:08] <mwhudson> oerheks: i mean *snapd* developers specifically, not people who develop snaps