Re: How to avoid stealth installation of systemd?

[Sune Vuorela]

On 2014-07-03, Joerg Jaspert  wrote:
> On 13626 March 1977, Norbert Preining wrote:
>> Joerg, please be reasonable.
>
> I entirely am, and thats why such a hate package won't bypass me, unless
> there is one of
>  a CTTE decision,
>  a GR forcing me, or
>  the ftp team overruling me.

Thanks.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp5k44$4o5$1...@ger.gmane.org

Bug#753672: ITP: node-mime-types -- ultimate JavaScript content-type utility - Node.js module

[Leo Iannacone]

Package: wnpp
Severity: wishlist
Owner: Leo Iannacone 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-mime-types
  Version : 1.0.1
  Upstream Author : Jonathan Ong  (http://jongleberry.com)
* URL : https://github.com/expressjs/mime-types
* License : Expat
  Programming Lang: JavaScript
  Description : ultimate JavaScript content-type utility - Node.js module
 This package provides a library for mime-type mapping similar to mime
 module with some differences, such as it always returns a value, even
 false if mime type is not found, and supports additional mime types.
 .
 Node.js is an event-based server-side JavaScript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b65d23.900db50a.7e14.e...@mx.google.com

Re: Bug#753641: ITP: liblinux-pid-perl -- wrapper around the getpid() and getppid() C functions

[Guillem Jover]

Hi!

On Thu, 2014-07-03 at 20:37:47 +0200, gregor herrmann wrote:
> Package: wnpp
> Owner: gregor herrmann 
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
> 
> * Package name: liblinux-pid-perl
>   Version : 0.04
>   Upstream Author : Rafael Garcia-Suarez 
> * URL : https://metacpan.org/release/Linux-Pid
> * License : Artistic or GPL-1+
>   Programming Lang: Perl
>   Description : wrapper around the getpid() and getppid() C functions
> 
> Perl already returns the PID and PPID in variables and builtins. Linux::Pid
> forces perl to call the underlying C functions getpid() and getppid().
> 
> This is useful with multithreaded programs. Linux' C library, using the Linux
> thread model, returns different values of the PID and the PPID from different
> threads.

With glibc and NPTL this module does not seem to make much sense, as
each different thread will have the same PID. If it was exposing the
Linux gettid() syscall then it would be the modern equivalent, but
that depends on the assumptions from the call sites and the expected
threading model, I suppose.

I guess this is just a dependency from something else? Why not patch
it to use the native perl functions instead?

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704080911.ga27...@gaara.hadrons.org

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Philip Hands]

The Wanderer  writes:

> ... particularly because I use rather fewer things than
> many other people, and don't use most fancy GUI elements. (For example,
> I don't have a graphical "power button" at all; I shut down by exiting
> my window manager, logging out of the console where I had originally run
> startx, logging in as root, and running 'shutdown -h'.)

So, let me get this straight:

You're saying that if, having decided to postpone rebooting after an
upgrade where any reasonable person would expect to reboot, you hear
rumours that features you don't use would have been broken if you had
them installed, you'll be highly displeased -- is that right?

and this is on a laptop, where you run testing, and which generally
gets rebooted by power outages, rather than any UI component that may or
may not be working at the time.

and you're inflicting this nonsense on the thousands of readers of this
list for what reason?  If it's to gain our gratitude and respect, I'm
afraid it's not working on me.

Cheers, Phil.

P.S. I'm yet to install systemd, but when I do switch to systemd, which
I will do despite being a bit of a stick in the mud, I'll expect to
reboot at least once.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://ftp.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpAQVhFR2SKI.pgp
Description: PGP signature

Re: Bug#752075: daemontools-run: Add systemd support

[Gerrit Pape]

Hi,

I looked into latest policy, but did not find anything about systemd
support.  I'm surprised that this is now a release critical bug, and the
package marked for removal.  What's the justification?

This package hooks into /etc/inittab, does systemd not automatically
manage services from inittab?  Isn't it systemd having release critical
bug then?

Regards, Gerrit


On Thu, Jun 19, 2014 at 12:54:06PM +0200, Joern Heissler wrote:
> Package: daemontools-run
> Version: 1:0.76-3
> Severity: grave
> Justification: renders package unusable
> 
> Hi,
> Debian decided to use systemd.
> 
> I'm using a local dnscache (djbdns) for recursive dns lookups, but this
> service isn't started automatically. I assume that it's because
> daemontools-run only supports sysvinit's inittab.
> 
> Please add systemd support,
> Cheers!
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (600, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages daemontools-run depends on:
> ii  daemontools  1:0.76-3
> 
> daemontools-run recommends no packages.
> 
> daemontools-run suggests no packages.
> 
> -- no debconf information


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140704090821.13265.qm...@79b6c771442573.315fe32.mid.smarden.org

Bloody noob dumb question

[Hans]

Dear developers,

please allow me a question. As I am absolutely new in coding, please 
apologize, if my question is too dumb.

So here it is:

I have the sourcecode of a little program (umtsmon), which has to be compiled 
for libqt3. But now I want it make compilable for latest libqt. I want to 
change nothing else, just make it compilable.

I get:

make
/usr/lib/x86_64-linux-gnu/qt4/bin/uic src/view/newprofiledialog.ui -o 
.ui/ui_newprofiledialog.h
uic: File generated with too old version of Qt Designer (3.3)
File 'src/view/newprofiledialog.ui' is not valid
Makefile:274: recipe for target '.ui/ui_newprofiledialog.h' failed
make: *** [.ui/ui_newprofiledialog.h] Error 1


And the first line in this (and other parts) is:



I guess, I have to change this, maybe. Please note, I am bloody new and just 
want to play around a little bit! I have installed kdevelop, maybe there are 
things easier with it. 

If you find my question stupid, it is ok, but I know nobody whom I can ask. So 
I asked the list.

Thanks for any answer!

Best regards

Hans 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/25542156.iycyMRUsP9@protheus2

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Ondřej Surý]

On Thu, Jul 3, 2014, at 16:59, Thorsten Glaser wrote:
> Besides, it’s not that the TC made a decision. Rather, the TC was
> split, and the chairman threw in his weight. This is absolutely not
> what I’d call a project(!) decision.

No!  The TC has made the decision with full adherence to Debian
Constitution.  If you disagree, perhaps you should go re-read the
Constitution, and if you disagree with our Constitution then perhaps
it's time for you to step down as a Debian Developer, since you are
bound by the Constitution and Social Contract and you are doing
hard to the project by making claims like this one.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1404466044.32693.138025825.706c6...@webmail.messagingengine.com

Re: Bloody noob dumb question

[Mathias Behrle]

* Hans: " Bloody noob dumb question" (Fri, 04 Jul 2014 11:06 +0200):

Hi Hans,

> If you find my question stupid, it is ok, but I know nobody whom I can ask.
> So I asked the list.

This list is about development in *Debian*, not Qt. You should search a list
for Qt development like [1][2].

Cheers,
Mathias

[1] http://lists.qt-project.org/mailman/listinfo
[2] http://lists.qt-project.org/mailman/listinfo/interest

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: Bloody noob dumb question

[Sune Vuorela]

On 2014-07-04, Hans  wrote:
> I have the sourcecode of a little program (umtsmon), which has to be compiled 
> for libqt3. But now I want it make compilable for latest libqt. I want to 
> change nothing else, just make it compilable.

Porting from Qt3 to Qt4 is not that simple, but you can look at
http://qt-project.org/doc/qt-4.8/porting4.html
and 
http://qt-project.org/doc/qt-4.8/porting4-designer.html

I'd suggest you to also once ported to Qt4 to also look into doing the
Qt5 port.


> If you find my question stupid, it is ok, but I know nobody whom I can ask. 
> So 
> I asked the list.

the qt-interest list on the qtproject might be a better place to start.
or #qt on freenode

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp5u1o$i9g$1...@ger.gmane.org

Re: Bug#752075: daemontools-run: Add systemd support

[Ansgar Burchardt]

Hi,

On 07/04/2014 11:08, Gerrit Pape wrote:
> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?

Ask the submitter?

> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?  Isn't it systemd having release critical
> bug then?

Could we please not have another systemd thread on -devel@? The last one
is not even cold yet... Thanks!

Unrelated to that, I would think that any package that modifies
/etc/inittab is buggy: maintainer scripts should not modify
configuration files belonging to other packages (Policy 10.7.4).

Even worse, daemontools-run adds a new entry uncoditionally on upgrade
even when the existing one was removed/commented out by the local admin.
That's a RC bug (Policy 10.7.3: "local changes must be preserved during
a package upgrade")...

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b67b69.6010...@debian.org

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Didier 'OdyX' Raboud]

That will be my last contribution to this pointless discussion.

Le jeudi, 3 juillet 2014, 16.59:25 Thorsten Glaser a écrit :
> > or without systemd btw). Given that the technical committee has made
> > a decision which stayed unchallenged (so far), I've now come to
> > think that
> No, there just has not been any challenge that met the form and
> other requirements… and I am at a bit of loss at what to do here.
> 
> Besides, it’s not that the TC made a decision. Rather, the TC was
> split, and the chairman threw in his weight.

