Re: Bug#660842: ITP: python-gnupg -- python wrapper for the gnupg command

[Evgeni Golov]

On Mon, Feb 27, 2012 at 09:06:51AM +0100, Elena ``of Valhalla'' wrote:
> On 2012-02-26 at 00:26:14 +0100, Evgeni Golov wrote:
> > What's wrong with [...]
> > What are the benefits of python-gnupg? The homepage doesnt tell any,
> > neither does the description :)
> 
> Mostly the documentation: python-gnupg's interface is fully documented 
> with docstrings (with examples checked in the test suite) and 
> it has an in-depth manual/tutorial[1].
> 
> among the other python interfaces to gnupg functionality, 
> python-gnupginterface seems to be the one documented best 
> in the module, but the last release was in 2002 and the 
> homepage[2] features broken links both to the mailing list 
> and documentation.
> The docstrings for both python-gpgme and python-pyme are 
> both poor, and in the case of pyme the homepage just refers 
> to the pgpme docs, which are complete, but of course based on the 
> slighty different conventions of the C library.

Hm, okay.
I must admit I have used both pyme and pygpgme with great success, but 
relying on the gpgme docs, as these are quite complete and apply quite 
well to the Python versions.

Another question I would like to raise is the performance -- 
python-gnupg seems to be a command line wrapper around gnupg, thus 
having to fork() heavily -- does it affect processing of data?

regards
Evgeni

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20120227082304.ga3...@dorei.kerker.die-welt.net

Re: Enabling package installation for non-root users

[Josselin Mouette]

Le lundi 27 février 2012 à 05:19 +0100, Sebastian Heinlein a écrit : 
> Am Donnerstag, den 23.02.2012, 18:46 +0200 schrieb Timo Juhani
> Lindfors: 
> > Josselin Mouette  writes:
> > > (We even have a patch to allow only a subset of packages but it is
> > > unfortunately a bit too hackish.)
> > 
> > Would be really nice to have some standard sets available (think
> > "browser extensions", "command-line tools that ship no services or suid
> > binaries"). I'd certainly let my desktop users install these without
> > having to ask me or having to install them manually to their $HOME..
> 
> Do you need a whitelist or a blacklist?

This should clearly be a whitelist. I don’t think there’s real use for a
blacklist, it is too dangerous.

> Do you want to limit all installations via aptdaemon or only for a set
> of users?

This functionality is already available through the PolicyKit
configuration. Maybe you can add two levels of authorization, one for
installing any package, the other one for installing the subset.

> We could limit the allowed packages by e.g. debtags, section and package
> names.

Yes please!
And I can has limitations by repository and priority too?

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/1330331524.3297.1748.camel@pi0307572

Re: Bug#660842: ITP: python-gnupg -- python wrapper for the gnupg command

[Elena ``of Valhalla'']

On 2012-02-26 at 00:26:14 +0100, Evgeni Golov wrote:
> What's wrong with [...]
> What are the benefits of python-gnupg? The homepage doesnt tell any,
> neither does the description :)

Mostly the documentation: python-gnupg's interface is fully documented 
with docstrings (with examples checked in the test suite) and 
it has an in-depth manual/tutorial[1].

among the other python interfaces to gnupg functionality, 
python-gnupginterface seems to be the one documented best 
in the module, but the last release was in 2002 and the 
homepage[2] features broken links both to the mailing list 
and documentation.
The docstrings for both python-gpgme and python-pyme are 
both poor, and in the case of pyme the homepage just refers 
to the pgpme docs, which are complete, but of course based on the 
slighty different conventions of the C library.

[1] http://packages.python.org/python-gnupg/
[2] http://py-gnupg.sourceforge.net/

-- 
Elena ``of Valhalla''


-- 
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/20120227080651.gc29...@home.home.trueelena.org

Re: upstart: please update to latest upstream version

[James Hunt]

On 21/02/12 22:57, Michael Biebl wrote:

On 21.02.2012 21:25, Russ Allbery wrote:


The most likely way forward is some period where either can be used and we
see how things shake out.  Unfortunately, neither currently supports
kFreeBSD.  The upstart upstream seems more amenable to doing so than the
systemd upstream.


Afaics both upstream projects take more or less the same position on
that matter.

At least Scott [1] was clear that he didn't intend to merge any
non-Linux specific code and that a kfreebsd port would basically have to
be maintained as a fork/branch.

Has this position changed for upstart now that James is de-facto the new
upstream maintainer?

Michael

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

Firstly, when talking about Upstart we need to make a clear distinction between Upstart itself and 
the library it relies upon heavily - the NIH Utility library [1].


