date:20110718

Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
 1. carry portability patches against systemd locally
 2. support multiple init systems
 3. drop kfreebsd (and HURD and others)

3 basically means dropping Universal from Debian, and replace it with
Linux.

Samuel


-- 
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/20110718101302.gd4...@const.bordeaux.inria.fr

Re: A few observations about systemd

2011-07-18 Thread Jon Dowland

On Mon, Jul 18, 2011 at 12:13:02PM +0200, Samuel Thibault wrote:
 Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
  3. drop kfreebsd (and HURD and others)
 
 3 basically means dropping Universal from Debian, and replace it with
 Linux.

I seem to recall Universal existing long before a non-Linux port.  I don't
interpret Universal as meaning more than one kernel, nor Debian's heart
to be the userland in exclusivity.

-- 
Jon Dowland


-- 
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/20110718103457.GA24530@pris

Re: A few observations about systemd

2011-07-18 Thread Federico Di Gregorio

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/07/11 12:13, Samuel Thibault wrote:
 Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
 1. carry portability patches against systemd locally
 2. support multiple init systems
 3. drop kfreebsd (and HURD and others)
 
 3 basically means dropping Universal from Debian, and replace it with
 Linux.

Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
as runs everything (when a Debian GNU/WinNT?).

federico

- -- 
Federico Di Gregorio   f...@initd.org
   Ma chi sei?-il trafficante di Nutella? -- Giorgia
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4kDEIACgkQvcCgrgZGjeuFUwCeKPRre1rMggXUcKCJX6maK6bK
OCAAoL7NPzl2EZzCgX1K+3HOXeeXHXT1
=scnd
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e240c4c.7030...@debian.org

Re: A few observations about systemd

2011-07-18 Thread Gergely Nagy

Federico Di Gregorio f...@debian.org writes:

 On 18/07/11 12:13, Samuel Thibault wrote:
 Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
 1. carry portability patches against systemd locally
 2. support multiple init systems
 3. drop kfreebsd (and HURD and others)
 
 3 basically means dropping Universal from Debian, and replace it with
 Linux.

 Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
 as runs everything (when a Debian GNU/WinNT?).

The main issue I have with dropping kFreeBSD  HURD would be (apart from
losing two platforms I use - even if for fun only; I don't want to use a
distribution that doesn't allow me to have as much fun as I do now) that
it leads down the path of dropping whatever a vocal upstream decides to
don't care about.

What if next year $upstream_of_an_important_package decides that he only
cares about amd64 and arm? The rest of the world is obsolete anyway...

Would Debian drop i386, ppc, mips and the rest?

-- 
|8]


--
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/87zkkbhmbh@balabit.hu

Re: A few observations about systemd

 I think only supporting Linux is entirely his perogative: It's his
 project, his time and he can support what he wants.

Hmm.  I may be wrong, but I was under the impression that he's pushing
systemd as the standard init, not just as his hobby project.  Josselin
may have more information.

-- Juliusz


-- 
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/87mxgbc00q@trurl.pps.jussieu.fr

Re: A few observations about systemd

   start-stop-daemon (and/or a new C helper that is run like s-s-d and
   does some of the same things as systemd)

Another architecture would be a daemon that is run from inittab, but
yes, your have a point there.

-- Juliusz


-- 
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/87ipqzbzxn@trurl.pps.jussieu.fr

Re: A few observations about systemd

On Mon, Jul 18, 2011 at 1:15 PM, Gergely Nagy alger...@balabit.hu wrote:
Federico Di Gregorio f...@debian.org writes:

On 18/07/11 12:13, Samuel Thibault wrote:
Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
1. carry portability patches against systemd locally
2. support multiple init systems
3. drop kfreebsd (and HURD and others)

3 basically means dropping Universal from Debian, and replace it with
Linux.

Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
as runs everything (when a Debian GNU/WinNT?).

The main issue I have with dropping kFreeBSD HURD would be (apart from
losing two platforms I use - even if for fun only; I don't want to use a
distribution that doesn't allow me to have as much fun as I do now) that
it leads down the path of dropping whatever a vocal upstream decides to
don't care about.

What if next year $upstream_of_an_important_package decides that he only
cares about amd64 and arm? The rest of the world is obsolete anyway...

What about also embeded marked ? Projection says what consumer will
use more embeded software than desktop in the next years.
Systemd seems pretty non modular and too heavy weight for this, at
least for now.

Would Debian drop i386, ppc, mips and the rest?

--
|8]

--
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/87zkkbhmbh@balabit.hu

--
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/CAE2SPAZj=-pMMsXjgVGRWZ9A91zE1K=ghgncg5dmdhmpo0m...@mail.gmail.com

Re: A few observations about systemd

2011-07-18 Thread Gergely Nagy

 What if next year $upstream_of_an_important_package decides that he only
 cares about amd64 and arm? The rest of the world is obsolete anyway...

 What about also embeded marked ? Projection says what consumer will
 use more embeded software than desktop in the next  years.
 Systemd seems pretty non modular and too heavy weight for this, at
 least for now.

It's actually lighter than sysvinit, from what I've seen so far, but my
experiences are fairly limited.

Furthermore, on embedded systems where it doesn't make sense to use
systemd, most probably sysvinit makes even less sense, and they're using
a custom init anyway.

But I'm not an embedded guy, the closest thing I have is my router,
which is using busybox's init, to the best of my knowledge.

-- 
|8]


-- 
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/87vcuzhkt8@balabit.hu

Re: A few observations about systemd

2011-07-18 Thread Simon McVittie

On Mon, 18 Jul 2011 at 12:34:52 +0200, Federico Di Gregorio wrote:
 Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
 as runs everything (when a Debian GNU/WinNT?).

I've always understood the universal OS to mean all-purpose and/or
for everyone. There's currently no CPU architecture suitable for all
purposes for which an OS is needed (I wouldn't want an x86 in my phone, or any
current ARM CPU in my laptop), so portability between CPU architectures
is necessary in order to be universal, but I think that's an implementation
detail rather than a goal.

Is Linux suitable for all purposes for which an OS is needed? I think that's
an open question. I'm not at all convinced that the ability to use kFreeBSD
or Hurd makes Debian any more universal (in terms of people who can use it,
or things you can use it for) than it already was, but the people working
on those ports clearly think there's some benefit in supporting them.

The point at which kFreeBSD or Hurd might harm Debian's universality is the
point at which supporting them causes problems for the rest of the project.
Are they a net benefit or a net burden to the rest of the project? I don't
claim to have the answer, but I think that's the question to be asking.

systemd is far from the only project whose maintainer considers supporting
non-Linux to be a waste of effort. Lennart does have a good point that
writing portably requires you to refrain from using features that were
added to Linux specifically to make what you're doing easier, more efficient
or both, which seems perverse at best. Perhaps the solution to systemd
portability is to give the FreeBSD kernel more of the useful features that
originated in Linux?

Indeed, you could view portability to many kernels as an instance of the
platform problem http://lwn.net/Articles/443531/: presumably, the only
reason you'd want to target kFreeBSD is that it does something better than
Linux does, but perhaps the right solution to that is to make Linux better.

S


-- 
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/20110718115410.ga31...@reptile.pseudorandom.co.uk

Re: A few observations about systemd

]] Gergely Nagy 

