Re: default MTA

[Bjørn Mork]

Jean-Christophe Dubacq  writes:

> And in my experience, email tends to be much more fragile than dbus.

The warm fuzzy feeling you get when you don't know there is a
problem... 

> How many times have I suddenly looked
> at the queue of a computer that has been mis-configured and that
> accumulated thousands of email from its system trying to repeatedly warn
> the user that, well, the email smarthost cannot be contacted?

Yes, and dbus would have just dropped the messages that couldn't be
delivered instead of queueing them.


Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8761xzlg2n@nemi.mork.no

Re: Switching to mozilla ESR in stable-security

[Raphael Geissert]

Russ Allbery  debian.org> writes:
[...]
> This would *enable* users to install software from backports if it either
> didn't exist in stable at all or if they explicitly requested it from
> backports, but would not install such software by default.

Packages which, by the way, are not supported by the security team.

Curiously enough, that's the subject that triggered this thread.

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20130531t105043-...@post.gmane.org

Can't find MQ_PRIO_MAX in include

[Fabrice Boissier]

Hello,

I'm trying to use some POSIX MQ on Debian.
I tried my code on Debian, FreeBSD and Cygwin, and it went well.
I encountered a problem on FreeBSD about the maximum priority, then I
searched about a fixed maximum, and I found MQ_PRIO_MAX.
On FreeBSD and Cygwin it works properly, but on Debian, I can't find the
macro MQ_PRIO_MAX.

Precisely :
I included  for the mq_attr definition, mq_open function, ...
And MQ_PRIO_MAX seems to be defined in  in POSIX explanations.
So, I included , and Debian still can't find MQ_PRIO_MAX.
I googled a little, and found it in  !
But if I put "only" , mq_open, mq_close... are undefined.
If I put  and , mq_attr is redefined.
If I put only , MQ_PRIO_MAX is undefined.

How should I found MQ_PRIO_MAX correctly on Debian ?
My CFLAGS are : -W -Wall -Werror -ansi -pedantic
My LDFLAGS are : -lrt
I'm working on a Debian Squeeze (2.6.32-042stab076.8 #1 SMP Tue May 14
20:38:14 MSK 2013 x86_64), with ldd (Debian EGLIBC 2.11.3-4) 2.11.3.

Shouldn't MQ_PRIO_MAX be define in  in the next releases ?

Thank you in advance !

-- 
Fabrice BOISSIER // Metalman

Re: systemd .service file conversion

[Olav Vitters]

On Thu, May 30, 2013 at 01:59:02PM -0700, Steve Langasek wrote:
> I can't speak to other distributions, but in Debian, the systemd maintainers
> are in no position to decide that Debian will agree to rewrite its
> system-level integration code (which works quite well already,

I meant more that:
- systemd coordinates across distributions via specific entry points
- those entry points either fully handle or discuss further or whatever
  is needed
- if you want differences between distributions, then systemd is not a
  good choice
- if you come late to the game, then obviously influencing things is
  more difficult

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531090940.ga4...@bkor.dhs.org

Re: systemd .service file conversion

[Olav Vitters]

On Thu, May 30, 2013 at 10:26:37PM +0200, Marc Haber wrote:
> Of course it won't. Upstream and Red Hat have shown many times that
> they just don't care.

I've already replied with various examples before refuting this.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531091036.gb4...@bkor.dhs.org

Re: Can't find MQ_PRIO_MAX in include

[Neil Williams]

On Fri, 31 May 2013 11:21:15 +0200
Fabrice Boissier  wrote:

> macro MQ_PRIO_MAX.
> How should I found MQ_PRIO_MAX correctly on Debian ?

> Debian Squeeze (2.6.32-042stab076.8 #1 SMP Tue May 14
> 20:38:14 MSK 2013 x86_64), 

So a linux kernel, the match is:

/usr/include/linux/mqueue.h:#define MQ_PRIO_MAX 32768

$ dpkg -S /usr/include/linux/mqueue.h
linux-libc-dev:amd64: /usr/include/linux/mqueue.h

Ensure linux-libc-dev is installed and look for the .h in the linux/
directory.

http://packages.debian.org/search?searchon=contents&keywords=mqueue.h&mode=path&suite=stable&arch=any

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpDkV76JaQ75.pgp
Description: PGP signature

Re: Can't find MQ_PRIO_MAX in include

[Fabrice Boissier]

linux-libc-dev and libc6-dev already installed, and the file
/usr/include/linux/mqueue.h contains MQ_PRIO_MAX and the struct mq_attr.

But the structure mq_attr in /usr/include/linux/mqueue.h is in conflict
with the one declared in the /usr/include/mqueue.h (precisely in
/usr/include/bits/mqueue.h that is included by /usr/include/mqueue.h)

Either MQ_PRIO_MAX and some other constants should be defined in limits.h,
or struct mq_attr shouldn't be defined twice.


2013/5/31 Neil Williams 

> On Fri, 31 May 2013 11:21:15 +0200
> Fabrice Boissier  wrote:
>
> > macro MQ_PRIO_MAX.
> > How should I found MQ_PRIO_MAX correctly on Debian ?
>
> > Debian Squeeze (2.6.32-042stab076.8 #1 SMP Tue May 14
> > 20:38:14 MSK 2013 x86_64),
>
> So a linux kernel, the match is:
>
> /usr/include/linux/mqueue.h:#define MQ_PRIO_MAX 32768
>
> $ dpkg -S /usr/include/linux/mqueue.h
> linux-libc-dev:amd64: /usr/include/linux/mqueue.h
>
> Ensure linux-libc-dev is installed and look for the .h in the linux/
> directory.
>
>
> http://packages.debian.org/search?searchon=contents&keywords=mqueue.h&mode=path&suite=stable&arch=any
>
> --
>
>
> Neil Williams
> =
> http://www.linux.codehelp.co.uk/
>
>


-- 
Fabrice BOISSIER // Metalman
Epita2012 - SRS
root SRS (Fév 2011 - Fév 2012)

Re: Switching to mozilla ESR in stable-security

[Jonas Smedegaard]

Quoting Russ Allbery (2013-05-30 19:56:23)
> Wouter Verhelst  writes:
> > On 30-05-13 19:29, Thomas Goirand wrote:
> 
> >> Maybe the best way forward is to have backports activated by 
> >> default
> 
> > No.
> 
> > If we're going down that route, we might as well give up on doing a 
> > stable release.
> 
> Two issues keep getting confused when people talk about this, so let 
> me try to clarify the way that this was clarified on backport-users.
> 
> The actual proposal in the bug report is to add backports.debian.org 
> to the default sources.list file in the installer, but not otherwise 
> change anything about the backports configuration.  Specifically, the 
> archive would remain NotAutomatic ButAutomaticUpgrades.

If you mean bug#691651 as Cyril suggests (thanks, Cyril!) then I only 
see that bugreport talking about adding commented out line for 
backports.  Not relying on APT hints for "damage control".

Can someone elaborate on those plans?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#710488: ITP: libxmpcore-java -- Adobe XMP Toolkit for Java

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: libxmpcore-java
  Version : 5.1.2
  Upstream Author : Adobe
* URL : http://www.adobe.com/devnet/xmp.html
* License : BSD
  Programming Lang: Java
  Description : Adobe XMP Toolkit for Java

The Extensible Metadata Platform (XMP) provides a standard format
for the creation, processing, and interchange of metadata, for a wide
variety of resources.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531093901.43106.8819.reportbug@debiandev

Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))

[Bastien ROUCARIES]

On Fri, May 31, 2013 at 4:42 AM, brian m. carlson
 wrote:
> On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote:
>> > Cons:
>> >
>> > - not all crypto libraries are equivalent; choosing one will exclude
>> > some functionality provided by others
>>
>> SEE compat layer
>> > - we somehow have to deal with legacy systems that can't convert
>> > - adoption of new software that uses something else is harder
>
> NSS does not support TLS 1.2.  Since RC4 is not used securely in TLS,
> and the only other choice in TLS 1.1 and earlier is block ciphers with
> CBC, this means that there are no secure choices.  I know the lack of
> TLS 1.2 support has caused customers of $DAYJOB endless heartache with
> regard to PCI compliance.

Not true anymore:
https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5

Please open a debian bug

>
> NSS supports fewer algorithms than either OpenSSL or GnuTLS.

Please fill bug:

Gnutls is really crappy about suid
see http://lists.debian.org/debian-devel/2010/03/msg00298.html
See also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941

And openssl has problem about license
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cae2spazib3iezzla-sd3r0ft7ff6pdxkvkrzgxdsn1d7foz...@mail.gmail.com

Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))

[Brian May]

On 31 May 2013 20:19, Bastien ROUCARIES  wrote:

> Gnutls is really crappy about suid
> see http://lists.debian.org/debian-devel/2010/03/msg00298.html


