system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Control: block 921012 by -1
Hi,
It's been a while since this bug was dealt with and I was tasked with
closing
it, I'm sorry that it took so long to write this reply.
The technical committee declines to overrule the NetworkManager and
udisks2
maintainer on this matter.
Instead, by working together with the maintainer o
Dear Debian developers, maintainers etc.
I use Debian for many years. My primary and only installation for work
is unstable installed in 2003 and i updated this one *many times*. I
love Debian because of freedom from more points of view.
One PoV is possibility to choose software component which i
Sorry for the delay in responding to this, but I wanted to wait until
the technical question before the committee had arrived at a result
before replying to it.
On Thu, 19 Nov 2020 at 06:49:37 -0800, Felix Lechner wrote:
> In Debian, users of 'sysvinit' strike me as such a "disfavored class".
Thi
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 perm
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 f
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
> 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 to
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 m
> "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 long-runni
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
suggesti
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 ge
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 udisks
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 men
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 I
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
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, bu
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
events a
package working with elogind I completely agree that it would be wrong for it to
make use of the logind virtual packages.
Mark
[1] progress-linux-base-system and debian-cloud-images-packages
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075#224
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 th
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
t
Hello,
On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote:
> On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
>
>> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
>> > My reasoning is that init scripts are the end goal, and that elogind is
>> > just a symptom of that end go
> "Russ" == Russ Allbery writes:
Russ> We do drop features all the time between stable releases,
Russ> though, and generally that too is at the maintainer's
Russ> discretion. The package maintainer's normal obligation in
Russ> Debian isn't to keep everything working that prev
Sam Hartman writes:
> The issue that came up in the policy discussion is that there may be
> implications for removing an init script. As an example upgrades may
> break. In the case of NetworkManager, you might find on an upgrade from
> buster to bullseye that you no longer have network becaus
❦ 28 décembre 2020 10:32 -05, Sam Hartman:
> But for example, we have a rule that is fairly basic to our community
> that we don't break upgrades, or at least we try hard not to.
This is becoming harder and harder because we pile more and more choices
(init choice, initramfs choice, merged-usr
> "Russ" == Russ Allbery writes:
Russ> I think this clearly and unambiguously says that maintainers
Russ> can depend on unit support and drop init scripts from their
Russ> packages if they so choose, and that this choice only requires
Russ> as much justification as rejecting a
Russ Allbery writes:
> I assumed that if option B won, some
> maintainers would drop init scripts, and therefore if folks wanted to
> maintain a set of working init scripts, they'd need to look at different
> options than ensuring they were incorporated into each package.
I agree, this was my se
gregor herrmann writes:
> What surprises me in this discussion: My very broad summary of the GR
> result was "systemd is the top priority, other init systems are
> supported on a best-effort basis", and now I'm reading statements which
> sound to me like "looking into new/future/niche init system
On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> > My reasoning is that init scripts are the end goal, and that elogind is
> > just a symptom of that end goal, and that therefore talking about
> > elogind in isolation serves no p
Hello Wouter,
On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
> My reasoning is that init scripts are the end goal, and that elogind is
> just a symptom of that end goal, and that therefore talking about
> elogind in isolation serves no purpose.
The GR specifically mentions elogind and
Hi Sam,
On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst writes:
> Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> >> I think that we should either decide that
> >>
> >> 1) NetworkManager should support elogind
> >>
> >> or
> "Wouter" == Wouter Verhelst writes:
Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
>> I think that we should either decide that
>>
>> 1) NetworkManager should support elogind
>>
>> or
>>
>> 2) That we haven't seen enough development o
On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> I think that we should either decide that
>
> 1) NetworkManager should support elogind
>
> or
>
> 2) That we haven't seen enough development of alternatives to systemd
> and the project consensus on the GR has changed.
Personally, I
Elana,
Thanks for passing this on.
On Mon, Dec 21, 2020 at 03:36:45PM -0800, Elana Hashman wrote:
> Less than 1% of users are installing sysvinit-core, with a steady
> downward trend.[1]
I accept that the number of users is small, although the figures referenced omit
users of openrc and runit. I
Matthew writes:
> * 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
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 w
On Thu, Nov 19, 2020 at 09:04:00PM -0800, Elana Hashman wrote:
>
> I caution folks from speculating too much on the maintainer's
> motivations and reasoning while they haven't yet had a chance to share
> their perspective on the bug. :)
>
> From what I can see reading through both #964139 and #96
On Wed, 16 Dec 2020 11:48:52 +0100
Philip Hands wrote:
> Are Simon's suggested dependencies are better in this regard?
As far as I know
> default-logind | logind
works fine, but something like
> systemd-sysv | network-manager-nonsystemd,
won't for the same reason mentioned in my previous mes
Matthew Vernon writes:
> 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 c
On Wed, 2020-12-16 at 14:46 +, Matthew Vernon wrote:
Not is it straightforwardly clear that "alternative init systems"
should in fact be interpreted to mean "alternative init systems (but
not
sysvinit)".
The GR text mostly seems to talk about *exploring* alternatives;
continuing to maintain
> "Matthew" == Matthew Vernon writes:
Matthew> 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 explor
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-syste
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
lorenzo writes:
> Hi all,
>
>> 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
>
> Please consider that apt has issue
Hi all,
> 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
Please consider that apt has issues with or group depends/recom
I had a great discussion with Mark Hindley about this issue a few months
ago.
I'd like to summarize what I said in that discussion as input to the TC.
But I'd also like to start out by reminding us all what we said in the
GR text that we agreed to.
As one of the contributors to that text, you m
❦ 15 décembre 2020 11:14 GMT, Mark Hindley:
>> Okay, great, I now see a clearer argument in favour of dropping the init
>> script: enabling the maintainer to preemptively avoid dealing with bugs
>> which are likely to generate hostility, rather than just the idea that
>> there could be bugs which
Hello,
On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote:
> Sean and Simon,
>
> On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
>> > In the cases where the regression was accidental, ideally, the answer
>> > would be someone calmly and politely offering a tested patch, but it
>>
Sean and Simon,
On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
> > In the cases where the regression was accidental, ideally, the answer
> > would be someone calmly and politely offering a tested patch, but it
> > sadly seems equally likely to result in hostility, and I think it's
>
On Tue, Dec 15, 2020 at 09:51:56AM +, Simon McVittie wrote:
> On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote:
> > Could I just check if there's a point of common acceptability which both
> > sides of this discussion could live with?
> >
> > libpam-systemd | network-manager-nonsyste
On Mon, 14 Dec 2020 at 22:56:57 +0100, Philip Hands wrote:
> Could I just check if there's a point of common acceptability which both
> sides of this discussion could live with?
>
> libpam-systemd | network-manager-nonsystemd
Presumably this is an optimized form of what we perhaps conceptually m
Sean Whitton writes:
> It is difficult to think further about this without input from the
> maintainer as to how much this was a part of his motivation, and what
> experiences he has had led him to think in that way.
Hi All,
Could I just check if there's a point of common acceptability which bo
Hello,
On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote:
> On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
>
>> Participants in the thread who have argued on that side of the
>> discussion seem to implicitly rely on the idea that a package maintainer
>> is responsible for applyi
On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
> The dependency issue is more challenging.
As I said earlier in the thread, if we don't want to overrule on the
logind dependency, then I don't think overruling on the init script
would make any sense (whereas overruling on the logind dep
Hello Simon and others,
On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:
> If we are unable to use particular system services (in this case NM) with
> a particular non-default init system without putting extra responsibility
> on the maintainers of those system services, then I think that
Josh,
On Mon, Nov 30, 2020 at 04:24:28PM -0800, Josh Triplett wrote:
> If (hypothetically) network-manager upstream
> decided to remove those legacy fallbacks, the maintainer would then be
> in a position of either:
But that is not what this particular discussion is about. Personally, I have no
i
On Mon, 30 Nov 2020 10:55:44 + Mark Hindley wrote:
> On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote:
> > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> > > #921012 is about changing network-manager to Depend upon "default-logind |
> > > logind" rather than libpa
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 1
Simon,
Thanks for your clear and insightful comments.
On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote:
> On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> > #921012 is about changing network-manager to Depend upon "default-logind |
> > logind" rather than libpam-system
On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> #921012 is about changing network-manager to Depend upon "default-logind |
> logind" rather than libpam-systemd
This is a change that is *sometimes* appropriate, but sometimes not,
depending on what facility the dependent package inten
On Sat, 21 Nov 2020 at 10:47:17 +0200, Wouter Verhelst wrote:
> On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> > 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)
>
> This
On Thu, 19 Nov 2020 at 21:04:00 -0800, Elana Hashman wrote:
> It would be much appreciated if Michael Biebl or another maintainer from
> the Utopia team could add some context here.
Most of the people in the pkg-utopia team are not active contributors to
most of its packages, so I don't think soli
On Thu, 19 Nov 2020 at 11:40:20 +, Ian Jackson wrote:
> My view is
> that the behaviour seen in #921012 and #964139 is an outrage
I don't think this is constructive, and if a package's maintainer doesn't
want to enter into conversations, this doesn't seem like an approach
that will change thei
Some procedural points, without going into the merits of the technical
committee doing as you ask or not:
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
On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote:
> I don't think this is very common. Init scripts are very specific to a
> distribution. A Debian init script cannot be used for Redhat. A SUSE
> init script does not work with Redhat. I find doubtful that the
> compatibility would be bet
❦ 19 novembre 2020 09:04 GMT, Matthew Vernon:
> 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.
I don't think this is very common. Init scripts are very specific to a
distribution. A Debian
On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> [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-suppo
On Thu, Nov 19, 2020 at 04:20:46PM -0800, Tianon Gravi wrote:
>
> On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote:
> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> > Even if someone else offers to
(Going to leave my own opinions on the underlying discussion here
aside, but wanted to highlight/echo this bit:)
On Wed, 18 Nov 2020 at 23:33, Josh Triplett wrote:
> Any inclusion of work into a package necessitates *some* amount of
> development and packaging resources by the maintainer of that
On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton
wrote:
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > First, as a point of order (for which some authoritative guidance from
> > the Secretary, CCed, would potentially prove useful): while the
> > technical committee is empowered to h
[I have consolidated responses to multiple bits of quoted text here, in
an effort to consolidate responses to variations on the same points, in
the hopes that doing so will avoid proliferating variations on a common
theme.
Also, the title of this bug itself presumes a disputed point of view.]
On
On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton
wrote:
> Hello,
>
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > I'd also like to address one other issue here. It would be easy to
> > hypothesize, at this point, that some additional communication (or more
> > verbose communication
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> First, as a point of order (for which some authoritative guidance from
> the Secretary, CCed, would potentially prove useful): while the
> technical committee is empowered to handle various types of disputes (up
> to and including o
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would exp
Hello,
On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would exp
Hi,
On Wed, Nov 18, 2020 at 11:33 PM Josh Triplett wrote:
>
> I do not believe it falls within the scope of the technical committee
> to override a decision already decided by a project-wide GR
In the State of California we follow such a strict interpretation of
ballot measures. While consistent
1. Basic principles
Josh Triplett writes:
> I do not believe it falls within the scope of the technical
> committee to override a decision already decided by a project-wide
> GR,
No-one is asking the TC to override the GR. In fact, Matthew is
asking the TC to *implement* the GR.
> or to "interp
[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 in
On Wed, 18 Nov 2020 17:33:26 + Matthew Vernon wrote:
> 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 alternati
On 18.11.20 18:33, Matthew Vernon wrote:
> 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 (#
Hi,
On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon wrote:
>
> I invite the technical committee to rule that:
What a great read! This message must be among the best prepared, and
most polite, to come before the committee.
Kind regards,
Felix Lechner
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, particular
82 matches
Mail list logo