I am personally more than happy for others to work on porting Upstart to other non-Linux platforms. 
However, I suspect the majority of the work in getting Upstart running on for example a FreeBSD 
kernel would be in porting NIH to that platform. Certainly, Like Scott, I dislike code littered with 
#ifdefs so any approach adopted would need to retain Upstart and NIH's code clarity and elegance. 
For Upstart itself, a compromise approach might be to create an 'arch/' directory like the kernel 
uses. However, for NIH, we really need Scotts input as he is the maintainer.


If we can find an approach acceptable to all parties, there is another important point to bear in 
mind: the tests. Scott and more latterly myself have spent a huge amount of effort maintaining the 
existing tests and writing new tests as features are added, to ensure expected system behaviour. I 
feel strongly that such tests are imperative for large software projects like this, particularly a 
system-critical one such as the init deamon. For current test statistics, see:


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

With respect to Upstart, as an absolute minimum I would want a "sign-off" stating all the tests had 
passed successfully on atleast the platform the patch applies to before considering accepting any 
patches into the upstream lp:upstart branch [2].


I've attached a list of library and function calls for both Upstart and NIH for those interested in 
assessing the size of the porting effort.


Kind regards,

James.

[1] - https://launchpad.net/libnih
[2] - https://launchpad.net/upstart

--
James Hunt

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


upstart+nih_calls.tgz
Description: application/compressed-tar

Re: upstart: please update to latest upstream version

[Riku Voipio]

On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
> > I have. Not on debian, but on debianish system with dash. And the result
> > was that shellscripts are indeed the bottleneck.  We still did convert to
> > upstart since we believed it would allow us to cut down the amount of
> > shell scripts.  The event based architecture however forced much more
> > shell scripting[1] that made the boot time improvement much less than
> > hoped.
 
> Interesting to know, thanks.  Was this done in a head-to-head comparison
> with the systemd "no shell" boot?

Systemd was not at ready that time.. Every exec has a price, and if a upstart
stanza has a pre-start and post-start script, that is already two shell execs.
Any command in shell script that is not a shell builtin is more execs. In this
sense dash is worse, as it has less builtins that bash. for example sleep is
not a builtin...

The other factor of shell scripts is psychological. Since shell scripts are
so easy to modify, people tend to litter them with unneccesary checks,
settings, workarounds and other spagethi. 

> > [1] stuff like this:
> 
> > -snip-
> > post-start script
> > # wait until daemon is ready
> > timeout=6
> > while [ ! -e /var/run/cups/cups.sock ]; do 
> > sleep 0.5
> > timeout=$((timeout-1))
> > -snip-
> 
> Oh dear, you've managed to find the worst upstart job in Ubuntu ;)

> If you have other stuff *like* this, I'd be interested to see it.  That
> particular upstart job is needed only because of peculiarities of how cups
> starts up.

Well that was a common development idiom with upstart when our developers
realized that neither "on started" or "on starting" did what they wanted...
Some of them were got rid of by changing upstream code to emit a signal when
really ready.

I just grepped an Ubuntu system to see if there were similar cases in Ubuntu as 
well ;)

Riku


-- 
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/20120227102425.ga28...@afflict.kos.to

Re: A few observations about systemd

[Bernhard R. Link]

* Uoti Urpala  [120226 20:20]:
> If someone complained about a nontrivial s390-specific problem in a
> context where I was upstream, I'd likely ignore him. In the Debian
> context, people other than porters should not be obligated to do
> significant work to resolve problems specific to fringe architectures,

It's the task of a maintainer to fix their packages. It's the task of
the porters to help the maintainers with this.

While there might be some problems originating from some architecture,
but most problems you will see and people claim to be "problems specific
to fringe architectures" are actual bugs in the program you just do not
*yet* see on your usual pet architectures. And some more because the
program is just doing some very narrowing assumptions.

Imagine how long amd64 would have taken, if people had not had years
to fix all those 64 bit bugs on alpha first (Which never really got
a mainstream architecture and where it was used was quite server-only.
Who would have guessed that fixing games to run there would have had
benefits in a so soon future?)



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

Re: upstart: please update to latest upstream version

[Matthias Klumpp]

Maybe interesting to read in this upstart vs. systemd vs. sysvinit
discussion is the comparison of these three init systems:
http://0pointer.de/blog/projects/why.html
Of course, Lennart Poettering did this, but the points mentioned are
valid. (Although the list is a bit outdated, at least on upstart's
side)
Cheers,
Matthias Klumpp

