19:00:14 <elbrus> #startmeeting
19:00:14 <MeetBot> Meeting started Wed Sep 23 19:00:14 2020 UTC.  The chair is elbrus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:14 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:20 <elbrus> #topic Admin
19:00:29 <elbrus> #info Previous minutes: http://meetbot.debian.net/debian-release/2020/debian-release.2020-06-24-18.59.html
19:00:39 <elbrus> #info ginggs had an action for a patch to britney
19:00:46 * elbrus hasn't seen that appear
19:01:07 <elbrus> #info Sebastinas had an action to create a bug for ben
19:01:08 <ginggs> no progress :)
19:01:24 <Sebastinas> The ben bug is #970744
19:01:31 <elbrus> #info elbrus had an action to send out arch qual mail to relevant teams
19:01:42 <elbrus> https://lists.debian.org/debian-release/2020/07/msg00250.html
19:02:21 <elbrus> due to personal issues I didn't have much time to follow up, but I guess most issues were opinions anyways that didn't require a follow up immediately
19:02:33 <elbrus> valuable opinions by the way
19:02:50 <elbrus> I don't recall blocking issues
19:03:04 <elbrus> but will summarize soon
19:03:44 <elbrus> Sebastinas: thanks for the bug report, I read it later
19:03:55 <elbrus> there was already discussions
19:04:14 <elbrus> #topic Transitions
19:04:23 <elbrus> anything worth mentioning going on?
19:04:47 <ginggs> adding python 3.9 as supported version coming soon
19:05:00 <elbrus> you're ready for it ;)
19:05:35 * elbrus recalls reading that supported version soon doesn't mean it will make it to bullseye, right?
19:05:35 <Sebastinas> nettle is taking some time due ocaml/binutils incompatibilities, but should finish once caml-crush gets fixed or autoremoved early October
19:06:02 <elbrus> Sebastinas: don't be shy to remove it earlier if it's in the way
19:06:52 * elbrus not judging, just pointing out you have that power
19:07:05 <Sebastinas> ACK
19:07:41 <elbrus> is that it for transitions?
19:08:11 <Sebastinas> A perl transition is also planned, but not yet ready yet.
19:08:34 <ginggs> elbrus: you are correct, adding python 3.9 now, doesn't mean it will be in bullseye
19:08:41 <ginggs> https://lists.debian.org/debian-python/2020/07/msg00023.html
19:09:01 <elbrus> ivodd around?
19:09:28 * elbrus had a agenda item that only makes sense when he is available
19:10:02 <elbrus> next topic
19:10:04 <elbrus> #topic porter call
19:10:13 <elbrus> seems we missed it for buster
19:10:28 <elbrus> I hear we should include i386 these days
19:10:33 <elbrus> do you agree?
19:11:03 <elbrus> who wants to do the call?
19:11:33 * elbrus can do it if nobody else volunteers
19:12:07 <ginggs> i'm happy to help
19:12:24 <ginggs> not sure what that entails
19:12:40 <elbrus> mostly compose an e-mail and send it around I guess
19:12:49 <elbrus> maybe check the archive for stretch
19:13:16 <pochu> o/
19:13:23 <elbrus> hi pochu
19:13:41 <elbrus> #action ginggs to do the porter call for bullseye
19:13:46 <pochu> yeah, I think we should probably drop the i386 waivers, or give it partial weight
19:13:57 <pochu> s/probably//
19:14:43 <elbrus> so I think that will be the big thing for the bullseye porter call
19:15:38 <elbrus> ginggs: next topic is yours
19:15:46 <elbrus> #topic binNEW
19:15:51 <elbrus> care to elaborate?
19:15:59 <ginggs> sure
19:16:04 * elbrus can copy your notes from the agenda
19:16:43 <ginggs> Should uploads to binNEW (or even NEW?) only be allowed to experimental?
19:16:59 <ginggs> - this could reduce the number of uncoordinated transitions, e.g. recent json-c
19:16:59 <ginggs> - this is ftpmaster's domain, but if we are in agreement, I could take it to them
19:16:59 <ginggs> - it might be possible for it to be automated, i.e. autoreject
19:16:59 <ginggs> - am I missing any downsides?
19:18:06 <elbrus> I think some packages need exceptions, wasn't there something with src:linux that was special?
19:18:23 <ginggs> so as it stands, uploads that go through NEW need a second source-only upload before they can migrate
19:18:28 <elbrus> also, does that work with bootstrapping?
19:18:53 <ginggs> so the change i'm suggesting is that the first upload needs to go via experimental
19:18:56 <elbrus> only if they include arch:all
19:18:57 <Sebastinas> As long as they don't have arch: all binaries, they just need a binNMU.
19:19:56 <ginggs> yeah, that's true
19:20:15 <pochu> that part could be solved with throw-away binaries
19:20:31 <elbrus> what's the status on that?
19:20:39 <elbrus> there's patches IIRC
19:20:49 <elbrus> by pabs and ivodd
19:20:57 <pochu> elbrus: oh are there? I wasn't aware of them
19:21:04 <elbrus> but no progress...
19:21:09 <Sebastinas> I can understand where the idea is coming from, but it adds extra work to time-starved maintainers.
19:21:15 <elbrus> I'm not totally sure I got the subject right
19:21:31 <ginggs> that doesn't help with uncoordinate transitions though
19:21:50 <Sebastinas> Then restrict to binNEW packages in Section libs
19:22:11 <ginggs> Sebastinas: yeah, that could work
19:22:42 <pochu> Sebastinas: but only when a lib package is also removed?
19:22:49 <elbrus> there's more transitions, but I guess the point is it could be a starter
19:23:15 <Sebastinas> pochu: Yeah
19:23:41 <pochu> btw I don't mind the ocasional small transition going through unstable without coordination. or at least it hasn't been a problem IME
19:24:23 <pochu> this idea sounds good to avoid potential trouble, but I wouldn't want it to be more work for maintainers if it's not needed
19:25:01 <ginggs> yeah, and wouldn't want to create more work for ftpmasters either
19:25:41 <ginggs> thanks for your input
19:25:51 <elbrus> additional note, the freeze policy now explicitly mentions that adding (or removing) binaries during the freeze is not allowed...
19:26:28 <elbrus> ginggs: so, you'll drop the idea, contemplate on it, or take it to the ftpmaster?
19:27:19 <ginggs> contemplate - nothing to take to ftpmaster just yet
19:27:54 <elbrus> #action ginggs think about proposal for blocking binNEW in unstable
19:28:13 <elbrus> #topic Packages should not depend on shared binutils libraries
19:28:21 <elbrus> ginggs, this is also yours
19:28:53 <ginggs> the package description for binutils-dev says "Note that building Debian packages which    depend on the shared libbfd is Not Allowed."
19:29:32 * elbrus wonders by who it is not allowed :)
19:29:38 <ginggs> d.oko :)
19:29:49 <elbrus> but you agree?
19:30:00 <ginggs> i couldn't find any references in policy
19:30:22 <ginggs> he does file bugs like #964537 with hints on how to fix
19:30:52 <ginggs> i found an old bug in ubuntu https://bugs.launchpad.net/ubuntu/+source/linux/+bug/783660
19:30:52 <elbrus> Build-Using is for licencing
19:31:10 <ginggs> where v.orlon writes : "By dynamically linking libbfd, it is not possible to have older versions of the perf tool installed (as there can only be one version of this lib). Also, Debian policy actually forbids depending on a certain version of the library).
19:31:13 <ginggs> "
19:31:59 <ginggs> and even redhat seem to have a similar policy https://bugzilla.redhat.com/show_bug.cgi?id=66222
19:32:23 <ginggs> "If you need to use bfd in some application, you need to link it statically in (e.g. -Bstatic -lbfd -Bdynamic) or be prepared for recompiling it every time binutils are upgraded."
19:33:36 <elbrus> would it makes sense to point policy-maintainers at this issue?
19:33:44 <ginggs> yesterday j.cristau wrote in this channel "i'm not sure static linking is any better tbh, if anything it makes it less likely anyone will notice and rebuild"
19:34:16 <ginggs> well, we write some policy
19:34:38 <ginggs> is this something we want to own?
19:34:51 <elbrus> doesn't feel like we should to me
19:35:43 <elbrus> do you think Debian policy doesn't already cover it (according to the vorlon quote)
19:36:10 <ginggs> i.e. only binaries from src:binutils may dynamically link to libbinutils
19:36:44 * elbrus doesn't know why libbinutils is special, so assumes it is in some way
19:37:39 <ginggs> it sounds like there can only be one version of libbinutils
19:37:54 <elbrus> fundamentally?
19:39:36 * elbrus proposes you take it to a policy bug
19:39:57 <elbrus> if not covered by the current text
19:40:16 <elbrus> more input?
19:40:35 <ginggs> I think setting up a permanent tracker might be useful
19:40:41 <ginggs> i can do that
19:40:46 <elbrus> fine by me
19:41:10 <elbrus> #action ginggs to set up permanent tracker for binutils
19:41:28 <elbrus> but isn't that a bit weird if it's forbidden?
19:41:44 <zeha> not sure you want non-team input: if its a private library, why is it in a libXY package, and why does it install into a system/shared library path
19:42:07 <zeha> (not sure there's a policy against linking to private libraries from unrelated packages)
19:42:33 <ginggs> I don't there's enough to take to a policy bug yet, further discussion need
19:42:37 <ginggs> -ed
19:43:17 <elbrus> you'll keep an eye on the problem, I assume?
19:43:31 <ginggs> ja
19:43:38 <elbrus> great
19:43:43 <elbrus> #topic autopkgtest policy
19:44:13 <elbrus> due to the recent discussion on d-devel@l.d.o I noticed we're slightly inconsistent
19:44:32 <elbrus> rc_policy says we want autopkgtest to test binaries "in some way"
19:44:48 <elbrus> while our freeze_policy talks about substantial testing
19:45:17 <elbrus> I think we lean more to substantial than "some way" nowadays
19:45:31 <elbrus> especially due to the hard freeze proposal
19:46:39 <elbrus> I propose I'll write a draft for an updated rc_policy
19:46:52 <elbrus> unless you now say the current text is fine
19:46:59 <elbrus> https://release.debian.org/bullseye/rc_policy.txt
19:47:02 <elbrus> bottom
19:47:50 <elbrus> mostly "mere installability or --version or the like is not enough"
19:48:13 <ginggs> current text says "These tests must test at least one of its own installed binary packages in some way, or must be marked as superficial."
19:48:38 <ginggs> I guess that could be reworded to be clearer
19:48:41 <elbrus> well, running --version is testing installed binaries
19:48:48 <elbrus> exactly
19:49:07 <elbrus> ok, I'll propose something and we discuss there
19:49:18 <ginggs> great!
19:49:36 <elbrus> #action elbrus to propose minor rc_policy text update for autopkgtest superficiallity
19:49:57 <elbrus> #topic AOB
19:50:03 <elbrus> anybody?
19:51:08 * elbrus was wondering if we could maybe meet with audio (and video) once
19:51:42 <elbrus> a sprint before the freeze would be good I guess
19:52:11 <ginggs> (and beer)
19:52:42 <elbrus> and discussion on Toy Stories
19:52:56 * elbrus got the DVD's for his birthday recently
19:53:08 <ginggs> oh happy birthday :)
19:53:33 <elbrus> #topic Next meeting
19:53:45 <elbrus> #info Next meeting is 28th October at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics)
19:53:52 <elbrus> #endmeeting