2+ years later or 2 Debian releases later, I would have hoped these issues
would be, somehow, magically, fixed by now :-(

Basically makes libpam-ldap + TLS broken with certain programs.

libnss-ldap is probably also broken, but seems you should be using
libnss-ldapd these days which may (?) avoid these problems.

(I stopped using LDAP for authentication as a direct result of these
problems - hardly a good selling point for Debian; so if something has
changed I may not have noticed)
-- 
Brian May 

Re: default MTA

[Marc Haber]

On Thu, 30 May 2013 23:25:15 +0300, Christian PERRIER
 wrote:
>MTA on average people's desktop machine are point less. Is there
>anyone who is *not* a Linux "geek" to deny this?

Non-Geeks are probably not aware that a system holds many packages of
software that expects to be able to deliver status messages as e-mail
via either /usr/lib/sendmail or tcp port 25 to localhost.

Geeks might be aware that there is relatively few software that can
accept e-mail messages by one of this means and is able to queue such
messages in case the real target is unavailable for some reason and
that is not called MTA.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uin90-0001dd...@swivel.zugschlus.de

Re: default MTA

[Marc Haber]

On Thu, 30 May 2013 20:25:12 -0400, Chris Knadle
 wrote:
>It's somewhat depressing when I ask for the person's email address and their 
>response is "I don't email", and they ask me for my Facebook ID and my 
>response is "I don't use Facebook".  It's a cultural divide that ends up 
>causing an electronic communications divide.

Not ever having used Facebook, what is a facebook ID? From what I have
seen, Facebook uses the real name of people while not having something
that deserves to be called "search", so people looking for Chris Scott
are basically hosed.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uinau-0001dn...@swivel.zugschlus.de

Re: default MTA

[Marc Haber]

On Fri, 31 May 2013 08:41:56 +0200, Jean-Christophe Dubacq
 wrote:
>Le 30/05/2013 18:29, Marc Haber a écrit :
>> On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters 
>> wrote:
>>> Seems the solutions are very focussed on the assumption that things
>>> cannot be changed. E.g. programs currently send email, so email it has
>>> to be forever.
>> 
>> It is not a good idea to drop the way that > 90 % of programs use to
>> deliver messages. I really hate the idea of having a thing as fragile
>> as dbus on a server just to collect status messages.
>
>73.6% of all statistics are made up.

You have a point here. I shold have written the vast majority.

>The way most programs deliver messages is actually syslog.

Which is an epic nightmare to parse automatically if one needs to put
messages in relation to each other and is only readable if all
messages are shorter than, say, 160 characters. Even firewall log
messages are way longer than that already.

> The most
>important of them being the kernel. We've been over it several times. As
>far as I know, the kernel does not send emails.

The kernel does not use syslog as well. It just dumps the messages
into a ring buffer and relies on some user space software to process
those in time. If that user space software fails, messages are
eventually overwritten and lost.

>A utility to scan syslog and convey important information to the user
>would be much more useful than configuring all mailers in Debian to read
>root's local mail by default. 

Alas, I would really love to have such an utility, I would even
participate in crowdfunding such an utiltiy, but it does not exist
yet. MTAs and MUAs exist and work.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uindz-0001df...@swivel.zugschlus.de

Re: How to check for other init systems from sysvinit script

[Philipp Kern]

On Thu, May 30, 2013 at 04:12:45PM -0700, Russ Allbery wrote:
> Vincent Bernat  writes:
> > I still use /etc/init.d/ start by habit and I find it convenient to
> > divert to systemd but I have no strong opinion on this. As long as
> > upstart jobs mask init scripts when booting, we are fine.
> Completely independent of the discussion in this thread, I encourage you
> to get in the habit of using the service program instead because it cleans
> the environment before starting the init script.  I cannot tell you how
> many times I've had to track down odd bugs in daemons that turned out to
> be because they were started by a sysadmin running the init script with
> weird settings in their environment.

Well, if systemd is detected the /etc/init.d/

Re: Debian systemd survey

[Marc Haber]

On Thu, 30 May 2013 13:59:09 -0700, Russ Allbery 
wrote:
>Marc Haber  writes:
>> Russ Allbery  wrote:
>>> Get rid of some of that complexity because it is pointless (you'll find
>>> that much of it is working around inadequacies in sysvinit).
>
>> Explain.
>
>For example, all the PID file handling is working around the inability to
>determine via better mechanisms whether or not the daemon is running.
>Much of the logic for changing users can be eliminated in favor of a
>declarative syntax.  Various logic for determining whether the daemon is
>installed can be handled via a better syntax or by having the base unit
>file not be a configuration file (I prefer the upstart approach here,
>personally).
>
>Also, determining which flags to pass to the daemon from some other
>configuration file, which is a common use of /etc/default files, is a hack
>to work around the fact that an init script is not really user-editable.
>We therefore move the parts that we expect users to change into a
>separate, simpler configuration file to avoid making them brave the
>dangers of the init script and deal with lots of dpkg configuration file
>prompts when we fix bugs in the init script.  But with a systemd or
>upstart configuration file, it becomes reasonable to have the user just
>edit that file directly to pass different parameters to the daemon, since
>the configuration file is already as simple, in many cases, as the
>/etc/default file was.

Agreed.

>>> Get rid of more of it by building a static configuration from the
>>> dynamic configuration when it changes, where appropriate.
>
>> So you are seriously suggesting to add an inotify trigger on the conf.d
>> directory instead of building the configuration right before it is
>> needed?
>
>Could you please find a better way of asking questions than putting a
>bunch of words in someone else's mouth that you clearly find absurd?

I'm going to try that.

>When the source of the configuration is debconf, we know exactly when it
>changes and don't need anything like inotify to know when to rebuild it.

Disagreed, one can change a debconf-generated file manually, thanks to
the debconf-is-not-a-registry mantra and the demand that a debconfed
package needs to read in its configuration before presenting the
debconf questions.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uin12-0001cu...@swivel.zugschlus.de

Re: default MTA

[Marc Haber]

On Thu, 30 May 2013 19:51:04 -0400, Chris Knadle
 wrote:
>For Exim, the one thing I would want to change would be to ship a 
>configuration that by default created an SSL certificate and enabled 
>MAIN_TLS_ENABLE to enable TLS SMTP transfers.

For e-mail coming in from other clients, with the local exim acting as
a server?

Certificates are usually only used in E-Mail when a server
authenticates itself to a client before the client sends its
authentication data. SMTP with client certificates is possible, but I
have only seen this two times in 15 years of running E-Mail servers.

>  [The Postfix package in Debian 
>does this.]  There's documentation and help for doing this for Exim in 
>/usr/share/doc/exim4-base/README.Debian.gz in Section 2.2 though, and so I 
>suspect there's a _reason_ why this isn't the default.

Noone has yet written code to do that, and volunteered to document and
support it.

Personally, I think that before we improve Exim's packaging in Debian
to be an SMTP server, we should first make it easiert to use Exim as a
client with a smart host, thus debconfing the username/password and
authentication scheme. Noone has volunteered to write that code,
either.

>> This wiki page has a nice summary http://wiki.debian.org/DefaultMTA
>
>I think the negative point of "Support community limited outside of Debian" is 
>untrue.  The exim-us...@exim.org mailing list is very active and responsive, 
>and Exim has become the most popular MTA since sometime in 2008.

Agreed, but exim's development speed has considerably slowed down
since Philip Hazel retired. The exim community is still alive, but I'd
say it's in limbo. Which is a real shame.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uinj2-0001ec...@swivel.zugschlus.de

Re: systemd .service file conversion

[Josselin Mouette]

Le jeudi 30 mai 2013 à 22:25 +0200, Marc Haber a écrit : 
> >Do you actually run a kernel other than Linux
> 
> Actually no, but it is a pleasure to see Debian move towards this
> freedom with every new release. 

I disagree with this claim. The wheezy release for kfreebsd is a joke,
and we should end it with jessie unless there are real users.

> systemd would put this freedom farther away than it ever was.

Using a dysfunctional port to justify keeping improvement away from the
ports that our users actually run is, at best, sophistry.

If you don’t like systemd, you need to find another excuse.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370002081.7985.95.camel@pi0307572

Re: Can't find MQ_PRIO_MAX in include

[Ben Hutchings]

On Fri, 2013-05-31 at 11:21 +0200, Fabrice Boissier wrote:
> Hello,
> 
> 
> I'm trying to use some POSIX MQ on Debian.
> 
> I tried my code on Debian, FreeBSD and Cygwin, and it went well.
> 
> I encountered a problem on FreeBSD about the maximum priority, then I
> searched about a fixed maximum, and I found MQ_PRIO_MAX.
> 
> On FreeBSD and Cygwin it works properly, but on Debian, I can't find
> the macro MQ_PRIO_MAX.
[...]

This is not a support forum for Linux development.  But as people have
already started giving you silly answers:

Per POSIX, you cannot assume this macro (or any such constant limit) is
defined, and must use sysconf(_SC_MQ_PRIO_MAX) at run-time if it is not.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.


signature.asc
Description: This is a digitally signed message part

Bug#710506: ITP: derelict3 -- A collection of dynamic D bindings to C libraries, useful for multimedia and game development.

[Matthew Bekkema]

Package: wnpp
Severity: wishlist
Owner: Matthew Bekkema 

* Package name: derelict3
  Version : 0~git20130530
  Upstream Author : Mike Parker 
* URL : https://github.com/aldacron/Derelict3
* License : Boost Software License
  Programming Lang: D
  Description : A collection of dynamic D bindings to C libraries, useful 
for multimedia and game development.

Derelict3 is a collection of D bindings to multimedia and game
development related libraries.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531131235.23664.81979.reportbug@carbon

Re: [clang] Report bugs on packages failing to build with clang

[Sylvestre Ledru]

On 29/05/2013 19:05, Sylvestre Ledru wrote:
> Hello,
> 
> With the recent setup of the parallel build infrastructure using clang
> instead of gcc [1], I would like to start to report
> bugs on packages failing to build with clang (with patches if possible).
> The severity would be minor.
> Of course, I would do that only when the issue is upstream [2].
I started to report them (with patches for now) with minor as severity:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=clang-ftbfs;users=pkg-llvm-t...@lists.alioth.debian.org

Sylvestre


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a8a9fd.5070...@debian.org

Re: systemd .service file conversion

[Uoti Urpala]

Helmut Grohne wrote:
> On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
> > Steve Langasek wrote:
> > > I can't speak to other distributions, but in Debian, the systemd 
> > > maintainers
> > > are in no position to decide that Debian will agree to rewrite its
> > 
> > Focusing on "position to decide" seems less than constructive.
> 
> I believe that you are mistaking Steve's point here. His statement
> appears merely factual to me. And that is what it is. Some of the paths
> you were talking about are explained in the Debian policy as exceptions
> to FHS, and clearly it is not individual maintainers to decide how to
> change the policy.

Individual maintainers are generally not in position to support systemd
in Debian if everyone else opposes, but "you're in no position to
introduce systemd to Debian" would still be less than constructive. I
don't know what you mean by that FHS bit - I don't think anything
under /etc/default is listed as "exception to FHS"? 

> > It makes a lot of sense to standardize those files across distributions.
> > You don't seem to disagree with Debian following the FHS for example (or
> > was your attitude to that "our current paths work quite well already,
> > thankyouverymuch" too?). Why would custom /etc file locations be "the
> > very purpose of Debian's existence" in a way that prohibits
> > standardization, if other filesystem layout isn't?
> 
> Again you appear to have a difficult time getting the argument. The
> purpose outlined was the integration work, not specific paths. Specific
> paths are merely a tool to get there. They can change, but that requires
> a lot of work and usually breaks tons of stuff. Indeed Debian is
> adopting a number of things from different distributions. That is a hard
> thing to do though, even for things that are already defacto standards.
> For example adopting the required filename encoding from Fedora turned
> out to be harder than expected (#701081). So given the work required to
> change such an aspect, the ones who want the change need pretty good
> arguments.

Nothing in Steve Langasek's message mentioned the amount of work. What
he said was "This integration, which is *the very purpose* of Debian's
existence, is not for systemd upstream (or any upstream) to dictate".
Claiming that he was actually making an argument about how difficult the
change would be to implement seems rather far-fetched. Obviously _you_
want to comment on the implementation aspect, but that's not what I was
replying to earlier, and not something I "failed to get".

The argument for changing is pretty obvious: standardization. I think
you're exaggerating the difficulty of changing for most of those files.
I think discussing the difficulty in more detail would not be meaningful
without considering particular cases. Anyway, my position is that
switching to cross-distro locations used by systemd is desirable; I'm
not saying it would have to be done for every file no matter what the
cost if something is particularly hard in practice. Whereas Langasek was
objecting more generally - he was clearly against such changes even if
easily doable.


> > If you think there is something actually wrong with the default choices
> > currently used by systemd, a much more constructive approach would be to
> > get that fixed across distros, rather than have Debian use a different
> > custom layout. Note that standardizing on the current Debian locations
> > across distros would not have been a good choice for the above two
> > files, as they include the rather arbitrary "/default/" path.
> 
> More often than not, there is no wrong with specific naming in
> standards. It just happens that you have to pick one. Indeed systemd
> appears to have come a bit late to the party and Debian has had a
> standard long before. Arguably systemd could be the one opting to adopt
> an existing standard.

I already addressed exactly this point in the text you're replying to:
"Note that standardizing on the current Debian locations across distros
would not have been a good choice for the above two files, ...". There
was good reason to use paths different from the traditional Debian ones
for those two files. Systemd did adopt the Debian location for other
files.

>  (Now this is of course false, because RedHat had
> their own file name policy well before the invention of systemd.)

I'm not sure what you were trying to say here (it's unclear what of your
previous text the "false" refers to). Anyway the systemd goal of more
standard paths meant discarding lots of Red Hat-specific paths too, like
things under /etc/sysinit/ (approximately equivalent to Debian
/etc/default/).

>  This
> is more true for the socket activation API that systemd could have
> reasonably adopted from upstart, but chose not to do.

Didn't systemd actually have a socket activation API before upstart? I
don't remember exactly, but IIRC upstart at least got it rather late and
there was no standard long before systemd.


> >

Re: Can't find MQ_PRIO_MAX in include

[Fabrice Boissier]

2013/5/31 Ben Hutchings 

> On Fri, 2013-05-31 at 11:21 +0200, Fabrice Boissier wrote:
> > Hello,
>
[...]
>
> This is not a support forum for Linux development.  But as people have
> already started giving you silly answers:
>

I previously searched... and nearly nobody uses POSIX MQ (except QNX ?!).
I previously asked on a Debian forum, and nobody could answer...

Per POSIX, you cannot assume this macro (or any such constant limit) is
> defined, and must use sysconf(_SC_MQ_PRIO_MAX) at run-time if it is not.
>

Personally, a twice declaration of a structure is probably not very very
good... ok, that's none of my business, I don't criticize this point.
But, the macro I was searching for is defined in a file, and as a third
developper I can't directly access it during precompilation... why ?
It seems nobody care about POSIX MQ, and it's a little puzzling that Debian
doesn't show the macro in limits.h or mqueue.h, even if it's declared in
some headers.
My point was only to be sure if that was expectable or not.


-- 
Fabrice BOISSIER // Metalman

Re: systemd .service file conversion

[Jeff Epler]

On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
> I disagree with this claim. The wheezy release for kfreebsd is a joke,
> and we should end it with jessie unless there are real users.

What makes me other than a "real user"?  Perhaps some users of Debian
are more equal^Wreal than others.

Jeff


signature.asc
Description: Digital signature

Re: systemd .service file conversion

[Jeff Epler]

On Thu, May 30, 2013 at 09:05:50PM +0200, Olav Vitters wrote:
> Do you actually run a kernel other than Linux and is anything other than
> Linux usable? I can understand it is not nice, but feels like the other
> options are bitrotting anyway.

Yes and yes.  Wheezy kfreebsd amd64 is dandy for server and OK for some
minor graphical desktop stuff (opengl is not in a good state right now,
at least with nvidia hardware: nouveau is no-go due to not having kernel
support and proprietary won't install).  if you want zfs on debian
(which is what I wanted) it's probably a better choice today than debian
linux with zfs-on-linux. (at least, that's the call I made)

There are some odd missing packages and problems, which I've filed a
number of patches for (e.g., three I've done this year are to build
valgrind; to improve gdb threads support; and to build mongodb) others
have recently filled in another missing piece with jdk7 support and I
generally get the sense that there is a core of smart people who are
dedicated to kfreebsd.

The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.

Jeff


signature.asc
Description: Digital signature

Re: systemd .service file conversion

[Игорь Пашев]

2013/5/31 Jeff Epler :
> Yes and yes.  Wheezy kfreebsd amd64 is dandy for server and OK for some
> minor graphical desktop stuff (opengl is not in a good state right now,
> at least with nvidia hardware: nouveau is no-go due to not having kernel
> support and proprietary won't install).  if you want zfs on debian
> (which is what I wanted) it's probably a better choice today than debian
> linux with zfs-on-linux. (at least, that's the call I made)


Debian GNU/kopensolaris is coming too ;-)

As for init system, my point is having different init systems for
different kernels is ok.
Having different init systems for the same kernel is pain in ass.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8wYp-8g_10snjquRMjqhw=9+5s2o6ixh6b7eb1_kn5...@mail.gmail.com

Re: systemd .service file conversion

[Marco d'Itri]

On May 31, Jeff Epler  wrote:

> The idea that somehow users of non-linux kernels don't matter or don't
> even exist as debian users is one of the most frustrating bits of this
> whole thread.
I'm sorry for the three kfreebsd users, but sometimes reality sucks.
Pretending that their needs are as much important as the needs of the 
99% of Debian users who use Linux does not make it true.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: How to check for other init systems from sysvinit script

[Ondřej Surý]

On Thu, May 30, 2013 at 11:00 PM, Ben Hutchings  wrote:

> > Is there some material on wiki.d.o I can use (and if not can
> > somebody prepare it)?
>

What Tollef, you and Steve wrote.

As you can see, even you (asking this question) made a mistake. So I think
it would be a good to have a place to collect the wisdom.

O.
-- 
Ondřej Surý 

Re: systemd .service file conversion

[Olav Vitters]

On Fri, May 31, 2013 at 08:53:07AM -0500, Jeff Epler wrote:
> The idea that somehow users of non-linux kernels don't matter or don't
> even exist as debian users is one of the most frustrating bits of this
> whole thread.

I was just curious, not suggesting. I also asked this on an IRC channel
and heard that basic things like e.g. GNOME is not working. To me, if
you offer a version it should work fully and pass all QA test. I heard
that every package has to ensure that it compiles. Compiling for me is
just a basic thing. Shouldn't be just that, it should work fully and
pass all the QA tests, else it just is not at the same level as other
architectures as x86_64 and so on.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531150822.ga3...@bkor.dhs.org

Re: Debian systemd survey

[Russ Allbery]

Marc Haber  writes:
> Russ Allbery  wrote:

>> When the source of the configuration is debconf, we know exactly when
>> it changes and don't need anything like inotify to know when to rebuild
>> it.

> Disagreed, one can change a debconf-generated file manually, thanks to
> the debconf-is-not-a-registry mantra and the demand that a debconfed
> package needs to read in its configuration before presenting the debconf
> questions.

Correct, which is why I went on to address exactly that question in the
rest of the message to which you are responding.  Because the upstart and
systemd configuration is much more easily parsable and suitable for use
directly as a configuration file due to much simpler structure than init
scripts, we can use it as the repository for configuration data and parse
it in the maintainer scripts to preserve that behavior.

-- 
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: http://lists.debian.org/8738t3jfiy@windlord.stanford.edu

Re: systemd .service file conversion

[Thomas Goirand]

On 05/28/2013 02:37 PM, Helmut Grohne wrote:
> On Mon, May 27, 2013 at 09:13:44AM +0200, Ond??ej Surý wrote:
>> I would be quite happy to write service files for two (systemd, upstart) or
>> three (systemd, upstart, openrc) of those in all my packages[*], if it
>> stops the endless flamewar here. I would also be happy to have the
>> requirement to support two (or three) of them in the Debian policy.
> 
> My major point here was precisely that you are *not* done with just
> writing the service/job descriptions/scripts for all those init systems.
> You'd likely have to patch every single daemon to enable the socket
> activation method for those init systems, that the authors of your
> daemon did not like to use.
> 
> If on the other hand you omit this patching, then that init system
> partially loses one of its selling points. So instead of supporting one
> init system properly, we support four init systems poorly.

Just to make sure I understood.

What selling point are you talking about? Why is it necessary to patch
daemons to have socket activation?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a8cc80.9050...@debian.org

Re: systemd .service file conversion

[Ondřej Surý]

On 31. 5. 2013, at 15:53, Jeff Epler  wrote:
> The idea that somehow users of non-linux kernels don't matter or don't
> even exist as debian users is one of the most frustrating bits of this
> whole thread.

I would happily support any non-linux kernel arch in form of integrating 
patches, but the reality is that Hurd and FreeBSD kernels are just toys.

That doesn't mean the toys are not important (...all work and no play...), they 
are, but they must not stop the inovation. And as we have sacrificed niche 
architecture and made them non-release, we must be also prepared to do the same 
with non-linux kernels if we have to.

Regards,
Ondrej

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/25726a79-ee8b-4bed-a5ad-c42ae925d...@sury.org

Re: How to check for other init systems from sysvinit script

[Ben Hutchings]

On Fri, May 31, 2013 at 05:10:31PM +0200, Ondřej Surý wrote:
> On Thu, May 30, 2013 at 11:00 PM, Ben Hutchings  wrote:
> 
> > > Is there some material on wiki.d.o I can use (and if not can
> > > somebody prepare it)?
> >
> 
> What Tollef, you and Steve wrote.
> 
> As you can see, even you (asking this question) made a mistake.

:-)

> So I think it would be a good to have a place to collect the wisdom.

OK, so please create that page with what you learned from this
thread.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531170726.gw4...@decadent.org.uk

Re: systemd .service file conversion

[Russ Allbery]

Thomas Goirand  writes:
> On 05/28/2013 02:37 PM, Helmut Grohne wrote:

>> My major point here was precisely that you are *not* done with just
>> writing the service/job descriptions/scripts for all those init
>> systems.  You'd likely have to patch every single daemon to enable the
>> socket activation method for those init systems, that the authors of
>> your daemon did not like to use.

>> If on the other hand you omit this patching, then that init system
>> partially loses one of its selling points. So instead of supporting one
>> init system properly, we support four init systems poorly.

> Just to make sure I understood.

> What selling point are you talking about? Why is it necessary to patch
> daemons to have socket activation?

Socket activation is a neat solution to several long-standing problems
with socket-based daemons (either local or network):

1. It's difficult to tell when the daemon is fully initialized and ready
   to accept connections from the network, and therefore to determine
   ordering constraints during startup.  Daemons that fork and background
   themselves are *supposed* to not do that until they're set up to accept
   connections, but many do not follow this rule, and fixing them can be
   non-trivial.  Socket activation bypasses this whole problem by having
   the init system listen on the sockets so that connections are held in
   an accepted state until the daemon finishes spinning up, which mostly
   eliminates the need to worry about ordering and timing constraints
   between the daemons unless there's an actual deadlock.

2. Daemons that can use socket activation *exclusively* can offload a lot
   of complexity around such things as managing both IPv4 and IPv6 socket
   endpoints to well-tested code.

3. It's possible for daemons to crash and be restarted transparently to
   the end user in some situations because the socket can be passed to a
   newly-recovered daemon.  (There are significant limitations here, of
   course, but it does improve robustness for some services.)

4. One can hold off on spawning daemons until they're actually used, which
   can save system resources.

For more details, see:

http://0pointer.de/blog/projects/socket-activation.html

It's basically an abstraction and generalization of the inetd concept,
making it work with a much wider array of socket-based services.

Note that upstreams are going to start supporting this regardless of what
Debian does, to work better on Red Hat systems.  For example, I plan on
adding support for socket activation to the network services for which I'm
upstream.  There's really no reason not to, and the code required is
fairly simple.

-- 
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: http://lists.debian.org/87bo7rhypb@windlord.stanford.edu

Re: systemd .service file conversion

[Ben Hutchings]

On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote:
> On 31. 5. 2013, at 15:53, Jeff Epler  wrote:
> > The idea that somehow users of non-linux kernels don't matter or don't
> > even exist as debian users is one of the most frustrating bits of this
> > whole thread.
> 
> I would happily support any non-linux kernel arch in form of integrating 
> patches, but the reality is that Hurd and FreeBSD kernels are just toys.
> 
> That doesn't mean the toys are not important (...all work and no play...), 
> they are, but they must not stop the inovation.
[...]

Please don't talk about 'innovation' in Linux.  There really isn't
anything particularly new going on here, just incremental development
of useful features.  There is also plenty of work being done to add
new features to the FreeBSD kernel (not all of which gets merged back
into it) and apparently a fair amount on Hurd.  Their major weakness
at the moment is in hardware support (this is an extremely weak point
for Hurd), and that can mostly be dealt with by making them work
efficiently in VMs.

The real problem we have is that these three kernels are not matching
each other's features, and if we want to run mostly the same userland
on all of them then it can only rely on the common subset of features.
That potentially leaves Debian trailing behind Linux-only
distributions that aren't limited in this way.

I think it makes more sense for all the non-Linux kernels to be
supported through debian-ports, allowing porters to apply kernel-
specific workaround patches, drop unsupportable packages, and release
on their own schedule.  There is a risk, of course, that this results
in continuing divergence if patches don't get fed 'upstream' to the
main Debian archive.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531170441.gv4...@decadent.org.uk

Re: systemd .service file conversion

[brian m. carlson]

On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote:
> That doesn't mean the toys are not important (...all work and no
> play...), they are, but they must not stop the inovation. And as we
> have sacrificed niche architecture and made them non-release, we must
> be also prepared to do the same with non-linux kernels if we have to.

With regard to innovation, FreeBSD has had integration between traffic
control and the firewall in pf for a long time.  Linux still requires
that you assign arbitrary integers as markers and keep them in sync
between two different sets of configuration files, and I have never seen
a tool to handle this automatically.  pf also has had passive OS
fingerprinting far longer than Linux has, and it is well-documented and
works almost out of the box, unlike iptables on Linux.

I would argue that the FreeBSD (and originally, OpenBSD) kernels are far
more innovative (and far easier to use) in this respect.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))

[brian m. carlson]

On Fri, May 31, 2013 at 12:19:27PM +0200, Bastien ROUCARIES wrote:
> On Fri, May 31, 2013 at 4:42 AM, brian m. carlson
>  wrote:
> > NSS does not support TLS 1.2.  Since RC4 is not used securely in TLS,
> > and the only other choice in TLS 1.1 and earlier is block ciphers with
> > CBC, this means that there are no secure choices.  I know the lack of
> > TLS 1.2 support has caused customers of $DAYJOB endless heartache with
> > regard to PCI compliance.
> 
> Not true anymore:
> https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5

Upstream bug 480514 is still open, and while it may have landed in the
main HEAD, it is not in any released version, and not in Debian.  It
would be irresponsible to transition to NSS when that would mean a
regression in security for users.

> > NSS supports fewer algorithms than either OpenSSL or GnuTLS.
> 
> Please fill bug:
> 
> Gnutls is really crappy about suid
> see http://lists.debian.org/debian-devel/2010/03/msg00298.html
> See also
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941
> 
> And openssl has problem about license

I'm not saying these problems don't exist, but they have no bearing on
the fact that OpenSSL and GnuTLS support far more algorithms.

Also, it's hard to tell what algorithms and protocols are supported (and
how to use NSS at all), since Debian does not include documentation and
much of the d.m.o documentation is seriously out of date.  We can't
expect everyone to switch to NSS without accurate, maintained, and
distributed documentation.