Sorry, but this is plain wrong (and you know it); the TC followed its 
decision-making process (outlined in the project's constitution [0,1]) 
which led to what is now a TC decision. The detail of the votes doesn't 
change the outcome. Quoting [2]:
> The committee decided that the default init system for Linux 
> architectures in jessie should be systemd.

There are no possible "weak" or "strong" decisions; the outcome of a TC 
or GR decision is either "resolution accepted" or "further discussion". 
Giving importance to the "winning majority" is your choice but doesn't 
change the decision itself.

> This is absolutely not what I’d call a project(!) decision.

I was careful enough to not say it was a project decision, mind you. 
That said, our technical decision body took a decision that stayed 
unchallenged (so far); this fact makes it a /de facto/ project decision.

> > Can we get over this now and start making Jessie the most awesome
> > stable release we've ever prepared together?
> 
> To do that, it MUST work without systemd, if alone for upgrade
> scenarios.

That's wrong: as far as the default init is concerned, it only MUST work 
without systemd-as-init until the first post-dist-upgrade reboot. I 
don't think any work outside of that scope should be imposed on the 
package maintainers [3].

> And alone the fact that the systemd issue *continuously* pops up
> shows you that it is nowhere even near solved.

I don't think that's true. From my (most-certainly) biased point of 
view, the issue continues to pop up because some very vocal systemd 
opponents keep vocally insisting that other fellow project volunteers 
ensure that their pet use-cases keep working with a non-default init 
system (or even without a specific non-init package). As far as I am 
concerned, I'm putting my energy to make sure my packages (and my setup) 
work as good as possible with the _default_ init that was picked for 
jessie. The rest is best-effort.

> Furthermore, the TC(-chairman) decision only was on the default
> init system for the Linux ports of jessie.

Please stop spreading the FUD that the default init decision was a TC-
chairman decision. This is plain wrong, as our constitution outlines.

> This means that
> • installing jessie with other init systems
> • switching between init systems
> • default init system for kFreeBSD ports
> • default init system for Hurd port
> • which non-default init systems are there?
> are still on the table.

Sure. They are on the "we want Debian Jessie to work with other inits 
than the default" persons' table, they have no reason to be on 
everyone's. As mentioned above: if you want this to work, make sure it 
does, propose patches, test scenarios, etc. Pushing for a package 
conflicting with systemd is not helping any of this.

> (Due to Debian’s requirements for sane upgrades, running a jessie
> system that was upgraded from an older release with sysvinit MUST be
> fully supported, anyway.)

Wrong, see above.

> I’m a bit torn between throwing it all (which is a bad idea ofc),
> writing a GR myself (which is also a bad idea due to my lack of
> language skills), packaging BSD init for my own repo, joining the
> (currently unheard) runit-as-init crowd…

Frankly, if voting on a default init GR would ensure we'd finally stop 
these bikeshed discussions (after few other weeks of mudslinging), by 
all means, go for it. That said, as far as I remember, the latest GR 
proposal [4] on this subject failed to gather the mandatory K seconds 
though. For me, this indicates that not even K=5 DDs were interested in 
having that discussion. We currently need half a percent of DDs to 
trigger a GR and it has not happened; could we get over this now?

OdyX

[0] https://www.debian.org/devel/constitution
[1] Which you agreed to.
[2] https://www.debian.org/devel/tech-ctte
[3] It doesn't mean they should not accept patches for adaptations for
other init systems though.
[4] https://lists.debian.org/debian-vote/2014/03/msg0.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1627463.lsrZH6mOqL@gyllingar

Re: Bug#752075: daemontools-run: Add systemd support

[Tollef Fog Heen]

]] Gerrit Pape 

> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?
> 
> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?  Isn't it systemd having release critical
> bug then?

inittab is a sysvinit-only feature.  It's not supported with any other
of our supported init systems.  Either use an init script, which is
supported by all of them or provide native units for each init system.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761jdphga@aexonyam.err.no

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Rens Houben]

In other news for Thu, Jul 03, 2014 at 04:59:25PM +0200, Thorsten Glaser has 
been seen typing:

> No, there just has not been any challenge that met the form and
> other requirements… and I am at a bit of loss at what to do here.
 
> Besides, it’s not that the TC made a decision. Rather, the TC was
> split, and the chairman threw in his weight. This is absolutely not
> what I’d call a project(!) decision.

FFS. 

The chairman didn't "Throw in his weight". He used his tiebreaker vote
to break a tie. Which is exactly what he was *supposed* to do.

Stop pretending you're concerned about procedural propriety when your
actual problem is that the committee, working by the established
procedures, produced an outcome you didn't want. Who do you think you
are, the senate GOP?



-- 
Rens Houben   |opinions are mine
Resident linux guru and sysadmin  | if my employers have one
Systemec Internet Services.   |they'll tell you themselves
PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704100615.ga30...@proteus.systemec.nl

Re: Bug#753641: ITP: liblinux-pid-perl -- wrapper around the getpid() and getppid() C functions

[gregor herrmann]

On Fri, 04 Jul 2014 10:09:12 +0200, Guillem Jover wrote:

> > * Package name: liblinux-pid-perl
> >   Version : 0.04
> >   Upstream Author : Rafael Garcia-Suarez 
> > * URL : https://metacpan.org/release/Linux-Pid
> > * License : Artistic or GPL-1+
> >   Programming Lang: Perl
> >   Description : wrapper around the getpid() and getppid() C functions
> > 
> > Perl already returns the PID and PPID in variables and builtins. Linux::Pid
> > forces perl to call the underlying C functions getpid() and getppid().
> > 
> > This is useful with multithreaded programs. Linux' C library, using the 
> > Linux
> > thread model, returns different values of the PID and the PPID from 
> > different
> > threads.
> 
> With glibc and NPTL this module does not seem to make much sense, as
> each different thread will have the same PID. If it was exposing the
> Linux gettid() syscall then it would be the modern equivalent, but
> that depends on the assumptions from the call sites and the expected
> threading model, I suppose.
> 
> I guess this is just a dependency from something else? Why not patch
> it to use the native perl functions instead?

Right, as noted in the third paragraph of the description, mod_perl
wants it:
https://bugs.debian.org/684290
https://lists.debian.org/debian-perl/2014/07/msg2.html ff.


Cheers,
gregor, not opposed to a mod_perl patch as an alternative

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Peter Ratzenbeck: Flowers from Ayako


signature.asc
Description: Digital Signature

Re: Bug#752075: daemontools-run: Add systemd support

[Ondřej Surý]

Gerrit,

it's up to you to lower the severity of the bug to "important" (I guess
since it will break with default init system).

You should have done that instead of ccing debian-devel in the
current situation.

Please do not abuse debian-devel to questions that could be politely
and calmly discussed outside the list.

Thanks,
O.

On Fri, Jul 4, 2014, at 11:08, Gerrit Pape wrote:
> Hi,
> 
> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?
> 
> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?  Isn't it systemd having release critical
> bug then?
> 
> Regards, Gerrit
> 
> 
> On Thu, Jun 19, 2014 at 12:54:06PM +0200, Joern Heissler wrote:
> > Package: daemontools-run
> > Version: 1:0.76-3
> > Severity: grave
> > Justification: renders package unusable
> > 
> > Hi,
> > Debian decided to use systemd.
> > 
> > I'm using a local dnscache (djbdns) for recursive dns lookups, but this
> > service isn't started automatically. I assume that it's because
> > daemontools-run only supports sysvinit's inittab.
> > 
> > Please add systemd support,
> > Cheers!
> > 
> > 
> > -- System Information:
> > Debian Release: jessie/sid
> >   APT prefers unstable
> >   APT policy: (600, 'unstable')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > 
> > Versions of packages daemontools-run depends on:
> > ii  daemontools  1:0.76-3
> > 
> > daemontools-run recommends no packages.
> > 
> > daemontools-run suggests no packages.
> > 
> > -- no debconf information
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/20140704090821.13265.qm...@79b6c771442573.315fe32.mid.smarden.org
> 


-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1404468401.9917.138036781.4169e...@webmail.messagingengine.com

[SOLVED] Re: Bloody noob dumb question

[Hans]

> 
> Porting from Qt3 to Qt4 is not that simple, but you can look at
> http://qt-project.org/doc/qt-4.8/porting4.html
> and
> http://qt-project.org/doc/qt-4.8/porting4-designer.html
> 
> I'd suggest you to also once ported to Qt4 to also look into doing the
> Qt5 port.
> 
> > If you find my question stupid, it is ok, but I know nobody whom I can
> > ask. So I asked the list.
> 
> the qt-interest list on the qtproject might be a better place to start.
> or #qt on freenode
> 
> /Sune

Yeah, thank you very much! I did not know, that porting from qt3 to qt4 is 
documented. Always thought, only insider know how to do it.

Now I have a lot of to read and to test. If I succeed, you will hear again 
from me.

Until then: Sorry for the noise. 

Happy hacking

Hans


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2849490.2fgxiDOgpt@protheus2

Re: Bug#752075: daemontools-run: Add systemd support

[Russ Allbery]

Gerrit Pape  writes:

> I looked into latest policy, but did not find anything about systemd
> support.  I'm surprised that this is now a release critical bug, and the
> package marked for removal.  What's the justification?

I'm very dubious about this being release-critical.

> This package hooks into /etc/inittab, does systemd not automatically
> manage services from inittab?

Correct, systemd doesn't use inittab.