| Federico Di Gregorio f...@debian.org writes:
| 
|  On 18/07/11 12:13, Samuel Thibault wrote:
|  Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
|  1. carry portability patches against systemd locally
|  2. support multiple init systems
|  3. drop kfreebsd (and HURD and others)
|  
|  3 basically means dropping Universal from Debian, and replace it with
|  Linux.
| 
|  Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
|  as runs everything (when a Debian GNU/WinNT?).
| 
| The main issue I have with dropping kFreeBSD  HURD would be (apart from
| losing two platforms I use - even if for fun only; I don't want to use a
| distribution that doesn't allow me to have as much fun as I do now) that
| it leads down the path of dropping whatever a vocal upstream decides to
| don't care about.

Just for the record: Hurd's no longer in unstable and hasn't been for a
while.

| What if next year $upstream_of_an_important_package decides that he only
| cares about amd64 and arm? The rest of the world is obsolete anyway...

Then we patch it or work around it somehow.

I'm not arguing for dropping kfreebsd, and I would like some of the
kFreeBSD porters to speak up with suggestions on how to handle the
situation best for them.  After all, it's they who have to live with
whatever solution we end up with.

-- 
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/8739i33it6@qurzaw.varnish-software.com

Re: A few observations about systemd

Tollef Fog Heen, le Mon 18 Jul 2011 13:54:45 +0200, a écrit :
 | Federico Di Gregorio f...@debian.org writes:
 | 
 |  On 18/07/11 12:13, Samuel Thibault wrote:
 |  Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
 |  1. carry portability patches against systemd locally
 |  2. support multiple init systems
 |  3. drop kfreebsd (and HURD and others)
 |  
 |  3 basically means dropping Universal from Debian, and replace it with
 |  Linux.
 | 
 |  Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
 |  as runs everything (when a Debian GNU/WinNT?).
 | 
 | The main issue I have with dropping kFreeBSD  HURD would be (apart from
 | losing two platforms I use - even if for fun only; I don't want to use a
 | distribution that doesn't allow me to have as much fun as I do now) that
 | it leads down the path of dropping whatever a vocal upstream decides to
 | don't care about.
 
 Just for the record: Hurd's no longer in unstable and hasn't been for a
 while.

Just for the record: Hurd is still in unstable and has been there for a
while, and is considered as a candidate for wheezy.

Samuel


-- 
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/20110718115720.gp4...@const.bordeaux.inria.fr

Re: A few observations about systemd

2011-07-18 Thread Gergely Nagy

Tollef Fog Heen tfh...@err.no writes:

 | The main issue I have with dropping kFreeBSD  HURD would be (apart from
 | losing two platforms I use - even if for fun only; I don't want to use a
 | distribution that doesn't allow me to have as much fun as I do now) that
 | it leads down the path of dropping whatever a vocal upstream decides to
 | don't care about.

 Just for the record: Hurd's no longer in unstable and hasn't been for a
 while.

True, but kFreeBSD is, and it's even growing a mipsel (or was it mips?)
leg, if I understood correctly.

 | What if next year $upstream_of_an_important_package decides that he only
 | cares about amd64 and arm? The rest of the world is obsolete anyway...

 Then we patch it or work around it somehow.

 I'm not arguing for dropping kfreebsd, and I would like some of the
 kFreeBSD porters to speak up with suggestions on how to handle the
 situation best for them.  After all, it's they who have to live with
 whatever solution we end up with.

Yup, completely agreed. My response was towards those who even
considered dropping an architecture as even a remotely possible
solution, and began arguing about what Universal meant.

(Personally, I like the patch systemd path best, and time and skill
permitting, I'd be happy to help, if so need be.)

-- 
|8]


-- 
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/87r55nhk4m@balabit.hu

Re: A few observations about systemd

On Mon, Jul 18, 2011 at 1:47 PM, Gergely Nagy alger...@balabit.hu wrote:
 What if next year $upstream_of_an_important_package decides that he only
 cares about amd64 and arm? The rest of the world is obsolete anyway...

 What about also embeded marked ? Projection says what consumer will
 use more embeded software than desktop in the next  years.
 Systemd seems pretty non modular and too heavy weight for this, at
 least for now.

 It's actually lighter than sysvinit, from what I've seen so far, but my
 experiences are fairly limited.

See depends. At least it could use dlopen and fall back

Bastien



 Furthermore, on embedded systems where it doesn't make sense to use
 systemd, most probably sysvinit makes even less sense, and they're using
 a custom init anyway.

 But I'm not an embedded guy, the closest thing I have is my router,
 which is using busybox's init, to the best of my knowledge.

 --
 |8]


 --
 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/87vcuzhkt8@balabit.hu




--
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/CAE2SPAa9fWohpvR=tpywroblw1dotftosrwvpusknpwjvg4...@mail.gmail.com

Re: A few observations about systemd

2011-07-18 Thread Federico Di Gregorio

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/07/11 13:15, Gergely Nagy wrote:
 Federico Di Gregorio f...@debian.org writes:
 
  On 18/07/11 12:13, Samuel Thibault wrote:
  Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
  1. carry portability patches against systemd locally
  2. support multiple init systems
  3. drop kfreebsd (and HURD and others)
  
  3 basically means dropping Universal from Debian, and replace it with
  Linux.
 
  Wasn't universal as in runs everywhere (i.e., on a lot of archs) vs
  as runs everything (when a Debian GNU/WinNT?).
 The main issue I have with dropping kFreeBSD  HURD would be (apart from
 losing two platforms I use - even if for fun only; I don't want to use a
 distribution that doesn't allow me to have as much fun as I do now) that
 it leads down the path of dropping whatever a vocal upstream decides to
 don't care about.

I'd never advocate dropping kernels or archs. Our social contract binds
us to provider our *users* the best possible OS. If systemd makes Debian
GNU/Linux better (and here I am supposing the vast majority of Debian
users are Linux users) then the right thing to do is to use it.

What about other kernels? What about embedded systems? That depends on
the developers involved. Probably using a different init or porting
systemd is a fine solution, depending on the amount of work required.

FreeBSD, HURD and Linux have different targets, a different user base
and a different developer base. Trying to create a completely uniform
Debian out of them is, IMO; doomed to fail. We don't want three
sub-optimal, perfectly identical operating systems. We want the three
best operating systems (maybe a little bit different in functionality)
we can give to our users. Right?

federico

- -- 
Federico Di Gregoriof...@debian.org
 - Ma cos'ha il tuo pesce rosso, l'orchite?
 - Si, ha un occhio solo, la voce roca e mangia gli altri pesci.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4kIHoACgkQvcCgrgZGjesj/gCePjKk5Lsdh+Ki++uIgWAwlU1N
QyYAn0AwKHjCQiJzw06k9UieQkJD1tfl
=i/XD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e24207a.1090...@debian.org

Re: register files in dpkg database programmatically? (was Re: How Debian Deals with Data)

2011-07-18 Thread Paul Wise

On Sun, Jul 17, 2011 at 1:04 AM, Peter Samuelson wrote:

 - Treat the file as though it were shipped in the package directly.
  This means it is removed on package upgrade, as well as on package
  removal.  This is very straightforward (append the filename to
  /var/lib/dpkg/info/{foo}.list), but perhaps not too useful.

Do you have a use-case for this? I guess such files would need to be
re-created on package upgrade and I'm not sure how useful this is.

 - Do not remove the file on package upgrade, but do remove it when
  removing the package.

I would use this in clamav-unofficial-sigs.
Registration/de-registration would happen both at postinst time and
also runtime from a cron job.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/CAKTje6G+DG4RiyytmFpvEP=-6444gdhwtdbhcdtmvngdtp+...@mail.gmail.com

Re: A few observations about systemd

 It's actually lighter than sysvinit, from what I've seen so far,

$ size /sbin/init /bin/systemd 
   textdata bss dec hex filename
  300401320 612   319727ce4 /sbin/init
 79369167482188  802627   c3f43 /bin/systemd

-- Juliusz


-- 
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/877h7fbxtk@trurl.pps.jussieu.fr

Re: A few observations about systemd

2011-07-18 Thread Adam D. Barratt


On Mon, 18 Jul 2011 13:54:45 +0200, Tollef Fog Heen wrote:
Just for the record: Hurd's no longer in unstable and hasn't been for 
a

while.


Hurd very much is still in unstable - hppa was the h.{3} architecture 
which we dropped.


Regards,

Adam


--
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/fc4f5396272cea51b755de5786d5a...@adsl.funky-badger.org

Re: A new version of make-dfsg has been uploaded to experimental, please test

2011-07-18 Thread Ian Jackson

Manoj Srivastava writes (A new version of make-dfsg has been uploaded to 
experimental, please test):
 make 3.82 will require some transitions due to backward
  incompatibility on GNU-make-specific features.  Some bug reports have
  already occurred for build issues with make 3.82, such as
  http://bugs.debian.org/603759 . Since there are known backward
  incompatibilities, make has been uploaded to experimental. NEWS.Debian
  has an incompatibility list.

Thanks for the heads-up.  *sigh*, why do they keep doing that ?

Anyway, can you please post the incompatibility list here, if it's not
too long ?  The package itself is still in incoming.

Ian.


-- 
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/20004.8629.319448.606...@chiark.greenend.org.uk

Re: A new version of make-dfsg has been uploaded to experimental, please test

2011-07-18 Thread Ian Jackson

I wrote:
 Anyway, can you please post the incompatibility list here, if it's not
 too long ?

Never mind, fetched it myself.

Ian.

make-dfsg (3.82-1) experimental; urgency=low

  * New upstream release. A complete list of bugs fixed in this version is
available here:  
http://sv.gnu.org/bugs/index.php?group=makereport_id=111fix_release_id=104set=custom
  * WARNING: Future backward-incompatibility!
Wildcards are not documented as returning sorted values, but up to and
including this release the results have been sorted and some makefiles
are apparently depending on that.  In the next release of GNU make,
for performance reasons, we may remove that sorting.  If your
makefiles require sorted results from wildcard expansions, use the
$(sort ...)  function to request it explicitly.
  * WARNING: Backward-incompatibility!
The POSIX standard for make was changed in the 2008 version in a
fundamentally incompatible way: make is required to invoke the shell
as if the '-e' flag were provided.  Because this would break many
makefiles that have been written to conform to the original text of
the standard, the default behavior of GNU make remains to invoke the
shell with simply '-c'.  However, any makefile specifying the .POSIX
special target will follow the new POSIX standard and pass '-e' to the
shell.  See also .SHELLFLAGS below.
  * WARNING: Backward-incompatibility!
The '$?' variable now contains all prerequisites that caused the
target to be considered out of date, even if they do not exist
(previously only existing targets were provided in $?).
  * WARNING: Backward-incompatibility!
As a result of parser enhancements, three backward-compatibility
issues exist: first, a prerequisite containing an = cannot be
escaped with a backslash any longer.  You must create a variable
containing an = and use that variable in the prerequisite.  Second,
variable names can no longer contain whitespace, unless you put the
whitespace in a variable and use the variable.  Third, in previous
versions of make it was sometimes not flagged as an error for explicit
and pattern targets to appear in the same rule.  Now this is always
reported as an error.
  * WARNING: Backward-incompatibility!
The pattern-specific variables and pattern rules are now applied in
the shortest stem first order instead of the definition order
(variables and rules with the same stem length are still applied in
the definition order). This produces the usually-desired behavior
where more specific patterns are preferred. To detect this feature
search for 'shortest-stem' in the .FEATURES special variable.
  * WARNING: Backward-incompatibility!
The library search behavior has changed to be compatible with the
standard linker behavior. Prior to this version for prerequisites
specified using the -lfoo syntax make first searched for libfoo.so in
the current directory, vpath directories, and system directories. If
that didn't yield a match, make then searched for libfoo.a in these
directories. Starting with this version make searches first for
libfoo.so and then for libfoo.a in each of these directories in order.
  * New command line option: --eval=STRING causes STRING to be evaluated
as makefile syntax (akin to using the $(eval ...) function).  The
evaluation is performed after all default rules and variables are
defined, but before any makefiles are read.
  * New special variable: .RECIPEPREFIX allows you to reset the recipe
introduction character from the default (TAB) to something else.  The
first character of this variable value is the new recipe introduction
character.  If the variable is set to the empty string, TAB is used
again.  It can be set and reset at will; recipes will use the value
active when they were first parsed.  To detect this feature check the
value of $(.RECIPEPREFIX).
  * New special variable: .SHELLFLAGS allows you to change the options
passed to the shell when it invokes recipes.  By default the value
will be -c (or -ec if .POSIX is set).
  * New special target: .ONESHELL instructs make to invoke a single
instance of the shell and provide it with the entire recipe,
regardless of how many lines it contains.  As a special feature to
allow more straightforward conversion of makefiles to use .ONESHELL,
any recipe line control characters ('@', '+', or '-') will be removed
from the second and subsequent recipe lines.  This happens _only_ if
the SHELL value is deemed to be a standard POSIX-style shell.  If not,
then no interior line control characters are removed (as they may be
part of the scripting language used with the alternate SHELL).
  * New variable modifier 'private': prefixing a variable assignment with
the modifier 'private' suppresses inheritance of that variable by
prerequisites.  This is most

Re: A few observations about systemd

Juliusz Chroboczek, le Mon 18 Jul 2011 14:03:19 +0200, a écrit :
  It's actually lighter than sysvinit, from what I've seen so far,
 
 $ size /sbin/init /bin/systemd 
textdata bss dec hex filename
   300401320 612   319727ce4 /sbin/init
  79369167482188  802627   c3f43 /bin/systemd

Well, sysvinit is not only /sbin/init, and systemd is not only sysvinit.

Samuel


-- 
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/20110718122812.gs4...@const.bordeaux.inria.fr

Re: A few observations about systemd

]] Samuel Thibault 

| Just for the record: Hurd is still in unstable and has been there for a
| while, and is considered as a candidate for wheezy.

Oh, indeed, it's just so far behind I didn't see it.  Mea culpa.

-- 
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/87mxgb22k7@qurzaw.varnish-software.com

Re: A few observations about systemd

On Mon, Jul 18, 2011 at 2:28 PM, Samuel Thibault sthiba...@debian.org wrote:
 Juliusz Chroboczek, le Mon 18 Jul 2011 14:03:19 +0200, a écrit :
  It's actually lighter than sysvinit, from what I've seen so far,

 $ size /sbin/init /bin/systemd
    text    data     bss     dec     hex filename
   30040    1320     612   31972    7ce4 /sbin/init
  793691    6748    2188  802627   c3f43 /bin/systemd

 Well, sysvinit is not only /sbin/init, and systemd is not only sysvinit.

Yes but 793691kb of unkillable even by -9 signal is not really nice.
Better security will need to keep pid==1 to some really simple stuff,
and delegate funky stuff to another daemon. pid == 1 should be keep
only to reap zombie process no more.

Bastien


 Samuel


 --
 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/20110718122812.gs4...@const.bordeaux.inria.fr




--
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/cae2spazdwc9lzdrljau3_3k_xwj2ah3vn9fsyd52tb_-x+v...@mail.gmail.com

Re: A few observations about systemd

On Mon, 18 Jul 2011, Gergely Nagy alger...@balabit.hu wrote:
 The main issue I have with dropping kFreeBSD  HURD would be (apart from
 losing two platforms I use - even if for fun only; I don't want to use a
 distribution that doesn't allow me to have as much fun as I do now) that
 it leads down the path of dropping whatever a vocal upstream decides to
 don't care about.

I don't think that dropping an architecture is necessary, patching systemd 
should be viable.

Sysvinit had a lot of patches in the Debian package that weren't included 
upstream for a long time.  There's no reason why the same couldn't be done for 
systemd.

It seems that cgroups is the main issue and systemd can already work without 
them.

On Mon, 18 Jul 2011, Juliusz Chroboczek j...@pps.jussieu.fr wrote:
  It's actually lighter than sysvinit, from what I've seen so far,
 
 $ size /sbin/init /bin/systemd 
textdata bss dec hex filename
   300401320 612   319727ce4 /sbin/init
  79369167482188  802627   c3f43 /bin/systemd

I think that they meant lighter in terms of not running shell scripts for lots 
of things.

A fast boot time is quite important for embedded systems.  I'm looking forward 
to using systemd in a year or two for some embedded systems that I run.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201107182246.10458.russ...@coker.com.au

Re: A few observations about systemd

2011-07-18 Thread Fernando Lemos

On Mon, Jul 18, 2011 at 9:02 AM, Gergely Nagy alger...@balabit.hu wrote:
[...]
 (Personally, I like the patch systemd path best, and time and skill
 permitting, I'd be happy to help, if so need be.)

While that may sound attractive at first, I don't think it's
technically possible at all at the moment. It's not a simple
portability problem, systemd relies on very complex Linux-specific
stuff. I think implementing all the required stuff would be an effort
comparable to implementing something like KMS or GEM or Gallium3D on
FreeBSD. It's simply not something a distribution could be concerned
with, so I don't think it would be realistic to consider this an
option. That said, I'd love to be proven wrong.


-- 
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/CANVYNa_hzFgUd6jmRY-e19=cqhor_8s779lj0wpk3np-qsf...@mail.gmail.com

Re: A few observations about systemd

On Mon, 18 Jul 2011, Bastien ROUCARIES roucaries.bast...@gmail.com wrote:
 Yes but 793691kb of unkillable even by -9 signal is not really nice.

root 1  0.0  1.0   4348  2844 ?Ss   May26   0:56 /bin/systemd 
--log-level info --log-target syslog-or-kmsg --system --dump-core --show-
status=1 --sysv-console=1 --deserialize 19

Unless systemd locks it's memory (and /proc/1/maps suggests not) then that 
will all be demand-paged and probably not much will be used on most systems.  
The above is from the ps output from one of my test i386 systems.

root 1  0.0  0.0   2024   132 ?Ss   Jan28   5:16 init [2]   
  

The above is from the ps output of one of my i386 servers running Squeeze.  It 
appears that systemd has allocated an extra 2324K of RAM and has an extra 
2712K resident.  Given that it's difficult to buy a phone with less than 256M 
of RAM nowadays that doesn't seem to be a big problem, and systemd can save 
memory by removing the need to run other daemons.

 Better security will need to keep pid==1 to some really simple stuff,
 and delegate funky stuff to another daemon. pid == 1 should be keep
 only to reap zombie process no more.

I think you mean to say that there is a theoretical benefit for reliability 
there.  As all the things that systemd does will be performed by different 
root owned processes in a typical Linux system there won't be much potential 
for security benefits in using separate processes.  Even with the most strict 
configuration of SE Linux the ability to constrain things such as autofs which 
can be included in systemd isn't a huge benefit as it's extremely difficult to 
constrain them to prevent attack.  If your autofs decides to mount an 
untrusted device (be it removable media or network) and allow device nodes 
and/or SUID binaries then you're going to lose.

Finally vmlinuz is 2.3M compressed on Squeeze and it has a huge amount of code 
used for modules.  If a serious bug is found in any of that code then nothing 
will save you.  I don't think that systemd is the security issue.

You could have a HURD system running SE Linux to constrain it's device drivers 
which is similar to some research projects that preceded SE Linux and is quite 
possible to implement if someone has enough coding time.  On such a system 
systemd might comprise a significant portion of the code that is highly 
trusted.  So I would be a lot more inclined to accept an argument for sysvinit 
over systemd if it was based on a SE-HURD platform.  But SE-HURD doesn't exist 
at this time and seems unlikely to exist in the next few years.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201107182313.00615.russ...@coker.com.au

Re: A few observations about systemd

2011-07-18 Thread Robert Millan

2011/7/18 Tollef Fog Heen tfh...@err.no:
 | The main issue I have with dropping kFreeBSD  HURD would be (apart from
 | losing two platforms I use - even if for fun only; I don't want to use a
 | distribution that doesn't allow me to have as much fun as I do now) that
 | it leads down the path of dropping whatever a vocal upstream decides to
 | don't care about.

 Just for the record: Hurd's no longer in unstable and hasn't been for a
 while.

I'm confused... I just checked and Hurd is in unstable.  Did you mean
something else?

 I'm not arguing for dropping kfreebsd, and I would like some of the
 kFreeBSD porters to speak up with suggestions on how to handle the
 situation best for them.  After all, it's they who have to live with
 whatever solution we end up with.

I missed the rest of the discussion, but if the proposal is to replace
sysvinit with systemd, that wouldn't force removal of any non-Linux
port.  It'd be an annoying inconvenient though, as it'd just make it
diverge a bit more than it already does.

Have you considered InitNG instead?  It seems to have similar goals as
upstart/systemd without sacrificing portability:

http://initng.org/trac

-- 
Robert Millan


--
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/CAOfDtXNo18etF4Cr3o3b9SS6vq_7=htlzyy6bmgd-qfqfao...@mail.gmail.com

Portability of systemd [was: A few observations about systemd]

 It's not a simple portability problem, systemd relies on very complex
 Linux-specific stuff.

Well, having looked at the code, yes and no.

Yes, because systemd recodes the whole startup process in C.
Translating a lot of distritibution-specific shell code into C is not
going to be portable:

  $ grep '^#.*TARGET' vconsole-setup.c 
  #ifdef TARGET_GENTOO
  #ifdef TARGET_MANDRIVA
  #if defined(TARGET_FEDORA) || defined(TARGET_MEEGO)
  #if defined(TARGET_FEDORA) || defined(TARGET_MEEGO)
  #elif defined(TARGET_SUSE)
  #elif defined(TARGET_ARCH)
  #elif defined(TARGET_FRUGALWARE)
  #elif defined(TARGET_ALTLINUX)
  #elif defined(TARGET_GENTOO)
  #elif defined(TARGET_MANDRIVA)

No, because that's not the case of systemd's core.  From what I've seen,
most of the non-portable code in systemd's core is merely there for
convenience.  For example, the %m printf descriptor is used extensively,
which is just shorthand for strerror.  Similarly, openat is used in
systemctl in order to implement a virtual cwd -- since systemctl is not
multi-threaded, this is easily (albeit messily) simulated with either
chdir or by manually concatenating absolute paths.

Now I've certainly not read all of the systemd code, but the one
exception that I've noticed is the use of cgroups.  While cgroups
provide systemd with some of its coolest functionality (notably the
ability to monitor SV initscripts, and the ability to reliably kill
mis-behaving multi-process daemons), I'm not sure to what extent people
think this functionality is central to systemd.

 I think implementing all the required stuff would be an effort
 comparable to implementing something like KMS or GEM or Gallium3D on
 FreeBSD.

I think that's an overstatement.

-- Juliusz


-- 
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/8739i3buad.fsf...@trurl.pps.jussieu.fr

Re: A few observations about systemd

2011-07-18 Thread Philipp Kern

On 2011-07-18, Samuel Thibault sthiba...@debian.org wrote:
 Just for the record: Hurd's no longer in unstable and hasn't been for a
 while.
 Just for the record: Hurd is still in unstable and has been there for a
 while, and is considered as a candidate for wheezy.

Just for the record: Hurd is not yet considered as a candidate, it just might
become one.


-- 
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/slrnj28eac.v70.tr...@kelgar.0x539.de

Re: A few observations about systemd

2011-07-18 Thread Matthias Klumpp

Hi!
I spoke with Lennart Poettering about this thread on IRC, and he asked me
to forward some clarifications about systemd to this list:


i found while reading through that thread

 a) the main memory usage by systemd is actually the selinux policy we
load in to memory so that we can tag sockets properly
so the big memory consumption is the price you pay for selinux, not
really for systemd
systemd will use more memory than sysvinit however
though if you then subtract the memory for inetd and so on, it will
probably comapre not too bad.
(!My Note: systemd can *of course* be used without SELinux)
the selinux policy issue is probably something we can improve, by
loading the policy only partially.

 b) systemd is very much suitable for the embedded area, that's why meego
switched to it, and it is available in a couple of embedded distributions
and, i am sure that those embedded distros are much better choices for
embedded devices, then debian is. with other words: systemd should cover 
the full range of debian. (!My Note: I showed him http://emdebian.org -
embedded devices means only really small devices here, the whole mobile
stuff is of course covered)

 c) the big problem for them about portability is not so much that i won't
accept the patches. it's primarily that porting it to non-linux is
practically impossible. about every line of it is non-portable code
i.e. we already use epoll as a main loop, already there you'll have a
hard time porting this to something else

 d) some of the debian folks seem to suggest that adopting upstart instead