NSS is also slow to accept patches and new features upstream.  It took
quite a long time to get TLS 1.1 and TLS 1.2 in, even when not having
them in had negative security implications.

Finally, does NSS support OpenSSL-style algorithm specifications to
select the protocols and algorithms used?  Lots of programs expect to be
able to pass this information to the library, and parts of e.g. the
Postfix configuration would fail to work without it.  This functionality
is required for PCI compliance, which I'm sure is something lots of
Debian's users want.

I'm all for crypto consolidation, but only if doing so doesn't cause
regressions in security or functionality.  Right now, that doesn't seem
to be the case.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: systemd .service file conversion

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 31, 2013 at 04:45:49PM +0300, Uoti Urpala wrote:
> >  This
> > is more true for the socket activation API that systemd could have
> > reasonably adopted from upstart, but chose not to do.
> 
> Didn't systemd actually have a socket activation API before upstart? I
> don't remember exactly, but IIRC upstart at least got it rather late and
> there was no standard long before systemd.
Looking at launchpad, it seems so:

Revision ID: james.h...@ubuntu.com-20110606170511-h7cm82b47vsv2y0o
Merge of lp:~jamesodhunt/upstart/upstream-udev+socket-bridges.

...while systemd had socket activation in current form since the beggining.

But chronology is less important then the technical differences between
the two interfaces.

