[07:13] <pstolowski> morning!
[07:31] <zyga> good morning!
[07:32] <zyga> man, sorry for being so late,
[07:32] <zyga> pstolowski: hey, how are you? :)
[07:32] <zyga> on the up side, my working space is ready and I'm after breakfast so ready to hack :)
[07:32] <pstolowski> zyga: hey, great! it was a nice weekend, how about you?
[07:33] <zyga> pstolowski: my wife has arrived here for the week, we saw more widelife yesterday and managed to score some nice photos :)
[07:33] <pstolowski> :)
[08:36] <Chipaca> ogra_: mo'in
[08:36] <Chipaca> ogra_: you said "mvo is wrong, /etc/environment is rw", but mvo was talking about /etc/profile unless I missed something
[08:40] <mup> PR snapd#5489 closed: release: snapd 2.34 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5489>
[08:41] <zyga> pstolowski: question on https://github.com/snapcore/snapd/pull/5488#pullrequestreview-135324049
[08:41] <mup> PR #5488: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488>
[08:41] <zyga> hey Chipaca :)
[08:41] <Chipaca> zyga: 'sup
[08:41] <zyga> Chipaca: monday :)
[08:41] <zyga> it's a bit chilly today but I'm doing allright
[08:42] <zyga> I had a fantastic coffee this morning
[08:42] <zyga> we scored a coffee grinder from the exposition in a store on Saturday
[08:42] <zyga> and used it to grind coffee for the first time in ages
[08:42] <zyga> the aroma and taste is superb
[08:43] <Chipaca> zyga: :-D
[08:45] <zyga> Chipaca: did you see this PR: https://github.com/snapcore/snapd/pull/5475
[08:45] <mup> PR #5475: Remove unneeded calls to daemon-reload <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5475>
[08:45] <zyga> I wonder if it is correct and we were doing useless ops all the time
[08:45] <Chipaca> zyga: it's possible, yes
[08:45] <zyga> or if there is a reason for deamon-reload _apart_ from updating systemd itself
[08:45] <Chipaca> daemon-reload is needed for when an existing service file changes
[08:46] <Chipaca> that's all afaik
[08:46] <Chipaca> and we probably do it all the time just in case  (because thinking about whether the change we did means the service file changes is harder than just doing it)
[08:47] <zyga> Chipaca: well, the PR claims that's not true
[08:47] <zyga> Chipaca: it claims that the side-effect of daemon-reload is to clear the status of a failed service
[08:47] <zyga> but otherwise systemd can manage by itself
[08:48] <Chipaca> “If you want systemd to reload the configuration file of a unit, use the daemon-reload command.”
[08:48] <Chipaca> ^ from systemctl(8)
[08:48] <zyga> I wonder if any of our tests actually capture this
[08:48] <zyga> that is, changes the service file
[08:49] <Chipaca> zyga: in any case it's marked as wip
[08:51] <Chipaca> zyga: so I wouldn't assume e.g. all the «systemctl status yadda yadda || true» are meant to be definitive
[08:52] <zyga> thank you, I will add that PR to the back burner to see what to do about it
[08:53] <ogra_> Chipaca, hmm, not sure what i was reading there ... sorry :P
[08:56] <Chipaca> zyga: there're a lot of failing spread tests saying "you should've run daemon-reload" fwiw
[08:56] <zyga> aha, that is a good indication then
[09:00] <Chipaca> zyga: all the ones i saw were 14.04, so it might indeed not be necessary after that
[09:00] <Chipaca> zyga: OTOH the _unit_ tests were failing, so we didn't get to see the whole log
[09:00]  * Chipaca hugs abeato 
[09:00] <zyga> mmm
[09:01] <Chipaca> it's possible we need to add a bunch of 'if systemd.IsOld() { systemd.Coddle() }
[09:02] <abeato> zyga, Chipaca I am basically doing some testing on whether snapd needs to call daemon-reload all the time, please consider it a WIP as I just wanted to run CI on it  - not sure if I could do that without the PR :)
[09:03] <Chipaca> abeato: it might be needed in 14.04 and optional afterwards, in which case i'd be ok with checking that
[09:03] <zyga> abeato: maybe just ask systemd devs
[09:03] <Chipaca> abeato: you can run ci on it but you'd need a key, and the keymaster is on holidays i think (or is that in august)
[09:04] <Chipaca> abeato: doing it this way is fine (but as i said on the pr please check unit tests first)
[09:04] <Chipaca> abeato: otherwise you're wasting resources to the kñot
[09:04]  * Chipaca wonders if that's obviously «al ñudo»
[09:05] <abeato> Chipaca sure, will do
[09:05] <Chipaca> abeato: ./run-checks --unit  should do it
[09:05] <abeato> nudo maybe :)
[09:05] <Chipaca> abeato: and ./run-checks --static should catch fmt and stuff also
[09:06] <Chipaca> abeato: knot -> nudo, kñot -> ñudo, clearly
[09:06] <abeato> there are things there that I think are needed for sure: reset-failed probably needs to be done whenever snapd removes a unit file, to clean the state
[09:06] <Chipaca> abeato: reset-failed is a great insight, maybe in a separate pr?
[09:06] <abeato> lol
[09:07] <abeato> Chipaca, yup, as a minimum I will propose that later
[09:07] <Chipaca> zyga: https://twitter.com/willkirkby/status/1016014401479041024
[09:08] <zyga> that would win the obfuscated C++ contest if there ever was one ;)
[09:10] <Chipaca> zyga: I thought Stroustrup was the IOC++CC winner for life
[09:31] <niemeyer> Mornings
[09:34] <pstolowski> o/
[09:40] <niemeyer> Chipaca: That might be the Steering Committee
[10:37] <mup> PR snapd#5436 closed: tests: add basic integration test for spread hold <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5436>
[10:37] <mup> PR snapd#5485 closed: testing: support for interfaces on core18 <Blocked> <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5485>
[11:00] <mup> PR snapd#5375 closed: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375>
[11:02] <mup> PR snapd#5405 closed: tests: do not mask errors in interfaces-timezone-control <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5405>
[11:12] <niemeyer> zyga: #5439 says it will be split.. should we close it then?
[11:12] <mup> PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5439>
[11:12] <zyga> yes,
[11:12] <zyga> I'm working on the 2nd patch of the split now, just pushed the first one :)
[11:12] <mup> PR snapd#5439 closed: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5439>
[11:13] <niemeyer> zyga: Thanks!
[12:13]  * zyga takes a break for lunch
[12:14] <zyga> only a few tests left and I will propose all of remapping, ready and tested :)
[12:32] <ogra_> cjwatson, do you happen to know how far https://forum.snapcraft.io/t/architectures/4972 is supported on the builders yet ? (i have some gadgets that can only be cross compiled where the build-on/run-on bits would be very handy, they workk locally but i dont know about build.snapcraft.io)
[12:38] <cjwatson> ogra_: It's not.  I'm working on it
[12:38] <ogra_> ok, thanks
[12:38] <cjwatson> (as in, it's my top task)
[12:38] <ogra_> awesome
[12:39] <ogra_> happy to be your guinea pig if you need one :)
[12:40] <cjwatson> the actual testing shouldn't be the hard bit.  just trying to get a huge pile of prerequisites in place
[12:40] <ogra_> k
[12:44] <pstolowski> zyga: hey do you have a moment for HO?
[13:01] <zyga> pstolowski: yes, after the standup
[13:31] <Chipaca> zyga: wrt transportation options for flock, https://i.imgur.com/jczldiD.jpg
[13:51] <Son_Goku> kyrofa, are we at a point where we're going to want to package snapcraft for fedora?
[13:53] <zyga> Chipaca: tank you :)
[14:22] <pstolowski> zyga: thanks for the suggestion of looking into udevadm code
[14:23] <pstolowski> zyga: those two binds we saw correspond to two event sources that udevadm monitor subscribes to - UDEV_MONITOR_KERNEL and UDEV_MONITOR_UDEV
[14:24] <pstolowski> zyga: the kernel one gives very limited data that seem to correspond to what I get with go-udev
[14:25] <pstolowski> zyga: you can tell udevadm monitor which one you want with --kernel or --udev  - it's both by default, thus two binds
[14:26] <zyga> aha
[14:26] <zyga> interesting
[14:26] <zyga> can you subscribe to the other event source in go?
[14:26] <zyga> and see what we get
[14:26] <pstolowski> zyga: yes that's what i'm going to try
[14:29] <pstolowski> zyga: ha! the comment in go-udev: Groups: 1, // TODO: demistify this field because msg receive if Groups != 0
[14:30] <zyga> ;D
[14:30] <zyga> yeah, I saw that TODO as well :)
[14:30] <zyga> funny
[14:30] <zyga> it's all undocumented mess
[14:30] <pstolowski> zyga: that's tha 1 vs 2 magic value, it tells if you want kernel or udev
[14:30] <zyga> this looks like a multicast group
[14:30] <zyga> and it seems that 1 and 2 are just used in practice
[14:30] <zyga> but man, which man page says so?
[14:31] <pstolowski> zyga: yep, sounds plausible
[14:35] <pstolowski> ok, go-udev doesn't accept udev events, looks like the format is different..digging in
[14:41] <zyga> mmm, indeed
[14:41] <zyga> see if you can read things with netcat
[14:42] <zyga> or maybe not
[14:42] <zyga> just do what you were doing :)
[15:08] <pstolowski> zyga: i'm almost there (with go-udev), needs only small changes
[15:08] <zyga> pstolowski: what is the wire format?
[15:09] <kyrofa> pstolowski, this sounds suspiciously like... no... can it be hotplug?
[15:09] <pstolowski> zyga: just a small header, followed by null-separated KEY=VALUE strings ;). only the headers differ between kernel and udev format
[15:10] <zyga> kyrofa: yes
[15:10] <zyga> kyrofa: but those are not the news you are looking for
[15:10] <zyga> kyrofa: ;-)
[15:10] <pstolowski> kyrofa: shh
[15:10] <zyga> it's still far away
[15:10] <kyrofa> Hahaha
[15:10] <kyrofa> I figured, just nice to see movement
[15:12] <pstolowski> kyrofa: 2 steps forward, 1 step back, that's how it goes ;)
[15:15] <kyrofa> I feel ya
[15:16] <zyga> kyrofa: I, for one, cannot wait to see those hotplug serial ports
[15:17] <pstolowski> zyga: got it working!
[15:17] <pstolowski> zyga: i get super rich data now \o/
[15:17] <zyga> pstolowski: that's great
[15:17] <zyga> pstolowski: does it also mean we can largely ignore reading sysfs now?
[15:18] <zyga> (ourselves, udev handles that)
[15:18] <pstolowski> this will probably be the most significat patch i'll have for upstream... but needs some more work. plus enumarating of existing device (info mode) based on udev is still TODO
[15:18] <pstolowski> zyga: indeed i don't think we will need to read /sys
[15:19] <zyga> pstolowski: I suspect that once you get the initial enumeration done you will have a very solid understanding of how hotplug will work
[15:19] <zyga> as in, on your laptop you will see plenty of devices
[15:20] <pstolowski> zyga: yes, it's just the go-udev enumeration which has same limitations as monitor mode.. will need to re-do it i think
[15:25] <pstolowski> zyga: sweet, even for device unplugging i'm getting all the nice data such as serial etc
[15:25] <zyga> right, because udev knows it
[15:32] <joc> does anyone know if the 2.34 is release is expected to be progressed in the next few days? or is it held while people are offline?
[15:33] <zyga> hey joc
[15:33] <zyga> I think it will be on hold until next week
[15:48] <joc> ok, thanks zyga
[16:11]  * zyga is writing missing tests
[16:29]  * zyga has some more useful tests now and iterates
[16:30] <zyga> I could use some proteins
[16:44] <zyga> ok, time to take a walk
[16:44] <zyga> I'm close to submitting the whole lot
[17:02] <ogra_> zyga, bugs have a lot of protein ... just eat some
[18:25]  * zyga is back from a walk in the forest
[18:25] <zyga> I met a small family of Badgers
[18:26] <zyga> never saw any in my life before
[18:27] <zyga> took some shaky photos while holding my dog so he would not chase after them
[19:29] <mup> PR snapcraft#2177 opened: pluginhandler: use uname from the host <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2177>
[19:31] <kyrofa> ondra, ^