of systemd would be a way out
that's bogus, since upstart is not portable to non-linux either

[15:45] mezcalero ximion: so, yeah, that's all my points
[15:45] mezcalero ximion: would be happy if you could forward that to
the ML


I think this clarifies some questions - and btw., speaking with Lennart is
not really annoying, if there are further questions about systemd, I don't
think just asking Lennart about it should be a problem, as well as
submitting patches for something Debian needs. ( c) seems to be a fair
reason for not accepting portability patches directly to systemd's main
branch to me)

Cheers,
  Matthias


-- 
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/6e497ec0e1ceeb0bd431966a81914...@mb8-2.1blu.de

Re: A few observations about systemd

Matthias Klumpp, le Mon 18 Jul 2011 16:03:41 +0200, a écrit :
 though if you then subtract the memory for inetd and so on, it will
 probably comapre not too bad.

Does systemd really intend to replace inetd too, including things like
internal echo server etc.?

Samuel


-- 
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/20110718142504.gf4...@const.bordeaux.inria.fr

Re: A few observations about systemd

On Mon, Jul 18, 2011 at 3:13 PM, Russell Coker russ...@coker.com.au wrote:
On Mon, 18 Jul 2011, Bastien ROUCARIES roucaries.bast...@gmail.com wrote:
Yes but 793691kb of unkillable even by -9 signal is not really nice.

