Re: libtiff borken - cannot build anymore?

[Didier 'OdyX' Raboud]

Hi Norbert,

Le mercredi, 22 mai 2013 02.20:22, Norbert Preining a écrit :
> On Di, 21 Mai 2013, Thorsten Glaser wrote:
> > resolved *correctly*, with*out* introducing further security
> > issues and RC bugs.
> 
> CAN YOU ALL STOP BITCHING AROUND ABOUT A NON-EXISTING ISSUE?!?!?!?!?!

Could you please stop yelling at debian-devel readers in upper-case and with 
inflated punctuation? Thanks in advance.

Really, the next time you want to communicate your frustration about 
something, avoid doing it on that mailing list; it really doesn't help getting 
your point understood (much to the contrary in my opinion).

Cheers,
OdyX


--
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/201305220855.41334.o...@debian.org

Re: Automated piuparts when entering the archive (Was: Debian development and release: always releasable (essay))

[Andreas Beckmann]

On 2013-05-22 03:53, Michael Gilbert wrote:
> I think the first step would be get get pages like [0] to include
> version numbers of the packages tested (and preferably links to test
> logs).

This should be put into a wishlist bug against piuparts-master ...

  If that were in place, then a patch to britney could block
> testing migrations for those package versions failed their
> wheezy2jessie upgrade test (for example).

special case to consider:
  wheezy -> fail
  wheezy2jessie -> fail
  sid -> pass
Such a package should be allowed to migrate, as it fixes an
"uninstallable" package.
And it should be possible for the RT to add overrides to ignore a
(minor) piuparts failure.


Andreas


-- 
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/519c71b7.7060...@debian.org

Re: Debian systemd survey

[John Paul Adrian Glaubitz]

On 05/21/2013 10:53 PM, Lucas Nussbaum wrote:


- Neither systemd nor upstart are likely to be ported to kfreebsd soon,
   as they both rely on many Linux-specific features and interfaces.


What about launchd? Wouldn't it be possible to port that to
Debian/kFreeBSD? It's designed to run in a BSD userland, after all.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/519c7077.5040...@physik.fu-berlin.de

Re: On advocating NM applicants

[Thorsten Glaser]

Jonathan Wiltshire (Front Desk  debian.org> writes:

> 3. Choose something appropriate from the links at the top right of the
>page. "Advocate for DD" is normally what you're after.

Can’t see that. (I tried a half dozen people just to confirm…)

bye,
//mirabilos


-- 
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.20130522t095801-...@post.gmane.org

Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers

[Tollef Fog Heen]

]] Dmitry Papchenkoff 

> Additionally, there was requests for packaging for xssstatus, which is
> (by upstream) a part of suckless-tools too, but (as for other
> suckless-tools) have separate tarball. For example, if xsstools will
> be included in main package, then «tools for minimalist window
> managers» will depend on xscreensaver even if they also includes dumb
> x locker. So, at least two or three of the tools already have reasons
> for making separate packages for them, that's not good — it's better
> then packages for one vendor organized in some common way.

You don't need to depend if only a minor functionality of the package
depends on some other package, a suggests is fine.  See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517

With 3.0 (quilt), you can have multiple upstream tarballs too.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4gzbg3s@qurzaw.varnish-software.com

Re: simplifying running piuparts

[Andreas Beckmann]

Hi Charles,

On 2013-05-22 06:05, Charles Plessy wrote:
> it is not fully related to your original question, but do you think that 
> piuparts
> could support running Autopkgtests as well ?

Theoretically yes, but I haven't looked into DEP8 so far ... reading ...

Quoting from the autopkgtest specification:
> The cwd of each test is guaranteed to be the root of the source
> package, which will have been unpacked but not built.  HOWEVER note

Since piuparts does not know about "source packages", this may be a bit
more difficult.
But it looks like it could be rather easy to have an --autopkgtest
option for pbuilder/sbuild as they already have the matching sources at
hand. And it could be done together with the archive wide rebuilds done
by Lucas.



Andreas


-- 
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/519c7785.80...@debian.org

Re: libtiff borken - cannot build anymore?

[Ondřej Surý]

JFTR I already realized that and the new libgd2 upload has only
libtiff-dev as B-D and D.

Ondrej

On Wed, May 22, 2013 at 8:07 AM, Raphael Hertzog  wrote:
> On Tue, 21 May 2013, Ondřej Surý wrote:
>> I did:
>>
>> $ grep tiff debian/control
>> B-D: libtiff5-alt-dev | libtiff-dev,
>
> Note that sbuild only considers the first alternative, so libtiff-dev
> would be ignored for bin-nmu on official buildds.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Get the Debian Administrator's Handbook:
> → http://debian-handbook.info/get/
>
>
> --
> 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/20130522060717.gb12...@x230-buxy.home.ouaza.com
>



-- 
Ondřej Surý 


--
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/CALjhHG83_xZ=sx1Fbi=�sqvcldcp9msomjwyvl-g6oncl...@mail.gmail.com

Re: libtiff borken - cannot build anymore?

[Thorsten Glaser]

Norbert Preining  logic.at> writes:

> > That to prevent is what package relationships are for!
> 
> And? I did lots of test, but forgot that texlive-lang will be in
> the NEW queue, thus full upgrades will not work.

Please anyone else, correct me if I’m wrong, but I see the following
scenario:

Teχ consists of packages “foo” and “bar”. Norbert says he uploaded both
but “bar” sits in the NEW queue, which is why the upgraded “foo” will
not work.

To me, this looks as if “foo” needs a versioned Depends on “bar” *and*
“bar” possibly needs a versioned Breaks against older “foo”.
Or “foo” needs a versioned Breaks against older “bar” and possibly
a(n unversioned) Depends/Recommends/Suggests against “bar”, depending
on the scenario.

Forgetting that things could sit in the NEW queue is no excuse, as
partial upgrades are supported by Debian.

Or did I understand the issue wrong? If so, you have my apologies, Norbert.

bye,
//mirabilos


-- 
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.20130522t100543-...@post.gmane.org

Re: libtiff borken - cannot build anymore?

[Ondřej Surý]

On Wed, May 22, 2013 at 10:09 AM, Thorsten Glaser  wrote:
>> > That to prevent is what package relationships are for!
>>
>> And? I did lots of test, but forgot that texlive-lang will be in
>> the NEW queue, thus full upgrades will not work.
>
> Please anyone else, correct me if I’m wrong, but I see the following
> scenario:

Do a full analysis of the problem and send a patch, please. Proposing
and solving hypothetical problems on d-d doesn't help anybody or
anything.

O.
--
Ondřej Surý 


--
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/caljhhg8ztutknn+xzyk8_c3n4auqn-hpeumkqnxrwrtr1zp...@mail.gmail.com

Re: Debian systemd survey

[Thorsten Glaser]

John Paul Adrian Glaubitz  physik.fu-berlin.de> writes:

> On 05/21/2013 10:53 PM, Lucas Nussbaum wrote:
> >
> > - Neither systemd nor upstart are likely to be ported to kfreebsd soon,
> >as they both rely on many Linux-specific features and interfaces.

And this is one more reason to continue supporting sysvinit
with file-rc and sysv-rc: having a unique system across kernels.

> What about launchd? Wouldn't it be possible to port that to
> Debian/kFreeBSD? It's designed to run in a BSD userland, after all.

Debian GNU/kFreeBSD has GNU userland, not BSD userland.
That’s why it’s named like that.

bye,
//mirabilos


-- 
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.20130522t100014-...@post.gmane.org

Re: libtiff borken - cannot build anymore?

[Raphael Hertzog]

Hi,

On Wed, 22 May 2013, Thorsten Glaser wrote:
> Teχ consists of packages “foo” and “bar”. Norbert says he uploaded both
> but “bar” sits in the NEW queue, which is why the upgraded “foo” will
> not work.
> 
> To me, this looks as if “foo” needs a versioned Depends on “bar” *and*
> “bar” possibly needs a versioned Breaks against older “foo”.

And this is the case. On my system, texlive-lang-* were not upgraded
and all of tex has been kept back except libkpathsea6 which Norbert
forgot (and this resulted in the breakage).

But that has been quickly fixed in texlive-bin (2013.20130521.30601-1)
and you're now just showing us that you love to waste everyone's time
by discussing things that you didn't bother to look into just to prove
that you have some theoretical knowledge of how things are supposed to
work.

Please stop posting so often on debian-devel unless you have something
interesting to say and unless you have done your homework about the topic
that you're responding too.

TIA.
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20130522083257.ge12...@x230-buxy.home.ouaza.com

Re: Debian systemd survey

[Thorsten Glaser]

Uoti Urpala wrote:

>A related point which I think is very important is the effect of
>Debian's decision on the larger community. Having Linux distributions
>permanently split in systemd and upstart camps would have major costs
>for the overall Linux community.

Actually, in the EU this is called antitrust and considered a good
thing for a “market”, also increasing innovation by open competition.

>Systemd is already guaranteed to live,

Yeah, in a proprietary RedHat world…

>could easily switch to. Maintaining and extending such a split between
>distros should be seen as a big negative, regardless of how upstart

No, it should be seen as a bit *positive*, for the aforementioned
reason as well as for reasons already seen on the list.

>IMO essentially irrelevant distractions such as effects on marginal
>systems like kFreeBSD shouldn't be brought up at all.

Like it or not, but kFreeBSD *is* now part of the ecosystem.
And I still think internal consistency is something desirable,
so sysvinit should stay the default, with other init systems
(yes this does include OpenRC) available for these who want
to use it.

>> As Debian, we have two different problems:
>> 1. We need to decide which init systems we want to support, and how.
>> 2. We need to decide which init system should be the default.

We will have a GR about that.

>I don't think it's at all obvious that it would make sense to support
>more than systemd

Debian is the Universal Operating System, not GNOME OS.
If you want to develop GNOME OS, please do it as a Derivate
or Blend, or something entirely separate.

Really, reading this makes Roger’s (IIRC) suggestion of removing
it entirely all that more enticing…

>fit-for-use maintenance of all three systems sounds like a rather costly

I see it like with new ports: if a new init system wants to be
supported, they should help the package maintainers along in
providing support, while the individual package maintainers
should be gently encouraged to actually include said patches.
And sysvinit is still the gold standard. (I personally like
BSD stuff more, but from what Debian provides it’s the least
evil or rather the one most people can agree to work with.)

bye,
//mirabilos


-- 
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/knhv7i$3vs$1...@ger.gmane.org

Re: Upstart & kFreeBSD port for Debian

[Dmitrijs Ledkovs]

On 22 May 2013 03:09, Guillem Jover  wrote:
> Hi!
>
> On Wed, 2013-05-22 at 01:47:42 +0100, Dmitrijs Ledkovs wrote:
>> On 22 May 2013 01:16, Michael Biebl  wrote:
>> > Am 22.05.2013 02:00, schrieb Dmitrijs Ledkovs:
>> >> On 21 May 2013 21:53, Lucas Nussbaum  wrote:
>> >>> On 20/05/13 at 18:19 +0200, Michael Stapelberg wrote:
>> >>> - Neither systemd nor upstart are likely to be ported to kfreebsd soon,
>> >>>   as they both rely on many Linux-specific features and interfaces.
>
>> >> Well, Colin Watson, Matthias Klose, Steve Langasek, James Hunt and I
>> >> have discussed the state of the kfreebsd possibility a few times over
>> >> the past year or so.
>
> I started porting libnih and upstart to GNU/kFreeBSD some months ago,
> just for fun, whenever I had nothing else to do. But then I'm not
> interested in assigning my copyright to a for-profit company that is
> not employing me (and no, this is not a job request); so I didn't
> post anything yet, because I don't use upstart, didn't want to promise
> anything (still don't), and it would present as an _interesting_
> situation for the Debian upstart maintainers (either reject the
> patches or carry them forever as a small fork...).
>

For libnih: fork it, push it, merge propose into
https://github.com/keybuk/libnih
As Steve already mentioned, Scott is the upstream for libnih.

>> >> It boiled down to: if we have waitid & inotify it should be possible
>> >> to have a reasonable stab at doing a kfreebsd port for the system-wide
>> >> upstart init (with libnih and mountall). For session init we currently
>> >> do use prctl to set subreaper, but one can still have session upstart
>> >> init without that syscall.
>> >>
>> >> Was there something else needed? Or can anyone else spot other "big
>> >> incompatible" chunks of code?
>> >
>> > https://lists.debian.org/debian-bsd/2009/07/msg00122.html
>
> I think I've posted this multiple times, whenever those items lists
> are posted:
>
>   
>

And somehow I have missed it up until now. Very nice guide. I like it
a lot. Concise pointers =)