> Isn't it systemd having release critical bug then?

I don't think it's likely that systemd will support inittab.  The
semantics of inittab are quite a bit inferior to what's available with
very little additional work using the native configuration format, and the
regular inittab jobs are provided by regularly-configured services.  Yes,
that is a disruptive change for people who were using inittab to run other
things.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738eho1en@windlord.stanford.edu

Essential binaries and Pre-Depends on libraries

[Ansgar Burchardt]

Hi,

essential binaries have to work also when the package is in an unpacked,
but not configured, state. For that reason, packages including essential
binaries use Pre-Depends on the shared libraries needed by those binaries.

However, from my reading of policy I get the impression that this still
leaves an open issue: the transitive dependencies.

Let's look at coreutils as an example. coreutils Pre-Depends on libacl1
(>= 2.2.51-8) and libc6 (>= 2.17). However libacl1 only has a Depends:
libc6 (>= 2.14).

What happens if libacl1 picks up a dependency on libc (>= 2.19)? I think
in this case the package manager might do the following on an upgrade:

 - Unpack new libacl1.
 - Unpack new coreutils.
 -> The dependency of libacl1 on libc6 is not satisfied.
Binaries using libacl1 are broken.
 - Unpack libc6.
 -> coreutils is okay again.

Wouldn't libacl1 also need to use Pre-Depends in this case?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b68f61.6030...@debian.org

Re: Essential binaries and Pre-Depends on libraries

[Jakub Wilk]

* Ansgar Burchardt , 2014-07-04, 13:26:
essential binaries have to work also when the package is in an 
unpacked, but not configured, state. For that reason, packages 
including essential binaries use Pre-Depends on the shared libraries 
needed by those binaries.


However, from my reading of policy I get the impression that this still 
leaves an open issue: the transitive dependencies.


See bug #593177.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704113719.ga6...@jwilk.net

RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Gerrit Pape]

On Fri, Jul 04, 2014 at 03:37:20AM -0700, Russ Allbery wrote:
> Gerrit Pape  writes:
> > I looked into latest policy, but did not find anything about systemd
> > support.  I'm surprised that this is now a release critical bug, and the
> > package marked for removal.  What's the justification?
> 
> I'm very dubious about this being release-critical.

I think it is.  The package will not work as expected without the
inittab interface.

> > This package hooks into /etc/inittab, does systemd not automatically
> > manage services from inittab?
> 
> Correct, systemd doesn't use inittab.
> 
> > Isn't it systemd having release critical bug then?
> 
> I don't think it's likely that systemd will support inittab.  The
> semantics of inittab are quite a bit inferior to what's available with
> very little additional work using the native configuration format, and the
> regular inittab jobs are provided by regularly-configured services.  Yes,
> that is a disruptive change for people who were using inittab to run other
> things.

Thanks Russ.  This also applies to the runit package actually.

Having my own init system since more than 10 years, I'm not that much in
systemd.  I looked at policy, but didn't find any instructions.

I hereby ask for help to add systemd support to these packages.

Important thing to know is: init scripts don't work out for this.  The
service management concept of daemontools and runit is, amongst other
things, a process tree with guaranteed process state, including
envrionment.  init scripts don't provide that.

Regards, Gerrit.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140704115052.24406.qm...@0268f0ed90ab4d.315fe32.mid.smarden.org

Re: Bug#752075: daemontools-run: Add systemd support

[Gerrit Pape]

On Fri, Jul 04, 2014 at 12:01:13PM +0200, Ansgar Burchardt wrote:
> Could we please not have another systemd thread on -devel@? The last
> one is not even cold yet... Thanks!

On Fri, Jul 04, 2014 at 12:06:41PM +0200, Ond??ej Surￜ wrote:
> Please do not abuse debian-devel to questions that could be politely
> and calmly discussed outside the list.

This is about a package I maintain with a RC bug that'll cause it to be
removed from the next Debian release.  I'm with Debian more than 12
years, I'm pretty sure debian-devel@l.d.o is the right place to ask
fellows for advice.

Switching to systemd is a big change, and what you're doing is not in
line with common understanding of Change Management.  I, and our
fellows, shouldn't be told to shut up.  I need support from my fellows
just because of that change.

On Fri, Jul 04, 2014 at 12:06:41PM +0200, Ond??ej Surý wrote:
> it's up to you to lower the severity of the bug to "important" (I guess
> since it will break with default init system).

I know that.  It's not right, it's RC with justification "renders
package unusable".  It's just that since more than six years this
package worked just flawlessly without any changes.  I like that.  It's
something else that renders it unusable.

We all should welcome RC bugs, they help us to make a good release.
Looks like the question in which package a RC bug shall be resolved
offends some people.  Not good.

Regards.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140704115255.24565.qm...@8e5fdd656e7568.315fe32.mid.smarden.org

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Matthias Urlichs]

Hi,

Gerrit Pape:
> > I'm very dubious about this being release-critical.
> 
> I think it is.  The package will not work as expected without the
> inittab interface.
> 
It's rather trivial to write an init script, and/or a systemd unit file,
which starts daemontools. Hooking into inittab isn't going to work with any
other init system, not just not with systemd.

> Having my own init system since more than 10 years, I'm not that much in
> systemd.  I looked at policy, but didn't find any instructions.
> 
You can start with the systemd.unit manpage. Searching the web for
"systemd howto write unit file" also yields some useful resources.

> Important thing to know is: init scripts don't work out for this.  The
> service management concept of daemontools and runit is, amongst other
> things, a process tree with guaranteed process state, including
> envrionment.  init scripts don't provide that.
> 
Well … systemd does.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704121746.gg23...@smurf.noris.de

Re: Bug#752075: daemontools-run: Add systemd support

[Matthias Urlichs]

Hi,

Gerrit Pape:
> This is about a package I maintain with a RC bug that'll cause it to be
> removed from the next Debian release.  I'm with Debian more than 12
> years, I'm pretty sure debian-devel@l.d.o is the right place to ask
> fellows for advice.
> 
I agree.

> Switching to systemd is a big change, and what you're doing is not in
> line with common understanding of Change Management.

Then again, change management does not usually start with multi-year
discussions and a TC decision. ;-)

> We all should welcome RC bugs, they help us to make a good release.

+1

> Looks like the question in which package a RC bug shall be resolved
> offends some people.  Not good.
> 
It doesn't exactly offend, but some people are on a hair trigger because of
the recent discussion – which IMHO has been mostly reasonable, compared to
what I remember from ten+ years or so ago …

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704122255.gh23...@smurf.noris.de

Re: systemd is here to stay, get over it now

[Thorsten Glaser]

OdyX wrote:

>all means, go for it. That said, as far as I remember, the latest GR
>proposal [4] on this subject failed to gather the mandatory K seconds
>though. For me, this indicates that not even K=5 DDs were interested in

I was not even aware of that proposal. This may also indicate lack
of, marketing or whatever.


Russ Allbery wrote:

>systemd is open source.  Every line of code is available to you to read.
>If you think the NSA has hidden some strange back-door in systemd, please

You know, backdoors are not only code vulnerabilities.

systemd is a backdoor in that, like the availability of Steam
games for DDs, it has a chance to hinder the progress of all
projects done in the spare time of the people affected.

systemd is a backdoor in that, by means of vendor lock-in, it
will make future subversing a system easier, because there will
be no alternative implementation of
* init
* syslog
* ntpd
* dhcp, IIUC
* udev
* dbus
* and whatever else systemd is going to ship or push into the kernel
any more, to which people could switch in case of a fatal emergency
with the systemd-provided code.

For example, systemd has support for its own (S)NTP client, but also
supports xntpd (rudely leaving OpenNTPD out already). The commit message
explains that the xntpd support will eventually go away.

This is the best example of, hm, there's no English idiomatic expression
I'm told in IRC... an "entry drug" (provided for free, and making you
dependent on getting even more of that fix). Similar to MSDNAA except
worse yet.

Yes, I just compared systemd to a drug. This feels strangely right
in so many ways.

This means that systemd not will but already has severely compromised
the OSS ecosystem. Heterogenous systems are the enemy of agencies,
after all, you know?

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp66ju$mhj$1...@ger.gmane.org

Re: systemd is here to stay, get over it now

[Juliusz Chroboczek]

> The problem is that some people bitch endlessly abut how evil systemd is
> _instead_of_ producing software (not just patches) to replace what
> systemd offers.

Abstracting away from your somewhat offensive choice of language, that's
a good point.  As far as I'm aware, the only major distribution that has
been doing the right thing is OpenWRT, which has recently switched to
"procd", a locally developed init replacement.

  git clone git://nbd.name/luci2/procd.git

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnt5i9rw.wl@pps.univ-paris-diderot.fr

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Michael Biebl]

Hi Gerrit,

Am 04.07.2014 13:50, schrieb Gerrit Pape:
> I hereby ask for help to add systemd support to these packages.

We (pkg-systemd team) can help you with that.

Let's follow up on the pkg-systemd mailing list.

In most cases adding a .service file is pretty simple.
If it's only about starting a svscanboot process, that might be as
simple as installing a file
/lib/systemd/system/svscanboot.service containing

[Unit]
Description=daemon tools

[Service]
ExecStart=/usr/bin/svscanboot
Restart=always

[Install]
WantedBy=multi-user.target



