Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Sam Hartman
General arguments about how the TC should conduct its business do not belong on this bug. I'd appreciate it if replies to this message are directed to a different place than this bug. We've established that the TC is operating consistently both with its historical process and with currently

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Felix Lechner
Hi, On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi wrote: > > the ability to talk privately with the committee is something CTTE has > allowed for a long time Debian has many great traditions, but the Magna Carta is much older. I found a great article about it ([1], p. 5): "the simple human need

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-27 Thread Gunnar Wolf
Sandro Tosi dijo [Tue, Jan 26, 2021 at 08:47:22PM -0500]: > the ability to talk privately with the committee is something CTTE has > allowed for a long time; it's a two-sided coin: it can prevent heated > exchanges, but it can also leave a sour taste in the petitioner's > mouth. > > While i would

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-26 Thread Sandro Tosi
> Here, the situation here is more complicated. There was a private > communication with the committee, but such side conversations are > unfair: How can Matthew ever feel that justice was served? I would > personally not feel closure unless I saw all such communications and > had an opportunity

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-20 Thread Felix Lechner
Hi, Sorry to comment so late. A meeting about this bug may already be in progress. On Sat, Jan 16, 2021 at 4:15 AM Matthew Vernon wrote: > > 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. In

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-18 Thread Sam Hartman
> "Russ" == Russ Allbery writes: >> 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. Russ> I understand (oh, boy, do I ever) how strained relationships Russ> are after the

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

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-17 Thread Andreas Henriksson
Hello Matthew Vernon, On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote: > [...], 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 [...] Possibly

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-16 Thread Russ Allbery
Matthew Vernon writes: > 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

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

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-15 Thread Gunnar Wolf
Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]: > > 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

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Sean Whitton
Hello, On Tue 12 Jan 2021 at 01:53PM +02, Wouter Verhelst wrote: > Maybe talk to debian-policy to come up with some wording to be added to > either the developer's reference or policy that discourages dropping > init scripts, but encourages talking to the maintainers of > orphan-sysvinit-scripts

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Wouter Verhelst
On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote: > [0] to that end, orphan-sysvinit-scripts is in NEW, Glad you're taking that route. I had been thinking of other things to suggest that would make your life easier while allowing maintainers to drop init scripts if they so desire,

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

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-11 Thread Mark Hindley
Simon, On Sun, Jan 10, 2021 at 08:03:18PM +, Simon McVittie wrote: > I wouldn't want to give a ruling that would be interpreted as precedent to > (effectively) overrule multiple maintainer decisions (whether they're > decisions by a single maintainer in multiple packages, or multiple >

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-10 Thread Simon McVittie
On Sat, 02 Jan 2021 at 18:36:23 +, Matthew Vernon wrote: > While [lowering NM's dependency on libpam-systemd from Depends to > Recommends] does address the co-installability of network-manager with > elogind, I would like you to still say something officially about the issue, > please, since