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