[07:04] <zyga> good morning
[07:14] <mborzecki> morning
[07:14] <mborzecki> chilly morning, -25C
[08:07] <pstolowski> morning
[08:15] <mborzecki> mvo: pstolowski: hey
[08:15] <mvo> good morning mborzecki and pstolowski
[08:16] <mborzecki> pstolowski: was it equally cold in your area in the morning?
[08:16] <pstolowski> mborzecki: -18C atm
[08:16] <pstolowski> is that cold enough? ;)
[08:20] <mborzecki> pstolowski: haha ;) nice, was -25C in the morning, couldn't open my car
[08:21] <pstolowski> oh wow
[08:22] <pstolowski> fwtw i thinking it's going to be >0 again this week
[08:22] <pstolowski> *i think
[08:23] <mup> PR snapd#9777 closed: gadget: add gadget.ResolveContentPaths() <Skip spread> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9777>
[08:24] <mborzecki> pstolowski: yeah, back to normal :)
[08:24] <mborzecki> mvo: do you have a log with failure of https://github.com/snapcore/snapd/pull/9844/commits/a0bda4cce16da09fed44d70c1eaa5e56516024fa ?
[08:24] <mup> PR #9844: cmd: make string/error code more robust against errno leaking <Created by mvo5> <https://github.com/snapcore/snapd/pull/9844>
[08:24] <mvo> mborzecki: yes, need to dig but should be able to find it
[08:25] <mvo> mborzecki: https://buildd.debian.org/status/fetch.php?pkg=snapd&arch=i386&ver=2.48.2-2&stamp=1610734191&raw=0
[08:26] <mvo> mborzecki: does what I write in my PR make sense?
[08:26] <mborzecki> mvo: thanks, let me see
[08:26] <mvo> mborzecki: pretty sure it's test related stuff leaking but it highlights our code is buggy, a strquote will never have errno set so we need to clear it
[08:27] <mvo> mborzecki: but yeah, thanks for looking into this, I'm not sure what exactly in the tests is causing this leaking
[08:27] <mvo> mborzecki: also a bit hard to reproduce, I had to setup a i386 sid vm
[08:27] <mvo> mborzecki: but there it failed without sbuild irrc, just by running latest gcc/i386
[08:27] <mborzecki> mvo: it built on amd64 though?
[08:28] <mvo> mborzecki: correct
[08:29] <mvo> mborzecki: here is the full build status https://buildd.debian.org/status/package.php?p=snapd&suite=sid
[08:29] <mvo> mborzecki: it also has issues on mips it seems
[08:29] <mborzecki> mvo: and riscv go does not support pie
[08:29] <mvo> mborzecki: but afaict we don't have to worry about mips*
[08:30] <mborzecki> yeah, unlikely one is going to run snapd on their mips router :P
[08:32] <mvo> mborzecki: +1
[08:56] <mborzecki> mvo: hm, so i'm trying debian i386 in podman which i upgraded to sid
[09:03] <mvo> mborzecki: and no luck with the error?
[09:07] <mborzecki> heh, network is down in the container after updating to sid ;)
[09:23] <mup> PR snapd#9845 opened: osutil: update go-udev package <Created by stolowski> <https://github.com/snapcore/snapd/pull/9845>
[09:24] <pstolowski> woot, cla-check fails with PermissionError: [Errno 13] Permission denied: '/home/ubuntu/.launchpadlib'
[09:25] <pstolowski> i wonder if it's going to like subtree of other repository nowadays... it wasn't an issue 2 years ago
[09:35] <mvo> mborzecki, pstolowski, degville  I accidently deleted the standup today, feel free to still have it from tomorrow on everything in the calendar is normal
[09:35] <pstolowski> mvo: ack
[09:37] <mborzecki> mvo: i can't reproduce the build failure in a container
[09:37] <mborzecki> mvo: all unit tests are passing
[09:37] <mborzecki> oh w8, but silly me tried the master branch
[09:39] <mborzecki> unit tests are happy on 2.48 too, what gives?
[10:16] <mborzecki> heh, what's not to hate about implicit errno
[10:18] <mborzecki> zyga: hi, you like C, do you have any ideas about improving the errno mess in https://github.com/snapcore/snapd/pull/9844 ?
[10:18] <mup> PR #9844: cmd: make string/error code more robust against errno leaking <Created by mvo5> <https://github.com/snapcore/snapd/pull/9844>
[10:19] <mborzecki> mvo: were you able to reproduce it in a vm too?
[10:22] <mvo> mborzecki: I think I was, it was friday evening, it's a bit of a blur but I can reboot this vm
[10:23] <mvo> mborzecki: trying it now, should have results in a few min
[10:24] <mvo> mborzecki: worst case is that it's sbuild (which definitely does a lot of strange things)
[10:28] <mvo> mborzecki: yes, i386 qemu based vm is enough for me to reproduce
[10:28] <mvo> mborzecki: do you need anything? gcc ver? kernel ver?
[10:28] <mvo> mborzecki: I don't think all sid updates are applied I could try with that
[10:29] <zyga> mborzecki, I'll get back to you in a moment
[10:30] <zyga> mborzecki, interesting
[10:31] <zyga> mborzecki, I have some ideas, I did run into this earlier but I didn't fix there
[10:32] <mborzecki> mvo: so the only difference is the kernel then, the continer is using my host's kernel, while you have the kernel from sid
[10:33] <zyga> mborzecki, my feeling around the _right_ solution is to drift away from global errno
[10:33] <zyga> mborzecki, deprecate die() that uses implicit errno
[10:34] <zyga> mborzecki, add die_just_because and die_because_errno
[10:34] <zyga> mborzecki, then those no longer have the problem that we are papering over
[10:34] <mvo> mborzecki: I was using 4.19, let me try a newer one
[10:35] <mborzecki> mvo: sid on 4.19?
[10:35] <zyga> mborzecki, then we go one by one and convert those to the new API
[10:35] <mvo> mborzecki: ha! fun, yes, with 5.10 I don't get the error
[10:35] <zyga> mborzecki, this is also nicely in line with the trend to avoid using global errno and start using errno _values_ but not the variable
[10:36] <mborzecki> zyga: yeah, thought about just adding a parameter to die(), but maybe a new die_<something>() would be better
[10:36] <zyga> mborzecki, I think it's better to be explicit, especially that in all the cases I can think of, it will be clear that we want to die_with_errno() and pass the errno
[10:36] <zyga> or die just because but ignore errno, even if there is some non-zero value there
[10:36] <zyga> how does that sound to you?
[10:38] <mborzecki> sound lines something we should have done a while ago :) maybe now's the time
[10:40] <zyga> mborzecki, I think it was always strangled by the feeling that touching C is bad and reviews never materialized
[10:40] <zyga> mborzecki, if that is not true anymore I'd love to see some progress on this
[10:40] <zyga> mborzecki, and I can help with review or coding if you want
[10:41] <zyga> CC mvo ^
[11:19] <mup> PR snapd#9846 opened: [RFC] systemd, many: no reload when enabling or disabling services <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9846>
[11:32] <mborzecki> silly gofmt
[11:39] <pstolowski> pedronis: hi, i'm unclear about max-format=.. argument for v2/assertions/validation-sets/...; it's not mentioned in the spec so probably not applicable there? or is it something implicitly supported by all assertion endpoints, and should be passed too?
[11:43] <zyga> pstolowski, IIRC max-format was for the case where an old device wakes up and talks to the store and is not confused by assertion format it cannot parse
[11:43] <zyga> pstolowski, so it was meant to be for all assertions
[11:44] <zyga> but I'm not sure if that's true
[11:44] <mup> PR snapd#9847 opened: cgroup-support.c: fix link to CGROUP DELEGATION <Created by jonasdn> <https://github.com/snapcore/snapd/pull/9847>
[11:46] <zyga> ijohnson, hey
[11:46] <ijohnson> hey zyga
[12:09] <mup> PR snapd#9848 opened: overlord/devicestate, sysconfig: do nothing when cloud-init is not present <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9848>
[12:14] <mup> PR snapd#9838 closed: asserts: sort by revision with Sort interface <validation-sets :white_check_mark:> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9838>
[12:15] <pedronis> pstolowski: it should be supported everywhere, double check with suligap
[12:15] <pstolowski> pedronis: sure, thanks
[12:23] <mborzecki> ijohnson: thanks for the review https://github.com/snapcore/snapd/pull/9848
[12:23] <mup> PR #9848: overlord/devicestate, sysconfig: do nothing when cloud-init is not present <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9848>
[12:23] <ijohnson> mborzecki: you're welcome :-)
[12:45] <mborzecki> ijohnson: is this more less what you had in mind? https://paste.ubuntu.com/p/dvGMDwT832/
[12:45] <ijohnson> mborzecki: yes thank you
[12:45] <mborzecki> cool, thanks for taking a look
[13:15] <ijohnson> cmatsuoka: hey do you still have that spread-runner worker online? it doesn't seem to be running cla check properly, anymore: https://pastebin.ubuntu.com/p/pngjxpRWbz/
[14:34] <pstolowski> ijohnson: i retried #9845 5 times and it fails every time on cla check, do you think i should keep trying some more?
[14:34] <mup> PR #9845: osutil: update go-udev package <Created by stolowski> <https://github.com/snapcore/snapd/pull/9845>
[14:34] <ijohnson> pstolowski: I tried like 3 times and it worked, but check the very start of the raw log from the github runner to see which runner got allocated
[14:34] <pstolowski> ijohnson: right, good idea
[14:35] <ijohnson> cause afaik it's random as to which runners get allocated
[14:35] <pstolowski> ijohnson: Machine name: 'claudio-spread-1'....
[14:35] <ijohnson> yeah that's the broken one right now
[14:36] <pstolowski> unfortunately it seems it's also the one that really wants to run over my PR right now ;)
[14:37] <ijohnson> haha it's very attached
[14:40] <pstolowski> ok, it picked a different one finally.. but failed checking one of the contributors of go-udev upstream :(
[14:45] <mup> PR snapd#9849 opened: tests/main/snap-network-errors: disable dns-caching on centos-7 <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9849>
[14:45] <ijohnson> :-(
[14:49] <pstolowski> not sure what to do about that... it doesn't make sense to chase radom people of 3rd party project about signing cla for us, obviously
[14:49] <pstolowski> i could --squash, but that sucks
[14:51] <mvo> pstolowski, ijohnson sorry a bit distracted but should I remove a runner (claudios?)
[14:51] <ijohnson> mvo: yeah if you have perms to do so, that would make cla-checks less likely to fail until cmatsuoka can fix the runner
[14:51] <pstolowski> +1
[14:57] <mvo> forced remove it
[14:58] <pstolowski> ty
[14:59] <dariball> is there a py-lib to use snap from within python ? haven't found one yet, just looking at the wrong spots?
[15:00] <zyga> dariball, use in which sense?
[15:00] <zyga> dariball, drive snap operations or manage a snap system?
[15:01] <dariball> I would like to check if there is a new version of a snap, refresh it, restart, stop
[15:10] <zyga> dariball, snapd is doing that work internally
[15:11] <zyga> dariball, there are REST apis for that as well, those can be scripted
[15:11] <zyga> but they only complement the internal refresh check
[15:11] <zyga> dariball, there are Glib bindings that I know of
[15:11] <zyga> dariball, I don't know if there are python bindings yet
[15:13] <dariball> oh, rest api sounds very good, just found it via unix-socket, perfect! thank you this is what I was looking for ...
[15:18] <pstolowski> dariball: https://snapcraft.io/docs/snapd-api may help
[15:20] <dariball> jap exactly what I was looking for, nice
[15:45] <mup> PR snapd#9815 closed: {,sec}boot: pass "key-name" to the FDE hooks <Needs Samuele review> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9815>
[16:49] <jdstrand> mvo: hey, would it make sense for me to be a collaborator on the snappy-debug snap? I was dropped from snappy-dev so can't commit to it any more. I can do MPs and hand off to emitorino. honestly, it would probably be best if it was converted to git and moved to github under the snapcore umbrella (perhaps with a rename to snap-debug). that all requires various bits of work. I'd be happy to continue to
[16:49] <jdstrand> contribute to the project though
[16:50] <jdstrand> mvo: let me know how you'd like me to do that
[16:54] <mvo> jdstrand: in a meeting but I want to absolutely add you as collaborator, can you please /msg me the email I should use for this?
[16:55] <jdstrand> mvo: so there is both collaborating on the snap and committing to the tree
[17:00] <mup> PR snapcraft#3420 opened: plainbox spread tests: set tasks to manual <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3420>
[17:02] <jdstrand> mvo: in other news, it looks like I am still part of the snapcore and ubuntu-core organizations in github. I think I'll leave that as is for now unless you want me to change it
[17:05] <mup> PR snapd#9850 opened: store: method for fetching validation set assertion <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9850>
[17:06] <pstolowski> pedronis_: ^
[17:06] <pstolowski> pedronis_: some dillemas here re primary key and potential reuse (after tweaks) of asserts.HeadersFromPrimaryKey
[17:07] <pstolowski> and it's based on the PR that switches to v2 api
[17:09] <zyga> https://twitter.com/zygoon/status/1351215032475004942/photo/1 :)
[17:09] <zyga> niemeyer, ^
[17:09] <zyga> hey jdstrand
[17:10]  * zyga hugs jdstrand for being here
[17:11] <jdstrand> hey zyga :)
[17:21] <zyga> mvo, is cachio off / sprinting this week?
[17:45] <ijohnson> zyga: cachio is moving to a new house this week, I think he will be back on like wed or thurs
[17:47] <zyga> ijohnson, oh, that's quite a big change
[17:47] <zyga> cool, thanks for letting me know
[17:47] <ijohnson> np
[17:47] <ijohnson> btw nice logo for spread, I like it
[17:52] <zyga> ijohnson, :)
[17:53] <zyga> I like it because it's so logo-like it's just lines spreaing outwards