On Tue, 26 Oct 2021, Clint Adams wrote:
> effort maintaining a utility which is superfluous given the
> existence of alternatives which are preferred by people who care
“It only exists if it’s in Debian.”
SCNR. But this is relevant, here.
[ overly harsh words deleted ]
bye,
//mirabilos
--
Inf
On Sat, 16 Oct 2021, Clint Adams wrote:
> It is my hope that update-shells will obsolete add-shell and remove-shell
Huh, what’s update-shells?
Hm, apparently something new in sid. Ouch. If you really wish for
that, it’ll involve painful versioned Pre-Depends and a largish
diff for backports :/ a
On Fri, 24 Sep 2021, Adrian Bunk wrote:
> and assuming the sysvinit-utils maintainers agree, that they adopt
> both the existing "which" and (at least temporarily) "tempfile".
Independent of which “which” is to be adopted, I ask for this “which”
to be one that *does* support “which -a”, which is
On Thu, 31 Aug 2017, Julien Puydt wrote:
> May I suggest to have /usr/bin/nodejs print a nice deprecation warning
> to use /usr/bin/node, and just *never* remove it?
On Thu, 31 Aug 2017, Didier 'OdyX' Raboud wrote:
> Le jeudi, 31 août 2017, 13.52:00 h CEST Jérémy Lal a écrit :
> > How about pri
On Thu, 31 Aug 2017, Jérémy Lal wrote:
> How about printing a "nice" warning explaining it would be a good idea to
> move to /usr/bin/node ?
That will break scripts that do:
x=$(nodejs somescript)
Or even ./somescript when that has a #!/usr/bin/env nodejs shebang.
> Then in next next release d
On Tue, 29 Aug 2017, Didier 'OdyX' Raboud wrote:
> I'm quite convinced that large parts of the Node.js ecosystem will cope well
> without any /usr/bin/nodejs available in stretch.
>
> So I'm not convinced it's really worth the trouble to keep it around for
> another stable release; I'd probably
Hi,
> * Restore /usr/bin/node following CTTE #862051
> Let's try to drop /usr/bin/nodejs before buster.
> Replaces and Conflicts nodejs-legacy.
> Closes: #754462.
please do NOT completely replace an ABI between releases.
Leave /usr/bin/nodejs there for at least one more release.
Th
On Fri, 28 Nov 2014, Ansgar Burchardt wrote:
> No, the ctte did not say that. We had a flamewar about that
> interpretation before.
That was almost word by word from
https://lists.debian.org/debian-devel-announce/2014/11/msg0.html
bye,
//mirabilos
--
>> Why don't you use JavaScript? I also
On Fri, 28 Nov 2014, Marco d'Itri wrote:
> On Nov 28, Svante Signell wrote:
>
> > a) Upgrades should _not_ change init: whatever is installed should be
> > kept.
> I disagree: upgrades should get the default init system unless the
> system administrator chooses otherwise.
I disagree with you,
On Fri, 28 Nov 2014, Svante Signell wrote:
> the order of pre-depends for int init package should change from
> Pre-Depends: systemd-sysv | sysvinit-core | upstart
> to
> Pre-Depends: sysvinit-core | systemd-sysv | upstart
That would probably require changes in d-i to ensure that
systemd is, inde
On Tue, 25 Nov 2014, Svante Signell wrote:
> (another partial? solution is to change order of the (pre-)depends of
> the init package, as proposed in
No, that breaks due to the bug in debootstrap’s dependency “resolver”
(see #557322, #668001, #768062) and the unwillingness of KiBi to fix
that. Th
Russ Allbery dixit:
>But when providing project-wide guidance, we have an obligation to worry
>about the error conditions as well. If multiple logind implementations do
>*not* materialize, or if they do materialize but then people lose interest
I question why logind is needed in the first place.
Ian Jackson dixit:
>(and to use a helper tool for daemonisation).
mksh -T- -c 'exec daemond arg1 …'
bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz i
Olav Vitters dixit:
>References to religion and second world war? Really? You expect people
>to listen to such bullshit?
Also, as a German, I’m affronted by Craig’s comment. After all,
Hitler was Austrian, not even German.
>Fairly easy to assign everything to conspiracy and say systemd
>advocate
Didier 'OdyX' Raboud dixit:
>Now, I think there is currently a shared agreement in Debian that
>
>"all Debian packages (unless there's a good reason) should run on
> sysvinit + Linux + amd64 , support outside that is best-effort"
Eh, no! Debian is the universal OS, and it has quite a numb
Colin Watson dixit:
>> https://lists.debian.org/debian-devel/2014/02/msg00106.html
>
>Various developers certainly continue to work enthusiastically on their
>preferred approaches, but that's not really the same as "efforts to
>resolve [the issue] via consensus".
But is not diversity some sort of
Colin Watson dixit:
>("Decide any technical matter where Developers' jurisdictions overlap").
I think it is not up to the d-i people to decide on the init system
anyway – especially as not d-i but debootstrap is the canonical way
to install Debian… and debootstrap goes by whatever ftp-masters put
Jason A. Donenfeld dixit:
>Question B. Debian will allow alternative, non-default, init systems on Linux:
No, as Ian already explained this will not permit people
to vote, for example:
A with multiple > B with multiple > B alone > NOTA > A alone
bye,
//mirabilos
--
Beware of ritual lest you f
Matthias Klumpp dixit:
>What would happen if we adopted systemd?
The project would lose (a different set of) contributors and users.
The OSS ecosystem would lose, vendor-lock-in would ensue in a way
even worse than the FSF does, and the remnants of Unix/GNU in Debian
would die, to be replaced by
Matthias Klumpp dixit:
>2014-01-30 ChaosEsque Team :
>> [bullshit]
This was actually *not* bullshit. The delivery of most of the
content could use some polishing, but the content is a(n inconvenient)
truth.
>Wasn't there some kind of a ban applied here?
Apparently not, but it’s better that way
Matthias Klumpp dixit:
>No, Josselin is right: GNOME *does not* work without services provided
>by systemd. He never said that - given some amount of work - it can't
Hum, we can always add “remove GNOME (3) from Debian” to the
list of GR or TC points to consider (this *has* been suggested
earlier
Olav Vitters dixit:
>IMO other init systems should provide the interfaces which GNOME
>requires. It is not up to GNOME to provide these. That or takeup
There is a lot wrong with that statement.
Imagine you’re working on/with a software FOO that is not yet
packaged in Debian. Say it comes from th
Michael Gilbert dixit:
>Why not avoid impeding progress and just let gnome do what it needs to
>work the way it wants, which would involve depending on the right
Excuse me, why is GNOME, specifically, being allowed to “do what it
wants”, in this case? Imagine other software with a more-or-less
le
piruthiviraj natarajan dixit:
>This thing about 'Linux/Debian is all about choice' reminds me of the
>famous post I read in the past about choice.
>
>http://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
That is about Fedora, and about Linux, but *not* about Debian.
Debian
Anthony Towns dixit:
> [default-init] Having examined the features and bugs of the various
>init systems packaged for Debian, the default init system for jessie
>for Linux architectures shall be {OpenRC | systemd | upstart |
Please do not forget sysv-rc here.
>determined by a GR}.
> [systemd-
Noa Resare dixit:
>- We believe that systemd will have the stronger community momentum moving
>forward when it comes to seeing close integration between modern init
>system features and upstream projects.
I believe that this is precisely a reason *against* choosing systemd,
as it leads to monocul
Christoph Anton Mitterer dixit:
>- At most upstream projects (the kernel, wayland, X, etc. pp.) people
>seem to at least think first about systemd...
Only those that have strong ties to Poettering, Red Hat, GNOME.
>if they support upstart at all.
Right, upstart is, right now, a Canonical soluti
Moritz Muehlenhoff dixit:
>FreeBSD upstream isn't a desktop OS and never will be, there're just too
>many deficiencies (e.g. lack of dbus
Eh, excuse me! It’s obviously possible to run a desktop without dbus!
In fact, this is a feature, in my eyes.
>limited hardware support
Oh c’mon. Linux does
Uoti Urpala dixit:
>They have had an overall negative effect on people working on Linux
>within Debian and people creating derivatives.
Besides what Russ said: Debian isn’t about Linux.
Debian is the universal operating system.
bye,
//mirabilos
--
18:47⎜ well channels… you see, I see everything
Steven Chamberlain dixit:
>Then he gives a preference for Debian's own insserv and startpar. It
>allows for boot order to be fixed (after running insserv once, the same
>/etc/rc2.d/Sxx numbering may be rsync'd out to many machines). startpar
I would like to express a preference for one init sys
Steven Chamberlain dixit:
>Actually, even if they forked in the same order every time, they might
>not be *ready* in the same order. That would be the rationale for
>readiness protocols and other features of the more complex init systems.
Strong disagree. This actually is a bug in the initscript
Vincent Lefevre dixit:
>Well, the scripts may be started sequentially, but this doesn't mean
>that the daemons will be and always in the same order. And they don't,
>as shows in the following log:
That’s due to the (now default with sysv-rc) use of parallel boot
in combination with insserv. It us
Okay,
and here’s the reasoning for “sticking to an antiquated” init system:
I fully believe that Debian should be as flexible as possible
when meeting users’ needs. There is already a big downstream
running on Upstart, and I believe that, given the assumption
that we need to decide on one/the ini
Ondřej Surý dixit:
>then please submit your arguments directly there.
Sure.
>> Please stick to your side and make arguments for _your_ case, not
My “case” here is to ask CTTE to not make any decision and defer
to the Developers as whole, by means of a GR. As Guillem wrote:
| stop doing work du
Paul Tagliamonte dixit:
>It may be, but it's not for the project. Let's let this bug be, and
>have the tech cttie decide on *the* init system for Debian. If you want
No, this must really really be decided first.
bye,
//mirabilos
--
Beware of ritual lest you forget the meaning behind it.
yeah
Paul Tagliamonte dixit:
>please vote on and decide on the default init system for Debian.
It’s not (just) about the _default_ but also on whether we will
force this default init system onto *all* our users, or whether
we commit to support more than one, and if so, how.
This is an *important* dis
On Tue, 10 Jul 2012, Thorsten Glaser wrote:
> > Right now I am waiting for the judgement of the tech-ctte regarding
> > nodejs. See bug#614907.
>
> Ah. Luckily, that’s almost resolved.
It has been resolved for days now, would please someone
implement the solution? I can, as
On Tue, 10 Jul 2012, Jonas Smedegaard wrote:
> Because it performs worse, which makes it less used in general, which
> makes it less tested, which makes it less trustworthy. I thought that
> was already clarified at bug#679665. Does it make sense now?
Thanks, yes.
> It is helpful that you in
On Tue, 10 Jul 2012, Jonas Smedegaard wrote:
> Right now I am waiting for the judgement of the tech-ctte regarding
> nodejs. See bug#614907.
Ah. Luckily, that’s almost resolved.
> I am concerned about switching compressor - see the discussion at
> bug#679665.
I see. (But yui was used before,
Hi again,
fact is that the udev maintainer uses an idiom which is broken,
so I think your resolution 1 is flawed.
I propose that it be changed to have udev use #!/bin/dash (in
sid) and #!/bin/bash (in lenny) instead of #!/bin/sh as shebang
line, since otherwise, no action at all would be taken.
pgp0I83CpKBCG.pgp
Description: PGP message
Steve Langasek dixit:
>You're aware that [ (test) is also not listed as a mandatory shell built-in,
>according to the POSIX reference you've cited?
Interesting.
>So from that perspective, there are lots of POSIX failures. Do you think we
>should treat [ specially, but not printf, because mksh h
pgp7MfTg5w0bg.pgp
Description: PGP message
43 matches
Mail list logo