We probably need to tweak the Type= [1] setting depending on what type
of service svcanboot is.

[1] man systemd.service

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Russ Allbery]

Gerrit Pape  writes:

> Important thing to know is: init scripts don't work out for this.  The
> service management concept of daemontools and runit is, amongst other
> things, a process tree with guaranteed process state, including
> envrionment.  init scripts don't provide that.

There's no reason to switch away from inittab for sysvinit.  For systemd,
a unit file can easily do everything that you would get from inittab.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvihmh9p@windlord.stanford.edu

adding systemd support to your package (Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support)

[Michael Biebl]

Am 04.07.2014 14:34, schrieb Michael Biebl:
> Hi Gerrit,
> 
> Am 04.07.2014 13:50, schrieb Gerrit Pape:
>> I hereby ask for help to add systemd support to these packages.
> 
> We (pkg-systemd team) can help you with that.
> 
> Let's follow up on the pkg-systemd mailing list.


I want to add, that this is a general offer.

If you as package maintainer want to add native systemd support then
this is great and we invite you to direct any questions you have to the

pkg-systemd-maintain...@lists.alioth.debian.org

mailing list and we will try to help you as best as we can.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: adding systemd support to your package (Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support)

[Michael Biebl]

Am 04.07.2014 14:38, schrieb Michael Biebl:
> pkg-systemd-maintain...@lists.alioth.debian.org
> 
> mailing list and we will try to help you as best as we can.

or join #debian-systemd on OFTC.


Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/04/2014 04:52 AM, Philip Hands wrote:

> The Wanderer  writes:
> 
>> ... particularly because I use rather fewer things than many other
>> people, and don't use most fancy GUI elements. (For example, I
>> don't have a graphical "power button" at all; I shut down by
>> exiting my window manager, logging out of the console where I had
>> originally run startx, logging in as root, and running 'shutdown
>> -h'.)
> 
> So, let me get this straight:
> 
> You're saying that if, having decided to postpone rebooting after an
> upgrade where any reasonable person would expect to reboot,

This part is precisely what I'm objecting to. I don't consider being
expected to reboot *in order to maintain existing functionality* after
an upgrade to be reasonable. (Being expected to reboot in order to use
the new functionality, for a sufficiently low-level component of the
system, is of course entirely reasonable.)

At the very least, in the very rare case that rebooting is actually
required, a prominent pre-install "this install will require you to
reboot ASAP" notification would be appropriate.

The situation is different in Windows (where such "please reboot now"
notifications are very common post-install, including with ordinary
programs rather than low-level components), of course, but I've
considered that to be an example of one of the advantages of *nix over
Windows.

> you hear rumours that features you don't use would have been broken
> if you had them installed, you'll be highly displeased -- is that
> right?

No.

I'm saying that if something I do use is broken during that period
between upgrade and reboot, I'll be highly displeased.

It's possible that nothing I do use will be affected, but it's also
possible that something I use will indeed be affected. It's not remotely
clear yet (at least to me) what features will be broken, or indeed even
which of the many systemd-related packages is expected to potentially
cause such breakage.

I would not be in the least bit surprised if I were not the only one who
would be displeased at a "continuing to use your computer indefinitely
after upgrading and before rebooting is not a scenario which is expected
to work" situation, given the historical tendency for people to chase
their own personal uptime records.

> and this is on a laptop, where you run testing, and which generally
> gets rebooted by power outages, rather than any UI component that may
> or may not be working at the time.

No. This is on both a laptop and a desktop; the desktop generally gets
rebooted by power outages, and the laptop by "the battery died because I
left it suspended for too long without plugging it in".

This also isn't about reboot methods which may or may not get broken;
it's about *other* things which may get broken. Nothing has been said to
narrow down what "other things" those might be, AFAIK, only that
GUI-based reboot methods must *not* get broken.

> and you're inflicting this nonsense on the thousands of readers of
> this list for what reason?  If it's to gain our gratitude and
> respect, I'm afraid it's not working on me.

(Why on Earth would anyone think that someone would raise an objection
in order to get gratitude from those to whom the objection is being
presented?)

I spoke up because I consider a scenario of "everything works, a routine
upgrade occurs, now something is broken until a reboot is performed" to
be undesirable and unacceptable, for pretty much any reason, and I had
never previously encountered a suggestion that such a scenario might be
considered "normal and expected" in any *nix environment.

If it were guaranteed that the "systemd" upgrade would *not* be a
"routine" upgrade, but a special one done with full knowledge of what is
happening, that might mitigate the problem somewhat - but we've already
seen that systemd can easily be pulled in without the user realizing
that it's going to happen, or indeed noticing that it *has* happened
until after the fact.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTtqHCAAoJEASpNY00KDJrpFMP/RL75yk3WEZTHWkI13GafeLb
/p27WzuKm8QLnoxY8uZn4VKtEsSufBPDTrZMHBIZYzdh4Llu+TqEbtd38Q6XoUwe
8lEvDZL4bWY1pCM3fFl/FuFLQDHPribwDkV/jqBQzS38OfQWcuS/f7oetNcG+dvi
rX3dw5VFbraNERLjHaADMk0fDVaSt87ItbSg00LnWsFnCjCbRSZl7wlexMhKQCMi
hbtApZL9JBXkiMJV5uNDcTuNeoYG72UeBD4S0+Z3j/Rsqdsrv8nLe5v2HdkExawF
Ck/NeSQsoh88Ltz1tBK/eYX7gR3Rcx5T6Gd3No+c5fxzxR2ggxA+VSLVg+EMV/fr
ZMfunGMJsXDsyLl2qG45meV230cL0+X1rABb/EdMozZgWrrhLGyLJAFnio6bRJeU
JwHT0WdmM/OiGj8z7WApjV0BEfzfJnsdZ/TnIviBBasZptlBxcNuVgF1eEagn8Gy
XoaJRPyuAem96MCKegbamFzKDD8ysnZe2yrDrfvZH68GXinCNI6oi4xp1YwFU62L
ZqOhwYi8utCvW7s/zXrzgeu5U7B/rkADtAA7Yt9Bg9kA5Mv0bfGksc1by6fNIrR9
OOdrPL4DE0xjNj6/2yHVzWB8MRoFVVSDHZLVpKTVnWsv6oZozz00JroA9i6NcBeZ
Y2PhDSKFwnjTV0LKWWmb
=g

Re: Bug#753641: ITP: liblinux-pid-perl -- wrapper around the getpid() and getppid() C functions

[Guillem Jover]

Hi!

On Fri, 2014-07-04 at 12:21:15 +0200, gregor herrmann wrote:
> On Fri, 04 Jul 2014 10:09:12 +0200, Guillem Jover wrote:
> > With glibc and NPTL this module does not seem to make much sense, as
> > each different thread will have the same PID. If it was exposing the
> > Linux gettid() syscall then it would be the modern equivalent, but
> > that depends on the assumptions from the call sites and the expected
> > threading model, I suppose.
> > 
> > I guess this is just a dependency from something else? Why not patch
> > it to use the native perl functions instead?
> 
> Right, as noted in the third paragraph of the description, mod_perl
> wants it:
> https://bugs.debian.org/684290
> https://lists.debian.org/debian-perl/2014/07/msg2.html ff.

> gregor, not opposed to a mod_perl patch as an alternative

Ok, so how about this non-tested patch? The test suite might need
patching too, but as I guess it was either not failing or being
ignored currently, I didn't touch it.

Thanks,
Guillem
Description: Fallback to use native perl getppid() if Linux::Pid is not present
Author: Guillem Jover 
Origin: vendor
Bug-Debian: http://bugs.debian.org/684290
Forwarded: no
Last-Update: 2014-07-04