Regards,

Dmitrijs.


-- 
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/CANBHLUhwJQKsshXv+_5UkrH=8kyxbdr3vmpr1otl0hu-eij...@mail.gmail.com

Re: jessie release goals

[Vincent Lefevre]

On 2013-05-19 09:17:31 +0200, Jean-Christophe Dubacq wrote:
> Le 16/05/2013 08:43, Vincent Lefevre a écrit :
> > On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote:
> >> No. Your server comes unconfigured, you do configure it while the other
> >> is still working, and then you stop the service on the first, finish
> >> syncing the mailboxes, switch the MX record, and then you can go to
> >> rest.
> > 
> > This is not possible, as I have only one server (which is sufficient
> > for a personal server).
> > 
> If this is a first configuration, then the mail was not working before
> anyway. So you are not losing thousands of emails.
> 
> It this is not, then you are already configured, and debconf will not
> touch your files.

It was a complete reinstallation (not an upgrade). Of course, I could
copy the configuration files. But if there were incompatible changes
in the new version of postfix, things could break. So, I wanted to
restart from clean config files and update them.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130522091835.ga25...@xvii.vinc17.org

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Dmitrijs Ledkovs]

On 22 May 2013 03:32, Paul Tagliamonte  wrote:
> On Wed, May 22, 2013 at 01:16:29AM +0100, Dmitrijs Ledkovs wrote:
>> I have signed Canonical's and Python Software Foundation's contributor
>> agreements.
>> But I have no intention to assign copyright to FSF at the moment,
>> given it's past well documented bad practices at doing things for the
>> sake of it, instead of benefit of the wider free software community.
>
> The FSF's end goal is Free Software[1], whereas Canonical's is cold,
> hard, cash. Nothing wrong with that, but you have to admit that they
> don't really care about ideology or ethics, but providing a distro
> people will use (and buy services / devices / support for).
>
> I don't see how you can see the FSF as worse than Canonical in terms of
> respecting your code and end user freedom.
>
> Relatedly, the PSF is great.
>
> I responded with my Ubuntu address to drive this point home clearly - I
> support what Canonical and Ubuntu are doing; so much, in fact, I've
> spent over 5 years of my life helping make that happen.
>
> That being said, I don't grok your argument.
>
> [1]: OK. Not Free Software as such, but Free Software as a means to an
>  end -- namely, free users.
>

My stance is reverse. IMHO Canonical has done more to promote free
software among people, companies, businesses, non-for-profits,
governments and NGOs than any other free software company or
organisation. It can be seen from the amount of pre-installed machines
shipped with Ubuntu from all Tier-1 hardware vendors and many other
smaller hardware vendors. Oracle is a company with a "cold, hard,
cash" goal. Canonical whilst striving to be self-sustaining, evidently
spends most of its profits/money on new Research&Development be it
Linaro, Unity, Juju or the SaaS offerings like U1 & Landscape suite of
services. Some produce more open source software than others, and all
of these will be ranked differently by each person differently, am I
still yet to be screwed by Canonical's projects. Please correct me if
I am wrong, but none of Canonical CA covered projects yet to (a)
change their license or (b) go proprietary. Since Canonical's CA
inception, it has been modified to grant less rights to canonical and
counter keep more to the authors, thus adjusting the balance based on
community feedback. And more and more software is released as open
source. Contrast with what Oracle has been doing in the past years.

FSF on the other hand:
* GFDL fiasco - because clearly the world cannot live another day
without RMS essay, and oh my one shouldn't generate GCC documentation
from code comments
* SSL licensing - the combination of gnutls going v3 & v3 still being
incompatible with OpenSSL and/or v2
* Clang/LLVM - moving gcc to v3 & thus making Apple contribute/develop
LLVM instead of continuing to use gcc (/me is on gcc camp, thus it's
fsf's negative point. Others might cheer for this move, which gave the
birth to Clang, eventually)
* GNU Project mismanagement/micromanagement - (GnuTLS & sed & others)
https://lwn.net/Articles/529522/  https://lwn.net/Articles/530460/
These are just a few grudges I have against FSF.

I like FSF EU division though.

As you say, "Relatedly, the PSF is great". So CA alone, is really not
a cause or reason for one's actions. In general, I like CAs as it
assigns liability to a 3rd party that can afford lawyers.

Regards,

Dmitrijs.


-- 
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/canbhluiawahrejt6mpr_4c2gjdixpbjw+cjiizthkdyhthu...@mail.gmail.com

Re: On advocating NM applicants

[Cyril Brulebois]

Thorsten Glaser  (22/05/2013):
> Jonathan Wiltshire (Front Desk  debian.org> writes:
> 
> > 3. Choose something appropriate from the links at the top right of the
> >page. "Advocate for DD" is normally what you're after.
> 
> Can’t see that. (I tried a half dozen people just to confirm…)

Look again, picking people that can be advocated for DD. For example:
  https://nm.debian.org/public/people/dm

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#709284: ITP: yorick-gy -- GObject introspection bindings for the Yorick language

[Thibaut Paumard]

Package: wnpp
Severity: wishlist
Owner: Thibaut Paumard 

Hi,

* Package name: yorick-gy
  Version : 0.0.1
  Upstream Author : Thibaut Paumard
* URL : https://github.com/paumard/yorick-gy
* License : GPL
  Programming Lang: C, Yorick
  Description : GObject introspection bindings for the Yorick language

This Yorick plug-in exposes the GObject introspection library to Yorick, with
particular interest in accessing the Gtk library. I propose to package it under
the debian-science umbrella, like the rest of the Yorick packages.

Regards, Thibaut.


-- 
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/20130522104830.11061.12383.report...@tantive-iv.obspm.fr

Re: On advocating NM applicants

[Thorsten Glaser]

Cyril Brulebois  debian.org> writes:

> Thorsten Glaser  debian.org> (22/05/2013):
> > Jonathan Wiltshire (Front Desk  debian.org> writes:
> > 
> > > 3. Choose something appropriate from the links at the top right of the
> > >page. "Advocate for DD" is normally what you're after.
> > 
> > Can’t see that. (I tried a half dozen people just to confirm…)
> 
> Look again, picking people that can be advocated for DD. For example:
>   https://nm.debian.org/public/people/dm

Hm weird. I tried earlier, since my *intent* was on advocating RichiH,
but now it worked, i.e. the link shows up in the upper-right corner,
where it was not previously.

*shrug*

bye,
//mirabilos


-- 
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.20130522t125147-...@post.gmane.org

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Stefano Zacchiroli]

On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote:
> Some produce more open source software than others, and all of these
> will be ranked differently by each person differently, am I still yet
> to be screwed by Canonical's projects. Please correct me if I am
> wrong, but none of Canonical CA covered projects yet to […]

When looking at copyright assignments to companies, the above is hardly
the point, in my opinion. The "problem" (quotes because it's just the
way things are) with companies is that they can be sold and bought, and
the new management can have entirely different objectives, and
strategies to reach it, than the former management you trusted. We have
seen plenty of bad examples of this happening to "open source" companies
in recent years, I'm surprised we haven't learned the lesson yet. Your
"historical record" arguments here say vary little about what could
happen in the future to CAA/CLAs you make to for-profit companies; the
only guarantees you have are the terms of the agreements.

Arguably, risks of changes in objectives and strategies exist also for
non-profit organizations. But when they are much lower when those
organizations have clear governance structures and contestable (it is
left to the reader to judge whether FSF fits this definition). Also, the
mere fact that you remove profit from the equation reduces quite a bit
the overall pressure in changing objectives and strategies.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: simplifying running piuparts (was: Re: Debian development and release: always releasable (essay))

[Holger Levsen]

Hi,

On Mittwoch, 22. Mai 2013, Charles Plessy wrote:
> it is not fully related to your original question, but do you think that
> piuparts could support running Autopkgtests as well ?

I think we need another setup for this. Autopkgtests may destroy their 
environment (and might need more than a chroot) so they cannot be fully tested 
in our current piuparts.d.o setup.

I'd rather do autopkgtests with jenkins.d.n (and be very happy to help anyone 
working on them).


cheers,
Holger




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

Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers

[Andrew Shadura]

Hello,

On Wed, 22 May 2013 00:11:20 +0400
Dmitry Papchenkoff  wrote:

> 10 packages, excluding metapackage.
> This work was originally done for test-packages for mentors.debian.net
> as an effort to update and clean up suckless-tools.
> But after posting packages to mentors I was requested to make
> ITP-bugs for it. So, I'll post ITP just for two packages and wait if
> maintainer or other users find it useful (if any)

I strongly disagree with this proposed split. The package is already
too small for that. This split just adds unnecessary complexity and
bloats the package manager lists, and also confuses users. Please don't.


-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#709294: ITP: fitsverify -- FITS File Format-Verification Tool

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org

* Package name: fitsverify
  Version : 4.16
  Upstream Author : NASA HEASARC
* URL :
http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/
* License : BSD (have to verify)
  Programming Lang: C
  Description : FITS File Format-Verification Tool

Read one or more input FITS files and verifies that the files conform to
the specifications of the FITS Standard document (known as the
NASA/Science Office of Standards and Technology 'Definition of the
Current  FITS Standard', document number, NOST 100-2.0, available online
 at http://fits.gsfc.nasa.gov/).

This is the stand alone version of the FTOOLS 'fverify' program.  It is
maintained by the HEASARC at NASA/GSFC.

I have setup a git repository at
http://anonscm.debian.org/git/debian-science/packages/fitsverify.git

Best

Ole


-- 
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/519cad8e.2090...@liska.ath.cx

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Wouter Verhelst]

On 22-05-13 13:06, Stefano Zacchiroli wrote:
> On Wed, May 22, 2013 at 10:13:23AM +0100, Dmitrijs Ledkovs wrote:
>> Some produce more open source software than others, and all of these
>> will be ranked differently by each person differently, am I still yet
>> to be screwed by Canonical's projects. Please correct me if I am
>> wrong, but none of Canonical CA covered projects yet to […]
> 
> When looking at copyright assignments to companies, the above is hardly
> the point, in my opinion.

No, that is *exactly* the point: yes, companies may have different
objectives, but that doesn't mean they have to use different ways to get
to those objectives.

A contract is binding, whether one party to the contract is a nonprofit,
a company, or a private person; if you receive promises (in writing)
that they won't do a particular thing, and they then go ahead and do it
anyway, you have perfect grounds to sue them for breach of contract.

> The "problem" (quotes because it's just the
> way things are) with companies is that they can be sold and bought, and
> the new management can have entirely different objectives, and
> strategies to reach it, than the former management you trusted.

If you trusted the former management and didn't sign any contract with
them, then that's your own fault, and you got entirely what you deserved.

In contrast, if you signed a well-specified contract with the former
management that specified explicitly what they could and could not do,
and then the new management heads off and does it anyway, you still have
the right to sue them. After all, you signed a contract with the
company, not with the company's management.

> We have
> seen plenty of bad examples of this happening to "open source" companies
> in recent years, I'm surprised we haven't learned the lesson yet.

The lesson, presumably, is "don't trust (non-written) words, trust
contracts".

> Your
> "historical record" arguments here say vary little about what could
> happen in the future to CAA/CLAs you make to for-profit companies; the
> only guarantees you have are the terms of the agreements.

That much, of course, is true.

[...]
> Also, the
> mere fact that you remove profit from the equation reduces quite a bit
> the overall pressure in changing objectives and strategies.

For big multinational companies, perhaps. But not for smaller companies.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/



signature.asc
Description: OpenPGP digital signature

Bug#709295: ITP: seafile -- online file storage and collaboration server

[Ondřej Surý]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" 

* Package name: seafile
  Version : 1.6.1
  Upstream Author : Seafile Ltd. 
* URL : http://seafile.com
* License : GPL3+
  Programming Lang: C
  Description : online file storage and collaboration server

 Seafile enables you to build private cloud for file sharing and
 collaboration among team members in your company/organization. This
 is the client of the seafile system.
 .
 First you create a file library in the web and upload files to
 it. Then you share it into a team or with another user.
 .
 File libraries can also be synchronized among computers and mobile
 devices.  You download a library to your PC. Whenever you add, delete
 or edit a file, the latest version be uploaded to the server
 automatically and then be synchronized to everyone's computer.
 .
 This package contains the seafile server.


-- 
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/20130522115009.7273.8567.reportbug@localhost6.localdomain6

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Holger Levsen]

Hi,

On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote:
> FSF on the other hand:
[...]

You forgot their failure with this "gnu unix system" they were trying to 
build! This also didnt take off - what a bunch of loosers!


