18:59:18 <elbrus> #startmeeting
18:59:18 <MeetBot> Meeting started Wed Sep 28 18:59:18 2022 UTC.  The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:18 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:28 <elbrus> #topic Admin
18:59:38 <elbrus> #info Previous minutes: http://meetbot.debian.net/debian-release/2022/debian-release.2022-03-23-20.03.html
18:59:50 <elbrus> #info ginggs had an action to work on list for a warning for mipsel and mips64el
19:00:34 * elbrus doesn't think that happened, but lets ginggs tell how far he got
19:00:59 <ginggs> i have nothing more than the concerns from the various teams
19:01:10 <elbrus> ack
19:01:18 <elbrus> #info elbrus had an action to add autopkgtest support in britney to arch qual web page
19:01:20 <elbrus> done
19:01:31 <elbrus> #info ginggs had an action to send out e-mail to team if they have any architecture concerns (like previous release cycles)
19:01:47 <ginggs> that was done
19:01:55 <elbrus> we learned that not all teams received the mail
19:02:18 <ginggs> although problems with not reaching all lists
19:02:50 <elbrus> shall we resend the mail or do a follow-up?
19:03:08 <ginggs> i resent to those that were publicly archived, and followed up with people at debconf
19:03:19 <ginggs> I think we have answers from everyone
19:04:08 <elbrus> let's come back at it in a later topic
19:04:18 <elbrus> #info elbrus had an action to draft a new bits
19:04:20 <elbrus> failed
19:04:35 <elbrus> I'll try again and I have a topic for input
19:04:45 <elbrus> #topic Transitions
19:04:58 <elbrus> Sebastinas: any news worth sharing?
19:05:01 <Sebastinas> ghc is finally happening.
19:05:06 <elbrus> \o/
19:05:22 <Sebastinas> It's just take some time to get through all the binnmus
19:05:27 <elbrus> mostly waiting for the rebuilds now?
19:05:29 <elbrus> ack
19:05:32 <Sebastinas> Mostly waiting for mips*el
19:06:12 <Sebastinas> There are some arch-specific bugs, but those packages where removed from testing (as far as I can tell).
19:06:43 <Sebastinas> s/where/were
19:07:09 <Sebastinas> Otherwise: ruby 3.1 is ongoing and almost done
19:07:16 <Sebastinas> glibc 2.35 is done
19:07:24 <Sebastinas> A perl transition is being prepared
19:07:37 <Sebastinas> gnome 43 is almost complete.
19:07:56 * elbrus worked a bit on the remnants of the python3.10-only transition, that should now nearly be done (some removals pending)
19:08:42 <Sebastinas> At some point I need to find some time to take a look at openfjx to finish ffmpeg. But that packages is a pain.
19:08:58 <elbrus> ack
19:09:07 <Sebastinas> It's a collection of embedded copies of old version of gstreamer and friends
19:09:41 * elbrus also worked on python2-rm, two last hurdles: pam-python (used by -edu) and qtwebengine-opensource-src
19:10:06 <Sebastinas> h01ger: can -edu move of off pam-python?
19:11:04 <Sebastinas> I'll ask mitya57 what's the state of qtwebengine-opensource-src before starting the next Qt transition
19:11:09 <elbrus> Mike (forgot his nick) promised to work on porting, but alas
19:11:31 <h01ger> Sebastinas: please ping the bug via the bts
19:11:38 <h01ger> trying to go afk since 2h
19:11:47 * elbrus pinged the bug already
19:12:08 <h01ger> :) (like today?)
19:12:14 <elbrus> although not with that specific question, but I'm sure that crossed their minds
19:12:18 <elbrus> no, but recently
19:12:19 <Sebastinas> There's pkg-config coming up, but I don't think that one needs our involvement.
19:12:40 <elbrus> Fri, 16 Sep 2022 22:50:29 +0200
19:12:48 <elbrus> ack
19:13:33 <h01ger> sep 16 is like 48 dinstall runs ago!
19:13:38 <elbrus> sunweaver.... (nick for Mike; we talked about python-pam)
19:14:00 <elbrus> true
19:14:25 <elbrus> Sebastinas: anything more on transitions?
19:14:38 <elbrus> should we ask how php8.2 is going in experimental?
19:14:39 <h01ger> #937234 is also not filed against an -edu- package, so its easy to miss
19:15:40 <Sebastinas> Don't think so. All other transitions are relatively small and mostly self-contained.
19:15:48 <elbrus> #topic current status of bookworm
19:16:48 <elbrus> https://udd.debian.org/dev/cgi-bin/rcblog7.cgi shows a bit much bugs in the "Affecting bookworm and unstable":rest group but I haven't check very recently
19:17:52 <elbrus> so at least I can't really say how good bookworm looks like right now, but I'm not aware of very bad bugs yes
19:17:56 <elbrus> s/yes/yet
19:18:39 <elbrus> merged-/usr seems to have triggered some issues, but from what I've seen, nothing bigger than expected
19:18:39 <Sebastinas> A bunch of those are on my "hopefully removed soon" list.
19:18:46 <Sebastinas> vtk7 for example
19:18:56 <elbrus> right
19:19:02 <kibi> if you mean breaking the installer is not bigger than expected, good
19:19:11 * elbrus missed that
19:19:23 * elbrus had the "what I've seen" disclaimer ;)
19:19:46 <kibi> debootstrap got a fix, base-installer too (checked just yesterday), and libdebian-installer wants to get uploaded too, so that cdebconf and other users get the same fix
19:20:16 <elbrus> well, it's indeed really the area where I expected issues, yes
19:20:30 <elbrus> but still, always annoying
19:20:42 <kibi> bluca and others have kept a close eye on this, and patches came up quite quickly, so I'm actually OK with your initial statement; we're not dragging this for months (famous last words)
19:21:01 <elbrus> exactly
19:21:42 <kibi> (the essential/required sets have been quite stable over time, seeing mostly removals; I suppose nobody expected the perl:any acquisition)
19:21:46 <elbrus> it seems to be handled so far, which is the most important thing in my opinion in those kind of "final" moves
19:21:53 <h01ger> clone #937234 and reassigned the clone to src:debian-edu-config
19:22:01 <h01ger> cloned
19:22:09 <elbrus> h01ger: thanks
19:22:55 <elbrus> any other comment on the bookworm status? (d-i comes next)
19:22:57 <h01ger> (will add affects & retitle & etc tomorrow or soon)
19:23:03 <kibi> elbrus: right; and still plenty of time to spot and fix fallouts that would not have been seen immediately
19:23:45 <h01ger> sadly debian-edu hasnt been ready for bookworm for months due to #1003694 :(
19:24:03 <h01ger> also in need of retitling it seems :(
19:24:47 <elbrus> boo (not blaming the messenger)
19:24:52 <elbrus> #topic current status of d-i
19:24:52 <h01ger> people with time and php knowledge would be very welcome to help fixing this bug. sunweaver didnt find time for it in months and i havent touched php in a, nah, two decades
19:25:11 <kibi> we have an alpha \o/
19:25:26 <h01ger> \o/
19:25:30 <elbrus> oops, if you have more to mention h01ger don't hold back
19:25:40 <elbrus> and yes, cheers for alpha
19:25:51 <h01ger> nah. we have an d-i alpha \o/
19:25:53 <elbrus> how does it look like?
19:25:59 <kibi> sorry it took so long; didn't spot much feedback so far, except the difference between netinst (OK) and netboot (KO since it pulls stuff base install from the mirror, not the ISO, and [see above, usrmerge])
19:25:59 <Sebastinas> (also for the state of bookworm: with ghc done, we'll also get rid of another llvm-toolchain version)
19:26:45 <kibi> I suppose we'll have more to plan/implement in 3 days; I don't have anything specific to share so far
19:26:52 <elbrus> kibi: so you have enough to work on :)
19:27:14 <elbrus> thanks
19:27:25 <elbrus> #topic tier proposal
19:27:34 <kibi> I hope to spend more time than the last 12 months working on d-i, a customer would like fixes/improvements/documentation; I hope this will keep me in the zone to attempt the cdebconf rewrite.
19:27:59 <kibi> elbrus sure moves faster than I type afterthoughts :)
19:29:04 <elbrus> sorry, I'm not *that* used to charing IRC meeting
19:29:22 <elbrus> good thing it took me some time to find my link
19:29:27 <elbrus> https://lists.debian.org/debian-release/2022/09/msg00006.html
19:30:10 <elbrus> I'm not sure how to proceed
19:31:03 <elbrus> part of the discussion went private, which makes it hard to discuss here
19:31:18 <kibi> I haven't followed that too closely, but ISTR jcristau's on-list reply made sense to me
19:32:39 <elbrus> I agree with the sentiment, but still stand by my question, would it be worse or better if that would become more visible
19:33:05 <elbrus> at least if archs deteriorate that way, it's clear they are not supportable
19:33:35 <elbrus> and now that burden is on everybody, also those that don't care we do architectures
19:33:53 <elbrus> I wonder what the right balance is
19:35:29 * elbrus will reply again to the last mail
19:35:48 <elbrus> #topic NMU in stead of binNMU
19:35:59 <elbrus> ginggs, still around?
19:36:09 <ginggs> yes
19:36:28 <elbrus> we have been discussing doing no-change source-only uploads instead of binNMU
19:36:39 <h01ger> uuuuuuuh, yay.
19:36:50 <elbrus> I think Sebastinas doesn't like those because of the timing?
19:37:06 <Sebastinas> I think I've raised my concerns in our private discussion
19:37:07 <ansgar> No-change or including B-D changes? (To depend on some newer version.)
19:37:07 <elbrus> (which *could* be fixed in britney I think)
19:37:12 <kibi> what's the difference?
19:37:23 <Sebastinas> It has a bunch of unsolved questions
19:37:47 <elbrus> bunch? I recall only the BTS as the second issue
19:37:49 <kibi> happy to take pointers, I'm not sure what problems this would solve, and what others it would bring
19:38:01 <Sebastinas> dw vs extra-depends, etc.
19:38:09 <h01ger> (if there's more public info on this, i'd be very interested to hear. if not yet, also fine.)
19:38:16 <elbrus> right
19:38:42 <elbrus> but you'd still have those tools, no?
19:39:04 <Sebastinas> That'd be two tools instead of one.
19:39:16 <elbrus> kibi: one of the features would be that it would be trivial for britney to properly trigger tests
19:39:38 <waldi> we would have rebuilds for arch-all packages
19:39:42 <elbrus> during transtions, we currently don't test if the rebuild binaries work
19:39:55 <kibi> ok, ta
19:41:18 <elbrus> waldi: if arch-all packages need rebuild, no-change source-only uploads can already happen
19:41:29 <elbrus> I do those regularly
19:41:46 <helmut> m-a:same coinstallability would work reliably
19:41:56 <elbrus> but indeed a bit better tooling for that (especially less bandwith on my side) would be nice
19:43:10 <elbrus> helmut: what was again the problem there, reproducibility of the binaries?
19:43:31 <elbrus> because we try to binNMU m-a:same always together
19:43:44 <helmut> elbrus: if someone manages to binNMU for on architecture and not for another (rarely happens these days, happens for ports though)
19:44:27 <helmut> elbrus: yeah, you mostly fixed that by process
19:45:23 <Sebastinas> Broken ports will also be broken with the source-only NMUs.
19:45:50 <Sebastinas> (As long as binaries just vanish even if they are still used)
19:45:52 <elbrus> that was my thought too
19:46:05 <kibi> that means source packages that will be in the archive but not in the relevant repositories, which might be confusing to people debugging stuff?
19:46:33 <kibi> as in git or $vcs repositories, missing tags etc.
19:47:49 <elbrus> you have that problem with regular NMU's already
19:47:58 <elbrus> but I guess you mean that problem just grows
19:48:21 <helmut> potentially, no-change NMUs could be pushed to dgit to reduce that problem
19:48:50 * elbrus would be using dgit if he made the tooling
19:49:05 * kibi /o\
19:49:30 <elbrus> maybe h01ger can comment, but dgit works nicely for drive by uploads
19:49:51 <ansgar> helmut: Multiple Git repositories for a package with possibly no common history just increase the confusion...
19:49:55 * elbrus recalls he used that for his build-info missing campaign
19:50:05 <kibi> definitely not a huge dgit fan, on the receiving end…
19:50:26 <elbrus> because you miss the nice patches?
19:51:19 <helmut> let's skip the dgit part. the topic is no-change nmus
19:52:23 <kibi> yes, I prefer things neat and tidy
19:52:47 <elbrus> I propose somebody (me?) starts a wiki to collect the pros and cons to see how to balance
19:52:55 <elbrus> and pick it up later again
19:53:03 <Sebastinas> Unless no-change NMUs somehow have some integration with wb to manage dws and extra-depends, it's a net negative for me.
19:53:15 <elbrus> Sebastinas: I hear you
19:53:18 <helmut> elbrus: in case you do, little pro: I can drop a bunch of code from rebootstrap
19:53:38 <elbrus> helmut: it'd be a wiki; you could add that ;)
19:53:46 <aurel32> technically there is the option of modifying the dependencies in the .dsc without changing the sources that are upload. It's ugly, but it's already used in the archive
19:54:17 <ansgar> aurel32: Packages in the archive can't do that though?
19:54:43 <ansgar> There is no code-executing target required for building a source package after all.
19:54:51 <aurel32> apt or w-b looks at the Sources file which come from the .dsc
19:55:12 <aurel32> so you build your package, you modify the build-deps in the .dsc, sign, upload
19:55:33 <aurel32> that's clever, but also ugly
19:55:48 * elbrus loves it ;)
19:55:50 <ansgar> ~.~
19:56:05 <aurel32> that way you don't need extra-depends
19:56:12 <helmut> ansgar: I can see this breaking things. e.g. rebootstrap checks satisfiability against the .dsc but actually installs d/control
19:56:17 <helmut> err aurel32 ^
19:56:33 <ansgar> Some people also do that to remove Recommends (as apt uses that from Packages too). It is somewhat evil and probably does trigger bugs...
19:56:57 <aurel32> helmut: I mean extra-depends on the w-b side, two avoid having to use 2 tools
19:57:37 <helmut> aurel32: I think I got that. in the end, you'll have the .dsc B-D mismatch the d/control B-D for packages in the archive
19:59:26 <elbrus> #action elbrus starts a Wiki page to collect pros and cons for no-change NMU vs binNMU (and potential solutions)
20:00:15 <elbrus> shall we continue or wrap up (topic and meeting)?
20:00:19 <ansgar> Ubuntu does this already? What do they do for build-deps?
20:00:41 <elbrus> ginggs: do you know?^
20:01:12 <aurel32> there's the option of always upgrading the chroot at the beginning of a build
20:01:40 <ansgar> aurel32: But that only works if the b-d already is satisfiable?
20:01:40 <aurel32> it will make builds slower, and will propagate issues faster to the archive, but that's an option
20:01:40 <ginggs> i don't think they do anything for build-deps
20:02:09 <h01ger> elbrus: nope, i cannot comment on dgit cause i have almost 0% exp with it. tried it twice maybe..
20:02:22 <ansgar> i.e., you can't do source-NMUs now and have w-b figure out the right order and timing.
20:02:23 <elbrus> ginggs: so if the build happens too soon, than that means another upload?
20:02:23 <aurel32> ansgar: yes, indeed, i was more thinking at the extra-depends case than the build-depends one, so that indeed doesn't work for the latter
20:02:31 <ginggs> elbrus: yeah
20:03:02 <h01ger> but i can see how perfect is the enemy of better (than binNMUs) :)
20:04:58 <elbrus> do we have time for another "nice idea" of me and ginggs? or shall we do that next time?
20:05:33 <kibi> time is fine for me
20:06:28 <elbrus> #topic being less strict about not removing <!nocheck> and <!nodoc> B-D of key packages?
20:07:22 <elbrus> due to bugs introduced by me in udd, we have had multiple occasions where everybody was informed that everything would be removed from testing
20:07:33 <elbrus> that works great to get RC bugs fixed in key packages
20:07:39 <elbrus> so, autoremoval works
20:07:41 <helmut> I'm less fond of <!nodoc> as it is misused quite often, is unreproducible and not verified by anything
20:07:47 <elbrus> for non key packages
20:07:53 <elbrus> see also https://release.debian.org/key-packages.html
20:08:37 <helmut> and for <!nocheck>, I think a prerequisite would be filing nocheck FTBFS at rc level (we currently don't do that)
20:08:46 <elbrus> I do value our promise a lot that you can rebuild our packages
20:08:51 * ginggs thinks elbrus should threaten to remove everything from testing once a month
20:09:07 <elbrus> but sometimes trading an RC bug for another RC bug is the right thing to do
20:09:57 <elbrus> helmut: ack
20:10:08 <helmut> I've seen packages that got the logic for nocheck wrong and would only run (and fail) tests when passing nocheck
20:10:40 <elbrus> helmut: seems like you suggest that <!nocheck> is verified
20:11:16 <helmut> it is being verified by crossqa.d.n for a fraction of the archive. I guess around 20%.
20:12:01 <helmut> nocheck is supposed to be a reproducible profile, but we also have packages violating that property and crossqa.d.n does not check that
20:12:17 <elbrus> what I meant to suggest is something along the line of "we promise you can rebuild your packages, but sometimes to work around RC issues, you will only be able to do that with the nocheck build profile"
20:12:57 <elbrus> if we can reduce the key package set that way, I think that's a win
20:13:08 <elbrus> (probably, most of the time)
20:13:13 <helmut> I like the idea, but prerequisites seem missing to me. start with requiring packages to build with nocheck. it's a normal bug at present
20:13:52 <elbrus> what do you mean with that last 'requiring"?
20:14:02 <helmut> nocheck ftbfs -> serious
20:14:36 <elbrus> agree
20:14:40 <ginggs> agree
20:14:46 <h01ger> if those were normal bugs til now, i would make them important now and rc after bookworm?
20:15:01 <elbrus> ack that too
20:15:48 <elbrus> to be clear, I don't need this implemented tomorrow (or before bookworm), I'm trying to get a feel for what people think about it
20:15:54 <sunweaver> sorry for not being as available for gosa/php fixes and the pam-python Py3 transition. Both issues are on my list, but none of them is trivial to amend.
20:16:26 <elbrus> ack
20:17:05 <h01ger> sunweaver: ack & hi
20:18:06 <elbrus> helmut: can you comment on why nodoc is unreproducible by the way?
20:19:16 <helmut> nodoc was meant to drop -doc packages from the build. instead, people use it to drop documentation files from binary packages carrying other content
20:19:43 <helmut> thus if you build with/without nodoc, you often get differring .debs rather than a reproducible subset of .debs
20:20:13 <elbrus> so we need a new nodocdeb profile
20:20:13 <helmut> this also happens for nocheck (e.g. when test results are included), but way less frequently
20:20:46 * elbrus has seen that yesterday indeed (codec2) and will need to update his MR
20:21:05 <helmut> also a number of nodoc profiles have been elided, because doing an arch-only build was equivalent (the -doc package being the only indep package)
20:21:44 <helmut> would it be possible to special case this in the autoremover instead? if the -doc package is the only arch:all package, consider b-d-i droppable
20:21:46 <sunweaver> pam-python: https://github.com/Ionic/pam-python/commits/master -> Ionic has been working on a Py3 port in the past days for one of my customer projects. But, I still need to test this on Debian Edu.
20:22:32 <elbrus> interesting idea
20:22:47 <elbrus> sunweaver: great news
20:23:04 <elbrus> (as in: progress)
20:24:37 <elbrus> #action elbrus to check if he can patch udd to special case b-d-i in case of only -doc as arch:all
20:25:10 <elbrus> I sense people are not fundamentally opposing the idea, which is already great
20:25:27 <elbrus> but I also sense we shouldn't rush here
20:26:13 <elbrus> #topic topics for bits
20:26:27 <elbrus> I want to do a bits soon again
20:26:45 <elbrus> at least mentioning the freeze is approaching
20:27:06 <elbrus> (so similar like last releases; a couple of months before the freeze)
20:27:18 <elbrus> are there more topics that should go in?
20:28:35 * elbrus already had an action to draft bits, so he carries that over
20:28:47 <elbrus> #topic AOB
20:29:04 <kibi> thanks, chairperson elbrus
20:29:24 <elbrus> LOL
20:30:18 <elbrus> anybody else?
20:30:54 <ginggs> nope
20:31:48 <elbrus> #topic Next meeting
20:32:01 <elbrus> #info Next meeting is 26 October at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics)
20:32:12 <elbrus> #endmeeting