--- libapache2-mod-perl2-2.0.8+httpd24-r1449661.orig/Apache-SizeLimit/lib/Apache/SizeLimit/Core.pm
+++ libapache2-mod-perl2-2.0.8+httpd24-r1449661/Apache-SizeLimit/lib/Apache/SizeLimit/Core.pm
@@ -139,10 +139,12 @@ BEGIN {
 *_platform_getppid = \&_perl_getppid;
 }
 elsif ($Config{'osname'} eq 'linux') {
-_load('Linux::Pid');
-
-*_platform_getppid = \&_linux_getppid;
-
+if (eval { require Linux::Pid }) {
+*_platform_getppid = \&_linux_getppid;
+}
+else {
+*_platform_getppid = \&_perl_getppid;
+}
 if (eval { require Linux::Smaps && Linux::Smaps->new($$) }) {
 $USE_SMAPS = 1;
 *_platform_check_size = \&_linux_smaps_size_check;

Re: systemd is here to stay, get over it now

[Matthias Urlichs]

Hi,

Thorsten Glaser:
> systemd is a backdoor in that, like the availability of Steam
> games for DDs, it has a chance to hinder the progress of all
> projects done in the spare time of the people affected.
> 
Yeah. It "has a chance".

It also "has a chance" to give people a big chunk of spare time back,
because they can find and fix their daemon startup bugs a whole lot
faster (and more consistently) than with SysVinit.

Your chance is pure speculation. My chance is personal experience.

> systemd is a backdoor in that, by means of vendor lock-in

Which vendor are you talking about, exactly?

> any more, to which people could switch in case of a fatal emergency
> with the systemd-provided code.
> 
I'd assume that switching from systemd to something_else in an emergency is
a whole lot easier than switching from Linux to something_else.

The solution to any grave bug will be, like with any piece of userland
software, to fix that bug and restart systemd. You can't do that with the
kernel yet (reboot required), yet I don't hear a lot of people complaining
about "vendor lock-in" by the Linux kernel.

> Yes, I just compared systemd to a drug. This feels strangely right
> in so many ways.
> 
One might want to counter this "argument" by comparing systemd-bashing
to a drug. That feels also strangely right in many ways.

Again: You want diversity and a non-systemd Debian? Fine.
Then shut up and help with the work required to get there,
instead of complaining on -devel.

We have all heard the arguments. And the "arguments". Multiple times.

Enough said. I, for one, will now *plonk* this thread.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704130433.gi23...@smurf.noris.de

Re: systemd is here to stay, get over it now

[Thorsten Glaser]

Juliusz Chroboczek wrote:
>> The problem is that some people bitch endlessly abut how evil systemd is
>> _instead_of_ producing software (not just patches) to replace what
>> systemd offers.
>
>Abstracting away from your somewhat offensive choice of language, that's
>a good point.  As far as I'm aware, the only major distribution that has

Eh, why would I need to write anything? BSD init WFM. SYSV init with
file-rc WFM unless someone breaks it again. I can live with SYSV init
with sysv-rc, if it must be (but then, please, no parallel boot). I
believe I could live with runit as init.

>been doing the right thing is OpenWRT, which has recently switched to
>"procd", a locally developed init replacement.

procd… ubus… *shudder* but at least they're consistent.
OpenWrt has been doing their own way for some time already.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp6908$sp4$1...@ger.gmane.org

Re: systemd is here to stay, get over it now

[Thorsten Glaser]

Dominik George dixit:

>systemd, in its nature as an init system, starts what you tell it to
>start. There is nothing that can prevent it from starting openntpd if
>you want that. If you through a service file at it, or even an LSB
>init script, then systemd has no choice but to start it.

No, this is about something else. This is about… I think it’s called
“services” and it is something other packages require, and I believe
it has to do something with dbus. This is not just about running an
NTP dæmon, but, AIUI, some APIs to manage and query it (just like
hostnamed, timezoned, etc).

Of course I can start OpenNTPD now (and cause e.g. xntpd’s start to
fail, with that), but some software will complain then. I have *no*
idea for what people will want to use this, but…

I cannot cite my sources as I got most of this from a private IRC
channel. But there was some commit message in a systemd- or related
git repository hinting at this. I did not save the link.

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1407041310230.17...@herc.mirbsd.org

Re: systemd is here to stay, get over it now

[Dominik George]

Hi Thorsten,

while I tend to basically acknowledge your points here, there is still one 
thing you obviously did not get until now, if I followed along correctly.

>For example, systemd has support for its own (S)NTP client, but also
>supports xntpd (rudely leaving OpenNTPD out already). The commit
>message
>explains that the xntpd support will eventually go away.

systemd, in its nature as an init system, starts what you tell it to start. 
There is nothing that can prevent it from starting openntpd if you want that. 
If you through a service file at it, or even an LSB init script, then systemd 
has no choice but to start it.

That said, dropping support for service foo in systemd means that service foo 
dropped both their service file and their init script, _not_ systemd doing 
anything.

If you have sources proving that systemd is planning to do antivirus-like 
signature checking on binaries to detect openntpd or something, then please 
provide such. I tend to not believe that!

Cheers,
Nik


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/dea96464-5991-42f2-8433-fad892d19...@email.android.com

Re: systemd is here to stay, get over it now

[Stephan Seitz]

On Thu, Jul 03, 2014 at 08:40:59PM +0200, Matthias Urlichs wrote:

The problem is that some people bitch endlessly abut how evil systemd is
_instead_of_ producing software (not just patches) to replace what systemd
offers.


But if they don’t want the systemd features why should they write 
software to replace systemd?


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

ITP: amap -- Next-generation scanning tool for pentesters

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name    : amap
  Version : 5.4
  Upstream Author : Van Hauser 
* URL : http://www.thc.org/thc-amap/
* License : GPL-2+
  Programming Lang: C
  Description : Next-generation scanning tool for pentesters

 AMAP stands for Application MAPper. It is a next-generation scanning
 tool for pentesters. It attempts to identify applications even if they
 are running on a different port than normal.
 .
 It also identifies non-ascii based applications. This is achieved by
 sending trigger packets, and looking up the responses in a list of
 response strings.

I would like to reintroduce this useful package in debian, since bug #381185 no 
longer applies
and this tool is useful and used in penetration testing and security (I took 
the Raphael package
from kali linux git).

Thanks,

Gianfranco



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1404480012.24216.yahoomail...@web171806.mail.ir2.yahoo.com

Re: systemd is here to stay, get over it now

[Norbert Preining]

On Fri, 04 Jul 2014, Matthias Urlichs wrote:
> Then shut up and help with the work required to get there,

Please stop this inpoliteness, or I request a ban on all mailing lists
due to permanent breaking of Code of Conduct.

(Long live the CoC - I am *so* happy to have it!! - hope someone 
got the sarcasm)

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704132502.gw19...@auth.logic.tuwien.ac.at

Re: systemd is here to stay, get over it now

[Steve McIntyre]

Thorsten Glaser wrote:
>
>You know, backdoors are not only code vulnerabilities.
>
>systemd is a backdoor in that, like the availability of Steam
>games for DDs, it has a chance to hinder the progress of all
>projects done in the spare time of the people affected.

Thorsten, you're too late. The argument is lost and Debian is moving
to systemd. We followed our rules and the TC chose that route.

I won't pretend to be happy about this - I'm *seriously* not a fan of
either systemd or its main developers myself. But sometimes you just
have to accept things you don't like and move on. Right now *you* and
others are hindering progress and wasting time of other developers
with this constant bickering and sniping. If you must do it, start the
GR and see how that goes. I even offer to second it just to help get
the issue resolved. If you don't want to go the GR route, then please
quit whining. You're achieving nothing but making yourself look bad.

We're 4 months from the Jeesie freeze and we all have better stuff to
be doing than posting repetitive crap on the lists like this.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1x33b7-0001p1...@mail.einval.com

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Milan P. Stanic]

On Fri, 2014-07-04 at 14:34, Michael Biebl wrote:
> Am 04.07.2014 13:50, schrieb Gerrit Pape:
> > I hereby ask for help to add systemd support to these packages.
> 
> We (pkg-systemd team) can help you with that.
> 
> Let's follow up on the pkg-systemd mailing list.
> 
> In most cases adding a .service file is pretty simple.
> If it's only about starting a svscanboot process, that might be as
> simple as installing a file
> /lib/systemd/system/svscanboot.service containing
> 
> [Unit]
> Description=daemon tools
> 
> [Service]
> ExecStart=/usr/bin/svscanboot
> Restart=always
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> 
> We probably need to tweak the Type= [1] setting depending on what type
> of service svcanboot is.
> 
> [1] man systemd.service

And for runit:

cat /etc/systemd/system/runit.service
[Unit]
Description=runit svscan
After=syslog.target

[Service]
ExecStart=/usr/bin/runsvdir -P /etc/service 'log: 
...'

[Install]
WantedBy=networking.service

N.B. WantedBy=networking.service can be changed to something
appropriate.

-- 
Kind regards,  Milan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704132224.ga29...@arvanta.net

Re: systemd is here to stay, get over it now

[Thorsten Glaser]

Matthias Urlichs wrote:

>Thorsten Glaser:
>> systemd is a backdoor in that, like the availability of Steam
>> games for DDs, it has a chance to hinder the progress of all
>> projects done in the spare time of the people affected.

>Yeah. It "has a chance".

Yes. (I was more or less referring to this discussion as time
killer, though.)

>It also "has a chance" to give people a big chunk of spare time back,

... maybe...

>because they can find and fix their daemon startup bugs a whole lot
>faster (and more consistently) than with SysVinit.

In SYSV init, I can just use "set -x". That just rocks.
(But anyway, I do not wish to discuss this here - there
are more suitable places/threads.)

>> systemd is a backdoor in that, by means of vendor lock-in
>
>Which vendor are you talking about, exactly?

"vendor lock-in" is an atomic expression, meaning the mechanism
to have one thing from vendor X depend on one other thing from
vendor X, which depends on just another thing from vendor X,
without being able to exchange components against those from
another vendor.

Good example here is autoconf 2.62 and later, which depend on
GNU m4, although previous versions also worked with BSD m4.
(There are patches, so 2.62 works but 2.63 doesn't, now.)
GNU software in general is the most prominent example of "vendor
lock-in" I know. The vendor in this case is the GNU project.

In the systemd case, it's systemd, obviously.

>The solution to any grave bug will be, like with any piece of userland
>software, to fix that bug and restart systemd. You can't do that with the

If you can fix the bug, sure. If not... or not in time...

>Again: You want diversity and a non-systemd Debian? Fine.
>Then shut up and help with the work required to get there,

With Debian as it is now, there is nothing needed (except
to upload the prevent-systemd package in its next iteration).
Debian as it is now works just fine without systemd. If *you*
want to change that, it's *you* who are breaking it.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp6a5v$sp4$2...@ger.gmane.org

ITP: schema2ldif -- Tool for converting OpenLDAP-style schemas to the LDIF

[Benoit Mortier]

Package: wnpp
Severity: wishlist
Owner: Benoit Mortier 

* Package name: schema2ldif
  Version : 0.1
  Upstream Author : Come Bernigaud 
* URL : https://forge.fusiondirectory.org/projects/schema2ldif
* License : GPL
  Programming Lang: Perl
  Description : Tool for converting OpenLDAP-style schemas to the LDIF 
format

 schema2ldif will read the given input file and convert it to an LDIF file
 that you can insert into you LDAP directory

-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Main developper in FusionDirectory : http://www.fusiondirectory.org/
Official French representative for OPSI : http://opsi.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201407041558.28805.benoit.mort...@opensides.be

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Michael Biebl]

Hi Milan,

Am 04.07.2014 15:22, schrieb Milan P. Stanic:
> And for runit:

Thanks for sharing.


> cat /etc/systemd/system/runit.service
> [Unit]
> Description=runit svscan
> After=syslog.target

The After=syslog.target is no longer necessary and not recommended
anymore. Lintian will actually complain about that.
Syslog is started via socket activation nowadays making this explicit
ordering obsolete.

> 
> [Service]
> ExecStart=/usr/bin/runsvdir -P /etc/service 'log: 
> ...'
> 
> [Install]
> WantedBy=networking.service

Services should be hooked up in targets. So WantedBy=networking.service
looks wrong.

In the vast majority of cases you want WantedBy=multi-user.target


Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd is here to stay, get over it now

[Matthias Urlichs]

Hi,

Norbert Preining:
> > Then shut up and help with the work required to get there,
> Please stop this inpoliteness, or I request a ban on all mailing lists
> due to permanent breaking of Code of Conduct.

*what* Seriously?!?

One of us seems to harbor a severe misconception or two about what kind of
behavior the CoC is supposed to sanction, and I sure hope it's not me.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704140238.gj23...@smurf.noris.de

GR - collecting proposals (was Re: systemd is here to stay, get over it now)

[Thorsten Glaser]

Steve McIntyre wrote:

>with this constant bickering and sniping. If you must do it, start the
>GR and see how that goes. I even offer to second it just to help get

Can you help formulate? I do not feel my English skills are
up to that.


Also, what options do we need?

1) systemd is the only init system supported in jessie (for Linux)
   => we accept the change and require all users to follow our new
  default

