Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Ping again. Thanks. On Thu 28 Mar 2024 at 01:33pm +08, Sean Whitton wrote: > Hello, > > On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote: > >> The vote has concluded. The result is that the Technical Committee >> recommends that Craig Small be appointed by the Debian Project >> Leader to the Technical Committee. >> >> Jonathan, over to you. > > Quick ping about this. The appointment holds up some administrative > stuff for us. Thanks. -- Sean Whitton
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Hello, On Mon 18 Mar 2024 at 10:43am +08, Sean Whitton wrote: > The vote has concluded. The result is that the Technical Committee > recommends that Craig Small be appointed by the Debian Project > Leader to the Technical Committee. > > Jonathan, over to you. Quick ping about this. The appointment holds up some administrative stuff for us. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: Next meeting -- 2nd April, 12pm UTC
Hello, On Thu 21 Mar 2024 at 06:27pm +08, Sean Whitton wrote: > Dear committee members, > > Our next meeting will be on 2nd April at midday UTC, on IRC. > After that, we'll do a poll for a consistent meeting time each month for > the remainder of 2024. > > Here is our agenda: > > - Review of previous meeting's AIs > > - Bug#1065170: Requesting advice on glib2.0 #1065022 > > - Any other business > > Minutes of previous meeting not available as meetbot.debian.net is down. I just closed the bug, and several people can't make it to this meeting time anyway, so let's postpone to May. -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 2nd April, 12pm UTC
Dear committee members, Our next meeting will be on 2nd April at midday UTC, on IRC. After that, we'll do a poll for a consistent meeting time each month for the remainder of 2024. Here is our agenda: - Review of previous meeting's AIs - Bug#1065170: Requesting advice on glib2.0 #1065022 - Any other business Minutes of previous meeting not available as meetbot.debian.net is down. -- Sean Whitton
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
On Sun, Mar 10, 2024 at 10:06:42AM +0800, Sean Whitton wrote: > Package: tech-ctte > X-debbugs-cc: csm...@debian.org, lea...@debian.org > > I call for votes on the following ballot to fill a vacant seat on the > Debian Technical Committee. The voting period starts immediately and > lasts for up to one week, or until the outcome is no longer in doubt. > > ===BEGIN > The Technical Committee recommends that Craig Small be > appointed by the Debian Project Leader to the Technical Committee. > > C: Recommend to Appoint Craig Small > F: Further Discussion > ===END I vote C > F -- Sean Whitton signature.asc Description: PGP signature
Bug#1065810: tech-ctte: Call for votes on TC membership of Craig Small
Package: tech-ctte X-debbugs-cc: csm...@debian.org, lea...@debian.org I call for votes on the following ballot to fill a vacant seat on the Debian Technical Committee. The voting period starts immediately and lasts for up to one week, or until the outcome is no longer in doubt. ===BEGIN The Technical Committee recommends that Craig Small be appointed by the Debian Project Leader to the Technical Committee. C: Recommend to Appoint Craig Small F: Further Discussion ===END -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 19th February, 12pm UTC
Hello, Our next meeting will be at 12pm UTC on Monday. Here is our agenda: - Recruitment -- on Jitsi - Bug#1060700: Impact of problems caused by aliasing on declared Conflicts - Any other business -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 9th January, 6pm UTC
Dear committee members, Our next meeting is scheduled for today at 6pm UTC. Here is our agenda: - Recruitment -- on Jitsi - Review of previous meeting's AIs - Any other business -- Sean Whitton signature.asc Description: PGP signature
Re: Next meeting -- 12th December, 6pm UTC
Hello, On Mon, Dec 11, 2023 at 06:50:44PM +, Sean Whitton wrote: > Dear committee members, > > Our next meeting is scheduled for tomorrow at 6pm UTC. I'll be coming back from Manchester by train today. So I'd like to start at 6:30pm. Given that all we really have is recruitment, half an hour will be enough time. In the event that I don't show up by 6:30pm, please discuss our candidates, and let me know whether there is a clear consensus, or whatever else the outcome is. Thanks! -- Sean Whitton
Next meeting -- 12th December, 6pm UTC
Dear committee members, Our next meeting is scheduled for tomorrow at 6pm UTC. Here is our agenda: - Recruitment -- on Jitsi - Review of previous meeting's AIs - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-11-14-18.00.html -- Sean Whitton
Next meeting -- 14th November, 6pm UTC
Dear committee members, Our next meeting is scheduled for tomorrow at 6pm UTC. Here is our agenda: - Recruitment - Bastian's recent post to Bug#1007717: <20231103112032.ny3d4ieeo7wrb...@shell.thinkmo.de>> - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-10-10-17.57.html -- Sean Whitton signature.asc Description: PGP signature
Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium
Hello, On Fri 13 Oct 2023 at 09:59pm +01, Sean Whitton wrote: > === BEGIN > > OPTION A: > > The Technical Committee formally repeals its moratorium recommending > that maintainers of individual packages should not proactively move > files from the root filesystem to corresponding locations under /usr in > the data.tar.* of packages (see #1035831). > > Under Constitution 6.1.5, the Technical Committee now recommends that > maintainers consult with those driving the merged-/usr transition before > moving files from the root filesystem to corresponding locations under > /usr in the data.tar.* of packages. > > The transition driver, which at the time of writing is Helmut Grohne, is > using a phased approach, in which the moratorium is rolled back for only > certain classes of packages, and changes, at a time. In addition, > restructuring uploads should be targeted at experimental, and left for > three days. This is in order that automated testing by dumat can occur. > > We recommend following <https://wiki.debian.org/UsrMerge>, as edited by > the transition driver(s). If there is any doubt as to whether a change > you wish to make is appropriate, please seek explicit approval from the > transition driver(s). > > OPTION N: > > None of the above. > > === END I vote A > N -- Sean Whitton signature.asc Description: PGP signature
[DRAFT] tech-ctte: Repeal merged-/usr file movement moratorium
Hello, Any feedback on the following? === Package: tech-ctte I call for votes on the following resolution. Voting lasts for one week or until the outcome is no longer in doubt. === BEGIN DRAFT BALLOT OPTION A: The Technical Committee formally repeals its moratorium recommending that maintainers of individual packages should not proactively move files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages (see #1035831). Under Constitution 6.1.5, the Technical Committee now recommends that maintainers consult with those leading the merged-/usr transition before moving files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages. The transition leaders are using a phased approach, in which the moratorium is rolled back for only certain classes of packages, and changes, at a time. In addition, they request that restructuring uploads should be targeted at experimental, and left for three days. This is in order that automated testing by dumat can occur. We recommend following <https://wiki.debian.org/UsrMerge> as edited by the transition leaders. If there is any doubt as to whether a change you wish to make is appropriate, seek explicit approval from the transition leaders. OPTION N: None of the above. === END DRAFT BALLOT -- Sean Whitton
Re: Next meeting -- 10th October, 6pm UTC
Hello, Revised agenda (thanks to Helmut & Matthew V.): On Fri 06 Oct 2023 at 08:49pm +01, Sean Whitton wrote: > Dear committee members, > > Our next meeting is scheduled for Tuesday at 6pm UTC. > > Here is our agenda: > > - Review of previous meeting's AIs - Lifting the merged-/usr moratorium - apt unblock request #1053151 > - Recruitment for Simon's seat > > - Any other business -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 10th October, 6pm UTC
Dear committee members, Our next meeting is scheduled for Tuesday at 6pm UTC. Here is our agenda: - Review of previous meeting's AIs - Recruitment for Simon's seat - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-08-08-17.58.html -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#1050001: Unwinding directory aliasing
Hello, On Sat 26 Aug 2023 at 03:47pm +01, Luca Boccassi wrote: >> On Wed, 23 Aug 2023 at 10:35:42 +0100, Luca Boccassi wrote: >> > Suse [...] tried [symlink farms similar to those that Ian proposes] >> > for a few years, then had to backtrack and >> > go the way everyone else successfully went instead, which quickly wrapped >> > up as >> > expected. >> >> I alluded to that in a previous mail to this thread, but I don't have >> first-hand knowledge of the specifics of how that went, and it sounds >> as though you might. Do you have references that you can point us to? >> (To the list or as private email for me to summarize on-list later, >> whichever seems more appropriate. > > https://en.opensuse.org/openSUSE:Usr_merge_preparation#initial_situation_in_openSUSE On this page it says The previous approach did not explain how to transition from [symlinks in /bin] to the actual directories as symlinks though. This implies that opensuse's goal was to get to the symlinked layout we have now, with something like Ian's preferred layout as an intermediate step. But then problems they encountered in trying to reach Ian's preferred layout as an intermediate step need not be encountered when trying to reach Ian's layout as a desired end state. So, I'm not sure we can use opensuse's experience as so straightforward a case to learn from. -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 8th July, 6pm UTC
Dear committee members, Our next meeting is scheduled for Tuesday at 6pm UTC. Here is our agenda: - Review of previous meeting's AIs - Any remaining DebConf23 presentation arrangements - Updates on merged-/usr -- if, Helmut, you think this would be useful this month? - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-07-11-17.58.html -- Sean Whitton signature.asc Description: PGP signature
Re: Next meeting -- 11th July, 6pm UTC
Hello, On Fri 07 Jul 2023 at 12:55pm +02, Helmut Grohne wrote: > On Fri, Jul 07, 2023 at 11:11:08AM +0100, Sean Whitton wrote: >> - Updates on merged-/usr >> -- if, Helmut, you think this would be useful this month? > > Let me summarize what has happened. The rewrite of DEP17 has seen wider > circulation and little feedback. It seems to me that we have consensus > on favouring a solution that does not rely on changes to dpkg as primary > mechanism (for reasons that we disagree about). In order to move > forward, we need figure out how to mitigate the loss of aliasing > symlinks, which seems to be a topic with strong disagreement. > > I suspect that merged-/usr is now largely blocked on my availability, > which isn't helped by vacation time. There's lots of actionable things > on my todo list that are unblocked now. Thanks. Let's not discuss it at our meeting unless someone else says they want to. -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 11th July, 6pm UTC
Dear committee members, Our next meeting is scheduled for Tuesday at 6pm UTC. Here is our agenda: - Jitsi: brief welcome to new members -- then back to IRC for remaining agenda items - Updates on merged-/usr -- if, Helmut, you think this would be useful this month? - DebConf23 presentation arrangements - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-06-13-17.58.html -- Sean Whitton signature.asc Description: PGP signature
Bug#1040228: Resignation & call for votes to elect the Chair
Hello,
On Mon 03 Jul 2023 at 05:55PM +01, Sean Whitton wrote:
> ===BEGIN
>
> A: Christoph Berg
> B: Matthew Garrett
> C: Helmut Grohne
> D: Simon McVittie
> E: Stefano Rivera
> F: Timo Röhling
> G: Matthew Vernon
> H: Sean Whitton
>
> ===END
I vote
A = B = C = D = G = H > E = F
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1040228: Resignation & call for votes to elect the Chair
Package: tech-ctte Dear committee members, As the membership of the committee has changed, in accordance with convention I hereby resign as Chair, effective one week from now, and call for votes to elect the Chair of the Technical Committee. Per the Debian Constitution, the vote runs until all members have voted, or until my resignation takes effect. I would like to continue in the role, if the committee agrees. The ballot: ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Simon McVittie E: Stefano Rivera F: Timo Röhling G: Matthew Vernon H: Sean Whitton ===END -- Sean Whitton signature.asc Description: PGP signature
Re: Calls for votes on TC memberships of stefanor & roehling
Hello Jonathan, On Thu 22 Jun 2023 at 12:57PM +01, Sean Whitton wrote: > Hello, > > On Wed 21 Jun 2023 at 07:59PM +02, Jonathan Carter wrote: > >> Hi Sean >> >> On 2023/06/21 14:25, Sean Whitton wrote: >>> The votes have concluded. The TC resolves to recommend that the Debian >>> Project Leader appoint Stefano Rivera and Timo Röhling >>> to the Debian Technical Committee. >> >> How about this? > > Thanks -- LGTM! Quick ping on sending this out. Thanks. -- Sean Whitton signature.asc Description: PGP signature
The TC at debconf23
Hello committee members & nominees, I've created <https://debconf23.debconf.org/talks/10-meet-the-technical-committee/>. Could you all login to the website using salsa SSO, such that it knows about each of us, and thus the content team can add us all as presenters, please? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: Calls for votes on TC memberships of stefanor & roehling
Hello, On Wed 21 Jun 2023 at 07:59PM +02, Jonathan Carter wrote: > Hi Sean > > On 2023/06/21 14:25, Sean Whitton wrote: >> The votes have concluded. The TC resolves to recommend that the Debian >> Project Leader appoint Stefano Rivera and Timo Röhling >> to the Debian Technical Committee. > > How about this? Thanks -- LGTM! -- Sean Whitton signature.asc Description: PGP signature
Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling
Hello, On Wed 14 Jun 2023 at 10:04AM +01, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Timo Röhling be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Timo Röhling > F: Further discussion > ===END I vote R > F -- Sean Whitton signature.asc Description: PGP signature
Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera
Hello, On Wed 14 Jun 2023 at 10:03AM +01, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Stefano Rivera be > appointed by the Debian Project Leader to the Technical Committee. > > R: Recommend to appoint Stefano Rivera > F: Further discussion > ===END I vote R > F -- Sean Whitton signature.asc Description: PGP signature
Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling
Package: tech-ctte X-debbugs-cc: roehl...@debian.org, lea...@debian.org I call for votes on the following ballot to fill a vacant seat on the Debian Technical Committee. The voting period starts immediately and lasts for up to one week, or until the outcome is no longer in doubt. ===BEGIN The Technical Committee recommends that Timo Röhling be appointed by the Debian Project Leader to the Technical Committee. R: Recommend to appoint Timo Röhling F: Further discussion ===END -- Sean Whitton signature.asc Description: PGP signature
Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera
Package: tech-ctte X-debbugs-cc: stefa...@debian.org, lea...@debian.org I call for votes on the following ballot to fill a vacant seat on the Debian Technical Committee. The voting period starts immediately and lasts for up to one week, or until the outcome is no longer in doubt. ===BEGIN The Technical Committee recommends that Stefano Rivera be appointed by the Debian Project Leader to the Technical Committee. R: Recommend to appoint Stefano Rivera F: Further discussion ===END -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 13th June, 6pm UTC
Dear committee members, Our next meeting is scheduled for Tuesday at 6pm UTC. Here is our agenda: - Jitsi: recruitment - Review of previous meeting AIs - Bug#1035904: dpkg currently warning about merged-usr systems - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-05-09-18.07.html -- Sean Whitton signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hello Emilio, On Thu 11 May 2023 at 12:30PM +02, Emilio Pozuelo Monfort wrote: > I think you're conflating two independent things. > > If you override the dpkg maintainer to remove that warning that occurs on > derivatives, then anyone could NMU dpkg and the maintainer wouldn't introduce > it back, effectively removing the warning from "dpkg upstream". > > OTOH if the dpkg maintainer switches to non-native packages, anyone could NMU > it adding the change as a patch, however the maintainer will just NACK the NMU > before or after it happens. > > So I don't see a problem with dpkg being native, just like e.g. apt is, and > that won't magically solve the issue at hand. I don't think the TC has or should have any authority over dpkg upstream, but with dpkg being a native package, any implementation of our decision for the Debian archive is also implemented for dpkg upstream. And it might be that the dpkg developers would be against the TC override solely or mostly because of this fact. So possibly changing that would resolve things peacefully. I don't see how this conflates things, but would be grateful for more explanation if you still think I'm doing so. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hello, On Thu 18 May 2023 at 07:55PM +02, Ansgar wrote: > Why not? We will not move that fast. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hello, On Thu 18 May 2023 at 07:21PM +02, Ansgar wrote: > The full freeze is approaching and there has been no progress on this > issue. Does the ctte think a decision before the release is still > possible? Not speaking for the whole ctte, but I don't think that is possible. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hello, On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > Cool, then let's ask tech-ctte. > > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. > > Thanks, > Ansgar > > [1]: https://bugs.debian.org/994388#397 This would require a new, maintainer-overruling vote. Our existing decisions do not apply, so far as I can tell. I have written a separate message to the bug and to debian-dpkg with a proposal to avoid having to have such a vote. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hello, On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive are copied unmodified into derivatives. The heart of the issue is how dpkg is a native package. What we're talking about is not the Debian system, but the Debian archive as it exists independently of the Debian system. dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly being used to distribute upstream dpkg. This is not in itself a problem -- we distribute a lot of stuff in source packages that does not form part of the Debian system. But in this case, this distribution that's occurring might conflict with how Debian is seeking to provide a product not just to end users, but also to those building derivatives. One simple solution is for dpkg to become a non-native package, carrying Debian-specific patches to do things like remove the warning code. Guillem & the other dpkg maintainers: would that change be something you are willing to consider? It might forestall this and similar issues from becoming contentious. Having dpkg as a non-native package would reflect the reality, that we can celebrate, that dpkg has an upstream existence independent of Debian. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium
Hello, On Tue 09 May 2023 at 01:26PM -07, Sean Whitton wrote: > === BEGIN > > OPTION A: > > Under Constitution 6.1.5, the Technical Committee recommends that the > maintainers of individual packages should not proactively move files > from the root filesystem to corresponding locations under /usr in the > data.tar.* of packages. So, /foo/bar should not move to /usr/foo/bar. > > Files that are in /usr in the Debian 12 release should remain in /usr, > while files that are in /bin, /lib* or /sbin in the Debian 12 release > should remain in those directories. If any files are moved from /bin, > /lib* or /sbin into /usr after the Debian 12 release, they should be > moved back to their Debian 12 locations. > > This moratorium lasts until we vote to repeal it. We expect to do that > during the trixie development cycle, and sooner rather than later. > We will continue to facilitate efforts to resolve the remaining issues > that stand in the way of safely repealing the moratorium. > > OPTION B: > > As option A, except that only maintainers of essential and transitively > essential packages should refrain from proactively moving files from the > root filesystem to corresponding locations under /usr in the data.tar.* > of packages. > > OPTION N: > > None of the above. > > === END I vote A > B > N -- Sean Whitton signature.asc Description: PGP signature
Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium
Package: tech-ctte I call for votes on the following resolution. Voting lasts for one week or until the outcome is no longer in doubt. Let me take this opportunity to thank Helmut for all his recent work on this topic. === BEGIN OPTION A: Under Constitution 6.1.5, the Technical Committee recommends that the maintainers of individual packages should not proactively move files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages. So, /foo/bar should not move to /usr/foo/bar. Files that are in /usr in the Debian 12 release should remain in /usr, while files that are in /bin, /lib* or /sbin in the Debian 12 release should remain in those directories. If any files are moved from /bin, /lib* or /sbin into /usr after the Debian 12 release, they should be moved back to their Debian 12 locations. This moratorium lasts until we vote to repeal it. We expect to do that during the trixie development cycle, and sooner rather than later. We will continue to facilitate efforts to resolve the remaining issues that stand in the way of safely repealing the moratorium. OPTION B: As option A, except that only maintainers of essential and transitively essential packages should refrain from proactively moving files from the root filesystem to corresponding locations under /usr in the data.tar.* of packages. OPTION N: None of the above. === END -- Sean Whitton signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Sun 07 May 2023 at 12:03PM +01, Luca Boccassi wrote: > Sure, this is in the context of the ongoing discussion in the TC about > revising their side of the advice. I think it's highly unlikely that we revise it rather than just reissue it, at the present time, because too many details are unsettled. > Also, we shouldn't lose sight of the reason why this was issued in the > first place: it is designed to stop a problem from happening, and that > problem can only happen when both conditions are true. I can't read > minds obviously, but I imagine that's the reason the RT advice was > worded as it was. It's designed to stop as-yet-unknown problems happening, too. -- Sean Whitton signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
Hello, On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote: > On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote: >> >> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to other >> > packages at the same time is maintained from bookworm till trixie, and >> > will lifted after trixie ships, and applies implicitly to all the >> > ~2000 binary pkgs that are affected by the above >> >> While the CTTE placed the moratorium until the release of bookworm, the >> release team extended it beyond, see >> https://lists.debian.org/e1ocdqk-0005ge...@respighi.debian.org. So you >> need explicit agreement from the release team on your plan. Failing >> that, any package that has been forcefully moved is immediately >> rc-buggy due to failing a release team requirement. > > Of course the release team needs to be on board, no questions about > that. But given the idea is to maintain their decision exactly as it > stands I wouldn't imagine it would be an issue? Once again, the > moratorium is explicitly about moving between locations _and_ > packages, in combination, not either/or. From that same email you > linked: > > "Files moving their canonical location between / and /usr (details in > [1]) *and* from one binary package to another binary package within > one release cycle remain an RC issue unless dpkg supports it." > > I'm proposing to keep this in place as a general rule, with the new > escape hatch that you devised as the only addition. Actually, the morotorium is not explicitly only about moving between both locations and packages. Firstly, the TC's morotorium does not have the qualification, restricting *any* movements in data.tar.*: The Technical Committee recommends that during the Debian 12 development cycle, the maintainers of individual packages should not proactively move files from the root filesystem to the corresponding locations in /usr in the data.tar.* of packages. Files that were in /usr in the Debian 11 release should remain in /usr, while files that were in /bin, /lib* or /sbin in the Debian 11 release should remain in those directories. If files were moved from /bin, /lib* or /sbin into /usr since the Debian 11 release, they should be moved back to their Debian 11 locations. Then secondly, the RT's message is ambiguous, because it says both that they want the /TC's/ morotorium to remain in place, and also that files moving between both locations and packages is an RC issue. Until the RT's position is clarified, I think we should treat the broader prohibition as what they require. The TC are going to discuss this issue at our meeting on Tuesday, and one possible outcome is that we reissue our version of the broader prohibition. Stepping back: I am far from being an expert on the details of merged-/usr. But one thing I've noticed is that among the people who have spent the most time looking into it, the majority think that simple fixes are not going to be sufficient. Only a few people who have spent a lot of time on it still think that the fixes that are required are relatively simple ones. If the former group are wrong then the transition takes longer than it needs to, but we don't lose any confidence in the state of our users' installations. If the latter group are wrong then we'll probably end up with a longer transition anyway, and a worse situation for both our maintainers and our users. And it's within one of the areas of Debian that we're most proud of -- completely smooth upgrades between stable releases. So, I think we should assume the people who are more worried are right, for the time being. We lose little in doing so. -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 9th May, 6pm UTC
Dear committee members, Our next meeting is scheduled for Tuesday at 6pm UTC. Apologies have been received from Matthew Vernon. Many thanks to Matthew V. for stepping in to chair our most recent meeting. Here is our agenda: - Jitsi: recruitment - Moratorium on moving files into /usr With an aim of keeping the focus on what the TC might do in an official capacity, the question before us is whether we need to officially extend our morotorium into trixie. Note that the RT's morotorium already extends, which takes away some urgency. My understanding of the -devel thread as of today is that + Helmut is actively leading the planning and design work, + the goal of setting something up such that the morotorium can be lifted is still on the table, but + we don't yet know that it can be done. Discussion continues. So, actually, I don't think we need to discuss this topic this month. Please correct me if I'm wrong. - Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-04-25-17.58.html -- Sean Whitton
Re: This month's meeting
Hello, On Wed 05 Apr 2023 at 04:26PM -07, Sean Whitton wrote: > Dear committee members, > > We are scheduled to have our meeting on Tuesday, but I will be > out-of-town. While it would be possible for me to join IRC, joining the > Jitsi video call to discuss recruitment would be quite difficult. Thank you all again for filling in the poll. We can all do Tuesday 25th, so let's meet at 6pm UTC on that day. I don't think it's a problem having our meeting close to each other given that we're mostly/wholly trying to resolve recruitment. -- Sean Whitton signature.asc Description: PGP signature
Re: This month's meeting
Hello, On Wed 05 Apr 2023 at 04:26PM -07, Sean Whitton wrote: > Dear committee members, > > We are scheduled to have our meeting on Tuesday, but I will be > out-of-town. While it would be possible for me to join IRC, joining the > Jitsi video call to discuss recruitment would be quite difficult. > > Could you fill in this poll regarding your availability on other > Tuesdays at the same time? And also regarding your availability on > Tuesday, because it might be that it's difficult for not just me. > > https://dud-poll.inf.tu-dresden.de/TQ6tqaZR8g/ Thanks to those who have filled this in already. It appears that this Tuesday isn't great for at least three of us, so let's say we'll do the 18th or the 25th, depending on final polling results. -- Sean Whitton signature.asc Description: PGP signature
This month's meeting
Dear committee members, We are scheduled to have our meeting on Tuesday, but I will be out-of-town. While it would be possible for me to join IRC, joining the Jitsi video call to discuss recruitment would be quite difficult. Could you fill in this poll regarding your availability on other Tuesdays at the same time? And also regarding your availability on Tuesday, because it might be that it's difficult for not just me. https://dud-poll.inf.tu-dresden.de/TQ6tqaZR8g/ Thanks. -- Sean Whitton
Re: Next meeting -- 14th March, 6pm UTC
Hello, On Mon 13 Mar 2023 at 02:35PM -07, Sean Whitton wrote: > Dear committee members, > > Our monthly meeting is scheduled for Tuesday at 6pm UTC. I'm sorry that I didn't appear today. I arrived at the office to join the meeting and found that my laptop charger had at some point stopped supplying it any power, and so the laptop was dead. I couldn't get connected to IRC for more than hour while the laptop resurrected itself, and by then it was too late. If there were thoughts shared on Jitsi about recruitment while you were waiting for people to join, could those perhaps be summarised to debian-ctte-private? Thank you. -- Sean Whitton
Next meeting -- 14th March, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Here is our Agenda: - Jitsi: recruitment - Review of previous meeting AIs Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-01-10-18.03.html -- Sean Whitton
Next meeting -- 14th February, 6pm UTC
Dear committee members, Niko and Gunnar, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Here is our Agenda: - Jitsi: hello to Matthew, farewell to Niko and Gunnar - Jitsi: recruitment - Review of previous meeting AIs Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-01-10-18.03.html -- Sean Whitton
Bug#1028357: Resignation & call for votes to elect the Chair
Package: tech-ctte Dear committee members, As the membership of the committee has changed, in accordance with convention I hereby resign as Chair, effective one week from now, and call for votes to elect the Chair of the Technical Committee. Per the Debian Constitution, the vote runs until all members have voted, or until my resignation takes effect. I would like to continue in the role, if the committee agrees. The ballot: ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Simon McVittie E: Matthew Vernon F: Sean Whitton ===END -- Sean Whitton signature.asc Description: PGP signature
Re: Next meeting -- 10th January, 6pm UTC
On Mon, Jan 09, 2023 at 05:34:07PM +, Matthew Garrett wrote: > > My apologies - I'm available tomorrow. No problem. Is the meeting time generally okay with you, or do we need to do a poll about that? Given short notice let's stick to no Jitsi until February. -- Sean Whitton
Re: Next meeting -- 10th January, 6pm UTC
Hello, On Fri, Jan 06, 2023 at 11:55:38AM -0700, Sean Whitton wrote: > > Our monthly meeting is scheduled for Tuesday at 6pm UTC. > > The DPL has not yet officially responded to our nomination of Matthew. > Our meeting are public though -- Matthew, can you plan to join us, > please, if you are available at that time? > > We said we would have a Jitsi session with old and new committee > members, to say farewell and hello. But even if the DPL responds to the > nomination before Tuesday, I don't think we can make a plan to have that > Jitsi session. So that'll have to wait until February. Although the DPL has now appointed Matthew (thanks Jonathan), we haven't heard from Matthew about his availability, so I'd like to stick to no Jitsi tomorrow, and a Jitsi including gwolf and ntyni in February. I will start the vote for the chair later today. -- Sean Whitton
Next meeting -- 10th January, 6pm UTC
Dear committee members, and Matthew, Our monthly meeting is scheduled for Tuesday at 6pm UTC. The DPL has not yet officially responded to our nomination of Matthew. Our meeting are public though -- Matthew, can you plan to join us, please, if you are available at that time? We said we would have a Jitsi session with old and new committee members, to say farewell and hello. But even if the DPL responds to the nomination before Tuesday, I don't think we can make a plan to have that Jitsi session. So that'll have to wait until February. Here is our Agenda: - Review of previous meeting AIs - Bug#1026104: longstanding problem with dependencies of python3-numpy in testing Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-11-08-17.58.html -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
Hello, We had a plan to have a meeting on Tuesday if anything came up. Reviewing #945824, I believe that even if we were eventually to overrule the Python maintainers on this, (i) the impact to users in the meantime is very low, and (ii) we are about to freeze, so it's unlikely we'd make any decision applying to bookworm. So I think we should leave this for the January meeting. -- Sean Whitton signature.asc Description: PGP signature
Re: December meeting
Hello, Our only agenda item is following up on Christoph's action item. So how about this: - if a bug is filed in the meantime, we'll meet at 6:30pm on the 20th - if nothing comes up, we'll not meet until January, at which point we can have a Jitsi session including Gunnar and Niko to say goodbye and thanks, and to welcome Matthew, should the DPL agree with our vote. -- Sean Whitton signature.asc Description: PGP signature
December meeting
Hello, We are scheduled to meet next Tuesday, but I'm not available. We could either have someone else chair, or push it forward one week -- there's nothing urgent. Is anyone not available at 6pm UTC on the 20th? -- Sean Whitton signature.asc Description: PGP signature
Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett
Hello, On Fri 25 Nov 2022 at 03:39PM -07, Sean Whitton wrote: > ===BEGIN > The Technical Committee recommends that Matthew Garrett be > appointed by the Debian Project Leader to the Technical Committee. > > H: Recommend to Appoint Matthew Garrett > F: Further Discussion > ===END I vote: H > F (sorry about the strange lettering) -- Sean Whitton signature.asc Description: PGP signature
Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett
Package: tech-ctte X-debbugs-cc: mj...@debian.org, lea...@debian.org I call for votes on the following ballot to fill a vacant seat on the Debian Technical Committee. The voting period starts immediately and lasts for up to one week, or until the outcome is no longer in doubt. ===BEGIN The Technical Committee recommends that Matthew Garrett be appointed by the Debian Project Leader to the Technical Committee. H: Recommend to Appoint Matthew Garrett F: Further Discussion ===END -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 8th November, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Agenda: - Jitsi: recruitment - Review of previous meeting AIs Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-10-11-17.58.html -- Sean Whitton
Missed chair election
Hello, I just realised that according to convention I was meant to start a vote on the TC chair when Elana's resignation took effect. Looks like no-one noticed this until now. A vote would definitely have made sense in August, but now it's not so long before the usual vote in January. We could do a vote now, or we could leave it until January, unless there is a controversial bug filed between now and then. In that case we could easily do a chair vote before voting on the bug. The thought would be that the casting vote could become relevant in that situation. -- Sean Whitton
Next meeting -- 11th October, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Agenda: - Jitsi: two interpersonal issues - see Helmut's mail to private alias on the 18th of August - Jitsi: recruitment - Review of previous meeting AIs - Bug #1020923: tech-ctte: please clarify if atomic updates are required Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-09-13-18.09.html -- Sean Whitton signature.asc Description: PGP signature
Bug#1020923: tech-ctte: please clarify if atomic updates are required
Hello Sam, Speaking only for myself. On Thu 29 Sep 2022 at 03:31PM -06, Sam Hartman wrote: > Is the maintainer expected to find a forum and try to build consensus on > this issue? I don't think they are. > In various ways the submitter has argued that those proposing to > continue the transition have an obligation to respond to his concerns. > To what extent is that true under our process? It seems to me that if the submitter was writing as a package maintainer, or otherwise raising the issues as part of work he was doing on Debian, there would be some sort of obligation, but I don't believe either of those are true. > From a process standpoint, to what extent should this bug block the > transition if the maintainer doesn't want it to. Not at all, unless the RT or TC think otherwise. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020923: tech-ctte: please clarify if atomic updates are required
Hello, On Thu 29 Sep 2022 at 10:16AM -06, Sam Hartman wrote: > I think it would help the current situation if the TC would clarify the > state of the bugs if they choose not to take up this issue at this time: > > * Who is expected to drive further discussion: the maintainer or the bug > submitter > > * What is the state until that further discussion happens? These are very broad questions ... > My understanding of our processes is that: > > 1) If the bug submitter disagrees with the maintainer they need to > drive discussion. If the TC isn't ready they could drive that > discussion debian-devel or some other forum. > > 2) Unless the TC or RT explicitly acts, the maintainer's severity > (wishlist in this case) stands. ... but at least what you've said here seems correct to me. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020923: tech-ctte: please clarify if atomic updates are required
Hello, On Wed 28 Sep 2022 at 08:00PM +02, Ansgar wrote: > Package: tech-ctte > X-Debbugs-Cc: Zack Weinberg > Control: block 1020920 by -1 > > Hi, > > please clarify if atomic updates are mandatory for the Debian system. > Or other measures to ensure that system crashes at *any* time do not > render a system unbootable. > > See also: https://bugs.debian.org/1020920 (1) Do you mean any package update? Certain packages? dist-upgrade? (2) The TC is a decision-making body of last resort. The bug you mention was filed today. Might this be premature? -- Sean Whitton signature.asc Description: PGP signature
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hello, On Tue 27 Sep 2022 at 09:23AM +01, Matthew Vernon wrote: > As Sean says, though, questions of what are and aren't RC bugs are typically > the domain of the release team, not the TC. I didn't intend to say that -- I think that Policy+TC decides bug severities, in general. But the RT decide which ones actually count for an impeding release. (One might then argue that that means that the RT do in fact determine which are the RC bugs, but I think that unhelpfully simplifies how Debian decision-making works.) > I don't think you're asking us to revisit our decision on the approach > taken to merged-/usr; we don't generally return to a decision once > made (and a GR would normally be the approach to overturning a TC > decision). Personally, I think there are circumstances where we might > (e.g. a convincing argument that we missed something critical in our > decision-making, or that circumstances have changed sufficiently to > warrant another look), but I don't think we are in that situation here > at the moment. > > I think the best way to proceed would be to open a bug describing the problem > that Simon outlines with RC severity; the relevant maintainers and release > team can then discuss how to resolve the issues and if they warrant delaying > the release or adjusting when we complete the transition. Obviously those > people might want to ask the TC for advice, but I think that would be up to > them at least in the first instance. Thanks for this helpful perspective. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hello, On Tue 27 Sep 2022 at 10:07AM -04, Zack Weinberg wrote: > I may have misunderstood the TC recommendation here. I was under the > impression that the “no migration of file paths” rule was *only* in > effect until the release of bookworm, and that it was motivated by the > need to continue supporting non-merged systems up till that point, not > by the dpkg bugs. No, it remains in place beyond that, and a decision on lifting it has not been made by anyone. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hello, On Mon 26 Sep 2022 at 04:48PM -04, Zack Weinberg wrote: > I'm surprised to hear you say that, given that, in the past, the TC > has required bugs of various severities to be filed, and has required > maintainers not to alter bug severities. Almost all of what I'm > asking for would follow "by operation of Policy", as it were, from the > requested s:critical bugs on usrmerge and usr-is-merged; I only > spelled them out for explicitness's sake. And I didn't file the bugs > myself because they would certainly be rejected by the maintainers, > and then I'd have to escalate _that_ to you, so I'm trying to save time > by skipping that step. This isn't about Policy, though, it's about timetabling, as you say downthread, and that's basically why we think the RT is the most relevant decision-making body -- they're the team with the timetables. > In my opinion, a "suitable transition mechanism" _must_ include a fix > for the dpkg bugs, Many TC and RT members basically agree with you, including myself, and lament the lack of integration of merged-/usr with dpkg. That's behind the idea in the RT's d-d-a e-mail where they said (paraphrasing) "the transition is not complete until the work on dpkg is complete." But they decided that less was to be done for bookworm: the transition is to be left incomplete in just this way. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hello, On Mon 26 Sep 2022 at 03:28PM -04, Zack Weinberg wrote: > Package: tech-ctte > Severity: normal > X-Debbugs-Cc: z...@owlfolio.org > > I formally request that the Technical Committee call a halt to the > merged-/usr transition until such time as all of the bugs in dpkg that > can, on a merged-/usr system, cause damage to the contents of the > filesystem (e.g. packaged files being silently deleted on upgrade) > have been fixed to the satisfaction of the dpkg maintainers. I believe that this request is invalid, for two reasons: - the specific things you ask for are all or mostly things that we think are currently up to the Release Team, and the TC cannot override delegates - you might be lacking the full context of TC-involving discussions over the past few months, but so far as I can see, you are asking for us to undo a decision that we only just made, which doesn't make sense. Therefore, we will likely just close this bug, I'm afraid. -- Sean Whitton signature.asc Description: PGP signature
Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT
Hello, On Sun 18 Sep 2022 at 03:11PM +02, Helmut Grohne wrote: > Hi, > > On Sat, Sep 10, 2022 at 11:57:48PM +0200, Johannes Schauer Marin Rodrigues > wrote: >> From my side, I'd be fine with the TC pausing any action on this issue and >> waiting for our mail to d-devel first. This is assuming that if there is no >> opposition to the DPKG_ROOT idea, that Steve then also has no objection >> against >> merging our patch. >> >> Helmut, what do you think? > > I think that the CTTE is so slow that there is no need to pause in any > way. The d-devel thread seems rather boring, so we may as well move > ahead. > > Let me restate that I see this as a procedural issue. I believe that a > maintainer has an obligation to communicate in a reasonable way. For > instance, we file RC bugs when the maintainer address bounces. I argue > that maintainer communication isn't working for pam. Even if more > arguments against DPKG_ROOT pop up now, I kinda find it late on > procedural grounds. > > So no, let's not pause this. Nothing has changed really. While Steve did > reply, that doesn't happen to please Sam. If the three weeks expired > today, I would have referred it to the CTTE as well. You'll have seen it, but for the benefit of others, at our meeting this week we decided that we will review the patch and determine whether we have a consensus about applying it during our next monthly meeting. -- Sean Whitton signature.asc Description: PGP signature
Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
Hello, On Sun 18 Sep 2022 at 03:04AM +01, Luca Boccassi wrote: > I'd like to request the CTTE to intervene and put an end to this > behaviour, so that the agreed plan based on your votes can be brought > to conclusion with plenty of time to spare before Bookworm's freeze. Intervening in this sort of way is not part of the TC's remit. In any case, it seems that other, more relevant core teams have taken action. -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 13th September, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Agenda: - Jitsi: two interpersonal issues - see Helmut's mail to private alias on the 18th - Review of previous meeting AIs - Following up on util-linux decision - Bug#1019409: decide whether pam should support DPKG_ROOT - Any other business I'm delaying TC recruitment to October's meeting. Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-08-09-17.59.html People with AIs: Emperor, gwolf, Myon, me -- Sean Whitton
Re: Bug#993161: pam: some remaining changes for DPKG_ROOT
Hello, On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote: > For the record I do not consider this an override requiring a > supermajority and would abide by a majority TC decision. Thank you for your input. The TC can just issue advice after reviewing the proposed changes, in this case. An alternative would be to word the resolution such that it counts as advice if we have a simple majority and an override if we have a supermajority. I'd prefer the former, but it would be good to hear from Helmut about it. -- Sean Whitton
Next meeting -- 9th August, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Agenda: * Review of previous meeting AIs * Suggestion from BoF about announcing all decisions to d-d, not d-d-a * Starting recruitment work for Elana, Gunnar and Niko's seats - We shouldn't feel compelled to fill all three seats if that would mean appointing someone we aren't totally sure about. Perhaps we should aim for two good candidates, three if we can? - We just need to discuss the mechanics at this meeting. Next time we'll probably want this topic to be done over private Jitsi. * Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-07-12-17.58.html -- Sean Whitton
Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
Hello, On Tue 26 Jul 2022 at 03:31pm +02, Johannes Schauer Marin Rodrigues wrote: > Hi tech-ctte > > Quoting Luca Boccassi (2022-07-25 15:22:10) >> There's also a pending MR for reportbug that would be good to have, but >> doesn't need to block other progress: >> >> https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/77 > > I just remembered a pending MR that I'd say is a little more important than > "good to have": > > https://salsa.debian.org/debian/debianutils/-/merge_requests/21 > > Without this one-line change, /etc/shells on merged-/usr systems will have > some > shells listed twice and some shells (like /usr/bin/bash) missing. The reason > is, that dpkg-realpath doesn't support merged-/usr and thus a workaround is > needed. > > Given the recent CTTE ruling over debianutils (#994275) and since the MR from > five months ago has no maintainer activity, I wanted to ask you for informal > advice on this. Should I just file a bug and NMU with maximum delay? Or is > application of this fix deemed more important? Informally, I suggest an NMU with a delay of five days, based on the idea that the bug is of at least Severity: important. -- Sean Whitton
Re: tech-ctte: more on merged-/usr
Hello, On Fri 22 Jul 2022 at 09:31am -06, Sam Hartman wrote: > I respectfully disagree with Helmut who is pushing for an acceptable > technical solution to be on the table before considering acting. > As others have pointed out, it's actually hard to come up with the > energy to improve and refine technical solutions. > Doing that in a climate where you face a political battle at the end is > not a realistic ask in our community at this time. > > I think that the TC is one of the few bodies who could take leadership > on this issue. > > You cannot design (or write) the patch. > You can do various things though. > You could confirm your willingness to solve this issue even over a dpkg > override. > (The TC's failure to act on the warning about unsupported configurations > leaves this in significant doubt and certainly left a bad taste in my > mouth at least). > > You could review the existing patch and explain why it's not good > enough, or since reviews already exist, you could decide as a body which > parts of those reviews need to be addressed. > > You could describe what review criteria or procedure you would use to > move forward. > > While I appreciate that you are currently expressing your personal > views, I think the TC needs to express views as a body to move forward. We have a consensus within the TC that, at the present time, we have fulfilled our role. This consensus is the result of discussing what other things we might do, at length, both within the committee and with the release team. We are continually monitoring the situation, and will consider whether there is more for us to do each time things change significantly. -- Sean Whitton
Re: today's TC talk
Hello, Great, thank you. -- Sean Whitton
today's TC talk
Hello, Just wanted to thank everyone who was involved in this. To committee members: My laptop died, seemingly permanently, three minutes in. I'll watch the recording when it's available but as that won't be for some weeks, could someone summarise anything discussed that it would be good for me to know before then, please? -- Sean Whitton
Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
Hello, On Tue 19 Jul 2022 at 08:01am +01, Simon McVittie wrote: > It's unfortunate that when a package like usrmerge has more than one > version waiting in NEW, the two operations available to the ftp team seem > to be "reject all versions of usrmerge" and "accept all versions of > usrmerge": if the result of NEW review is that the new binary package > needs to be renamed, as it was in this case, then the ideal result would > have been to reject usrmerge/28 from the queue and immediately accept > usrmerge/29. Just fyi, that's not right, we can reject individual uploads, but accept means accepting all of them because of how overrides work. -- Sean Whitton
Re: Slides for the talk
Hello, On Wed 13 Jul 2022 at 03:20PM -07, Sean Whitton wrote: > Here: https://people.debian.org/~spwhitton/talks/2022/tech-ctte.pdf Updated, please re-fetch. -- Sean Whitton
Re: Resignation: Elana Hashman (ehashman)
Hello, On Thu 14 Jul 2022 at 10:43AM -07, Elana Hashman wrote: > I've made the very difficult decision to resign from the Debian > Technical Committee, effective August 1, 2022. This should provide some > time to complete any final action items and transition my duties. > > It has been a great honour to serve the project in this way, and I hope > that perhaps in the future I can return to finish off my term. I've had > serious health challenges over the past year and have not been able to > give the TC the time or energy the position deserves, so I feel this is > for the best for now. Many thanks for your work over the past two years. I find this particularly sad because you and I were appointed at the same time. The committee has benefitted from having you on it a great deal. Looking forward to future opportunities to work together on free software. -- Sean Whitton
Slides for the talk
Here: https://people.debian.org/~spwhitton/talks/2022/tech-ctte.pdf I've not committed the PDF to git in case we need to tweak anything between now and the talk. Gunnar knows how to recompile, or I can. We'll commit the PDF to git afterwards. -- Sean Whitton
Re: Please help reschedule the Technical Committee talk
Hello, On Tue 12 Jul 2022 at 01:25PM -05, Gunnar Wolf wrote: > Hello, dear Content Team! > > We are in a tech-ctte meeting right now. We are scheduled to have our > BoF on July 18, 14:00. However, two of the tech-ctte members will be > participting remotely, from the East coast of the USA. That means the > talk is scheduled too early. West coast* Thanks Gunnar for sending this and hope it's possible to reschedule. -- Sean Whitton
Next meeting -- 12th July, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Agenda: * Review of previous meeting AIs - Only (1) and (2) from the minutes need checking up on. * DebConf22 presentation - updating the slides - appointing someone the primary presenter, as TC chair won't be there in person. * Any other business Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-06-14-18.01.html -- Sean Whitton
Bug#1007717: Ballot and call for votes
Hello, On Mon 20 Jun 2022 at 05:31PM -07, Sean Whitton wrote: > BEGIN BALLOT > > Using its powers under constitution 6.1.5, the Technical Committee > issues the following advice: > > 1. It is not a bug of any severity for a package with a non-native > version number to use a native source package format. > > 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise > complain, when a non-native version number is used w/ 3.0 (native). > > 3. We suggest that the wontfix tag on #737634 be reconsidered. > > 4a. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > > This is because there is currently no other source format which is > such that avoid both (i) uploading the whole source, including > upstream, for every upload; and (ii) having to maintain > debian/patches/ inside the package tree. > > 4c. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > However, we recommend discontinuing use of 1.0-with-diff in other > circumstances, to simplify the contents of the archive. > > This is because ... [second paragraph as in 4a]. > > 5. We decline to comment on the recent source package format MBF. > > Option A -- issue items 1-3, 4a and 5 > > Option C -- issue items 1-3, 4c and 5 > > Option X -- issue only items 1, 2, 3 and 5 > > Option N -- none of the above. > > END BALLOT I vote A > C > X > N -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Ballot and call for votes
Hello, I hereby call for votes on the following resolution: BEGIN BALLOT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4a. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 4c. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because ... [second paragraph as in 4a]. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1-3, 4a and 5 Option C -- issue items 1-3, 4c and 5 Option X -- issue only items 1, 2, 3 and 5 Option N -- none of the above. END BALLOT -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
Hello, On Fri 17 Jun 2022 at 02:45am +02, gregor herrmann wrote: > Well, yes, sure. > That would all be nice. > But issuing some advice about 1.0-with-or-without-dpatch or whatever > doesn't really change anything for them. Indeed, we have somewhat drifted off-topic :) > Oh, right, I totally agree that for all practical reasons the > practical source of most of the packages I upload are in a salsa > git repo. > > But that's completely irrelevant. > What's relevant for Debian are some *.orig.tar.gz *.debian.tar.xz > *.dsc an some web mirrors. I don't understand -- why would it be irrelevant? -- Sean Whitton
Bug#1007717: Updated draft resolution
Hello, On Fri 17 Jun 2022 at 01:03AM +02, gregor herrmann wrote: > And that's what we are talking about: Debian experts building > packages for Debian. At least that's what my priorities are. I think Ian might really mean "Debian source package experts". It ought to be our goal to make it so that you can be a Debian expert without being a Debian source package expert. It also seems worth mentioning that users wanting to apply patches to packages installed on their systems are also one of priorities. > And dgit also is just a nice workaround for the problem that the > canonical source of Debian packages is not Git repo; it pretends that > there is, and it stumbles across all kinds of corner cases caused by > how source packages look like nowadays. I would challenge this idea: at this point, the canonical source of very many Debian packages is indeed their git repos on salsa. Not all of them, but very many. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Updated draft resolution
Hello, On Thu 16 Jun 2022 at 08:47am +02, Helmut Grohne wrote: > > Indeed, and I do agree that 4c is such a clear statement. I would like > to see a stronger statement here, but Sam et al. tried to gain consensus > on that and there wasn't. So the CTTE advice probably shouldn't override > that non-consensus. That makes 4c a lot more of an attractive option to > me. Finally, the main conflicting parties in this issue (oversimplified) > were Lucas and Ian, so if 4c is strong enough for Lucas, that's good as > well. > > I hereby withdraw my intention to extend the ballot as sent by Sean on > June 7th. > > Thanks for bearing with me and bringing those arguments forward. Cool, thanks for reviewing and confirming that. -- Sean Whitton
Bug#1007717: Updated draft resolution
Hello, On Wed 15 Jun 2022 at 04:06PM +02, Lucas Nussbaum wrote: > > According to https://udd.debian.org/~lucas/format10.cgi (which is based > on what lintian knows about the archive), there are 114 packages using > 1.0 with quilt. However, 67 of those are maintained by the Debian X > team. If you plan to discontinue 1.0+patch-system in the context of > this bug, it would probably be a good idea to have a discussion with > them to better understand their use case. Thanks for this info. > I personally think that it would be enough for this bug to issue a clear > statement that we want to move away from 1.0 unless there's a good > reason, on a per-package basis, not to. That would create a mandate to > work on surveying the remaining packages and identifying the remaining > use cases. That would also allow motivated volunteers to work on > migrating the remaining packages when there's no reason to stay with > 1.0, using the NMU procedure if needed. I agree that this would be a good outcome, as expressed by your option 4c. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Draft resolution for "Native source package format with non-native version"
he development of such a source format. To be honest I don't think it's really necessary as everyone agrees it would be better to have it, but if you think it should be said explicitly then let's do that. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Wed 08 Jun 2022 at 12:06pm +02, Julian Andres Klode wrote: > On Tue, Jun 07, 2022 at 08:19:29PM +0200, Helmut Grohne wrote: >> Please keep in mind that this is about trade-offs. It is a question of >> how we value "package ownership". If we favour the strong ownership >> approach that Debian used for a long time, then yes accommodating the >> needs of maintainers is paramount. If we want to lessen the concept of >> ownership, embrace drive-by contributions and decentralize maintenance, >> then we need a stronger focus on uniformity. I suppose that my own >> opinion on this matter is fairly obvious at this point. > > This is also a significant issue for downstreams. With my Ubuntu hat > on, if I have to touch packages downstream, I loathe it everytime I > get a non-descript blob of all the changes. This is not inherent to all of the workflows we are discussing here, just one of them. Indeed, this is one of the primary motivations for one of the others. -- Sean Whitton
Bug#1007717: Updated draft resolution
Hello, On Tue 10 May 2022 at 05:29pm -07, Sean Whitton wrote: > At today's ctte meeting we considered whether we can start a vote on > this, but two committee members were missing, and someone else at the > meeting reported that they hadn't yet been able to spend enough time > thinking through the issue to be ready to vote. > > We came up with the following plan. Below I've drafted a ballot. Once > each of those three individuals has let me know that they've had a > chance to catch up, I'll start a vote. The hope is that this can happen > well in advance of our next meeting. So, ctte members, if I don't > already know that you're caught up, please write to me once you are. Unfortunately, people haven't yet indicated they're caught up. Here's an updated ballot in light of our upcoming meeting. I've left space to add a 4b, if, when our current discussion is concluded, someone would like that in addition to 4c. ~ DRAFT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4a. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. This is because there is currently no other source format which is such that avoid both (i) uploading the whole source, including upstream, for every upload; and (ii) having to maintain debian/patches/ inside the package tree. 4c. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. However, we recommend discontinuing use of 1.0-with-diff in other circumstances, to simplify the contents of the archive. This is because ... [second paragraph as in 4a]. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1-3, 4a and 5 Option C -- issue items 1-3, 4c and 5 Option X -- issue only items 1, 2, 3 and 5 Option N -- none of the above. END DRAFT -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 11:26am +01, Ian Jackson wrote: > In this case I would like to suggest that progress would be better > served by trying to unblock a better source format that (i) has some > kind of delta representation (ii) does not put a > needing-to-be-maintained copy of the delta metadata inside the working > tree. > > There are several proposals for how to do that which are obviously > possible to implement. If the TC wants to unblock that, you could > look at them and pick one. > > (And, I quextion whether .dsc format is the right place for Debian to > pursue uniformity. .dsc is a legacy format we are maintaining because > our git transition is stalled.) I think that this would be out-of-scope for this bug as presented to us: we'd need someone to present those options for us to choose between. Let's stick with the current resolution text for a bug that's probably been open too long already. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 08:19pm +02, Helmut Grohne wrote: > Please keep in mind that this is about trade-offs. It is a question of > how we value "package ownership". If we favour the strong ownership > approach that Debian used for a long time, then yes accommodating the > needs of maintainers is paramount. If we want to lessen the concept of > ownership, embrace drive-by contributions and decentralize maintenance, > then we need a stronger focus on uniformity. I suppose that my own > opinion on this matter is fairly obvious at this point. I disagree with you that this is primarily about package ownership, and I think that we agree on more than you realise we do :) The git-first people are not making a trade-off between the maintainer's convenience and the convenience of others who want to work with the package. The most important reason for wanting both (i) git-first workflows and (ii) uploads done with dgit, is to make it easier for people other than the maintainer to work with the package. So, your priorities are quite in agreement with those of Ian, Sam, Russ and I. In other words, I would like to make weaker package ownership more possible, in a project with Debian's history, by improving our tools for dealing with packages for which you're not primary maintainer. What we disagree about is the extent to which the current tooling amounts to a failed experiment, such that we should give up on it and fall back to 'apt-get source'. Many people strongly prefer 'dgit clone' to 'apt-get source' already, and the number of people switching to upload with 'dgit [--gbp] push-source' is steadily rising. Against this backdrop, some of us are interested in git-first workflows for reducing the distance between the output of 'debcheckout' and 'dgit clone'. It's completely reasonable that you're more sceptical about the prospects of solving the outstanding issues in this programme than others are, but surely we can agree that this is an ongoing piece of work rather than something we're sure we can reject? And if keeping an old source package format around is needed for that work to continue, then that's a compelling reason to keep it around. > How would you go about reducing them to a sane number? The goal is to attack this problem on two fronts: 1. reduce the need for uniformity by making it possible for people to get their cross-archive work done using 'dgit clone' 2. develop git-first workflows that solve all the existing usecases. > You can rephrase it as reducing complexity if that helps. It's not the > one additional source package format that is too much. It's that we > continue using all the failed experiments while adding new ones and when > some Lucas comes around and tries to clean up the mess he gets referred > to us. As I said, I don't think it's fair to characterise the git-first work as a failed experiment. It's ongoing work. And the source package format is just a way to keep it going, at the present moment. > I have anecdotal evidence that people find Debian's processes too > complex. Unless you closely work withing a particular packaging team > (with unified processes), onboarding people into Debian takes very long > compared to other projects. Right, hence why we want 'dgit clone' to be as useful as possible. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 09:31am +02, Lucas Nussbaum wrote: > A middle ground between (4) and (4b) could be to discourage the use of > 1.0-with-diff in circumstances where it is not justified. Something > like: > > 4c. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > However, we recommend discontinuing use of 1.0-with-diff in other > circumstances to gain more uniformity. > > That opens the path to an archive where the only remaining 1.0 packages > are the ones where there's a reason to use 1.0. (as opposed to > currently, where we have a mix of packages using 1.0 for a good reason, > and packages using 1.0 because nobody cared to update them to modern > practices). This would be a good ballot option to include, thank you. -- Sean Whitton
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, On Tue 07 Jun 2022 at 07:43am +02, Helmut Grohne wrote: > While I can agree with this item on a technical level, I think there is > more to it than that and I am wondering whether it sends the "right" > message. > > Sometimes, things we do are technically possible and fill a niche well. > Yet, we decide that it is no longer reasonable to continue supporting > them and remove their support despite the feature being useful to some. > Quite clearly, there is a trade-off involved here. Continuing to support > 1.0-with-diff comes with a cost that reduces uniformity inside the > archive. Evidently, this is what motivated Lucas to file the MBF > initially. My experience is that lack of uniformity is a significant > barrier to prospective contributors to Debian. I think this argument needs to be made more precise -- we should be clearer about why this particular un-uniformity is bad. I don't think the issue for new contributors is persuasive enough, as new contributors can mostly ignore source packages. It's not like, e.g., debhelper vs. cdbs. I haven't yet seen an argument that the lack of uniformity is doing anyone's work any harm comparable to the harm done to things like what Ian and Sam want to do. > Exploring different technical approaches does have value as well, but I > think we've had sufficient time to consider the various advantages and > disadvantages of various source packages formats. On a whole, it seems > to me that that the number of packages benefiting from 1.0-with-diff is > relatively small. I agree, it's not about the benefits of the source format, we do indeed understand all the trade-offs by now. It's that certain ideas and workflows *which are not really about source packages* are made inconvenient or impossible if we remove this option. In other words, it needs to be replaced before it can be deprecated. > What would you think about adding an alternative option 4? > > 4b. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package. > Given that the number of packages for which this is relevant is > fairly small, we recommend discontinuing use of 1.0-with-diff to > gain more uniformity. Thanks for coming up with the text. I'd say that as uniformity is not good in itself, it would be good to have more concrete reasons for wanting uniformity in this case documented in this bug (not necessarily in the resolution text) before we add it to the ballot. -- Sean Whitton
Next meeting -- 14th June, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday 14th at 6pm UTC. Agenda: * Review of previous meeting AIs * Bug#1007717 -- Native source package format with non-native version * Do we want to start systematically announcing decisions to d-d-a right after we make them? * DebConf22 presentation * Any other business People with AIs: Elana, Niko, Matthew, me Minutes of previous meeting: <http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-05-10-17.59.html> -- Sean Whitton
Bug#1007717: attempt to summarize current state of this bug
Hello, On Wed 11 May 2022 at 10:56AM +02, Lucas Nussbaum wrote: > I think that: > [...] > - git-using workflows are a best practice (based on their usage by the > vast majority of packages) > > But I challenge that there is a consensus that git-first workflows are a > best practice. I think that they are a practice that is worth exploring > and experimenting on, but not yet widely adopted nor understood. But I > would be happy to be proven wrong (especially of based on facts). I would say that we don't have a consensus on either. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Draft resolution for "Native source package format with non-native version"
Hello, At today's ctte meeting we considered whether we can start a vote on this, but two committee members were missing, and someone else at the meeting reported that they hadn't yet been able to spend enough time thinking through the issue to be ready to vote. We came up with the following plan. Below I've drafted a ballot. Once each of those three individuals has let me know that they've had a chance to catch up, I'll start a vote. The hope is that this can happen well in advance of our next meeting. So, ctte members, if I don't already know that you're caught up, please write to me once you are. ~ DRAFT Using its powers under constitution 6.1.5, the Technical Committee issues the following advice: 1. It is not a bug of any severity for a package with a non-native version number to use a native source package format. 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise complain, when a non-native version number is used w/ 3.0 (native). 3. We suggest that the wontfix tag on #737634 be reconsidered. 4. We believe that there are indeed circumstances in which 1.0-with-diff is the best choice for a particular source package, including, but not limited to, git-first packaging workflows. 5. We decline to comment on the recent source package format MBF. Option A -- issue items 1--5 Option B -- issue items 1, 2, 3 and 5, but not 4 Option N -- none of the above. END DRAFT -- Sean Whitton signature.asc Description: PGP signature
Next meeting -- 10th May, 6pm UTC
Dear committee members, Our monthly meeting is scheduled for Tuesday at 6pm UTC. Agenda: * Private Jitsi discussion to wrap up recent interpersonal issues * Review of previous meeting AIs * Bug#1007717 -- Native source package format with non-native version * DebConf22 presentation * Any other business People with AIs: gwolf, ehashman, spwhitton, Myon Minutes of previous meeting: <http://meetbot.debian.net/debian-ctte/2022/debian-ctte.2022-04-05-17.59.html> -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello, On Wed 20 Apr 2022 at 03:31PM +01, Matthew Vernon wrote: > ===Rationale > > There are two "rename" programs - the perl rename, and the util-linux > rename. Debian and its derivatives have shipped the perl rename as > /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped > the util-linux rename thus. The two implementations are incompatible. > Users might reasonably desire both implementations to be available on > the same system; they are designed to meet different needs. > > Backwards-compatibility (and the lack of a compelling argument that > rename from util-linux should replace perl rename) means that > /usr/bin/rename in Debian should remain the perl rename. > > Prior to bullseye, util-linux's rename was shipped as > /usr/bin/rename.ul; Debian's users who wish to use util-linux's rename > will expect it to be in this location. > > ===End Rationale > > ===Begin Resolution A > The Technical Committee overrides the util-linux maintainer, and > requires that util-linux's rename should be shipped as > /usr/bin/rename.ul in a binary package built from src:util-linux. The > package containing rename.ul must not conflict with the rename package > nor divert /usr/bin/rename. > ===End Resolution A > > ===Begin Resolution B > The Technical Committee overrides the util-linux maintainer, and > requires that util-linux's rename should be shipped in a binary package > built from src:util-linux. If this package Conflicts with the rename > package, then it must not contain any other binaries. > ===End Resolution B > > ===Begin Resolution N > None of the above > ===End Resolution N I vote A > B > N -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello, On Fri 15 Apr 2022 at 01:14PM -07, Russ Allbery wrote: > Sean Whitton writes: > >> In this case I believe you need to formally withdraw options A and >> then propose another ballot. > > Minor procedural point: the person proposing the options can also freely > modify them, so you didn't technically have to withdraw them and could > instead just alter the options to whatever new text you want. 6.3.2: > > Any member of the Technical Committee may propose additional ballot > options or modify or withdraw a ballot option they proposed. > > (The underlying assumption is that the TC are sophisticated voters who can > closely track the status of the ballot, so we can err on the side of > convenience to let proposers rewrite the options to whatever they want. > If that makes previously acceptable options unacceptable, other TC members > can always propose new options or reinstate versions of the previous > options.) I failed to read "or modify", thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello Matthew, On Thu 14 Apr 2022 at 04:47PM +01, Matthew Vernon wrote: > ===Begin Resolution > > The Technical Committee resolves that util-linux's rename should be > shipped in a binary package build from src:util-linux. If this package > Conflicts with the rename package, then it should not contain any other > binaries. > > The Technical Committee overrides the util-linux maintainer, and > requires that this binary should be shipped as /usr/bin/rename.ul > > ===End Resolution > > A: Approve resolution, including override of util-linux maintainer > B: Approve only first paragraph of resolution > N: None of the above I think that both of these involve overriding the maintainer, as the restriction to not include any other binaries if the package Conflicts: with bin:rename is also to override the maintainer? > Matthew > ps; my first TC resolution, please be gentle if I have the procedure wrong! Thank you for coming up with this text. Actually, the new procedure is new to all of us; this is our first use of it. In this case I believe you need to formally withdraw options A and then propose another ballot. -- Sean Whitton signature.asc Description: PGP signature
Bug#994388: Bug#1008489: proposed diff for dpkg 1.21.7+nmu1
Hello, On Sat 09 Apr 2022 at 11:50am +02, Ansgar wrote: > Hi, > > I've prepared a patch for the current issue. See the attached proposed > NMU diff. I've limited it to minimal changes. I don't understand. The warning is already no longer emitted on Debian? -- Sean Whitton
