19:09:45 #startmeeting 19:09:45 Meeting started Wed Sep 22 19:09:45 2021 UTC. The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:09:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:09:55 #topic Admin 19:10:10 #info Previous minutes: http://meetbot.debian.net/debian-release/2021/debian-release.2021-06-23-19.28.html 19:10:20 #info elbrus had an action to draft a bits => done 19:10:30 #topic Transitions 19:10:38 .oO(3 months since the last meeting) 19:11:06 that's your cue Sebastinas 19:11:22 glibc migrated, so a bunch of stuff got unblocked 19:11:50 ack 19:12:11 Otherwise it's the usual bunch of small uncoordinated transitions that mostly cause no issues, and some ongoing ones. 19:12:34 And then there's r-base and r-api-bioc with a vast amount of autopkgtest failures 19:13:02 People working on r-api-bioc seem to take care of regressions in their packages 19:13:18 yes I think ginggs spotted the issue with some of those the day before yesterday 19:13:27 But r-base just dropped without anyone taking care of it as far as I can see 19:13:57 yeah, apparently some rebuilds are needed for r-base 19:14:48 but it wasn't stated exactly which 19:15:07 i'm hoping the autopkgtests will show us 19:15:52 i am keeping an eye on it 19:16:05 Thanks 19:16:24 Maybe r-api-4.0 should have been bumped 19:17:37 according to upstream, not 19:17:52 * ginggs looks for a mail.. 19:18:39 what shall we do with the python removal trackers? seems like mostly a lot of cruft RM bugs need to be filed... 19:19:30 is anybody still chacing that? 19:19:35 I would expect those to have bugs 19:19:45 that == the remainder 19:19:54 https://lists.debian.org/debian-r/2021/09/msg00083.html 19:20:11 see the bit about "rebuild for graphics devices" 19:20:18 tumbleweed: you mean the remainer, or the cruft? 19:21:05 e.g. ola is listed for the unversioned one but I don't see a bug 19:21:07 elbrus: remainder. I think python2-rm and unversioned-python-rm both had MBFs 19:21:42 but yeah, I see that re ola 19:21:56 I'd expect them to be of severity serious and they would have been kicked out of testing long time ago 19:22:06 ACK 19:22:08 the packages with their bug 19:22:57 * bunk wonders whether bookworm will still ship 2.7 for pypy 19:23:14 bunk: safe to say yes, at least as a B-D for pypy3 19:23:23 elbrus: I have started to send a first batch of RM bugs, will keep an eye on further things 19:23:55 jmm_: thanks 19:24:23 which means we should keep the trackers for now :) 19:24:39 Sebastinas: anything else regarding transitions? 19:25:09 #topic roll call 19:25:15 No 19:25:26 no roll call? :) 19:25:31 LOL 19:25:36 Except that we should probably also raise all the llvm-toolchain-9 bugs to serious to get llvm-9-toolchain removed. 19:25:50 ;) 19:25:57 Sebastinas: go-go-go (I say without checking) 19:26:04 agreed 19:26:29 so roll call, i'd like to send the mail soon 19:26:38 we should decide on the deadline 19:26:44 last time was very short; 19:27:04 mail was sent on 2020-11-02 and deadline was 2020-11-27 19:27:48 three months? 19:27:56 with two reminders? 19:28:11 sounds good to me 19:28:35 you'll take care of drafting/sending the mail (like last time)? 19:28:40 i will 19:28:58 #action ginggs: send roll call 19:30:42 #topic key packages (popcon) 19:31:16 last year we agreed to change the criteria of popcon for key packages 19:31:40 but didn't do the actual change because of the freeze 19:31:41 Can you remind us what we decided? 19:32:03 http://meetbot.debian.net/debian-release/2021/debian-release.2021-01-27-19.07.html 19:32:28 Right, thanks 19:32:57 popcon threshold 100% ~= popcon doesn't count? 19:33:05 exactly 19:34:36 ivodd mentioned that we could probably "improve" the key package criteria even further 19:34:52 by reconsidering how we treat meta-packages 19:35:02 I think it's worth investigating 19:35:17 with the aim to reduce the set we now call "key" 19:35:36 to more resemble something like "must-be-in-to-be-able-to-release" 19:36:15 because I really don't like we treat some packages different from others 19:38:08 I guess he meant something like reconsider if all desktop tasksel should be key 19:38:30 we'd need a bit of buy in from kibi 19:38:36 for that I gues 19:38:39 s 19:38:42 definitely worth investigating 19:38:55 * bunk wonders whether packages like libreoffice would stay key or become optional 19:39:03 * elbrus too 19:40:35 maybe I should come up with a proposal for this 19:41:24 #action elbrus: make proposal of how to reduce key package set further 19:42:33 no other ideas? 19:43:03 no 19:43:16 #topic arch qual: number of buildds 19:43:47 I'm wondering if we should rethink this section of the arch qualification policy 19:43:48 https://salsa.debian.org/release-team/release.debian.org/-/blob/master/www/bookworm/arch_policy.html#L125-128 19:43:55 in particular: 19:44:07 "keep up with unstable with not more than two buildds" 19:44:28 * elbrus thinks we haven't enforced this in years 19:44:47 and doesn't know how current buildds would be judged *now* 19:44:50 yeah, so i think we should update that to match reality 19:45:10 i shouldn't think we care how many buildds there are, as long as they can keep up 19:45:35 the original argument was the price of maintenance 19:45:44 if you need more than two 19:45:52 is that an issue nowadays? 19:46:09 I haven't heard people complaining 19:46:16 At least I haven't heard complaints from DSA or buildd admin 19:46:19 but maybe I'm not listening in the right channels 19:47:05 should we ask them, and if they're fine, update our text? 19:47:46 sure we can ask 19:47:47 Yes, I'm with a text that would just say that buildds needs to be able to keep up 19:47:56 that's the idea 19:47:56 +fine 19:48:29 so: "The architecture is able to keep up with unstable, has redudancy..." 19:48:51 we can bikeshed the text in an MR... :) 19:49:13 ginggs: can you ask? 19:49:18 sure 19:49:51 #action ginggs: ask DSA and buildd if they're fine with the current number of buildds per arch 19:50:04 #topic AOB 19:50:11 anybody? 19:50:20 no 19:50:46 After the roll call it might be a good time to revisit the set of release architectures. 19:50:55 I think we didn't have enough time to do that for bullseye. 19:50:57 that was the whole idea, yes 19:51:04 to do it now 19:51:18 such that we have time to properly handle it 19:51:56 #topic Next meeting 19:52:03 #info Next meeting is 27th October at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics) 19:52:12 #endmeeting