2012/2/27 Riku Voipio :
> On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
>> > I have. Not on debian, but on debianish system with dash. And the result
>> > was that shellscripts are indeed the bottleneck.  We still did convert to
>> > upstart since we believed it would allow us to cut down the amount of
>> > shell scripts.  The event based architecture however forced much more
>> > shell scripting[1] that made the boot time improvement much less than
>> > hoped.
>
>> Interesting to know, thanks.  Was this done in a head-to-head comparison
>> with the systemd "no shell" boot?
>
> Systemd was not at ready that time.. Every exec has a price, and if a upstart
> stanza has a pre-start and post-start script, that is already two shell execs.
> Any command in shell script that is not a shell builtin is more execs. In this
> sense dash is worse, as it has less builtins that bash. for example sleep is
> not a builtin...
>
> The other factor of shell scripts is psychological. Since shell scripts are
> so easy to modify, people tend to litter them with unneccesary checks,
> settings, workarounds and other spagethi.
>
>> > [1] stuff like this:
>>
>> > -snip-
>> > post-start script
>> >     # wait until daemon is ready
>> >     timeout=6
>> >     while [ ! -e /var/run/cups/cups.sock ]; do
>> >         sleep 0.5
>> >         timeout=$((timeout-1))
>> > -snip-
>>
>> Oh dear, you've managed to find the worst upstart job in Ubuntu ;)
>
>> If you have other stuff *like* this, I'd be interested to see it.  That
>> particular upstart job is needed only because of peculiarities of how cups
>> starts up.
>
> Well that was a common development idiom with upstart when our developers
> realized that neither "on started" or "on starting" did what they wanted...
> Some of them were got rid of by changing upstream code to emit a signal when
> really ready.
>
> I just grepped an Ubuntu system to see if there were similar cases in Ubuntu 
> as well ;)
>
> Riku


--
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/CAKNHny_-o+tT2ShAvJxts63gi5L_i=qb8mqxtr-prheg2fj...@mail.gmail.com

Re: upstart: please update to latest upstream version

[Samuel Thibault]

Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> discussion is the comparison of these three init systems:
> http://0pointer.de/blog/projects/why.html
> Of course, Lennart Poettering did this, but the points mentioned are
> valid. (Although the list is a bit outdated, at least on upstart's
> side)

What is Lennart's point?  That it does everything that are
traditionnally done in other packages?  I don't see what point that
makes.  Just an instance: "Console and keyboard setup".  Great, yet
another set of keymaps?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120227165146.ga14...@type.bordeaux.inria.fr

Bug#601455: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo

[Jonathan Nieder]

clone 601455 -1
retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via 
/etc/default/foo
quit

peter green wrote:

> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it altogether is not really reasonable)
> I think the original bug of being unable to stop
> a dameon after disabling it in /etc/default still needs to be fixed.

You're right.  Sorry for my heavy-handed response before.

Would there be any easy way to get a list of affected packages?
By grepping for ENABLE and DISABLE in /etc/init.d and looking at the
context, I find the following packages have this problem in my local
(pretty small) installation:

  aiccu 20070115-14.1
  bootlogd from initscripts 2.88dsf-22
  rsync 3.0.9-1



-- 
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/20120227165322.GA14108@burratino

Processed: Re: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> clone 601455 -1
Bug#601455: multiple, annoyingly different ways to disable an init script
Bug 601455 cloned as bug 661496.

> retitle 601455 can't stop daemon using /etc/init.d/foo stop when disabled via 
> /etc/default/foo
Bug #601455 [general] multiple, annoyingly different ways to disable an init 
script
Changed Bug title to 'can't stop daemon using /etc/init.d/foo stop when 
disabled via /etc/default/foo' from 'multiple, annoyingly different ways to 
disable an init script'
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
601455: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601455
-1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.133036161912238.transcr...@bugs.debian.org

Re: description of "general" pseudo-package is misleading (leads people to use it as a catch-all)

[Jonathan Nieder]

(moving Mikko to bcc to avoid spamming him)
Don Armstrong wrote:

> retitle 661241 vlc probably using wrong sound output by default (but not 
> clear from reporter)
> reassign 661241 vlc
[...]
> Mikko Koho: I'm guessing as to what your problem is, but you're going
> to have to provide more information in order for anyone to address it
> properly. Please indicate which version of vlc you are using, which
> sound output it is using, etc.

Thanks, Don, and sorry about my (lazy and) misguided response.

There were once many bugs in the "the font suddenly became too big"
style misfiled against "general" that no one was addressing which hid
the actual general problems that the developer body at large could be
working on.  I see no easy way to solve that.

When it is obvious which package is relevant, that's great ---
someone can forward the report to the maintainer and reassign it.

When a report has an unreachable reporter and so little detail that
forwarding it would not be useful, that's fine, too --- a friendly
person can close the bug with a pointer about how to prepare a more
detailed report in case someone interested finds it.

The difficult cases are in between: carrying out the back-and-forth to
get such details as what action precipitated the problem, what result
was expected, what happened instead, and how the difference indicates
a bug, with debian-devel cc-ed, does not seem particularly productive.
If the "general" package did not exist, such reports would be quickly
redirected to debian-user with a goal of finding an appropriate
maintainer who could take responsibility for fixing the problem.  What
is an appropriate equivalent when receiving reports through the BTS?