In systemd a socket activated process gets the variable $LISTEN_FDS
and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
The interface is very generic.

In upstart the process gets one socket, with the number given in
the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
there's only one socket, (b) is tied to upstart, and (c) there's only
one socket.

The limitation to one socket is quite constraining, e.g. we like
apache to listen on both 80 and 443, and the requirement for apache to
open the second port itselfs makes it impossible to start apache
unpriviledged.

Zbyszek

[1] 
http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
[2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531185352.gd28...@in.waw.pl

Re: systemd .service file conversion

[Svante Signell]

On Fri, 2013-05-31 at 08:59 -0500, Jeff Epler wrote:
> On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
> > I disagree with this claim. The wheezy release for kfreebsd is a joke,
> > and we should end it with jessie unless there are real users.
> 
> What makes me other than a "real user"?  Perhaps some users of Debian
> are more equal^Wreal than others.

>From 1984 by George Orwell: quoting freely: "Everybody is equal but some
are more equal than others", a pig leader speech :)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370027215.4618.14.camel@PackardBell-PC

Re: systemd .service file conversion

[Svante Signell]

Ah, sorry  wrong book: Animal farm, by the same author George Orwell: :)

1984 is about big brother watching you. (of course both very recommended
these days)

On Fri, 2013-05-31 at 21:06 +0200, Svante Signell wrote:
> On Fri, 2013-05-31 at 08:59 -0500, Jeff Epler wrote:
> > On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
> > > I disagree with this claim. The wheezy release for kfreebsd is a joke,
> > > and we should end it with jessie unless there are real users.
> > 
> > What makes me other than a "real user"?  Perhaps some users of Debian
> > are more equal^Wreal than others.
> 
> From 1984 by George Orwell: quoting freely: "Everybody is equal but some
> are more equal than others", a pig leader speech :)
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370027566.4618.19.camel@PackardBell-PC

