Re: On init in Debian

[Svante Signell]

On Tue, 2012-03-20 at 14:49 -0700, Russ Allbery wrote:
> Bernd Zeimetz  writes:

> > No. The goal should be to have something which is easy to debug.
> 
> I don't agree.  I'm happy to trade frequency of problems for more
> difficult debugging in the rare cases that problems still happen.  In
> other words, provided that a new solution exposed a much smaller surface
> that *could* be buggy, I'm happy for debugging problems still remaining to
> be somewhat more difficult.

And how do you expect non-experts be able to solve problems when they
pop up. Buying consultant services from the experts?


-- 
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/1332317005.25378.79.ca...@hp.my.own.domain

Bug#664836: ITP: node-gyp -- Native addon build tool for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-gyp
  Version : 0.3.7
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/TooTallNate/node-gyp
* License : Expat
  Programming Lang: JavaScript
  Description : Native addon build tool for Node.js

node-gyp is a cross-platform command-line tool written in Node.js
for compiling native addon modules for Node.js, which takes away the
pain of dealing with the various differences in build platforms.
node-gyp will replace node-waf program in Node.js version 0.8.
.
Node.js is  an event-based server-side javascript engine.




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

Re: On init in Debian

[Marco d'Itri]

On Mar 21, Svante Signell  wrote:

> And how do you expect non-experts be able to solve problems when they
> pop up. Buying consultant services from the experts?
Non-experts are not able to solve any problem, so this is not an issue.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On init in Debian

[Svante Signell]

On Wed, 2012-03-21 at 09:29 +0100, Marco d'Itri wrote:
> On Mar 21, Svante Signell  wrote:
> 
> > And how do you expect non-experts be able to solve problems when they
> > pop up. Buying consultant services from the experts?
> Non-experts are not able to solve any problem, so this is not an issue.
> 
They can with the help of people with the knowledge and interest in
helping out, e.g. using MLs. And people learn by time and own effort.
The other alternative would be to buy support from RedHat or Canonical.
Unfortunately such a solution voids _all_ reasons for having Debian as a
distribution for _any_ users. If that is your intention, why do you work
on Debian, when RHL and Ubuntu is already available? 



-- 
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/1332320380.25378.87.ca...@hp.my.own.domain

Re: On init in Debian

[Bernhard R. Link]

* Marco d'Itri  [120321 09:34]:
> On Mar 21, Svante Signell  wrote:
> > And how do you expect non-experts be able to solve problems when they
> > pop up. Buying consultant services from the experts?
> Non-experts are not able to solve any problem, so this is not an issue.

I'm really fed up with this elitism. There are not only experts and
people knowing nothing. The is a wide range between.

By building things that either work or are impossible to fix you might
be able to finaly produce a situation like that, with dependent users
not being able to do anything and only people taking some explicit
courses able to fix things.

But that is neither was the situation currently is in the Linux world
not what it should become.

Actually I think enabling people to gradually understand the system
they use and being able to fix the problems they run into is a even
more important part of freedom than just licenses. What good is being
allowed by law to modify your system if the system itself treats you
as a child that should not mess with anything?

Where should future free software writers origin from if there is a
barrier erected between users and 'experts'?

Bernhard R. Link


-- 
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/20120321090152.ga2...@client.brlink.eu

Re: On init in Debian

[Gergely Nagy]

m...@linux.it (Marco d'Itri) writes:

> On Mar 21, Svante Signell  wrote:
>
>> And how do you expect non-experts be able to solve problems when they
>> pop up. Buying consultant services from the experts?
> Non-experts are not able to solve any problem, so this is not an
> issue.

I'm afraid I'll have to disagree. If non-experts weren't able to solve
problems, I wouldn't be here today, and I wouldn't have a job, nor would
I be a Debian developer.

-- 
|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/87d386714l.fsf@algernon.balabit

On init in *Debian*

[Thomas Hood]

Technical and other merits of contending init systems have been
discussed here at some length. I think we should focus on another
question, namely, which alternative is best suited to *Debian*, taking
into consideration Debian's developer community structure (many
independent package maintainers, minimalistic policy) and the role of
Debian in relation to other distributions, most importantly Ubuntu.

Init system foo might be technically fabulous, but if maintaining foo
in Debian requires frequent simultaneous changes to many packages then
foo might not be well suited to Debian.

By "alternatives" I mean alternative sets of sets of supported init systems:
* sysvinit for all kernels
* Upstart for Linux; sysvinit for others
* systemd for Linux; sysvinit for others
* sysvinit and optionally Upstart for Linux; sysvinit for others
* sysvinit and optionally Upstart and optionally systemd for Linux,
sysvinit and optionally systemd for others
etc., etc.,

The proposal to drop support for kernels other than Linux has already
been adequately aired.  For the sake of focus I'd like to make the
assumption in this thread that support for alternative kernels and
architectures will not be dropped on account of the choice of init
system alternative.

Putting the question another way: is it most compatible with Debian's
structure and consistent with its traditions to continue supporting
sysvinit universally (enforced by policy) and to leave it up to
maintainers, helped by others, to support other init systems alongside
sysvinit?  Then if things happen as they have in the past, Upstart
enthusiasts will open bug reports requesting the inclusion of Upstart
job configuration files; systemd enthusiasts will open bug reports
requesting the inclusion of systemd service files, and so on.

Or do you see some other approach as more compatible and consistent?
-- 
Thomas Hood


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

Re: On init in Debian

[Bernd Zeimetz]

On 03/21/2012 09:29 AM, Marco d'Itri wrote:
> On Mar 21, Svante Signell  wrote:
> 
>> And how do you expect non-experts be able to solve problems when they
>> pop up. Buying consultant services from the experts?
> Non-experts are not able to solve any problem, so this is not an issue.

Obviously you were born as an expert.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4f69a3cc.1070...@bzed.de

Re: On init in Debian

[Martin Wuertele]

* Marco d'Itri  [2012-03-21 09:34]:

> On Mar 21, Svante Signell  wrote:
> 
> > And how do you expect non-experts be able to solve problems when they
> > pop up. Buying consultant services from the experts?
> Non-experts are not able to solve any problem, so this is not an issue.

But they can provide debugging info and some level of analyses that
helps to triage the problems (and if it's a simple set -x in init
scripts). 

yours Martin


-- 
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/20120321094909.gc2...@anguilla.debian.or.at

Re: Re: On init in Debian

[Eric Valette]

  
  

  
> And how do you expect non-experts be able to solve problems when they
> pop up. Buying consultant services from the experts?
Non-experts are not able to solve any problem, so this is not an issue.
  
  You are even unable to understand how brilliant I am you poor
  stupid fellows.
  
  Come on, there are people on this list that have been using debian
  for probably longer than you and know Linux quite well. System
  init is very fragile, as bootloader. Fixing them is complicated
  and should be done in a couple of hours so that broken machines do
  not spread to much beyond people unable to fix them. So its vital
  to have a lot of people able to fix broken init in a couple of
  hours. It did happen in the past, and will happen with any init
  system. (grub upgrade broke one of my machine yesterday).
  
 A new system init will require a learning
  curve and the sentence above, make people fear that they will be
  unable to fix anything by themselves while you sleep after pushing
  an insufficiently tested change...

--eric


  

  



-- 
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/4f69a19e.7080...@free.fr

Re: On init in Debian

[Bernd Zeimetz]

On 03/20/2012 10:49 PM, Russ Allbery wrote:
> Bernd Zeimetz  writes:
>> On 03/17/2012 08:20 PM, Marco d'Itri wrote:
>>> 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.
> 
>> No. The goal should be to have something which is easy to debug.
> 
> I don't agree.  I'm happy to trade frequency of problems for more
> difficult debugging in the rare cases that problems still happen. 

How can you be sure that such problems will happen less often? What if a
problem is not solvable by editing a config file?

> In
> other words, provided that a new solution exposed a much smaller surface
> that *could* be buggy, I'm happy for debugging problems still remaining to
> be somewhat more difficult.
> 
>> Shell scripts are easy to debug, even via a serial console.
> 
> I also don't agree with this, for what it's worth.

Common init scripts are short enough to make them easy to debug. Its
more annoying when these shellscripts call other shellscripts which call
other shellscripts - but that is a different issue which needs to be
solved - but not necessarily in the init system.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4f69a81e.5000...@bzed.de

Bug#664845: ITP: libpadre-plugin-pdl-perl -- PDL support for Padre IDE

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpadre-plugin-pdl-perl
  Version : 0.05
  Upstream Author : Ahmad M. Zawawi 
* URL : http://search.cpan.org/dist/Padre-Plugin-PDL/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL support for Padre IDE

Once this plugin is enabled, Padre editor will provide context-sensitive
help integration for PDL. (PDL stands for Perl Data Language,
a perl extension that is designed for scientific and bulk numeric
data processing and display.)

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


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

Bug#664257: multiarch tuples are not documented/defined

[Goswin von Brederlow]

Matthias Klose  writes:

> On 19.03.2012 15:34, Jonathan Nieder wrote:
>> Goswin von Brederlow wrote:
>>
>>> Did you read the wiki page?
>>
>> Yes.  Is the kind of information on which calling convention, basic
>> system library structures, and so on form the ABI for a given tuple
>> that I was giving examples of not what the upstream gcc folks were
>> looking for?  I'm not sure I understand the point of your question.
>>
>> Ah, maybe this is where we are talking past each other: I read this as
>> a request to pin down and document the definition of each multiarch
>> tuple.  Perhaps you read it as a request to pin down and document the
>> definition of the term "multiarch tuple", without necessarily pinning
>> down the details for each arch.
>>
>> It would certainly be useful to clarify which is needed before
>> deciding which to spend time on, so thanks for asking.  Matthias?
>
> first thing would be the documentation of each tuple currently used by
> Debian (including the ones used for the non-default biarch
> multilibs). If we can come up with a definition of "multiarch tuple"
> later that's fine, but given that we did abandon the earlier approach
> I'm not sure that's possible.
>
>   Matthias

Should we even have biarch in the multiarch world?

The biarch libs and foreign libs installed through multiarch implement
the same ABI/calling convention/functionality. They are basically
interchangable.

To make them truely interchangable the multiarch tuple for biarch libs
should be the same as they would have if they were the native
one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
example from now on]. And they should use the same paths. If there is no
native equivalent for some biarch lib then just make up some multiarch
tuple based on the gnu triplet. The only thing that matters is that it
uniquly identifies the calling convention of the lib.