root 1 0.0 1.0 4348 2844 ? Ss May26 0:56 /bin/systemd
--log-level info --log-target syslog-or-kmsg --system --dump-core --show-
status=1 --sysv-console=1 --deserialize 19

Unless systemd locks it's memory (and /proc/1/maps suggests not) then that
will all be demand-paged and probably not much will be used on most systems.
The above is from the ps output from one of my test i386 systems.

root 1 0.0 0.0 2024 132 ? Ss Jan28 5:16 init [2]

The above is from the ps output of one of my i386 servers running Squeeze. It
appears that systemd has allocated an extra 2324K of RAM and has an extra
2712K resident. Given that it's difficult to buy a phone with less than 256M
of RAM nowadays that doesn't seem to be a big problem, and systemd can save
memory by removing the need to run other daemons.

I have some avr32 card with 32Mb that are valuable and do measurement
over network with blas/lapack. 1Mb is a lot of double. Phone is not
the only market.

Better security will need to keep pid==1 to some really simple stuff,
and delegate funky stuff to another daemon. pid == 1 should be keep
only to reap zombie process no more.

I think you mean to say that there is a theoretical benefit for reliability
there. As all the things that systemd does will be performed by different
root owned processes in a typical Linux system there won't be much potential
for security benefits in using separate processes.

pid == 1 is immortal. I should not get unrecoverable signal like
sigsegv. I could restart other daemon if needed.

Even with the most strict
configuration of SE Linux the ability to constrain things such as autofs which
can be included in systemd isn't a huge benefit as it's extremely difficult to
constrain them to prevent attack. If your autofs decides to mount an
untrusted device (be it removable media or network) and allow device nodes
and/or SUID binaries then you're going to lose.

It is more profound. Pid == 1 could not be killed is it does bad work.
I will prefer a simple init daemon that could spawn a rescue shell if
needed over a ttyS or netconsole. If systemd is stuck I have better
chance to log onto my system. It will save development time.

Finally vmlinuz is 2.3M compressed on Squeeze and it has a huge amount of code
used for modules. If a serious bug is found in any of that code then nothing
will save you. I don't think that systemd is the security issue.

I use to recompile my own kernel. The problem is not init is root and
trusted code, but more init is unkillable.

You could have a HURD system running SE Linux to constrain it's device drivers
which is similar to some research projects that preceded SE Linux and is quite
possible to implement if someone has enough coding time. On such a system
systemd might comprise a significant portion of the code that is highly
trusted. So I would be a lot more inclined to accept an argument for sysvinit
over systemd if it was based on a SE-HURD platform. But SE-HURD doesn't exist
at this time and seems unlikely to exist in the next few years.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/

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

Re: A few observations about systemd

2011-07-18 Thread Roger Leigh

On Mon, Jul 18, 2011 at 04:03:41PM +0200, Matthias Klumpp wrote:
  c) the big problem for them about portability is not so much that i won't
 accept the patches. it's primarily that porting it to non-linux is
 practically impossible. about every line of it is non-portable code
 i.e. we already use epoll as a main loop, already there you'll have a
 hard time porting this to something else

Seriously?  It's just a poll interface.  How hard could it /possibly/
be to fall back to using plain poll(2) in the mainloop?  It's not
like the interfaces are vastly different.  Both poll(2) and epoll_*(2)
do pretty much exactly the same thing.  epoll might be a better
performing interface, and scale better, but it's not like poll(2) is
broken or particularly difficult to use.  (It's actually far simpler.)

There is plenty of portable software out there doing exactly this.
systemd isn't particularly special in this respect.  Take a look at
apache, for example.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: A few observations about systemd

]] Robert Millan 

| 2011/7/18 Tollef Fog Heen tfh...@err.no:
|  | The main issue I have with dropping kFreeBSD  HURD would be (apart from
|  | losing two platforms I use - even if for fun only; I don't want to use a
|  | distribution that doesn't allow me to have as much fun as I do now) that
|  | it leads down the path of dropping whatever a vocal upstream decides to
|  | don't care about.
| 
|  Just for the record: Hurd's no longer in unstable and hasn't been for a
|  while.
| 
| I'm confused... I just checked and Hurd is in unstable.  Did you mean
| something else?

No, I merely misread the rmadison output.

|  I'm not arguing for dropping kfreebsd, and I would like some of the
|  kFreeBSD porters to speak up with suggestions on how to handle the
|  situation best for them.  After all, it's they who have to live with
|  whatever solution we end up with.
| 
| I missed the rest of the discussion, but if the proposal is to replace
| sysvinit with systemd, that wouldn't force removal of any non-Linux
| port.  It'd be an annoying inconvenient though, as it'd just make it
| diverge a bit more than it already does.

(please read a bit more of the thread, I'd really like your input, but
your answer seems a bit incomplete in the context of the full thread.)

Where «a bit more» means that it'll run completely separate scripts for
booting and starting daemons.  This also means people won't be testing
those scripts which will undoubtedly lead to bugs.  I really don't think
that's a good way forward.

| Have you considered InitNG instead?  It seems to have similar goals as
| upstart/systemd without sacrificing portability:

No.  Part of the reason why I think systemd is interesting is because
some/all/lots of the other distros are moving in the same direction and
there's not really much to win in terms of having different init systems
and init scripts than the others.

Regards,
-- 
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/87ipqz1vpa@qurzaw.varnish-software.com

Re: Portability of systemd [was: A few observations about systemd]

On Mon, Jul 18, 2011 at 3:19 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote:
It's not a simple portability problem, systemd relies on very complex
Linux-specific stuff.

Well, having looked at the code, yes and no.

Yes, because systemd recodes the whole startup process in C.
Translating a lot of distritibution-specific shell code into C is not
going to be portable:

$ grep '^#.*TARGET' vconsole-setup.c
#ifdef TARGET_GENTOO
#ifdef TARGET_MANDRIVA
#if defined(TARGET_FEDORA) || defined(TARGET_MEEGO)
#if defined(TARGET_FEDORA) || defined(TARGET_MEEGO)
#elif defined(TARGET_SUSE)
#elif defined(TARGET_ARCH)
#elif defined(TARGET_FRUGALWARE)
#elif defined(TARGET_ALTLINUX)
#elif defined(TARGET_GENTOO)
#elif defined(TARGET_MANDRIVA)

No, because that's not the case of systemd's core. From what I've seen,
most of the non-portable code in systemd's core is merely there for
convenience. For example, the %m printf descriptor is used extensively,
which is just shorthand for strerror.

see gnulib portable to most unix

Similarly, openat is used in
systemctl in order to implement a virtual cwd -- since systemctl is not
multi-threaded, this is easily (albeit messily) simulated with either
chdir or by manually concatenating absolute paths.

See also gnulib but could fail if mode change behalf (see also
gnulib). Could be emulated using fork then sending fd by socket

Now I've certainly not read all of the systemd code, but the one
exception that I've noticed is the use of cgroups. While cgroups
provide systemd with some of its coolest functionality (notably the
ability to monitor SV initscripts, and the ability to reliably kill
mis-behaving multi-process daemons), I'm not sure to what extent people
think this functionality is central to systemd.

BSD jail

I think implementing all the required stuff would be an effort
comparable to implementing something like KMS or GEM or Gallium3D on
FreeBSD.

I think that's an overstatement.

-- Juliusz

--
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/8739i3buad.fsf...@trurl.pps.jussieu.fr

--
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/CAE2SPAa=hcaq9lg+o_xcck7ncgaqxy2sitfomqhsd5xgx+g...@mail.gmail.com

Re: A few observations about systemd

2011-07-18 Thread Ben Hutchings

On Mon, 2011-07-18 at 11:34 +0100, Jon Dowland wrote:
 On Mon, Jul 18, 2011 at 12:13:02PM +0200, Samuel Thibault wrote:
  Jon Dowland, le Mon 18 Jul 2011 10:35:30 +0100, a écrit :
   3. drop kfreebsd (and HURD and others)
  
  3 basically means dropping Universal from Debian, and replace it with
  Linux.
 
 I seem to recall Universal existing long before a non-Linux port.  I don't
 interpret Universal as meaning more than one kernel, nor Debian's heart
 to be the userland in exclusivity.

What's more, neither of the 'ports' to other kernels increases hardware
support.

I fundamentally disagree with the idea that all our packages must avoid
relying on certain features because some developers want to experiment
with FreeBSD (which already has a Linux emulation layer) or Hurd (a
long-running joke) and they are lacking these features.  This doesn't
serve users, it serves those developers.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Re: A few observations about systemd

On Tue, 19 Jul 2011, Matthias Klumpp matth...@nlinux.org wrote:
 I spoke with Lennart Poettering about this thread on IRC, and he asked me
 
 to forward some clarifications about systemd to this list:
 
 
 i found while reading through that thread
 
  a) the main memory usage by systemd is actually the selinux policy we
 load in to memory so that we can tag sockets properly
 so the big memory consumption is the price you pay for selinux, not
 really for systemd

root 1  7.9  1.4  41828  7588 ?Ss   00:42   0:01 /bin/systemd

On an AMD64 KVM instance running SE Linux I see the above in ps output.  When 
I boot the same instance with selinux=0 I see the below:

root 1  9.3  0.7  38236  3868 ?Ss   00:43   0:01 /bin/systemd

It seems that the additional memory use for SE Linux is 3592K used and 3720K 
resident.

