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 +
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 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 +, 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 ijack...@chiark.greenend.org.uk writes:

 Russ Allbery writes (Bug#636783: supermajority bug):
  Ian Jackson ijack...@chiark.greenend.org.uk 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