> From: Andrei POPESCU
>Why bother when a simple pin will do the job:
Because installing a package is cleaner than modifying
some configuration file, and because APT pinning is
sometimes fragile and can have interactions with other
pinning stanzas and is something IMHO reserved for the
local a
> From: Guido =?iso-8859-1?Q?G=FCnther?=
>GTK+3 supports themes
GTK/GNOME people have stated numerous times that they do not want them.
>. This
>> is a perfectly fine job for a derivate or Pure Blend: to provide a
>> polished system that serves one use case well.
>
>Proper integration certain
Steve Langasek dixit:
>On Tue, May 13, 2014 at 08:23:55PM +0000, Thorsten Glaser wrote:
>> >service foo works across Linux distributions, with or without
>> >systemd, and does the right thing.
>
>> It doesn’t work on lenny, and (unless service /etc/init.d/foo is
&g
Thibaut Paumard dixit:
>People who run testing or unstable should be prepared to deal with
>occasional breakages.
With occasional *temporary* breakages, such as packages disappearing
(in testing) or needing to be set on “hold” temporarily, yes.
With the init system suddenly be swapped out under
Russ Allbery dixit:
>> • no /etc/init.d/$foo (to tabcomplete, no less!) any more
>
>I've been telling people to stop using this for years. You should stop
>using this too, regardless of what init system you're using, since it
>doesn't sanitize environment variables. You leak all kinds of crap fr
Thijs Kinkhorst dixit:
>On Tue, May 13, 2014 18:03, Russ Allbery wrote:
>> You're aware, right, that my primary background is with enterprise use,
>> and I've been doing large-site systems administration for twenty years?
>>
>> systemd is a godsend with basically no downside for our enterprise us
Cyril Brulebois dixit:
>The sad thing is: almost nobody reads the release notes.
Many people run testing or unstable, so there are no “release”s
to have notes for, either… (but yes, even those who run stable
don’t).
bye,
//mirabilos
--
“When udev happened I wrote mdev.”
-- Rob Landley i
Didier 'OdyX' Raboud dixit:
>Le mardi, 13 mai 2014, 16.25:31 Thorsten Glaser a écrit :
>> On Mon, 12 May 2014, Tollef Fog Heen wrote:
>> > Are you aware that Joss isn't a systemd maintainer? (He's one of
>> > the GNOME maintainers.)
>>
>
On Mon, 12 May 2014, Tollef Fog Heen wrote:
> ]] Andrew Shadura
> > This sort of behaviour is precisely why so many people not only
> > dislike systemd, but also it's maintainers.
>
> Are you aware that Joss isn't a systemd maintainer? (He's one of the
> GNOME maintainers.)
There’s not really a
On Tue, 13 May 2014, Josselin Mouette wrote:
> My opinion is that many users are migrating away from Debian because we
> are unable to make decisions on important technical topics and leave
> them with 3 different setups, none of which actually work, instead of
> providing one that is correctly po
On Mon, 12 May 2014, James Cloos wrote:
> Note that you cannot just strip colour profiles from image containers.
>
> Doing so changes the output.
>
> You'd have to replace the profile with a Free equivilent. Or, if no
> free equivilent is available, edit the image to match a Free profile.
Can yo
On Mon, 12 May 2014, Noah Meyerhans wrote:
> On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
> >What about the task of running a short program for a brief duration, e.g.
> >from cron scripts? Is using su considered acceptable?
I thought s-s-d is for starting dæmons, not for th
On Sat, 10 May 2014, Bas Wijnen wrote:
> > So please get dirmngr fixed instead of blaming systemd/logind.
>
> This is the part you should _NEVER_ do. It is YOUR responsibitiliy, as a
> maintainer (you are the maintainer, right?), to make sure that a bug that is
> reported in the wrong place gets
On Fri, 9 May 2014, Steve Langasek wrote:
> > > >> ii systemd 204-10
> > > >> ii systemd-sysv 204-10
>
> > You can purge them. Install sysvinit-core at the same time.
>
> This is unconstructive advice.
No, it is not, for someone who wants s
On Sun, 11 May 2014, Marc Haber wrote:
> On Sat, 10 May 2014 22:13:01 +0200, Matthias Urlichs
> wrote:
> >I also would not expect an "end user" to add "su foo -c /do/whatever" to
> >/etc/rc.local. Your opinion may differ, that's OK.
>
> Especially people who are not as Debian-centric as we are t
Tollef Fog Heen wrote:
>> Changes to the default init system should not affect existing setups.
>
>Were that true, it would be different to how we handle changes in other
>defaults.
A default is a default because it is only applies when the
sysadmin defaults to it, when the sysadmin defaults maki
On Fri, 9 May 2014, Andrew Shadura wrote:
> On 9 May 2014 14:32, Tollef Fog Heen wrote:
> >> Well, I've not been asked if I wanted to switch to systemd based boot
> >> when upgrading. I think this is a bug in init system choice and should
> >> be reported.
ACK.
I noticed this because I have a p
On Thu, 8 May 2014, Paul Wise wrote:
> /usr/share/doc/doxygen/README.jquery
This is a bug in doxygen. Replacing the embedded jquery copy
in the Debian package shipping it with a link to the jquery
version in Debian should be the right thing to do. Maybe this
entire technology behind doxygen needs
On Wed, 7 May 2014, Ian Jackson wrote:
> Yes. But this isn't as bad as you think, because the source
> availability requirement exists only if you modify the AGPL'd
> software.
Which you may want to do, in order to patch a security issue
you just found, locally, before filing it upstream.
Or be
On Sun, 4 May 2014, Timo Weingärtner wrote:
> The installer already asks whether to enable non-free repositories. Perhaps
This could get a loud warning, yes.
> the warning could be more verbose differentiating between open-source-but-non-
> free (GFDL etc.) and closed-source.
There is no diffe
Matthias Urlichs dixit:
>Thorsten Glaser:
>> Did you *read* how upstream answered the one thing I *did* forward
>> myself?
>>
>For the benefit of the other readers here, would you please supply a
>reference URL?
Sure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bu
Sune Vuorela dixit:
>On 2014-05-03, Thorsten Glaser wrote:
>> This does not, of course, prevent people like the Mesa maintainers
>> from refusing to do it. I’ve got no idea how to enforce DevRef on
>Thank you for volunteering to help forwarding bug reports for the mesa
Ben Finney dixit:
>That is, to answer the question “what is the source form of the work”,
>we need a definition that answers in terms of “such-and-so form of the
>work”.
Well, the one you’d want to have when you were to modify (think, fork)
the original work in question.
In the autoconf case: ev
Nikolaus Rath dixit:
>Ah, wait. So is the requirement that we ship the source to all files in
>the source package, or is the requirement to ship the source to all
>files in the source package that are used to generate the binary
>package?
The former, plus…
>Paul Tagliamonte writes:
>> Yes. Ple
Russ Allbery dixit:
>Svante Signell writes:
>
>> Does the Debian guidelines give any hints on who is responsible to
>> report a patch upstream? Is it the bug submitters or the Debian package
>> maintainers responsibility (in addition to eventually apply them to the
>> packages)?
>
>I don't think
Henrique de Moraes Holschuh dixit:
>On Wed, 30 Apr 2014, Pierre wrote:
>> When /tmp is configured as noexec (for example /tmp in RAM), some
>> scripts fail on package update.
[…]
>It may look like it is working, but we don't properly support it,
Sounds like a release goal for jessie+1 or jessie
On Tue, 29 Apr 2014, Jakub Wilk wrote:
> > > A wide misconception. Chroots are easily implemented and add security
^^^
> > > almost for free (often /dev/log is all that is needed) and so can be used
> > > by default without an
On Tue, 29 Apr 2014, Steven Chamberlain wrote:
> On Mon, 28 Apr 2014 16:52:10 + (UTC), daThorsten Glaser wrote:
> > For their OpenSSL fork, specifically, they rely on some system
> > properties such as their RNG’s behaviour way too much [...]
>
> I would think Linux and FreeBSD have much bett
Kevin Chadwick yahoo.co.uk> writes:
> > > > > Security and chroots aren't things I would associate, you need
better.
>
> A wide misconception. Chroots are easily implemented and add security
> almost for free (often /dev/log is all that is needed) and so can be
> used by default without any pote
Tollef Fog Heen err.no> writes:
> > “openvt” is used to start a program on a new virtual terminal, and
according to
> > its manual page, it has been renamed from “open” at the end of the XXth
> > century. The changelog of the kbd package confirms the impression that
it
> > has been phased out ef
Marko Randjelovic eunet.rs> writes:
> On Tue, 29 Apr 2014 11:35:26 +0800
> Paul Wise debian.org> wrote:
> > On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote:
> >
> > > - security patches should be clearly marked as such in every *.patch
> > > file
> >
> > That sounds like a good idea,
Shachar Shemesh debian.org> writes:
> My understanding of things is that undefined behaviors are fairly
> common, and almost always benign. Look at the following code:
> int add( int a, int b )
> {
> return a+b;
> }
> Do you really want to get a "Warning: signed in
Jonas Smedegaard jones.dk> writes:
> Please elaborate what you mean can "trigger later".
>
> Simple example: Choosing via debconf to have adduser create homes below
> "/srv/home" instead of the default "/home".
Ah, sure.
Admin installs adduser. adduser defaults to /home.
Admin now installs yo
Shachar Shemesh debian.org> writes:
> the changes there is a runtime check for undefined behavior. Just
> compile with -fsanitize=undefined, and your program will crash with
> log if it performs an operation that C/C++ considers to be
> undefined.
This does not help. At all.
Con
Jonas Smedegaard jones.dk> writes:
> >> How to reconfigure debconf from postinst of another package?
I also thought that was absolutely forbidden.
> > Note that, if, as an admin, I explicitly choose an option in debconf
> > and then, latter, another package overwrite my choice (or even
>
Stuart Prescott debian.org> writes:
> Unfortunately, the people who understand multiarch well enough to write it
> up for policy haven't done so which leaves us with no normative
> documentation in policy for the the Multi-Arch field in Packages, no
> description of how the package manager sho
Wookey dixit:
> +++ Paul Wise [2014-04-16 19:51 +0800]:
> > On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote:
> >
> > > What some people here try to do, update config.guess and related files,
> > > is, IMHO, just a hack. Sure, it will just work, but only for us (Debian).
[…]
> > Other distrib
Pirate Praveen gmail.com> writes:
> I love democracy, where everyone has a say and have a chance to make
> the changes they want
This sentence is *so* wrong…
bye,
//mirabilos (usually part of the minority, no matter where)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wit
On Fri, 11 Apr 2014, Ansgar Burchardt wrote:
> On 04/11/2014 12:42, Ian Jackson wrote:
> > What people expect is that the compiler compiles programs the way C
> > was traditionally compiled.
Actually, I think we need to go further. We need a programming
language (with at least two compiler imple
On Tue, 15 Apr 2014, Dmitry Smirnov wrote:
> On Mon, 14 Apr 2014 15:40:00 Thorsten Glaser wrote:
> > • even if I disagree with maintainers (things like bugs
> > in mc), I can mostly live with it (although, when I was
> > m68k porter, some pissed me *seriously* off)
[…]
Alberto Salvia Novella dixit:
> Why you choose to develop in Debian over any other distribution?
First of: why “instead”? Many developers are active in other
distributions and/or operating systems. So am I.
I came to Debian for a number of reasons:
• it was the last GNU/Linux I used before swit
Ian Jackson dixit:
>> If the architecture uses two's complement, however, then the code is
>> correct.
>
>Unfortunately adversarial optimisation by modern compilers means that
>this kind of reasoning is no longer valid.
>
>The compiler might easily see that your code unconditionally performs
>a co
On Tue, 8 Apr 2014, Ian Jackson wrote:
> > ISTR reading somewhere that Depends do not mean that the dependency is
> > always configured before the package depending on it is configured, but
> > only that it once was configured successfully.
>
> This is true. If A -Depends-> B and A is "installed
On Fri, 4 Apr 2014, Ansgar Burchardt wrote:
> I'm interested where POSIX says what you are sure it says (that the
> shell is responsible for evaluating #!).
I said the shell is supposed to, and suggested to search POSIX, but
I wasn’t sure that it was POSIX standardised, and never said so. As
you
On Fri, 4 Apr 2014, Chow Loong Jin wrote:
> Are you sure about this?
Yes.
> Some references would be helpful. I can't seem to find anything on this
> through
Sure. I’ve patched mksh to use “#?” ipv “#!” as shebang, to
simulate a kernel not supporting the shebang:
Index: exec.c
===
Chow Loong Jin debian.org> writes:
> For the record, there's CONFIG_BINFMT_SCRIPT, which when disabled, causes
all
> #! scripts to be run under /bin/sh unconditionally.
>
> *everything* runs under /bin/sh, including Perl, Python, and Bash scripts.
Yes, and /bin/sh is supposed to parse the sheba
Ondrej Riha dixit:
>linux-headers-2.6-* and linux-image-2.6-* and linux-doc-2.6-*
These packages no longer exist, they have been removed from unstable.
Debian-Ports mini-dak does not generally follow this sort¹ of removals
automatically, so they will eventually be cleaned up manually.
The packa
Norbert Preining logic.at> writes:
> In the trigger program we already check that texlive base is in proper
> state (ii in dpkg listing), but that seems not to be enough.
ISTR reading somewhere that Depends do not mean that the dependency is
always configured before the package depending on it i
Adam Borowski angband.pl> writes:
> You don't need to jump through those multistrap hoops anymore. You need
to
> recompile the kernel with CONFIG_X86_X32=y, but after that you can use any
Could this *please* become the default in linux-image-3.14-1-amd64?
Thanks,
//mirabilos, eagerly awaiting
Paul Wise debian.org> writes:
> On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote:
>
> > Alternatively, we could make NetworkManager the default.
> > It is already here, it works, and it doesn’t have such problems.
>
> Or systemd-networkd.
I surely hope the both of you are kidding.
bye,
Simon McVittie debian.org> writes:
> (I would recommend that porters doing manual builds use sbuild if at all
> possible, though, to be as close as possible to what a buildd would have
> done.)
On the other hand, porters are often packagers, and many packagers are
much more familiar with cowbuil
On Mon, 24 Mar 2014, Kevin Toppins wrote:
> -> Debian needs to *cut all ties* to systemd
[…]
> -> revert every program systemd took over to its pre-systemd state
>
> -> cut your losses while you still can technically achieve a reversion
Seconded (especially the last bullet point).
bye,
//mi
Joachim Breitner debian.org> writes:
> The minified file contains a copyright header, and the license is MIT,
> so I believe shipping jquery-1.11.0.min.js without query-1.11.0.js is
It’s legal, but it’s not allowed because it breaks the *promise* we
(Debian) do to our users/downstreams.
That’s
Joachim Breitner debian.org> writes:
> Before this thread gets too long and we hear too many opinion from
> people don’t have a say in this (like me), I’d like to hear an official
> statement from the ftp-team on the question:
>
> Does Debian tolerate files in upstream tarballs that are
Simon McVittie debian.org> writes:
> tl;dr: extensive discussion of why this mistake is easy to make and
> why sbuild can't trivially fix it; Raphael Hertzog suggests making
Allowing things with mismatching changelog vs. distribution into the
archive will introduce problems by the way, since cow
Thomas Goirand debian.org> writes:
> But when the package isn't in stable (yet), and is only in Sid/testing,
> how long should a transition package last? Until the next stable
> release? IMO it'd be bad to have a transition package introduced in the
> new Stable if the package wasn't in old-stabl
Carlos Alberto Lopez Perez igalia.com> writes:
> On 13/02/14 22:10, Dimitri John Ledkov wrote:
> > All that's needed, I guess, is for someone to write a patch to dak /
> > wanna-build ... and schedule _all.deb builds on amd64 ?
> > Or if arch-restricted package, on one of the arches it will buil
Paul Tagliamonte debian.org> writes:
>
> On Fri, Feb 14, 2014 at 04:39:25PM +0100, Wouter Verhelst wrote:
> > > Are buildd people happy with humans sending their logs this way?
> >
> > Well, I am, but it's probably not my call.
>
> Which keyring does it use to validate? Can DMs send logs? Does
Sam Hartman debian.org> writes:
[ autotools ]
> I assure you, that even if you get past the being blind bit, it's still
> impossible to figure out what's going on.
And even then, even when you did the unbelievable and, say, ported libtool
to MirBSD and Interix (consuming a whole bottle of wine i
Andrey Rahmatullin wrar.name> writes:
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> Isn't that one of problems fixed by rebuilding everything on buil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Georgy Demidov dixit:
>Debian user here. This is my first and last letter about the bug
>#727708. I feel this is important to share.
http://mid.gmane.org/1393001326.916837...@f432.i.mail.ru
Thank you for sharing this. This was very appreciated, an
Wookey wookware.org> writes:
> Do I understand this correctly - that it prevents a package
> cross-binutils-0.1 to generate binaries called
> binutils-arm-linux-gnueabi-2.24-3
> binutils-arm-linux-gnueabihf-2.24-3
Actually, these packages will be buggy usually: debhelper uses
the source version
Tollef Fog Heen err.no> writes:
> ]] Jaromír Mikeš
>
> > Aha ... so these default flags are added by compiler and they are not
> > controlled by debian tools at all?
> > Can I see somewhere default flags for different archs?
>
> run gcc -dumpspecs on the different platforms and you can see the
Simon McVittie debian.org> writes:
> If we standardize on "_*" (or capital letters or whatever) for packaged
Users with capital letters sometimes cannot receive eMail correctly.
(Using _ in my packages since I think the BSDs’ approach sensible.)
> accounts, then "adduser --system" could also s
Jonas Smedegaard jones.dk> writes:
> Quoting Michael Kaserer (2014-01-08 11:00:50)
> > We are two students currently working on a research project regarding
> > motivation for contributing to Open Source projects. You can help us
> > by filling out the following web-survey, it only takes max. 2
On Mon, 6 Jan 2014, Chow Loong Jin wrote:
> Upstart doesn't directly make use of the LSB headers -- it just calls back
> onto
Ah okay, thanks for this explanation!
(I’ve switched back to sysvinit for now.)
On Sat, 4 Jan 2014, Roger Leigh wrote:
> It might be safer to do something like this:
On Sun, 5 Jan 2014, Clint Adams wrote:
> because any code under this license would be deliberately incompatible
> with anything else FOR NO GOOD REASON.
Uhm, then stop advocating the GNU GPL, which is deliberately incompatible
with anything else FOR NO GOOD REASON.
bye,
//mirabilos
--
[16:04:33
On Fri, 3 Jan 2014, Roger Leigh wrote:
> If file-rc and/or the maintainer scripts somehow restored the links
> incorrectly, then insserv will ignore the header and preserve your
> customisations
Hm. I can’t remember *ever* doing *any* customisations.
I normally just put an “exit 0” below the sheb
Roger Leigh codelibre.net> writes:
> Did you try running insserv by hand to restore the links? Did
> the maintainer scripts restore any of the links for you?
I’ve tried both (unsure if what I tried was right; dpkg-reconfigure
initscripts and insserv with most combinations of -d, -f, the name
of
On Fri, 3 Jan 2014, Josselin Mouette wrote:
> Le vendredi 03 janvier 2014 à 10:20 +0000, Thorsten Glaser a écrit :
> > I was running file-rc
>
> > And: why did this happen in the first place?
>
> I think you answered to that question yourself.
Yes, with a simple BSD-s
Hi *,
after a dist-upgrade, my sid system wouldn’t boot at all any more: no
network (because udev didn’t rename eth1 to eth0), read-only filesystem,
I was dumped into a root shell after being asked for the root password,
but by then the filesystem was read-write.
I was running file-rc and decided
Samuel Thibault debian.org> writes:
> > Isn’t there a GRUB2 port for Xen now?
>
> Yes, and it will be part of the grub2 source code, but that's not
> released yet.
But it’s in Debian already (which is where I saw it before writing
the above posting):
http://packages.debian.org/experimental/gru
Steve Langasek dixit:
>of GPLv3, and explicitly did not. In fact, the system library exception is
>now defined even more narrowly than for GPLv2, so that it now covers only
>language runtime libraries. I think this was a poor choice on the FSF's
Is it really?
| A "Standard Interface" means an
Philipp Kern wrote:
>â¦and Xen in general. I agree with this assessment.
Isnât there a GRUB2 port for Xen now?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/l8n
Steve Langasek dixit:
>(For values of "permanently" that include "we now have two implementations
>of sh in Essential, because no one has done the work to let us get rid of
>bash".)
Maybe because the offered alternative sucks so much.
I’d happily split mksh into mksh and mksh-static, make
the la
Simon McVittie wrote:
>As far as I can see, changing from (libtiffN-dev Provides libtiff-dev,
>libtiff(N+1)-dev does not) to the other way round has an inherent race
Hm indeed. Makes me wonder whether it would not be better to make
libtiff-dev the real package and abandon libtiffN-dev altogether.
On Thu, 5 Dec 2013, Jay Berkenbilt wrote:
> * If your package build-depends on libtiff5-dev, you don't HAVE to do
>anything, but you may be helping yourself in the future if you change
>the build dependency to libtiff-dev (>> 4.0.3-6~).
Uhm, I have a rather general question here.
libtiff
On Wed, 4 Dec 2013, Tollef Fog Heen wrote:
> Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all
> that serial console + networked power switch? I suspect Debian would be
Isn’t “serial console + networked power switch” preferable?
See http://fish2.com/ipmi/ (“IPMI: Freight
Ingo Jürgensmann dixit:
>Because I didn't want to do any packaging at all, it became impossible
>at some point until DMs and such were introduced. Somewhen I decided
It’s even better now: we have “non-packaging developers”, e.g. people
who work on, say, exclusively the press team.
>to apply, but
>> I don't really see the point, as it is already the case. Actually most
>> of the uploaders in debian-ports are non-DD, and it is something that
>> should not be lost in the transfer either.
>
>If debian-ports is converted to official Debian service, then all the
>user database is extracted from
KiBi wrote:
>Dmitrijs Ledkovs (2013-12-03):
>> What is the opportunity cost here? Are there no machine available
>> within budget? If that's the case, what's the current budget that
>> Debian Project can contribute, and what's the shortage to buy ARM
>> 64-bit hardware *today*?
>arm64 hardware
>> Wouter Verhelst (2013-12-02):
>>> It will revert to throwaway chroots the minute LVM gets unbroken in
>>> stable.
>FWIW, ARM buildds are quite fine on stable LVM snaphots.
Hrm, ARM is little-endian, right?
LVM snapshots are apparently (according to the buildd
maintainers who run that) unstab
On Wed, 27 Nov 2013, Steven Chamberlain wrote:
> I was referring to the sysvinit program/package, which I think is made
> obsolete by OpenRC; the original SysV init scripts could still be used
> by OpenRC.
I think you’re confusing sysvinit with sysv-rc here.
This was never about the sysvinit *p
Matthias Urlichs dixit:
>A systemd service file is five lines.
Someone has shown that this works with sysvinit as well,
if you use #!/path/to/some-helper as shebang.
>Want more features in your init script? Like, say, a reliable way to
>figure out if any parts of your server are still running af
ольга крыжановская dixit:
>Thorsten, thanks for the review, but the package was not intended for
>official review yet. I only send it around, to find a mentor, and then
>weed out the bugs, one by one, and some one else leaked that posting
>to debian-devel, before the work was ready.
Ah, okay. But
Thorsten Glaser mirbsd.de> writes:
> No, it isn’t – but you could build-depend on mksh, if the script
> can be run with it (haven’t tested it), possibly with a few changes
OK, I’ve tried with the following patch:
diff -Nru ksh-93v-20131010/debian/control ksh-93v-20131010/debian/contro
Giovanni Rapagnani ideanet.be> writes:
> - the script is executed using /usr/bin/ksh. Is it fine to have a build
> dependency on the package we are about to build? If it is, the build
No, it isn’t – but you could build-depend on mksh, if the script
can be run with it (haven’t tested it), possibl
On Wed, 6 Nov 2013, Gergely Nagy wrote:
> Please no. That's a maintenance nightmare. I'm fine with one on
> GNU/Linux, another everywhere else (but I'll treat everything else as
> secondary), but supporting all of them, everywhere they're available, is
> madness.
And:
> Freedom of choice remains
On Tue, 5 Nov 2013, Paul Tagliamonte wrote:
> > First of all, I do not agree Debian community is hurt because of
> > split about init system,
>
> I disagree strongly. Please read through every flame thread over the
> last 4 years and try to say this with a straight face.
That’s why I say let’s j
Niels Thykier dixit:
>Then there are more concrete things like ruby's test suite seg. faulting
>on ia64 (#593141), ld seg. faulting with --as-needed on ia64
And only statically linked klibc-compiled executables work on IA64,
not dynamically linked ones. I’ve looked into it, but Itanic is so
massi
On Thu, 31 Oct 2013, Simon McVittie wrote:
> file-rc ships its own update-rc.d implementation (at least, according to
> the package description it does) which hopefully has the enable/disable
> subcommands.
It does, but…
> My understanding is that something like `update-rc.d $service disable`
…
On Thu, 31 Oct 2013, Florian Weimer wrote:
> Curiously, a lot of system administrators do not do this correctly
> using sysvinit, causing system daemons to start unexpectedly after
> installing package updates.
What *is* the correct way, anyway?
My coworkers tell me to delete the symlinks in /et
Steven Chamberlain dixit:
[…]
>substitute Upstart here if you prefer), each package's maintainer could:
[…]
* Write scripts for one system and generate the other from it
or even
* Write “Debian init declaration” and let something take care
of generating an initscript and whatever the other syst
Olav Vitters vitters.nl> writes:
> Most of systemd is not in pid1. This was explained by a blog references
But (by the time of the jessie freeze, at least) it will need systemd to
be pid1 to work. Same thing, really, just picking words.
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debian-dev
Stefano Zacchiroli debian.org> writes:
> *technical* decision is stupid. We really need to stop thinking that
> every single member of the Debian project, just because he/she is a DD,
> has a clue on every single technical matter that go on in the project.
This means that you just don’t vote if
Lucas Nussbaum debian.org> writes:
> I agree. I don't think that many substantial new arguments are going to
> be brought by waiting more on this topic. And it is clear that we have
> reached a point where not having clear guidance is severely hurting the
> project.
I agree.
> I think that it w
Luca Capello pca.it> writes:
> My X60 (from late 2006) can not either, but IMHO the reason behind it
> that the SD reader it is not connected through the USB bus:
> =
> $ lspci | grep SD
> 15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host
Adapter (rev 18)
Right, but t
Andrew Kane dixit:
>A lot of these boxes are ones that one would reasonably expect to
>support booting from USB, but in some cases the option isn't there in
>the BIOS setup or boot menu and in others the option is there but is
>ignored on boot some or all of the time. The inability to boot from a
Nikolaus Rath dixit:
>To cut a long story short, I am not convinced that by open sourcing my
>code I am acquiring a moral obligation to take into account the
>preferences of potential users in future versions - no matter how large
But that’s just the thing! You are!
Of course, only in a way, and
Thomas Goirand dixit:
>> and at turning
>> the required changes to packaged software into general and defensible
>> upstream improvements. I've always been very impressed by this effort,
>Well, because of the upstream for Systemd, it can't, someone would have
>to fork the project (or maintain a
301 - 400 of 562 matches
Mail list logo
