18:58:27 #startmeeting 18:58:27 Meeting started Wed Dec 23 18:58:27 2020 UTC. The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:27 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:58:36 #topic Admin 18:58:47 #info Previous minutes: http://meetbot.debian.net/debian-release/2020/debian-release.2020-09-23-19.00.html 18:59:04 #info ginggs had an action for a patch to britney 18:59:38 o/ no patch, sorry 18:59:48 o/ 19:00:00 #info ginggs had an action to do the porter call for bullseye 19:00:08 https://lists.debian.org/debian-release/2020/11/msg00039.html 19:00:13 and on the agenda 19:00:41 hmm, nearly all actions were for ginggs? 19:00:44 #info ginggs had an action to think about a proposal for blocking binNEW in unstable 19:01:07 * elbrus has seen some progress on the MR of ivodd 19:01:22 ivodd_ even 19:02:45 ginggs: I guess we would have heard the proposal 19:03:02 #info ginggs had an action to set up a permanent tracker for binutils 19:03:11 https://release.debian.org/transitions/html/libbinutils.html 19:03:25 #info elbrus had an action to propose minor rc_policy text update for autopkgtest superficiallity 19:03:32 https://salsa.debian.org/release-team/release.debian.org/-/merge_requests/8 19:03:48 #topic Transitions 19:04:16 we're getting close to the transition freeze (and (build-)essentials freeze) 19:04:22 how are we doing? 19:04:37 ginggs, Sebastinas, pochu? 19:06:12 python 3.8 removal is almost done 19:06:38 i don't think there are any blockers there 19:06:54 except some removals? 19:06:56 boost 1.74 almost done, but blocked by ceph, again 19:07:11 not for the transition, but there are still some rc issues on key packages 19:07:28 elbrus: Everything needed for removing 3.8 from testing is either on the autoremoval list or fixed in unstable. 19:09:10 ginggs: are we still planning to start some transitions before the freeze? 19:10:42 php 8.0? 19:10:48 https://bugs.debian.org/cgi-bin/pkgreport.cgi?exclude=pending%3Adone;users=release.debian.org@packages.debian.org;tag=transition;ordering=transitions 19:11:20 in the past we've accepted transitions up to the cut-off, but with an eye to making sure they're manageable. if not then we deferred them. 19:12:14 I was mostly thinking of: are there transitions on the radar that we should start to think about deferring? 19:12:44 php 8.0 looks like there's quite some blocking bugs 19:12:57 didn't check how easy they are to fix 19:13:31 (my own package failed it's autopkgtest, I already contacted upstream and they fixed the issue and it uncovered a mistake by me too) 19:13:49 own package => cacti 19:15:03 php7.4 has upstream support for just under 2 years more 19:15:15 Many regressions spotted on https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults have no associated bug report. 19:15:49 my instinct is that 8.0 will be too big a rush, but I'm not really invested in it so 19:16:38 ack 19:17:05 I guess Sebastinas is not around yet to join the discussion... 19:17:07 too bad 19:17:49 ginggs: that's it on transitions? 19:18:02 i think so, yes 19:18:22 then, for the tough one 19:18:24 #topic architecture qualification 19:18:32 what shall we do with it 19:18:38 I suppose we need to see the maintainers report on php8 before deciding but it doesn't look promising right now based on the autopkgtests 19:19:10 elbrus, can you give a summary on arch qual? 19:19:21 https://release.debian.org/bullseye/arch_qualify.html 19:19:38 ginggs and I have updated that with incoming info 19:19:57 i386 and ppc64el only have 1 porter each, s390x has none 19:20:01 some of the info was taken over from stretch 19:20:44 I'll jump in here and say that while I'm normally in favour of open meetings, I'm not sure arch qual should be one of them. it's an *extremely* emotive subject and we really need to be clinical about it. A dedicated meeting for it when all info is collated and available (and triple checked) would be my suggestion 19:22:15 please also read Adrian's proposal for that topic 19:22:55 jmw, this is my first arch qualification, but I read a bit about it, so I can be quite OK with that. I just didn't want to postpone it... 19:22:56 i think a mail to d-d-a stating that i386, ppc64el and s390x have not met the porter requirement could be useful 19:23:08 I'm not sure 19:23:15 elbrus: yes, I realise it's also a pressing matter 19:23:15 we were late with the call 19:23:32 and I'm not really in a position to contribute much useful to it at the moment anyway 19:23:42 well, experience 19:23:45 I merely speak from experience :) 19:23:55 ginggs and Sebastinas and me are new on the team 19:24:37 #action elbrus to continue arch qual discussion ASAP by e-mail 19:24:46 ginggs: you may find that simply provokes one meeeelion porters suddenly turning up out of the blue to work on the arch, and vanish just as quickly once it's released 19:25:14 enough with badmouth^Uabsolutely correct 19:25:31 well, that already happend with the call. I'm surprised by some porters, who were almost silent during the last cycle 19:25:54 we should do the call at the start of the cycle, not near the end 19:25:56 elbrus: perhaps circulate to team@ enough info for everyone to try and digest so they are ready for a meeting, and try to set something up early in the new year? but only a suggestion 19:26:03 All currently committed porters were either already stretch porters or DD in the year 2000. 19:26:44 #topic idea: ask ftp-master if we can get a block for (build-)essential at the start of the freeze? 19:27:13 our first freeze now incorporates the (build-)essential freeze 19:27:14 hello! 19:27:31 I'm working on debugging jruby and opening a bunch of bug reports 19:27:40 pollo: we're having a meeting 19:27:46 ah sorry! 19:28:37 apparently we have the power to block uploads to unstable (in scope of transitions) 19:28:53 well we have the power to ask at least :) 19:28:55 a block for Sid? I think we could do that somehow though I have never used it 19:29:05 would it make sense to avoid accidental uploads to unstable to ask? 19:29:12 exactly: power to ask 19:29:20 but, what do you think? 19:29:25 But I wouldn't use that for many packages without a consensus with ftpmastwr indeed 19:29:30 * elbrus will ask if we think it's useful 19:29:48 I think currently the framework needs fixing too 19:29:58 what's the problem to be solved with this? 19:30:02 * Sebastinas waves 19:30:04 How would the developer be informed about the block? 19:30:05 that's always a good place to start 19:30:41 No changes to packages that are (transitively) part of (build-)essential 19:30:41 Changes to packages in (build-)essential affect the build of every package. The impact of bugs in these packages can take a lot of time to resolve. Therefore, they are no longer appropriate. This is especially the case for toolchain packages, build systems, packaging helpers, etc. 19:30:55 copied from the freeze policy 19:30:58 https://release.debian.org/bullseye/freeze_policy.html 19:31:37 bunk: an announcement that we enforce our policy that way 19:31:46 if agreed with ftpmaster of course 19:31:50 elbrus: How can I see whether any of my packages is affected? 19:32:08 if it's part of build-essential or essential.. 19:32:16 or a dependcy of those 19:32:40 I maintain a package that is one of 3 providers of an (transitively) essential virtual package. 19:33:21 is it picked by the buildds? 19:33:49 It is not the implementation that is installed by default. 19:34:42 I think than it doesn't count, but maybe ivodd_ can comment on that (later) 19:34:43 but with 228 reverse-bdeps I couldn't tell whether anything transitively (build-)essential pulls it in 19:35:02 well, you can define that as the set of packages that end up in a buildd chroot, or plus all all packages needed to build those 19:35:37 I think we could (and should) provide a list if it's unclear 19:35:52 doko: So how can I see whether gawk is in the latter without an explicit list? 19:35:54 has there been a problem in the past with inappropriate uploads of these packages which couldn't be solved with fixes or reverts? because it does sound like a fairly opaque list 19:36:43 jmw: we added that because some issues during buster (I don't recall what the issue was exactly) 19:37:35 yeh I vaguely recall. but what I'm getting at is whether technical enforcement is necessary with all the complexity it brings to corner cases 19:37:44 whatever solution is chosen, please don't make over difficult to update frozen a package in testing 19:38:13 aurel32: that sentence doesn't get parsed by me 19:38:18 I do remember R being an issue once but that might have been stretch, and a reversion solved it 19:38:22 My first worry is that without an explicit list (which might be a lot larger than you think) it is not clear at all which packages are affected. 19:38:40 bunk, ack 19:38:52 if we were to ask ftpmaster, we would need the list anyways 19:39:18 * bunk remembers an upload of binutils upstream master around the transition freeze of stretch or buster 19:39:38 mm 19:40:01 elbrus: i mean if a package has to be fixed for important bugs (iiuc this is allowed during the freeze) we should just be able to upload it after an ack from the release team 19:40:03 one option might be to prepare the list anyway and publish it with a request, and save enforcement for if there's actually a problem 19:40:14 bunk, your memory is wrong. that was when somebody decided to make pie the default just before the freeze ... 19:41:05 if you post this list, please also make a guide line for freeze exceptions 19:41:21 elbrus: if it's more difficult than getting a package into next point release, people will just wait for 11.1 19:41:24 jmw: we put this in our freeze policy now, if we can enforce it, it could avoid the problems (which need reverting and rebuilding and...) 19:41:43 doko: https://tracker.debian.org/news/812066/accepted-binutils-2275120161102-1-source-into-unstable/ 19:41:44 aurel32: sure, acked fixes should be able to get in 19:41:46 * New upstream snapshot, taken from the trunk. 19:42:20 yep, before the freeze 19:42:53 3 days before the transition freeze 19:43:09 doko: bunk, let's try to not get eachothers emotions up... 19:43:27 that specific incident is not really what's under discussion here 19:43:36 let's not get bogged down 19:43:58 and it's a combination of pie, binutils, and mips* 19:44:48 ok, so I take it for this to fly I need to create the list anyways, and people are not against asking, but also aren't really enthousiastic 19:45:15 I'm certainly not against, but I'm also in favour of minimum friction for good uploads 19:45:25 I don't really have a strong feeling either way 19:45:38 as we have it our policy, it would help ourselves if we have the list, so, I'll make it 19:46:05 #action elbrus to compile the list as meant in the freeze policy for (build-)essentials 19:46:08 yes, definitely 19:46:42 #topic RT sprint? 19:47:04 I was wondering, during buster we had a sprint in Paris 19:47:25 should we try to do a sprint soon too? 19:47:46 f2f sprints are lovely but probably unrealistic at the moment 19:47:55 full ack 19:48:11 so that leaves, how useful is a virtual sprint at this moment? 19:49:14 in the cloud team, we've been using jitsi for some meetings lately. It's worked well as a f2f alternative. 19:49:51 any particular focus you had in mind? 19:50:30 no, mostly team building I guess 19:50:55 and issues will come to mind when it approaches, but that's not strong for organizing 19:51:13 we did quite a lot of RC bug triaging during Paris 19:51:29 unblock sprints might be worth organising in time, but if there's no focus the danger is it just turns into a fiddling-with-things session 19:51:33 discuss the difficult cases 19:51:45 ack 19:52:44 my experience last year was that unblock was slightly easier that RC bug triaging 19:52:51 but maybe that's just me 19:53:24 and maybe I can make the call easier than I could last time 19:53:51 anyways, let's keep it in mind and pick it up when we think it's useful 19:54:02 #topic multiple versions of $packages in bullseye (e.g. llvm-toolchain) 19:54:27 there are multiple packages that have multiple versions in the archive 19:54:32 I think we care 19:54:41 but do we chase? 19:55:03 I think we could bump all the "please switch to llvm-11" bugs to RC 19:55:03 sorry but I need to go, this tiny person is not going to let me get away with much more 19:55:12 related to gingss next topic 19:55:27 OpenJDK 15 support state for Bullseye (#975016) 19:55:29 And see how far we get. 19:56:01 jmw: ttyl 19:56:21 #974779 "Either you go back to -9 or move to -11" 19:56:41 I thought that was strange 19:56:46 Sebastinas: normally upstreams don't always update to the latest -11. I think you cannot avoid -9. try to get rid off 10 19:57:51 9 removal is only blocked by ghc, and that has a MR that could be tried. 19:58:06 apart from llvm specifically, I think we should try hard to not have more than 2 versions? 19:58:10 elbrus: for openjdk: my preferences would be a snapshot of openjdk-17, which then could be updated by a stable release update, or a security update 19:58:36 -17 will be the next lts 19:58:43 The security team wants to support 2 openjdk versions? 19:58:45 currently we have 5 openjdk's in testing 19:58:57 without 17 19:59:11 I think that's really too much 19:59:30 bunk, please read the reply by the release team 19:59:44 elbrus: no, it would be -11 and one more, -17 preferred 20:00:01 Shipping 11 in bullseye and injecting 17 to bullseye-backports (to avoid bootstrapping it there) still sounds like the sanest option to me. 20:00:05 doko: Which reply? 20:00:26 s/release/security/ 20:01:14 Shipping a non-default OpenJDK without security support is just madness. 20:01:53 "Please enable bullseye-backports if you want security support for this version." 20:02:08 That's what it would boil down to. 20:02:31 At that point it is strictly better to have it only in bullseye-backports. 20:02:32 that's your opinion.backports is not something which can be enabled everywhere 20:03:03 And a Java without security support should be installed in these places? 20:03:52 -17 can have security support, that's why I'm suggesting it 20:04:33 we're not planning to support 17 in stable in addition to 11, including a 16 was only suggested to allow people to easily bootstrap 17 in backports 20:04:35 In what email is the security team saying this? 20:06:01 we had two JREs in some older release and not keen at all to repeat that 20:07:38 doko: for my unstanding, you don't want/need openjdk 13 and 15 in testing? shall we at least remove those? 20:08:00 elbrus: I'll take care of these before the ff 20:08:17 My suggestions for the "bootstrap 17 in backports" problem were in https://lists.debian.org/debian-release/2020/11/msg00213.html 20:08:20 it would help to do that earlier, not everybody sees your plans 20:09:16 ok, I'll do that before eoy 20:09:22 thanks 20:10:22 Would it help if I write an email to debian-ftp and debian-backports asking for opinions on that? 20:11:55 do I understand correctly that openjdk is unique in that sense? 20:12:34 * bunk looks at rust 20:12:35 i.e. that it needs the previous version to build, whereas other new toolchain packages (for firefox?) can just be built? 20:13:00 the uniqness is that for a new bootstrap in bullseye you need to build 12 with 11, 13 with 12, 14 with 13, 15 with 14, 16 with 15 and 17 with 16 ... 20:14:12 It's not unique, but might be the only important case relevant for backports. 20:14:49 bunk: writing up the exact problem and proposed solutions (with pros and cons) may be worth it 20:15:10 I'll do that after Christmas 20:15:18 and if debian-ftp and debian-backports can help with some of the solutions, that's good to get their ideas 20:15:22 thanks 20:16:04 then I propose to close after the AOB 20:16:07 well, also include debian-release and the bug submitter, don't design a solution on your own 20:16:24 unless ginggs really want's his topic on key packages 20:16:38 should be quick? 20:16:50 #topic Should we increase the popcon threshold for key_packages? 20:17:03 ginggs: why? 20:17:13 and did you test what the difference will be? 20:17:35 why: to reduce work for us 20:17:51 that depends on the answer to the second question ;) 20:18:06 i can give you numbers, but not sure if that's interesting 20:18:21 does anyone know how the 5% figure was chosen? 20:19:12 ivodd_ probably, but I think it was a bit of gut feeling 20:20:07 also, I think that was sort of where popularity started dropping if you ordered packages by popcon or something like that 20:20:52 ok some numbers: at 5% 2350 package are key only based on popcon 20:21:27 increasing the threshold to 20% reduces that by half, to 1268 20:21:53 and key packages without popcon? 20:22:46 doko: build-deps of key packages are also key packages 20:23:05 paul@mulciber ~ $ grep reason /tmp/key_packages.yaml.cgi |wc 20:23:05 6487 20:23:51 i don't know if there are other key packages 20:23:54 so, most are key not because of popcon 20:24:48 right, but increasing the threshold for those by popcon should drop them and their build-deps, right? 20:25:13 ginggs: puppet, d-i, piuparts, debian-cd, debian-installer-netboot-images, sbuild 20:25:54 and, standard, important, required 20:26:41 you can play on coccia 20:26:45 (I think) 20:26:53 let's discuss off-line 20:27:36 no, udd.debian.org of course 20:27:45 so no objections to increasing the threshold? 20:28:00 I want to understand better before agreeing 20:28:40 (ivodd_ too I think) 20:29:23 ack 20:29:45 #action ginggs to come up with key_package threshold impact 20:29:50 #topic AOB 20:30:04 anybody? 20:30:05 An official request from me as only committed i386 porter: If you decide to not make i386 a full release architecture in bullseye, please drop it completely from bullseye. Everything else would prevent offering it as full architecture in ports. 20:30:25 elbrus: please add the release arch qualification to your first post bullseye meeting 20:30:44 Short update on the transitions since I haven't been around before. 20:30:56 doko: I think we'll try to announce something before that time 20:31:17 well, yes, I mean the qualification for bookworm 20:31:18 Sebastinas: yes please (ginggs did a bit) 20:31:28 octave and gnat should finish soon. There are some smaller (mostly smooth updatable) ones still ongoing. 20:31:36 Some of them are blocked on gnutls28 20:32:04 That is: binNMUs don't migrate because they pick up a dependency on gnutls28 in unstable 20:32:58 Once gnutls28 migrates, a bunch of transitions should be done (glade, ulfius) 20:33:18 capstone, volk and libjsoncpp as well (I think) 20:33:46 nifticlib doesn't look too good. 20:34:10 indeed 20:34:39 Then there are still some lined up: fmtlib, xalan and linphone-stack look doable before the transition freeze. 20:35:21 would now be the time to mention jruby being a key package and being pretty broken in sid? 20:35:31 happy to talk about it after the meeting if that's prefered 20:35:32 pollo: one moment, we're closing 20:35:40 php8.0 still has a lot of blocking bugs, so not sure if that would be manageable. 20:35:50 Sebastinas: it's a bit in the backlog 20:36:06 sentiment here was that it may be too much 20:36:26 ack 20:36:46 but that we should wait for the maintainers summary of things 20:37:21 Sebastinas: that's it? 20:38:00 Yes, nothing else comes to my mind. 20:38:00 (you missed the python stuff, but ginggs reported on those) 20:38:14 anybody else/ 20:38:16 ? 20:38:18 one more thing: 20:38:19 Yes, but ginggs is driving that. 20:38:49 we removed a python package which wasn't ready for 3.9, and probably won't be ready until the ff 20:39:04 how to handle an upstream ff exception? 20:39:17 full freeze? 20:39:44 doko: I think it's described in the policy 20:39:49 yes 20:39:54 that's numba 20:40:07 let's not do that here and now 20:40:11 ok 20:40:23 please check the procedures in the freeze policy 20:40:53 * elbrus I expect the answer will be: too late 20:41:06 (and soft freeze is the deadline) 20:41:15 #topic Next meeting 20:41:24 #info Next meeting is 27th January at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics) 20:41:29 #endmeeting