For Debian (wheezy+x) I would like to see gcc-multilib depend on
libc6:i386 instead of libc6-i386. Or maybe remove multilib support
alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
-m32 could remain for compatibility but call i486-linux-gnu-gcc.

After all with multiarch having anything build for 32bit in amd64 is
wastefull as it just duplicates the package already in i386. Same with
ppc / ppc64, ...

MfG
Goswin



-- 
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/87ehsm2qs9.fsf@frosties.localnet

Re: On init in Debian

[Marco d'Itri]

On Mar 21, "Bernhard R. Link"  wrote:

> > Non-experts are not able to solve any problem, so this is not an issue.
> I'm really fed up with this elitism.
I am fed up with other cathegories of people, but for some reason the 
Debian listmasters requested that I do not discuss this here.

> There are not only experts and
> people knowing nothing. The is a wide range between.
Yes, I know well this. My point, which obviously passed way over all of 
you, was not that Debian systems should only be serviceable by 
"experts" (whatever this means).

People are not born with an innate knowledge of sysvinit-style init 
scripts, so if they can learn how to debug them then they can as well 
learn how to debug upstart/systemd.
If this were not true then the logical consequence would be to not adopt 
any new technology.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On init in Debian

[Tollef Fog Heen]

]] Svante Signell 

> On Tue, 2012-03-20 at 14:49 -0700, Russ Allbery wrote:
> > Bernd Zeimetz  writes:
> 
> > > No. The goal should be to have something which is easy to debug.
> > 
> > I don't agree.  I'm happy to trade frequency of problems for more
> > difficult debugging in the rare cases that problems still happen.  In
> > other words, provided that a new solution exposed a much smaller surface
> > that *could* be buggy, I'm happy for debugging problems still remaining to
> > be somewhat more difficult.
> 
> And how do you expect non-experts be able to solve problems when they
> pop up. Buying consultant services from the experts?

I don't expect non-experts to be able to solve problems with init
scripts any more or less than I expect them to be able to solve problems
with systemd units, so I fail to see why this question is relevant.

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

Re: Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment

[Simon McVittie]

On 20/03/12 20:11, Ivan Krylov wrote:
>  Sandbox is a library (and helper utility) to run programs in a "sandboxed"
>  environment.  This is used as a QA measure to try and prevent applications 
> from
>  modifying files they should not.

Is sandbox secure (in the sense that an actively malicious program run
inside a sandbox, whose author is fully aware of how sandbox works, is
prevented from breaking out), or does it only protect against common
mistakes and not against deliberate abuse?

If sandbox is not suitable for sandboxing deliberately malicious
programs, I think it's important for its package description to say so.

(For instance, chroot(2) is not secure against malicious programs with
CAP_SYS_CHROOT. If I understand it correctly, schroot, as commonly used
in Debian infrastructure, is secure if its user cannot get root
privileges and all setuid-root binaries inside the chroot are secure.)

>  For people who are familiar with the Debian "fakeroot" project or the RPM 
> based
>  "InstallWatch", sandbox is in the same vein of projects.

Is it really, though? fakeroot is just an LD_PRELOAD hack which pretends
to have root privileges: it doesn't allow the program to do anything
that it couldn't already do (its real privileges are those of the user
running it). As a result, fakeroot "fails safe" if a privileged action
isn't supported by fakeroot - it just won't work. In contrast, a
mechanism that gives real root privileges will "fail open", and allow
all privileged actions that it doesn't specifically deny.

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/4f69bd0a.1020...@debian.org

Re: On init in Debian

[Svante Signell]

On Wed, 2012-03-21 at 12:11 +0100, Tollef Fog Heen wrote:
> ]] Svante Signell 

> > And how do you expect non-experts be able to solve problems when they
> > pop up. Buying consultant services from the experts?
> 
> I don't expect non-experts to be able to solve problems with init
> scripts any more or less than I expect them to be able to solve problems
> with systemd units, so I fail to see why this question is relevant.

As mentioned before set -x can be used and somebody knowledgeable about
the output can help the person having problems. This is just an example
of possible debugging for a non-expert.
 
Can you explain what features are so much better with systemd/upstart
(event-based) compared to sysvinit? If you are interested in faster boot
times, then coreboot would help much compared to commercial BIOSes,
regardless of the init system.

Regarding who is expert or not, can the people who considers themselves
as such (others shouldn't bother) do a _scientific_ comparison of the
three alternatives with respect to important features. First step would
be to write down which aspects are important, and continue from there.
Also, practical experiments are needed to verify statements made.

To repeat, we are talking Debian now, no other distribution :-(


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

Re: On init in *Debian*

[Marco d'Itri]

On Mar 21, Thomas Hood  wrote:

> The proposal to drop support for kernels other than Linux has already
> been adequately aired.  For the sake of focus I'd like to make the
> assumption in this thread that support for alternative kernels and
> architectures will not be dropped on account of the choice of init
> system alternative.
I do not believe this to be a reasonable assumption.

> sysvinit?  Then if things happen as they have in the past, Upstart
> enthusiasts will open bug reports requesting the inclusion of Upstart
> job configuration files; systemd enthusiasts will open bug reports
> requesting the inclusion of systemd service files, and so on.
This would be a bad solution, because it would require doing everything 
three times.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On init in Debian

[Tollef Fog Heen]

]] Svante Signell 

> On Wed, 2012-03-21 at 12:11 +0100, Tollef Fog Heen wrote:
> > ]] Svante Signell 
> 
> > > And how do you expect non-experts be able to solve problems when they
> > > pop up. Buying consultant services from the experts?
> > 
> > I don't expect non-experts to be able to solve problems with init
> > scripts any more or less than I expect them to be able to solve problems
> > with systemd units, so I fail to see why this question is relevant.
> 
> As mentioned before set -x can be used and somebody knowledgeable about
> the output can help the person having problems. This is just an example
> of possible debugging for a non-expert.

Yes, and systemd --test is useful to debug systemd problems.  I don't
know what point you are trying to make?

> Can you explain what features are so much better with systemd/upstart
> (event-based) compared to sysvinit? If you are interested in faster boot
> times, then coreboot would help much compared to commercial BIOSes,
> regardless of the init system.

I have no idea why you are constructing a straw-man which I don't think
I've ever argued for, and then propose a different solution to it (and
to boot, one that does not generally work on most systems).

As for a few features that are better: services are properly contained
and are actually managed rather than relying on the assumption that
since you've run a shell script that happened to exit 0, that service is
up and working.

Related, services are properly contained and there's no way for the
environment of the user who is starting the service to leak into the
service's environment.

> Regarding who is expert or not, can the people who considers themselves
> as such (others shouldn't bother) do a _scientific_ comparison of the
> three alternatives with respect to important features. First step would
> be to write down which aspects are important, and continue from there.
> Also, practical experiments are needed to verify statements made.

I'd rather work on making systemd better and a better init system for
Debian than to satisfy some academic desire for a comparison of init
systems.

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

Re: On init in *Debian*

[Ian Jackson]

Marco d'Itri writes ("Re: On init in *Debian*"):
> On Mar 21, Thomas Hood  wrote:
> > The proposal to drop support for kernels other than Linux has already
> > been adequately aired.  For the sake of focus I'd like to make the
> > assumption in this thread that support for alternative kernels and
> > architectures will not be dropped on account of the choice of init
> > system alternative.
>
> I do not believe this to be a reasonable assumption.

Yes, we know, but as Thomas says, that view has already been
adequately aired.  You don't need to post every time to contradict
it.

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

Re: On init in Debian

[Bernd Zeimetz]

On 03/20/2012 07:14 AM, Tollef Fog Heen wrote:
> ]] 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.
> 
> FWIW, I have a proposal for a GSoC task this year to write a
> systemd-to-initscript converter,
> http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files
> 
> The systemd service files are covered by the «interface guarantee»,
> meaning they won't change incompatibly in a future release of systemd,
> so I think having that as the base format would be fairly reasonable,
> though probably just a subset so it's portable to other kernels and init
> systems.

