19:02:44 <elbrus> #startmeeting
19:02:44 <MeetBot> Meeting started Wed Mar 22 19:02:44 2023 UTC.  The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:52 <elbrus> #topic Admin
19:03:05 <elbrus> #info Previous minutes: http://meetbot.debian.net/debian-release/2023/debian-release.2023-02-22-19.01.html
19:03:20 <elbrus> #info elbrus had an action to start points in the release notes on items mentioned in the meeting of January
19:03:35 <elbrus> there are bug reports for them but no text yet
19:04:03 <elbrus> still not a lot of bugs overall...
19:04:13 <elbrus> #info <somebody> had an action to update the e2fsprogs bug about our decision
19:04:24 <elbrus> done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031325#202
19:04:40 <elbrus> and acted upon
19:04:57 <elbrus> I think we still need to help it migrate, but haven't checked today
19:05:09 <elbrus> #info <somebody> had an action to update the request-tracker4 transition bug with our conclusion
19:05:18 <elbrus> done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031587#22
19:05:48 <elbrus> until yesterday there was no progress I'm aware off, this is becoming uncomfortably late?
19:07:10 <kibi> morning
19:07:24 <elbrus> I wonder, I recall seeing some packages affected by autoremoval because of that transition; I wonder if we should avoid that...
19:07:27 <elbrus> hi kibi
19:08:00 <Sebastinas> I think there were at least two pings on the rt4 bug without reply
19:08:10 <elbrus> indeed
19:08:34 <elbrus> hence I think we should assume it's not happening, but then reverse dependencies maybe shouldn't suffer
19:09:06 <elbrus> at least I will try to keep an eye out ...
19:09:22 <Sebastinas> We could give them until end of March and if they are not ready by then, let's postpone rt4 removal
19:09:33 <elbrus> something like that indeed
19:09:41 <ginggs> agreed
19:10:21 <elbrus> #agreed: rt4 removal gets until the end of the month otherwise we defer
19:10:25 <elbrus> #topic Transitions
19:10:46 <elbrus> well, the biggest one just discussed
19:11:16 <elbrus> webkit2gtk
19:11:20 <Sebastinas> I expect two webkit related transitions to happen
19:11:22 <Sebastinas> That and the qt one
19:11:44 <elbrus> on track?
19:12:09 <Sebastinas> qtwebengine-opensource-src is staged in experimental and mostly ready to go
19:12:17 <Sebastinas> I'm waiting for a feedback from mitya57
19:12:34 <elbrus> but no worries?
19:12:40 <Sebastinas> No
19:12:43 <elbrus> great
19:13:00 <elbrus> we have one removal transition ongoing
19:13:10 <mitya57> I will check tomorrow if the two rdeps build fine. But I'm 90% sure they do.
19:13:18 <Sebastinas> mitya57: Thanks
19:13:25 <elbrus> I forgot the details, but I recall I filed a related bug
19:13:28 <Sebastinas> elbrus: equinox-framework-rm?
19:13:29 <elbrus> mitya57: thanks
19:13:31 <elbrus> yes
19:14:44 <elbrus> does anybody know more details
19:14:51 <Sebastinas> Not really
19:15:00 <elbrus> otherwise I'll look into it again tomorrow
19:15:02 <Sebastinas> I keep seeing equinox-framework in update output
19:15:38 <Sebastinas> If tycho gets auto removed, equinox-framework should no longer be blocked from being removed itself
19:16:09 <elbrus> right; bug 1031686
19:16:26 <elbrus> bug #1031686
19:16:48 <elbrus> then we have auto-upperlimit-ruby-minitest
19:17:35 <elbrus> some rebuild not migrating?
19:17:57 <elbrus> all arch:all
19:18:19 <elbrus> how can they all be green and it still being a problem?
19:18:56 <Sebastinas> TBH I don't understand what's the state there.
19:19:10 <elbrus> want to figure out, or shall I?
19:19:36 <Sebastinas> ruby-minitest is still in the archive.
19:20:05 <elbrus> -upperlimit- is the part it triggers on
19:20:16 <Sebastinas> ah
19:20:20 <elbrus> so there must be an versioned depends somewhere
19:21:08 <Sebastinas> ruby-minitest (<= 5.15.0-9999)
19:21:21 <Sebastinas> That's from ruby-maxitest
19:21:54 <elbrus> ack
19:22:08 <elbrus> but that's green on the tracker...
19:23:03 <jochensp> (libruby3.1 3.1.2-6 Provides ruby-minitest unversioned)
19:23:40 <elbrus> thanks
19:24:08 <elbrus> but do unversioned provides count for versioned Depends?
19:24:36 <Sebastinas> apt is happy to install ruby-maxitest
19:24:39 <elbrus> I guess they do but not for equality?
19:25:01 <elbrus> smells like a bug
19:25:13 <elbrus> most likely in ruby-maxitest
19:25:24 <elbrus> or in libruby3.1
19:25:32 <Sebastinas> I don't  know ruby well enough … but if ruby-minitest is provided by ruby itself, should the package be removed?
19:25:47 <elbrus> I'll ask on #d-ruby later
19:26:04 <elbrus> #action elbrus to check on ruby-maxitest Depends
19:26:19 <elbrus> I guess that's it for transitions?
19:26:33 <Sebastinas> Yes
19:26:47 <elbrus> #topic unblock request
19:26:55 <elbrus> big backlog ...
19:27:16 <Sebastinas> yeah
19:27:19 <Sebastinas> and there are some big ones
19:27:20 <elbrus> 18
19:27:34 <elbrus> anything we should discuss now?
19:27:41 <Sebastinas> kibi: do you want to be kept in the loop for di-related unblocks (e.g. di-netboot-assistant)?
19:28:39 <kibi> feel free to, but di-n-a is fine to go
19:28:51 <elbrus> bug #1033271: my first feeling is: unreviewable so, too late?
19:29:18 <Sebastinas> 80+ unblocks are not managable.
19:29:34 <elbrus> indeed
19:29:35 <Sebastinas> kibi: ACK, will unblock di-netboot-assistant and CC you for everything else that's coming up.
19:29:52 <kibi> thanks!
19:30:29 <elbrus> did anything happen with mesa today?
19:30:44 <elbrus> if not, shall I just do an NMU to tpu?
19:30:51 <Sebastinas> There's an upload to tpu
19:30:55 <elbrus> a, great
19:30:56 <Sebastinas> https://tracker.debian.org/news/1427519/accepted-mesa-2236-1deb12u1-source-into-testing-proposed-updates/
19:31:19 <elbrus> does that version make sense?
19:31:31 <ginggs> llvm-toolchain-15 just finished building on mips64el \o/
19:31:32 * elbrus would have expected a ~ instead of +
19:31:49 <elbrus> but I guess there are propups
19:32:01 <Sebastinas> ginggs: llvm-toolchain-15 needs its orig to be cleaned up
19:32:11 <elbrus> agreed
19:32:40 <Sebastinas> There are bugs with repacking …
19:33:04 <Sebastinas> But it's a key package, so I don't want anything to slip in that's not reviewable.
19:33:22 <elbrus> indeed
19:34:05 <elbrus> any other unblock we should discuss?
19:34:40 <Sebastinas> Maybe live-tasks-non-free-firmware
19:34:54 <elbrus> aha, right, the highvoltage request :)
19:35:09 <Sebastinas> It's new source and binaries, but I intend to unblock for non-free-firmware support
19:36:00 <elbrus> the descriptions have a bug, but maybe I shouldn't hold it up for that
19:36:20 <elbrus> it's talking about dependencies, but it has none
19:36:52 <Sebastinas> Indeed.
19:37:10 <Sebastinas> Good catch. Do you want to follow up or should I?
19:37:22 <elbrus> but anyways as it's a meta package I can live with the exception
19:37:31 <elbrus> I expect highvoltage to catch the backlog :)
19:37:36 <Sebastinas> :)
19:38:04 <Sebastinas> There are bunch of unblocks for cross-building and non-RT architecture fixes.
19:38:15 <elbrus> hmm
19:38:25 <elbrus> haven't seen those yet
19:38:29 <Sebastinas> I think they are out-of-scope at this stage.
19:38:38 <Sebastinas> fuse3 and ghostscript
19:38:57 <Sebastinas> (bunch = 2 ;))
19:39:10 <elbrus> without having looked at it, I tend to agree
19:39:31 <ginggs> fuse3 is also about fixing the Makefile for examples
19:40:18 <ginggs> so not only fixing build on hppa
19:40:37 <elbrus> fixing the installer on hppa it claims
19:40:43 <elbrus> kibi must be thrilled
19:41:04 <kibi> rolling on the floor thrilled
19:42:35 <kibi> (thinking of my fellow coworkers who didn't comment on #1029849 — and now #1033325 — 's RC-ness, but not to worry, patches are on the way)
19:44:16 <elbrus> bug #1029849
19:44:25 <elbrus> bug #1033325
19:45:18 <kibi> (just teasing, it's all fine)
19:46:08 <elbrus> rounding up this topic?
19:47:16 <elbrus> #topic current status of bookworm
19:48:22 <elbrus> anybody know of any blocking bug
19:48:41 <ansgar> I would like to get rid of stretch before the release date.
19:48:59 <ansgar> It saves the renaming stretch to oldoldoldstable part which is a bit annoying.
19:49:37 <elbrus> ack, but out of control for this team
19:50:30 <ansgar> Yes, I think I can find some solution to the blocker in the worst case. It's just a bit more work. Either way, should be doable.
19:51:07 <elbrus> just out of curiousity, what's a blocker for just archiving it?
19:52:00 <ansgar> elbrus: If one wants to preserve timestamps, one has to use debmirror's rsync method. Which only works with an rsync daemon. Which requires username/password (or running my own rsync; it's localhost anyway...)
19:52:26 <ansgar> Other issues like disk space (including on mirrors) should be fine by now.
19:53:01 <elbrus> ack and thanks for elaborating
19:53:56 <Sebastinas> There is a new usrmerge bug (#1033167) … but it already got a patch
19:54:35 <elbrus> it involves multiple packages, right?
19:55:31 <Sebastinas> I think that was the other one with systemd service files
19:55:53 <elbrus> I've been looking for autopkgtest failures like bug #1033147 which are related to kernel
19:56:06 <elbrus> ah, OK
19:57:43 <elbrus> luckily so far that has been the only one
19:58:27 <elbrus> shall we move on?
19:58:40 <Sebastinas> The install and upgrade jenkins jobs are still green
19:58:47 <elbrus> \o/
19:59:21 <elbrus> #topic current status of d-i
19:59:34 <elbrus> kibi: do you want to share something?
19:59:39 <kibi> we're thinking about a release these days, but linux isn't helping us much
19:59:56 <elbrus> tell carnil and he'll accomodate I bet :)
19:59:58 <kibi> lots of interesting things on the packaging side, but the upstream stable releases tend to regress here and there
19:59:59 <elbrus> but you know that
20:00:16 <kibi> so we'll have to pick and choose what we release with for the upcoming RC 1
20:00:24 <elbrus> ack
20:00:38 <helmut> Sebastinas: the usrmerge bug is 3 uploads (debianutils, dash, usrmerge)
20:00:41 <kibi> more generally: we were initially lacking feedback, but that came in, and we have a few improvements on the firmware side (just uploaded two packages)
20:00:54 <elbrus> a, you don't mean about uploads happening but that no version is perfect :)
20:00:59 <Sebastinas> helmut: ACK
20:01:20 <kibi> so I'm more or less happy where we are (or will be once we have a release out); we'll probably still want to have another one after that, to iron things out and/or deal with unanticipated fallouts from the *many* changes in e.g. hw-detect
20:01:39 <kibi> I don't have much more, but still happy to take any questions
20:01:51 <carnil> kibi: to not disturb too much the current meeting, about src:linux, I will do my best to help for whatever you need on my side
20:02:15 * elbrus loves carnil
20:02:32 <kibi> carnil: just to give some hints as to what seems problematic: the arm64 size increase that breaks Pi devices under u-boot is one, the ppc64el regression in d-i is another
20:03:35 <kibi> the same could happen with many different things, it just happens that linux is a very big piece of software, and having many archs means being able to break in various ways :)
20:03:35 <carnil> for the arm64 size increase I forward the issue this morning to upstream, I hope to get some help there, aurel32 did great work on bisecting the introducing upstream change
20:04:06 <kibi> definitely not pointing fingers (at either linux or you), just stating what's my short-term item when it comes to d-i releases :)
20:04:54 <kibi> and yeah, I saw the forward, and I'll try and look at the ppc64el one myself, time permitting
20:06:31 <elbrus> thanks; I don't have questions regarding d-i
20:06:53 <elbrus> #topic release date
20:07:23 <elbrus> I guess it will be good to have at least one weekend between the point release and the bookworm release
20:09:14 <elbrus> kibi: I wasn't sure if I read your reply that you could support all proposed dates in May or you didn't reply to the availability question
20:09:42 <elbrus> and of course none of the release managers replied
20:10:11 <kibi> lemme try and debug what I wrote
20:10:16 <elbrus> I fear we still depend on adbs handling the strings and the signing?
20:10:54 <elbrus> Message-ID: <20230316111223.jfaqqscdxsyrftxh@mraw.org>
20:11:03 <kibi> way ahead of you
20:11:17 <elbrus> :)
20:11:19 <kibi> provided we have 2 releases before end of April, I'm happy with whatever you pick in May, if May this is
20:11:32 <elbrus> ack
20:11:51 <Sebastinas> hrm, I missed that dicussion. I'll try to reply soon.
20:12:10 <kibi> (also, forgot to mention, but shim* seems fine, hence the not worrying about that part at the moment)
20:12:11 <elbrus> wasn't sure if that only covered that d-i is ready enough or also meant you could support the weekend
20:13:06 <elbrus> seems like if we want Sledge in and release in May it will be 13
20:13:31 <elbrus> I'll ping the discussion tomorrow
20:13:49 <Sledge> cool
20:14:14 <elbrus> we still need to find somebody with a key available for signing in that weekend :)
20:14:39 <elbrus> #topic AOB
20:15:12 <elbrus> anything I missed on the agenda or that popped up?
20:16:19 <elbrus> calling once
20:16:41 <elbrus> calling twice
20:16:53 <elbrus> #topic Next meeting
20:17:02 <elbrus> #info Next meeting is 26 April at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics)
20:17:12 <elbrus> #endmeeting