Re: systemd .service file conversion

[Svante Signell]

On Fri, 2013-05-31 at 16:33 +0200, Marco d'Itri wrote:
> On May 31, Jeff Epler  wrote:
> 
> > The idea that somehow users of non-linux kernels don't matter or don't
> > even exist as debian users is one of the most frustrating bits of this
> > whole thread.
> I'm sorry for the three kfreebsd users, but sometimes reality sucks.
> Pretending that their needs are as much important as the needs of the 
> 99% of Debian users who use Linux does not make it true.

That's maybe the current situation, I'm one of them. Weren't I counted,
I found more than three? Give it a few years and make the same
statement again, do you dare :) Nothing is ever constant, things evolve
with time, Linux or no Linux.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370028479.4618.26.camel@PackardBell-PC

Re: Bug#708566: library -dev naming policy encourages unnecessary transitions

[Junichi Uekawa]

Hi,

At Mon, 20 May 2013 19:33:43 -0700,
Russ Allbery wrote:
> 
> Guillem Jover  writes:
> 
> > Perhaps, but I think we just lack better documentation and advice when
> > it comes to shared library handling in general.
> 
> > There was an attempt by Junichi Uekawa (CCed) some time ago [L], but
> > AFAIR some people shunned it because supposedly it contained inaccuracies
> > or suboptimal advice (I've to confess I never reviewed it). IMO these
> > should have been corrected instead of trying to banish it from Debian.
> > I think something like that should be revived, reviewed and subsumed
> > into the policy manual or the devref.
> 
> > [L] 
> 
> I'm wholeheartedly in favor of this, and even had some thoughts from time
> to time about helping with (or adopting) that guide and rolling it into
> Policy.  But I haven't been doing a very good job finding time for Debian
> things lately.  I'd love to see someone take this on.

Some preconditions from that time has changed, and major change since
then has been that binary-only uploads are much easier
infrastructure-wise than before that there's less reason to rename a
-dev package than when this was authored about 8 years ago.

The last time I seriously worked on this document was 2006 and in the
hindsight, I was learning this stuff as I wrote this document, there
must be inaccuracies. But I lack the motivation to revise this
document now.

> 
> -- 
> 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: http://lists.debian.org/87wqqe27pq.dancerj%dan...@netfort.gr.jp

Re: systemd .service file conversion

[Roger Lynn]

On 30/05/13 16:30, Matthias Klumpp wrote:
> 2013/5/30 Marco d'Itri :
>> The /etc/ /lib/ /usr/lib/ split with files overriding each other,
>> invented because RPM systems do not prompt the user on package upgrades
>> and Red Hat does not support upgrading to the next major release.
> Well, that might have been one reason, but splitting the conf files
> has other advantages too. I like that I have the original file as
> reference, that I have very small config-override files which can
> easily be backed up, and it also simplifies updates, because I don't
> have to merge diffs of config files, but just need to adjust them
> later, if something has changed.

I prefer to be notified of changes to configuration files during upgrades so
that I know which configurations need updating, rather than just hoping that
the old config will work with the updated package and missing out on any new
options silently introduced in a master configuration file which I can't
even easily diff for updates.

Roger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/evfn7a-03j@silverstone.rilynn.me.uk

Custom Reload command/signal in upstart

[Ondřej Surý]

Hi,

I have tried to rewrite php5-fpm init.d file for systemd and upstart and
ended up with:

cat > php5-fpm.service << EOF
[Unit]
Description=The PHP FastCGI Process Manager
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/php5-fpm.pid
ExecStartPre=sh -c 'if [ -n "$(/usr/sbin/php5-fpm --fpm-config
/etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "\[ERROR\]")" ]; then echo
"Please fix your configuration file..."; /usr/sbin/php5-fpm --f\
pm-config /etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "\[ERROR\]"; exit 1; fi'
ExecStart=/usr/sbin/php5-fpm
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target
EOF

and

cat > php5-fpm.upstart << EOF
# php5-fpm - The PHP FastCGI Process Manager



description "The PHP FastCGI Process Manager"
author "Ondřej Surý "

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [016]

pre-start script
  if [ -n "$(/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf -t
2>&1 | grep "\[ERROR\]")" ]; then
echo "Please fix your configuration file..."
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf -t 2>&1 |
grep "\[ERROR\]"
stop ; exit 1
  fi
end script

respawn
exec /usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
EOF

It's pretty much equivalent with one exception – I need to send USR2 on
reload. Does upstart already have the support for custom reload signals?

Ondrej
-- 
Ondřej Surý 

Re: systemd .service file conversion

[Helmut Grohne]

Dear upstart developers,

debian-devel@l.d.o has been talking about socket activation interfaces.
The technical differences are nicely summarized:

On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
> But chronology is less important then the technical differences between
> the two interfaces.
> 
> In systemd a socket activated process gets the variable $LISTEN_FDS
> and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
> The interface is very generic.
> 
> In upstart the process gets one socket, with the number given in
> the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
> there's only one socket, (b) is tied to upstart, and (c) there's only
> one socket.
> 
> The limitation to one socket is quite constraining, e.g. we like
> apache to listen on both 80 and 443, and the requirement for apache to
> open the second port itselfs makes it impossible to start apache
> unpriviledged.
> 
> Zbyszek
> 
> [1] 
> http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
> [2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html

Is there any chance for upstart to adopt the socket activation interface
from systemd? As has been pointed out above, the interface is more
generic. Having upstart and systemd differentiate on interfaces does not
serve any good. Instead upstart could benefit from daemons already
supporting systemd style socket activation. Having one interface to
socket activation would greatly reduce the amount of integration work to
be done by distributions such as Debian. I am aware that this is kind of
a bike shedding discussion. The value to be gained is the uniformity
though.

If this is not possible, please briefly lay out the reason (or point to
previous discussion of this matter).

Thanks in advance

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531213138.ga15...@alf.mars

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Josh Triplett]

On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote:
> Upstream has changed the license to GPLv3.  It has an additional
> permission to negate any "viral effects", but it only applies to
> packages that include a configuration script generated by GNU
> autoconf.
[...]
> Here is the new license text for config.sub and config.guess:
[...]
>As a special exception to the GNU General Public License, if you
>distribute this file as part of a program that contains a
>configuration script generated by Autoconf, you may include it under
>the same distribution terms that you use for the rest of that
>program.  This Exception is an additional permission under section 7
>of the GNU General Public License, version 3 ("GPLv3").