cheers,
Holger


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

Re: simplifying running piuparts (was: Re: Debian development and release: always releasable (essay))

[Jakub Wilk]

* Holger Levsen , 2013-05-22, 13:26:
it is not fully related to your original question, but do you think 
that piuparts could support running Autopkgtests as well ?
I think we need another setup for this. Autopkgtests may destroy their 
environment (and might need more than a chroot) so they cannot be fully 
tested in our current piuparts.d.o setup.


FWIW, most of the packages don't need anything more than a chroot.
Out of 116 packages that have DEP-8 tests, only 2 declare the 
breaks-testbed restrictions. (And, AFAICS, even the two with 
breaks-testbed don't currently need stronger isolation.)


--
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/20130522121418.ga3...@jwilk.net

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Stefano Zacchiroli]

On Wed, May 22, 2013 at 01:35:54PM +0200, Wouter Verhelst wrote:
> No, that is *exactly* the point: yes, companies may have different
> objectives, but that doesn't mean they have to use different ways to get
> to those objectives.
> 
> A contract is binding, whether one party to the contract is a nonprofit,
> a company, or a private person; if you receive promises (in writing)
> that they won't do a particular thing, and they then go ahead and do it
> anyway, you have perfect grounds to sue them for breach of contract.

... except that the examples being made were of activities that are
permitted by the terms of the agreement. The discussion was about
whether you should trust that a company won't do in the future
activities that you consider "bad" (but which *are* permitted by the
agreements), based on their past record of not doing so.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: simplifying running piuparts (was: Re: Debian development and release: always releasable (essay))

[Holger Levsen]

On Mittwoch, 22. Mai 2013, Jakub Wilk wrote:
> FWIW, most of the packages don't need anything more than a chroot.

Interesting, thanks.


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

Re: Debian systemd survey

[Tollef Fog Heen]

]] Lucas Nussbaum 

> If I were you, I would be very worried about the risk that the decision
> will be taken not by looking at which one is the best, but by looking at
> which one is de-facto supported in Debian. In that area, systemd is very
> late, since:
> - AFAIK nobody has started the effort to document things in policy
> - there are 300+ upstart job files ready to be imported from Ubuntu
> 
> So, please work on:
> - policy support
> - outlining how systemd and sysvinit can properly co-exist in the archive
>   (this is required in any case for the duration of the transition)
> - outlining how the transition could be achieved, eased, and tracked

We're going to respond to those once the time period for the survey is
up.  Until then, could we please not be having this discussion?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehczrz8n@qurzaw.varnish-software.com

Re: Debian systemd survey

[Josselin Mouette]

Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : 
> - there are 300+ upstart job files ready to be imported from Ubuntu

When you compare the time it takes to write an upstart job file or a
systemd unit file, to the time it takes to proprely test it, I don’t
think this argument makes any sense. If the only things we do for
improving the distribution are to take stuff from Ubuntu because, well,
it’s here, we might as well stop developing anything at all.

