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