Sounds like a good plan to make the fanboys of both sides of the world
happy - I have no idea if its possible, but maybe also generate upstart
configs?

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4f69e125.3090...@bzed.de

Bug#664257: multiarch tuples are not documented/defined

[Matthias Klose]

On 21.03.2012 11:26, Goswin von Brederlow wrote:

Matthias Klose  writes:


On 19.03.2012 15:34, Jonathan Nieder wrote:

Goswin von Brederlow wrote:


Did you read the wiki page?


Yes.  Is the kind of information on which calling convention, basic
system library structures, and so on form the ABI for a given tuple
that I was giving examples of not what the upstream gcc folks were
looking for?  I'm not sure I understand the point of your question.

Ah, maybe this is where we are talking past each other: I read this as
a request to pin down and document the definition of each multiarch
tuple.  Perhaps you read it as a request to pin down and document the
definition of the term "multiarch tuple", without necessarily pinning
down the details for each arch.

It would certainly be useful to clarify which is needed before
deciding which to spend time on, so thanks for asking.  Matthias?


first thing would be the documentation of each tuple currently used by
Debian (including the ones used for the non-default biarch
multilibs). If we can come up with a definition of "multiarch tuple"
later that's fine, but given that we did abandon the earlier approach
I'm not sure that's possible.

   Matthias


Should we even have biarch in the multiarch world?


multilib libraries should continue to build.


The biarch libs and foreign libs installed through multiarch implement
the same ABI/calling convention/functionality. They are basically
interchangable.

To make them truely interchangable the multiarch tuple for biarch libs
should be the same as they would have if they were the native
one. E.g. the i386-linux-gnu for 32bit libs on amd64 [using amd64 as
example from now on]. And they should use the same paths. If there is no
native equivalent for some biarch lib then just make up some multiarch
tuple based on the gnu triplet. The only thing that matters is that it
uniquly identifies the calling convention of the lib.


For Debian (wheezy+x) I would like to see gcc-multilib depend on
libc6:i386 instead of libc6-i386.  Or maybe remove multilib support
alltogether and use i486-linux-gnu-gcc (a cross compiler) instead. gcc
-m32 could remain for compatibility but call i486-linux-gnu-gcc.


no. adding cross-architecture build dependencies doesn't add to the build 
stability. The possibility to call another version or target compiler from the 
driver was removed upstream, so I doubt somebody want to re-add it again, and I 
won't carry this as a downstream patch (so please get the done in stage1 for 4.8 
if you are interested in that).



After all with multiarch having anything build for 32bit in amd64 is
wastefull as it just duplicates the package already in i386. Same with
ppc / ppc64, ...


yes, but you are quick to waste my own time. Patches which do not go upstream do 
require an extra maintenance effort as seen for the split build (gcc, gcj, ...) 
and the hardening patches.  A lot of multilib packages can be dropped,

but the ones built from gcc and glibc should continue to build.



--
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/4f69e602.4040...@debian.org

Re: On init in *Debian*

[Josselin Mouette]

Le mercredi 21 mars 2012 à 13:39 +, Ian Jackson a écrit :
> Marco d'Itri writes ("Re: On init in *Debian*"):
> > On Mar 21, Thomas Hood  wrote:
> > > The proposal to drop support for kernels other than Linux has already
> > > been adequately aired.  For the sake of focus I'd like to make the
> > > assumption in this thread that support for alternative kernels and
> > > architectures will not be dropped on account of the choice of init
> > > system alternative.
> >
> > I do not believe this to be a reasonable assumption.
> 
> Yes, we know, but as Thomas says, that view has already been
> adequately aired.  You don't need to post every time to contradict
> it.

Just because a few vocal people disagree with it, doesn’t mean there is
consensus against it.

Anyway, the point of these discussions is not to hang kFreeBSD
developers or to throw stones at Hurd. The point is to choose a good
init system for Linux. And if other kernels can’t deal with it, so be
it.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


--
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/1332341680.2806.4.camel@tomoe

Re: On init in Debian

[Svante Signell]

On Wed, 2012-03-21 at 14:44 +0100, Tollef Fog Heen wrote:
> ]] Svante Signell 