-- 
 .''`.  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/1369226754.12592.96.camel@pi0307572

Deciding on init systems (Was: Debian systemd survey)

[Lucas Nussbaum]

On 22/05/13 at 08:22 +, Thorsten Glaser wrote:
> >> As Debian, we have two different problems:
> >> 1. We need to decide which init systems we want to support, and how.
> >> 2. We need to decide which init system should be the default.
> 
> We will have a GR about that.

(I assume that by "about that", you mean (2). For (1), we only need
people to do the work.)

While this is a possible outcome, I think that this is rather unlikely.
If it happens, it would be the most technical GR ever seen so far, and a
failure, as we would not have been able to achieve a decision by other
means.
Also, it would be very inefficient to ask every DD to acquire sufficient
knowledge about init systems to be able to take an informed decision
about that.

Instead, if the decision of which one should be the default is not
consensual by the time we have made sufficient progress on supporting
the various init systems (policy changes, understanding how they can
coexist and how packages can migrate to them), I think that it would be
a good solution to ask the technical committee to decide on that.

Lucas


signature.asc
Description: Digital signature

Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers

[Kartik Mistry]

On Wed, May 22, 2013 at 5:00 PM, Andrew Shadura  wrote:
> I strongly disagree with this proposed split. The package is already
> too small for that. This split just adds unnecessary complexity and
> bloats the package manager lists, and also confuses users. Please don't.

+1.

Dmitry, Have you contact maintainer before proposing split? Please do.
And, package is in collab-maint. Feel free to propose patch(es) to it.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


-- 
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/capdygezfqumpfrn6ttozkfl43bryevpbhycxakz2uvrhu3c...@mail.gmail.com

Re: Debian systemd survey

[Marco d'Itri]

On May 21, Lucas Nussbaum  wrote:

> We don't need to select a single init system at this point, and it would
As the maintainer of a package which is strongly tied to the init 
system, I disagree.

> Then, something I failed to find in the discussion was a discussion of
> how sysvinit / systemd / upstart could co-exist (not on a single system,
> but in the archive).
I suggest that this is related to my first point.

> I understand that systemd replaces some parts of
> initscripts, could also replace syslog, etc. How do systemd supporters
> see that working in practice? What kind of feature duplication between
> init sytems should be expected? How much does it increase the
> maintenance effort?
I am not strictly a systemd supporter but more like a "modern init 
system supporter", and the duplication, increased mainteinance overhead 
and lack of QA are the reasons why I do not want to support multiple 
init systems in my packages and I do not think that Debian should either 
as a project.

> Is it realistic to dream about a generator that would automate the
> generation of sysvinit scripts, systemd .service files, and upstart job
> files for a majority of our packages (the "easy" ones)?
The "easy" ones can continue using sysvinit scripts for a while, since 
they can coexist with both upstart and systemd configurations.
(Maybe better in the systemd case.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers

[Jonathan Dowland]

On Wed, May 22, 2013 at 07:17:34AM +0400, Dmitry Papchenkoff wrote:
> Maybe there should not be a separate package for each tool, but at
> least st and dmenu should be packaged separately.

Why?

> Moreover, there IS a package named stterm in unstable which ships st
> separately (I've found it then published ITP for my version of st). It
> lacks Breaks/Conflicts with suckless-tools 38, but will overwrite it
> files.

It predates suckless-tools in the archive. Therefore, suckless-tools
should have renamed its st binary. Conflicts is not appropriate here.


-- 
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/20130522133146.GA20887@debian

Re: Debian systemd survey

[Bernd Schubert]

On 05/22/2013 04:50 AM, Uoti Urpala wrote:

Lucas Nussbaum wrote:

I went through the various init systems threads again during the last
few days. My understanding of the consensus so far is the following:

- Both systemd and upstart bring many useful features, and are a
   clear improvement over sysvinit.


Yes, both are an improvement over sysvinit.



Hrmm, I have not tested systemd yet, but personally I'm not conviced 
about the advantages of upstart:


- Stops booting *somtimes*, does not provide any information why. I 
didn't report a bug yet as an almost black screen won't help in any way 
how to figure out why it stopped. Already that stops without any further 
information why and where is a sufficiently big design issue, imho.
(Btw, in the mean time I belive this issue is related to /etc/mtab, but 
I'm not sure yet.).


- Updating/install programs in a chroot fails with weird messages that 
those programs (afaik for example X) cannot connect to upstart. Well, it 
is a chroot, what does it expect?


- Personally I'm using unionfs-fuse as very first init script to mount 
/etc and /var and others on my development systems. So no need to modify 
an initrams, but a very simple approach and controllable using a boot 
script. But specifying a script to be run *before* anything else is not 
possible (yet?).




Bernd



--
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/519cca74.9030...@aakef.fastmail.fm

Re: Debian systemd survey

[Guillem Jover]

Hi!

On Wed, 2013-05-22 at 09:15:03 +0200, John Paul Adrian Glaubitz wrote:
> On 05/21/2013 10:53 PM, Lucas Nussbaum wrote:
> >- Neither systemd nor upstart are likely to be ported to kfreebsd soon,
> >   as they both rely on many Linux-specific features and interfaces.
> 
> What about launchd? Wouldn't it be possible to port that to
> Debian/kFreeBSD? It's designed to run in a BSD userland, after all.

launchd relies heavily on Mach and Apple specific interfaces, and while
there was a GSOC to port it to FreeBSD, funnily enough, in the end it
might be easier to port it to GNU/Hurd! :)

Also last I checked the upstream svn repo had not seen any update in a
while, which might mean upstream practices might not be optimal.

Thanks,
Guillem


-- 
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/20130522135758.ga25...@gaara.hadrons.org

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Svante Signell]

On Wed, 2013-05-22 at 13:37 +0200, Holger Levsen wrote:
> Hi,
> 
> On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote:
> > FSF on the other hand:
> [...]
> 
> You forgot their failure with this "gnu unix system" they were trying to 
> build! This also didnt take off - what a bunch of loosers!

It is taking off, albeit slowly: (please join to make it happen faster:)
http://www.debian.org/ports/hurd/hurd-news.en.html
http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hurd_2013.html
http://www.phoronix.com/scan.php?page=news_item&px=MTM3NzA
http://news.slashdot.org/story/13/05/22/120258/debian-gnuhurd-2013-released


-- 
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/1369231279.8127.3.ca...@s1499.it.kth.se

Bug#709317: ITP: cpl-plugin-sinfo -- ESO data reduction pipeline for SINFONI

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org

* Package name: cpl-plugin-sinf
  Version : 2.3.3
  Upstream Author : Andrea Modigliani 
* URL : http://www.eso.org/sci/software/pipelines/sinfo
* License : GPL
  Programming Lang: C
  Description : ESO data reduction pipeline SINFONI

This is the data reduction pipeline for the SINFONI instrument of the
Very Large Telescope (VLT) from the European Southern Observatory (ESO).
.
SINFONI is a near-infrared (1.1 - 2.45 µm) integral field spectrograph
fed by an adaptive optics module, currently installed at the Cassegrain
focus of UT4. The spectrograph operates with 4 gratings (J, H, K, H+K)
providing a spectral resolution around 2000, 3000, 4000 in J, H, K,
respectively, and 1500 in H+K - each wavelength band fitting fully on
the 2048 pixels of the Hawaii 2RG (2kx2k) detector in the dispersion
direction. The spatial resolution is selectable from 0.25", 0.1" to
0.025" per image slice, which corresponds to a field-of-view of 8"x8",
3"x3", or 0.8"x0.8" respectively. The instrument can be also used for
seeing limited open loop observations.


-- 
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/519cd6e3.9020...@liska.ath.cx

Bug#709321: ITP: cpl-plugin-fors -- ESO data reduction pipeline for FORS

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org

* Package name: cpl-plugin-fors
  Version : 4.9.23
  Upstream Author : ESO
* URL : http://www.eso.org/sci/software/pipelines/fors
* License : GPL
  Programming Lang: C
  Description : ESO data reduction pipeline FORS

FORS pipeline recipes for the reduction of data obtained with the FORS1
and FORS2 instruments in the LSS, MOS, MXU, PMOS, and direct imaging
instrument modes.
.
FORS is the visual and near UV FOcal Reducer and low dispersion
Spectrograph for the Very Large Telescope (VLT) of the European Southern
Observatory (ESO). Two versions of FORS have been built, upgraded and
moved to the Cassegrain foci of different telescopes in the past years.
In April 2009, FORS1 was dismounted to make room for X-shooter, so only
FORS2 is in operation. FORS is designed as an all-dioptric instrument
for the wavelength range from 330 nm to 1100 nm and provides an image
scale of 0".25/pixel (or 0".125/pixel with the high resolution
collimator) in the standard readout mode (2x2 binning). FORS2 is
installed on UT1 (Antu) and is by default equipped with a detector
system that is optimised for the red with a very low level of fringes
thanks to a mosaic of two 2k x 4k MIT CCDs (with 15 µm pixels). However,
the blue-optimised detector system that was previously available on
FORS1 has been commissioned on FORS2 and can be requested for Visitor
Mode observation. The geometries of both detector systems are similar,
with the optical axis falling ~30" above the gap and offsets of a few
arc-seconds between the two chips. FORS2 has many modes, including
multi-object spectroscopy with exchangable masks, long-slit
spectroscopy, imaging and spectro-polarimetry and high-time resolution
imaging and spectroscopy.


-- 
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/519cd80f.6020...@liska.ath.cx

Bug#709323: ITP: cpl-plugin-giraf -- ESO data reduction pipeline for GIRAFFE

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org

* Package name: cpl-plugin-giraf
  Version : 2.11
  Upstream Author : Ralf Palsa 
* URL : http://www.eso.org/sci/software/pipelines/giraf
* License : GPL
  Programming Lang: C
  Description : ESO data reduction pipeline for GIRAFFE

This is the data reduction pipeline for the GIRAFFE instrument of the
Very Large Telescope (VLT) from the European Southern Observatory (ESO).
.
GIRAFFE is a medium-high resolution (R=7500-3) spectrograph for the
entire visible range 370-900 nm. GIRAFFE is aimed at carrying out
intermediate and high resolution spectroscopy of galactic and
extragalactic objects having a high spatial density. The name comes from
the first design, where the spectrograph was standing vertically on a
platform.


-- 
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/519cd951.6010...@liska.ath.cx

Bug#709329: ITP: cpl-plugin-amber -- ESO data reduction pipeline for AMBER

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org

* Package name: cpl-plugin-amber
  Version : 4.2.2
  Upstream Author : Armin Gabasch  
* URL : http://www.eso.org/sci/software/pipelines/amber
* License : GPL
  Programming Lang: C
  Description : ESO data reduction pipeline for AMBER

This is the data reduction pipeline for the Amber instrument of the Very
Large Telescope (VLT) from the European Southern Observatory (ESO).
.
AMBER is a near-infrared, multi-beam interferometric instrument,
combining simultaneously up to 3 telescopes. AMBER can be used in Period
82 and following with UTs or ATs (see below for current performance
specifications). All possible triplets of UTs are available, and a
number of selected AT combinations.


-- 
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/519cdb27.6030...@liska.ath.cx

Bug#709330: ITP: cpl-plugin-hawki -- ESO data reduction pipeline for HAWK-I

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-scie...@lists.debian.org

* Package name: cpl-plugin-hawki
  Version : 1.8.12
  Upstream Author : César Enrique García Dabó   
* URL : http://www.eso.org/sci/software/pipelines/hawki
* License : GPL
  Programming Lang: C
  Description : ESO data reduction pipeline for HAWK-I

This is the data reduction pipeline for the HAWK-I instrument of the
Very Large Telescope (VLT) from the European Southern Observatory (ESO).
.
HAWK-I is a near-infrared (0.85-2.5 µm ) wide-field imager. It is being
offered for the first time in Period 81. The instrument is cryogenic
(120 K, detectors at 80 K) and has a full reflective design. The light
passes four mirrors and two filter wheels before hitting a mosaic of
four Hawaii 2RG 2048 * 2048 pixels detectors. The final F-ratio is
F/4.36 ( 1 arcsec on the sky corresponds to 169 µm on the detector).


-- 
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/519cdbca.3000...@liska.ath.cx

Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers

[Vasudev Kamath]

On 14:31 Wed 22 May , Jonathan Dowland wrote:
> On Wed, May 22, 2013 at 07:17:34AM +0400, Dmitry Papchenkoff wrote:
> > Maybe there should not be a separate package for each tool, but at
> > least st and dmenu should be packaged separately.
> 
> Why?
> 
> > Moreover, there IS a package named stterm in unstable which ships st
> > separately (I've found it then published ITP for my version of st). It
> > lacks Breaks/Conflicts with suckless-tools 38, but will overwrite it
> > files.
> 
> It predates suckless-tools in the archive. Therefore, suckless-tools
> should have renamed its st binary. Conflicts is not appropriate here.

Actually both suckless-tools with st and stterm existed together and
still exists together but as Dmitry says stterm doesn't overwrite st
files shipped by suckless-tools, it actually renames st files to
stterm. And new version of suckless-tools in experimental (39) does no
longer have st (will be uploaded soon to unstable).

I already replied to this ITP as I'm the maintainer of suckless-tools
but didn't Cc debian-devel but since the thread is still continuing here
is clarification from my side on the bug report [1]

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709237#28

-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E


signature.asc
Description: Digital signature

Re: Debian launchd survey

[Steve Langasek]

On Wed, May 22, 2013 at 09:15:03AM +0200, John Paul Adrian Glaubitz wrote:
> On 05/21/2013 10:53 PM, Lucas Nussbaum wrote:

> >- Neither systemd nor upstart are likely to be ported to kfreebsd soon,
> >   as they both rely on many Linux-specific features and interfaces.

> What about launchd? Wouldn't it be possible to port that to
> Debian/kFreeBSD? It's designed to run in a BSD userland, after all.

That doesn't seem like it would help at all with the concern about keeping
our userspace aligned across kernels.

-- 
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: Debian systemd survey

[Lucas Nussbaum]

On 22/05/13 at 14:45 +0200, Josselin Mouette wrote:
> Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : 
> > - there are 300+ upstart job files ready to be imported from Ubuntu
> 
> When you compare the time it takes to write an upstart job file or a
> systemd unit file, to the time it takes to proprely test it, I don’t
> think this argument makes any sense. If the only things we do for
> improving the distribution are to take stuff from Ubuntu because, well,
> it’s here, we might as well stop developing anything at all.

Note that if it's there, and Ubuntu uses upstart, it has probably been
tested. I was not suggesting that we blindly import upstart job files
from Ubuntu, but a basis to start from is better than no basis at all.
(I can see how my phrasing was a bit confusing -- sorry about that)

Lucas


-- 
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/20130522154811.ga25...@xanadu.blop.info

using upstart in Debian [was, Re: Debian systemd survey]

[Steve Langasek]

On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote:
> On 05/22/2013 04:50 AM, Uoti Urpala wrote:
> >Lucas Nussbaum wrote:
> >>I went through the various init systems threads again during the last
> >>few days. My understanding of the consensus so far is the following:

> >>- Both systemd and upstart bring many useful features, and are a
> >>   clear improvement over sysvinit.

> >Yes, both are an improvement over sysvinit.

> Hrmm, I have not tested systemd yet, but personally I'm not conviced
> about the advantages of upstart:

> - Stops booting *somtimes*, does not provide any information why. I
> didn't report a bug yet as an almost black screen won't help in any
> way how to figure out why it stopped. Already that stops without any
> further information why and where is a sufficiently big design
> issue, imho.
> (Btw, in the mean time I belive this issue is related to /etc/mtab,
> but I'm not sure yet.).

Sorry you ran into trouble with upstart.  Probably related to /etc/fstab,
rather than /etc/mtab...  Due to incomplete upstart integration of plymouth
in Debian at present, if there are problems in /etc/fstab, mountall won't
always be able to display any prompt to the user asking what to do (cf. 
http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/).

Whereas sysvinit would eventually give up on trying to mount filesystems in
/etc/fstab if they were missing at boot and continue booting without them,
upstart takes the design decision that this is an error that the admin needs
to deal with directly.  This ensures that the system always boots reliably
in the face of "slow" disks, which become more of a problem now that your
init system is so fast that it can boot before your hardware has been
probed.

Feel free to file a bug report against the upstart package (with a copy of
your /etc/fstab attached) so we can look at this further.

> - Updating/install programs in a chroot fails with weird messages
> that those programs (afaik for example X) cannot connect to upstart.
> Well, it is a chroot, what does it expect?

This is bug #685779, which will be fixed in the next upload of sysvinit to
unstable.

> - Personally I'm using unionfs-fuse as very first init script to
> mount /etc and /var and others on my development systems. So no need
> to modify an initrams, but a very simple approach and controllable
> using a boot script. But specifying a script to be run *before*
> anything else is not possible (yet?).

I'm skeptical of the value of such a design in place of just using an
initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of
to do this.  You create an upstart job that's 'start on real-startup-event',
runs your necessary pre-setup, and at the end calls 'initctl emit startup'
to call into the rest of the boot sequence; then you pass
'--startup-event=real-startup-event' to init on the kernel commandline.

-- 
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: Debian systemd survey

[Steve Langasek]

On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote:
> Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : 
> > - there are 300+ upstart job files ready to be imported from Ubuntu

> When you compare the time it takes to write an upstart job file or a
> systemd unit file, to the time it takes to proprely test it, I don’t
> think this argument makes any sense.

Please leave the FUD at the door.  Writing upstart jobs is not difficult;
while there are some gotchas currently with process lifecycle (which will be
fixed soon), there is also very complete documentation (for these issues,
and generally).

  http://upstart.ubuntu.com/cookbook/

> If the only things we do for improving the distribution are to take stuff
> from Ubuntu because, well, it’s here, we might as well stop developing
> anything at all.

Sure; obviously the right thing to do is to instead take stuff from GNOME
and freedesktop.org without regard to integration with our existing system,
because if Lennart says it's right it must be so.

-- 
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: Debian systemd survey

[Matthias Klumpp]

Am 22.05.2013 18:12 schrieb "Lucas Nussbaum" :
>
> On 22/05/13 at 14:45 +0200, Josselin Mouette wrote:
> > Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit :
> > > - there are 300+ upstart job files ready to be imported from Ubuntu
> >
> > When you compare the time it takes to write an upstart job file or a
> > systemd unit file, to the time it takes to proprely test it, I don’t
> > think this argument makes any sense. If the only things we do for
> > improving the distribution are to take stuff from Ubuntu because, well,
> > it’s here, we might as well stop developing anything at all.
>
> Note that if it's there, and Ubuntu uses upstart, it has probably been
> tested. I was not suggesting that we blindly import upstart job files
> from Ubuntu, but a basis to start from is better than no basis at all.
> (I can see how my phrasing was a bit confusing -- sorry about that)
Please also keep in mind that many upstream projects ship systemd service
files. Therefore, most of the systemd work is already done too.
Cheers,
Matthias

Re: Debian systemd survey

[Josselin Mouette]

Le mercredi 22 mai 2013 à 09:41 -0700, Steve Langasek a écrit : 
> On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote:
> > When you compare the time it takes to write an upstart job file or a
> > systemd unit file, to the time it takes to proprely test it, I don’t
> > think this argument makes any sense.
> 
> Please leave the FUD at the door.  Writing upstart jobs is not difficult;
> while there are some gotchas currently with process lifecycle (which will be
> fixed soon), there is also very complete documentation (for these issues,
> and generally).

In which way do you disagree with what I wrote, exactly? Maybe my
English was wrong, so let me explain it in simple words.
Time to write an upstart job = short
Time to write a systemd unit file = short
Time to test an upstart job = long
Time to test a systemd unit file = long

Therefore:
How much we should care of existing upstart jobs = little
How much we should care of existing systemd unit files = little

> > If the only things we do for improving the distribution are to take stuff
> > from Ubuntu because, well, it’s here, we might as well stop developing
> > anything at all.
> 
> Sure; obviously the right thing to do is to instead take stuff from GNOME
> and freedesktop.org without regard to integration with our existing system,
> because if Lennart says it's right it must be so.

Yes of course, because Debian is well-known for using fd.o and GNOME
software as is, without patching it ever, and adopting new technologies
blindly and very quickly, before they are well tested.

Have it ever occurred to you that people might want to see systemd as
default, not because Lennart said it, but because they think it is
better than any alternative? Better than upstart *in the way it
integrates with our existing system*, BTW.

I understand it will be a pain for Ubuntu if Debian picks a different
init system. I don’t think this is relevant for the discussion, though.

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/1369244732.13422.10.camel@tomoyo

Re: libtiff borken - cannot build anymore?

[Jay Berkenbilt]

Russ Allbery  wrote:

> Jay Berkenbilt  writes:
>> Ondřej Surý  wrote:
>
>>> This results in:
>>>
>>> E: libgd-tools: binary-or-shlib-defines-rpath usr/bin/annotate
>>> /usr/lib/x86_64-linux-gnu/libtiff5-alt
>
>> Yes, I'm afraid that's unavoidable.  This issue is mentioned in the
>> README.Debian file.  This works by installing the .so file in a
>> non-standard location so that it can coexist with libtiff4, and linking
>> in that way with libtool the rpath to be embedded.  Once the tiff
>> transition is completed and the packages are rebuilt, this problem will
>> go away.
>
> This shouldn't be required, since the two libtiff shared libraries can
> both go into /usr/lib (since they have different SONAMEs).  The only thing
> that can't go into /usr/lib and has to go somewhere else is the *.so
> symlink, which doesn't require an rpath setting, only a -L flag during
> linking.

The .so files (there are two libraries), static libraries, and .la files
are already the only files in a non-standard location.  Basically only
the files whose names clash are in non-standard locations.  (Tiff still
can't remove its .la file yet, or at least it couldn't though I can't
remember the exact details of when it's okay to remove the .la
fileit has a lot of reverse dependencies  It's the only package
I maintain that still installs .la files.)  I don't remember exactly
what is causing the rpath to appear, but I remember having investigated
it and determined, possibly incorrectly, that I couldn't fix it without
modifying libtool.  I will give it another look.  It is my recollection
that libtool is automatically adding the rpath when it finds the .so
file in a non-standard location since it assumes that the actual shared
library will be in the same directory as the .so file.  In other words,
the rpath is not actually being used hereit is pointing to a place
where the libraries are not found.  I am already adjusting the .so file
manually in the installation to ensure that it points to the correct
place:

$ dpkg --contents libtiff5-alt-dev_4.0.2-6_amd64.deb | fgrep .so
lrwxrwxrwx root/root 0 2013-01-26 12:33 
./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiff.so -> ../libtiff.so.5.1.0
lrwxrwxrwx root/root 0 2013-01-26 12:33 
./usr/lib/x86_64-linux-gnu/libtiff5-alt/libtiffxx.so -> ../libtiffxx.so.5.1.0

> See the krb5-multidev and heimdal-multidev packages for how this is done.

I'll give them a look and see if I can tell what they're doing
differently.

-- 
Jay Berkenbilt 


--
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/20130522141348.0222507418.qww314...@jberkenbilt-linux.appiancorp.com

Re: Debian systemd survey

[Martin Wuertele]

* Josselin Mouette  [2013-05-22 15:03]:

> Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : 
> > - there are 300+ upstart job files ready to be imported from Ubuntu
> 
> When you compare the time it takes to write an upstart job file or a
> systemd unit file, to the time it takes to proprely test it, I don’t
> think this argument makes any sense. If the only things we do for
> improving the distribution are to take stuff from Ubuntu because, well,
> it’s here, we might as well stop developing anything at all.

Actually it sounds like you propose to stop developing and take
everything from Redhat, Lennart, Gnome because it's there and they say
so.

Seems to me that luckily not everybody agrees with that approach (CTTE
#681834, CTTE #688772)...


--
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/20130522175034.gd13...@anguilla.debian.or.at

Re: Debian launchd survey

[John Paul Adrian Glaubitz]

On 05/22/2013 05:51 PM, Steve Langasek wrote:

On Wed, May 22, 2013 at 09:15:03AM +0200, John Paul Adrian Glaubitz wrote:


What about launchd? Wouldn't it be possible to port that to
Debian/kFreeBSD? It's designed to run in a BSD userland, after all.


That doesn't seem like it would help at all with the concern about keeping
our userspace aligned across kernels.


I honestly don't think this is going to be a realistic goal considering
the fact neither upstart or systemd are still not working on BSD or even
Hurd and I don't see any serious efforts by anyone to see this happen
anytime soon.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/519d0dad.2000...@physik.fu-berlin.de

Re: Debian systemd survey

[Josselin Mouette]

Le mercredi 22 mai 2013 à 19:50 +0200, Martin Wuertele a écrit : 
> Actually it sounds like you propose to stop developing and take
> everything from Redhat, Lennart, Gnome because it's there and they say
> so.

Damn! I have been exposed.

I admit to everything. I am merely an artificial creature, designed by
Lennart and sent here by the GNOME cabal, to end Debian as it is and
turn it into a useless system that is not the UNIX way™.

> Seems to me that luckily not everybody agrees with that approach (CTTE
> #681834, CTTE #688772)...

Fortunately the CTTE failed to expose me before you did, since they
ended up authorizing the dependency I surreptitiously introduced.

kthxbye,
-- 
 .''`.  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/1369247299.13422.20.camel@tomoyo