I like to imagine that clarifying whether assigning a bug to the
"general" means "I don't know" or "I suspect fixing this bug will
require touching many packages" could help so these bugs are sent
somewhere appropriate in the first place.  Sane?

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/20120227172212.GI10740@burratino

Re: upstart: please update to latest upstream version

[Steve Langasek]

On Mon, Feb 27, 2012 at 05:45:14PM +0100, Matthias Klumpp wrote:
> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> discussion is the comparison of these three init systems:
> http://0pointer.de/blog/projects/why.html
> Of course, Lennart Poettering did this, but the points mentioned are
> valid. (Although the list is a bit outdated, at least on upstart's
> side)

It was out of date even at the time it was written.

To be fair, it also omits one of SystemD's greatest strengths:  Roman
numeral-compliant project naming.  System D is obviously way better than
System V.

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


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

[Matthias Klumpp]

2012/2/27 Samuel Thibault :
> Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
>> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
>> discussion is the comparison of these three init systems:
>> http://0pointer.de/blog/projects/why.html
>> Of course, Lennart Poettering did this, but the points mentioned are
>> valid. (Although the list is a bit outdated, at least on upstart's
>> side)
>
> What is Lennart's point?  That it does everything that are
> traditionnally done in other packages?  I don't see what point that
> makes.  Just an instance: "Console and keyboard setup".  Great, yet
> another set of keymaps?
No, "console and keyboard __setup__", he's not establishing another
keymap set, it's just the setup part.
And systemd is very modular, you can always split out parts you don't like.
I recently tried systemd on my machine, just to see how it works, and
I am really excited about it now :) System boot speed is *much* better
now, defining new services is absolutely trivial and working with
systemd just feels right(tm), at least to me. To be honest, I didn't
manage to get everything working, but I am not an init-system expert
and haven't tried to dig deeper there.
I also use upstart on my Kubuntu machine (well, it was default,
so...), but at time I very much prefer systemd. Of course, that's my
very own, personal opinion.
And, as Lennart already stated:

"I am listening. I mean, besides the really basic design decisions
Upstart has nothing that systemd hasn't. The reason for that among
other things is that I actually looked at Upstart, and added to
systemd everything I liked about it. But hey, I'd be really happy to
see Scott post a similar blog story, so that we can see the other side
of the medal."

I would really like to see that comparison from upstart's side too! :)
Regards,
Matthias Klumpp


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

Re: description of "general" pseudo-package is misleading (leads people to use it as a catch-all)

[Don Armstrong]

On Mon, 27 Feb 2012, Jonathan Nieder wrote:
> The difficult cases are in between: carrying out the back-and-forth
> to get such details as what action precipitated the problem, what
> result was expected, what happened instead, and how the difference
> indicates a bug, with debian-devel cc-ed, does not seem particularly
> productive.

> If the "general" package did not exist, such reports would be
> quickly redirected to debian-user with a goal of finding an
> appropriate maintainer who could take responsibility for fixing the
> problem.

http://www.debian.org/Bugs/Reporting already tells people to contact
-user if they are unable to determine which package their bug report
should be filed against. I suppose text could be added to reportbug to
mimic this... perhaps changing:

   Please enter the name of the package in which you have found a problem, or 
type 'other' to report a more general problem.

to 

   Please enter the name of the package in which you have found a problem, or 
type 'other' to report a more general problem.
   If you don't know what package the bug is in, please contact 
debian-u...@lists.debian.org for assistance.

[and the list can be changed as needed for l10n.]

> What is an appropriate equivalent when receiving reports through the
> BTS?

You start out by taking your best guess, and then prodding the bug
submitter(s) for more information.

When a bug wrongly gets assigned to general, that just means that a
much wider audience is reached, and someone needs to look at the bug,
and take their best guess as to the right package to assign it to, and
reassign it, hopefully guiding the bug reporter to provide more
information.

> I like to imagine that clarifying whether assigning a bug to the
> "general" means "I don't know" or "I suspect fixing this bug will
> require touching many packages" could help so these bugs are sent
> somewhere appropriate in the first place.

I suppose, but "General problems (e.g. "many manpages are mode 755")"
is pretty specific.

I suppose I could change it to general -- "Problems which affect many
packages (blah blah blah)".


Don Armstrong

-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
 -- Edmund Burke "Thoughts on the Cause of Present Discontents"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120227181106.gg30...@rzlab.ucr.edu

Re: upstart: please update to latest upstream version

[Steve Langasek]