On an AMD64 system that means the SE Linux memory overhead in systemd is 8.5% 
of used memory and 49% of resident memory.  While 49% of total resident size 
sounds like a lot, 4M isn't much memory on a remotely modern system.  Of 
course this depends on which policy modules are loaded.

 systemd will use more memory than sysvinit however
 though if you then subtract the memory for inetd and so on, it will
 probably comapre not too bad.
 (!My Note: systemd can *of course* be used without SELinux)
 the selinux policy issue is probably something we can improve, by
 loading the policy only partially.

Yes, I've just spent as much time browsing the systemd code as I'm willing to 
do late at night.  It seems that there is room for improvement based on what I 
observe (the RAM usage is a lot bigger than /etc/selinux) but reading the code 
I can't see anything obvious or easy.

We should be able to cache the things we need and discard the rest with a 
result of only a few K of data used (and maybe 100K of extra code paged in).

  b) systemd is very much suitable for the embedded area, that's why meego
 switched to it, and it is available in a couple of embedded distributions
 and, i am sure that those embedded distros are much better choices for
 embedded devices, then debian is. with other words: systemd should cover
 the full range of debian. (!My Note: I showed him http://emdebian.org -
 embedded devices means only really small devices here, the whole mobile
 stuff is of course covered)

http://doc.coker.com.au/papers/porting-se-linux-hand-held-devices/

As an aside in 2003 I wrote a paper about porting SE Linux to the iPaQ which 
had 64M of RAM and 48M of storage.  One of my clients does some embedded stuff 
nowadays, the smallest motherboards that their suppliers offer have 128M of 
RAM soldered on (and something a lot greater than 48M of storage).

The overhead of systemd on modern embedded systems is a lot less than the 
overhead of some of the things we were doing 8 years ago as a fraction of 
system resources.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201107190105.33678.russ...@coker.com.au

Re: A few observations about systemd

2011-07-18 Thread Joey Hess

Josselin Mouette wrote:
 Developing for Linux-only is fine, but Lennart has explicitly said that
 he wouldn’t remotely consider accepting portability patches, which goes
 further than any other piece of free software I had to deal with.

To the contrary, it's quite similar to OpenBSD's handling of openssh.
(Though without the portablity team yet.)

-- 
see shy jo


signature.asc
Description: Digital signature

Re: A few observations about systemd

On Tue, 19 Jul 2011, Bastien ROUCARIES roucaries.bast...@gmail.com wrote:
  The above is from the ps output of one of my i386 servers running
  Squeeze.  It appears that systemd has allocated an extra 2324K of RAM
  and has an extra 2712K resident.  Given that it's difficult to buy a
  phone with less than 256M of RAM nowadays that doesn't seem to be a big
  problem, and systemd can save memory by removing the need to run other
  daemons.
 
 I have some avr32 card with 32Mb that are valuable and do measurement
 over network with blas/lapack. 1Mb is a lot of double. Phone is not
 the only market.

How do dpkg and apt-get run on that?

http://etbe.coker.com.au/2008/05/22/xen-and-swap/

Back in 2008 I did some tests on Xen DomUs running Debian with varying amounts 
of RAM.  A simple apt-get command to install 14 packages started taking 
exponentially greater amounts of time when less than 32M of RAM were 
available.  A DomU with 28M of RAM wasn't bootable with the default Debian 
initrd.

Given that things are getting bigger all the time (both kernel and user-space) 
I wonder if Wheezy will boot in a default configuration with 32M of RAM 
anyway.

It could be that systemd isn't the biggest problem for 32M systems in Wheezy.

  Better security will need to keep pid==1 to some really simple stuff,
  and delegate funky stuff to another daemon. pid == 1 should be keep
  only to reap zombie process no more.
  
  I think you mean to say that there is a theoretical benefit for
  reliability there.  As all the things that systemd does will be
  performed by different root owned processes in a typical Linux system
  there won't be much potential for security benefits in using separate
  processes.
 
 pid == 1 is immortal. I should not get unrecoverable signal like
 sigsegv. I could restart other daemon if needed.

Jul 19 01:01:47 unstable64 systemd[1]: Caught SEGV, dumped core as pid 889.
Jul 19 01:01:47 unstable64 systemd[1]: Freezing execution

It's not strictly unrecoverable.  If you run kill -11 1 then you get the 
above in syslog.

But it does result in a system that doesn't work properly.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201107190117.20904.russ...@coker.com.au

Re: register files in dpkg database programmatically? (was Re: How Debian Deals with Data)

2011-07-18 Thread Christopher Baines

On Mon, 2011-07-18 at 14:19 +0200, Paul Wise wrote:
 On Sun, Jul 17, 2011 at 1:04 AM, Peter Samuelson wrote:
 
  - Treat the file as though it were shipped in the package directly.
   This means it is removed on package upgrade, as well as on package
   removal.  This is very straightforward (append the filename to
   /var/lib/dpkg/info/{foo}.list), but perhaps not too useful.
 
 Do you have a use-case for this? I guess such files would need to be
 re-created on package upgrade and I'm not sure how useful this is.

This could be used for the original suggestion of fetching data and
placing it on the system, if the data came in any format that allowed
updates of existing data, then the other way would be used (data
persistent when upgraded). This functionality would be very useful for
the above use case. 

Chris


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

Re: A few observations about systemd

]] Russell Coker 

| On Tue, 19 Jul 2011, Bastien ROUCARIES roucaries.bast...@gmail.com wrote:
|   The above is from the ps output of one of my i386 servers running
|   Squeeze.  It appears that systemd has allocated an extra 2324K of RAM
|   and has an extra 2712K resident.  Given that it's difficult to buy a
|   phone with less than 256M of RAM nowadays that doesn't seem to be a big
|   problem, and systemd can save memory by removing the need to run other
|   daemons.
|  
|  I have some avr32 card with 32Mb that are valuable and do measurement
|  over network with blas/lapack. 1Mb is a lot of double. Phone is not
|  the only market.
| 
| How do dpkg and apt-get run on that?

Slowly.

A noop apt-get update takes about 10.5s, one where it updates most of
the Packages files is at closer to six minutes.  This is with / on a SD
card and no swap.

|  pid == 1 is immortal. I should not get unrecoverable signal like
|  sigsegv. I could restart other daemon if needed.
| 
| Jul 19 01:01:47 unstable64 systemd[1]: Caught SEGV, dumped core as pid 889.
| Jul 19 01:01:47 unstable64 systemd[1]: Freezing execution
| 
| It's not strictly unrecoverable.  If you run kill -11 1 then you get the 
| above in syslog.
| 
| But it does result in a system that doesn't work properly.

Well, yes.  If init crashes, stuff generally don't work that well
afterwards. :-)

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


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

Re: A few observations about systemd

2011-07-18 Thread Joey Hess

Simon McVittie wrote:
 The point at which kFreeBSD or Hurd might harm Debian's universality is the
 point at which supporting them causes problems for the rest of the project.

That is the crux of the issue. I think that if we find ourselves being
held back by needing to support kfreebsd or the hurd, a good question to
ask is:

If we had made this change before the kfreebsd port was released, would
it have somehow prevented that port?

My experience in Debian is that we adopted a great deal of linux-specific
technology over time, without much concern for whether it would cause
difficulty for unreleased ports (eg hurd). For example, d-i took
advantage of heavily linux-specific devfs[1] and was generally developed
without any particular care about portability. And yet this rather
massive weight of linux-specific choices did not prevent the kfreebsd port
from happening. It just made that port more of an impressive achivement.

So it seems unlikely to me that many changes would run afoul of the
above question, if every change made during Debian's history so far has
not managed to block the port. I'm hoping to see us go full ahead with
the linux-specific stuff. While still maintaining easy portability where
possible, in our best tradition of harnessing multiple architectures to
improve overall quality. And having the hard portability issues dealt
with by the port's dev team.

(The corollary BTW, is that we should take full advantage of freebsd-specific
features inside that port. Eg, running daemons inside jails or whatever.)

-- 
see shy jo

[1] which turned out to not have legs, but then we just switched to the
linux-specific udev instead :P


signature.asc
Description: Digital signature

Re: A few observations about systemd

On Mon, Jul 18, 2011 at 4:54 PM, Roger Leigh rle...@codelibre.net wrote:
 On Mon, Jul 18, 2011 at 04:03:41PM +0200, Matthias Klumpp wrote:
  c) the big problem for them about portability is not so much that i won't
 accept the patches. it's primarily that porting it to non-linux is
 practically impossible. about every line of it is non-portable code
     i.e. we already use epoll as a main loop, already there you'll have a
 hard time porting this to something else

 Seriously?  It's just a poll interface.  How hard could it /possibly/
 be to fall back to using plain poll(2) in the mainloop?  It's not
 like the interfaces are vastly different.  Both poll(2) and epoll_*(2)
 do pretty much exactly the same thing.  epoll might be a better
 performing interface, and scale better, but it's not like poll(2) is
 broken or particularly difficult to use.  (It's actually far simpler.)

 There is plenty of portable software out there doing exactly this.
 systemd isn't particularly special in this respect.  Take a look at
 apache, for example.

see particularly libevent-core-1.4-2

http://monkey.org/~provos/libevent/


 Regards,
 Roger

 --
  .''`.  Roger Leigh
  : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
  `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iEYEARECAAYFAk4kSRMACgkQVcFcaSW/uEhP7wCgriCMOGTncvO4w0uenX/X9HhG
 kAIAoJ9++eo2BdnH31jGH9Y+8H9JicLA
 =l+PS
 -END PGP SIGNATURE-




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAE2SPAb3SJBJih32mQC4q+Nmj_7pBvzsDaBLpvwd=tvpecv...@mail.gmail.com

Re: A few observations about systemd

Simon McVittie s...@debian.org writes:

 Is Linux suitable for all purposes for which an OS is needed? I think
 that's an open question. I'm not at all convinced that the ability to
 use kFreeBSD or Hurd makes Debian any more universal (in terms of people
 who can use it, or things you can use it for) than it already was, but
 the people working on those ports clearly think there's some benefit in
 supporting them.

Just to add a data point here, I've been able to get a fairly substantial
project to use Debian when they otherwise wouldn't have considered it
because of the existence of the kFreeBSD port, specifically due to it
providing a clean way to run ZFS as a kernel file system on Debian.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: A few observations about systemd

]] Roger Leigh 

| Seriously?  It's just a poll interface.  How hard could it /possibly/
| be to fall back to using plain poll(2) in the mainloop? 

poll(2) does not give you edge triggers, something systemd uses, so
while you can emulate this in your own code, it does make life more
complex.

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


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

Re: A few observations about systemd

2011-07-18 Thread Moritz Mühlenhoff