Interesting choice of wording.  Read literally ("generated by
Autoconf"), this would mean that the exception only applies when you
distribute config.guess or config.sub as part of a source distribution
that includes the generated configure, not just the input configure.ac.
Which should be the case for most source distributions, but it still
seems interesting.

And on the flip side, you could also trivially satisfy this by including
a generated configure script that doesn't actually get used.

In any case, this seems like something we could easily scan for with
lintian or with any of the automatic whole-archive source scanning
tools: just look for a source package that contains config.sub or
config.guess but does *not* contain a configure script (or whose
configure script does not contain "Generated by GNU Autoconf" in its
first few lines).

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531220859.GB12303@jtriplet-mobl1

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Henrique de Moraes Holschuh]

On Fri, 31 May 2013, Josh Triplett wrote:
> On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote:
> > Upstream has changed the license to GPLv3.  It has an additional
> > permission to negate any "viral effects", but it only applies to
> > packages that include a configuration script generated by GNU
> > autoconf.
> [...]
> > Here is the new license text for config.sub and config.guess:
> [...]
> >As a special exception to the GNU General Public License, if you
> >distribute this file as part of a program that contains a
> >configuration script generated by Autoconf, you may include it under
> >the same distribution terms that you use for the rest of that
> >program.  This Exception is an additional permission under section 7
> >of the GNU General Public License, version 3 ("GPLv3").
> 
> Interesting choice of wording.  Read literally ("generated by

Indeed.

> Autoconf"), this would mean that the exception only applies when you
> distribute config.guess or config.sub as part of a source distribution
> that includes the generated configure, not just the input configure.ac.
> Which should be the case for most source distributions, but it still
> seems interesting.
> 
> And on the flip side, you could also trivially satisfy this by including
> a generated configure script that doesn't actually get used.

Yes.  It is not exactly an watertight wording.

I expect this license might be further updated to correct these points,
it is not like we don't have to update config.sub/guess at least once an
year...

So I advise people to stick to the obvious intention behind the license
change, which is that GNU config is to be used by GPLv3 packages and
also by packages that use GNU autoconf/automake regardless of their
license.

> In any case, this seems like something we could easily scan for with
> lintian or with any of the automatic whole-archive source scanning
> tools: just look for a source package that contains config.sub or
> config.guess but does *not* contain a configure script (or whose
> configure script does not contain "Generated by GNU Autoconf" in its
> first few lines).

I will file a bug report with upstream to the effect that the license
should allow distribution under a different license in any case where
GNU autoconf or GNU automake is used, even if the configuration scripts
have not been generated yet.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013053137.ga15...@khazad-dum.debian.net

Re: Custom Reload command/signal in upstart

[Clint Byrum]

On 2013-05-31 14:44, Ondřej Surý wrote:

Hi,

I have tried to rewrite php5-fpm init.d file for systemd and upstart
and ended up with:

cat > php5-fpm.service << EOF

[Unit]
 Description=The PHP FastCGI Process Manager
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/php5-fpm.pid
ExecStartPre=sh -c 'if [ -n "$(/usr/sbin/php5-fpm --fpm-config
/etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "[ERROR]")" ]; then echo
"Please fix your configuration file..."; /usr/sbin/php5-fpm --f
pm-config /etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "[ERROR]"; exit 1; 
fi'

ExecStart=/usr/sbin/php5-fpm
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target
EOF

and

cat > php5-fpm.upstart << EOF

# php5-fpm - The PHP FastCGI Process Manager                        
                                                                     
                                                         

description "The PHP FastCGI Process Manager"
author "Ondřej Surý "

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [016]

pre-start script
  if [ -n "$(/usr/sbin/php5-fpm --fpm-config
/etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "[ERROR]")" ]; then
    echo "Please fix your configuration file..."
    /usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf -t
2>&1 | grep "[ERROR]"
    stop ; exit 1
  fi
end script

respawn
exec /usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
EOF

It's pretty much equivalent with one exception – I need to send USR2
on reload. Does upstart already have the support for custom reload
signals?


It does not have such support. It expects commands to handle HUP as a 
graceful reload. This is one reason apache has never been redone as an 
upstart job. I believe postfix also does not respond well to HUP.


This suggests more custom actions be added:

https://bugs.launchpad.net/upstart/+bug/94873

And this suggests just being able to change the signal:

https://bugs.launchpad.net/upstart/+bug/893021


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a76d807461c8a2fd1150c560256ac...@secure.spamaps.org

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Russ Allbery]

Josh Triplett  writes:
> On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote:

>> Upstream has changed the license to GPLv3.  It has an additional
>> permission to negate any "viral effects", but it only applies to
>> packages that include a configuration script generated by GNU
>> autoconf.
> [...]
>> Here is the new license text for config.sub and config.guess:
> [...]
>>As a special exception to the GNU General Public License, if you
>>distribute this file as part of a program that contains a
>>configuration script generated by Autoconf, you may include it under
>>the same distribution terms that you use for the rest of that
>>program.  This Exception is an additional permission under section 7
>>of the GNU General Public License, version 3 ("GPLv3").

> Interesting choice of wording.  Read literally ("generated by
> Autoconf"), this would mean that the exception only applies when you
> distribute config.guess or config.sub as part of a source distribution
> that includes the generated configure, not just the input configure.ac.
> Which should be the case for most source distributions, but it still
> seems interesting.

I suspect that most distributions that don't include the generated
configure script also don't include config.{sub,guess} and rely on
autoreconf to copy those files in from some system location.

Also, it's worth noting that config.{sub,guess} are standalone shell
scripts that are invoked as independent programs, and are not linked into
or included in any other work in all their usages of which I'm aware, so
the change of license has very little effect.  Given that they are shell
scripts, they are their own source code, so as far as I can tell all the
requirements of the GPLv3 are trivially satisfied even if you include them
as part of the build system of entirely non-free software provided that
you include a copy of the GPLv3 somewhere.

I have a hard time imagining any situation in which this licensing change
has any practical impact.

-- 
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: http://lists.debian.org/87sj1294a7@windlord.stanford.edu

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Jakub Wilk]

* Henrique de Moraes Holschuh , 2013-05-31, 18:44:
As a special exception to the GNU General Public License, if you 
distribute this file as part of a program that contains a configuration 
script generated by Autoconf, you may include it under the same 
distribution terms that you use for the rest of that program.


So I can distribute this file under the terms of GPLv2, but only if 
$something. What about §6 of said license? (“You may not impose any 
further restrictions on the recipients' exercise of the rights granted 
herein.”)


--
Jakub Wilk


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

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Russ Allbery]

Jakub Wilk  writes:
> * Henrique de Moraes Holschuh , 2013-05-31, 18:44:

>> As a special exception to the GNU General Public License, if you
>> distribute this file as part of a program that contains a configuration
>> script generated by Autoconf, you may include it under the same
>> distribution terms that you use for the rest of that program.

> So I can distribute this file under the terms of GPLv2, but only if
> $something. What about §6 of said license? (“You may not impose any
> further restrictions on the recipients' exercise of the rights granted
> herein.”)

My understanding of the way this license provision works is that if you do
$something, you are permitted to relicense the file.  Once you've
relicensed the file, the new license is in effect and you can forget about
the old license entirely, even if you stop doing $something.  I think
that's the only way this *can* make sense, since the receipient of your
pure-GPLv2 distribution can reuse everything in that distribution under
the terms of the GPLv2; if they couldn't, then you wouldn't *actually* be
"includ[ing] it under the same distribution terms that you use for the
rest of that program."

That does seem to make the condition here pointless.  I don't see any
reason why I couldn't include these scripts in a package licensed under
the Expat license, distribute that package, declare that I am accepting
this condition and distributing the config.{guess,sub} files under the
Expat license, and then take them from that distribution and do anything I
wish with them that satisfies the minimal terms of the Expat license since
I now have Expat-licensed versions of the files.

In other words, I don't get why the FSF didn't just use their standard
all-permissive license in the first place, like they do for the generated
configure script, since I think this trivially reduces to that.

It would be interesting to hear the opinion of FSF legal counsel on the
above.

-- 
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: http://lists.debian.org/87li6u93oe@windlord.stanford.edu

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Josh Triplett]