On Mon, Feb 27, 2012 at 12:24:25PM +0200, Riku Voipio wrote:
> On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote:
> > > I have. Not on debian, but on debianish system with dash. And the result
> > > was that shellscripts are indeed the bottleneck.  We still did convert to
> > > upstart since we believed it would allow us to cut down the amount of
> > > shell scripts.  The event based architecture however forced much more
> > > shell scripting[1] that made the boot time improvement much less than
> > > hoped.

> > Interesting to know, thanks.  Was this done in a head-to-head comparison
> > with the systemd "no shell" boot?

> Systemd was not at ready that time.. Every exec has a price, and if a
> upstart stanza has a pre-start and post-start script, that is already two
> shell execs.  Any command in shell script that is not a shell builtin is
> more execs.  In this sense dash is worse, as it has less builtins that
> bash.  for example sleep is not a builtin...

No disagreement with any of that.  But how high is that price, in point of
fact?  If no one's measured it, then converting scripts to C programs to
avoid the added exec() calls is premature optimization.  If the only
comparison is between two different distros, you might find that your boot
time is higher for completely unrelated reasons (bug in a video driver?
handling of corner cases in one path but not the other, that impact the
reliability for that 1% of users it matters to?).

I would certainly welcome it if someone did profiling that showed whether
the shells are a bottleneck.  My own subjective experience is that this is
probably not the low-hanging fruit on a general-purpose distro, but if it
turns out that there are significant speed improvements to be had, we could
certainly look at moving more core startup functionality into C for upstart.

> The other factor of shell scripts is psychological. Since shell scripts are
> so easy to modify, people tend to litter them with unneccesary checks,
> settings, workarounds and other spagethi. 