Jon Dowland j...@debian.org schrieb:
 On Mon, Jul 18, 2011 at 08:12:04AM +0200, Josselin Mouette wrote:
 Developing for Linux-only is fine, but Lennart has explicitly said that
 he wouldn’t remotely consider accepting portability patches, which goes
 further than any other piece of free software I had to deal with.

 Oh.  That's worse than I thought.

 We need one and only one init system in Debian. (Those considering
 maintaining several init systems in parallel do not see how stupid,
 bloated and error-prone it would be to require all daemon maintainers to
 maintain more init scripts than they do now.) I’d like to see systemd as
 that one init system, but this challenges the future of kfreebsd.

 I've just written pretty much the opposite in my last message to the thread,
 however: it's my opinion that supporting kfreebsd et al should be done with 
 the
 minimum impact on the Linux Debian distribution.   So, pre-supposing systemd, 
 I
 see three options:

 1. carry portability patches against systemd locally
 2. support multiple init systems
 3. drop kfreebsd (and HURD and others)

 I thought 2. would be more likely than 1. (and fairer on Tolleg!) since I
 expect there will be people with no interest in kfreebsd/HURD that 
 nevertheless
 would like init system choice; however I'm not one of those people, and I'm
 increasingly of the opinion that choice for choices sake harms us.

There're other blockers beside systemd to KFreeBSD being a full Debian port,
e.g. the lack of KMS in Xorg. Even the guy who gave a talk von FreeBSD at 
last year's DebConf didn't use FreeBSD on his desktop.

Cheers,
Moritz 


-- 
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/slrnj28sii.44k@inutil.org

Re: A few observations about systemd

Moritz Mühlenhoff j...@inutil.org writes:

 There're other blockers beside systemd to KFreeBSD being a full Debian
 port, e.g. the lack of KMS in Xorg. Even the guy who gave a talk von
 FreeBSD at last year's DebConf didn't use FreeBSD on his desktop.

It's one thing to not work well on desktops, though, and quite another to
not support init scripts.  We have long-standing ports that have never
worked on desktops (like s390).

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Bug#634345: ITP: telepathy-farstream -- Glue library between telepathy and farsight2

2011-07-18 Thread Emilio Pozuelo Monfort

Package: wnpp
Severity: wishlist
Owner: Emilio Pozuelo Monfort po...@debian.org

* Package name: telepathy-farstream
  Version : 0.1.1
  Upstream Author : Olivier Crête olivier.cr...@collabora.com
and others
* URL : http://telepathy.freedesktop.org/
* License : LGPL 2.1+
  Programming Lang: C
  Description : Glue library between telepathy and farsight2

 Telepathy-farstream is a helper library to glue together Telepathy's media
 signalling and the media streaming capabilities of Farsight2.
 .
 Telepathy is a D-Bus framework for unifying real time communication,
 including instant messaging, voice calls and video calls. It abstracts
 differences between protocols to provide a unified interface for applications.
 .
 Farsight2 is a framework for media streaming in audio/video conferences.



-- 
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/20110718184922.26723.36571.reportbug@marte

DEP5 Copyright Question

2011-07-18 Thread Nikolaus Rath

Hi,

I understand that a DEP5 copyright file lists licenses and copyrights
for files in the debian source package directory, rather than for files
that are installed by the generated .deb.

Does that mean that files that are *generated* during execution of
debian/rules (e.g. rendered documentation) do not need to be included in
the copyright file?

If they have to be included: isn't that slightly inconsistent? If one
wants to have the copyright for all *installed* files (rather than all
shipped files), shouldn't the files then also be listed relative to the
system root (rather than the source package directory)?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/87k4bfto5e@inspiron.ap.columbia.edu

Re: DEP5 Copyright Question

2011-07-18 Thread Neil Williams

On Mon, 18 Jul 2011 14:54:53 -0400
Nikolaus Rath nikol...@rath.org wrote:

 I understand that a DEP5 copyright file lists licenses and copyrights
 for files in the debian source package directory, rather than for files
 that are installed by the generated .deb.
 
 Does that mean that files that are *generated* during execution of
 debian/rules (e.g. rendered documentation) do not need to be included in
 the copyright file?

Auto-generated files can only have the copyright of whatever creative 
content is provided by a human writer (not the copyright of the tools
used in generation). The documentation presumably comes from some kind
of source files contained in the source package and presents that same
data in a different format. The copyright of the original data is
unaffected (assuming it complies with DFSG), the generated content is
basically the distribution of a modified form of the source itself and
hence under the same licence as the source itself.

Declaring the copyright of the source covers any reformatting of the
source which occurs during the building/packaging/distribution process.

-- 


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



pgpBaGPtVajqF.pgp
Description: PGP signature

Re: DEP5 Copyright Question

On Mon, Jul 18, 2011 at 02:54:53PM -0400, Nikolaus Rath wrote:
 I understand that a DEP5 copyright file lists licenses and copyrights
 for files in the debian source package directory, rather than for files
 that are installed by the generated .deb.

 Does that mean that files that are *generated* during execution of
 debian/rules (e.g. rendered documentation) do not need to be included in
 the copyright file?

 If they have to be included: isn't that slightly inconsistent? If one
 wants to have the copyright for all *installed* files (rather than all
 shipped files), shouldn't the files then also be listed relative to the
 system root (rather than the source package directory)?

DEP5 does not require per-file recording of copyright and license
information, it merely provides a facility for doing so where this is
interesting or relevant.

I don't personally think it's interesting or relevant to record in
debian/copyright the license of generated files, and there is certainly
nothing in Policy that requires you to do this.  Why do you ask?

-- 
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: Portability of systemd [was: A few observations about systemd]

2011-07-18 Thread Jonathan Nieder

Juliusz Chroboczek wrote:

 No, because that's not the case of systemd's core.  From what I've seen,
 most of the non-portable code in systemd's core is merely there for
 convenience.  For example, the %m printf descriptor is used extensively,
 which is just shorthand for strerror.  Similarly, openat is used in
 systemctl in order to implement a virtual cwd -- since systemctl is not
 multi-threaded, this is easily (albeit messily) simulated with either
 chdir or by manually concatenating absolute paths.

Now _that_ sort of thing is fixable.  Like so:

#define printf compat_printf
extern int compat_printf(const char *format, ...);

with compat_printf being a shim that handles %m.  See gnulib for some ---
perhaps too ambitious --- examples (printf and openat).

(By the way, I thought kfreebsd and hurd supported openat fine already.
It's even part of POSIX.  And %m is handled by glibc, not the kernel,
so not a problem for our ports.)

 Now I've certainly not read all of the systemd code, but the one
 exception that I've noticed is the use of cgroups.  While cgroups
 provide systemd with some of its coolest functionality (notably the
 ability to monitor SV initscripts, and the ability to reliably kill
 mis-behaving multi-process daemons), I'm not sure to what extent people
 think this functionality is central to systemd.

If we had forever to do it, I think the obvious thing would be to
provide the minimal cgroup functionality needed in the other kernels.
Alas, time is sometimes a hard thing to find.

Thanks and hope that's amusing.
Jonathan


-- 
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/20110718195017.ga6...@elie.gateway.2wire.net

Re: [Lennart Poettering] Re: A few observations about systemd

On Sun, Jul 17, 2011 at 06:51:17PM +0200, Lennart Poettering wrote:
 In fact, a minimal systemd system will win in almost very aspect against
 a remotely similarly powerful sysvinit system: you will need much fewer
 processes to boot. That means much shorter boot times.

This is, as far as I'm aware, an unproven assertion.  While it's true that
there is a cost to the additional processes used in init scripts, I have not
seen any serious attempt at measuring how big this impact actually is -
certainly not in terms that would be relevant to Debian, which uses dash as
its /bin/sh and insserv by default (in squeeze and above).

I'm sure that systemd does much better than a traditional sysvinit boot with
/bin/bash and no dependency-based booting.  But then, so does Debian's
current boot system, and so does upstart; and neither of the latter two
involve grandiose claims of a shell-free boot.  Trying to take the shell
completely out of the boot means a definite tradeoff here between boot speed
and configurability/maintainability, and in the absence of hard numbers, I
suspect this is a false optimization and not a trade-off that we actually
want to make in a general distribution.  Which then calls into question the
use of such claims as a justification for a switch to systemd at all...

  For a low-level piece of infrastructure, systemd interacts with a lot of
  high-level software; while this might be okay for a workstation running
  Gnome, it makes me wonder whether it will be usable on servers.
  A cursory look shows that systemd intrinsically depends on D-Bus (the
  *desktop* bus) and knows about Plymouth, RedHat's implementation of
  a splash screen.  More on that below.

 Oh, come on.

 systemd does not depend on Plymouth, it merely interacts with it if it
 is around it. Where interaction simply means writing a single message
 every now and then to ply to keep it updated how far the boot
 proceeded. It's more or a less a single line of text we send over every
 now and then in very terse code.

One of these days I'll get around to writing that blog entry to set the
record straight on why plymouth is an indispensible component of boot with
any modern boot system, because when everything is starting in parallel, you
need something to handle I/O multiplexing to the user on console.  So in a
real sense, it *should* be a dependency.  Even if you don't care about
splash, you still need multiplexing.

Upstart has the same dependency, though pid 1 doesn't talk directly to
plymouth in the upstart model; instead this is handled by an out-of-process
plymouth-upstart bridge, as well as by the out-of-process mountall service
that talks to plymouth for handling of fscks, skipping the mounting of
missing filesystems, etc.

  He practices misleading advertising[2], likes to claim that the
  universal adoption of systemd by all distributions is a done thing[3],
  and attempts to bully anyone who has the gall to think that the
  discussion is still open[4].

 Juliusz practices misleading anti-advertising [1], likes to ignore the
 fact that all major distros either made systemd the default or include
 it in their distro with the exception of Ubuntu.

Well, it's nice to see that Lennart is at least acknowledging Ubuntu as a
major distribution these days, unlike in some of his earlier rhetoric. ;)

Though this is still a pretty misleading comment, since both of these
statements are also true:

  All major distros either made sysvinit the default or include it in their
  distro.

  All major distros either made upstart the default or include it in their
  distro.

Ho-hum...

-- 
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: [Lennart Poettering] Re: A few observations about systemd

2011-07-18 Thread Mike Hommey

On Mon, Jul 18, 2011 at 01:22:37PM -0700, Steve Langasek wrote:
 On Sun, Jul 17, 2011 at 06:51:17PM +0200, Lennart Poettering wrote:
  In fact, a minimal systemd system will win in almost very aspect against
  a remotely similarly powerful sysvinit system: you will need much fewer
  processes to boot. That means much shorter boot times.
 
 This is, as far as I'm aware, an unproven assertion.  While it's true that
 there is a cost to the additional processes used in init scripts, I have not
 seen any serious attempt at measuring how big this impact actually is -
 certainly not in terms that would be relevant to Debian, which uses dash as
 its /bin/sh and insserv by default (in squeeze and above).
 
 I'm sure that systemd does much better than a traditional sysvinit boot with
 /bin/bash and no dependency-based booting.  But then, so does Debian's
 current boot system, and so does upstart; and neither of the latter two
 involve grandiose claims of a shell-free boot.  Trying to take the shell
 completely out of the boot means a definite tradeoff here between boot speed
 and configurability/maintainability, and in the absence of hard numbers, I
 suspect this is a false optimization and not a trade-off that we actually
 want to make in a general distribution.  Which then calls into question the
 use of such claims as a justification for a switch to systemd at all...