2) systemd and sysvinit are both supported in jessie, but sysvinit
   is only supported for systems upgraded from older Debian installs;
   package maintainers have to at least not actively break existing
   sysvinit support and should accept patches to keep sysvinit with
   sysv-rc working
   => we accept the change but do not enforce it on all users; we
  intend to keep the old way working for as long as reasonably
  possible, even though it means degraded operation for some
   (maintenance burden is on the package maintainers, plus a
   possible team of volunteers)

3) systemd and sysv are both supported in jessie (for all ports,
   probably - Hurd in any case, I don't know what the kFreeBSD
   people have); package maintainers have to at least not actively
   break existing sysvinit support and must accept patches to keep
   sysvinit with sysv-rc working
   - new installations must either offer a choice of init system,
 or install systemd and offer switching the init system to
 sysvinit later (e.g. via apt-get install, possibly with the
 famous "Yes I know what I am doing" prompt)
   (maintenance burden is on the maintainers of d-i and systemd
and sysvinit, for this; the way is to be decided by CTTE if
those do not find a suitable one by themselves)
   - existing installations of older (pre-jessie) Debian may be
 upgraded to our new standard init system systemd, but only
 after the user has been suitably warned, e.g. via a debconf
 propmpt at priority "medium" (i.e. not shown to novices)
   (maintenance burden is on the package maintainers, plus a
   possible team of volunteers, for the init scripts; maintenance
   burden for the upgrade scenario is with the maintainers of the
   affected packages (sysvinit and systemd, AIUI))
   => we promote our new default, but permit our users to choose
  for themselves, if they feel they are technically skilled
  enough to make this choice and live with the limitations
  of a non-standard system; switching back and forth between
  the two supported systems is always possible

4) all init systems currently in Debian are supported in jessie;
   maintainers must support sysvinit at least as in 3) and are
   encouraged to accept patches for file-rc, upstart, possibly
   OpenRC and runit
   - new installations operate as in 3) except support for all
 init systems that are not either the old default (sysv-rc)
 or the new default (systemd) may use a more complicated
 path (e.g. switch from systemd to sysvinit first, then to
 the other init system)
   (maintenance burden for sysvinit is on the package maintainers;
maintenance burden for the other init systems is on the
maintainers of those init systems; the path to switch between
init systems is to be decided by CTTE if the maintainers of
the init systems do not find a suitable way by themselves)
   - existing installations can keep running, although we may
 migrade existing installations of the old default to the
 new default as in 3) above (e.g. debconf "medium")
   => we promote freedom of choice, and our new default is the
  preselected choice, but users who feel they can cope with
  it are free to choose differently; switching back and
  forth between init systems is subject to whatever the
  maintainers come up, or CTTE if they don't, but switching
  should be possible and defined but not necessarily easy

You may note I agree, in all of these proposed options, that
we can change the default init system to our new default which
CTTE has decided on, for both new and existing installations;
I just require that the user is to be informed about it and
can abort the upgrade if they do not wish the change (at debconf
"medium" priority; I think about something like the linux-image
packages do to prevent removal of the running kernel), and that
the user has a defined way to switch between init systems.


Thanks in advance,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp6dlk$tvc$1...@ger.gmane.org

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Adam Borowski]

On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote:
> So, let me get this straight:
> 
> You're saying that if, having decided to postpone rebooting after an
> upgrade where any reasonable person would expect to reboot

This is Debian, not Windows or Red Hat, forced reboots are not acceptable.

There was enough trouble when udev needed an in-lockstep upgrade with the
kernel a few releases back.  If systemd components are going to need such
forced reboots on a repeated basis, I don't like where this is going.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704144228.ga10...@angband.pl

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Ondřej Surý]

On Fri, Jul 4, 2014, at 16:42, Adam Borowski wrote:
> On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote:
> > So, let me get this straight:
> > 
> > You're saying that if, having decided to postpone rebooting after an
> > upgrade where any reasonable person would expect to reboot
> 
> This is Debian, not Windows or Red Hat, forced reboots are not
> acceptable.

Yes, this is Debian and not a magic world.

> There was enough trouble when udev needed an in-lockstep upgrade with the
> kernel a few releases back.  If systemd components are going to need such
> forced reboots on a repeated basis, I don't like where this is going.

Nobody said that. But I am sure you can understand that some changes
might require a reboot to have all functionality. I think it's
unreasonable
to require that all components must work in every combination of partial
upgrade.

And still this is unstable/testing and some inconveniences are allowed,
we just must be sure that the stable release upgrade process is smooth.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1404486367.14427.138117277.67a2e...@webmail.messagingengine.com

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/04/2014 10:42 AM, Adam Borowski wrote:

> On Fri, Jul 04, 2014 at 09:52:07AM +0100, Philip Hands wrote:
> 
>> So, let me get this straight:
>> 
>> You're saying that if, having decided to postpone rebooting after
>> an upgrade where any reasonable person would expect to reboot
> 
> This is Debian, not Windows or Red Hat, forced reboots are not
> acceptable.
> 
> There was enough trouble when udev needed an in-lockstep upgrade with
> the kernel a few releases back.  If systemd components are going to
> need such forced reboots on a repeated basis, I don't like where this
> is going.

To be fair, I don't think anyone has suggested that reboots would be
required "on a repeated basis" - only on the initial transition.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTtsSDAAoJEASpNY00KDJr0KgP/0d/BnwUhqZxdcP6+UWewIKu
O6QSfy+kffDVt6crNyVg7qYFN5ny1piWFVDuwHZpJIOlNW5/PKfWlL9wyehWFnJq
pBAU5bVRj6mnnMr3iWUf2N3O3afBWOnLqYGTnMbGB0tzWZdlaSXPN3rPdQpx7yOF
uXiy7h+RzV/eoF//U+ihEUI50hBG+c6Qe0RncbOEvoRvZv2fwJtBZU4MXeVH3Ga0
ilQGDA28X19AChTvcUuy7RRKXLYYGZlRcgxsSMvSlDZQNz9f7j+MHJbKGOLtD0nN
3caQVVk4evxxcliBKPjCgzpmnK2aqI+XZTrH4qDGnNF7KJzBWPtB692srtcukmb9
SwwXWfC6bIUMGT7CW1MUB6/JmGJbF+CGNduUcqZxi/Hpe+MN1FzPgij9YVRJtu8/
6TiZBoSn0JnqcFfjaRKp6Ex8SAqgEdWt/7Eya9xzoP+s5tyo3CpB2450vbkWIjOA
RLbvYZglzpZVRI3uZs8xRdi/4pxSYIYrWCz26VU0j+mxLA1AmgpKLrjSVMTDjJBO
WmtOJ8fcPK7VF77v7hj1ymswvyzAlnPk6w26cVqeRvBoCjFktWwUDiQCoqRbJzYC
mFo7cX+01Z0WDQXpbO1M3oklo/bgNo7ArAbWrhEOBdv31WDM0lKNWYYV21Uczgyh
+MT/Km1XQvz06VJDRxsv
=qkRr
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b6c483.4040...@fastmail.fm

