19:36:03 <nthykier> #startmeeting
19:36:03 <MeetBot> Meeting started Wed Oct 23 19:36:03 2019 UTC.  The chair is nthykier. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:36:03 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:36:18 <nthykier> #addchair elbrus
19:36:22 <nthykier> #chair elbrus
19:36:22 <MeetBot> Current chairs: elbrus nthykier
19:36:26 <elbrus> :)
19:36:48 <nthykier> #topic Actions and follow ups
19:36:55 <elbrus> ivodd ginggs ^
19:37:00 <nthykier> #info Last meeting minutes being  http://meetbot.debian.net/debian-release/2019/debian-release.2019-08-28-19.05.html
19:37:01 <elbrus> pochu
19:37:16 <elbrus> adsb; kibi ...
19:37:34 <elbrus> jcristau: (promised to not be around)
19:37:45 <nthykier> elbrus: You had an action "to propose a first version to reportbug"; how did that go?
19:38:01 <elbrus> submitted but not applied
19:38:48 <elbrus> https://salsa.debian.org/reportbug-team/reportbug/merge_requests/31
19:38:49 <adsb> o/
19:39:06 <nthykier> #info elbrus had an action about proposing an update to reportbug: Done; pending review: https://salsa.debian.org/reportbug-team/reportbug/merge_requests/31
19:40:26 <nthykier> elbrus: is the arch-qual action also done?
19:40:39 <elbrus> mips is removed
19:40:55 <elbrus> I added a header that it's early in the cycle and we haven't properly started
19:41:00 <elbrus> so yes, don
19:41:02 <elbrus> done
19:41:03 <nthykier> #info elbrus had an action to update the arch-qual table and that has been done
19:41:06 <nthykier> :)
19:41:21 <elbrus> the action of ivodd is also done
19:41:28 <elbrus> to get access for ginggs
19:41:37 <elbrus> he has been scheduling binNMU's
19:41:46 <nthykier> #info ivodd had an action  to request wb access to ginggs and that is also done
19:41:56 <nthykier> (or ginggs hacked wb - we shall never know :P)
19:42:25 <elbrus> we could ask him :)
19:42:38 <nthykier> cool, I think that was it for actions + follow up
19:43:12 <nthykier> Moving on to transitions
19:43:18 <nthykier> #topc Transitions
19:43:19 <nthykier> ...
19:43:24 <nthykier> #topic Transitions
19:43:38 <elbrus> going OK I think
19:43:39 <nthykier> Perl got done \o/
19:43:42 <elbrus> indeed
19:43:56 <elbrus> thanks to ivodd to get britney passing stuff
19:44:32 <elbrus> currently there's some items behind gcc-9 which (last time I looked) didn't build anywhere
19:44:41 <elbrus> hope that's not going to be an issue
19:44:48 <nthykier> #info Perl transition is finished without "too many issues"
19:45:19 <elbrus> firefox-esr is blocked
19:45:25 <nthykier> on?
19:45:32 <elbrus> on nodejs on <arch>
19:46:07 <elbrus> missing build on armel
19:46:07 <elbrus> missing build on mips64el
19:46:18 <elbrus> oops
19:46:23 <elbrus> firefox-esr unsatisfiable Build-Depends(-Arch) on armel: nodejs (>= 8.11)
19:47:03 <elbrus> aha, new one today
19:47:07 <nthykier> if it is missing builds on armel and mips64el, then it has 3 issues
19:47:14 <elbrus> so hopefully thats resolving itself
19:47:21 <nthykier> (and not just one)
19:47:43 <elbrus> nah, that all seems fresh
19:47:50 <elbrus> so my notes are outdated
19:48:03 <nthykier> ok
19:48:04 <ansgar> nodejs/armel seems unsupported.
19:48:23 <ansgar> As in "armel is not present in the architecture list set by the maintainer"
19:48:30 <elbrus> than firefox-esr on armel is unsupported
19:48:32 <nthykier> elbrus: you added a note "How to divide the work effeciently?" under transition; could you expand on that?
19:48:53 <elbrus> I think pochu did most work in the buster release
19:49:10 <nthykier> (re: firefox-esr - removal from armel seems prudent if we cannot support there anyway)
19:49:14 <elbrus> I was wondering how to divide the work; to avoid to much duplicate work
19:49:30 <elbrus> too
19:50:14 <elbrus> in most transitions one needs to look around to get a gasp on it
19:50:28 <adsb> +r
19:50:32 <elbrus> so, should we try to divide the transitions?
19:51:18 <elbrus> or how do we avoid acking something that's in the way of another plan?
19:51:19 <nthykier> divide in the sense that "5 for you, 5 for me, 5 for Adam, ..."?
19:51:26 <elbrus> just use the bts for all this?
19:51:42 <elbrus> or, the one you ack, you follow?
19:52:05 <elbrus> except that just doing binNMU's once a transition starts doesn't seem to be too bad
19:52:06 <adsb> good luck giving me 5 transitions :P
19:52:09 <elbrus> except sometimes
19:53:01 <nthykier> I tend to go with "the on you ack, you follow" as a rule of thumb - especially when I am low on time (although, I am generally fine with people showing up and helping out with "my transitions" - which was the case with my last two in fact)
19:53:34 <elbrus> I'm fine with that
19:53:47 <nthykier> I think it would be great if we could get a stable link between the BTS and the transition (notably close of the BTS bug when the transition is done)
19:54:01 <nthykier> (which is easier said than done)
19:54:42 <elbrus> the autotransitions are not too difficult to spot and close
19:55:00 <elbrus> but yes, automation is cool
19:55:19 <nthykier> (most of the auto-transitions rarely "really" need a bug in the first place >.>)
19:56:01 <elbrus> but most difficult ones typically *also* have an auto-transition
19:56:49 <elbrus> related question
19:57:05 <elbrus> when do we start to "worry" about transitions that don't finish?
19:57:25 <elbrus> e.g. auto-double-conversion
19:57:37 <elbrus> or auto-ldc
19:58:01 <elbrus> closer to transition freeze I guess
19:58:42 <nthykier> in general yes, although we can kick packages out of testing to "help things along" earlier
19:59:09 <elbrus> sure, autoremovals are great for that
19:59:18 <nthykier> :)
20:00:02 <elbrus> next topic?
20:00:03 <nthykier> btw, we are at the originally planned end time.  Should I finish up the meeting now or do people have time to continue?
20:00:16 <elbrus> I have some more time
20:00:31 <nthykier> "next topic?" answers my next question assuming we continue ;)
20:01:02 <nthykier> ok, moving on
20:01:12 <nthykier> #topic Python 2 binary packages removal
20:01:22 <elbrus> brought in by ginggs
20:01:55 <nthykier> can you shortly describe the issue?
20:02:08 <elbrus> <ginggs> people are asking if there's a release goal for removing python2 from bullseye
20:02:08 <elbrus> <ginggs> (are release goals still a thing even?)
20:02:08 <elbrus> <ginggs> some people are wanting to make all leaf packages depending on python2, RC
20:02:30 <elbrus> <ginggs> the people who don't want this, want an answer from release team
20:02:53 <elbrus> I don't think we do release goals anymore
20:03:09 <nthykier> ok, the first part is easy to answer: We do not do release goals indeed
20:04:05 <elbrus> doko proposed a discussion on #d-python next week
20:04:33 <elbrus> I suggested for packages that want to drop their python2 binary to communciate with their reverse dependencies
20:04:36 <elbrus> before dropping
20:04:43 <elbrus> and ideally agree on a timeline
20:04:52 <nthykier> I am conceptually for removing legacy code, but as I recall the current python2 removal flows have been causing us issues, so I am not in a hurry to support a removal frenzy
20:04:53 <elbrus> leaf packages are fine of course
20:05:31 <elbrus> yes, britney has an issue that is considers the python 2 package cruft and leaves it in testing if package still depend on it
20:05:40 <elbrus> and some package now also FTBFS in testing
20:05:52 <elbrus> so yes, more coordination is needed
20:06:11 <nthykier> well, they are cruft from how we defined cruft in britney and we have configured britney to ignore cruft
20:06:24 <nthykier> (ignore_cruft=1)
20:06:29 <elbrus> yes, but cruft was supposed to be only in libs/oldlibs
20:06:33 <nthykier> no
20:06:38 <elbrus> a
20:06:43 <nthykier> that is smooth updates
20:06:56 <elbrus> right
20:07:05 <nthykier> cruft is "any binary no longer built by a source" (roughtly speaking)
20:07:08 <elbrus> ack
20:07:29 <nthykier> smooth updates applies to the subset that is in libs/oldlibs (possibly over simplified)
20:08:03 <elbrus> so the problem is not cruft (which I thought), but the fact that not all cruft is maintained to enable packages to build in testing
20:08:23 <elbrus> so it's the lack of cruft that's the problem
20:08:40 <elbrus> but we also want packages to build in testing, how do these two add up?
20:09:01 <nthykier> if we disable ignore_cruft, then britney will not allow migration of packages that have unhandled cruft items.  It *may* be a solution to reduce the number of (future) issues in testing
20:09:21 <nthykier> although it will immediately make the existing backlog apparent and affect transitions
20:09:29 <elbrus> right, but it's also there for a purpose
20:09:52 <olly> (even if release goals were still a thing, python2 removal would seem to fail at the "Affect more than just one set of packages (eg: not just a package transition)" requirement)
20:10:50 <nthykier> I think we enabled to make our lives easier in general as the auto-decrufter in dak either did not exist or had (still have?) limitations that make it inadequate to handle most issues beign cruft
20:11:01 <elbrus> can smooth-upgrades happen without cruft?
20:11:09 <nthykier> yes
20:11:18 <nthykier> smooth-updates existed before "ignore-cruft" was added
20:11:23 <elbrus> ok
20:11:52 <elbrus> the auto-decrufter still doesn't work well for arch:all IIAC
20:12:10 <nthykier> ignore-cruft basically makes britney ignore old binaries *in sid*
20:12:33 <nthykier> where smooth updates applies to the obsolete binary *in testing*
20:13:12 <elbrus> I think ivodd found that ignore-cruft allowed cruft in testing (for the python cases)
20:13:40 <nthykier> ok - anyhow, I would just make sure we all were aware of the configuration and that it can be changed
20:13:53 <elbrus> I still have it on my todo to look at his ivodd/cruft-old-libraries-v5
20:13:56 <elbrus> branch
20:14:11 <elbrus> that was a valid remark indeed
20:14:16 <nthykier> I think we should rewind back to the original question: People expect us to say something about the python2 removal?
20:14:27 <elbrus> ack
20:15:19 <elbrus> I tend to think that communication with the maintainers need to happen, you don't need RC for that
20:15:33 <nthykier> ack
20:15:58 <elbrus> on the other hand, the amount of packages is huge
20:16:01 <nthykier> According to the python2-rm tracker, we got 1676 "bad" source packages left
20:16:04 <nthykier> indeed
20:16:33 <elbrus> http://sandrotosi.me/debian/py2removal/
20:16:38 <elbrus> has a nice overview
20:17:15 <elbrus> I can see how it helps to slowly peel away leave packages by autoremovals
20:17:46 <elbrus> but I'd like to state that maintainers should be empowered to drop the RC level to gain more time
20:18:43 <elbrus> I like the peeling better than the approach of core packages dropping their python 2 binary
20:18:59 <elbrus> like the python-django I'm still blocking
20:19:02 <elbrus> that's no fun
20:20:23 <elbrus> for what it's worth, ginggs opinion was that leaf packages could be RC for python2-rm
20:20:56 <elbrus> I'm not sure, as it feels like a stick
20:21:07 <elbrus> there should be a carrot ;)
20:22:33 <elbrus> shall we agree here that the RT doesn't say that leave packages in the python2-rm transition are RC?
20:23:16 <elbrus> or did I misjudge the silence
20:24:42 <elbrus> nthykier: still around?
20:25:14 <nthykier> elbrus: yes, sorry - I lost connection to my IRC bouncer
20:25:41 <elbrus> you have the backlog?
20:26:00 <nthykier> just did - I am personally also not ready to make python2-rm RC
20:26:37 <elbrus> #agree RT doesn't say that leave packages in the python2-rm transition are RC just yet
20:26:49 <elbrus> leaf packages obviously
20:27:24 <nthykier> (if we fix the issue with britney and testing, I might be inclined to change my stance as it would reduce the effect of this transition)
20:27:51 <elbrus> all right
20:28:00 <nthykier> effect -> consequences of "unorderly python2 removals"
20:28:30 <elbrus> shall we postpone the other topics to next time?
20:29:38 <nthykier> that might be  good -  I am experiencing a noticable lag on my end
20:30:56 <nthykier> #topic Next meeting
20:31:17 <nthykier> #info Next meeting is 27th November at 19:00 UTC (import into your calendar via https://release.debian.org/release-calendar.ics) [Remember DST if you are affected by that]
20:31:20 <nthykier> #endmeeting