Next meeting: Monday 23 September, 10:00 UTC

2024-09-17 Thread Matthew Vernon

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

2024-08-17 Thread Matthew Vernon

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

2024-08-06 Thread Matthew Vernon

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

2024-08-06 Thread Matthew Vernon

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

2024-08-06 Thread Matthew Vernon

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

2024-08-06 Thread Matthew Vernon

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

2024-08-02 Thread Matthew Vernon

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

2024-04-30 Thread Matthew Vernon

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

2024-02-19 Thread Matthew Vernon

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

2024-02-19 Thread Matthew Vernon

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?

2023-12-21 Thread Matthew Vernon

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

2023-09-22 Thread Matthew Vernon

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]

2023-08-27 Thread Matthew Vernon

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

2023-08-18 Thread Matthew Vernon

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

2023-08-08 Thread Matthew Vernon

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

2023-07-14 Thread Matthew Vernon
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

2023-07-04 Thread Matthew Vernon

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

2023-06-14 Thread Matthew Vernon
-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

2023-06-14 Thread Matthew Vernon
-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

2023-05-26 Thread Matthew Vernon

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

2023-05-26 Thread Matthew Vernon

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)

2023-05-25 Thread Matthew Vernon

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

2023-05-16 Thread Matthew Vernon
-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)

2023-05-15 Thread Matthew Vernon

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

2023-04-25 Thread Matthew Vernon

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

2023-04-23 Thread Matthew Vernon

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

2023-03-14 Thread Matthew Vernon

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

2023-01-15 Thread Matthew Vernon

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

2023-01-07 Thread Matthew Vernon

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

2022-12-06 Thread Matthew Vernon

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

2022-11-25 Thread Matthew Vernon

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

2022-09-27 Thread Matthew Vernon

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

2022-09-10 Thread Matthew Vernon

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

2022-07-22 Thread Matthew Vernon

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

2022-06-21 Thread Matthew Vernon

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"

2022-06-07 Thread Matthew Vernon

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

2022-05-10 Thread Matthew Vernon

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

2022-05-02 Thread Matthew Vernon

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

2022-04-29 Thread Matthew Vernon

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

2022-04-20 Thread Matthew Vernon

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

2022-04-16 Thread Matthew Vernon

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

2022-04-15 Thread Matthew Vernon

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

2022-04-15 Thread Matthew Vernon

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

2022-04-14 Thread Matthew Vernon

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

2022-04-09 Thread Matthew Vernon

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

2022-04-05 Thread Matthew Vernon

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

2022-03-29 Thread Matthew Vernon

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

2022-03-29 Thread Matthew Vernon

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

2022-03-29 Thread Matthew Vernon

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

2022-03-25 Thread Matthew Vernon

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

2022-03-20 Thread Matthew Vernon

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

2022-01-31 Thread Matthew Vernon

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

2022-01-31 Thread Matthew Vernon



===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

2021-01-17 Thread Matthew Vernon

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

2021-01-16 Thread Matthew Vernon

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

2021-01-11 Thread Matthew Vernon

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?

2021-01-02 Thread Matthew Vernon

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?

2020-12-23 Thread Matthew Vernon

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?

2020-12-16 Thread Matthew Vernon

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?

2020-12-16 Thread Matthew Vernon

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?

2020-11-30 Thread Matthew Vernon

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?

2020-11-19 Thread Matthew Vernon

[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?

2020-11-18 Thread Matthew Vernon

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

2020-07-30 Thread Matthew Vernon

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

2015-08-31 Thread Matthew Vernon

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

2015-08-28 Thread Matthew Vernon

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

2014-06-28 Thread Matthew Vernon
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.

2014-03-25 Thread Matthew Vernon
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