> > Regarding who is expert or not, can the people who considers themselves
> > as such (others shouldn't bother) do a _scientific_ comparison of the
> > three alternatives with respect to important features. First step would
> > be to write down which aspects are important, and continue from there.
> > Also, practical experiments are needed to verify statements made.
> 
> I'd rather work on making systemd better and a better init system for
> Debian than to satisfy some academic desire for a comparison of init
> systems.

How on earth would anybody be able to make a decision if there are no
comparisons between the alternatives available? Throw a dice, rely on
gut feelings, or what? Since everybody is so damned biased in opinions,
I don't see any alternative to making a thorough investigation. This
could be a useful GSoC task. If case the "experts" approve that somebody
not senior or expert enough enough do the work. This would be much more
intersting than writing a systemd-to-initscript converter.


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

Re: On init in Debian

[Josselin Mouette]

Le lundi 19 mars 2012 à 23:17 +0100, Christoph Egger a écrit :
>   *iff* it was reasonably clear porting upstart would be the required
> step I'm rather certain -bsd@ would be working on it. But please noone
> expect us to support multiple -- currently linux-only -- init
> alternatives just because they *might* *eventually* become default in
> Debian *some* day.

This is a reasonable position to take, but if it is the general position
of kFreeBSD developers, it completely dismisses the shrieks of all those
asking to not choose a solution that currently doesn’t work for
kFreeBSD.

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


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

Re: On init in Debian

[Timo Juhani Lindfors]

Svante Signell  writes:
> How on earth would anybody be able to make a decision if there are no
> comparisons between the alternatives available?

I personally decided to install systemd to one of my machines to learn
how it works. I'd recommend this to anyone in this thread that has never
used systemd.


-- 
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/84sjh2dlsj@sauna.l.org

Re: On init in Debian

[Andres Mejia]

On Mar 21, 2012 10:57 AM, "Svante Signell"  wrote:
>
> On Wed, 2012-03-21 at 14:44 +0100, Tollef Fog Heen wrote:
> > ]] Svante Signell
>
> > > Regarding who is expert or not, can the people who considers
themselves
> > > as such (others shouldn't bother) do a _scientific_ comparison of the
> > > three alternatives with respect to important features. First step
would
> > > be to write down which aspects are important, and continue from there.
> > > Also, practical experiments are needed to verify statements made.
> >
> > I'd rather work on making systemd better and a better init system for
> > Debian than to satisfy some academic desire for a comparison of init
> > systems.
>
> How on earth would anybody be able to make a decision if there are no
> comparisons between the alternatives available? Throw a dice, rely on
> gut feelings, or what? Since everybody is so damned biased in opinions,
> I don't see any alternative to making a thorough investigation. This
> could be a useful GSoC task. If case the "experts" approve that somebody
> not senior or expert enough enough do the work. This would be much more
> intersting than writing a systemd-to-initscript converter.
>
>
> --
> 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/1332341808.2962.264.ca...@s1499.it.kth.se
>

FYI, some level of analysis between the three init systems has been done.
See [1].

1. http://0pointer.de/blog/projects/why.html

A bit of a disclaimer here, this comparison was done by a systemd
developer. OTOH he makes quite a convincing argument for systemd.

~ Andres

Re: On init in *Debian*

[YunQiang Su]

It' said that the 2 main advantage of systemd are parallel and
much simpler configuration file.

Is it possible to implement an init system for kFreeBSD and Hurd,
which init system support the configuration file format, while doesn't
support parallel.

Then for maintainer of packages with service, she/he can maintain only
one configuration file, and it works on both kFreeBSD/Hurd and Linux.

On Wed, Mar 21, 2012 at 10:54 PM, Josselin Mouette  wrote:
> Le mercredi 21 mars 2012 à 13:39 +, Ian Jackson a écrit :
>> Marco d'Itri writes ("Re: On init in *Debian*"):
>> > On Mar 21, Thomas Hood  wrote:
>> > > The proposal to drop support for kernels other than Linux has already
>> > > been adequately aired.  For the sake of focus I'd like to make the
>> > > assumption in this thread that support for alternative kernels and
>> > > architectures will not be dropped on account of the choice of init
>> > > system alternative.
>> >
>> > I do not believe this to be a reasonable assumption.
>>
>> Yes, we know, but as Thomas says, that view has already been
>> adequately aired.  You don't need to post every time to contradict
>> it.
>
> Just because a few vocal people disagree with it, doesn’t mean there is
> consensus against it.
>
> Anyway, the point of these discussions is not to hang kFreeBSD
> developers or to throw stones at Hurd. The point is to choose a good
> init system for Linux. And if other kernels can’t deal with it, so be
> it.
>
> --
>  .''`.      Josselin Mouette
> : :' :
> `. `'  “If you behave this way because you are blackmailed by someone,
>  `-    […] I will see what I can do for you.”  -- Jörg Schilling
>
>
> --
> 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/1332341680.2806.4.camel@tomoe
>



-- 
YunQiang Su


--
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/cakcpw6xtqnf+k+_ybk9mw53cnnuvoopdjo6vcgketaj2q01...@mail.gmail.com

Re: On init in Debian

[Russ Allbery]

Svante Signell  writes:
> On Tue, 2012-03-20 at 14:49 -0700, Russ Allbery wrote:

>> I don't agree.  I'm happy to trade frequency of problems for more
>> difficult debugging in the rare cases that problems still happen.  In
>> other words, provided that a new solution exposed a much smaller
>> surface that *could* be buggy, I'm happy for debugging problems still
>> remaining to be somewhat more difficult.

> And how do you expect non-experts be able to solve problems when they
> pop up. Buying consultant services from the experts?

The definition of "somewhat more difficult" is not "impossible for anyone
other than an expert."

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

Re: On init in Debian

[Vincent Bernat]

Le 21.03.2012 10:01, Bernhard R. Link a écrit :

* Marco d'Itri  [120321 09:34]:

On Mar 21, Svante Signell  wrote:
> And how do you expect non-experts be able to solve problems when 
they

> pop up. Buying consultant services from the experts?
Non-experts are not able to solve any problem, so this is not an 
issue.


I'm really fed up with this elitism. There are not only experts and
people knowing nothing. The is a wide range between.


For me, Marco was just sarcastic.


--
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/74153834109d47419998ace48bd97...@luffy.cx

Re: On init in Debian

[Russ Allbery]

Bernd Zeimetz  writes:
> On 03/20/2012 10:49 PM, Russ Allbery wrote:

>> I don't agree.  I'm happy to trade frequency of problems for more
>> difficult debugging in the rare cases that problems still happen.

> How can you be sure that such problems will happen less often?

I apply basic principles of software design, the exact same ones that lead
me to use standard libc functions instead of inventing my own wheels
because, indeed, when one does that, problems will happen less often.

I plan on relying on the fact that using common infrastructure means that
lots of other people have been testing and debugging that infrastructure
for you, which means that it's going to be considerably more robust and
cope with more of the corner cases than that thing I wrote as a one-off to
solve my immediate problem.

I'm a bit surprised that I even have to say this, since to me this is
obvious to the point of triviality.

> What if a problem is not solvable by editing a config file?

What happens when you have a problem with libc that isn't solvable by
editing a config file?  Or with any other package in Debian?  Well, first
you try to debug it using the tools available, and if you can't figure out
what's going on, you file a bug.

>> I also don't agree with this, for what it's worth.

> Common init scripts are short enough to make them easy to debug.

Speaking as someone who has debugged a *lot* of init scripts over the past
15+ years, I continue to disagree with this.

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

Re: On init in *Debian*

[Russ Allbery]

YunQiang Su  writes:

> It' said that the 2 main advantage of systemd are parallel and much
> simpler configuration file.

> Is it possible to implement an init system for kFreeBSD and Hurd, which
> init system support the configuration file format, while doesn't support
> parallel.

The primary problem with supporting systemd on kFreeBSD is that it uses
Linux-specific facilities for discovering system events and hence knowing
when to start or stop particular services, and for tracking services so
that it knows when they're started and whether they're still running.
(There may be a few other things as well, but that seems to be the two
major, broad areas of non-trivial Linux-specific functionality.)

Those are both core to the whole init system and can't be easily done
without by just disabling parallelism or a similar simple fix.

It's certainly *possible* to implement the same on kFreeBSD and Hurd; I
don't think anyone is questioning that, just the level of work and whether
it will happen.

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

Re: Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment

[Goswin von Brederlow]

Simon McVittie  writes:

> On 20/03/12 20:11, Ivan Krylov wrote:
>>  Sandbox is a library (and helper utility) to run programs in a "sandboxed"
>>  environment.  This is used as a QA measure to try and prevent applications 
>> from
>>  modifying files they should not.
>
> Is sandbox secure (in the sense that an actively malicious program run
> inside a sandbox, whose author is fully aware of how sandbox works, is
> prevented from breaking out), or does it only protect against common
> mistakes and not against deliberate abuse?
>
> If sandbox is not suitable for sandboxing deliberately malicious
> programs, I think it's important for its package description to say so.
>
> (For instance, chroot(2) is not secure against malicious programs with
> CAP_SYS_CHROOT. If I understand it correctly, schroot, as commonly used
> in Debian infrastructure, is secure if its user cannot get root
> privileges and all setuid-root binaries inside the chroot are secure.)
>
>>  For people who are familiar with the Debian "fakeroot" project or the RPM 
>> based
>>  "InstallWatch", sandbox is in the same vein of projects.
>
> Is it really, though? fakeroot is just an LD_PRELOAD hack which pretends
> to have root privileges: it doesn't allow the program to do anything
> that it couldn't already do (its real privileges are those of the user
> running it). As a result, fakeroot "fails safe" if a privileged action
> isn't supported by fakeroot - it just won't work. In contrast, a
> mechanism that gives real root privileges will "fail open", and allow
> all privileged actions that it doesn't specifically deny.
>
> S

Is it any better than bind mounting / read-only recursively somewhere,
(s)chrooting there and running the code without CAP_SYS_CHROOT (e.g. as
user)?

Or using unionfs to allow writes but store them in a different directory
tree.

MfG
Goswin


-- 
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/87mx79opt2.fsf@frosties.localnet

Re: On init in *Debian*

[Ian Jackson]

Josselin Mouette writes ("Re: On init in *Debian*"):
> Just because a few vocal people disagree with it, doesn’t mean there is
> consensus against it.

Just because a few vocal people want to throw out KFreeBSD, doesn't
mean there is consensus for it.

> Anyway, the point of these discussions is not to hang kFreeBSD
> developers or to throw stones at Hurd. The point is to choose a good
> init system for Linux. And if other kernels can’t deal with it, so be
> it.

No, the point if these discussions is to decide how to organise the
provision of init services in Debian.

That is different to your statement "choose a good init system for
Linux" in two important ways.  Firstly Debian is not just Linux, and
by putting your statement that way you are being tendentious.
Secondly, we do not necessarily want to simply choose one system.

There are other reasons not to like systemd, although if you've drunk
every other kind of Poettering kool-aid I guess you may not see them.

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

Re: On init in *Debian*

[Allison Randal]

On 03/21/2012 09:22 AM, Russ Allbery wrote:
> 
> The primary problem with supporting systemd on kFreeBSD is that it uses
> Linux-specific facilities for discovering system events and hence knowing
> when to start or stop particular services, and for tracking services so
> that it knows when they're started and whether they're still running.
> (There may be a few other things as well, but that seems to be the two
> major, broad areas of non-trivial Linux-specific functionality.)
> 
> Those are both core to the whole init system and can't be easily done
> without by just disabling parallelism or a similar simple fix.
> 
> It's certainly *possible* to implement the same on kFreeBSD and Hurd; I
> don't think anyone is questioning that, just the level of work and whether
> it will happen.

