19:00:56 #startmeeting 19:00:56 Meeting started Wed Sep 9 19:00:56 2020 UTC. The chair is rvandegrift. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:45 * noahm waves 19:01:51 after the cloud BoF, we said we'd talk about doing jitsi meetings. I thought it'd also be good to see if we wanted to try a remote sprint this fall. does anyone have other topics? 19:02:31 I'm happy to try jitsi. Only issue is the lack of meetbot there. 19:03:32 well, we would need to take notes, like during an in person meeting 19:03:57 Everybody's favorite task ;) 19:04:22 sure 19:05:07 I'm also in favor of a remote sprint, but I think it'd be important to come up with an agenda ahead of time. We'll need to schedule across a lot of different timezones and we need to make sure the time is used effectively. 19:05:32 I'll volunteer to write minutes next meeting and we'll try jitsi instead of irc 19:05:42 works for me. thanks. 19:06:25 agreed, a remote sprint seems harder. an agenda would be useful. I also don't know if doing all day sessions is reasonable via video chat 19:06:36 yeah 19:07:42 Maybe we can all put some though into sprint activities, and propose agenda ideas over the next few weeks. Discuss them at the next meeting, and put together a schedule based on that. 19:08:02 good idea - I'll send a note to the mailing list since it looks like most folks couldn't make it today 19:08:15 awesome. 19:09:07 that's all I had on this stuff. Other topics? 19:09:31 I wouldn't mind a short discussion on publishing images with buster-backports kernels. 19:09:43 sure 19:10:43 sadly i don't have any numbers on the usage in azure. i know numbers exist somewhere 19:11:00 we do publish backports kernel images there, right? 19:11:09 Are they as visible as the standard images? 19:11:12 yes 19:11:36 I have a couple merge requests open with the kernel team for AWS related things, but I'm not sure they'll want to merge them. 19:12:00 ^^^ targeting the buster kernel. 19:12:24 If they decide not to merge them, then the functionality will require a newer kernel. 19:13:26 So, publishing arm64 and amd64 images with the backports kernel seems like a possible approach. 19:14:02 Are there any strong objections to this? 19:14:15 no, sounds reasonable to me 19:14:33 nope 19:14:51 The lack of security support is unfortunate, but I don't know what other choices we have. 19:15:19 I guess we'll need another marketplace listing for that too? 19:15:26 support by the security team. the upstream kernel is security supported by … upstream 19:16:15 waldi: yes, and benh is good about updating the backports kernel, but it's still not done as frequently as upstream publishes security fixes. 19:16:29 rvandegrift: yeah 19:16:38 hmpf. if you select debian 10 on azure, you get the backports variant pre-selected currently. i asked them not to do that several times 19:17:17 huh, that doesn't seem ideal. 19:18:00 well. in that case it's a first party image. so the microsoft support get's the first bunch on angry questions 19:18:24 I bet that means it's quite popular :) 19:18:41 i have no idea 19:18:55 OK, so I'll continue trying to get my MRs into the buster kernel, but will also prepare for eventually publishing backports kernel images. That'll probably happen at some point, regardless of what happens with the current MRs. 19:19:32 In particular, right now we fail to boot on the arm64 bare-metal EC2 instance types, which is bad. 19:20:19 *shrug* i didn't even know such things exists 19:21:45 They're pretty awesome. 64 arm64 cores, lots of RAM, fast local nvme storage. 19:22:57 yea sounds like it'd be nice to have that working 19:23:21 Anyway, that's enough for this topic. 19:23:33 anything else? 19:23:34 (my current kernel building instance got 64 x86 cores and 256GB ram or so) 19:23:39 yes 19:23:46 waldi: do you have anything new to say about the systemd-networkd investigation? 19:24:01 i got asked if we could expedite point release updates 19:24:20 not exactly sure why, but i thought about it 19:24:40 are they delayed for a long time now? 19:25:07 we might anyway want to build images including packages from proposed-updates to maybe in the future find problems before the release 19:25:24 but this means we need to split buster (with proposed-updates) and buster (with security) 19:25:57 yea, sounds like it could be useful 19:26:02 Yeah, I have thought of that before. I think it makes sense. 19:26:16 they are delayed few days, because they automatic build will first build one the next morning and then someone needs to manualy trigger the release process 19:27:09 if we build images with proposed-updates, we can just release an image that was build somewhere after the freeze, as long as no packages have been excluded from the point release 19:27:42 So we'd need to pay a little closer attention to the actual details of the point release 19:27:47 yep 19:28:51 It'd be nice to automate some checks around that. I wouldn't want to release something that was excluded from the release. 19:28:52 we might be able to slip a point into the check list 19:29:31 yep. should be easy 19:29:45 wouldn't that leave proposed-updates in the apt sources for the point release? 19:29:48 no 19:30:01 we replace the whole sources.list in the end 19:30:06 no, we have the _BUILD classes that provide different sources during the build 19:30:10 So we are safe there 19:31:08 oh I see 19:32:13 waldi: are you planning on working on this in the near future? Or should someone else pick it up? 19:32:37 someone else could pick that up 19:33:09 I will create an issue on salsa so we can track it there. 19:33:23 thx 19:35:57 if there's nothing else, then I think we're finished for this month 19:36:09 noahm asked about systemd-networkd 19:36:17 i actually looked into it a bit 19:36:18 oh I missed that, sorry! 19:36:41 the whole ipv4+ipv6 dhcp stuff works nicely 19:37:06 i realized that azure seems to have started to always assign ipv6 addresses to instances 19:37:27 multi-nic is a problem 19:37:52 it somehow takes about 2s longer to boot 19:38:00 not sure why yet 19:38:45 huh. Do you have a debian-cloud-images branch that configures an image with networkd? I'd be very interested in looking at it. 19:38:53 sure 19:39:14 https://salsa.debian.org/waldi/debian-cloud-images/-/tree/test-systemd-networkd 19:39:33 thanks 19:41:10 cloud-init currently hard depends on ifupdown, that's why it tries realy hard to kill it 19:42:00 right, it'll take some work if we want to change that. 19:42:31 i have not found a way to do dynamic policy routing. systemd-networkd can configure that, but only static 19:42:45 As long as ifupdown remains Debian's default, I wonder how hard we want to push in this direction. 19:43:20 ifupdown and dhclient may not be pretty, but they're very flexible. 19:43:27 ifupdown is not debian's default. network-manager is used by d-i with desktop environment 19:43:48 if there's no desktop environment? 19:43:52 yeah. i don't know yet 19:45:37 systemd-networkd at least solves some problems, but is less flexible for sure 19:46:29 https://gitlab.com/craftyguy/networkd-dispatcher provides some hooks for more flexibility, though I haven't actually used it before 19:47:44 hmm 19:47:49 that's potentially interesting. it looks like it's trying to implement some of the extensibility that dhclient provides. 19:51:28 davdunc still didn't manage to handle those AWS accounts? 19:51:49 not so far as I've heard... will nag again. 19:52:36 oh, not sure if anybody noticed this, but Amazon Lightsail added buster, finally. 19:53:02 They still have jesse, which really needs to go away. I have informed them of this. 19:55:54 I have no other topics. 19:55:57 did our dpl contact anyone from the cloud team, which is currently tasked to handle vendor relations, with his "debian.net team" idea? 19:56:40 because what he brought up in -project includes another team tasked with cloud vendor relations 19:56:51 presumably it would be one of the delegates he'd have contacted? 19:57:40 I haven't heard anything from him besides what was on -project. 19:57:53 I didn't see anything other than the -project thread 19:57:59 okay 19:58:18 i don't have anything else 19:58:37 okay folks - thanks for the time! 19:58:43 #endmeeting