Re: Debian systemd survey

[John Paul Adrian Glaubitz]

On 05/22/2013 06:41 PM, Steve Langasek wrote:

On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote:

Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit :

- there are 300+ upstart job files ready to be imported from Ubuntu



When you compare the time it takes to write an upstart job file or a
systemd unit file, to the time it takes to proprely test it, I don’t
think this argument makes any sense.


Please leave the FUD at the door.  Writing upstart jobs is not difficult;
while there are some gotchas currently with process lifecycle (which will be
fixed soon), there is also very complete documentation (for these issues,
and generally).


systemd's unit files are still way simpler than upstart job files since
these are just more or less a simple set of instructions to give
systemd some hints on how to deal with the targets and services, it
actually does most of the work automatically without the need of scripts
at all (which are obviously still required for upstart).


If the only things we do for improving the distribution are to take stuff
from Ubuntu because, well, it’s here, we might as well stop developing
anything at all.


Sure; obviously the right thing to do is to instead take stuff from GNOME
and freedesktop.org without regard to integration with our existing system,
because if Lennart says it's right it must be so.


Honestly, these personal accusations against Lennart are getting old and
boring. Don't you really have any other good argument to bring up
against systemd other than you dislike *one* of the systemd developers?*

And while I don't support all of the decisions GNOME upstream makes, I
fully support f.d.o as an actual free and independent organization
which hosts the development of systemd.

*When* there is one company that is trying to fragment the Linux world
then it's Canonical with its urge to come up with one NIH project
after another, be it Bazaar (which seems to have been abandoned by
upstream with >2000 open bugs [1]) or the Mir display server
which isn't supported by neither the X.org/DRM developers or
any developers of desktops like KDE, Enlightment or GNOME.

Adrian

* As you may know, systemd is developed by a large amount of
  contributors.

> [1] https://bugs.launchpad.net/bzr

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/519d1008.3040...@physik.fu-berlin.de

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Ben Hutchings]

On Wed, May 22, 2013 at 04:01:19PM +0200, Svante Signell wrote:
> On Wed, 2013-05-22 at 13:37 +0200, Holger Levsen wrote:
> > Hi,
> > 
> > On Mittwoch, 22. Mai 2013, Dmitrijs Ledkovs wrote:
> > > FSF on the other hand:
> > [...]
> > 
> > You forgot their failure with this "gnu unix system" they were trying to 
> > build! This also didnt take off - what a bunch of loosers!
> 
> It is taking off, albeit slowly: (please join to make it happen faster:)
[...]

I think you're missing Holger's point: FSF has had great success with
the GNU project.  This is independent of the Hurd kernel.

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/20130522183651.gf4...@decadent.org.uk

Re: Debian systemd survey

[John Paul Adrian Glaubitz]

On 05/22/2013 07:50 PM, Martin Wuertele wrote:

Actually it sounds like you propose to stop developing and take
everything from Redhat, Lennart, Gnome because it's there and they say
so.


And another one. Why is it that almost anyone who isn't favor of
systemd is directly going off insulting their developers or any
of the organizations behind of it?

You know why many projects are adopting many technologies that
are developed by RedHat people? It's because RedHat is an excellent
upstream and they are one of the largest contributors to the whole
Linux software stack, be it the kernel or anything above.

Distributions would adopt more innovative and useful technologies
developed by Canonical, for example, if there were any. I can't
actually think of anything by Canonical which has been widely
adopted outside Ubuntu.

Blame Canonical for being a bad upstream, not RedHat for being
a good one!

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/519d1163.9070...@physik.fu-berlin.de

Bug#709363: ITP: libmodule-build-cleaninstall-perl -- module to remove the old module before installing the new one

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libmodule-build-cleaninstall-perl
  Version : 0.05
  Upstream Author : Joel A. Berger 
* URL : https://metacpan.org/release/Module-Build-CleanInstall/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to remove the old module before installing the new 
one

 Module::Build::CleanInstall is a subclass of Module::Build with one
 additional feature, before upgrading the module from and old version to a new
 one, it first removes the files installed by the previous version. This is
 useful especially when the new version will not contain some files that the
 old one did, and it is necessary that those files do not remain in place.
 .
 Since it is a subclass of Module::Build it is used exactly like that module.
 Module::Build::CleanInstall does provide an additional action uninstall, but
 it need not be called separately; the action install will call it when
 invoked.
 .
 The uninstalling is done by removing the files in the installed module's
 packlist|ExtUtils::Packlist which is created when the module is first
 installed.


-- 
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/20130522185840.8065.63480.reportbug@localhost

Re: Debian systemd survey

[Russ Allbery]

Martin Wuertele  writes:
> * Josselin Mouette  [2013-05-22 15:03]:

>> When you compare the time it takes to write an upstart job file or a
>> systemd unit file, to the time it takes to proprely test it, I don’t
>> think this argument makes any sense. If the only things we do for
>> improving the distribution are to take stuff from Ubuntu because, well,
>> it’s here, we might as well stop developing anything at all.

> Actually it sounds like you propose to stop developing and take
> everything from Redhat, Lennart, Gnome because it's there and they say
> so.