I recall this as one of the key differences: systemd is tightly coupled
to the Linux kernel, while upstart is not. I was curious, so asked Scott
James Remnant (upstart's creator), and he says it wouldn't be much
effort to port upstart to kFreeBSD and Hurd.

It would be informative to try the port. Treat it as a pilot project,
see how far we can get in a short period of time. Debian has people with
extensive experience in porting software to kFreeBSD and Hurd. If a
couple of them are interested, we can connect them with with a couple of
the upstart core developers and it could move quite quickly.

I'd be happy to help,
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/4f6a0e88.2040...@lohutok.net

Re: On init in Debian

[The Fungi]

On 2012-03-21 15:57:23 +0100 (+0100), Josselin Mouette wrote:
> This is a reasonable position to take, but if it is the general
> position of kFreeBSD developers, it completely dismisses the
> shrieks of all those asking to not choose a solution that
> currently doesn’t work for kFreeBSD.

I've been following this and all related threads to date and never
saw anyone pipe up with, "As one of the kfreebsd/hurd/whatever
porters, I refuse to work on implementing a solution to support a
new init system." Most of the detractors appeared to simply be using
non-Linux ports as an excuse not to switch away from sysvinit, but
weren't necessarily the ones who would be taking on that work
anyway... and that lead to heated arguments in which these
experimental ports got caught in the crossfire for no good reason.

Attacking the usefulness or viability of those projects as a means
of discrediting the vocal opposition seems to me to be doing more
harm than good, as does using them as a scapegoat to avoid
introducing new technologies. I have a few machines running kfreebsd
and hurd ports (for testing some decidedly useful technologies
missing from Linux), and the various non-Linux porters have done a
commendable job implementing necessary features to support other
previously Linux-only reliance in Debian. I see no good reason to
expect that they wouldn't continue to do so.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


-- 
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/20120321175433.gl...@yuggoth.org

Re: On init in Debian

[David Weinehall]

On Wed, Mar 21, 2012 at 11:06:22AM +0100, Bernd Zeimetz wrote:
> On 03/20/2012 10:49 PM, Russ Allbery wrote:
> > I don't agree.  I'm happy to trade frequency of problems for more
> > difficult debugging in the rare cases that problems still happen. 
> 
> How can you be sure that such problems will happen less often? What if a
> problem is not solvable by editing a config file?

You mean "solvable" as in sprinkling sleep here and there in the init
scripts? (There's 40 occurences of sleep -- comments of course removed
-- in various init scripts on my system).

Where exactly would such a hypothetical unsolvable problem be?  In the
service that the config file manages?  In that case it's a bug that
should be fixed in that service.  In systemd/upstart?  Then it should of
course be fixed in systemd/upstart, just like a sysvinit bug should be
fixed in sysvinit, not in the init scripts.

Or are you referring to the fact that the config file won't be turing
complete?  If you can find a contrived enough problem that
baffles systemd/upstart, without being a bug in the service, yet can be
solved in a clean manner by sysvinit, then I'm confident that the
upstream developers of both systemd and upstream would happily help to
add the missing functionality.

> > In other words, provided that a new solution exposed a much smaller
> > surface that *could* be buggy, I'm happy for debugging problems
> > still remaining to be somewhat more difficult.
> > 
> >> Shell scripts are easy to debug, even via a serial console.
> > 
> > I also don't agree with this, for what it's worth.
> 
> Common init scripts are short enough to make them easy to debug. Its
> more annoying when these shellscripts call other shellscripts which call
> other shellscripts - but that is a different issue which needs to be
> solved - but not necessarily in the init system.

On my machine (which might not be the least bit representative of an
"normal" machine -- whatever what would be), the length of the init
scripts ranges from 8 to 653 lines, with the average being 115 lines.

I'd hardly call that short enough to be easy to debug.


Kind regards, David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120321180026.gf17...@suiko.acc.umu.se

Re: On init in Debian

[John H. Robinson, IV]

David Weinehall wrote:
> 
> On my machine (which might not be the least bit representative of an
> "normal" machine -- whatever what would be), the length of the init
> scripts ranges from 8 to 653 lines, with the average being 115 lines.

I got curious. I used my workstation as a basis.

Total Numbers:  87
Mean (Average): 126.02299
Median: 95
Mode:   88,104,159
Pop. Std. Dev:  97.84599
Variance:   9573.83855
High:   436 (checkroot.sh)
Low:8   (rcS)

> I'd hardly call that short enough to be easy to debug.

I didn't remove comments, or compare against the skeleton (which did get
counted, but I removed README)

Not that I think it matters at all, but I did also find 30 occurences of
sleep being called. Anywhere from .1 seconds, up to 5 seconds.

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120321182343.gt2...@a.mx.sbih.org

Re: On init in Debian

[Russ Allbery]

"John H. Robinson, IV"  writes:

> Not that I think it matters at all, but I did also find 30 occurences of
> sleep being called. Anywhere from .1 seconds, up to 5 seconds.

Yeah, this is why so many people are excited about a more event-driven
boot.  Most (hopefully, eventually, all) of those can go away once events
are available for when services are really started or devices available.

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

Re: On init in *Debian*

[Thomas Goirand]

On 03/21/2012 05:42 PM, Thomas Hood wrote:
> Technical and other merits of contending init systems have been
> discussed here at some length. I think we should focus on another
> question, namely, which alternative is best suited to *Debian*, taking
> into consideration Debian's developer community structure (many
> independent package maintainers, minimalistic policy) and the role of
> Debian in relation to other distributions, most importantly Ubuntu.
>
> Init system foo might be technically fabulous, but if maintaining foo
> in Debian requires frequent simultaneous changes to many packages then
> foo might not be well suited to Debian.
>
> By "alternatives" I mean alternative sets of sets of supported init systems:
> * sysvinit for all kernels
> * Upstart for Linux; sysvinit for others
> * systemd for Linux; sysvinit for others
> * sysvinit and optionally Upstart for Linux; sysvinit for others
> * sysvinit and optionally Upstart and optionally systemd for Linux,
> sysvinit and optionally systemd for others
> etc., etc.,
>   

I really think that what's missing here is:
- Improve sysvinit and make it better to fit our needs without breaking
anything (eg: less scripts redundancy, parallel booting, ...).

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/4f6a3082.2080...@debian.org

Bug#664902: ITP: mitm-me -- Firefox extension to click through certificate warnings

[Sascha Girrulat]

Package: wnpp
Severity: wishlist
Owner: Sascha Girrulat 

* Package name: mitm-me
  Version :  2.1.110626
  Upstream Author :Tim Andras 
* URL :  http://andras-tim.github.com/mitm-me
* License : MPL 1.1
  Programming Lang: Java-Script
  Description : Firefox extension to click through certificate warnings



-- 
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/20120321200738.7867.89220.reportbug@kang.girrulat.local

Re: On init in *Debian*

[Russ Allbery]

Thomas Goirand  writes:

> I really think that what's missing here is:
> - Improve sysvinit and make it better to fit our needs without breaking
>   anything (eg: less scripts redundancy, parallel booting, ...).

If you added to sysvinit cgroup support or something similar (so that we
don't have to use PID files and all that dance to figure out whether a
daemon is running and figure out how to stop it), boot-time events so that
init scripts are started when particular devices or other services are
available without requiring arbitrary sleeps and other hacks, and service
monitoring so that services are automatically restarted if they crash for
some reason, then I think it would be an interesting alternative to
upstart or systemd (which can do all of that now).  Particularly if the
configuration for a typical simple daemon startup, shutdown, and restart
were on the order of 10 lines of easy-to-read configuration.

Good luck on your project!  Let us know when you're done.  :)

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

Bug#664951: ITP: mitm-me -- Firefox extension to click through certificate warnings

[Sascha Girrulat]

Package: wnpp
Severity: wishlist
Owner: Sascha Girrulat 

* Package name: mitm-me
  Version : 2.1.110626 
  Upstream Author : Tim Andras 
* URL : http://andras-tim.github.com/mitm-me
* License : MPL-1.1
  Programming Lang: Java-Script 
  Description : Firefox extension to click through certificate warnings

 For IT admins who want very much to click through thousands of self-signed
 certificate warnings and get MitM attacked, this simplifies the process.



-- 
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/20120321204225.20806.10578.reportbug@kang.girrulat.local

Bug#664952: ITP: node-ansi -- Advanced ANSI formatting tool for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-ansi
  Version : 0.1.0
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/TooTallNate/ansi.js
* License : Expat
  Programming Lang: JavaScript
  Description : Advanced ANSI formatting tool for Node.js

node-ansi is a module for Node.js that provides an easy-to-use API
for writing ANSI escape codes to Stream instances.
ANSI escape codes are used to do fancy things in a terminal window,
like render text in colors, delete characters, lines, the entire window,
or hide and show the cursor, and lots more.
.
Node.js is  an event-based server-side javascript engine.




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

Re: On init in *Debian*

[Josselin Mouette]

Le mercredi 21 mars 2012 à 16:49 +, Ian Jackson a écrit :
> Josselin Mouette writes ("Re: On init in *Debian*"):
> > Just because a few vocal people disagree with it, doesn’t mean there is
> > consensus against it.
> 
> Just because a few vocal people want to throw out KFreeBSD, doesn't
> mean there is consensus for it.

No one *wants* to throw out kFreeBSD. But if keeping it implies
technical restrictions on the Linux port, we’re facing a huge problem,
on a project scale, which reaches far beyond the choice of an init
system.

At least one of the kFreeBSD developers has made it clear that we should
choose a solution first and that they will try to adapt to it (and the
rest of the project could even help them to do it if it’s not too much
work). This is always how we’ve dealt with kFreeBSD until now, and I
feel this is a much more pragmatic approach than putting insane
prerequisites on a solution beforehand. It is also an approach that
involves all Debian developers in a constructive way, instead of telling
some of them that they won’t get the features they need because of some
other developers.

> That is different to your statement "choose a good init system for
> Linux" in two important ways.  Firstly Debian is not just Linux, and
> by putting your statement that way you are being tendentious.