Re: Bug#752075: daemontools-run: Add systemd support

[Adam Borowski]

On Fri, Jul 04, 2014 at 12:06:41PM +0200, Ondřej Surý wrote:
> it's up to you to lower the severity of the bug to "important" (I guess
> since it will break with default init system).

I'd call it "wishlist" at most.  The package is still perfectly working with
sysvinit (including openrc).

If you can't or don't want to code systemd support, please add a "Breaks:".

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704152053.gb10...@angband.pl

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Matthias Urlichs]

Hi,

Adam Borowski:
> There was enough trouble when udev needed an in-lockstep upgrade with the
> kernel a few releases back.  If systemd components are going to need such
> forced reboots on a repeated basis, I don't like where this is going.
> 
systemd and its components can re-exec themselves, that's not the problem.

The problem is that along with systemd we're changing a lot of the
supporting infrastructure ("we" here is Upstream, for the most part).

Keeping old low-level interfaces around just to avoid logging out or
rebooting may or may not be something we can do easily. While I'll
certainly be happy to be able to dist-upgrade without a subsequent reboot,
if it turns out that this is not going to be easy to achieve then so be it.

For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to
do *that* without forcing at least a re-login?

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704152805.gk23...@smurf.noris.de

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Scott Kitterman]

On Friday, July 04, 2014 17:28:05 Matthias Urlichs wrote:
> Hi,
> 
> Adam Borowski:
> > There was enough trouble when udev needed an in-lockstep upgrade with the
> > kernel a few releases back.  If systemd components are going to need such
> > forced reboots on a repeated basis, I don't like where this is going.
> 
> systemd and its components can re-exec themselves, that's not the problem.
> 
> The problem is that along with systemd we're changing a lot of the
> supporting infrastructure ("we" here is Upstream, for the most part).

Upstream of what?

> Keeping old low-level interfaces around just to avoid logging out or
> rebooting may or may not be something we can do easily. While I'll
> certainly be happy to be able to dist-upgrade without a subsequent reboot,
> if it turns out that this is not going to be easy to achieve then so be it.
> 
> For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to
> do *that* without forcing at least a re-login?

Just because it can't be avoided completely, doesn't mean it shouldn't be 
minimized.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/9964234.g258putz8I@scott-latitude-e6320

Re: RFH: Re: Bug#752075: daemontools-run: Add systemd support

[Milan P. Stanic]

On Fri, 2014-07-04 at 15:55, Michael Biebl wrote:
> Am 04.07.2014 15:22, schrieb Milan P. Stanic:
> > And for runit:
> Thanks for sharing.
> 
> > cat /etc/systemd/system/runit.service
> > [Unit]
> > Description=runit svscan
> > After=syslog.target
> 
> The After=syslog.target is no longer necessary and not recommended
> anymore. Lintian will actually complain about that.
> Syslog is started via socket activation nowadays making this explicit
> ordering obsolete.

Nice to know. Tnx.

> > 
> > [Service]
> > ExecStart=/usr/bin/runsvdir -P /etc/service 'log: 
> > ...'
> > 
> > [Install]
> > WantedBy=networking.service
> 
> Services should be hooked up in targets. So WantedBy=networking.service
> looks wrong.
> 
> In the vast majority of cases you want WantedBy=multi-user.target

My point was not to show perfect systemd unit for runit but to show that
it is really easy to write it. It took me one minute to write and test it
and I don't know much about systemd units.

-- 
Kind regards,  Milan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704155049.ga32...@arvanta.net

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/04/2014 11:28 AM, Matthias Urlichs wrote:

> Hi,
> 
> Adam Borowski:
>> There was enough trouble when udev needed an in-lockstep upgrade with the
>> kernel a few releases back.  If systemd components are going to need such
>> forced reboots on a repeated basis, I don't like where this is going.
>> 
> systemd and its components can re-exec themselves, that's not the problem.
> 
> The problem is that along with systemd we're changing a lot of the
> supporting infrastructure ("we" here is Upstream, for the most part).
> 
> Keeping old low-level interfaces around just to avoid logging out or
> rebooting may or may not be something we can do easily. While I'll
> certainly be happy to be able to dist-upgrade without a subsequent reboot,
> if it turns out that this is not going to be easy to achieve then so be it.
> 
> For Zurg (Jessie+1),

Has that name actually been formalized in any way? I still like it, but
last I heard it wasn't officially anything more than a misunderstanding
and a joke.

> we're likely to switch to Wayland. How do you plan to do *that*
> without forcing at least a re-login?

It seems unlikely that that "switch" will involve removing X entirely,
since many things will still rely on X, even if the X they rely on ends
up getting run nested inside of Wayland (as I believe is a supported
scenario, exactly for backwards-compatibility reasons).

As such, anything that relies on X should still be able to keep working,
as long as the existing X session continues running. It's just that
anything that relies on Wayland won't be able to work until the restart
is done.

- From my perspective, that's perfectly acceptable; everything that was
working before continues to work, but you don't get the new
functionality until you restart.


If that's *not* the case - if things that rely on X will break, or (more
likely) if some of the things which people use will be upgraded from
versions which rely on X to versions which rely on Wayland - then at the
very least a pre-upgrade warning should be provided, with the
opportunity to cancel / postpone the upgrade.

One of the things people have been asking for, when it comes to systemd,
is such a warning in the form of a debconf prompt; however, there seems
to be resistance to that idea, and indeed I'm not sure it hasn't been
outright rejected.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTts+yAAoJEASpNY00KDJru+oP/jmer/NUQ46fexoIW3n2D9BR
fsAaPAIZdh8MciNtdyrxRksev5f5nrCuP8g9Pw8jV9XbXZh2cuS4sJWKwLpqupc5
nl1e2NVAiGu16J74zVrUd97haAPYQ80Vg7D5LXKDH5wqojbXZQ+w44GY3oNbmNG8
oYKArEFgSoIXIR9MWCOz4pMLUegeeS93keZqdQ7I+TPPZc5keif3EZzoib4uDp9v
r3F4L4kvSlSmjvKfZq+DyVrwgSPRMtyoxTK8tXdhLxcUZvlQV6TSFsD9iTGY3piZ
Jja+mVZicFGtBt5iQ/WeC3KGjkyao0/wfmgn26IiIsvPoRIB8a/RKHVmHIi7R+uK
cs/wFCS6jzs1Z5r1QZpT3Bo4smgtAPkSKGhF1ldYBZqZlrn362BN+plSLi1fhQtw
7QOzdl+JI9sbMxWw/WtXqpBlaGKTUJiPoom7oUg+Y+K21AWUNw/ygWbzpB3SHjK8
EGvuSeAFr3E8d9U1tUHNT+Msca9L23aGsreXAh4xnUQOQj60brJLUBodlTVSapGs
DRaNSOE0l/JEn3mQ1tpx0C9b263V4uVf/cOpXpyLBdOpCukSs6UunZ/IgVwUoG7U
3DTuVyKidG2SvGeyQ8nKZyJ2kMbj548+0MGQR9Tvqn/65tklu8tsxnxIK0r/lMlH
IxRJHxEqa+q+4iP1wsvv
=fPU6
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b6cfb2.6030...@fastmail.fm

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Marco d'Itri]

On Jul 04, The Wanderer  wrote:

> This part is precisely what I'm objecting to. I don't consider being
> expected to reboot *in order to maintain existing functionality* after
> an upgrade to be reasonable.
Tough luck for you then, I fear that this is a perception issue.

> At the very least, in the very rare case that rebooting is actually
> required, a prominent pre-install "this install will require you to
> reboot ASAP" notification would be appropriate.
This is reasonable and udev used to do this when appropriate, but it may 
be hard to determine in complex cases like the one being discussed.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)

[Jakub Wilk]

* The Wanderer , 2014-07-04, 12:00:

Zurg (Jessie+1),

Has that name actually been formalized in any way?


No. But no worries, if RT chooses a different name, we'll have a GR to 
override them. :-P


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140704162226.ga1...@jwilk.net

Bug#753367: Solved

[Jeremy Davis]

Install was from USB.  Setup was not removing entry for USB drive from
fstab upon completion of installation.  Removed line for USB from fstab.
Functions normally.

-- 
Jeremy

"You can ignore reality, but you cannot ignore the consequences of ignoring
reality." - Ayn Rand

Re: Bug#752075: daemontools-run: Add systemd support

[Tollef Fog Heen]

]] Adam Borowski 

> On Fri, Jul 04, 2014 at 12:06:41PM +0200, Ondřej Surý wrote:
> > it's up to you to lower the severity of the bug to "important" (I guess
> > since it will break with default init system).
> 
> I'd call it "wishlist" at most.  The package is still perfectly working with
> sysvinit (including openrc).

According to the TC ruling, not supporting a particular init system is,
IIRC, breaking a «should», so normal bug.  I'd possibly argue for
important since it's the default, but it also seem Pape is ok with it
being RC.

> If you can't or don't want to code systemd support, please add a "Breaks:".

No, that's not ok.  Not supporting an init system (with some exceptions)
is not ok for Jessie.

This means that if your daemon relies on using /etc/inittab to start
you, you have at least two bugs against you: systemd and upstart
support.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2tx6wap74@rahvafeir.err.no