> Seems to me that luckily not everybody agrees with that approach (CTTE
> #681834, CTTE #688772)...

This isn't appropriate.  I'm quite confident that Josselin is making
informed technical judgements in what he views as the best interests of
the project and the best technological direction for Debian.  It's
certainly fair game to disagree with him about the wisdom of that
direction, but please don't level these kinds of accusations.

There are a lot of people who choose to use systemd on its own merits.  I
know of green-field Linux-based projects with no vested interest in any
choice that have chosen systemd purely on its merits (and others that have
not).  This is not one of those decisions where there's an obvious correct
choice and everyone else is just not looking at the problem properly.

The CTTE bugs you cite were about a difficult tradeoff between integration
and flexibilty, with strong usability arguments to be made on both sides.
Just because the CTTE ended up disagreeing with the initial choice of the
GNOME maintainers doesn't mean that Josselin did anything wrong.  It means
that we have a governance process for making controversial decisions;
that's what it's there for.  It's not always obvious what decisions will
be controversial in advance, and different people working on different
parts of the project can, completely in good faith, view the relative
merits of different tradeoffs differently.

-- 
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/87li76lthk@windlord.stanford.edu

Re: Debian systemd survey

[Martin Wuertele]

* John Paul Adrian Glaubitz  [2013-05-22 20:57]:

> On 05/22/2013 07:50 PM, Martin Wuertele wrote:
> >Actually it sounds like you propose to stop developing and take
> >everything from Redhat, Lennart, Gnome because it's there and they say
> >so.
> 
> And another one. Why is it that almost anyone who isn't favor of
> systemd is directly going off insulting their developers or any
> of the organizations behind of it?

Actually it's just a response to the ongoing insulting by joss to
variouse participants on mailinglists. As usual he has a way of mailing
that i find disgusting.

> You know why many projects are adopting many technologies that
> are developed by RedHat people? It's because RedHat is an excellent
> upstream and they are one of the largest contributors to the whole
> Linux software stack, be it the kernel or anything above.

In many projects yes, in some no. Current kernel development, tough an
understandable way to compete with Oracle, is not as cooperative as it
was.

> Distributions would adopt more innovative and useful technologies
> developed by Canonical, for example, if there were any. I can't
> actually think of anything by Canonical which has been widely
> adopted outside Ubuntu.

Actually in ubuntu happened a lot of multiarch development before it
ended up in debian.

> Blame Canonical for being a bad upstream, not RedHat for being
> a good one!

Actually that is not true. With some projects they both do a good job
while with others they suck, it depends mainly on the actual persons
involved. 


-- 
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/2013052219.ge13...@anguilla.debian.or.at

Re: Debian systemd survey

[Martin Wuertele]

* Josselin Mouette  [2013-05-22 20:45]:

> Le mercredi 22 mai 2013 à 19:50 +0200, Martin Wuertele a écrit : 
> 
> > Seems to me that luckily not everybody agrees with that approach (CTTE
> > #681834, CTTE #688772)...
> 
> Fortunately the CTTE failed to expose me before you did, since they
> ended up authorizing the dependency I surreptitiously introduced.

Seems like you haven't realised yet: only if a maintainer makes
controversal decisions and several others disagree such a case comes
before the CTTE. 

Having choices ending up twice within relatively short time before the
CTTE should give the maintainer a hint. 


--
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/20130522192730.gf13...@anguilla.debian.or.at

Re: On advocating NM applicants

[Jonathan Wiltshire (Front Desk)]

On Wed, May 22, 2013 at 07:48:27AM +0100, Jonathan Wiltshire (Front Desk) wrote:
> Hi,
> 
> In the past few days and weeks there have been many advocacies, for new
> applicants and for DM->DD applicants.
> 
> Please take advantage of the NM web interface where possible, as it makes
> the process much more streamlined for us. If the applicant doesn't have a
> record there yet, please wait patiently until they (or front desk) say "go!"
> and then do that.
> 
> Your message will be sent on to debian...@lists.debian.org on your behalf,
> and meanwhile we get all the information required in one place.
> 
> To advocate someone through the web interface:
> 
> 1. Log in to https://nm.debian.org/
> 2. Use the "People" tab to find the applicant of interest [1]
> 3. Choose something appropriate from the links at the top right of the
>page. "Advocate for DD" is normally what you're after.
> 4. Enter your message and if you're the first, also choose if this is to be
>an uploading or non-uploading application.
> 
> You can still email your advocacy to front desk or debian-nm, but it will
> be copied into here in any case.
> 
> Thanks for your assistance!
> 
> 
> 1: you will end up somewhere like https://nm.debian.org/public/person/jmw/
> 
> For front desk:
> -- 
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
> 
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

s/debian-nm/debian-newmaint/ throughout, sorry for any confusion. Turns out
the oldest habits die hardest.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: Digital signature

Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Daniel Walrond]

Hello,

As per policy 10.9 - Permissions and owners[0], opensmtpd requires
some system users for running non-root-privileged processes. I propose
to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf.

Also I will be co-maintaining this package with Ryan Kavanagh, who has
already done some work packaging opensmtpd.


Dan

[0] http://www.debian.org/doc/debian-policy/ch-files.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/20130522201318.gh2...@sumdoave.com

Re: Debian systemd survey

[Russ Allbery]

Martin Wuertele  writes:

> Seems like you haven't realised yet: only if a maintainer makes
> controversal decisions and several others disagree such a case comes
> before the CTTE.

Having decisions appealed to the CTTE is not a punishment.  It just
indicates that a decision is controversial and the project was unable to
reach a consensus.  It's not always possible (and indeed not always wise)
to avoid controversial decisions.

> Having choices ending up twice within relatively short time before the
> CTTE should give the maintainer a hint. 

It is, for example, probably a hint that the maintainer is working on
something important that a lot of people care deeply about and therefore
have strong opinions about.

-- 
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/87d2sikbaf@windlord.stanford.edu

Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh

[Holger Levsen]

On Mittwoch, 22. Mai 2013, Ben Hutchings wrote:
> I think you're missing Holger's point: FSF has had great success with
> the GNU project.  This is independent of the Hurd kernel.

Yet I'm happy to finally see a Debian GNU/Hurd release. Wow! & Whohooo!


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

Re: using upstart in Debian [was, Re: Debian systemd survey]

[Daniel Baumann]

On 05/22/2013 06:19 PM, Steve Langasek wrote:
> I'm skeptical of the value of such a design in place of just using
> an initramfs, but the 'friendly-recovery' package in Ubuntu gives
> an example of to do this.

live-config-upstart needs the same to be useful. personally i have no
experience with upstart at all and would therefore welcome a patch to
implement this properly in live-config, otherwise upstart support will
be dropped with one of the next uploads.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.bauman


-- 
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/519d2bc5.7050...@progress-technologies.net

Re: Debian systemd survey

[Lucas Nussbaum]

Hi,

On 22/05/13 at 15:11 +0200, Marco d'Itri wrote:
> On May 21, Lucas Nussbaum  wrote:
> 
> > We don't need to select a single init system at this point, and it would
> As the maintainer of a package which is strongly tied to the init 
> system, I disagree.
> 
> > Then, something I failed to find in the discussion was a discussion of
> > how sysvinit / systemd / upstart could co-exist (not on a single system,
> > but in the archive).
> I suggest that this is related to my first point.
> 
> > I understand that systemd replaces some parts of
> > initscripts, could also replace syslog, etc. How do systemd supporters
> > see that working in practice? What kind of feature duplication between
> > init sytems should be expected? How much does it increase the
> > maintenance effort?
> I am not strictly a systemd supporter but more like a "modern init 
> system supporter", and the duplication, increased mainteinance overhead 
> and lack of QA are the reasons why I do not want to support multiple 
> init systems in my packages and I do not think that Debian should either 
> as a project.

I agree that ideally, a swift and uneventful transition to a single
modern init system would be great. Unfortunately, we have two strong
alternatives, and no clear collective understanding of which one is
better now, and will be for the future.

I fully understand that supporting more than one init system increases
the maintenance effort and the QA needs significantly, and that this is
unlikely to be sustainable on the long term. However, this is a possible
compromise that buys us time while we gain a better understanding of the
pros and cons of each solution.

What I failed to understand so far is what it would mean to support
sysvinit, systemd and upstart from the point of view of udev (and other
key packages). Could you enlighten me? What are the main problems to
expect?

Lucas


signature.asc
Description: Digital signature

systemd .service file conversion

[Helmut Grohne]

On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote:
> There was a GSoC project in 2012 about generating sysvinit scripts from
> systemd .service files. Was there some communication about its outcome?

I had a look at this idea and its result. From what I saw, I do not
believe a conversion process to be successful in a big enough fraction
of actual .service files. This is because systemd (and for that matter
upstart should we consider a job file conversion as well) actually
provide more functionality than sysv does. Some of that functionality
does not properly map to an init script conversion.

 * stdout/stderr to syslog redirection
   This is possibly implementable, but needs more than a line of shell.
 * supervision/service restart/heartbeat
   sysv simply does not provide this functionality. Other tools are
   needed to mimic this. An option could be djb's daemontools. Still you
   either end up with some supervision process with similar tasks as
   systemd/upstart or have a supervision process per service.
 * missing dependencies
   Due to the use of socket activation it is to be expected that
   services stop declaring their dependencies. In .service files this
   information commonly is not present, because it is not needed.
 * socket activation cont'd
   I guess that at some point services will expect that their sockets
   are already open when they are started, because this eliminates a
   privileged bind() operation.
 * resource/privilege limitations
   Service files provide a mechanism to describe and limit the required
   privileges or resources. Some of these map to shell commands, others
   don't. Arguably this part is non-essential to a conversion process.

You can already see parts of these in action in current .service files,
but it is to be expected that there will be more usage of these and
other features.

> Is it realistic to dream about a generator that would automate the
> generation of sysvinit scripts, systemd .service files, and upstart job
> files for a majority of our packages (the "easy" ones)?

Based on the above arguments, I believe that a conversion process will
not work out. (I note that I may be wrong here.) Talking just about
systemd and sysvinit, there is the possibility to create a .service
interpreter to let sysvinit execute systemd .services. upstart already
has such an interpreter. The necessary hooks in sysvinit/insserv already
exist and are easily extensible. I therefore suggest to drop the idea of
generating shell scripts. Also consider the amount of work required to
fix a bug in a conversion utility compared to an interpreter. Are we
really gonna rebuild all services (that only ship a .service file)?

>From my point of view this raises the question of interoperability
between systemd and upstart. Is a conversion in either direction
feasible? Possibly systemd -> upstart, because we already have the job
interpreter?

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/20130522203904.ga7...@alf.mars

Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR

[Josselin Mouette]

Le mercredi 22 mai 2013 à 21:27 +0200, Martin Wuertele a écrit : 
> Seems like you haven't realised yet: only if a maintainer makes
> controversal decisions and several others disagree such a case comes
> before the CTTE. 
> 
> Having choices ending up twice within relatively short time before the
> CTTE should give the maintainer a hint. 

A hint of what? That some people will appeal to the CTTE regardless (or
to a GR, like it was hinted several times in this thread already)
because they feel entitled to tell others what to do and how they should
do it? Because they know better what an operating system should be?

I do not accept this kind of intellectual terrorism, where a handful of
low-throughput contributors (when they contribute at all), who never
even try to understand the issues at hand, keep on bitching and whining
endlessly, unsatisfied until others abandon whatever they were trying to
improve. This behavior is toxic to the project. It leads to sclerosis,
killing any kind of momentum that can be built around a given direction.

You don’t get to define what Debian is. It is fortunate that the CTTE
thinks twice before answering to such requests; and in the case of NM,
despite heated discussions, the result ended up satisfying for all
involved parties – except of course for those who just can’t stand the
idea that NM could be installed on a Debian computer, but it’s not as if
those who really develop Debian really cared for them.

kthxbye,
-- 
 .''`.  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/1369256701.13422.37.camel@tomoyo

Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Colin Watson]

On Wed, May 22, 2013 at 09:13:18PM +0100, Daniel Walrond wrote:
> As per policy 10.9 - Permissions and owners[0], opensmtpd requires
> some system users for running non-root-privileged processes. I propose
> to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf.

Thanks for CCing me, which I assume was in my rôle as base-passwd
maintainer.  I only really need to be involved if you need static IDs
for some reason, rather than the normally-preferred method of using
dynamic IDs via 'adduser --system'.  If so, please give a short
explanation of why that's the case.

Policy 10.9 does say to check even dynamic names with the base-passwd
maintainer, and I congratulate you for being one of the very few
developers to read it in close enough detail to notice that. ;-)  That
wording should perhaps be revised, as neither I nor (as far as I know)
any of my predecessors have kept a registry of all dynamic names used in
Debian, only of the IDs we've allocated from the static ranges 0-99 and
6-64999, so we aren't really in a position to perform a reliable
check for name uniqueness.

I'd normally just require that statically-allocated user/group names
should be obviously derived either from your package name or,
occasionally, from the name of one of the commands you ship, and that's
generally good practice for dynamically-allocated names too.  The names
you suggest are close enough to your package name, and that package name
is distinct enough, that I think there's very unlikely to be a clash and
you should be fine.  So, if all you need is dynamically-allocated IDs,
then go ahead.

Cheers,

-- 
Colin Watson   [cjwat...@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/20130522210821.gf5...@riva.ucam.org

Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Russ Allbery]

Daniel Walrond  writes:

> As per policy 10.9 - Permissions and owners[0], opensmtpd requires
> some system users for running non-root-privileged processes. I propose
> to user the following dynamic accounts; opensmtpd, opensmtpq, opensmtpf.

> Also I will be co-maintaining this package with Ryan Kavanagh, who has
> already done some work packaging opensmtpd.

We currently have no good policy about how to name system users, but
despite that I personally would recommend against using simple
alphanumeric usernames like those.  (They are longer than eight
characters, which avoids some local namespaces, but not all.)

There are two conventions that other packages have used to make it less
likely that system accounts will conflict with local usernames:

* Append "Debian-" to the username, as in Debian-opensmtpd
* Append an underscore, as in _opensmtpd

I personally mildly prefer the latter just because it's simple, although
it isn't as informative or robust against any namespace issue.  Note that
you will have to pass --force-badname to adduser to let you use an
underscore in the name.

-- 
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/87fvxeiukt@windlord.stanford.edu

Re: Debian systemd survey

[Matt Zagrabelny]

On Wed, May 22, 2013 at 3:30 PM, Russ Allbery  wrote:
> Martin Wuertele  writes:
>
>> Seems like you haven't realised yet: only if a maintainer makes
>> controversal decisions and several others disagree such a case comes
>> before the CTTE.
>
> Having decisions appealed to the CTTE is not a punishment.  It just
> indicates that a decision is controversial and the project was unable to
> reach a consensus.  It's not always possible (and indeed not always wise)
> to avoid controversial decisions.
>
>> Having choices ending up twice within relatively short time before the
>> CTTE should give the maintainer a hint.
>
> It is, for example, probably a hint that the maintainer is working on
> something important that a lot of people care deeply about and therefore
> have strong opinions about.

Well said.

-mz


-- 
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/caolfk3wxeoscjz06nkqg1qtompftkegp3sb05tz5onng5en...@mail.gmail.com

Re: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Colin Watson]

On Wed, May 22, 2013 at 02:16:34PM -0700, Russ Allbery wrote:
> We currently have no good policy about how to name system users, but
> despite that I personally would recommend against using simple
> alphanumeric usernames like those.  (They are longer than eight
> characters, which avoids some local namespaces, but not all.)

I've never been a fan of worrying about this, largely because the names
that are really a practical problem are mostly the ones that have been
around forever and that we're stuck with (things like "man" could well
be a real name; I have a co-worker whose initials are apparently SSH;
people occasionally try to use things like "staff"; and so on), while
most of the ones that have been introduced more recently, and certainly
the longer and/or more elaborate ones, are likely to be innocuous.

Pragmatically, I wouldn't be inclined to lose any sleep over the chances
of somebody having a local username called opensmtpd that wasn't
actually for a local installation of this very same package.  And our
user/group namespace is such that it really almost has to be handled
pragmatically.

> There are two conventions that other packages have used to make it less
> likely that system accounts will conflict with local usernames:
> 
> * Append "Debian-" to the username, as in Debian-opensmtpd

This was used by Debian-exim and not a lot else that I ever heard of.
In my view this scheme rightly failed; plenty of simple system
monitoring tools (top, ps, and the like) truncate long usernames in many
modes or turn them into UIDs, and sticking a seven-character prefix on
the front just seems to be trying to maximise the probability of trouble
like this, even though it is certainly clear.

Cheers,

-- 
Colin Watson   [cjwat...@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/20130522215516.gg5...@riva.ucam.org

Re: Debian systemd survey

[Steve Langasek]

On Wed, May 22, 2013 at 07:45:32PM +0200, Josselin Mouette wrote:
> Le mercredi 22 mai 2013 à 09:41 -0700, Steve Langasek a écrit : 
> > On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote:
> > > When you compare the time it takes to write an upstart job file or a
> > > systemd unit file, to the time it takes to proprely test it, I don’t
> > > think this argument makes any sense.

> > Please leave the FUD at the door.  Writing upstart jobs is not difficult;
> > while there are some gotchas currently with process lifecycle (which will be
> > fixed soon), there is also very complete documentation (for these issues,
> > and generally).

> In which way do you disagree with what I wrote, exactly? Maybe my
> English was wrong, so let me explain it in simple words.
> Time to write an upstart job = short
> Time to write a systemd unit file = short
> Time to test an upstart job = long
> Time to test a systemd unit file = long

> Therefore:
> How much we should care of existing upstart jobs = little
> How much we should care of existing systemd unit files = little

I see - yes, I misunderstood your argument, and thought you were claiming
that upstart jobs take longer to write and test.  The above makes more
sense.

I do think that in the context of Debian, upstart has the upper hand in
terms of the testing owing to the fact that Ubuntu, which is very similar to
Debian, has already worked out most of the kinks.

But I'd rather demonstrate this instead of spending time arguing it, so...

> > > If the only things we do for improving the distribution are to take stuff
> > > from Ubuntu because, well, it’s here, we might as well stop developing
> > > anything at all.

> > Sure; obviously the right thing to do is to instead take stuff from GNOME
> > and freedesktop.org without regard to integration with our existing system,
> > because if Lennart says it's right it must be so.

> Yes of course, because Debian is well-known for using fd.o and GNOME
> software as is, without patching it ever, and adopting new technologies
> blindly and very quickly, before they are well tested.

There certainly have been cases of fd.o changes being dropped into Debian
without dealing with the integration questions.  mime -> .desktop is a prime
example of this.  .desktop is clearly far superior - but that doesn't mean
it's ok to drop the existing stuff on the floor.  So if your comment is a
fair critique of upstart proponents, then mine is an equally fair critique
of systemd proponents.

> Have it ever occurred to you that people might want to see systemd as
> default, not because Lennart said it, but because they think it is
> better than any alternative? Better than upstart *in the way it
> integrates with our existing system*, BTW.

Oh, it absolutely has occurred to me.  And has it occurred to you that the
upstart proponents likewise feel that theirs is the better alternative?

I'd be happy to hear you expand on how you think systemd integrates better
with the existing system in Debian.  I certainly don't see that this is the
case - particularly when the systemd dbus services, which people have told
me are so essential a component of the GNOME desktop going forward, had no
tested backend that integrated with the Debian locations for system-level
config files until I provided one for Ubuntu.

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


signature.asc
Description: Digital signature

Re: systemd .service file conversion

[Kurt Roeckx]

On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote:
> On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote:
> > There was a GSoC project in 2012 about generating sysvinit scripts from
> > systemd .service files. Was there some communication about its outcome?
> 
> I had a look at this idea and its result. From what I saw, I do not
> believe a conversion process to be successful in a big enough fraction
> of actual .service files. This is because systemd (and for that matter
> upstart should we consider a job file conversion as well) actually
> provide more functionality than sysv does. Some of that functionality
> does not properly map to an init script conversion.

Note that such conversion to a sysv init script is not supposed to
provide all the features that upstart and systemd provide.  Else
there would be no need to move to systemd or upstart in the first
place.

>  * stdout/stderr to syslog redirection
>This is possibly implementable, but needs more than a line of shell.

Do you know about logger(1)?  If that itself is not good enough,
it should be easy enough to make something that does what you
want.

>  * missing dependencies
>Due to the use of socket activation it is to be expected that
>services stop declaring their dependencies. In .service files this
>information commonly is not present, because it is not needed.

It's not because it's not needed that we can't add this.  If we
already have this information there is no need to throw it away.

>  * socket activation cont'd
>I guess that at some point services will expect that their sockets
>are already open when they are started, because this eliminates a
>privileged bind() operation.

That would just mean that those don't work at all with sysv
anymore, and since I think we still have to support sysv,
we should fix them.

> Based on the above arguments, I believe that a conversion process will
> not work out. (I note that I may be wrong here.) Talking just about
> systemd and sysvinit, there is the possibility to create a .service
> interpreter to let sysvinit execute systemd .services. upstart already
> has such an interpreter. The necessary hooks in sysvinit/insserv already
> exist and are easily extensible. I therefore suggest to drop the idea of
> generating shell scripts. Also consider the amount of work required to
> fix a bug in a conversion utility compared to an interpreter. Are we
> really gonna rebuild all services (that only ship a .service file)?

I would argue that if such a conversion script would exist, we can
probably have more consistent init script implementations, and
less bugs in them.

I'm also not sure why fixing a conversion script is that much
work.

Plsese note that I'm not saying that such a script is a good or
bad thing, just that I don't follow your arguments.


Kurt


-- 
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/2013054745.ga9...@roeckx.be

Re: Debian systemd survey

[Steve McIntyre]

Matthias wrote:
>Am 22.05.2013 18:12 schrieb "Lucas Nussbaum" :
>>
>> Note that if it's there, and Ubuntu uses upstart, it has probably been
>> tested. I was not suggesting that we blindly import upstart job files
>> from Ubuntu, but a basis to start from is better than no basis at all.
>> (I can see how my phrasing was a bit confusing -- sorry about that)
>
>Please also keep in mind that many upstream projects ship systemd service
>files. Therefore, most of the systemd work is already done too.

Most? Really? Do you have stats for that?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim."  [ seen in ucam.chat ]


-- 
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/e1ufib9-0007zz...@mail.einval.com

Re: blhc and hardening flags (was: Re: jessie release goals)

[Nick Andrik]

> That reminds me.  Is there a way to get blhc to tell me *which* line in a
> build log makes it think that compiler flags are hidden?

I agree that would be really useful

> https://buildd.debian.org/~brlink/packages/r/remctl.html is reporting that
> the compiler flags are hidden.  So far as I know, this is false, but this
> package builds Perl, PHP, Python, and Ruby extensions, and it's possible
> that one of those build systems is misconfigured.  But I can't tell from
> this page which line it's upset about.

Usually what I do is to copy the whole page and pass it through the
blhc on my local system.
In your case I get this message:
NONVERBOSE BUILD: compiling remctl.c

Your build logs include:
make[4]: Entering directory
`/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby'
compiling remctl.c
linking shared-object remctl.so
make[4]: Leaving directory
`/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby'

Seems like a valid warning to me

--
=Do-
N.AND


-- 
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/cann5kou4h4b6o4tqfshetkwb7yvbtkjue-tdndt4lhym1-m...@mail.gmail.com

Re: blhc and hardening flags

[Russ Allbery]

Nick Andrik  writes:

> Usually what I do is to copy the whole page and pass it through the
> blhc on my local system.
> In your case I get this message:
> NONVERBOSE BUILD: compiling remctl.c

> Your build logs include:
> make[4]: Entering directory
> `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby'
> compiling remctl.c
> linking shared-object remctl.so
> make[4]: Leaving directory
> `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby'

> Seems like a valid warning to me

Aha!  Thank you.  So it's the Ruby build system that's hiding the flags
here.  I'll take a deeper look and see if a bug against ruby1.9.1-dev is
in order.

-- 
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/8738tepm2j@windlord.stanford.edu

Re: Debian systemd survey

[Vincent Lefevre]

On 2013-05-22 15:39:00 +0200, Bernd Schubert wrote:
> On 05/22/2013 04:50 AM, Uoti Urpala wrote:
> >Lucas Nussbaum wrote:
> >>I went through the various init systems threads again during the last
> >>few days. My understanding of the consensus so far is the following:
> >>
> >>- Both systemd and upstart bring many useful features, and are a
> >>   clear improvement over sysvinit.
> >
> >Yes, both are an improvement over sysvinit.
> 
> Hrmm, I have not tested systemd yet, but personally I'm not conviced about
> the advantages of upstart:
> 
> - Stops booting *somtimes*, does not provide any information why. I didn't
> report a bug yet as an almost black screen won't help in any way how to
> figure out why it stopped. Already that stops without any further
> information why and where is a sufficiently big design issue, imho.
> (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm
> not sure yet.).

Well, a frozen boot without much information can also occur with
sysvinit (e.g. due to udev). For instance, I had the following
problem in the past:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606192

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130523003328.ga4...@xvii.vinc17.org

Re: Debian systemd survey

[Miroslaw Baran]

> 
> * As you may know, systemd is developed by a large amount of
>contributors.

…as you may know, upstart is not only older than systemd, but is also used on a 
large amount of live systems, probably many times more the number of systems 
that 
have systemd installed.*⁾

Best regards,
– Jubal

*) Ubuntu, chromebooks, Kindles, RHEL6 and Centos6.

-- 
Don't you have a home to go to?

Re: Debian systemd survey

[Chow Loong Jin]

On 23/05/2013 02:35, John Paul Adrian Glaubitz wrote:
>> Sure; obviously the right thing to do is to instead take stuff from GNOME
>> > and freedesktop.org without regard to integration with our existing system,
>> > because if Lennart says it's right it must be so.
> Honestly, these personal accusations against Lennart are getting old and
> boring. Don't you really have any other good argument to bring up
> against systemd other than you dislike *one* of the systemd developers?*

I didn't see that as a personal accusation against Lennart really. It looked
more like an attack on the sheeple who follow blindly what Lennart says, simply
because he said it therefore it must be right.

> [...] Bazaar (which seems to have been abandoned by
> upstream with >2000 open bugs [1]) [...].

On the other hand, it would be nice if you keep your FUD to the minimum. Bazaar
doesn't look abandoned[1], and >2000 open bugs is not uncommon. Nautilus and
Rhythmbox themselves have >1000 open bugs each.

[1] https://code.launchpad.net/bzr

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: Debian systemd survey

[Chow Loong Jin]

I really like how this paragraph:

On 23/05/2013 02:41, John Paul Adrian Glaubitz wrote:
> [...]
> And another one. Why is it that almost anyone who isn't favor of
> systemd is directly going off insulting their developers or any
> of the organizations behind of it?

and this paragraph:

> Blame Canonical for being a bad upstream, not RedHat for being
> a good one!

appear in the same post.

The irony is strong here. Let not the pot call the kettle black.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

bzr (was: Re: Debian systemd survey)

[Jeremy Bicha]

On 22 May 2013 22:02, Chow Loong Jin  wrote:
>> [...] Bazaar (which seems to have been abandoned by
>> upstream with >2000 open bugs [1]) [...].
>
> On the other hand, it would be nice if you keep your FUD to the minimum. 
> Bazaar
> doesn't look abandoned[1], and >2000 open bugs is not uncommon. Nautilus and
> Rhythmbox themselves have >1000 open bugs each.
>
> [1] https://code.launchpad.net/bzr

Two commits this year? The only thing that makes it not completely
abandoned by upstream is that occasionally there are a few maintenance
bugfix commits done.

For the record, I do use bzr (with
http://jameswestby.net/bzr/builddeb/user_manual/merge.html ) in my
normal Ubuntu/Debian packaging workflow. I haven't figured out how to
git to work as nicely for that usecase yet.

Jeremy Bicha


-- 
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/caaajcmzsv+wibph7dmoce2fq4d3cmtaqoe48axuogzw+6pd...@mail.gmail.com

Re: Debian systemd survey

[Thomas Goirand]

On 05/22/2013 04:53 AM, Lucas Nussbaum wrote:
> - Neither systemd nor upstart are likely to be ported to kfreebsd soon,
>   as they both rely on many Linux-specific features and interfaces.

Though it should be easy enough to port OpenRC to kFreeBSD and Hurd,
once it completes its support for the current init.d scripts. You
completely forgot that option.

The only thing that worries me is the cgroup thing, but probably it
should be possible to fallback to .pid files in such case (in an
automated way).

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/519d9aff.6040...@debian.org

Re: Debian systemd survey

[Matthias Urlichs]

Steve McIntyre  writes:

> Matthias wrote:
> >
> >Please also keep in mind that many upstream projects ship systemd service
> >files. Therefore, most of the systemd work is already done too.
> 
> Most? Really? Do you have stats for that?
> 
Given the fact that sysvinit scripts are supported by systemd
out-of-the-box, the basic work is already done. So why would you need any stats?

I run all of my servers with the (ancient, by this time) systemd shipped
with wheezy. There are exactly zero init scripts on my machines which don't
work at all, and only one (collectd) does not properly delegate to systemd
when invoked directly.

-- 
-- Matthias Urlichs



-- 
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.20130523t063402-...@post.gmane.org

Re: Debian systemd survey

[Thomas Goirand]

On 05/23/2013 01:45 AM, Josselin Mouette wrote:
> I understand it will be a pain for Ubuntu if Debian picks a different
> init system. I don’t think this is relevant for the discussion, though.

It might be very relevant for many of us that our package works on
*both* Debian and Ubuntu (and other derivative, including those who
derive from Ubuntu, like for example Mint) without too much
modifications. Some of my packages already incorporate some upstart
script for that reason.

I do all of my work in Debian, though whenever possible, I am happy to
see that my development fits the (140+, according to distro watch)
Debian derivatives. And I don't think I am the only one thinking this
way (in fact, I *know* many other DD / DM think this way).

So yes, being friendly for our downstream is very relevant to this
discussion (even though obviously, that isn't the only point).

Thomas

P.S: Please note that I'm not taking any side above. Just replying to
your point that it isn't relevant, which I think is simply not right.


--
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/519da071.8080...@debian.org

Re: bzr (was: Re: Debian systemd survey)

[Andrew Starr-Bochicchio]

On Wed, May 22, 2013 at 11:31 PM, Jeremy Bicha  wrote:
> On 22 May 2013 22:02, Chow Loong Jin  wrote:
>>> [...] Bazaar (which seems to have been abandoned by
>>> upstream with >2000 open bugs [1]) [...].
>>
>> On the other hand, it would be nice if you keep your FUD to the minimum. 
>> Bazaar
>> doesn't look abandoned[1], and >2000 open bugs is not uncommon. Nautilus and
>> Rhythmbox themselves have >1000 open bugs each.
>>
>> [1] https://code.launchpad.net/bzr
>
> Two commits this year? The only thing that makes it not completely
> abandoned by upstream is that occasionally there are a few maintenance
> bugfix commits done.

While I can't imagine anything good coming from discussing VCS choices
on debian-devel, I'll venture a reply...

I wouldn't say that bazaar is completely "dead," I just had a commit
merged this week. Though AFAICT, Canonical no longer employs anyone to
work on it directly, but it seems some number of bazaar hackers are
still employed in other positions there. I have no idea what their
long term plans are, but I'd imagine that Launchpad and Ubuntu will
continue to be consumers of bazaar for the foreseeable future. No one
has stepped up to drive development, and I do wish Canonical would
make some sort of official statement about their intentions.

There have been a number of interesting retrospectives from former
bazaar core developers, for those that are interested:

https://lists.ubuntu.com/archives/bazaar/2012q4/075330.html
http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html
https://lists.ubuntu.com/archives/bazaar/2013q1/075475.html

I've been the Debian maintainer for a number of bzr plugins for the
past few years, and I've recently picked up the maintenance of the bzr
package as well.

> For the record, I do use bzr (with
> http://jameswestby.net/bzr/builddeb/user_manual/merge.html ) in my
> normal Ubuntu/Debian packaging workflow. I haven't figured out how to
> git to work as nicely for that usecase yet.

I'd encourage anyone who cares about this workflow and these packages
to continue any further discussion of bazaar in Debian over on
pkg-bazaar-maint.

Thanks!

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Developer 
   PGP/GPG Key ID: D53FDCB1


-- 
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/CAL6k_AyPVeSrTVW=9bysfxvdtp4b-prsczm5fymouzmpz8r...@mail.gmail.com

Re: Debian systemd survey

[Thomas Goirand]

On 05/23/2013 02:35 AM, John Paul Adrian Glaubitz wrote:
> Honestly, these personal accusations against Lennart are getting old and
> boring. Don't you really have any other good argument to bring up
> against systemd other than you dislike *one* of the systemd developers?*
> 
> [...]
>
> * As you may know, systemd is developed by a large amount of
>   contributors.

If you are tired of seeing the same arguments, don't post things which
have already been debunked as well. You are doing the very same thing
that you are complaining about: I already posted in this list the git
log stats, and Lennart owns more than 40% of all the commits. So no,
Lennart is not just *one* of the systemd developers, he's the main one,
and by far.

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/519da160.1040...@debian.org

Re: Debian systemd survey

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 23, 2013 at 12:37:35AM +0100, Steve McIntyre wrote:
> Matthias wrote:
> >Am 22.05.2013 18:12 schrieb "Lucas Nussbaum" :
> >>
> >> Note that if it's there, and Ubuntu uses upstart, it has probably been
> >> tested. I was not suggesting that we blindly import upstart job files
> >> from Ubuntu, but a basis to start from is better than no basis at all.
> >> (I can see how my phrasing was a bit confusing -- sorry about that)
> >
> >Please also keep in mind that many upstream projects ship systemd service
> >files. Therefore, most of the systemd work is already done too.
> 
> Most? Really? Do you have stats for that?
While it's a lot of work to query artibrary upstream projects, it
is pretty easy to query a distribution. Fedora is likely the most
unit-file-endowed distribution out there. According to repoquery,
724 distinct binary rpms provide unit files in /usr/lib/systemd/system,
in Fedora 19.

I'd guess that the majority of those files will be usable by Debian,
which usually packages more than Fedora.

This number must be compared with 1094 packages with scripts in
/etc/init.d (quoting Lucas Nussbaum from earlier in the thread here),
and packages having inetd or xinetd files. I'm not sure if this
comes out to a majority, but it probably fairly close.

Zbyszek


-- 
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/20130523045301.ga28...@in.waw.pl

Re: systemd .service file conversion

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 23, 2013 at 12:47:46AM +0200, Kurt Roeckx wrote:
> On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote:
> > On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote:
> > > There was a GSoC project in 2012 about generating sysvinit scripts from
> > > systemd .service files. Was there some communication about its outcome?
> > 
> > I had a look at this idea and its result. From what I saw, I do not
> > believe a conversion process to be successful in a big enough fraction
> > of actual .service files. This is because systemd (and for that matter
> > upstart should we consider a job file conversion as well) actually
> > provide more functionality than sysv does. Some of that functionality
> > does not properly map to an init script conversion.
> 
> Note that such conversion to a sysv init script is not supposed to
> provide all the features that upstart and systemd provide.  Else
> there would be no need to move to systemd or upstart in the first
> place.
> 
> >  * stdout/stderr to syslog redirection
> >This is possibly implementable, but needs more than a line of shell.
> 
> Do you know about logger(1)?  If that itself is not good enough,
> it should be easy enough to make something that does what you
> want.
> 
> >  * missing dependencies
> >Due to the use of socket activation it is to be expected that
> >services stop declaring their dependencies. In .service files this
> >information commonly is not present, because it is not needed.
> 
> It's not because it's not needed that we can't add this.  If we
> already have this information there is no need to throw it away.

At least in case of systemd files, providing this information is often
unwanted. Ordering dependencies can be specified explictly using
Before= and After=, but if socket activation is used, services can be
started in parallel. If one of the services then attempts to query the
other, it'll hang (the kernel queues the packet) until the other
service starts processing requests. Declaring the dependency
explicitly doesn't gain anything, and can add an unnecessary slowdown.
It is just better to have the dependencies solved "automagically", and
adding explicit requirements for the sake of sysvinit conversions is
unlikely to be met with much enthusiasm.

> >  * socket activation cont'd
> >I guess that at some point services will expect that their sockets
> >are already open when they are started, because this eliminates a
> >privileged bind() operation.
> 
> That would just mean that those don't work at all with sysv
> anymore, and since I think we still have to support sysv,
> we should fix them.
> 
> > Based on the above arguments, I believe that a conversion process will
> > not work out. (I note that I may be wrong here.) Talking just about
> > systemd and sysvinit, there is the possibility to create a .service
> > interpreter to let sysvinit execute systemd .services. upstart already
> > has such an interpreter. The necessary hooks in sysvinit/insserv already
> > exist and are easily extensible. I therefore suggest to drop the idea of
> > generating shell scripts. Also consider the amount of work required to
> > fix a bug in a conversion utility compared to an interpreter. Are we
> > really gonna rebuild all services (that only ship a .service file)?
> 
> I would argue that if such a conversion script would exist, we can
> probably have more consistent init script implementations, and
> less bugs in them.
> 
> I'm also not sure why fixing a conversion script is that much
> work.
Providing a conversion script which recreates all of systemd
functionality would basically mean reimplemting a big part of
systemd in shell. Providing an interpeter would man reimplementing
a big part of systemd in whatever the interpreter is written in.
Both options seem infeasible, unless only partial functionality is
supported. [1] lists e.g. SystemCallFilter=, PrivateTmp=, PrivateNetwork=,
CapabilityBoundingSet=, SecuritBits= which have security and
correctness implications, and are IMHO pretty hard to recreate.

Zbyszek

[1] http://www.freedesktop.org/software/systemd/man/systemd.exec.html#Options


-- 
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/20130523051618.gb28...@in.waw.pl

Re: Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR

[Andrew Shadura]

Hello,

On Wed, 22 May 2013 23:05:01 +0200
Josselin Mouette  wrote:

> Subject: Bwah I will tell my daddy^W^Wthe CTTE^W^Wa GR

Couldn't you please finally stop behaving like a five years old?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR

[Ondřej Surý]

Joss isn't the only one to blame. Could all please stop bashing each other (and 
Joss) and stick back to technical arguments? (Saying "I'm sorry" privately to 
each other for each ad hominem argument used in this thread would also help!)

I can clearly see what has provoked this reaction and I have a deep 
understanding for it.

Ondřej Surý
P.S.: You should also stop using phrases like "five years old" - using the word 
"inappropriate" would make your email still correct, but not so dishonesting.

On 23. 5. 2013, at 7:44, Andrew Shadura  wrote:
> Hello,
> 
> On Wed, 22 May 2013 23:05:01 +0200
> Josselin Mouette  wrote:
> 
>> Subject: Bwah I will tell my daddy^W^Wthe CTTE^W^Wa GR
> 
> Couldn't you please finally stop behaving like a five years old?
> 
> -- 
> WBR, Andrew


--
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/9778ac19-fef2-40e6-b15f-e108ba9d5...@sury.org

Re: systemd .service file conversion

[Helmut Grohne]

On Thu, May 23, 2013 at 12:47:46AM +0200, Kurt Roeckx wrote:
> Note that such conversion to a sysv init script is not supposed to
> provide all the features that upstart and systemd provide.  Else
> there would be no need to move to systemd or upstart in the first
> place.

That is true, and I already pointed out some of that functionality as
non-essential (e.g. resource limits). 

> On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote:
> >  * stdout/stderr to syslog redirection
> >This is possibly implementable, but needs more than a line of shell.
> 
> Do you know about logger(1)?  If that itself is not good enough,
> it should be easy enough to make something that does what you
> want.

Good catch. Having it integrate with e.g. start-stop-daemon appears
slightly harder, but yeah this surely is not a blocker.

> >  * missing dependencies
> >Due to the use of socket activation it is to be expected that
> >services stop declaring their dependencies. In .service files this
> >information commonly is not present, because it is not needed.
> 
> It's not because it's not needed that we can't add this.  If we
> already have this information there is no need to throw it away.

Yeah, we do have this information in our init scripts, but it already is
being dropped on the way to .service files. One reason to use .service
files is that someone else (e.g. RedHat) does the work of creating them.
Just they don't need those dependencies. I am not sure that it is
feasible to maintain this information on our own and keep it tested and
working.

> >  * socket activation cont'd
> >I guess that at some point services will expect that their sockets
> >are already open when they are started, because this eliminates a
> >privileged bind() operation.
> 
> That would just mean that those don't work at all with sysv
> anymore, and since I think we still have to support sysv,
> we should fix them.

The question here is: What is less work? Fixing N services to support
sysv or creating a program that creates the environment that those N
services expect? And how large is N?

Also consider the insane amount of code duplication due to every service
implementing daemonization on its own. (libdaemon0 has about 10 rdeps)
One of the major reasons to go to either systemd or upstart was to get
rid of that code, now we add it back for sysv?

> I would argue that if such a conversion script would exist, we can
> probably have more consistent init script implementations, and
> less bugs in them.

You appear to not be aware that such a thing does exist:
https://github.com/akhilvij/systemd-to-sysvinit-converter

> I'm also not sure why fixing a conversion script is that much
> work.

We currently have about 400 Arch:all packages shipping init scripts. Let
me guess that at some point 1/4 would use such a conversion utility. Are
you going to binNMU those 100 Arch:all packages? How to track such a
transition when the converter will not end up in the runtime
dependencies?

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/20130523062829.ga10...@alf.mars