I'd expect some important differences between shell script based init
and systemd-type init by the simple fact that there are (or at least
should be, I don't know how systemd actually works) less files to read.
Less files to read == less disk seeks. Disks seeks hurt startup performance.

Mike


-- 
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/20110718211439.ga14...@glandium.org

Re: A few observations about systemd

Hi Jon,

On Mon, Jul 18, 2011 at 10:30:15AM +0100, Jon Dowland wrote:
 Likewise,  a recent kernel does not seem like a problem, and cgroups seems
 like a fairly core part of what systemd does.

There are use cases where requiring the latest kernel would be a problem. 
For example, some virtual hosting environments, such as those using Xen
virtualization, don't give you control over the kernel you're running.  I
seem to remember 2.6.18 being a common kernel vintage in use with Xen, which
is definitely too old to work with systemd; but even if Xen moves forward to
a newer preferred kernel version, systemd could adopt and start to depend on
some other kernel feature down the line and cause the same problem.

The udev+kernel version coupling already gives us maintenance headaches for
distribution backwards-compatibility and upgradeability.  I suppose most
people running Xen can avoid this because it's virtualized and they can get
away without using udev; but when PID 1 won't start, it's a different
proposition entirely.

I guess the same applies for containers like LXC and such - you don't get
your own kernel, you just get your own kernel namespace, and you have to run
PID 1...

So yes, I expect strict kernel requirements from an init system to be a
problem.

-- 
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: [Lennart Poettering] Re: A few observations about systemd

2011-07-18 Thread Uoti Urpala

Steve Langasek vorlon at debian.org writes:
 I'm sure that systemd does much better than a traditional sysvinit boot with
 /bin/bash and no dependency-based booting.  But then, so does Debian's
 current boot system, and so does upstart; and neither of the latter two
 involve grandiose claims of a shell-free boot.  Trying to take the shell
 completely out of the boot means a definite tradeoff here between boot speed
 and configurability/maintainability, and in the absence of hard numbers, I

Tradeoff? What tradeoff? Sysv-style init scripts are messy, definitely not
maintainable, and theoretically configurable in the turing-complete sense but
hard to modify in practice. systemd service configuration wins in boot speed,
wins big in maintainability, and is at least equal in configurability (you can
configure most things easier than with shell scripts, but can still fall back to
them if necessary).


  Juliusz practices misleading anti-advertising [1], likes to ignore the
  fact that all major distros either made systemd the default or include
  it in their distro with the exception of Ubuntu.
 
 Well, it's nice to see that Lennart is at least acknowledging Ubuntu as a
 major distribution these days, unlike in some of his earlier rhetoric. ;)
 
 Though this is still a pretty misleading comment, since both of these
 statements are also true:
 
   All major distros either made sysvinit the default or include it in their
   distro.
 
   All major distros either made upstart the default or include it in their
   distro.

It's not that misleading after all when you consider how quickly systemd has
reached that position. It was only published last year. To have reached its
current position already shows a lot of momentum.

Sysvinit is the old default, but nobody seriously claims it's gaining ground.
Upstart is still used in Ubuntu but doesn't seem to have much future elsewhere.
There's quite a lot of interest in systemd for Debian too, whereas I've seen few
people express interest in Upstart. The interest is especially low when you
consider Debian's ties with Ubuntu and people who only care about Upstart
because of that.


-- 
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.20110719t001733-...@post.gmane.org

Re: [Lennart Poettering] Re: A few observations about systemd

Uoti Urpala uoti.urp...@pp1.inet.fi writes:

 Upstart is still used in Ubuntu but doesn't seem to have much future
 elsewhere.  There's quite a lot of interest in systemd for Debian too,
 whereas I've seen few people express interest in Upstart.

Funny, my personal experience has been the exact opposite, including the
conversations that I had in-person at the last Debconf.

 The interest is especially low when you consider Debian's ties with
 Ubuntu and people who only care about Upstart because of that.

This is completely false.  I have no affiliation whatsoever with Ubuntu
and personally have no interest in using it.  Nonetheless, I think upstart
looks quite interesting

systemd also looks interesting, and I'm generally happy with either of
them as possibilities, I'm rather concerned by systemd's lack of interest
in portability.  The upstart maintainers have expressed considerably more
willingness to date to work with Debian on meeting our project's goals and
incorporating those changes into the upstream release.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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

Re: A few observations about systemd

2011-07-18 Thread Neil McGovern

On Mon, Jul 18, 2011 at 10:54:16AM -0700, Russ Allbery wrote:
 Moritz Mühlenhoff j...@inutil.org writes:
 
  There're other blockers beside systemd to KFreeBSD being a full Debian
  port, e.g. the lack of KMS in Xorg. Even the guy who gave a talk von
  FreeBSD at last year's DebConf didn't use FreeBSD on his desktop.
 
 It's one thing to not work well on desktops, though, and quite another to
 not support init scripts.  We have long-standing ports that have never
 worked on desktops (like s390).
 

Just for information, and not to do with the current situation, but it
should be noted that adding a new port doesn't necessarily have the
same criteria as keeping an existing one.

Neil
-- 
I will never drink gin again - Harmoney


-- 
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/20110718195912.gf...@feta.halon.org.uk

Re: [Lennart Poettering] Re: A few observations about systemd

2011-07-18 Thread Cyril Brulebois

Russ Allbery r...@debian.org (18/07/2011):
 The upstart maintainers have expressed considerably more willingness
 to date to work with Debian on meeting our project's goals and
 incorporating those changes into the upstream release.

For reference, that would likely be:
  http://lists.debian.org/debian-bsd/2009/07/msg00122.html

