Re: debian-multimedia.org considered harmful

[Arto Jantunen]

Thomas Goirand  writes:

> On 03/17/2012 06:11 AM, Romain Beauxis wrote:
>> 2012/3/11 Mike Hommey 
>>   
>>> The problem is: decss is illegal in very much more than just the US.
>>> This is a very different situation.
>>> 
>> Orly? Do you know of any law and/or court case backing this assertion?
>>
>> Romain
>>   
> There is a DMCA in both US and UK (at least)...

The EU has a directive that requires member countries to implement at
least some parts of the DMCA. For example Finland opted to implement the
full thing, and people have actually gotten convictions for using decss
(so far only people who turned themselves in as a protest, however).

The US has a lot of power and desire to push their agenda through in
other countries, which tends to mean that a legal problems in the US
will easily spread to a lot of places. The ACTA and TPPA things are
"nice" examples (they include the DMCA and worse).

-- 
Arto Jantunen


-- 
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/87bonvmyy0@iki.fi

Re: On init in Debian

[Philip Hands]

On Fri, 16 Mar 2012 23:32:25 -0700, Allison Randal  wrote:
...
> In this case, the options I see being weighed are whether to support
> sysvinit, upstart, or systemd, or some combination.
...
> So, the contributor agreement is a factor, but not the only factor (or
> even the primary factor).

There is a big difference between supporting the use of something as an
alternative, and choosing it as a default -- I'd expect that we're able
to support the use of all of these to a greater or lesser extent, but
the contributor agreement ensures that many people will vehemently
resist its adoption as the Debian default, which is almost certainly
enough to ensure it won't happen no matter if upstart were 1000 times
better than every alternative in every dimension (and if that were the
case I'd imagine we'd fork it to route around the problem, as with ice*)

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpib32DV5Mxv.pgp
Description: PGP signature

Re: On init in Debian

[Thomas Goirand]

On 03/17/2012 08:10 AM, Fernando Lemos wrote:
> Right now, creating a init script means copying an ugly 159-line
> skeleton and carefully editing it, hoping not to break anything while
> at it. Even if we can't have a single generator for multiple init
> systems, having something declarative to build most init scripts we
> need would be a big step forward and it would make a lot of sense as
> well in a future where we may need to support multiple init systems.
>   

Yes!

Having a shell script library for that would make it more declarative,
and less imperative, so we wouldn't have to write all of the script.

For me, that'd be quite easy enough. I'm proposing myself to write
such library if nobody wants to do it, but of course, I would need some
others to review my work. The ultimate goal would be that packages
would simply need to do something like:

NAME=package-binary-file
DESC="package daemon description"

[ -e . /usr/share/sysv-lib/debsysv-lib ] && debsysv-init-lib $@

That's (in best cases) only 3 lines, (plus the lsb-base header)...
Of course, in many cases, we need a bit more, this could be
implemented with things like START_OPTS / STOP_OPTS and
so on, and maybe some hooks for start/stop functions.

Please comment on the above and give you ideas. Let's start
a discussion on how to simplify what we have already, this
can't hurt, whatever path we choose!

Thomas


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

Re: On init in Debian

[Thomas Goirand]