Debian is just Linux. Seriously. It might turn out to be more than this,
but we’re not there. Those using untested, experimental OSes in
production are dangerous people that I would never hire as sysadmins.

> Secondly, we do not necessarily want to simply choose one system.

We need to choose one global solution, if you prefer this wording.
Having it consisting of a user choice between several different
implementations is a terrible idea for a number of reasons, but indeed
you are entitled to an opinion that “Linux is about choice” and to put
such possibilities on the table.

> There are other reasons not to like systemd, although if you've drunk
> every other kind of Poettering kool-aid I guess you may not see them.

I have drunk enough of Poettering to know he’s a toxic and obnoxious
person. Unfortunately that doesn’t prevent him from writing good
software. Still, the personality of the lead developer should certainly
be considered as one parameter for a good choice.

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


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

Re: On init in *Debian*

[Fernando Lemos]

On Wed, Mar 21, 2012 at 4:48 PM, Thomas Goirand  wrote:
> I really think that what's missing here is:
> - Improve sysvinit and make it better to fit our needs without breaking
> anything (eg: less scripts redundancy, parallel booting, ...).

You're missing the point. We already have parallel booting. Less
script redundancy, while being something it seems most of us (if not
all of us) are interested in, is just a nice side effect of switching
to a modern init system.

An improved init system would need to be event based, as many people
with actual knowledge on the issue have already stated (as the Linux
kernel itself is becoming increasingly event-based). Turning sysvinit
into an event-based init system is basically rewriting it. So what
you're proposing to boils down to "let's start a new event-based init
system from scratch".

So you're saying we could create this brand new init system instead of
using stuff that is being used in the real world. And you're also
saying that this would be done in a way that will cause less breakage
than using alternatives that have been used for quite some time now. I
don't mean to sound disrespectful, but this makes no sense at all.

Regards,


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

a good "license your software" how-to for upstream developers ?

[Jérémy Lal]

Hi,
i find it difficult and time-consuming to explain, with limited vocabulary
(english is not my mother tongue), to an upstream developer that his tarball
is not properly licensed.
For example i've seen software that was intended to be free, released without
any license, or with missing license on some files, bundled dependencies, or
pictures, or even worse with a modified adhoc license.
I find it very very hard to find the right words to explain whatever is wrong
with those, and so, i wonder if there is some clear and concise documentation
about how to properly license a free software, targeted at upstream developers.

Regards,
Jérémy Lal


-- 
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/4f6a589e.9090...@melix.org

Bug#664974: ITP: octave-geometry -- geometric computing functions for Octave

[Rafael Laboissiere]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: octave-geometry
  Version : 1.4.0
  Upstream Author : The Octave Community 
* URL : http://octave.sourceforge.net/geometry/
* License : GPL-3+
  Programming Lang: Octave
  Description : geometric computing functions for Octave

This package extends the MatGeom functions for Octave, a scientific
computing software.  It is useful to create, transform, manipulate and
display geometric primitives in 2D.  It also contains functions for
performing boolean operations between two polygons and to manipulate
files in SVG and gmsh formats.

This Octave add-on package is part of the Octave-Forge project.

Initial Debian package at
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-geometry.git

Rafael Laboissiere (in the behalf of the Debian OCtave Group) 



-- 
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/20120321230341.30450.71089.reportbug@mullen

Re: On init in Debian

[Tollef Fog Heen]

]] Svante Signell 

