Next meeting: Monday 23 September, 10:00 UTC
Dear TC members, Our next meeting will be on Monday 23rd September at 10:00 UTC. I believe everyone can make that time (if not, please let me know!) Agenda: - Review previous meeting's actions: - helmut start a new file under procedures/ in tech-ctte.git about designated discussion moderators - spwhitton to write to kernel team regarding waldi's takeover offer - spwhitton to start vote for new chair - tumbleweed to ask doko for more details on how he would implement waldi's takeover offer - Bug #1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely - Decide who will take over from spwhitton in running the recruitment/ctte-cronscript.sh script[0] - Recruitment - spwhitton's term ends 31 Dec, so we will have 1 vacancy come 1st Jan - AOB Minutes of previous meeting: https://meetbot.debian.net/debian-ctte/2024/debian-ctte.2024-08-16-08.00.html Regards, Matthew [0] https://lists.debian.org/debian-ctte/2024/08/msg00130.html
Bug#1078851: Resignation & call for votes to elect the Chair
Hi, On 17/08/2024 05:10, Sean Whitton wrote: Thank you for your work as chair, Sean! ===BEGIN BALLOT A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Stefano Rivera E: Timo Röhling F: Craig Small G: Matthew Vernon H: Sean Whitton ===END BALLOT I vote G = E > A = B = C = D = F > H Regards, Matthew OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077764: Call for votes: don't issue any ruling
Hi, On 06/08/2024 13:33, Sean Whitton wrote: = BEGIN BALLOT The Technical Committee declines to overrule the maintainer of base-files, or issue any advice on issues concerning /etc/os-release. We do not think there is a clear proposal on the table for us to assess, and we do not think it is appropriate to issue any general statements on the issues concerning /etc/os-release. A: Decline to overrule or issue advice N: None of the above END BALLOT = I vote A > N. A bit of me wants to say something more positive about the current unstable/testing lack-of-distinction, but perhaps you are right it is better to leave that for now. Regards, Matthew OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1077764: Ruling request on os-release specification implementation
On 06/08/2024 11:22, Luca Boccassi wrote: On Tue, 6 Aug 2024 at 11:10, Matthew Vernon wrote: Hi, On 06/08/2024 10:42, Luca Boccassi wrote: This is not a hard technical problem with no known solution that we are asking for design guidance on. This is a trivial technical problem with a hard social conflict at its core. What we are really blocked on is that the current owner of os-release refuses to let us fix it. This is an unfair and inaccurate summary. The policy question of "should testing and unstable be differentiated by os-release" isn't straightforward, and there isn't consensus that the answer should be "yes", as you would like it to be. But in what way is it inaccurate? Your text says (at least as I read it) "the technical problem is easy, but the os-release maintainer is preventing us from implementing the otherwise-agreed solution". This is an accusation of poor conduct aimed at the os-release maintainer. Given that there is a policy question here that is not straightforward (and where there isn't an obvious consensus), this isn't a fair accusation to make. People are allowed to disagree with each other in Debian, and must be allowed to do so without being accused of acting in bad faith. And same question as I asked Sean earlier - by "consensus" here, do you mean that you want to see more people outside of TC members chiming in on the policy question? No. TC bugs are not popularity contests. My point is that your paragraph I objected to was claiming that the os-release maintainer was stopping "us" [presumably meaning Debian] from fixing the bug that os-release does not differentiate between testing and unstable. In fact, you are trying to change Debian's position on the differentiation between testing and unstable; the os-release maintainer is acting, in effect, to maintain the current RT position. You are "blocked" by having not yet persuaded the necessary people (RT at least, maybe also the TC) that this change should happen. To be clear: it's perfectly OK to want to change the project's position on this question (even though I don't currently agree with you); it's perfectly OK to try and persuade the os-release maintainer to do as you wish; it's _not_ OK to accuse the os-release maintainer of bad behaviour because they don't agree with you. Regards, Matthew
Bug#1077764: Ruling request on os-release specification implementation
On 06/08/2024 11:22, Luca Boccassi wrote: On Tue, 6 Aug 2024 at 11:10, Matthew Vernon wrote: The policy question of "should testing and unstable be differentiated by os-release" isn't straightforward, and there isn't consensus that the answer should be "yes", as you would like it to be. Debian's current (and long-standing) answer to that question is "no", and my view is that you have not advanced a sufficiently compelling case that this answer should be changed. Sorry, I don't follow. How is that related to the implementation details of how to solve it? Well, because if the answer to the question is "no, testing and unstable should not be differentiated by os-release", then there is no need to come up with a system whereby they are differentiated. Regards, Matthew
Bug#1077764: Ruling request on os-release specification implementation
Hi, On 06/08/2024 10:42, Luca Boccassi wrote: This is not a hard technical problem with no known solution that we are asking for design guidance on. This is a trivial technical problem with a hard social conflict at its core. What we are really blocked on is that the current owner of os-release refuses to let us fix it. This is an unfair and inaccurate summary. The policy question of "should testing and unstable be differentiated by os-release" isn't straightforward, and there isn't consensus that the answer should be "yes", as you would like it to be. Debian's current (and long-standing) answer to that question is "no", and my view is that you have not advanced a sufficiently compelling case that this answer should be changed. Regards, Matthew
Bug#1077764: Ruling request on os-release specification implementation
Hi, With my jaunty TC member hat on, I would prefer if issue came to us with a description of both sides' perspective on the discussion that they would view as fair. In any case, I hope that Santiago will feel able to chime in with their perspective. My initial thought is that this is really about whether the base-files maintainer is correct to have decided that os-release for testing and unstable should not provide VERSION nor VERSION_ID; that seems to me the technical policy question, and whether os-release moves into a new package or not is an implementation detail that flows from that decision? I think the base-files maintainer's position is that testing and unstable do not have a version, and that testing gets a version towards the end of the release cycle (in closing #659853 they say "like /etc/debian_version, this file should only be considered meaningful for stable releases"). They assert that the release team supports this approach (and I've not seen any suggestion to the contrary). I note that the os-release spec says "Note that operating system vendors may choose not to provide version information, for example to accommodate for rolling releases. In this case, VERSION and VERSION_ID may be unset. Applications should not rely on these fields to be set." I think the submitter's contention against that is that in fact people do want to be able to differentiate between testing and unstable. I think they would go further and say that people want to be able to do this without doing anything more involved than inspecting /etc/os-release and that Debian should support them in so doing. Is that a broadly fair summary? Regards, Matthew
Bug#1069890: Resignation & call for votes to elect the Chair
Hi, ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Stefano Rivera E: Timo Röhling F: Craig Small G: Matthew Vernon H: Sean Whitton ===END I vote H > A = B = C = D = E = G > F If no-one else wants to be chair when Sean leaves, I'd be willing to do so. Regards, Matthew OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
Hi, On 12/01/2024 12:31, Helmut Grohne wrote: For the gzip case, we have the additional question whether we tolerate the temporary policy violation for the trixie upgrade or halt the /usr-move and retry with a modified dpkg (that could land in trixie, so we could complete in forky). What's the scope of dpkg modification needed here? And is likely the sort of thing the dpkg maintainers would accept. Were we not already in a bit of a mire here, it's not clear to me that policy is wrong here (and thus that we should set it aside). I also note that there may be unknowns beneath. In May last year, things looked good, then we found empty directory loss and m-a:same shared file loss. Then things looked good again until October when we found this. Chances are, there are more unknowns. This continues to make me worry we are not on the path of robust engineering. But I appreciate I'm in a very small minority in that regard. Regards, Matthew
Bug#1060700: Requesting advice regarding the impact of problems caused by aliasing on declared Conflicts
On 17/01/2024 14:07, Helmut Grohne wrote: I somehow missed how Ben's libnfsidmap bug #1058937 works slightly simpler. Given that $second has a conflict with the installed version of $first, one can skip that second step and instead install $second directly with dpkg -i. So no, this weird selections stuff is not technically necessary. To check I have understood correctly: one may see loss of files when doing dpkg -i of a package where it Conflicts: with an installed package? If that's so, then I think it increases my unhappyness about this situation. I can understand "do upgrades with apt, that's the tooling for the job", and we had already talked about adding something to release notes to describe what manual actions that one might take during an upgrade were dangerous, but "dpkg -i foo.deb where foo.deb Conflicts with something you have installed" seems like the sort of thing one really might reasonably do during an upgrade that has got stuck for some reason or other. Regards, Matthew
Re: /usr-move: Do we support upgrades without apt?
Hi, On 21/12/2023 09:41, Helmut Grohne wrote: Is it ok to call upgrade scenarios failures that cannot be reproduced using apt unsupported until we no longer deal with aliasing? I incline towards "no"; if an upgrade has failed part-way (as does happen), people may then reasonably use dpkg directly to try and un-wedge the upgrade (e.g. to try and configure some part-installed packages, or try installing some already-downloaded packages). It may be that the mitigations necessary are worse than the risk, but I think the behaviour as described in #1058937 is definitely buggy. Regards, Matthew
Bug#1052460: tech-ctte: In re ticket 1051368: including Selenium Manager in python3-selenium package
Hi, On 22/09/2023 14:50, Jonathan Kamens wrote: The current version of the Selenium bindings for all supported programming languages relies on a Rust executable called Selenium Manager for managing the webdriver executables required for the various browsers that the bindings interact with. Selenium upstream has one git repository - https://github.com/SeleniumHQ/selenium which contains bindings for python (packaged in Debian as python3-selenium), ruby (packaged in Debian as ruby-selenium-webdriver), and C#/Java/Javascript (not AFAICT packaged in Debian) as well as the Selenium Manager, which is a rust CLI tool. I agree that having the Manager available in Debian would enhance the experience of python and ruby Selenium users. From the upstream changelog, it seems that version 4.11 is where searching for drivers is done via the Manager: * Use Selenium Manager to locate drivers on PATH [ https://github.com/SeleniumHQ/selenium/pull/12356 ] ...and the Ruby bindings have a similar entry. But the latest version of ruby-selenium-webdriver in Debian is 4.4, so that issue hasn't bitten yet. I'm afraid your analysis of how selenium manager might be made available in Debian is incorrect, however. It would need to be built like any other Rust program - with a source package and so on (Debian packages cannot download things from the internet during their build process); and the various rust dependencies would also need packaging if they're not already available in Debian. This is quite a lot of work, and I can quite see that the (presumably) python specialists who have packaged python3-selenium would not feel able to take on that Rust work. An alternative approach might be to patch python3-selenium to search PATH for drivers (as I think it did before that functionality was moved to the manager) - I'd be interested to hear if the maintainer would consider a patch do so if someone wrote one? I see that python3-selenium now has a NEWS.Debian entry that points to README.Debian, which seems like a reasonable way to bring this to users' attention. Regards, Matthew
Bug#1050001: Unwinding directory aliasing [and 3 more messages]
Dear Luca, On 27/08/2023 03:16, Luca Boccassi wrote: [things] You've already been asked by a couple of people to moderate your tone in this thread. I appreciate there is a lot of frustration around /usr-merge, but your contributions are not helping with that at all. Nor do they help us have a constructive discussion. The DEP-17 work continues whilst this discussion is ongoing; this discussion is not delaying that work. I think it is fair to say that when ctte decided on /usr-merge it was expected that a) the process would be reasonably straightforward and b) dpkg could be taught to understand directory aliasing, so we would not have to be doing things "behind dpkg's back", as it were. I think the need for a releases-long moratorium on moving files and the volume and depth of technical work represented by DEP17 demonstrate that those expectations turned out not to be met. Given that, it seems to me that a) warnings that "it's not that simple & easy" were not FUD and describing them thus is unhelpful b) it's reasonable to at least ask the question "given what we know now, are we still sure this is the correct approach?" Any such consideration must be mindful of the fact that the majority of Debian installs are now /usr-merged, which means that the complexity of unwinding such installs has to be a heavy factor in thinking about alternative approaches. I'm hopeful, but not certain, that the DEP17 work will get us to a coherent state again by foxy (which still feels a long time off); I don't think we should underestimate the work to be done in properly completing /usr-merge. This discussion has, I think, been broadly useful in clarifying some folks' thinking in this area. I would very much like if we could keep it focused on the technical matters. Regards, Matthew
Bug#1050001: Unwinding the directory aliasing mistake
On 18/08/2023 09:05, Christoph Berg wrote: Re: Ian Jackson Protecting my mental health I will try to avoid regularly reading this thread. I hope that now that I have made the suggestion, others will be able to carry the conversation. I will be configuring my mail client to disregard my personal copies of messages sent to this bug; when I want to read the thread I will look at the mailing list. Also, if you disagree with my decision to raise this now, please don't email me. If you feel I have overstepped a boundary, please contact the Community Team or DAM. I think this is just gross. Submitting a proposal and then telling CT/DAM to deal with the fallout is rude. I disagree; the TC has handled a number of issues now where at least one of the main participants has declined to participate in the discussion thread. It's obviously not ideal, but I don't think it's entirely out of order (and the TC has not considered it as such in the past). Regards, Matthew Disclaimer: I know Ian personally, but I don't think that's affecting my opinion here
Re: Next meeting -- 8th July, 6pm UTC
On 07/08/2023 07:39, Luna Jernberg wrote: Should this really be July or August? August - the meeting is later today. Since I'm writing anyway, my action item from last meeting resulted in this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041072 Regards, Matthew
Bug#1041072: trixie: Explicitly flag that /usr-merge changes will break skip-upgrades
Package: release-notes Severity: normal X-Debbugs-Cc: debian-c...@debian.org Hi, We don't support skip-upgrades, but in practice they can often be made to work by an experienced administrator. For trixie, though, packages are going to be allowed to assume merged-/usr, and the ongoing work to resolve the outstanding problems around merged-/usr and dpkg is going to concentrate on making sure all bookworm-trixie upgrades will work. But changes that could result in file loss on a bullseye-trixie skip-upgrade will not be considered bugs, so it would be good to particularly emphasise in the trixie release notes that skip-upgrades to it are not supported, and that in all circumstances administrators must upgrade to bookworm first. Thanks, Matthew ps: on a procedular note, whilst I'm filing this bug as an action from a technical committee meeting, this is not a formal TC request.
Bug#1040228: Resignation & call for votes to elect the Chair
Hi, On 03/07/2023 17:55, 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: H > A = B = C = D = G > E = F Regards, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#1037563: tech-ctte: Call for votes on TC membership of Timo Röhling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On Wed, 14 Jun 2023 10:04:54 +0100, 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 Regards, Matthew -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmSJhhcACgkQEvTSHI9q Y8hlRxAAqtB1a7wktMYhZbLsgJCGUj6rrWTleVHQUYUA68RTF8zuNiXNsLtOZhFY KpChIb8eHf0tKTGS2QzyPya88b8Y2v5GIomdDrVnm0xik8T0lIFRTO6ojnJDb1sQ Mkb2ookniRp3AhLA4vlmZgtDmtKECBHYcEwXrehN6QQQc1Q0A38r8N/cGhy3d5GI EiyJSDwI9nPw4W8WWWfxGvL+3HDPRKr89uBzOfb8/IPQEJ/LdnCXMUT0FfhEsMMC yl0odXa3iL9MNLvWlOAUClJMKbFu/qdHfEn8GPEM2+wAOj3bsxCa3g1W7677LmOY PRW00wsTln98a/8l/M5854JTCikExQ+UKC7H5UNw/NsfG23et5A8akNN4uFZV1YM 0PStKLrjmTE6FS3j/0s+x5hsgWflr0jtW4tUg+Ra925bGEZJaPaZa5rSCJ8a2dAn xdUL2+YdsCtN0thUnAbqinm9L+ne0SwIENQTf7SY01CWkr9o0QTGV7Gu3OhOuTA+ bLsvG2hP87vmXWl3xPFTwQwY9cZjtXdAV6ammQBsIYmGRKSU638R3MZCsq3LCDKk FR+Tv6slr1xcLqV3xim3cNzooH+vqlBbzSblqgMbub9op2Z6rQ06vER/zKNUCGdn YQ9MDrvo2Y/bnVmAyciSPIhyNG1jEfuY1JfgGer+GkaGEEOrsLA= =cICf -END PGP SIGNATURE-
Bug#1037562: tech-ctte: Call for votes on TC membership of Stefano Rivera
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On Wed, 14 Jun 2023 10:03:19 +0100, 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 Thanks, Matthew -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmSJhd8ACgkQEvTSHI9q Y8jiaw/+K4VyZctMAdD+SvVIefZJ+seSDBPkHR9a8xwfuz4mXIDKycmvGh6lyI8r 1S3ZmyUSAyntac97Wxl8cFWH2Z+BPYQI61tZK5IP+bkQSMj44QWkIxgAlFbrApCi OrshXTup8Nws/IKz6cR5hSvSEtO7f07janwdTmzBAhDpYF/IHoAPKVY+kxX7M4hr Mtt/lZhzdAAZEsojBdpvhx0HDKTJruZQrdf/3dz5ftVdQVPAz/lq1W4oCcxlrs1y 39lzlRhZGdUq62fokoGApoc1B2uVv/mHln1oC6FpyqMfT9ocwotASb5ks3IAz0Ix bdf5ApX8vL/9Q1bpjRMaLDSorkNI8s9Mq1yGPZmhXHYLWFdbh5ucB8DtY85dGkEY u2Ej/C1jgXF0O35nDFFMBpvjXD/BmU52okTIW5qOTa7Ndmt1PWoFchx1TpT9mL2R XJY6DcV7/9AyJUs6M+vVhHJ0EmoDp5o/Z7RMOmPBDYTgyoW6XCNAw3zJdRTVfg+g VIF3YYZP6y+vNeqMmx4Iu9dM+1b4fF0QVIOia+VnSVJjMqWlYy6cLEMSQm5Q37Lk OiGsdNgDyCl5CoKnsvS88PF+EnLY1k2WHWrdrDZ6MhYdmh9+9H9KKf5wQvSVcFGu XPVyoO0bek8UOZ3OWyXtpV6WMbRlflIhmpS1462y3W9s+1AfW2k= =//2f -END PGP SIGNATURE-
Re: DEP 17: Improve support for directory aliasing in dpkg
On 26/05/2023 09:24, Luca Boccassi wrote: On Fri, 26 May 2023 at 08:39, Matthew Vernon wrote: Consider: it is consistent to believe that it would have been better for dpkg not to have had that warning added (quite some time ago now), but that by now most derivatives that care will likely have patched it out again (mitigating the harm); and if the current work on dpkg is allowed to run its course then the warning will probably go away anyway. That assumes all derivatives track unstable/testing and have taken action, but it is possible for derivatives to track stable only, and those would be broken. I agree such distributions would be left with a confusing disagreement between the release notes "only /usg-merged systems are supported" and dpkg's warning. I agree this isn't ideal; but the release notes will mitigate the risk to such derivatives. And as I said up-thread (and I'm trying not to repeat myself too much), I'm not sure why this is suddenly urgent so late in the release cycle, nor that we wouldn't be better off working on fixing the issues around dpkg and /usr-merge (which some people are currently doing). Regards, Matthew
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On 26/05/2023 07:03, Ansgar wrote: On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: Ansgar writes: Debian going out of its way to tell derivative users to switch back from merged-/usr to split-/usr is the *opposite* of trying to make things as smooth for them as possible. Yes, I agree with that part and I think I objected to that at the time. Nonetheless, one bad decision doesn't mean that it is Debian policy that we don't care about derivatives or their users. I think we made a mistake there which is not in alignment with our ideals or our goals. We should try to reverse that mistake, not double down on it. My impression is that the tech-ctte disagrees on this point and would not want to reverse the mistake, but double down on it (in your words). Your impression is incorrect. And assigning motivations to other parties during contentious discussions should be done with care if at all. Consider: it is consistent to believe that it would have been better for dpkg not to have had that warning added (quite some time ago now), but that by now most derivatives that care will likely have patched it out again (mitigating the harm); and if the current work on dpkg is allowed to run its course then the warning will probably go away anyway. Or rather my impression is that they would like to avoid any decision on the dpkg mess situation. (Though not making a decision when asked is of course also an explicit decision.) There is currently a pile of ongoing work and discussion about /usr-merge and dpkg (in -devel at least). It seems to me that the right thing to do is to see how that work pans out, and let the people doing that work do so in peace. So let me summarize Debian's "official" position as I understand it: we do *NOT* care how dpkg's recommendations will break derivative installations at all; if systems become unbootable, cause data loss, ... now or in the future that is explicitly fine. This is also unhelpful (and incorrect). I do not think the case has been made that it is urgent that we remove (or revise) the warning from dpkg Right Now; if you want to attempt to do so, please do so without impugning those who disagree with you. Regards, Matthew
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, This thread has rather veered off the initial bug report. On 11/05/2023 13:16, Simon Richter wrote: Hi, On 5/11/23 10:59, Sean Whitton 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 way I see it (but I'm not a dpkg maintainer), the current implementation is correct, as dpkg does not support aliased directories, but Debian has decided to use it in such an environment nonetheless. The tech-ctte decision not to roll back usrmerge accepts responsibility for this decision, so silencing the warning on Debian is correct, but no one has accepted that responsibility for derived distributions. Any derived distribution can easily go on record and request inclusion in the list of distributions where this warning is suppressed, by typing the phrase "Yes, I understand that this is a bad idea." into an email client. I have considerable sympathy for this point of view. Further, given ongoing (and quite fruitful) discussion on how to resolve the outstanding issues around /usr-merge and dpkg, I don't think the question of dpkg's warning (and its unfortunate wording) is one that is useful for the technical committee (and the dpkg maintainers) to be spending time on right now. I think I would feel differently if there were derivatives who had asked the dpkg maintainers to likewise exclude their distro from the warning had been rebuffed (though I suspect such folk will just be patching it out in their own builds). Likewise I would expect that once we have finished sorting out the outstanding /usr-merge & dpkg issues that the warning would be removed. But those scenarios aren't where we're at now, so I think the project should continue to focus on moving ourselves to the point where dpkg does support /usr-merge as implemented in Debian. Regards, Matthew
Bug#1035831: tech-ctte: Reinstate merged-/usr file movement moratorium
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 09 May 2023 21:26:10 +0100, Hi, 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. Regards, Matthew - -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmRjwrQACgkQEvTSHI9q Y8jZ2g//dP+kxRXBLe/GjgE54NsePfPFmXD4gFaOsr535M3IePVRqA7JNHs9g0Fj kCZLH0lZnM04pTp/EPqUas/9HY4wq6sVTo+SDjWe+seJu6ichdIqLmuKoKUF1jqp ps+ZBi0ppeQBrfirYU1i9xrKXQPMMfcQ+IRgyllvPSwuqB9lpFPDeIYsZGEJjaER KzZ4lm+/56F4SrnannYon5la8IO+nUQFvM3vWuaQJFENnTB8RaMjBm+29kvUnJEl 7JHVdKZppqwgiYtzaOkLfEdAv2zcfpk/fL6Zd/pe6p+nSPXWXzyhUVJvCcuRq6B+ uiGj8F7G0K35jSm/1wozSwE9iyeNfOi9QJS4XnRYT8t6VxUn8KfZUbMBtalh4fIN 3dt10eKkJEPBSNuMzky7uDQszbo6JaQIWRs0Jb7pYftpimcCf0OZ/3ICC/gTHm/I 63CFwXaIm/cSXEw/ol9GBJ1ZIh5zcRH95tK0bLDZtIs6KRMF0aqzUvwaYSBcxCuM sirbd+PaQ87I19nPyyFuwi6yhUDwWsnXCENc/GGsU9LQp/UDaG5Er8YVcfWkpMh2 lM+ih6qP9hLjeYBAywYJlzRWYVieiLvfaOQCrkOlfOSZKQD8tGqGTbBj6+9LTa9e YxJJrSiHXK3g8JY/GLvnIJLlvcEdsE1Ivkae8WaeHBuvc8JUs7w= =Dysi -END PGP SIGNATURE-
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On 15/05/2023 16:54, Bdale Garbee wrote: I could. Can you provide an example of actual value delivered to Debian from merged-/usr? With respect, I don't think this line of argument is going to get us very far - this bug isn't about whether we should undo usr-merge, so I don't think a debate on the merits or otherwise of usr-merge is germane. [I think this applies to the contrary side of the argument also] Regards, Matthew
Next meeting: 18:00 UTC today
Dear committee members, Today is our slightly delayed monthly meeting, at 18:00 UTC. The March meeting didn't happen, so this is our first meeting since February. I've not seen any recruitment updates, so I propose we leave that topic until the May meeting in a couple of weeks (and so don't have a Jitsi segment to today), unless Sean has something he wants discussed in that regard, so the agenda is: - Review of AIs from February meeting - DEP17 - the moratorium on moving files into /usr Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-02-14-17.58.html Regards, Matthew
Re: DEP17 feedback
Hi, A quick summary, because my memory is suspect at the best of times... On 22/04/2023 20:36, Sam Hartman wrote: Oh, excellent. I was just considering formally asking the TC to extend the file move moratorium to trixie. I've seen a number of people recently proposing moving files in trixie who do not appear to understand the issues, and so I think more TC clarification on this issue is important. Would a formal request help, or can the TC handle this internally? This was advice (constitution 6.1.5) we issued in October 2021 apropos bug 994388[0]: "- Please stop moving individual packages' files from the root filesystem into /usr, at least for now.", clarified in the lengthier text to mean that we expected this sort of move would become possible during the Debian 13 release cycle. That advice expires once Debian 12 is released. The release team position[1] is: "* The TC resolution #994388[1] recommended a moratorium on moving files' canonical location from / into /usr. Until there's support in dpkg for merged /usr, we want this moratorium to remain in place, even after the bookworm release. 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. " So we _could_ leave it to the RT's discretion as to when they think dpkg supports it enough to start allowing it, or we could extend our moratorium. Regards, Matthew [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 [1] https://lists.debian.org/debian-devel-announce/2022/07/msg2.html
Re: Next meeting -- 14th March, 6pm UTC
Hi, On 13/03/2023 21:35, Sean Whitton wrote: Minutes of previous meeting: http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-01-10-18.03.html I think that should be http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-02-14-17.58.html Regards, Matthew
Bug#1028357: Resignation & call for votes to elect the Chair
Hi, On 09/01/2023 22:30, Sean Whitton wrote: ===BEGIN A: Christoph Berg B: Matthew Garrett C: Helmut Grohne D: Simon McVittie E: Matthew Vernon F: Sean Whitton ===END I vote thus: F > A = C = D = E > B Regards, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#1026104: longstanding problem with dependencies of python3-numpy in testing
Hi, On 14/12/2022 18:55, Joachim Wuttke wrote: At times, python3-numpy in testing depends on two python3 minor versions in parallel. This is unusual, annoying for many users, and breaking dependent software for some. Complaints have been filed at Sandro, would you be opposed to relaxing the Depends: to a Recommends: ? If you would be opposed, would you mind briefly explaining why, please? Thanks, Matthew
Re: December meeting
Hi, On 06/12/2022 00:10, Sean Whitton wrote: 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? Either option WFM. Happy to be stunt-double chair if necessary. Regards, Matthew
Bug#1024823: tech-ctte: Call for votes on TC membership of Matthew Garrett
Hi, On 25/11/2022 22:39, 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. Regards, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
Hi Zack, Thanks for bringing this to the committee; even if Sean is correct that we won't act on this report, you've described the issues clearly and I think it was worth bringing to our attention. On 26/09/2022 20:28, Zack Weinberg wrote: It has been known for some time that dpkg has bugs which prevent it from correctly handling merged-/usr systems. #858331/#848622 is the only such bug (that I can find) that has actually been recorded in the BTS, and it *appears* to be a relatively harmless problem, affecting only dpkg-query output. This much is uncontroversial. However, Simon Richter showed in https://lists.debian.org/debian-devel/2021/08/msg00326.html that the > bad dpkg-query output is only the most obvious symptom of a much more serious problem, and that, under conditions that will plausibly occur in the archive after the release of bookworm (assuming all continues as presently planned) upgrading packages on a merged-/usr system can cause packaged files to disappear from the filesystem. The files most likely to be affected are the files that are currently packaged in /bin, /sbin, and /lib, including, just to mention a few, /bin/bash, /bin/systemd, and /lib/$ARCH/libc.so.6. Thus, the dpkg bugs can render systems unbootable on upgrade, and should be considered critical severity. This is a very useful message, and (at least to my mind) makes it clearer how more serious problems might well occur. 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 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, Matthew
Re: Bug#993161: pam: some remaining changes for DPKG_ROOT
On 09/09/2022 19:45, Sean Whitton wrote: 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. AIUI, Steve's objection is substantially that this is quite an invasive change to make across our toolchain, and should be discussed on debian-devel before just being implemented package-by-package (rather than any particular objection to the approach). Is that correct? But that Sam is unsold on the technical approach and wanted input from Steve before agreeing? Regards, Matthew
Re: tech-ctte: more on merged-/usr
Hi, Not quite sure where in the relevant threads to put this concern, but. On 17/07/2022 14:21, Luca Boccassi wrote: On Sun, 2022-07-17 at 11:34 +0100, Simon McVittie wrote: On Sun, 17 Jul 2022 at 00:56:14 +0100, Luca Boccassi wrote: The patch from user uau that the dpkg maintainer rejected in the past has been submitted to the existing bug [2] for completeness (with permission from the author). If I remember correctly, Julian Andres Klode was developing a version of this patch that replaced the hard-coding of the /usr merge with a more general way to declare "directory A is an alias for directory B" and have it stored in the dpkg database, so that dpkg has the mechanism and some Essential package like init-system-helpers or base-files could have the policy, in the hope that this would be more acceptable to the dpkg maintainer. Is that code available? I asked Julian a week ago or so on IRC if he had worked on that patch at all, and the answer was no. Besides, I think [0] and everything else make it very evident at this point that the form and function of the patch attached to the dpkg bug are not really the problem. There are more fundamental issues of project management and organization at play, and thus we really do not want those issues to be in the way of the goal of fully moving to merged-usr. [putting footnotes in your .sig means they go missing when I reply] While it's understandable, I am saddened and a bit worried by the "it's too much hassle to fix dpkg's usr-merge support, let's not bother" message I seem to be getting from these threads. I like to think that Debian strives for technical excellence, not "this class of bugs is very infrequent, so it's not worth the pain to fix". I get that getting patches accepted into dpkg can be challenging (and that is, in an of itself a problem), but it worries me that we seem to be collectively deciding that this is an acceptable status quo. This is very much a personal view, not an expression of anything approximating TC policy. Regards, Matthew [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#132 (the warning that was briefly in dpkg re merged systems)
Bug#1007717: Ballot and call for votes
Hi, On 21/06/2022 01:31, Sean Whitton wrote: 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 I vote: A > C > X > N Thanks, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#1007717: Draft resolution for "Native source package format with non-native version"
On 07/06/2022 07:08, Sean Whitton wrote: 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. Mmm. And I'd be pretty reluctant to talk about deprecation until the replacement is good to go. 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. I would certainly vote against 4b as drafted; I would need considerable persuasion that "more uniformity" here is a concrete benefit. Regards, Matthew
Bug#1007717: attempt to summarize current state of this bug
Hi, I thought it might be useful to try and summarize where we are with this bug, which hasn't see much recent activity (not least as there's a TC meeting later...). * Questions asked of the TC The Committee was invited to issue advice on a number of points: I - continued use of 1.0 native format 1) declare that there is nothing with with a package with a native format but a non-native version number 2) request the dpkg maintainer relax the restriction of 3.0 native that prevents using that format with a non-native version number 3) declare that the MBF on the topic shouldn't have been filed against packages where the change is more complicated than simply change the source format II - continued use of 1.0-with-diff 4) declare that there are circumstances where use of 1.0-with-diff is the best tradeoff between different considerations 5) declare that the MBF on this topic shouldn't have been filed against packages that are 1.0-with-diff (or at least not against all of them) During the following discussion, TC has also been invited to come up with policy on native packages and Debian revisions. * Package formats The TC have been told that: 1.0-without-diff is in some circumstances better than 3.0 (native), because dpkg prohibits use of 3.0 native with a non-native version number; were that restriction relaxed, 3.0 (native) could replace 1.0-native 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based workflows, because in 3.0 (quilt) the diff is included inside the source tree 3.0 (quilt) with single-debian-patch can represent some changes to the source tree that 1.0-with-diff cannot native format has the advantage over any quilt or diff format that it can represent some changes to a source tree that patch/diff cannot represent (e.g. changes to symlinks, which are changes you can make in git) I don't believe any of these statements has been challenged. * Discussion in the bug Lucas (who filed the MBFs) has stated that they do not intend to make them RC, nor reopen ones that the maintainers close. This may well make 3/5 relatively moot? The issue of preferred form for modification has been raised (source package in general, quilt stack, or VCS repo); Sam states that there is consensus both that git workflows are best practice (especially where upstream uses git), and that natives packages are sometimes an appropriate tool to use. There is a wide range of git workflows, which the occasional NMUer can avoid caring about by use of dgit(7). There was also discussion of whether 1.0 formats were "niche" - they represent 1.9% of packages in testing. Russ argues that we should allow both native and non-native packages (defined by whether there is a separate upstream release from the Debian package) to use single-tarball source formats (and that the name 3.0 (native) is a bit confusing here); Felix instead contends that "native" means instead that a package lacks a Debian patch, and we should stop defining native or otherwise in terms of version numbers. There was some further discussion of better terminology, but I don't think it went anywhere conclusive. Updates / corrections welcome :) HTH, Matthew
Fwd: Bug#1003653: Revision of removal of rename.ul from package util-linux
Dear Chris, Thanks for your contributions to the discussion of Bug 1003653. Here's a copy of the Technical Committee's decision on the question; if you've got any questions about any of this, please let us know. Thanks, Matthew Forwarded Message Subject: Bug#1003653: Revision of removal of rename.ul from package util-linux Resent-Date: Fri, 29 Apr 2022 18:45:01 +0000 Resent-From: Matthew Vernon Resent-To: debian-bugs-d...@lists.debian.org Resent-CC: Technical Committee Date: Fri, 29 Apr 2022 19:41:46 +0100 From: Matthew Vernon Reply-To: Matthew Vernon , 1003...@bugs.debian.org To: 1003...@bugs.debian.org On 20/04/2022 15:31, Matthew Vernon wrote: I hereby call for a vote on the following ballot. Unless a TC member objects to calling for a vote, voting lasts for a week, or until the result is no longer in doubt. The voting period is over. ===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 Resolution A wins, with 7 first preference votes (and no other votes). Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
On 20/04/2022 15:31, Matthew Vernon wrote: I hereby call for a vote on the following ballot. Unless a TC member objects to calling for a vote, voting lasts for a week, or until the result is no longer in doubt. The voting period is over. ===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 Resolution A wins, with 7 first preference votes (and no other votes). Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, I hereby call for a vote on the following ballot. Unless a TC member objects to calling for a vote, voting lasts for a week, or until the result is no longer in doubt. ===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 Regards, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, Thanks for this. 1. While the former "should" is guarded by "requires", I think the latter can be read as a recommendation. I therefore propose replacing it with "must" to make the override more obvious. 2. While option B reads fine to me, option A is a little confusing to me due to the combination of the naming requirement with the mentioning of the conflict. Given the rename.ul name, there seems to be no reason to cause a conflict at all and we can simply require that. As such I think the options should be fully separated. I think I would generally like TC resolutions to be "natural English to be interpreted pragmatically, particularly in light of the rationale" rather than bullet-proof legalese. Now is not the time to die on this particular hill, though :-) ===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' I hereby modify my options A and B to replace them with the contents of A' and B' thus. [I'll do the necessary C&P when calling for a vote on the ballot] Thanks, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, Thanks for the feedback on my previous draft; here's a revised ballot. I propose a ballot as follows - if no-one suggests further options in the mean time, I will call for a vote on this ballot on Tuesday, after the weekend of public holidays. From a procedural point of view, I am formally withdrawing both ballot options I proposed in <9012b2bf-dd1f-afc4-7f62-75ba4116b...@debian.org> (thus voiding that process per constitution 6.3.1.3), and starting afresh. ===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 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 should not contain any other binaries. The Technical Committee further requires that this binary should be shipped as /usr/bin/rename.ul ===End Resolution A: Override util-linux maintainer, approve entire resoltuion B: Override util-linux maintainer, approve only first paragraph of resolution N: None of the above Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
On 15/04/2022 07:36, Gunnar Wolf wrote: Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]: Backwards-compatibility (and the lack of a compelling argument that util-linux's rename is significantly superior to the perl rename) means that /usr/bin/rename in Debian should remain the perl rename. I'd prefer to read "that neither 'rename' implementation is superior to the other", maybe even explaining that "they were designed out of different needs and meet different criteria". I intended to cover that in the first paragraph; my point here was that there would need to be some compelling reason to change our /usr/bin/rename implementation now (such as the util-linux one being much better). I'll try and draft it better. Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, Thanks to everyone for your contributions to this discussion. I think we're at the point where voting is appropriate. I propose a ballot as follows - if no-one suggests further options in the mean time, I will call for a vote on this ballot on Tuesday, after the weekend of public holidays. ===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. Backwards-compatibility (and the lack of a compelling argument that util-linux's rename is significantly superior to the 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 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 Regards, Matthew ps; my first TC resolution, please be gentle if I have the procedure wrong!
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, On 09/04/2022 14:59, Chris Hofstaedtler wrote: I was not planning on doing that: stable already does not have /usr/bin/rename.ul. People were asking for it to be restored before the stable release, though, I think? #966468 was opened against version 2.36-1 back in July 2020. Given rename.ul is not in stable (bullseye), I do not think we should do this. From a compatibility point of view, we do not win anything. At this point, we are more talking about shipping a new program in a new place, than continuing to ship an existing program. I disagree; we have historically shipped rename.ul, we didn't in stable (against the wishes of at least some of our users), but I don't think that means that restoring it again would be "shipping a new program in a new place" in a meaningful sense. If we were talking about all of this before the stable release, I would be a lot more open about other options. But by now almost two years have passed since the change, and bullseye is out for ~ 9 months. Issues are slow to get to the TC, and the TC is often slow to resolve them; I think "escalate to the TC rapidly or the status quo ante will prevail" is not a line I want to encourage. I know we all want this TC issue to be resolved. But I do not want to end up shipping rename.ul indefinitely. I'm still not sure what harm occurs from doing so? Regards, Matthew
Re: Next meeting -- one week early, 5th April @ 7pm UTC
Hi, On 29/03/2022 21:01, Sean Whitton wrote: I have Covid, so am not going to be around this evening, sorry. * DebConf22 CfP -- what sort of talk do we want to submit? I think I have no particular feeling on this, so happy with whatever you decide. Sean's "meet the TC" seems a reasonable idea. * Bug#1003653: Revision of removal of rename.ul from package util-linux I sort of feel we should make a decision on this, it's been dragging for a while now (not helped, I feel, by rather limited interaction from the package maintainer). I think the maintainer's position is currently that "rename.ul should be shipped as /usr/bin/rename in a package that would therefore have to conflict: with the rename package". I'm afraid I think that's wrong, and a disservice to our users. I don't think "two things called /usr/bin/rename, pick one" is better than the previous "file-rename is /usr/bin/rename, util-linux' rename is /usr/bin/rename.ul". * Bug#1007717: Native source package format with non-native version I'm not quite sure where we are as a committee on this; I thought Ian Jackson's mail that Sean forwarded on early in the thread was quite convincing on the merits of the various source formats; but a bunch of more-or-less related issues have been raised by various parties, and I think maybe a summary would be useful? Regards, Matthew
Re: Next meeting -- one week early, 5th April @ 7pm UTC
On 29/03/2022 21:11, Sean Whitton wrote: Hello, On Tue 29 Mar 2022 at 01:01pm -07, Sean Whitton wrote: Due to both the current interpersonal situation and the impeding DebConf22 CfP, can we have our meeting a week early? Please let me know if you can't. I think I'm the only person who is somewhere that doesn't observe DST, so we should move it to 6pm UTC, right, going forward? FWIW, I was expecting it to remain at 19:00 UTC; notwithstanding 5th April (when I made other arrangements not expecting a meeting), 18:00 UTC works for me just as well. Regards, Matthew
Re: Next meeting -- one week early, 5th April @ 7pm UTC
Hi, On 29/03/2022 21:01, Sean Whitton wrote: Due to both the current interpersonal situation and the impeding DebConf22 CfP, can we have our meeting a week early? Please let me know if you can't. I'm afraid I probably can't be there until probably around 19:30 UTC (but I don't want to guarantee that); I can provide my input in advance, though. * DebConf22 CfP -- what sort of talk do we want to submit? FWIW, I'm afraid I won't be at DebConf (given the situation in Ukraine, I don't want to be committing to travel to Kosovo this year). If there's anything you would like more input from me on, please ask and I'll do my best :) Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, On 29/03/2022 00:55, Sean Whitton wrote: On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote: The problem here is that if ul-extra contains things besides rename, and it conflicts with the perl rename, people will rightfully complain that they can't install /usr/bin/fincore-from-ul-extra and /usr/bin/rename-from-perl at the same time. Indeed, and doesn't it violate Policy 10.1, which says "Two different packages must not install programs with different functionality but with the same filenames" ? Perhaps it's an edge case. Yeah, I don't think we serve our users by having two different packages both of which want to install /usr/bin/rename. I'm still not quite sure why the previous path is so objectionable - we shipped /usr/bin/rename.ul for years, Debian (and derivative) users will be expecting it there, having util-linux-extra (WLOG) install it there seems like the right answer (and the one least surprising to our users)... Regards, Matthew
Bug#994388: dpkg currently warning about merged-usr systems
On 25/03/2022 16:25, Russ Allbery wrote: Luca Boccassi writes: But anyway, it turns out it's all moot because - drum roll - there is a patch: https://0x0.st/oNFG.diff This was shared just now on #debian-devel IRC by user 'uau', linked here with explicit permission. This is fantastic, thank you so much! Is the author following this thread? Could they get this patch into a git repository forked from dpkg so that interested parties could start iterating? I have some concrete feedback on the patch, and obviously there are a few things that need to be done before it really could be merged (such as handling the other architecture directories as noted in the patch introduction), so it needs some iteration. That's probably not a good topic for a TC bug, and for various reasons it may not be best to do early iteration on the dpkg mailing list, so we may need some other forum. I'm happy to help out as I have time with patch review and further feedback. I'd like to second Russ' note that it's great that a patch exists :) I'd also like to second the note that the TC (and this bug in particular) is emphatically not the place to be working on this patch. Also, I think the presence and suitability of this patch doesn't change the discussion about the warnings that dpkg is currently emitting, which are the subject of this bug. FTR, I think the current warning is inappropriate; a reportbug script that flags the known issues with dpkg's support for /usr-merge seems like the more appropriate place. Regards, Matthew
Bug#1007717: Native source package format with non-native version
On 17/03/2022 17:52, Russ Allbery wrote: Helmut Grohne writes: Do you think it would be impossible to move forward on this matter in a consensus-based way? I don't know. I have some reasons to be dubious, but it's possible that I'm being excessively pessimistic. I'm inclined to agree with Russ here; my impression is there are one or two long-standing areas of disagreement here, and that consensus hasn't been arrived at. In the spirit of consensus: Do you agree that retrying this in a consensus-based way is still possible? If the relevant people required to implement a decision are willing to tackle it that way, I am certainly willing to participate from the Policy side. For the avoidance of doubt, if that is the case, I am not going to suggest the TC gets in the way! Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, Having joined the committee, I thought it best to try and get up to speed on this issue. Is my summary correct? --begin There are two "rename" programs, one part of upstream util-linux "rename.ul" and one provided by the rename package "rename.pl"[0] For a long time, Debian's "/usr/bin/rename" has been rename.pl (via the alternatives system). rename.ul is rename in some other distributions(RedHat; et al?) The two renames have substantially different CLI syntax, making them unsuitable for an alternatives arrangement #926637 asked for rename.ul to become a rename alternative; the maintainer explained why it was not a suitable alternative to rename.pl; they then stopped shipping rename.ul entirely in 2.35.2-5 #966468 & #982944 asked for rename.ul to return (though the latter rather confuses the removal vs alternatives issue) None of the above bugs was linked with this TC bug (it would be normal to block them on this bug), which unfortunately meant the maintainer wasn't notified as early as would have been ideal The maintainer's view is that there is too little value to having rename.ul on a system in a place where you would not expect it to be; and that further this even more strongly not be done in an "essential" package that is installed everywhere. --end Assuming that's all correct, my feeling is that there is no particular reason for Debian's rename to stop being rename.pl, but that we should make rename.ul available to users who want it. I think the maintainer would be happy to move rename.ul into bsdextrautils (as /usr/bin/rename.ul)? Taking it out of essential, not considering it an alternative to rename.pl, and keeping it available for people who want it. Regards, Matthew [0] called file-rename on my stable system.
Bug#1004611: Resignation & call for votes to elect the Chair
===BEGIN A: Christoph Berg B: Helmut Grohne C: Elana Hashman D: Simon McVittie E: Niko Tyni F: Matthew Vernon G: Sean Whitton H: Gunnar Wolf ===END G > A = C = D = E = H > B = F [rationale: being new I don't really have much of an opinion, other than the new chair probably shouldn't be either of the newbies :) ] Regards, Matthew OpenPGP_signature Description: OpenPGP digital signature
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
On 17/01/2021 10:29, Andreas Henriksson wrote: Possibly getting off topic here, but I happened to read a bit of this discussion and while seeing your comment I thought it might be a good time to remind you about #934463. I agree it's off-topic here, so I've sent a message to that bug suggesting an approach. Regards, Matthew
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
On 16/01/2021 01:39, Gunnar Wolf wrote: Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]: Please overrule the maintainer in #923387 so that it is can be used on systems with elogind; it has been tested and shown to work thus as well as being supported by upstream[1]. As it was mentioned on a previous mail to this thread, this discussion on including an elogind dependency was done WRT network-manager. An agreeable solution was brought forward by the maintainer. #923387 (udisks2) was just mentioned in this discussion. Maybe an amicable solution can be tried before asking the TC outright to overrule the maintainer? The maintainer won't talk to me, nor will they engage with me (or anyone else) on this thread, though they will it seems talk to the TC in private. I think, though, that it is common ground between submitter and maintainer that the Depends is necessary for udisks2 (unlike in network-manager where it turned out not to be). There was some discussion about whether elogind works with udisks2 in early 2019 and again in early 2020. On 2020-03-15 Nils draws the maintainer's attention to the explicit mention of elogind support in udisks upstream changelog. Later that day, the maintainer closed and archived(!) the bug, for reasons they decline to elaborate on. Mark reopened on 2020-07-02 on the basis that the bug isn't fixed. Adam sent a ping on 2020-12-31, reminding the maintainer that udisks2 is important for a range of desktop software, that the freeze is coming, and that udisks2 works with elogind, and asking them again to apply the (trivial) patch. There has been no input from the maintainer of this package for over 9 months. Mark tells us that there are not currently any other packages which could be used with elogind were it not for an incorrect dependency on libpam-systemd, so I hope we don't need to worry about the broader question any further. Given the arguments are prone to be very similar, and the issue itself will unfold in a similar fashion, can we try to have a different process? One that does not bring so much heat? I hope a very similar resolution can be had for #923387 - without needing a six-week-long discussion. I don't think this bug can be resolved by downgrading the Depends: to a Recommends:. The maintainer may be able to correct me on that point. We are getting very close to the freeze; without this fix it will be impossible to install a range of desktop software on a bullseye system that runs any init system other than systemd. The maintainer may not like elogind, but udisks supports elogind, and the project resolved that technologies like elogind that enabled alternative init systems were important to the project. I have not come to the TC to ask them to overrule the maintainer frivolously nor before exploring as many other options as I could. The TC is Debian's body for resolving issues of this sort, and the maintainer will at least talk to you. Naturally, if you can persuade them to fix 923387 in a way that means we can use udisks and elogind together in Debian in bullseye I would be delighted. But otherwise, I think you must overrule them, and soon enough that they can upload a fix so it gets into bullseye. Regards, Matthew
Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages
Hi, On 10/01/2021 20:03, Simon McVittie wrote: If you intend the scope of this bug to involve overruling maintainers' decisions in packages other than NM, what other packages/bugs did you have in mind? Is it just udisks2/#923387, or are there more? I understand (but I don't think it has been explicitly stated) that the TC is going to decline to overrule on the question of init scripts?[0] I'm going to beg that question for the rest of this mail, but obviously if I'm wrong that will increase the scope somewhat. Please overrule the maintainer in #923387 so that it is can be used on systems with elogind; it has been tested and shown to work thus as well as being supported by upstream[1]. Mark tells us that there are not currently any other packages which could be used with elogind were it not for an incorrect dependency on libpam-systemd, so I hope we don't need to worry about the broader question any further. Regards, Matthew [0] to that end, orphan-sysvinit-scripts is in NEW, and while I hope your ruling will not result in a bonfire of perfectly good init scripts, I hope that maintainers who decide to ditch them will let us know so we can add them there [1] I've not restated my rationale about how technologies like elogind are important to the project per GR etc etc. I can if you like, but I don't think that's necessary here
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, I see that network-manager 1.28.0-2 has been uploaded, with (inter alia) the following changelog entry: * Demote libpam-systemd to Recommends. This allows users to use and experiment with other init systems. Such a setup is neither tested nor fully supported and users need to be aware that some functionality might be broken. (Closes: #921012) I don't know if Michael has discussed this with you in private, and that you thus know why this change was made (rather than adjusting the dependency as requested). While this does address the co-installability of network-manager with elogind, I would like you to still say something officially about the issue, please, since this is not the only affected package. As an example, bug 923387 (which Michael is also maintainer of) for udisks2, where the dependency must be a Depends not a Recommends (so the workaround used for network-manager won't help). Like 921012, Michael closed it on 2020-03-15 and Mark re-opened it (since the bug wasn't resolved) on 2020-07-02, and there has been no input from him since. I submit that this is technically substantially the same issue, and that you might usefully rule on it unless Michael has told you he plans to fix that already. I don't think (especially given the incoming freeze) that it does anyone any good to have to re-hash the same arguments about that bug. Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On 21/12/2020 23:36, Elana Hashman wrote: The maintainer, Michael Biebl, reached out to the tech-ctte privately. I have summarized his reasoning for why he dropped support for elogind and the init script that prompted this bug: Thanks. There's little point trying to have this discussion with Michael by proxy, I suspect, but I thought I would make a couple of observations on what he says; I will try and not repeat myself too much, although he does raise things that have already come up in this bug. * While we have largely talked about sysvinit here, the issues here do relate to other init systems - elogind integration is useful for all non-systemd inits * I appreciate that there is a tension between maximally integrating systemd-specific features into the distribution and maintaining compatibility with other init systems. There was an option to do so in the init system GR, and it did not win. So while the GR allowed for project consensus to shift over time, I don't think acting as if option F "focus on systemd" won within the same release cycle is really on * We've talked about the burden already; there are people willing and able to help with this, and that offer remains good, be that by providing patches, MRs, help with bug reports on non-systemd systems, NMUs, or some other mechanism that Michael would prefer * I think the difficulty of elogind support is overstated - in the case of network-manager, there are a number of people who are running it thus without issue Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On 14/12/2020 21:56, Philip Hands wrote: Could I just check if there's a point of common acceptability which both sides of this discussion could live with? [...] My suggestion for a mutually bearable solution would be that the network-manager package could have its dependency on libpam-systemd changed to instead be something like: libpam-systemd | network-manager-nonsystemd Is this instead of the logind virtual package? I'm not quite sure what problem you're trying to solve here, but I'm don't think it generalises well (you'd end up with potentially lots of package that just Depend on logind and maybe contain an init script); and without any input from the network-manager maintainer about why they were unwilling to take the patch to use the existing virtual package, I'm not sure why this should be more acceptable. If you think this approach is impractical for some reason, please say so, because what I have in mind as a better option does rather rely on this being available as a plausible fall-back position. I'm confused as to why you don't just tell us what your better option is. Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
On 15/12/2020 22:07, Sam Hartman wrote: However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. We did not say in that GR that we were interested in supporting ongoing development of sysvinit. I find it surprising that, in a TC bug about (inter alia) whether a dependency on libpam-systemd should be changed to default-logind | logind i.e. to facilitate use of elogind you appear to be saying that a GR text that talks about the importance of "technologies such as elogind" should be interpreted as meaning in effect that actually it isn't all that important and network-manager should continue to have effectively a systemd-only dependency. Not is it straightforwardly clear that "alternative init systems" should in fact be interpreted to mean "alternative init systems (but not sysvinit)". Nor is this a case of someone demanding that the network-manager maintainer provide a sysvinit script nor fix the bugs in an existing-but-broken one. By analogy, consider a Finnish translation for a package - as a maintainer I don't know enough Finnish to write nor usefully evaluate a particular translation; but I apply it to my package if one is supplied. If it's erroneous enough that bug reports pile up about it and no-one supplies a fix, I might eventually pull it from the package. But some of the arguments in this thread seem quite close to "non-systemd users might have a slightly less good experience with network-manager, so we should prevent them from using it at all" - which would be like me deciding that my Finnish users might get slightly imperfect messages so I shouldn't support that language at all. Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Hi, On 29/11/2020 16:59, Simon McVittie wrote: Some procedural points, without going into the merits of the technical committee doing as you ask or not: Broadly, I expect the TC to know their procedural stuff better than I do, but I'll try and answer your points :) On Wed, 18 Nov 2020 at 17:33:26 +0000, Matthew Vernon wrote: I invite the technical committee to rule that: * The network-manager init script should be restored * Network-manager should Depend: on default-logind | logind rather than libpam-systemd This looks like a request to use the technical committee's power to overrule the maintainer of network-manager under section 6.1.4 of the Debian constitution. Is that what you are asking for? Yes, I think so; I mean, you might also decide that this is a matter where jurisdictions overlap (between the init diversity folk and the network-manager maintainers), and I wouldn't think that unreasonable. * Similar init-compatibility changes should not be blocked by package maintainers unless they are defective on their own merits This seems like a broader request, and it's less clear which of the technical committee's powers you are asking us to use. Please could you either clarify what you are asking us to do, or reduce the scope of this request to the issue that you are immediately concerned with, namely network-manager? I'm not going to answer this directly, but instead try and explain what I was hoping to achieve - as you say (in text I've snipped), there are a number of ways you might wish to address this question. Let us beg the question for the moment, and suppose you agree with me that the changes I outline should be made to network-manager. Suppose further that there are other packages where fundamentally the same question arises between now and the bullseye freeze (this isn't a hypothetical; there are). I would suggest that it's not in anyone's interests for each bug report to have to come before the TC in turn (I think this is obviously true, but can justify this if you like). To that end, you might want to say something about the more general case at least in period leading to the bullseye release, whether that's expressed as deciding a matter of policy or giving advice. If that's a longer decision-making process, I don't see why you couldn't say "The TC rules on the request to overrule thus; and will say more on the matter hereafter" and then say something more general later. I don't think any statement of this kind would be overriding the GR - as I said in my initial bug report, I think the GR supports what I'm trying to achieve here (pace Josh). To briefly address the question on network-managers utility raised elsewhere: I think it is true both that there are many systems where it is roughly essential (portable devices - nothing else comes close from a managing multiple networks POV), and also classes of systems where being able to install GNOME without it is clearly desirable (desktop systems with complex but stable networking where ifupdown or netplan are more appropriate). Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
[I don't need a CC, thanks] Hi, I know it was mentioned back in the day, but trying to re-ask it now: Wouldn't it be possible to ship init scripts for compatibility purposes from a sysvinit (or maybe a sysvinit-support) package? This would be the inverse of what happened back when systemd was introduced, which was about shipping service files that superseded existing init scripts. I have thought about this, and it seems like a bad idea for a number of reasons, including: 1) poor user experience - a package of initscripts would clutter /etc/init.d/ with a huge number of files (most of which would be no use to the user) 2) init scripts to need to change sometimes, typically that change will accompany a version change in the associated daemon (e.g. the CLI changes) - the most natural way to have this work seamlessly is for the init script to come with the daemon 3) many upstreams (esp. those who support BSD) ship a sysvinit file, again making the daemon (source at least) package the natural place to keep it. 4) difficulty reliably achieving seamless handoff from daemon package to a putative sysvinit-scripts package (e.g. packages that actively remove the init.d file from the installed system; keeping a users' modifications to the file) I understand that you might not want that maintenance burden, however it seems like the network-manager maintainers might not want that maintenance burden either. I think the burden concern is over-made here. This is not a case of "this init script has bugs that have been causing problems and no-one has fixed it", nor a bug report of the form "please write an init script". There is an extant, working init script. There are people more than happy to provide assistance should it need updating. I concede that collaborating with those people is non-zero effort, but this is not a case of "I want this work done and am not prepared to help do it". Regards, Matthew
Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?
Package: tech-ctte Control: block 921012 by -1 Control: block 964139 by -1 X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk Dear Technical Committee, This bug report relates specifically to bugs in the network-manager package (#921012, #964139) but has broader implications, particularly around what it means to "support the efforts of developers"[0] working on support for alternative init systems (I will talk about sysvinit here without loss of generality to other non-systemd init systems). In brief: #921012 is about changing network-manager to Depend upon "default-logind | logind" rather than libpam-systemd #964139 is about restoring the removed network-manager init script which was removed from the package. There is no suggestion that the init script was buggy Both changes are necessary for it to be possible to install network-manager on a sysvinit system; it is going to be hard to use Debian without network-manager. Both bugs have sat open for extended periods with no input from the maintainer; so I prepared an NMU and uploaded it to DELAYED/14 as well as making an MR on salsa[1]. The NMU was declined, on the basis that removing the init script was not a mistake; I'm not aware of any rationale being provided beyond that for refusing either patch. I'm afraid the effect of this is that the maintainers of this package are making it impossible for other developers to enable support of sysvinit. There are people[2] who will (and have) test compatibility changes, help with issues with sysvinit scripts, and so on, but those efforts are in effect being stonewalled. The effect of this, and equivalent behaviour in some other packages, is that it is going to be impossible to make a useful Bullseye for users who want to use sysvinit. I (and a couple of other interested parties) have approached the DPL about this matter on a number of occasions this year, and have tried to follow their advice where possible. I regret that it has proved necessary to involve the technical committee. I invite the technical committee to rule that: * The network-manager init script should be restored * Network-manager should Depend: on default-logind | logind rather than libpam-systemd * Similar init-compatibility changes should not be blocked by package maintainers unless they are defective on their own merits * These changes be made in time to be effective in Bullseye Regards, Matthew [0] From the wording of the winning option in the 2019 Init systems GR [1] https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/7 [2] e.g the mailing list debian-init-divers...@chiark.greenend.org.uk of people who are more than happy to help with this sort of thing
Re: CTTE requesting questions for DebConf20 BoF
Hi, A few thoughts, if I may: On 26/07/2020 21:37, Sean Whitton wrote: Private Discussions --- One way to solve the perception issue is to have a way for people to have private discussions with the TC. I think being able to have some private discussions with the TC could be helpful, especially if the TC is to more explicitly include mediating social problems within its remit. The risks here seem to include "the TC seems to be doing nothing because it is talking in private" "the TC becomes [seen as] a secretive cabal" and "TC only announces its decision, leaving the losing side feeling like they've not had a fair hearing". Some of those could be addressed in how decisions are announced; but "try and discuss in public as much as possible" is a tricky line to find. **Proposal 2**: Explicitly delegate the mediation task for solving social conflict between developers, when no code-of-conduct violation is in place. This could be to: a. A new group of developers b. The Community Team c. The Technical Committee. I suspect that mediation may need to be part of the TC role (rather than being done by a separate group) - as you say there are likely to be both technical and social issues at play, and trying to have them addressed by separate bodies seems likely to be messy? As mentioned, the restriction on the TC only being able to choose between options limits the work that the TC can do. It also limits the legitimity that the committee has, because it's seen as a bunch of people that just issue decisions without doing any of the work. I think the counter-point here is that if the question comes to the TC "should we do A or B" and then a TC member says "Actually, I think C is better", how does the TC (give the impression of) giving all of A B and C a fair hearing? Relatedly, if developers ask the TC "A or B", and the TC says "this isn't a ruling on A vs B; rather, we think you should consider C instead", that might well be unsatisfactory. **Proposal 4**: Modify the Constitution to allow the TC to get invoked early, clarifying how that works. Or have a separate body to invoke early for technical advice, with the TC remaining the body of last resort? Again otherwise the risk is the parties talk to the TC informally, who informally suggest a solution; one party is unhappy and wants a formal resolution, but will then feel that this is a doomed enterprise because the TC has already suggested something - where can they usefully appeal? **Proposal 5**: Abolish the TC and split it into separate roles. This would of course require changing the Constitution and there are a bunch of open questions regarding who gets to do what and how the members of each body should be elected. FWIW, I don't think this is the right answer. Regards, Matthew
Re: TC delays
On 31/08/15 08:39, Didier 'OdyX' Raboud wrote: - issues not having a "mentor" within the committee; I'd like us to try pursuing the latter idea: for each topic submitted to us, we'd put one of us in charge of "making sure the issue keeps moving": reformulating, pinging, leading, etc. That seems like a very good suggestion to me (for whatever that's worth!); the alternative would be to have a secretary or similar whose role was to do this for every topic, but for the TC it probably makes sense to distribute this role among the members. Regards, Matthew
Bug#741573: Proposed draft of ballot to resolve menu/desktop question
On 28/08/15 19:22, Sune Vuorela wrote: On Thursday 27 August 2015 18:11:56 Ian Jackson wrote: (c) be destroyed. Given that there are people who want to maintain it, I think (c) is unacceptable.[1] Unfortunately, the people who wants to maintain it are not the same people who has to carry the maintenance work (shipping, checking, fixing and managing the menu files across the packages of the distribution, which is why a) is unacceptable. I haven't seen anyone interested in working on tooling[1] to accomplish b) which leaves just c) as a possibility. That's not much comfort to folk like me who use the trad menu (I'm an FVWM user) - you're proposing getting rid of something that currently works, and leaving nothing to replace it with. Regards, Matthew
Bug#636783: supermajority bug
Ian Jackson writes:
> Russ Allbery writes ("Bug#636783: supermajority bug"):
> > Ian Jackson writes:
> > > The fix to the constitutional supermajority bug has been delayed
> > > rather. Sorry about that. I have drafted what I think is an
> > > implementation of our conclusions here and in the TC.
> >
> > > Opinions welcome.
> >
> > I haven't reviewed the wording in detail, but the general discussion and
> > intent looks right to me. Thank you for drafting this!
>
> You're welcome.
>
> I'd appreciate it if _someone_ would review the wording in detail, and
> post to say that they'd done so. (That doesn't have to be a TC
> member, of course.) It would be embarassing to have to fix this
> _again_ ...
Do you have a version of the voting-text-as-amended if this were to
pass, IYSWIM? I think that would be easier to review than putting
together current-text plus diff.
Regards,
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5b61jlqhk9@chiark.greenend.org.uk
Bug#741573: On menu systems.
Charles Plessy writes: > Over almost one year of work and discussion, including a call for comments on > the debian-devel mailing list, we have shaped a modification to the Debian > Policy that 1) incorporates the description of the FreeDesktop menu system and > its use in Debian for listing program in desktop menus and associating them > with media types, and 2) softens the wording on the Debian Menu system to > reflect that in Jessie it will be neither displayed nor installed by default > on > standard Debian installations. I'm rather non-plussed by the proposal to devalue the Debian Menu system. I use fvwm, and while for frequently-used apps I don't use the menu (instead launching them from particular keys), the Debian menu is how I both launch apps I use less frequently, and explore what I've got installed. Its comprehensive coverage means that if I'm not quite sure what application I want, I can have a bit of a browse and try things out. Any proposal that reduces the coverage of the Debian Menu seems a bad idea for me... Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5bmwgeyy5w@chiark.greenend.org.uk