On 03/17/2012 02:45 AM, Russ Allbery wrote:
> Lars Wirzenius  writes:
>
>   
>> I don't know what should happen next, except someone should take
>> leadership on this issue and find a rough consensus on what we as a
>> project want to do.  The usual way of that to happen is for someone to
>> grab a keyboard and start writing actual code, as opposed to
>> e-mails. Do-ocracy ftw.
>> 
> I believe we should finalize the Policy update to allow packages to start
> including optional upstart scripts (#591791, which needs more seconds),
> write a similar Policy update for systemd, and then get some practical
> experience.
>
> That doesn't resolve the whole problem, but it does let people start doing
> things instead of just talking about it and may uncover interesting data.
> And allowing packages to include parallel upstart configuration with init
> scripts that defer to upstart when it's available has the separate
> advantage of immediately making life easier for packagers who want to
> maintain the same package on both Debian and Ubuntu.
>   
There's not only the policy to change, unfortunately. I wrote it already.

Currently, if you make a debian/$package.upstart using dh 8 sequencer,
then $package will depend on upstart. Then if you install $package, it
will pull upstart, and remove sysvinit, which makes your system unusable
(since most package don't have upstart support).

So again, currently, adding upstart support in a package when using
dh 8 sequencer and ${misc:Depends} is *not* possible today.

Thomas


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

Re: On init in Debian

[Ben Finney]

Allison Randal  writes:

> On 03/16/2012 06:50 PM, Ben Finney wrote:
> Allison Randal  writes:
> > > Hypothetically, if this went away,
> > > would it have a substantial impact on the decision?
> > Which decision in particular, and by who?
>
> Anthropologically speaking, folkmoot is […] but I'd say the "decision"
> is more a matter of who volunteers to do what.
>
> Does that sound about right?

I don't know what you're asking, which is why I asked you for
clarification of what you mean.

You asked “if this [requirement for the Canonical contributor agreement
before accepting contributions in ‘upstart’] went away, would it have a
substantial impact on the decision?” and I don't know what “the
decision” you're referring to is.

There are several being discussed, to be decided by different parties,
as summarized by Lars Wirzenius. Which one are you asking about?

> > If the Canonical contributor agreement were no longer required for
> > contributions to a work, then depending on that work for core Debian
> > features would be significantly less controversial, IMO. Does that
> > answer your question?
>
> Yes, thanks. So, the contributor agreement is a factor, but not the only
> factor (or even the primary factor).

That's not a good conclusion from what I'm saying. I don't know enough
about the issues that might be relevant for ‘upstart’ in Debian to be
exhaustive; there may be many more, there many be a few more, or there
may be only one.

I'm only pointing out that the contributor agreement requirement imposed
by Canonical is, as you asked, IMO a significant part of the
controversy.

-- 
 \   “It's easy to play any musical instrument: all you have to do |
  `\   is touch the right key at the right time and the instrument |
_o__)will play itself.” —Johann Sebastian Bach |
Ben Finney


-- 
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/87bonvo1uh@benfinney.id.au

Re: On init in Debian

[Philip Hands]

On Sat, 17 Mar 2012 18:23:57 +0800, Thomas Goirand  wrote:
> On 03/17/2012 08:10 AM, Fernando Lemos wrote:
> > Right now, creating a init script means copying an ugly 159-line
> > skeleton and carefully editing it, hoping not to break anything while
> > at it. Even if we can't have a single generator for multiple init
> > systems, having something declarative to build most init scripts we
> > need would be a big step forward and it would make a lot of sense as
> > well in a future where we may need to support multiple init systems.
> >   
> 
> Yes!
> 
> Having a shell script library for that would make it more declarative,
> and less imperative, so we wouldn't have to write all of the script.
> 
> For me, that'd be quite easy enough. I'm proposing myself to write
> such library if nobody wants to do it, but of course, I would need some
> others to review my work. The ultimate goal would be that packages
> would simply need to do something like:
> 
> NAME=package-binary-file
> DESC="package daemon description"
> 
> [ -e . /usr/share/sysv-lib/debsysv-lib ] && debsysv-init-lib $@

I'm happy to help with that ... although, I doubt we're the first people
to think of something like this, and it would be a shame to ignore an
existing solution.

RedHat have some functions for use in init scripts, in
/etc/rc.d/functions (although I've not used RedHat for a decade or more,
so I've no idea what's included there).

OpenWRT does something quite interesting, which is that they have an
/etc/rc.common and then make the init scripts start thus:

#!/bin/sh /etc/rc.common
# Copyright (C) 2006-2010 OpenWrt.org
# Copyright (C) 2006 Carlos Sobrinho

NAME=dropbear
PROG=/usr/sbin/dropbear
START=50
STOP=50
PIDCOUNT=0
...

so the thing that actually gets run is the /etc/rc.common, which sources
the init.d script at its end, so it is possible to override any part of
the common script by including functions in the service specific script,
but otherwise it just does the default.

Any others?

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpsml5IihDqR.pgp
Description: PGP signature

Bug#664257: multiarch tuples are not documented/defined

[Jonathan Nieder]

Matthias Klose wrote:

> While we strive to get multiarch ready for squeeze, there is
> currently nothing to point to what the multiarch tuples actually
> mean, neither on the Debian side nor on some kind of standards side
> like the FHS or LSB.  This has to be documented on the Debian side,
> and better be incorporated into standards like the FHS or LSB.
>
> The current state is http://wiki.debian.org/Multiarch/Tuples,
> deriving from http://wiki.debian.org/Multiarch/TuplesAbandoned. An
> email to debian-ports didn't get any feedback. From my point of view
> such a wiki page should be self-contained and be usable as a
> reference for upstream projects.

Thanks.  To start (warning: the following is just a bunch of guesses,
many of which are almost certainly wrong):

 i386-linux-gnu: Intel ia32 ABI, ELF, Linux syscalls, glibc 2.x.
psABI is documented in the System V ABI Intel386 architecture
processor supplement: http://www.sco.com/developers/devspecs/

 x86_64-linux-gnu: Likewise, but using the AMD64 psABI as documented
in abi.pdf: http://x86-64.org/documentation/

 sparc-linux-gnu: Likewise, but with the SPARC psABI as documented
in psABI3rd.pdf: http://www.sparc.com/standards/
Debian uses the v8plus ABI, but I think that is
backward-compatible with the old svr4 ABI and doesn't have to be
part of the definition.

 sparc64-linux-gnu: Likewise, but with the SPARC v9 64-bit psABI.
Not sure where the reference documentation is for that.

 alpha-linux-gnu: Likewise, but with the Tru64 UNIX Calling Standard
for Alpha Systems:
http://www.openwatcom.org/ftp/devel/docs/alpha%20calling%20standard.pdf

 m68k-linux-gnu: Likewise, but with the Motorola 68000 Family
Processor Supplement to the System V ABI which doesn't seem to
be available oneline. (?)

 arm-linux-gnueabi: ARM's "new" GNU EABI for Linux, soft float, 32 bit.
Documented at http://wiki.debian.org/ArmEabiPort which refers to

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042a/IHI0042A_aapcs.pdf
http://www.codesourcery.com/gnu_toolchains/arm/arm_gnu_linux_abi.pdf

 arm-linux-gnueabihf: likewise but with hard float



-- 
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/20120317130615.GA3097@burratino

Re: On init in Debian

[Jon Dowland]

On Sat, Mar 17, 2012 at 06:23:57PM +0800, Thomas Goirand wrote:
> Having a shell script library for that would make it more declarative,
> and less imperative, so we wouldn't have to write all of the script.
> 
> For me, that'd be quite easy enough. I'm proposing myself to write
> such library if nobody wants to do it

Isn't this what metainit does?


-- 
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/20120317141331.GA9426@debian

Re: On init in Debian

[Josselin Mouette]

Le samedi 17 mars 2012 à 09:16 +, Philip Hands a écrit : 
> There is a big difference between supporting the use of something as an
> alternative, and choosing it as a default -- I'd expect that we're able
> to support the use of all of these to a greater or lesser extent, but
> the contributor agreement ensures that many people will vehemently
> resist its adoption as the Debian default, which is almost certainly
> enough to ensure it won't happen no matter if upstart were 1000 times
> better than every alternative in every dimension (and if that were the
> case I'd imagine we'd fork it to route around the problem, as with ice*)

If this were the case, we would have never replaced lprng by CUPS.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: On init in Debian

[Josselin Mouette]

Le vendredi 16 mars 2012 à 18:39 +0100, Marco d'Itri a écrit : 
> On Mar 16, Vincent Danjean  wrote:
> 
> > * We could try to define a file format that allow a conversion (by a
> >   separate specific tool or at runtime) to various init systems.
> >   This would avoid to be blocked by the syntax/features of one "source"
> >   init system.
> I doubt that this is possible except for the most trivial cases (which 
> are not interesting), because the three init systems do not have the 
> same features and they have different semantics.

It is for trivial cases (>90% of init scripts) that this is the most
interesting. Non-trivial cases could still be handled by shipping a
manually written init script together.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: On init in Debian

[Marco d'Itri]

On Mar 17, Josselin Mouette  wrote:

> > I doubt that this is possible except for the most trivial cases (which 
> > are not interesting), because the three init systems do not have the 
> > same features and they have different semantics.
> It is for trivial cases (>90% of init scripts) that this is the most
> interesting. Non-trivial cases could still be handled by shipping a
> manually written init script together.
But for the trivial cases we can just keep using sysv init scripts until 
a winner emerges.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On init in Debian

[Marco d'Itri]

On Mar 16, Alexander Wirt  wrote:

> > What attack? Toys are not evil, I like toys.
> > But an OS developed by 10 people for maybe 100 people is still a toy.
> Yeah, like Linux too not so long ago. With people like you we would still
> have to use Windows.
Predicting the future has always been a tricky business, but the 
adoption rates (as users and as developers) of both OSes are different 
enough that some extrapolation is reasonable: for the foreseable future 
~nobody will ever care about Hurd and kFreeBSD.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On init in Debian

[Thomas Goirand]

On 03/17/2012 10:13 PM, Jon Dowland wrote:
> On Sat, Mar 17, 2012 at 06:23:57PM +0800, Thomas Goirand wrote:
>   
>> Having a shell script library for that would make it more declarative,
>> and less imperative, so we wouldn't have to write all of the script.
>>
>> For me, that'd be quite easy enough. I'm proposing myself to write
>> such library if nobody wants to do it
>> 
> Isn't this what metainit does?
>   
I just had a look, and no, that's not what metainit does.
What it does is *generating* an init.d script, using the
metainit syntax as input. IMO, just a normal shell script
tiny library to simplify our init.d scripts would be enough.

Thomas


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

Re: On init in Debian

[Russ Allbery]

Thomas Goirand  writes:

> Currently, if you make a debian/$package.upstart using dh 8 sequencer,
> then $package will depend on upstart. Then if you install $package, it
> will pull upstart, and remove sysvinit, which makes your system unusable
> (since most package don't have upstart support).

Changing this is only waiting for Policy to be finalized.  See #577040.

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


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

Re: On init in Debian

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Mar 17, Josselin Mouette  wrote:

>> It is for trivial cases (>90% of init scripts) that this is the most
>> interesting. Non-trivial cases could still be handled by shipping a
>> manually written init script together.

> But for the trivial cases we can just keep using sysv init scripts until
> a winner emerges.

I would dearly like to stop using sysv init scripts for the trivial cases
as soon as I can, since they just introduce a bunch of possible bugs
without much real benefit.

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


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

Re: On init in Debian

[Thomas Goirand]

On 03/17/2012 08:40 PM, Philip Hands wrote:
> I'm happy to help with that ...

Cool! Let's do it together then.

> although, I doubt we're the first people
> to think of something like this, and it would be a shame to ignore an
> existing solution.
>
> RedHat have some functions for use in init scripts, in
> /etc/rc.d/functions (although I've not used RedHat for a decade or more,
> so I've no idea what's included there).
>   

I had a look in a CentOS VM, and I didn't see such file. Is it only in RHEL?

> OpenWRT does something quite interesting, which is that they have an
> /etc/rc.common and then make the init scripts start thus:
>
> #!/bin/sh /etc/rc.common
> # Copyright (C) 2006-2010 OpenWrt.org
> # Copyright (C) 2006 Carlos Sobrinho
>
> NAME=dropbear
> PROG=/usr/sbin/dropbear
> START=50
> STOP=50
> PIDCOUNT=0
> ...
>
> so the thing that actually gets run is the /etc/rc.common, which sources
> the init.d script at its end, so it is possible to override any part of
> the common script by including functions in the service specific script,
> but otherwise it just does the default.
>   

The idea is nice, I think that being able to overwrite the functions
you want is cool, even though there are many other ways to do it.
But it seems to be a bit hard to integrate with dh_installinit, Probably,
what we would like is a symlink to this rc.common, with the
package specific script being located in /etc/$whatver being sourced
by rc.common, right? Do you see how we could do and keep a
dh_installinit compatibility?

Thomas


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

Re: On init in Debian

[Thomas Goirand]

On 03/16/2012 06:14 PM, Lars Wirzenius wrote:
> * We could require every package that provides a service that needs to be
>   started by init to support both sysvinit and upstart or systemd. However,
>   given the realities of Debian development, this would probably mean
>   that one of them would be badly tested, and therefore likely to be buggy.
> * We could try to have a tool to automatically convert an upstart or systemd
>   service configuration into a sysvinit init.d script. I have no idea if that
>   is really feasible, but if it worked for most packages, we could probably
>   live with the others requiring some manual work.
>   

I know almost nothing about systemd

I'd like people to think twice before opt-in for systemd. I just
taked with a friend working for redhat, and he told me how much
he hates it. He told me that if *anything* goes wrong in the boot
process, then basically, you're stuck, because the next thing will
be waiting forever. That's basically truth with any event based
init, and maybe we're just fine with just dependency booting.

In French we say: "Le mieux est l'ennemi du bien"... :)

If anyone who knows systemd can comment on the above, that'd be great.

Thomas


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

Re: On init in Debian

[Timo Juhani Lindfors]

Thomas Goirand  writes:
> taked with a friend working for redhat, and he told me how much
> he hates it. He told me that if *anything* goes wrong in the boot
> process, then basically, you're stuck, because the next thing will

http://fedoraproject.org/wiki/How_to_debug_Systemd_problems

seems to cover this quite extensively.


-- 
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/848vizku3d@sauna.l.org

Re: On init in Debian

[Russ Allbery]

Thomas Goirand  writes:

> I'd like people to think twice before opt-in for systemd. I just taked
> with a friend working for redhat, and he told me how much he hates
> it. He told me that if *anything* goes wrong in the boot process, then
> basically, you're stuck, because the next thing will be waiting
> forever.

How does this differ from sysvinit or, really, any init system going back
to the earliest days of UNIX?  I had to debug problems of that type on
Solaris and even SunOS systems years ago.  Either the boot is fully
ordered, in which case each init script has to complete before the next
can run and init scripts that don't complete stop the boot process, or
it's dependency-based (whether via events or not) and runs potentially in
parallel, in which case if a subsystem that provides a significant
dependency doesn't start, nothing that depends on that subsystem will
start either.

So far as I can tell, this is the case for all the boot systems we're
considering, including the one we're using now.

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


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

Re: On init in Debian

[Lars Wirzenius]

On Sun, Mar 18, 2012 at 12:53:37AM +0800, Thomas Goirand wrote:
> I know almost nothing about systemd
> 
> I'd like people to think twice before opt-in for systemd. I just
> taked with a friend working for redhat, and he told me how much
> he hates it. He told me that if *anything* goes wrong in the boot
> process, then basically, you're stuck, because the next thing will
> be waiting forever. That's basically truth with any event based
> init, and maybe we're just fine with just dependency booting.

Oh nice!

I managed a to spark a new empty discussion, which repeats the old 
arguments, but produces no code. And now there's a challenge
to start a new round of naked FUD wrestling. This was quite the
opposite of what I tried to do. Sorry.

Bugs happen. They get fixed. Life goes on. If you don't grok that,
you should disqualify yourself from doing anything with technology.

I am disappointed in myself for believing that anything good would
come from discussing anything controversial on debian-devel. Luckily,
this new realisation has sobered me so thoroghly that if I get drunk
on Irish whiskey tonight, I won't have a hungover tomorrow.

-- 
All my predictions will turn out to be false


signature.asc
Description: Digital signature

Re: On init in Debian

[Allison Randal]

On 03/17/2012 05:20 AM, Ben Finney wrote:
> 
> I don't know what you're asking, which is why I asked you for
> clarification of what you mean.
> 
> You asked “if this [requirement for the Canonical contributor agreement
> before accepting contributions in ‘upstart’] went away, would it have a
> substantial impact on the decision?” and I don't know what “the
> decision” you're referring to is.
> 
> There are several being discussed, to be decided by different parties,
> as summarized by Lars Wirzenius. Which one are you asking about?

Ah, got it. I was asking about any of the variations involving upstart.

But, I think Philip's right, that there's a significant difference
between supporting it as an alternative and choosing it as a default.

> I'm only pointing out that the contributor agreement requirement imposed
> by Canonical is, as you asked, IMO a significant part of the
> controversy.

Okay, thanks, that's useful.

Allison


--
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/4f64d931.8030...@lohutok.net

Re: On init in Debian

[Thomas Goirand]

On 03/18/2012 01:43 AM, Lars Wirzenius wrote:
> I managed a to spark a new empty discussion, which repeats the old 
> arguments, but produces no code. And now there's a challenge
> to start a new round of naked FUD wrestling. This was quite the
> opposite of what I tried to do. Sorry.
>   
Sorry, that was *not* my intention, and I'm disappointed if you
take it this way. Your summing-up of the previous discussion
was quite good, please don't go away... :)

Have you noticed that both myself and Phil Hands took the
decision to write a sysv init lib, to avoid code duplication?
That alone is a good thing, no?

Thomas


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

Re: On init in Debian

[Michael Biebl]

On 17.03.2012 17:48, Thomas Goirand wrote:
> On 03/17/2012 08:40 PM, Philip Hands wrote:
>> I'm happy to help with that ...
> 
> Cool! Let's do it together then.
> 
>> although, I doubt we're the first people
>> to think of something like this, and it would be a shame to ignore an
>> existing solution.
>>
>> RedHat have some functions for use in init scripts, in
>> /etc/rc.d/functions (although I've not used RedHat for a decade or more,
>> so I've no idea what's included there).
>>   
> 
> I had a look in a CentOS VM, and I didn't see such file. Is it only in RHEL?
> 
>> OpenWRT does something quite interesting, which is that they have an
>> /etc/rc.common and then make the init scripts start thus:
>>
>> #!/bin/sh /etc/rc.common
>> # Copyright (C) 2006-2010 OpenWrt.org
>> # Copyright (C) 2006 Carlos Sobrinho
>>
>> NAME=dropbear
>> PROG=/usr/sbin/dropbear
>> START=50
>> STOP=50
>> PIDCOUNT=0
>> ...
>>
>> so the thing that actually gets run is the /etc/rc.common, which sources
>> the init.d script at its end, so it is possible to override any part of
>> the common script by including functions in the service specific script,
>> but otherwise it just does the default.
>>   
> 
> The idea is nice, I think that being able to overwrite the functions
> you want is cool, even though there are many other ways to do it.
> But it seems to be a bit hard to integrate with dh_installinit, Probably,
> what we would like is a symlink to this rc.common, with the
> package specific script being located in /etc/$whatver being sourced
> by rc.common, right? Do you see how we could do and keep a
> dh_installinit compatibility?
> 


looks like you are wanting to re-invent openrc [1]

[1] http://roy.marples.name/projects/openrc
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: On init in Debian

[Marco d'Itri]

On Mar 17, Thomas Goirand  wrote:

> Have you noticed that both myself and Phil Hands took the
> decision to write a sysv init lib, to avoid code duplication?
> That alone is a good thing, no?
It's not, because the goal should be to deprecate init scripts like 
other distributions did.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On init in Debian

[Philip Hands]

On Sun, 18 Mar 2012 00:48:01 +0800, Thomas Goirand  wrote:
> On 03/17/2012 08:40 PM, Philip Hands wrote:
...
> > so the thing that actually gets run is the /etc/rc.common, which sources
> > the init.d script at its end, so it is possible to override any part of
> > the common script by including functions in the service specific script,
> > but otherwise it just does the default.
> >   
> 
> The idea is nice, I think that being able to overwrite the functions
> you want is cool, even though there are many other ways to do it.
> But it seems to be a bit hard to integrate with dh_installinit, Probably,
> what we would like is a symlink to this rc.common,

No, I think you've misunderstood -- the normal script itself
(/etc/init.d/whatever) is run initially, which because of the #! is not
run as a shell script, but instead it runs the rc.common script, which
then uses the script you thought you were running as a configuration
file, by sourcing it at the end of the rc.common.

Maybe it'll be clearer if I paste an edited version of rc.common here:

=-=-=-=-=-=-
#!/bin/sh
# Copyright (C) 2006-2009 OpenWrt.org
 
. $IPKG_INSTROOT/etc/functions.sh
 
initscript=$1
action=${2:-help}
shift 2  
   
start() {
return 0
}   
 
stop() {
return 0
}   
 
restart() {
trap '' TERM
stop "$@"
start "$@"
} 

...

. "$initscript"  
 
ALL_COMMANDS="start stop reload restart boot shutdown enable disable enabled 
depends ${EXTRA_COMMANDS}"
list_contains ALL_COMMANDS "$action" || action=help 
   
[ "$action" = "reload" ] && action='eval reload "$@" || restart "$@" && :'  
   
$action "$@"
   
=-=-=-=-=-

so it works out what the script that called it was, and what it was
being asked to do, but because it sources the $initscript, you get the
chance to define your own versions of start() stop() etc.

It's really quite clever, but the main problem with it is that (as you
just found) people tend to misunderstand what's going on, which could
lead to more problems than it solves.  Also, if we were going to try to
get people to change their init scripts, it's probably better to breath
new life into the metainit idea.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgp0i1lPLF5Zd.pgp
Description: PGP signature

Re: On init in Debian

[Nikolaus Rath]

Thomas Goirand  writes:
> On 03/18/2012 01:43 AM, Lars Wirzenius wrote:
>> I managed a to spark a new empty discussion, which repeats the old 
>> arguments, but produces no code. And now there's a challenge
>> to start a new round of naked FUD wrestling. This was quite the
>> opposite of what I tried to do. Sorry.
>>   
> Sorry, that was *not* my intention, and I'm disappointed if you
> take it this way.

I would be pretty surprised if anyone took this any other way. You
started by saying that you don't really know what you're talking about,
and continued by spreading some rumors about a systemd deficiency you
have heard of from someone else. 


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/874ntm53cb@vostro.rath.org

Bug#664466: ITP: shelltestrunner -- test command-line programs or arbitrary shell commands

[Iustin Pop]

Package: wnpp
Severity: wishlist
Owner: Iustin Pop 

* Package name: shelltestrunner
  Version : 1.2.1
  Upstream Author : Simon Michael 
* URL : http://joyful.com/shelltestrunner
* License : GPLv3
  Programming Lang: Haskell
  Description : test command-line programs or arbitrary shell commands

shelltestrunner is a cross-platform tool for testing command-line
programs (or arbitrary shell commands). It reads simple declarative
tests specifying a command, some input, and the expected output, error
output and exit status. Tests can be run selectively, in parallel,
with a timeout, in color, and/or with differences highlighted.



-- 
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/20120317222033.30496.97179.report...@ruru.hq.k1024.org

Re: On init in Debian

[Karl Goetz]

On Sun, 18 Mar 2012 00:48:01 +0800
Thomas Goirand  wrote:

> On 03/17/2012 08:40 PM, Philip Hands wrote:
> > I'm happy to help with that ...
> 
> Cool! Let's do it together then.
> 
> > although, I doubt we're the first people
> > to think of something like this, and it would be a shame to ignore
> > an existing solution.
> >
> > RedHat have some functions for use in init scripts, in
> > /etc/rc.d/functions (although I've not used RedHat for a decade or
> > more, so I've no idea what's included there).
> >   
> 
> I had a look in a CentOS VM, and I didn't see such file. Is it only
> in RHEL?

19:33:06 (centos6) kgoetz@epicfail: ~ $ ls /etc/init.d/functions 
-rwxr-xr-x 1 root root 14K Dec 19 12:00 /etc/init.d/functions

(i note init.d is a symlink to /etc/rc.d/init.d, so the functions have
been moved down a level)
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group
*** I've changed GPG key to 6C097260 ***


signature.asc
Description: PGP signature

Re: On init in Debian

[Karl Goetz]

On Sat, 17 Mar 2012 18:23:57 +0800
Thomas Goirand  wrote:

> On 03/17/2012 08:10 AM, Fernando Lemos wrote:
> > Right now, creating a init script means copying an ugly 159-line
> > skeleton and carefully editing it, hoping not to break anything
> > while at it. Even if we can't have a single generator for multiple
> > init systems, having something declarative to build most init
> > scripts we need would be a big step forward and it would make a lot
> > of sense as well in a future where we may need to support multiple
> > init systems. 

> some others to review my work. The ultimate goal would be that
> packages would simply need to do something like:
> 
> NAME=package-binary-file
> DESC="package daemon description"

If you are planning to generate these out of systemd/upstart configs,
both provide a description field, but I don't see a name field from
either.
http://www.freedesktop.org/software/systemd/man/systemd.unit.html
http://linux.die.net/man/5/init

> [ -e . /usr/share/sysv-lib/debsysv-lib ] && debsysv-init-lib $@
> 
> That's (in best cases) only 3 lines, (plus the lsb-base header)...
> Of course, in many cases, we need a bit more, this could be
> implemented with things like START_OPTS / STOP_OPTS and
> so on, and maybe some hooks for start/stop functions.

Hopefully there is some way to know (as a user) that a service doesn't
support restart (or some other arbitrary target). Services that
silently fail to (re)start are rather annoying
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group
*** I've changed GPG key to 6C097260 ***


signature.asc
Description: PGP signature

Re: debian-multimedia.org considered harmful

[Romain Beauxis]

2012/3/17 Arto Jantunen :
> Thomas Goirand  writes:
>
>> On 03/17/2012 06:11 AM, Romain Beauxis wrote:
>>> 2012/3/11 Mike Hommey 
>>>
 The problem is: decss is illegal in very much more than just the US.
 This is a very different situation.

>>> Orly? Do you know of any law and/or court case backing this assertion?
>>>
>>> Romain
>>>
>> There is a DMCA in both US and UK (at least)...
>
> The EU has a directive that requires member countries to implement at
> least some parts of the DMCA. For example Finland opted to implement the
> full thing, and people have actually gotten convictions for using decss
> (so far only people who turned themselves in as a protest, however).
>
> The US has a lot of power and desire to push their agenda through in
> other countries, which tends to mean that a legal problems in the US
> will easily spread to a lot of places. The ACTA and TPPA things are
> "nice" examples (they include the DMCA and worse).

Yes, but how does that make decss or other CSS decryption codes illegal?

It's a cliche comparison but still, CSS decryption is the knife and
DMCA is the murder; the fact that murder is illegal does not imply
that knives are.

There are grounds for declaring a CSS decryption code illegal, such as
license and patent infringement but, as far as I know, there is not
existing legal decision on that mater, at least in western Europe.

Furthermore, concerning libdvdcss, encryption keys are generated or
brute-force'd which makes it even harder to argue based on
intellectual property.. Also libdvdcss has never been legally
challenged.

Most of the legal arguments on this matter are based on legal
bullying. There may be some serious threat, though, but I believe that
it is wrong to consider CSS decryption codes "illegal" per say.

Romain


-- 
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/CABWZ6OQfaersAqE-Mtrv=NF3u-yd=-RfzUKL=etc-xuv_w3...@mail.gmail.com

Re: Re: debian-multimedia.org considered harmful

[Christoph Anton Mitterer]

On Sun, 2012-03-11 at 10:02 +0100, Eric Valette wrote:
> Again, I can understand the reasons, but an average user expects to be 
> able to read dvd or blue-ray or to get a decent multimedia player.
> 
> Other distribution do have ways to provide it to their users.

Which distro provides Blu-Ray playback?

Even though there is libaacs and friends now... the MKBs are only
publicly known till version ... what? ... 10?


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: debian-multimedia.org considered harmful

[Christoph Anton Mitterer]

On Sun, 2012-03-11 at 00:56 -0800, Russ Allbery wrote:
> Because it's not illegal in just Kbanga. 
>  The content providers are doing
> their best to make it illegal everywhere, and would potentially harass
> Debian as an organization in rather more than just one country if we
> distribute decss.

In principle you're right,.. but we start to enter a path of doom if we
censor ourself like this...
You'll probably be able to find thousands of places in any distro, where
some patent troll or content mafia organisations pretend to have
"rights" on.
This starts with Redmonds FAT in the Linux kernel over probably
gazillions of Patents of VoIP or other multimedia techniques.

Unfortunately courts in many countries largely follow those evil
organisations.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: debian-multimedia.org considered harmful

[Russ Allbery]

Christoph Anton Mitterer  writes:

> In principle you're right,.. but we start to enter a path of doom if we
> censor ourself like this...

> You'll probably be able to find thousands of places in any distro, where
> some patent troll or content mafia organisations pretend to have
> "rights" on.

Hence the Debian patent policy.

We can't just ignore things like this, nor is it responsible use of
project resources to openly flaunt disobedience to laws, however
ill-conceived.  But neither is it Debian policy to seek out trouble when
that trouble isn't forthcoming.

If you do want to be part of an organization that openly disobeys stupid
laws and makes a point of civil disobedience, more power to you.  I
personally will be cheering you on.  But the Debian Project is not that
organization, nor is it structured to be that organization (and carefully
structuring such an organization is important).  The Debian Project has
other goals, which mostly require that it work within the legal framework
that it has available while making public statements when that legal
framework interferes with project goals.

As individual developers, we can of course support a range of
organizations, from the practical and goal-oriented to those that are more
political, adversarial, or aimed at practicing civil disobedience, as we
feel is appropriate and as match our individual beliefs.  It doesn't work
for one organization to try to be all of those things at once.

The situation with decss is not new, and the project has been putting up
with it for quite a long time.  The legal situation around DRM and other
content restrictions continues to be troubling, but I don't think anything
has changed about decss recently that augurs a path of doom.

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


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

Re: Adding selinux pam module by default for desktop manager

[Steve Langasek]

On Thu, Mar 08, 2012 at 08:13:10PM +0100, Laurent Bigonville wrote:
> On SELinux enabled system, login applications need to call selinux pam
> module during the opening of the session to correctly set the user's
> security context. In Debian the "login" service is already doing this,
> but desktop managers are not.

> I would propose to add the needed call to the pam_selinux module in DM
> pam services by default. This pam module is installed in the
> libpam-modules package, which is (I think) installed by default on
> every system.

Heh, yes, libpam-modules is a non-removable part of the system.

> The pam module needs to be called twice, please see the login pam
> service or my patch[0] for gdm3. The module can be 'require'ed if we
> are sure it's installed on the system.

> Any input on this?

> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661289

This is an obviously-correct change to make; we should have the same
handling in gdm and other DMs as we do in login.

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


signature.asc
Description: Digital signature

Re: debian-multimedia.org considered harmful

[Chris Knadle]

On Saturday, March 17, 2012 21:53:18, Russ Allbery wrote:
> Christoph Anton Mitterer  writes:
> > In principle you're right,.. but we start to enter a path of doom if we
> > censor ourself like this...
> > 
> > You'll probably be able to find thousands of places in any distro, where
> > some patent troll or content mafia organisations pretend to have
> > "rights" on.
> 
> Hence the Debian patent policy.
> 
> We can't just ignore things like this, nor is it responsible use of
> project resources to openly flaunt disobedience to laws, however
> ill-conceived.  But neither is it Debian policy to seek out trouble when
> that trouble isn't forthcoming.
> 
> If you do want to be part of an organization that openly disobeys stupid
> laws and makes a point of civil disobedience, more power to you.  I
> personally will be cheering you on.  But the Debian Project is not that
> organization, nor is it structured to be that organization (and carefully
> structuring such an organization is important).  The Debian Project has
> other goals, which mostly require that it work within the legal framework
> that it has available while making public statements when that legal
> framework interferes with project goals.

The above explains the whole reason d-m.o exists.

However perhaps it also might explain the tenuous relationship d.o has with  
d-m.o because d.o may need to distance itself from the work d-m.o does.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/201203180129.20352.chris.kna...@coredump.us

Re: debian-multimedia.org considered harmful

[Russ Allbery]

Chris Knadle  writes:
> On Saturday, March 17, 2012 21:53:18, Russ Allbery wrote:

>> Hence the Debian patent policy.

>> We can't just ignore things like this, nor is it responsible use of
>> project resources to openly flaunt disobedience to laws, however
>> ill-conceived.  But neither is it Debian policy to seek out trouble
>> when that trouble isn't forthcoming.

>> If you do want to be part of an organization that openly disobeys
>> stupid laws and makes a point of civil disobedience, more power to you.
>> I personally will be cheering you on.  But the Debian Project is not
>> that organization, nor is it structured to be that organization (and
>> carefully structuring such an organization is important).  The Debian
>> Project has other goals, which mostly require that it work within the
>> legal framework that it has available while making public statements
>> when that legal framework interferes with project goals.

> The above explains the whole reason d-m.o exists.

> However perhaps it also might explain the tenuous relationship d.o has
> with d-m.o because d.o may need to distance itself from the work d-m.o
> does.

Yup.  Exactly.  Christian is taking on himself the legal risk of providing
those packages, which the project as a whole can't really do.  Discussion
about the confusion that can be caused by some of the other packages he
carries aside (and I do think that issue is real), I for one thank him for
his work.

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


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