On Fri, May 31, 2013 at 07:22:37PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 31 May 2013, Josh Triplett wrote:
> > On Fri, May 31, 2013 at 06:44:00PM -0300, Henrique de Moraes Holschuh wrote:
> > > Upstream has changed the license to GPLv3.  It has an additional
> > > permission to negate any "viral effects", but it only applies to
> > > packages that include a configuration script generated by GNU
> > > autoconf.
> > [...]
> > > Here is the new license text for config.sub and config.guess:
> > [...]
> > >As a special exception to the GNU General Public License, if you
> > >distribute this file as part of a program that contains a
> > >configuration script generated by Autoconf, you may include it under
> > >the same distribution terms that you use for the rest of that
> > >program.  This Exception is an additional permission under section 7
> > >of the GNU General Public License, version 3 ("GPLv3").
> > 
> > Interesting choice of wording.  Read literally ("generated by
> 
> Indeed.
> 
> > Autoconf"), this would mean that the exception only applies when you
> > distribute config.guess or config.sub as part of a source distribution
> > that includes the generated configure, not just the input configure.ac.
> > Which should be the case for most source distributions, but it still
> > seems interesting.
> > 
> > And on the flip side, you could also trivially satisfy this by including
> > a generated configure script that doesn't actually get used.
> 
> Yes.  It is not exactly an watertight wording.
> 
> I expect this license might be further updated to correct these points,
> it is not like we don't have to update config.sub/guess at least once an
> year...
> 
> So I advise people to stick to the obvious intention behind the license
> change, which is that GNU config is to be used by GPLv3 packages and
> also by packages that use GNU autoconf/automake regardless of their
> license.

Of course; I didn't intend to suggest taking advantage of that
interesting loophole, just that it existed.

> > In any case, this seems like something we could easily scan for with
> > lintian or with any of the automatic whole-archive source scanning
> > tools: just look for a source package that contains config.sub or
> > config.guess but does *not* contain a configure script (or whose
> > configure script does not contain "Generated by GNU Autoconf" in its
> > first few lines).
> 
> I will file a bug report with upstream to the effect that the license
> should allow distribution under a different license in any case where
> GNU autoconf or GNU automake is used, even if the configuration scripts
> have not been generated yet.

If that happens, the automated check could then also not warn about
packages containing configure.ac or configure.in.  Still seems worth
doing, though.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531224503.GB12741@jtriplet-mobl1

Re: GNU config (config.sub/guess) is now GPLv3 with additional permission

[Henrique de Moraes Holschuh]

On Sat, 01 Jun 2013, Jakub Wilk wrote:
> * Henrique de Moraes Holschuh , 2013-05-31, 18:44:
> >As a special exception to the GNU General Public License, if you
> >distribute this file as part of a program that contains a
> >configuration script generated by Autoconf, you may include it
> >under the same distribution terms that you use for the rest of
> >that program.
> 
> So I can distribute this file under the terms of GPLv2, but only if
> $something. What about §6 of said license? (“You may not impose any
> further restrictions on the recipients' exercise of the rights
> granted herein.”)

Well, the $something is "you don't change the build system to stop using
autoconf while still retaining config.sub or config.guess".

I am not sure it matters at all (clearly upstream seems to think that it
should/might), but I'd be very hard pressed to think that $something is
enough to be a problem for GPLv2.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531224607.gb15...@khazad-dum.debian.net

Re: Custom Reload command/signal in upstart

[Steve Langasek]

Hi Ondřej,

On Fri, May 31, 2013 at 11:44:53PM +0200, Ondřej Surý wrote:
> I have tried to rewrite php5-fpm init.d file for systemd and upstart and
> ended up with:

> cat > php5-fpm.service << EOF
> [Unit]
> Description=The PHP FastCGI Process Manager
> After=syslog.target network.target

> [Service]
> Type=forking
> PIDFile=/var/run/php5-fpm.pid
> ExecStartPre=sh -c 'if [ -n "$(/usr/sbin/php5-fpm --fpm-config
> /etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "\[ERROR\]")" ]; then echo
> "Please fix your configuration file..."; /usr/sbin/php5-fpm --f\
> pm-config /etc/php5/fpm/php-fpm.conf -t 2>&1 | grep "\[ERROR\]"; exit 1; fi'
> ExecStart=/usr/sbin/php5-fpm
> ExecReload=/bin/kill -USR2 $MAINPID

> [Install]
> WantedBy=multi-user.target
> EOF

> and

> cat > php5-fpm.upstart << EOF
> # php5-fpm - The PHP FastCGI Process Manager

> description "The PHP FastCGI Process Manager"
> author "Ondřej Surý "

> start on (local-filesystems and net-device-up IFACE!=lo)
> stop on runlevel [016]

FYI, it's strongly recommended to use 'start on runlevel [2345]' here as the
start condition, for several reasons:

 - The 'filesystem' events are one-time events seen only at boot time; if
   the admin drops the system to runlevel 1 and then returns to runlevel 2,
   you probably want the service to restart.
 - The event name is 'local-filesystem', not 'local-filesystems', so this
   job wouldn't auto-start at all.  (FWIW, the 'initctl check-config'
   command from the upstart package would warn about this; but this tool is
   only usable when upstart is the running init, so probably not ideal for
   packagers not running upstart themselves.)
 - The 'local-filesystem' event may be emitted before any remote filesystems
   have been mounted... which might include part or all of /usr and /var.
   So since php5-fpm is itself not a service that is used for mounting
   remote filesystems, it should not try to start until the filesystem is
   completely up.

The 'runlevel' event is later than both the 'local-filesystem' event and the
'net-device-up' events, except in the case where your network interface is
configured with network-manager instead of ifupdown.  So you shouldn't need
to worry about this causing your service to start too "early".

> pre-start script
>   if [ -n "$(/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf -t 
> 2>&1 | grep "\[ERROR\]")" ]; then
> echo "Please fix your configuration file..."
> /usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf -t 2>&1 |
> grep "\[ERROR\]"
> stop ; exit 1
>   fi
> end script

Unrelated style comment - you could write this to call php5-fpm -t a single
time:

  pre-start script
errors=$(/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf -t 2>&1 
| grep "\[ERROR\]")
if [ -n "$errors" ]; then
  echo "Please fix your configuration file..."
  echo $errors
  stop ; exit 1
fi
  end script

Also, the 'exit 1' is unnecessary; the 'stop' is sufficient to ensure the
job stops, all the 'exit 1' does is result in additional log spam.

> respawn
> exec /usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
> EOF

> It's pretty much equivalent with one exception – I need to send USR2 on
> reload. Does upstart already have the support for custom reload signals?

Presently not, as Clint mentions - though I see Dmitrijs has just claimed
https://bugs.launchpad.net/upstart/+bug/893021 for himself in response to
this thread. :)

-- 
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: [clang] Report bugs on packages failing to build with clang

[Michael Tautschnig]

Hi Sylvestre,

[...]
> I started to report them (with patches for now) with minor as severity:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=clang-ftbfs;users=pkg-llvm-t...@lists.alioth.debian.org
> 

You might want to take a look at

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@debian.org&tag=goto-cc

as quite a few more could deserve a usertag of yours, much like you already did
for aconnectgui. At least I can see the bugs filed against

coriander
cdecl
tpb
ax25-tools
pcp
r-cran-xml

are causing build failures with clang as well.

Best,
Michael



pgph3YKnJU7CH.pgp
Description: PGP signature

Bug#710584: ITP: mediawiki-mwxml2sql -- Tools to help import MediaWiki XML dumps into database

[wpmirrordev]

Package: wnpp
Severity: wishlist
Owner: wpmirrordev 

* Package name: mediawiki-mwxml2sql
  Version : 0.0.2
  Upstream Author : Ariel T. Glenn 