(Feel free to correct me if you had other references in mind.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

On Mon, Jul 18, 2011 at 10:18:14PM +, Uoti Urpala wrote:
 Steve Langasek vorlon at debian.org writes:
  I'm sure that systemd does much better than a traditional sysvinit boot with
  /bin/bash and no dependency-based booting.  But then, so does Debian's
  current boot system, and so does upstart; and neither of the latter two
  involve grandiose claims of a shell-free boot.  Trying to take the shell
  completely out of the boot means a definite tradeoff here between boot speed
  and configurability/maintainability, and in the absence of hard numbers, I

 Tradeoff? What tradeoff?

The tradeoff of hard-coding policy into C code in exchange for faster boot.

 Sysv-style init scripts are messy, definitely not maintainable, and
 theoretically configurable in the turing-complete sense but hard to
 modify in practice.

Yes, all of this is true.  You seem to have mistaken my criticism of the
systemd model for a defense of sysvinit, which it was not.  A system where
*everything* is a shell script is not very maintainable; but neither is a
system whose design is predicated on the idea that everything is built-in.

The middle ground between the two seems to be upstart.

 systemd service configuration wins in boot speed,

You did actually read my message, right, where I observed that there are no
published numbers to support this claim in a relevant head-to-head
comparison?  And your only response is to repeat the unsubstantiated claim?

  Though this is still a pretty misleading comment, since both of these
  statements are also true:

All major distros either made sysvinit the default or include it in their
distro.

All major distros either made upstart the default or include it in their
distro.

 It's not that misleading after all when you consider how quickly systemd has
 reached that position.

Um, of course it is.  Claiming that it's included in the distro as if
that's some sort of major milestone is *incredibly* misleading.  Lots of
things are included in lots of distros that are never going to be used by
default.  Debian has certainly not made a decision to use systemd yet, but
that doesn't stop Lennart from using the package's presence in the Debian
archive in his propaganda.

-- 
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: [Lennart Poettering] Re: A few observations about systemd

Cyril Brulebois k...@debian.org writes:
 Russ Allbery r...@debian.org (18/07/2011):

 The upstart maintainers have expressed considerably more willingness to
 date to work with Debian on meeting our project's goals and
 incorporating those changes into the upstream release.

 For reference, that would likely be:
   http://lists.debian.org/debian-bsd/2009/07/msg00122.html

 (Feel free to correct me if you had other references in mind.)

I think this is somewhat obsoleted by in-person discussions at Debconf in
2010.  But this is now-fallible year-old memory, so having the discussion
with him explicitly to get the current state of his thinking would be a
good idea.

We talked about BSD explicitly during the various init system discussions
at Debconf, and the impression I came away with was that he didn't have
the time to write the code himself, but was definitely willing to work
with someone who was interested and make sure that it would continue to
work.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/871uxnqk5z@windlord.stanford.edu

Re: [Lennart Poettering] Re: A few observations about systemd

 I have not seen any serious attempt at measuring how big this impact
 actually is

 I'd expect some important differences between shell script based init
 and systemd-type init

Yeah, that's everybody's intuition too.  But Steve is right -- it would
be good to see some real benchmarks.

-- Juliusz


-- 
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/87sjq3fc2k@trurl.pps.jussieu.fr

Re: Portability of systemd [was: A few observations about systemd]

2011-07-18 Thread brian m. carlson

On Mon, Jul 18, 2011 at 02:50:17PM -0500, Jonathan Nieder wrote:
 (By the way, I thought kfreebsd and hurd supported openat fine already.
 It's even part of POSIX.  And %m is handled by glibc, not the kernel,
 so not a problem for our ports.)

I know the FreeBSD kernel has supported openat(2) since 8.0, but I don't
know if the kFreeBSD glibc has it implemented.  If not, it's very likely
trivial to accomplish.

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


signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

On Mon, Jul 18, 2011 at 11:14:39PM +0200, Mike Hommey wrote:
  I'm sure that systemd does much better than a traditional sysvinit boot with
  /bin/bash and no dependency-based booting.  But then, so does Debian's
  current boot system, and so does upstart; and neither of the latter two
  involve grandiose claims of a shell-free boot.  Trying to take the shell
  completely out of the boot means a definite tradeoff here between boot speed
  and configurability/maintainability, and in the absence of hard numbers, I
  suspect this is a false optimization and not a trade-off that we actually
  want to make in a general distribution.  Which then calls into question the
  use of such claims as a justification for a switch to systemd at all...

 I'd expect some important differences between shell script based init
 and systemd-type init by the simple fact that there are (or at least
 should be, I don't know how systemd actually works) less files to read.
 Less files to read == less disk seeks. Disks seeks hurt startup performance.

Yes, I've read your blog entries on the subject. :-)  That's true, but I
think the reduction in the number of files being accessed, for systemd vs.
sysvinit or upstart, is rather small; aside from some things in /etc/rcS.d,
most init scripts would have approximately a 1:1 correlation with upstart
jobs or systemd config files, and if you've read the shell off disk once
it's in cache and there's not likely to be any more seeking.  So I do expect
that most of the shell penalty will be CPU rather than disk in the context
of boot.

-- 
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: [Lennart Poettering] Re: A few observations about systemd

2011-07-18 Thread Uoti Urpala

Russ Allbery rra at debian.org writes:
 Uoti Urpala uoti.urpala at pp1.inet.fi writes:
 
  Upstart is still used in Ubuntu but doesn't seem to have much future
  elsewhere.  There's quite a lot of interest in systemd for Debian too,
  whereas I've seen few people express interest in Upstart.
 
 Funny, my personal experience has been the exact opposite, including the
 conversations that I had in-person at the last Debconf.

Last? As in 2010? Given how quickly systemd has gained momentum, the 2010 status
is hardly representative of current interest in systemd or its relative
popularity compared to Upstart.


  The interest is especially low when you consider Debian's ties with
  Ubuntu and people who only care about Upstart because of that.
 
 This is completely false.  I have no affiliation whatsoever with Ubuntu
 and personally have no interest in using it.  Nonetheless, I think upstart
 looks quite interesting

I didn't claim that there would not be a single person interested in Upstart.
You could be more familiar with the attitudes of Debian developers than I am,
but if 2010 experience and your personal opinion are the only things you're
basing that on then it's not enough to show that low interest in Upstart would
be completely false (even restricted to developers only). 

 systemd also looks interesting, and I'm generally happy with either of
 them as possibilities, I'm rather concerned by systemd's lack of interest
 in portability.  The upstart maintainers have expressed considerably more
 willingness to date to work with Debian on meeting our project's goals and
 incorporating those changes into the upstream release.

I think the important question is whether portability to other kernels is or
should be a project's goal, and how much else you're willing to lose for the
sake of that goal. I know I would personally be a lot happier with a Debian that
supports systemd functionality than with a Debian that can run on a BSD kernel.


-- 
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.20110719t004726-...@post.gmane.org

Re: [Lennart Poettering] Re: A few observations about systemd

Uoti Urpala uoti.urp...@pp1.inet.fi writes:

 I think the important question is whether portability to other kernels
 is or should be a project's goal, and how much else you're willing to
 lose for the sake of that goal.

I believe that it should be, and I'm willing to lose systemd for that
goal, although hopefully it wouldn't come to that.

 I know I would personally be a lot happier with a Debian that supports
 systemd functionality than with a Debian that can run on a BSD kernel.

Well, while we're putting stakes in the ground, I suppose I'll hammer mine
in there as well.  I completely disagree to the point that I would take
that to a GR.

Thankfully, I suspect this will be a false dichotomy.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/874o2jp3fm@windlord.stanford.edu

Re: [Lennart Poettering] Re: A few observations about systemd

2011-07-18 Thread brian m. carlson

On Mon, Jul 18, 2011 at 11:05:56PM +, Uoti Urpala wrote:
 I think the important question is whether portability to other kernels
 is or should be a project's goal, and how much else you're willing
 to lose for the sake of that goal. I know I would personally be a lot
 happier with a Debian that supports systemd functionality than with a
 Debian that can run on a BSD kernel.

I ran GNU/kFreeBSD on a server of mine for over a year because it had
pf.  pf makes OS fingerprinting automatic and a lot easier (at the time,
Debian's Linux kernel did not have the osf module) and traffic shaping
is much, much easier as well[0].  The Linux kernel has only recently had
ipset functionality merged upstream, which pf has had for years.  The
FreeBSD kernel also had a much, much more responsive scheduler as well
(it may still, I don't know).  It also supports ZFS, which is very
important to some people.  The reason I left is because pf stopped
working.  I agree that GNU/kFreeBSD is not a great desktop platform, but
it is an excellent server platform.

Also, I've installed systemd on my laptop and it logs almost nothing to
the console (verbose on the kernel command line does not help).
Logging to syslog is not helpful when the system won't come up to the
point of starting syslog.  What it *does* log (to syslog), however, is a
message that /usr as a separate partition is obsolete, even though this
has no effect on systemd at all, other than offending the upstream
author.  Last I checked, The Unix Way did not involve having important
system programs prattle on about irrelevant details.

I'll side with supporting GNU/kFreeBSD over systemd any day.

[0] Extremely limited bandwidth for incoming Windows SMTP servers,
anyone?

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


signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

2011-07-18 Thread Uoti Urpala

Steve Langasek vorlon at debian.org writes:
  Tradeoff? What tradeoff?
 
 The tradeoff of hard-coding policy into C code in exchange for faster boot.

What's actually hard-coded so hard that it would have negative effects? What do
you actually *lose* here? The systemd model prefers to avoid shell scripts when
possible. I think that's a very good principle. But it's not like you couldn't
run shell code if you can't achieve the effect you want any other way (after all
even compatibility for sysv scripts is still provided!).

By the way, I think in exchange for faster boot is focusing too narrowly on
boot speed. It's not like boot speed would be the only reason to avoid shell.


  Sysv-style init scripts are messy, definitely not maintainable, and
  theoretically configurable in the turing-complete sense but hard to
  modify in practice.
 
 Yes, all of this is true.  You seem to have mistaken my criticism of the
 systemd model for a defense of sysvinit, which it was not.  A system where
 *everything* is a shell script is not very maintainable; but neither is a
 system whose design is predicated on the idea that everything is built-in.
 
 The middle ground between the two seems to be upstart.

Again, what's the actual maintainability problem in the systemd model? I think
you haven't identified any, and I can't really guess what you mean either.


  systemd service configuration wins in boot speed,
 
 You did actually read my message, right, where I observed that there are no
 published numbers to support this claim in a relevant head-to-head
 comparison?  And your only response is to repeat the unsubstantiated claim?

I don't know how much it wins, and I don't really care that much about boot
speed myself. Also, overall speed win could come from socket activation too, not
just avoidance of shell scripts. My main point was that your claim of tradeoff
was unsubstantiated as you didn't actually identify any negative effects to
counter the speed gains (and in fact I think quite the opposite is true). That
holds whether the speed gains are large or small.


  It's not that misleading after all when you consider how quickly systemd has
  reached that position.
 
 Um, of course it is.  Claiming that it's included in the distro as if
 that's some sort of major milestone is *incredibly* misleading.  Lots of
 things are included in lots of distros that are never going to be used by
 default.  Debian has certainly not made a decision to use systemd yet, but
 that doesn't stop Lennart from using the package's presence in the Debian
 archive in his propaganda.

Yes literally just is included doesn't mean much, but it has more support in
Debian than just a lone maintainer uploading it. Anyway I don't want to argue
about the exact semantics of his statement. systemd does have a lot momentum
even if its adoption is not a done deal in every distribution yet, and it's
hard to imagine Upstart turning the tide now or a new candidate appearing and
taking over.


-- 
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.20110719t011655-...@post.gmane.org

Re: DEP5 Copyright Question

2011-07-18 Thread Nikolaus Rath

Steve Langasek vor...@debian.org writes:
 On Mon, Jul 18, 2011 at 02:54:53PM -0400, Nikolaus Rath wrote:
 I understand that a DEP5 copyright file lists licenses and copyrights
 for files in the debian source package directory, rather than for files
 that are installed by the generated .deb.

 Does that mean that files that are *generated* during execution of
 debian/rules (e.g. rendered documentation) do not need to be included in
 the copyright file?

 If they have to be included: isn't that slightly inconsistent? If one
 wants to have the copyright for all *installed* files (rather than all
 shipped files), shouldn't the files then also be listed relative to the
 system root (rather than the source package directory)?

 DEP5 does not require per-file recording of copyright and license
 information, it merely provides a facility for doing so where this is
 interesting or relevant.

 I don't personally think it's interesting or relevant to record in
 debian/copyright the license of generated files, and there is certainly
 nothing in Policy that requires you to do this.  Why do you ask?


My sponsor requested me to add debian/copyright entries for files in the
generated HTML documentation. The documentation is generated by Sphinx,
and Sphinx adds some templates and js libraries which are then covered
(at least that's what I believe) by the Sphinx license rather then the
license of the documentation source files.

On one hand it makes sense to me that /usr/share/[package]/copyright
should contains information about all files in [package]. But on the
other hand it doesn't make sense to me to add something like
debian/tmp/... into my copyright file...


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/8762mzi36y@vostro.rath.org

Re: DEP5 Copyright Question

2011-07-18 Thread Nikolaus Rath

Neil Williams codeh...@debian.org writes:
 On Mon, 18 Jul 2011 14:54:53 -0400
 Nikolaus Rath nikol...@rath.org wrote:

 I understand that a DEP5 copyright file lists licenses and copyrights
 for files in the debian source package directory, rather than for files
 that are installed by the generated .deb.
 
 Does that mean that files that are *generated* during execution of
 debian/rules (e.g. rendered documentation) do not need to be included in
 the copyright file?

 Auto-generated files can only have the copyright of whatever creative 
 content is provided by a human writer (not the copyright of the tools
 used in generation). The documentation presumably comes from some kind
 of source files contained in the source package and presents that same
 data in a different format.

Yes, but it also contains images, style sheets and java script libraries
from the rendering tool (Sphinx).

 The copyright of the original data is unaffected (assuming it complies
 with DFSG), the generated content is basically the distribution of a
 modified form of the source itself and hence under the same licence as
 the source itself.

 Declaring the copyright of the source covers any reformatting of the
 source which occurs during the building/packaging/distribution
 process.

Even in this case?


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/8739i3i1qx@vostro.rath.org

Re: massive bug report to replace !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 kludges with dpkg wildcards

2011-07-18 Thread Erik de Castro Lopo

Robert Millan wrote:

 Title and template description (below) is self-explanatory.  156
 packages are affected (list is attached).
 
 Package: %package%
 Severity: wishlist
 User: debian-...@lists.debian.org
 Usertags: kfreebsd
 
 The debian/control file in %package% uses a negated list of architectures
 to specify a package relationship (most likely Build-Depends) on a
 Linux-specific package.  I.e. something like:
 
   Build-Depends: libfoo-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386]

Is anyone working on making this a lintian warning?

The package I uploaded last night would have been fixed if this
was caught by lintian :-).

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.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/20110719130609.d701c1b5.er...@mega-nerd.com

Re: [Lennart Poettering] Re: A few observations about systemd