One of the worst contributors to the use of 'script' in upstart jobs instead
of 'exec' is the need for backwards-compatibility with pre-upstart
/etc/default/* files.  The options here are all fairly poor:

 - ignore the admin's /etc/default settings when switching init systems
 - migrate any local changes to /etc/default into the upstart job at upgrade
   time, by editing a conffile in a maintainer script
 - keep sourcing /etc/default at runtime

I guess systemd has largely chosen option 1 (in part because there's a weird
view in the systemd community that these jobs belong upstream, so Debian
integration issues are entirely ignored).  For many upstart jobs in Ubuntu,
we've chosen option 3.  Which do you think is the right solution?  Are there
other options I haven't seen?

> > If you have other stuff *like* this, I'd be interested to see it.  That
> > particular upstart job is needed only because of peculiarities of how cups
> > starts up.
> 
> Well that was a common development idiom with upstart when our developers
> realized that neither "on started" or "on starting" did what they
> wanted...  Some of them were got rid of by changing upstream code to emit
> a signal when really ready.

Right, this requires a definition of "started" that's appropriate for the
service in question.  Socket-based activation would be another solution
here, but that might also require changing upstream code anyway.

FWIW, aside from this one bug affecting cups, I'm pretty sure that *any*
service for which upstart's "on started" is broken/racy is also broken/racy
in sysvinit.  The code really ought to be fixed upstream for everyone's
benefit.

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


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

[Samuel Thibault]

Matthias Klumpp, le Mon 27 Feb 2012 18:42:39 +0100, a écrit :
> 2012/2/27 Samuel Thibault :
> > Matthias Klumpp, le Mon 27 Feb 2012 17:45:14 +0100, a écrit :
> >> Maybe interesting to read in this upstart vs. systemd vs. sysvinit
> >> discussion is the comparison of these three init systems:
> >> http://0pointer.de/blog/projects/why.html
> >> Of course, Lennart Poettering did this, but the points mentioned are
> >> valid. (Although the list is a bit outdated, at least on upstart's
> >> side)
> >
> > What is Lennart's point?  That it does everything that are
> > traditionnally done in other packages?  I don't see what point that
> > makes.  Just an instance: "Console and keyboard setup".  Great, yet
> > another set of keymaps?
> No, "console and keyboard __setup__", he's not establishing another
> keymap set, it's just the setup part.
> And systemd is very modular, you can always split out parts you don't like.

Ok, that still does not make a point: we *already* have scripts to do
a lot of what is listed, so yet another implementation does not make a
point, to my mind.

Note: I'm not saying that systemd is bad, I'm just saying that the array
is completely unfair: yes, initscripts don't do a lot of that. Simply
because there is already software that do these.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120227181858.ga4...@type.famille.thibault.fr

Re: A few observations about systemd

[Uoti Urpala]

Bernhard R. Link wrote:
> While there might be some problems originating from some architecture,
> but most problems you will see and people claim to be "problems specific
> to fringe architectures" are actual bugs in the program you just do not
> *yet* see on your usual pet architectures. And some more because the
> program is just doing some very narrowing assumptions.

Yes, such bugs do exist. However, I think the benefit of testing on
other architectures to uncover such bugs has been exaggerated. Many of
the problems that end up taking the most time are toolchain issues
specific to the architecture. Typical free software projects already
have multiple known issues that actually affect people even on popular
architectures; ability to find one more thing that's in principle broken
is not particularly valuable. It's mainly the relatively simple projects
or projects with exceptional developer resources (like parts of the
kernel) where ability to find more bugs results in quality improvements
with any kind of consistency. Debugging things on architectures you
don't normally use, often remotely on unfamiliar systems, is likely to
be slow and not have a particularly good results/effort ratio.

Note that I'm not opposing having Debian on multiple hardware
architectures. But that's mainly because I think it doesn't necessarily
require major extra effort, not because I'd consider such hardware
support to be essential.

> Imagine how long amd64 would have taken, if people had not had years
> to fix all those 64 bit bugs on alpha first (Which never really got
> a mainstream architecture and where it was used was quite server-only.
> Who would have guessed that fixing games to run there would have had
> benefits in a so soon future?)

I'm not sure exactly how long more AMD64 support would have taken
without Alpha, but I think it would have become supported reasonably
fast in any case, and likely with substantially less overall effort than
by fixing issues as they come up through Debian Alpha builds. "First
upstream developer of a game gets an AMD64 machine and makes the game
run on it" is just inherently a lot more efficient than "Debian
maintainer forwards reports about game not working on Alpha".
Considering the introduction of AMD64 overall, I think Debian did a
pretty bad job - avoiding the fuck-ups in the introduction of the
architecture in Debian would have helped a lot more than the 64-bit
preparation with Alpha.

If you want to help the development of upstream projects in general,
there's an obvious thing that could use more resources: make sure that
the latest upstream code is always available in Debian unstable (or if
it's likely to cause breakage, at least in experimental), and don't let
the introduction of new upstream versions in unstable stop around
releases. Getting more feedback about changes quickly is a lot more
important than testing on unusual architectures.



-- 
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/1330375471.5387.174.camel@glyph.nonexistent.invalid

Re: upstart: please update to latest upstream version

[Uoti Urpala]

Steve Langasek wrote:
> If no one's measured it, then converting scripts to C programs to
> avoid the added exec() calls is premature optimization.  If the only

You keep repeating the same FUD. Again, avoiding shell is not just an
optimization, much less a premature one. Also, if I understand the
original poster correctly, this included cases where you would not have
needed any separate C program either with systemd.


> One of the worst contributors to the use of 'script' in upstart jobs instead
> of 'exec' is the need for backwards-compatibility with pre-upstart
> /etc/default/* files.  The options here are all fairly poor:
> 
>  - ignore the admin's /etc/default settings when switching init systems
>  - migrate any local changes to /etc/default into the upstart job at upgrade
>time, by editing a conffile in a maintainer script
>  - keep sourcing /etc/default at runtime
> 
> I guess systemd has largely chosen option 1 (in part because there's a weird
> view in the systemd community that these jobs belong upstream, so Debian
> integration issues are entirely ignored).  For many upstart jobs in Ubuntu,

The systemd view is that this configuration should be standardized
rather than every distro using a random different method. I don't think
that view is at all weird. "Debian integration issues are entirely
ignored" is again FUD - standardization does require some kind of
transition, but Debian has in no way been "ignored" here (and no this
standardization does not mean simply adopting the old Fedora setup or
anything like that).



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

Re: A few observations about systemd

[Goswin von Brederlow]

Uoti Urpala  writes:

> Bernhard R. Link wrote:
>> Imagine how long amd64 would have taken, if people had not had years
>> to fix all those 64 bit bugs on alpha first (Which never really got
>> a mainstream architecture and where it was used was quite server-only.
>> Who would have guessed that fixing games to run there would have had
>> benefits in a so soon future?)
>
> I'm not sure exactly how long more AMD64 support would have taken
> without Alpha, but I think it would have become supported reasonably
> fast in any case, and likely with substantially less overall effort than
> by fixing issues as they come up through Debian Alpha builds. "First
> upstream developer of a game gets an AMD64 machine and makes the game
> run on it" is just inherently a lot more efficient than "Debian
> maintainer forwards reports about game not working on Alpha".
> Considering the introduction of AMD64 overall, I think Debian did a
> pretty bad job - avoiding the fuck-ups in the introduction of the
> architecture in Debian would have helped a lot more than the 64-bit
> preparation with Alpha.

Just to give a timeframe here: After compiling the base packages and
build-essentials, setting up a repository on alioth and buildds
compiling the rest of Debian was a breeze. The number of build packages
for amd64 went from <5% to >95% of all packages in 6-8 weeks. The
complete archive rebuild we did after that took 3-4 weeks.

So it took 3-4 people about twice as long as cpu speed and upload
bandwidth dictated to build nearly all of debian and fix amd64 specific
issues. And that was for a verry large part due to alpha having fixed
64bit issues already.

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/87399w6jsa.fsf@frosties.localnet

Re: upstart: please update to latest upstream version

[Goswin von Brederlow]

Steve Langasek  writes:

> I would certainly welcome it if someone did profiling that showed whether
> the shells are a bottleneck.  My own subjective experience is that this is
> probably not the low-hanging fruit on a general-purpose distro, but if it
> turns out that there are significant speed improvements to be had, we could
> certainly look at moving more core startup functionality into C for upstart.

Or compile shell scripts to binary. There are a number of toy compilers
for shell out there that could be adapted for that use.

>> The other factor of shell scripts is psychological. Since shell scripts are
>> so easy to modify, people tend to litter them with unneccesary checks,
>> settings, workarounds and other spagethi. 
>
> One of the worst contributors to the use of 'script' in upstart jobs instead
> of 'exec' is the need for backwards-compatibility with pre-upstart
> /etc/default/* files.  The options here are all fairly poor:
>
>  - ignore the admin's /etc/default settings when switching init systems
>  - migrate any local changes to /etc/default into the upstart job at upgrade
>time, by editing a conffile in a maintainer script
>  - keep sourcing /etc/default at runtime
>
> I guess systemd has largely chosen option 1 (in part because there's a weird
> view in the systemd community that these jobs belong upstream, so Debian
> integration issues are entirely ignored).  For many upstart jobs in Ubuntu,
> we've chosen option 3.  Which do you think is the right solution?  Are there
> other options I haven't seen?

Option 3 is the right solution.

Option 1 is just plain wrong. There are a number of packages where I've
had to change the defaults to suite my needs and all that work would be
lost.

Option 2 is also bad. There is a reason why we have /etc/default instead
of setting the options in the init.d scripts directly. Most importantly
the init.d scripts can be updated without dpkg questions.

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

Re: upstart: please update to latest upstream version

[Russ Allbery]

I said this in another message, but I'm not sure I was sufficiently
explicit, so I'm going to try again to inject a bit more reality into this
thread.

The next step for looking at alternative init systems is finalizing the
Policy changes that are required to support alternative init systems.
That discussion is happening separately in debian-policy (and is largely
complete).  I believe there's already general consensus around documenting
what people *can* do if they choose to add such support, with the explicit
requirement that sysvinit scripts continue to be supported.

At that point, we can start actually testing Debian with alternative init
systems and individual packagers can decide whether to add support for
specific alternative init systems like upstart or systemd or continue to
rely on their init system emulation.

This will give us considerably more data about many things: what benefits
we can see from this approach, how difficult it is for the early adopters
to write upstart or systemd configuration, what a transition would look
like, and so forth, without causing any harm to the rest of Debian or
doing anything irreversible.  It will also let us *do* things and see
whether they work rather than just *talking* about things, which is
usually a substantial improvement.

This is very similar to the approach that was taken for rolling out
dependency-based boot.

Once we have that practical experience and a Policy framework in which we
can do that experiment, we will have considerably more data and will be
able to have a more informed debate.

I think the current argument has reached the point where it's a waste of
everyone's time.  We have a pretty good idea of what we're doing in the
short run, none of the discussion we're currently having is particularly
relevant to that, and much of the discussion is speculation without data
that we'll be able to acquire later.  Worse, I think it has degraded to
the point where a small number of people with strongly held views are
basically repeating their views at each other without any hope of anyone
changing their mind.  This is bad, since it hardens everyone's views and
makes it more difficult for everyone later to reconsider in the light of
additional evidence and possibly change their minds.

People can certainly continue talking about this if they want to and feel
like they have something significantly new to add, but I'd ask everyone to
seriously consider just letting this conversation end right now and
revisit the discussion later when we have more information and a better
framework in which to have it.

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

Bug#661554: ITP: kvpm -- Logical volume manager and disk partitioning tool

[Benjamin J. Scott]

Package: wnpp
Severity: normal
Owner: "Benjamin J. Scott" 

* Package name: kvpm
  Version : 0.8.5
  Upstream Author : Benjamin J. Scott 
* URL : http://http://sourceforge.net/projects/kvpm/
* License : GPL version 3
  Programming Lang: C++
  Description : Logical volume manager and disk partitioning tool

KVPM is a KDE GUI for the Linux Volume Manager project and libparted.  
It uses the standard LVM tools and programs to work with logical
volumes.  It can also format volumes and mount them.



-- 
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/20120227221439.32291.51723.reportbug@bedroom.boskone

Re: upstart: please update to latest upstream version

[Uoti Urpala]

Goswin von Brederlow wrote:
> Steve Langasek  writes:
> > /etc/default/* files.  The options here are all fairly poor:

> Option 2 is also bad. There is a reason why we have /etc/default instead
> of setting the options in the init.d scripts directly. Most importantly
> the init.d scripts can be updated without dpkg questions.

See http://0pointer.de/blog/projects/on-etc-sysinit.html for a
description of the systemd upstream view (which also shows that Debian
has hardly been "ignored" like Steve Langasek claimed). The comments
also address some of the issues.


-- 
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/1330383187.5387.200.camel@glyph.nonexistent.invalid

Re: description of "general" pseudo-package is misleading (leads people to use it as a catch-all)

[Jonathan Nieder]

Don Armstrong wrote:

> http://www.debian.org/Bugs/Reporting already tells people to contact
> -user if they are unable to determine which package their bug report
> should be filed against. I suppose text could be added to reportbug to
> mimic this... perhaps changing:

Very nice.  Filed as http://bugs.debian.org/661563

[...]
> I suppose I could change it to general -- "Problems which affect many
> packages (blah blah blah)".

Yes, that sounds good to me.  I guess technically it is closer to
"Problems which afflict many packages", since, for example, "I can't
boot" would affect my ability to use all packages, but I'm not too
worried about that particular confusion.

Thanks,
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/20120228010313.GB14575@burratino

Bug#661565: ITP: nyancat -- Terminal-based Pop Tart Cat animation

[Jonathan McCrohan]

Package: wnpp
Severity: wishlist
Owner: Jonathan McCrohan 

* Package name: nyancat
  Version : 0.1
  Upstream Author : Kevin Lange 
* URL : http://miku.acm.uiuc.edu/
* License : NCSA
  Programming Lang: C
  Description : Terminal-based Pop Tart Cat animation 

Nyancat is an animated, color, ANSI-text telnet server that renders a loop of
the classic Nyan Cat animation. Nyancat can also be run as a standalone program
in a local terminal if telnet functionality is not required.



-- 
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/20120228012315.10899.14478.report...@lambda.dereenigne.org

Re: upstart: please update to latest upstream version

[Steve Langasek]

On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
> > Well, I fudged a little here.  You're right that, as written above, nis is
> > not guaranteed to start before autofs.  Due to a (well-understood and
> > recognized) limitation of upstart's current event handling, if the
> > 'runlevel' event is seen before 'starting autofs', the subsequent 'starting
> > autofs' event will *not* block waiting for nis to be started, and so the
> > startup will happen in parallel.

> Which is the problem. Half the time on boot autofs fails to get the maps
> from NIS.

Ah, it looks to me like this is an out-of-order migration then of the autofs
init script to an upstart job when the nis package had yet been converted to
upstart.  That's a bug in those packages, plain and simple.  Seems to have
been reported as
.

I've corrected this now for the upcoming Precise release.

> Well, you are totaly cheating and using a dependency based design to
> work around the problem.

Heh.  I don't think this is cheating at all; it's always been the intent to
support this modality in upstart, AFAIK.  There are just some cases where
the currently available built-in semantics fall short of the mark.

> When was wait-for-state introduced? I don't seem to have this on
> Lucid. Another of those growing problems?

Yes.  It was introduced in Ubuntu 11.10.

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


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

[Goswin von Brederlow]

Steve Langasek  writes:

> On Sun, Feb 26, 2012 at 05:24:16PM +0100, Goswin von Brederlow wrote:
>> > Well, I fudged a little here.  You're right that, as written above, nis is
>> > not guaranteed to start before autofs.  Due to a (well-understood and
>> > recognized) limitation of upstart's current event handling, if the
>> > 'runlevel' event is seen before 'starting autofs', the subsequent 'starting
>> > autofs' event will *not* block waiting for nis to be started, and so the
>> > startup will happen in parallel.
>
>> Which is the problem. Half the time on boot autofs fails to get the maps
>> from NIS.
>
> Ah, it looks to me like this is an out-of-order migration then of the autofs
> init script to an upstart job when the nis package had yet been converted to
> upstart.  That's a bug in those packages, plain and simple.  Seems to have
> been reported as
> .
>
> I've corrected this now for the upcoming Precise release.

Thanks.

>> Well, you are totaly cheating and using a dependency based design to
>> work around the problem.
>
> Heh.  I don't think this is cheating at all; it's always been the intent to
> support this modality in upstart, AFAIK.  There are just some cases where
> the currently available built-in semantics fall short of the mark.
>
>> When was wait-for-state introduced? I don't seem to have this on
>> Lucid. Another of those growing problems?
>
> Yes.  It was introduced in Ubuntu 11.10.

Can I just copy the wait-for-state job onto a lucid system or does it
need a newer upstart as well?

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/8762ereexe.fsf@frosties.localnet