* URL : 
https://gerrit.wikimedia.org/r/#/admin/projects/operations/dumps
* License : GPL-2.0+
  Programming Lang: C
  Description : Tools to help import MediaWiki XML dumps into database

 Tools for converting MediaWiki XML dumps into a format that can be rapidly
 loaded into a local instance of MediaWiki. 
 
 o mwxml2sql - convert MediaWiki XML dump file into MySQL INSERT commands 
 
 o sql2txt   - convert MySQL INSERT commands to LOAD DATA INFILE commands 
 
 o sqlfilter - filter MySQL INSERT statements with fields matching values 
 
 The Wikimedia Foundation offers wikipedias and wiktionaries in nearly 300
 languages.  About once a month, the WMF publishes dump files of each wiki in
 XML format.  The WMF also publishes a software, MediaWiki, that anyone may use
 to create their own wiki.  MediaWiki can also be used to create a local mirror.
 To build a mirror, one must import an XML dump file into a local instance of
 MediaWiki. These tools are faster than those published with MediaWiki (much
 faster than importDump.php).  Speed is important for mirroring the largest
 wikis such as the `enwiki'.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130601014415.11901.91831.reportbug@darkstar-7.local

Re: How to check for other init systems from sysvinit script

[Thomas Goirand]

On 05/31/2013 04:39 AM, Ondřej Surý wrote:
> Practical question: if I were to support systemd .service, upstart init job 
> and/or OpenRC 

FYI, you meant to write OpenRC runscripts. :)

On 05/31/2013 05:00 AM, Ben Hutchings wrote:
> If I understand correctly, OpenRC doesn't require init to directly
> start services, so on an OpenRC system your script should run in
> the same way it does now.

I believe that's quite right. OpenRC doesn't re-implement sysvinit
anyway, but only sysvrc.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a95793.9080...@debian.org

Re: systemd .service file conversion

[Lennart Poettering]

On Fri, 31.05.13 23:31, Helmut Grohne (hel...@subdivi.de) wrote:

> debian-devel@l.d.o has been talking about socket activation interfaces.
> The technical differences are nicely summarized:
> 
> On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
> > But chronology is less important then the technical differences between
> > the two interfaces.
> > 
> > In systemd a socket activated process gets the variable $LISTEN_FDS
> > and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
> > The interface is very generic.
> > 
> > In upstart the process gets one socket, with the number given in
> > the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
> > there's only one socket, (b) is tied to upstart, and (c) there's only
> > one socket.
> > 
> > The limitation to one socket is quite constraining, e.g. we like
> > apache to listen on both 80 and 443, and the requirement for apache to
> > open the second port itselfs makes it impossible to start apache
> > unpriviledged.
> > 
> > Zbyszek
> > 
> > [1] 
> > http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
> > [2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html
> 
> Is there any chance for upstart to adopt the socket activation interface
> from systemd? As has been pointed out above, the interface is more
> generic. Having upstart and systemd differentiate on interfaces does not
> serve any good. Instead upstart could benefit from daemons already
> supporting systemd style socket activation. Having one interface to
> socket activation would greatly reduce the amount of integration work to
> be done by distributions such as Debian. I am aware that this is kind of
> a bike shedding discussion. The value to be gained is the uniformity
> though.
> 
> If this is not possible, please briefly lay out the reason (or point to
> previous discussion of this matter).

To provide a bit of context: we deliberately designed our socket passing
logic to be generic enough to be implementable elsewhere than systemd
(i.e. we kept it as minimalistic as possible and kept any reference to the
systemd name out of it). I remember even emailing the Upstart guys about
that, but I never got any reply. This was a long long time before Upstart
added socket activation.

Note that what Upstart eventually implemented regarding socket
activation kinda misses the major point of it. 

Socket activation in the launchd/systemd sense is a tool that (among
other things) allows you to get rid of ordering dependencies between clients
and servers, and systematically parallelize their startup. 

Here's an example: if you have a syslog daemon and a service that logs
to syslog, then the former is the server, the latter is the client. Now,
let's say you want to start both at boot. In classic init systems you
would have to make sure that you first start the syslog daemon, and only
after that finished initialization -- and hence established the syslog
socket in the file system -- you can go on and start the client. Hence
you need to express this dependency, and if you don't do that you will
lose messages. Now, if you employ socket activation for this, then you'd
first establish the syslog socket from your init system, and then start
the syslog daemon and its client *at the same time*. Since the socket is
known to be established before your two services initialize logging will
always just work -- and you do not have to express any dependency
explicitly anymore! On top of that, parallelization is maximized since
client and server start at the same time, and do not have to wait for
each other (at least until the socket buffer runs full and the client
starts to block, but that hopefully happens relatively late). Things
hence get simpler, and faster at the same time!

Now, if you understood the scheme above then you will have noticed that
socket activation is *not* about lazy activation here. You start both
services early on, and at the same time. You do not wait for an incoming
connection. And that's something Upstart cannot do with its scheme. In
Upstart, since the sockets are part of the socket connection event, you
always need the connection to take place first.

Hence: on systemd (and launchd where idea comes from) socket activation
is primarily about getting rid of dependencies and increased
parallelization. And secondarily about lazy activation. On Upstart
however socket activation is about lazy activtion and nothing else.

In my eyes this makes socket activation in Upstart pretty much 
uninteresting and misses the major point of it. (Well, at least to the
level I understood Upstart. Maybe I totally missed how it works, but
from the docs, it appears it cannot create the listening socket, and
then activate its service from any other event than the actual incoming
connection event of it, but still have the listening socket passed to
the service.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


-- 
To UNSUBSCRIBE,

Feedback on Debian 7.0

[Nikolas Kallis]

Hello,



I am just checking out Debian 7.0 for the first time and so far I 
overall like it. Among other things, its sleek, I like the colour 
scheme, its completely open source, stable, and I have so far not been 
effected by a bug.


There are a few things I don't like about it though, that I want to 
share in hope the future Debian won't suffer things I found as a problem.



The first issue I had was finding the system requirements for it. I 
eventually found the information, but is was burred deep in a technical 
manual. The information should have been around when I was on route 
obtaining Debian 7.0.


Also. searching 'System requirements' in the search box on Debian 
website return nothing. I've never had success using the search feature.



Another problem is that Debian 7.0's documentation does not correlate 
with Debian 7.0. At no time was I informed that Debian 7.0 is code named 
'Wheezy', and because of this, it was a head fuck for me when I 
approached the documentation, because I didn't know if I was reading the 
correct documentation as I am not in the development circle and as so, 
don't know the code name for Debian 7.0.


This made me especially mad, because Debian 6.0 suffered the same 
problem, and I reported it, yet the problem still exists.


Ubuntu 12.04 LTS is my primary operating system. There are more things I 
dislike about Ubuntu 12.04 LTS than I do Debian 7.0, but its 
documentation is far superior, which is the second reason why I will 
continue using Ubuntu 12.04 LTS because Debian 7.0 requires more time 
than I have on hand to use.


Shitty documentation is one of the biggest killers when it comes to 
software. Its extremely important software developers know this, because 
not everyone is computer literate, and or has enough time to handle 
problems/learn how to do things.



Another thing I am pissed off about is the lack of a graphical 
text-editor being included in Debian 7.0. The last time I checked, my 
calendar said 2013, and as so, would not expect a text-editor not being 
included in a desktop-environment based operating system.


I know there is the 'nano' command line based text-editor included in 
Debian 7.0, but I, along with 99.999% of the world uses their computer 
in a desktop environment, so a text-editor should be included.



Another thing that pisses me off is IceWeasel.
I have read upon the Mozilla-Debian situation, and from what I 
understand Mozilla were not happy that Debian wes tampering with the 
Firefox logo or branding.


I don't know if the person or persons responsible for doing it in the 
past still develop Debian, but Mozilla's flagship suite being barred 
from inclusion is for this reason is immature.


There is nothing wrong with Firefox's logo. I find the reasoning for its 
exclusion freakish and borderline bizarre. If I were to use Debian 7.0 
as my primary operating system I'd be really annoyed that Mozilla 
software is not included. I don't think 99% of Debian uses would mind 
using Firefox with its official branding, and I think the decision made 
was self-centred and selfish, and not in line with what the overall 
user-base wants.
It is unlikely most people use Debian because of deep ideological 
reasons, and I think the decision to bar Mozilla products from Debian 
has done way more harm than good.



There is something else I didn't like, but I can't remember what it was 
and I am out of time.



I look forward to Debian 8.0.



Regards,

Nikolas Kallis


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a9816d.1030...@nikolaskallis.com

Re: Feedback on Debian 7.0

[Russ Allbery]

Thank you for your feedback!

Nikolas Kallis  writes:

> Another thing I am pissed off about is the lack of a graphical
> text-editor being included in Debian 7.0. The last time I checked, my
> calendar said 2013, and as so, would not expect a text-editor not being
> included in a desktop-environment based operating system.

> I know there is the 'nano' command line based text-editor included in
> Debian 7.0, but I, along with 99.999% of the world uses their computer
> in a desktop environment, so a text-editor should be included.

This is another one of those documentation problems, I think.  There are
oodles and oodles and oodles of graphical text editors in Debian.  I bet
there are over twenty different ones, at least.  At least one of them is
included in the default GNOME environment (gedit) and the KDE environment
(Kate), but there are tons of other ones, ranging from old-school ones
like Emacs to much newer editors like Scribes.

How did you try to find one?  It would help us to know where you looked so
that we can figure out how to get this documented in the correct place.

> Another thing that pisses me off is IceWeasel.
> I have read upon the Mozilla-Debian situation, and from what I understand
> Mozilla were not happy that Debian wes tampering with the Firefox logo or
> branding.

I'm afraid that you've gotten some partial information that's led you to
draw the exact opposite conclusion from what happened.  Debian rebranded
Firefox because the Mozilla Foundation told us we had to and weren't
allowed to include it as Firefox or use the Firefox logo.  Specifically,
they told us we weren't allowed to modify the software in any way
(including applying security patches) without their approval and still
call it Firefox or use the Firefox logo.  As you might imagine, that poses
serious problems for us.  We need to reserve the right to port the
software to some of the platforms that Debian supports that aren't as
common, or fix urgent security issues, or fix problems that have to be
fixed for proper integration with the rest of the operating system.  We
also want to promise to all of our users that all the software included in
Debian is actually free software and they can further modify and
redistribute it as they choose.

This is a really unfortunate situation that no one on either side is
particularly happy with.  What appears to have happened is that other
distributions have partly ignored the exact trademark license terms that
the Mozilla Foundation has set, or at least treated them as a theoretical
issue and decided not to worry about it, and Mozilla has in turn ignored
the fact that they may not necessarily exactly follow them.  Debian as a
project tries to take all license requirements very seriously and follow
them to the letter, and we realized we couldn't promise in all situations
to do that with the Firefox trademarks.  We brought that to the attention
of the Mozilla Foundation, but they weren't willing to change the license
terms.

Other projects have created trademark policies that don't have these
issues, at least to the same degree.  I'm hopeful that the Mozilla
Foundation may eventually change theirs.

> I don't know if the person or persons responsible for doing it in the
> past still develop Debian, but Mozilla's flagship suite being barred
> from inclusion is for this reason is immature.

Please note that Iceweasel in Debian is exactly the same as Firefox as
released by the Mozilla Foundation, just with different branding.  In
other words, we're not barring anything; we *want* to package their
software!  And we do.  However, we weren't allowed to call it Firefox
without accepting a bunch of restrictions on exactly how we package it, so
we package the exact same software, working exactly the same way, but with
a different name and logo to comply with trademark law.

If they told us we could call it Firefox without compromising our ability
to maintain the packages to the quality standards that Debian users
expect, we would happily change the branding back, because we know it's
confusing and frustrating to our users.

-- 
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: http://lists.debian.org/874ndi4byi@windlord.stanford.edu

Re: Feedback on Debian 7.0

[Hashem Nasarat]

On 06/01/2013 01:06 AM, Nikolas Kallis wrote:
>
> Another thing I am pissed off about is the lack of a graphical
> text-editor being included in Debian 7.0. The last time I checked, my
> calendar said 2013, and as so, would not expect a text-editor not
> being included in a desktop-environment based operating system.
>
> I know there is the 'nano' command line based text-editor included in
> Debian 7.0, but I, along with 99.999% of the world uses their computer
> in a desktop environment, so a text-editor should be included.
>
gedit (though it's poorly named) is included


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a98c1e.2040...@gmail.com