> On Wed, 2012-03-21 at 14:44 +0100, Tollef Fog Heen wrote:
> > ]] Svante Signell 
> 
> > > Regarding who is expert or not, can the people who considers themselves
> > > as such (others shouldn't bother) do a _scientific_ comparison of the
> > > three alternatives with respect to important features. First step would
> > > be to write down which aspects are important, and continue from there.
> > > Also, practical experiments are needed to verify statements made.
> > 
> > I'd rather work on making systemd better and a better init system for
> > Debian than to satisfy some academic desire for a comparison of init
> > systems.
> 
> How on earth would anybody be able to make a decision if there are no
> comparisons between the alternatives available?

It could be as simple as «the most popular/the one which people actually
ship units/jobs for is the one we'll move to».

> [...] This could be a useful GSoC task.

Given there's no code to write in such a report, I don't think it'd be
appropriate for gsoc.

> This would be much more intersting than writing a
> systemd-to-initscript converter.

This I disagree with, Debian doesn't work by people sitting down,
writing papers and then agreeing on a course of action.  Debian works,
mostly, by people putting in effort and then documenting how others can
solve the same or similar problems.

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

Re: a good "license your software" how-to for upstream developers ?

[Simon Paillard]

Hi,

On Wed, Mar 21, 2012 at 11:39:26PM +0100, Jérémy Lal wrote:
> i find it difficult and time-consuming to explain, with limited vocabulary
> (english is not my mother tongue), to an upstream developer that his tarball
> is not properly licensed.
> For example i've seen software that was intended to be free, released without
> any license, or with missing license on some files, bundled dependencies, or
> pictures, or even worse with a modified adhoc license.
> I find it very very hard to find the right words to explain whatever is wrong
> with those, and so, i wonder if there is some clear and concise documentation
> about how to properly license a free software, targeted at upstream 
> developers.

Maybe http://wiki.debian.org/UpstreamGuide#Licenses ?
 

-- 
Simon Paillard


-- 
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/20120321231526.gi7...@glenfiddich.mraw.org

Bug#664975: ITP: indigo -- Organic Chemistry Toolkit

[Michael Banck]

Package: wnpp
Severity: wishlist
Owner: Debichem Team 


* Package name: indigo
  Version : 1.0.0
  Upstream Author : GGA Software Services LLC
* URL : http://ggasoftware.com/opensource/indigo
* License : GPLv3
  Programming Lang: C++, Java, Python
  Description : Organic Chemistry Toolkit

  Indigo is a C++ based organic chemistry and cheminformatics software
  environment.  Features Include:
  .
   * Molecule and reaction rendering including SVG support
   * Automatic layout for SMILES-represented molecules and reactions
   * Canonical (isomeric) SMILES computation.
   * Exact matching, substructure matching, SMARTS matching.
   * Matching of tautomers and resonance structures.
   * Molecule fingerprinting, molecule similarity computation.
   * Fast enumeration of SSSR rings, subtrees, and edge sugraphs.
   * Molecular weight, molecular formula computation.
   * R-Group deconvolution and scaffold detection. 
   * Computation of the exact maximum common substructure for an
 arbitrary amount of input structures
   * Combinatorial chemistry
   * Plugin support in the API
  .
  File formats Indigo support include MDL Mol, SDF, RDF, CML, SMILES and
  SMARTS.



-- 
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/20120321233619.ga4...@nighthawk.chemicalconnection.dyndns.org

Re: On init in *Debian*

[Michael Biebl]

On 21.03.2012 18:23, Allison Randal wrote:
> I recall this as one of the key differences: systemd is tightly coupled
> to the Linux kernel, while upstart is not. I was curious, so asked Scott
> James Remnant (upstart's creator), and he says it wouldn't be much
> effort to port upstart to kFreeBSD and Hurd.

The only major difference I see between systemd and upstart in term of
using Linux specific features, is systemd using cgroups.
Someone suggested that jails offer similar functionality on (k)freebsd.

Other then that, see the list [1] Scott posted some years ago, about
upstart using Linux specific features. This matches many of the features
systemd is using (aside from ptrace).

Where do you see upstart being *more* portable then systemd?

> 
> It would be informative to try the port. Treat it as a pilot project,
> see how far we can get in a short period of time. Debian has people with
> extensive experience in porting software to kFreeBSD and Hurd. If a
> couple of them are interested, we can connect them with with a couple of
> the upstart core developers and it could move quite quickly.

We tried to kick-start this port 3 years ago [1]

Unfortunately nothing has happened since then. I'm not sure, why the
effort to get an upstart port, failed.

Cheers,
Michael

[1] http://lists.debian.org/debian-bsd/2009/07/msg00122.html

-- 
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

debian/rules VS debian/copyright.

[Mike Mestnik]

I'm really a horrible person and I'm excellent at writing files like
debian/rules. From my perspective it's perfectly clear that a simple
tool designed to write perfect debian/rules files would have no chance
at writing a debian/copyright file. I understand that for decades there
has been a large group of hard working individuals that excel at writing
both.

I'd like to point out a need, and a desire on my part, for this to change.

I've been told that in order to write a good debian/copyright one must
have interment knowledge of a package and therefore be part of the
packaging team. I fail to see how the two relate, there is a lot more
that goes into a package then just the debian/copyright and unlike the
debian/rules it stands alone as it doesn’t interface with any other part
of the Debian Package, excepting that the original source is not part of
the Debian Package(at least in this instance).

Both files interface with the original source, but that's where the
similarities end.

I've also been told that having a single maintainer responsible for the
package as a whole is a good idea. I say one can easily split technical
and legal responsibility without the need for any gray lines. Doing so
reduces the knowledge base, an important part of finding the right ppl.
Allowing for more knowledgeable technical writers, like myself, to write
excellent packages and debian/rules files further improving the quality
of Debian.

1. I see a clear benefit.
2. I see a long road ahead.
3. I see an eventual finish where Package Maintainers and Helpers can
either focus on debian/rules or debian/copyright without the need to be
familiar at all with the other.

I offer up this edit for your review. I understand many might hate and
oppose the idea of splitting the two.

Thank you.

Index: english/intro/help.wml
===
RCS file: /cvs/webwml/webwml/english/intro/help.wml,v
retrieving revision 1.11
diff -u -r1.11 help.wml
--- english/intro/help.wml  11 Apr 2010 13:38:53 -  1.11
+++ english/intro/help.wml  22 Mar 2012 00:54:17 -
@@ -1,7 +1,9 @@
 #use wml::debian::template title="How can you help Debian?"
 
-If you are considering helping in the development of Debian GNU/Linux
-there are many areas in which both experienced and inexperienced users can 
assist:
+As a "Net-New" User
+
+New users can start right away, even with out installing or intending
+to use Debian.  Though it's a good idea to at least try it once.
 
 # TBD - Describe requirements per task?
 # such as: knowledge of english, experience in area X, etc..
@@ -14,13 +16,34 @@
 the bugs associated with packages you use and provide further
 information, if you can reproduce the issues described in them.
 
-# TBD - link to users mailing lists
-# Translators, link directly to the translated mailing lists and provide
-# a link to the IRC channel in the user's language
-If you are an experienced user you can help other users through 
-the http://lists.debian.org/";>user mailing lists or
-by using the IRC channel #debian.  For more information on support 
options
-and available sources read the support 
pages.
+Help Debian keep track of your favorite applications in the
+Work-Needing and Prospective Packages 
lists.
+
+# TBD - favorite features
+# Currently I'm unaware of a place to suggest "Better support for socks5"
+# 
+
+You can help with the development of the public face of Debian and
+contribute to the website or by 
+helping with the organisation of events
+worldwide.
+
+You can donate equipment and services to 
the Debian project so that 
+either its users or developers can benefit from them.  We are in constant 
search
+for mirrors worldwide our users can rely on and
+auto-builder systems for our porters.
+
+Help Debian promoting itself by talking about it and demonstrating it to 
others.
+
+
+
+Debian Labor
+
+Debian is always looking for help and there are some areas where just being
+a worm body ready to learn new things is the perfect starting place.
+
+
 
 # TBD - link to translators mailing lists
 # Translators, link directly to your group's pages
@@ -33,6 +56,25 @@
 language.  For more information read the Internationalisation pages.
 
+You can help writing copyright definitions for package maintainers in need.
+Best place to find one is
+http://mentors.debian.net/";>mentors.debian.net.
+
+
+
+Debian Development
+
+If you are considering helping in the development of Debian GNU/Linux
+there are many areas in which both experienced and inexperienced users can 
assist:
+
+# TBD - link to users mailing lists
+# Translators, link directly to the translated mailing lists and provide
+# a link to the IRC channel in the user's language
+If you are an experienced user you can help other users through
+the http://lists.debian.org/";>user mailing lists or
+by using the IRC channel #debian. For more information on support 
options
+and available sources read the support pages.
+
 You can h

Bug#664979: ITP: m2vrequantiser -- MPEG-2 streams requantization

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: m2vrequantiser
  Version : 1.1
  Upstream Author : Martin Wimpress
* URL : https://launchpad.net/m2vrequantiser
* License : GPL
  Programming Lang: C
  Description : MPEG-2 streams requantization

 This package provides m2vrequantiser, a tool to requantize
 MPEG-2 streams without recompressing. M2VRequantiser
 accepts raw MPEG2 video data (not VOB) from standard
 input and writes the recompressed frames to standard output.
 .
 m2vrequantiser represents a good replacement for tcrequant,
 an obsolete utility provided by some versions of the transcode
 suite.



-- 
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/20120322010654.3480.8546.reportbug@alessio-laptop

Re: debian/rules VS debian/copyright.

[Jonathan Yu]

Hi Mike,

On Wed, Mar 21, 2012 at 9:00 PM, Mike Mestnik wrote:

> I say one can easily split technical
> and legal responsibility without the need for any gray lines.
>

While I am certainly not opposed to your idea in principle - that everyone
has something to contribute (including non-programmers) to Debian's
continued success - I think that for most packages, the problem would be
logistical.

>From my experience working with the Debian Perl Group as a contributor but
not a Debian Developer, our workflow works something like this:

1. An interested party commits desired changes with corresponding
debian/changelog updates to the team repository

2. The Package Entropy Tracker notices the change, and flags it as Pending
Upload

3. A Debian Developer reviews the package and provides sponsorship
(uploading the work on behalf of the original contributor) if applicable,
or requests further changes

When it comes to copyright and licensing information, which is typically a
matter of looking through the accompanying documentation and leaving
appropriate notes in debian/copyright, it is typically a small job that is
done along with the rest of the packaging process. One nice way of doing a
quick spot check is using "grep -ir copyright ." to find all instances of
the word "copyright" in the source files. Logistically, requiring
developers to wait for an external party to work on copyright information
(which typically doesn't take too long in my experience) would
significantly slow down at least the Debian Perl Group's ability to process
and upload packages.

When it comes to translations, which I think is an area that recieves much
more non-developer attention than debian/copyright files, the logistical
issue still arises - but since we don't all write all of the languages in
existence, we often have no choice but to seek the assistance of interested
parties.

However, all that being said, I think that Debian can benefit from
interested parties assisting with copyright audits. We certainly have a lot
of metadata and a lot of code in the various Debian repositories - but how
accurately does that metadata (e.g. license and copyright information)
reflect the reality?

Moreover, there are a lot of open bug reports where we are blocked on an
ITP due to incomplete or missing copyright/licensing information - it would
be nice to have more eyes to look over these bugs, forward the information
upstream where appropriate, and follow up on open bug reports
(unfortunately, of which, there are many).

To sum up, the two places I see non-developer assistance being beneficial
to the Debian project (in the context of copyright and licensing
information) are:

1. Auditing of copyright/licensing information: ensure that the metadata
stored in debian/copyright is correct. This can be very difficult to do as
sometimes code is taken from other sources by upstream developers without
attribution.

2. Following up on bugs related to copyright/licensing information: for
cases where an ITP/RFP has been filed, but where copyright information is
not clear from the source data, file a bug report with the upstream
developers, or alternatively, ping the upstream developers in case the bug
has been overlooked. Possibly spend some time investigating alternative bug
trackers that the upstream developers may use instead, or their personal
e-mail addresses.

Cheers,

Jonathan

Re: debian/rules VS debian/copyright.

[Mike Mestnik]

On 03/21/12 20:36, Jonathan Yu wrote:
> Hi Mike,
>
> On Wed, Mar 21, 2012 at 9:00 PM, Mike Mestnik  > wrote:
>
> I say one can easily split technical
> and legal responsibility without the need for any gray lines.
>
>  
> While I am certainly not opposed to your idea in principle - that
> everyone has something to contribute (including non-programmers) to
> Debian's continued success - I think that for most packages, the
> problem would be logistical.
>
> From my experience working with the Debian Perl Group as a contributor
> but not a Debian Developer, our workflow works something like this:
>
> 1. An interested party commits desired changes with corresponding
> debian/changelog updates to the team repository
>
> 2. The Package Entropy Tracker notices the change, and flags it as
> Pending Upload
>
> 3. A Debian Developer reviews the package and provides sponsorship
> (uploading the work on behalf of the original contributor) if
> applicable, or requests further changes
>
> When it comes to copyright and licensing information, which is
> typically a matter of looking through the accompanying documentation
> and leaving appropriate notes in debian/copyright, it is typically a
> small job that is done along with the rest of the packaging process.
> One nice way of doing a quick spot check is using "grep -ir copyright
> ." to find all instances of the word "copyright" in the source files.
> Logistically, requiring developers to wait for an external party to
> work on copyright information (which typically doesn't take too long
> in my experience) would significantly slow down at least the Debian
> Perl Group's ability to process and upload packages.
>
> When it comes to translations, which I think is an area that recieves
> much more non-developer attention than debian/copyright files, the
> logistical issue still arises - but since we don't all write all of
> the languages in existence, we often have no choice but to seek the
> assistance of interested parties.
>
> However, all that being said, I think that Debian can benefit from
> interested parties assisting with copyright audits. We certainly have
> a lot of metadata and a lot of code in the various Debian repositories
> - but how accurately does that metadata (e.g. license and copyright
> information) reflect the reality?
>
> Moreover, there are a lot of open bug reports where we are blocked on
> an ITP due to incomplete or missing copyright/licensing information -
> it would be nice to have more eyes to look over these bugs, forward
> the information upstream where appropriate, and follow up on open bug
> reports (unfortunately, of which, there are many).
>
> To sum up, the two places I see non-developer assistance being
> beneficial to the Debian project (in the context of copyright and
> licensing information) are:
>
> 1. Auditing of copyright/licensing information: ensure that the
> metadata stored in debian/copyright is correct. This can be very
> difficult to do as sometimes code is taken from other sources by
> upstream developers without attribution.
>
This is where I'm stuck on my package not so much the specific issue of
a lack of attribution, but the process of auditing the
copyright/licensing information.  Thanks to your input I now can see my
path vary clearly.

I'll take a bit to reflect this re-wording and apply both of these
suggestions to my recommended patch.

Thank you!

> 2. Following up on bugs related to copyright/licensing information:
> for cases where an ITP/RFP has been filed, but where copyright
> information is not clear from the source data, file a bug report with
> the upstream developers, or alternatively, ping the upstream
> developers in case the bug has been overlooked. Possibly spend some
> time investigating alternative bug trackers that the upstream
> developers may use instead, or their personal e-mail addresses.
>
> Cheers,
>
> 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/4f6a8dc7.7020...@mikemestnik.net

FictionCity.NET - The Social Network for Artists

[FictionCity.net]

¡Hola!


fran carras quiere invitarte a unirte a la red mundial más importante de 
artistas.
Podrás subir tus trabajos y obras para que organizaciones y artistas conozcan 
tu talento.

http://www.fictioncity.net/profile/594168

¡Regístrate en FictionCity.NET hoy!

FictionCity.NET
www.FictionCity.NET
i...@fictioncity.net


Para desuscribirte de la lista, ingresa esta dirección: 
http://www.fictioncity.net/invitation/optout?eMail=debian-devel%40lists.debian.org&key=96aa8a95638ee123d7bf36f5173c95fc&l=es

Re: On init in *Debian*

[Philip Hands]

On Wed, 21 Mar 2012 15:54:40 +0100, Josselin Mouette  wrote:
> Le mercredi 21 mars 2012 à 13:39 +, Ian Jackson a écrit :
> > Marco d'Itri writes ("Re: On init in *Debian*"):
> > > On Mar 21, Thomas Hood  wrote:
> > > > The proposal to drop support for kernels other than Linux has already
> > > > been adequately aired.  For the sake of focus I'd like to make the
> > > > assumption in this thread that support for alternative kernels and
> > > > architectures will not be dropped on account of the choice of init
> > > > system alternative.
> > >
> > > I do not believe this to be a reasonable assumption.
> > 
> > Yes, we know, but as Thomas says, that view has already been
> > adequately aired.  You don't need to post every time to contradict
> > it.
> 
> Just because a few vocal people disagree with it, doesn’t mean there is
> consensus against it.

That is indeed true ... as is the inversion of that thought.

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


pgp6NObv5WvdH.pgp
Description: PGP signature

Re: debian/rules VS debian/copyright.

[Charles Plessy]

Le Wed, Mar 21, 2012 at 08:00:06PM -0500, Mike Mestnik a écrit :
> I'm really a horrible person and I'm excellent at writing files like
> debian/rules. From my perspective it's perfectly clear that a simple
> tool designed to write perfect debian/rules files would have no chance
> at writing a debian/copyright file. I understand that for decades there
> has been a large group of hard working individuals that excel at writing
> both.
> 
> I'd like to point out a need, and a desire on my part, for this to change.
> 
> I've been told that in order to write a good debian/copyright one must
> have interment knowledge of a package and therefore be part of the
> packaging team. I fail to see how the two relate, there is a lot more
> that goes into a package then just the debian/copyright and unlike the
> debian/rules it stands alone as it doesn’t interface with any other part
> of the Debian Package, excepting that the original source is not part of
> the Debian Package(at least in this instance).

Dear Mike,

for copyright summaries and all other aspects of Debian packaging, proofreading
is always appreciated.  I have proposed in the past a peer review system for
copyright files.  Perhaps it can fit your needs, but you will have to make it
popular.

  http://wiki.debian.org/CopyrightReview

In an ideal world, it would be trivial to write a Debian copyright file because
the upstream sources would already contain a perfect documentation of all
the copyright and license notices.  The work that is made in Debian can
be made more widely useful if forwarded and accepted upstream; this is also
an area where anybody can help.

Importantly, the check for copyright and license notices is necessary at each
upload.  Reviewing existing files and reporting inaccuracies in our BTS will
also be helpful, especially when the inaccuracy is critical.  It is not
frequent at the scale of one package, but at the level of our distribution it
definitely happens that upstream authors change the license of their works or
add non-free files without explicitely documenting it.

Lastly, you can also contribute by facilitating distribution-wide work on
copyright matters, for instance by writing tools that leverage machine-readable
copyright formats, or setting up services similar to what source.debian.net
provided using OpenGrok.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120322035600.gb14...@falafel.plessy.net

B2G security model (debian package management recommended) - help and advice needed

[Luke Kenneth Casson Leighton]

folks, hi,

please take a deep breath before reading.

i'm keenly aware of the view that many people hold of me in debian.
that i'm even bringing something to your attention and asking for your
help (not for me, personally) should therefore tell you a lot more
than needs to actually be said.

i'm presently coming up to nine hours of continuous non-stop typing
(just today) to deal with something on the B2G developer mailing
lists: the security model, and it's getting to the point where i'm i
serious need of some highly-technical (as well as social) assistance.

your patience greatly appreciated whilst i explain.

B2G is a new operating system where the Gecko web front-end doubles up
(triples up?) as the window manager as well as the applications
"runner".  they started from the android codebase, ripped out java,
ripped out webkit, dropped gecko in place using OpenGL _directly_
writing to the framebuffer, and then went, "ok, now we got the basics,
let's make this work".

as a concept, i find this both fascinating and exciting.  the
resources of the mozilla foundation with the non-profit-orientated
motivation to create an open alternative to google's android?
fantastic!

by the time they're done, there will be *another* FOSS operating
system out there - one with the potential to reach a hundred million
units or more, through mass-volume sales world-wide, via numerous
telephone companies.  applications could be developed by people that
could take off just as fast as any android or iphone application:
potentially millions of downloads per day if an app becomes highly
popular.

and the whole thing *won't* be tied to a particular vendor, or to a
profit-maximising company.  the mozilla foundation is a non-for-profit
organisation, so has the potential to take into consideration aspects
that are *not* over-ridden by profit maximisation (such as "increasing
revenue stream").

i have every confidence in the mozilla foundation to deliver the goods
on the U.I, on the apps example development, and much more besides.

what's of fundamental and deep concern to me is their ability to
comprehend the security implications of what they're doing.

and, you *know* me - it should come as absolutely no surprise to any
of you to learn that even the mozilla foundation is deploying
increasingly-hostile censorship measures to prevent me from
communicating with them.

ok, you can laugh now.  go on.  yeah, i know.  i did it again.

happy now? :)

but seriously: it should be reasonably clear as to why i've persisted
with this *despite* increasing resistance, and it should speak volumes
that i'm asking (requesting NOT demanding) - publicly - for people to
wander over and take (CONSIDER taking) a look at the security
discussion taking place.

why am i asking [requesting-not-demanding] that _you_ - debian
developers - get [CONSIDER getting] involved?  it's because the
application distribution model that i know best (that will also fulfil
the requirements) is... yep, debian.

why i am so deeply concerned about the discussion on the b2g-dev
mailing list has nothing to do with me, but has everything to do with
what the people in the mozilla foundation - those actively involved in
the b2g decision-making process - are recommending be used for
application distribution. it's SSL!

now, i know you know how debian package management works.  imagine if
someone on a debian list somewhere went "hey guys!  you know that
infrastructure you use to distribute debian packages?  i've got a
great idea for a replacement for the system you've been establishing
and refining for almost 20 years, it's called SSL!"

now that you've picked yourself up off the floor, either from shock or
from laughing so hard you couldn't stand upright, you may be wondering
if i've made some sort of hilarious techie joke.  i assure you i
haven't.

what _would_ be funny though would be if, after reading this, someone
who *really* knows how SSL well and truly works actually said "yes,
here's a workable technical solution which uses SSL and delivers the
goods, i did a complete paper on it, it easily scales to the numbers
you describe, but didn't mention it here on the debian lists ever
because they already have a fully-working solution, and i didn't wish
to make an ass of myself like you do on a regular basis, mr lkcl".

then i would be very very happy that the joke was entirely on me.

... but my instincts and experience with SSL (so far) and with the
debian package management system (so far), tell me otherwise (to
date).

the problem is: i've rather comprehensively fucked up relations
with... i think it's now about... ooo, getting on for 30+ people in
mozilla, who are getting so incensed that i'm quotes telling them what
to do quotes that in true terry pratchett style it's going beyond
annoying, gone out the other side and is bordering on becoming funny.

i think saying "i know there are many of you who wish i was dead so
that i'd stop typing" probably did it, this time.

anyway, eno