Re: systemd is here to stay, get over it now

[Steve Langasek]

Matthias,

On Fri, Jul 04, 2014 at 04:02:38PM +0200, Matthias Urlichs wrote:
> Norbert Preining:
> > > Then shut up and help with the work required to get there,
> > Please stop this inpoliteness, or I request a ban on all mailing lists
> > due to permanent breaking of Code of Conduct.

> *what* Seriously?!?

> One of us seems to harbor a severe misconception or two about what kind of
> behavior the CoC is supposed to sanction, and I sure hope it's not me.

While Thorsten's unconstructive mails evoke much the same reaction from me,
I think you've been very aggressive in this thread (not to mention
dismissive of the legitimate perspectives of those who don't agree that a
move to systemd is an improvement), and "shut up" is an impolite thing to
say.

While I have no interest in joining Norbert in calling for your ban, I would
like to ask you to consider taking a step back from this thread, and
evaluating whether such messages are actually contributing to bringing these
discussions to a conclusion.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd is here to stay, get over it now

[Juliusz Chroboczek]

> While I have no interest in joining Norbert in calling for your ban,

Having had the pleasure to meet Norbert in person, I have no doubt that he
was joking when appealing to the CoC.  (I did find his comment funny --
actually, I find the CoC ifself pretty funny --, but I realise that this
is an international mailing list and that Austrian-Japanese humour is not
necessarily obvious to everyone.)

Coming back to the subject at hand, this thread has been pretty productive
in showing that I'm not alone in wanting my servers and my netbook to run
Debian without systemd (I've given up on my full-fledged desktops, for
better or worse), and in showing that it can be achieved with the existing
mechanisms (apt pinning).  I have good hope that the systemd maintainers
will take this minority of users into account in their further development.

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjgoyhwl.wl@pps.univ-paris-diderot.fr

Introducing vcswatch

[Christoph Berg]

Hi,

I am maintaining too many PostgreSQL packages, and I keep forgetting
which package has changes committed that have not yet been uploaded.

To fix that, there's now a service running at qa.debian.org which
grabs the Sources files from unstable and experimental, notes all
Vcs-* URLs, makes checkouts, and compares the debian/changelog file
seen there with the current version in the archive. The name I came up
with - vcswatch - isn't really smart, but it says what it is about.
The URL is:

https://qa.debian.org/cgi-bin/vcswatch

There's also a DDPO column showing the information.

Basically packages should be in state "OK" (no changes outstandig) or
"NEW" (there's something waiting to be uploaded), everything else is a
problem. "OLD" means that the archive is ahead of the VCS. "UNREL" is
a special case of "OLD" where the versions match, but the changelog in
VCS still has "UNRELEASED". "ERROR" is obviously an error.

Repositories polls are randomized over 20..28h intervals, and are
automatically schedules when a new package version is seen in the
archive. Users can also click the "Scan now" button (or put a wget for
it in their post-whatever hooks) to get a new scan at the next */5
cron interval.

Supported VCS are: Bzr Cvs Darcs Git Hg Mtn Svn. There's a dozen
packages in the archive announcing Arch, but these have all since
moved to Git, and Arch is so weird I gave up on supporting it.

There also some statistics:

VCS Count   OK  NEW OLD UNREL   ERROR
Arch12  0   0   0   0   12
Bzr 199 103 32  40  3   21
Cvs 18  4   0   0   0   14
Darcs   718 368 339 2   0   9
Git 10799   73092224655 61  550
Hg  62  20  4   20  2   16
Mtn 21  16  3   2   0   0
Svn 351716571447170 33  210
26  0   0   0   0   0

(The last line is 26 packages that just have a Vcs-Browser field with
no specific Vcs-*.)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: systemd is here to stay, get over it now

[Tollef Fog Heen]

]] Juliusz Chroboczek 

> > While I have no interest in joining Norbert in calling for your ban,
> 
> Having had the pleasure to meet Norbert in person, I have no doubt that he
> was joking when appealing to the CoC.

I have yet to find mr Preining funny in any of his mails sent to any of
the lists I read.  Humour, except when accompanied with explicit tags of
HERE BE HUMOUR does not work very well on large lists.

> I have good hope that the systemd maintainers will take this minority
> of users into account in their further development.

I (and I believe I speak for all the systemd maintainers) bear no ill
will against non-systemd users and will try to avoid breaking stuff for
them, but it's also a use case we don't hit, so breakage there is less
likely to be seen by us. We'll do our best to fix it when reported, of
course.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2mwcoajxz@rahvafeir.err.no

Re: sysvinit is still here, and here to stay for jessie

[Thorsten Glaser]

Matthias Urlichs wrote:

>For Zurg (Jessie+1), we're likely to switch to Wayland. How do you plan to

We're *what*?

(Says someone who uses X11 forwarding, VNC in, VNC out, and all
that on an almost-, if not daily, basis.)


OT: prevent-systemd-*_9_all.deb are in my repo. Wookey, feel
free to use the changes I made as suggestions for yours.
As usual, Origin/Bugs are repo-specific, and to be removed
for the main archive.

bye,
//mirabilos, who really should sleep


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lp7bc8$a99$1...@ger.gmane.org

Re: systemd is here to stay, get over it now

[Norbert Preining]

> I have yet to find mr Preining funny in any of his mails sent to any of
> the lists I read.  Humour, except when accompanied with explicit tags of
> HERE BE HUMOUR does not work very well on large lists.

Well, because I don't write "WARNING HUMOUR COMING" and then some
people don't get it  bad for them ... good for me .. gives
me more laughs.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140705003821.gc23...@auth.logic.tuwien.ac.at

Re: systemd is here to stay, get over it now

[Juliusz Chroboczek]

Tollef Fog Heen  wrote:

> I [...] will try to avoid breaking stuff

I expect no less from a Debian Developer.

> but it's also a use case we don't hit, so breakage there is less likely
> to be seen by us. We'll do our best to fix it when reported, of course.

That is good to hear.  It would be even better if actions followed.

I'll remind you that this thread started with systemd breaking my system,
and a systemd maintainer summarily closing my bug report.  Not once, but
twice.  Summarily dismisisng non-systemd issues, unfortunately, is the
kind of attitude that we've come to expect from many (not all) systemd
supporters.

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2dky5nl.wl@pps.univ-paris-diderot.fr

Re: systemd is here to stay, get over it now

[Matthias Urlichs]

Hi,

Steve Langasek:
> While I have no interest in joining Norbert in calling for your ban, I would
> like to ask you to consider taking a step back from this thread, and
> evaluating whether such messages are actually contributing to bringing these
> discussions to a conclusion.
> 
Thanks for the honest feedback.
-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140705012101.gl23...@smurf.noris.de

Re: systemd is here to stay, get over it now

[Russ Allbery]

Juliusz Chroboczek  writes:

> I'll remind you that this thread started with systemd breaking my
> system, and a systemd maintainer summarily closing my bug report.  Not
> once, but twice.

Because the bug was already fixed in a newer version of systemd.  While
we're reminding people of things.

> Summarily dismisisng non-systemd issues, unfortunately, is the kind of
> attitude that we've come to expect from many (not all) systemd
> supporters.

I believe the description of what happened as "summarily dismissing" is
factually inaccurate.  In fact, he investigated and confirmed that the bug
was already fixed and closed it accordingly.  You have a legitimate cause
for complaint, which I think has already been heard and registered, that
the response was too terse and that you didn't realize this is what the
response meant, but the problem was not dismissed.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k37stwv6@windlord.stanford.edu

Re: systemd is here to stay, get over it now

[martin f krafft]

also sprach Stephan Seitz  [2014-07-04 15:09 
+0200]:
> But if they don’t want the systemd features why should they write
> software to replace systemd?

Because there are better ways to implement it, including more
granular approaches and less of a desktop focus. And you could be
a better upstream.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"it isn't pollution that's harming the environment.
 it's the impurities in our air and water that are doing it."
  - dan quayle


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Introducing vcswatch

[Andreas Tille]

Hi Christoph,

On Fri, Jul 04, 2014 at 11:04:33PM +0200, Christoph Berg wrote:
> 
> https://qa.debian.org/cgi-bin/vcswatch

Cool!  I wonder whether you could add a field where you can seek for
package maintainer address (since if I can only seek for a package it
does not make much of a difference to look into the repository itself.)

Thanks for doing this interesting investigation which looks quite
helpful

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140705061950.gd19...@an3as.eu

Re: GR - collecting proposals (was Re: systemd is here to stay, get over it now)

[Thomas Goirand]

On 07/04/2014 10:28 PM, Thorsten Glaser wrote:
> 4) all init systems currently in Debian are supported in jessie;

We don't need a GR to support this option. Of course, all init systems
are supported, to the best of our efforts, and I don't see why someone
would refuse a patch. I haven't seen such a behavior so far.

Please don't start a GR with such foolish choice as 1) to 3), where we
may decide to stop supporting alternative init systems. This isn't the
current situation, we just have decided for a default init system, and
that's enough (for now).

Instead, wouldn't you help with alternatives? Like for example, help
with porting upstart to kFreeBSD and Hurd, or help with OpenRC to detach
the parser from the boot system would help (and I haven't found the time
to work on that so far, unfortunately).

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b79b39.4080...@debian.org