Re: Why is help so hard to find?

[Neil Williams]

On Fri, 14 Jan 2011 23:46:53 -0800
Mike Bird  wrote:

> On Fri January 14 2011 22:06:21 Christian PERRIER wrote:
> > You're right. No Debian developer is involved in large institutions
> > or corporations where hundreds of such servers are in use. All
> > Debian developers are kids playing on their parents' computer to
> > build a distro, during hacking nights, instead of doing their home
> > work and learn at school.
> 
> You're mistaken Christian. 

Mike, you missed the sarcasm completely and just went on another
rant about two (unrelated) bugs which affect you directly. Guess what
- I don't give two flying figs about those two specific issues because
they don't affect me. I care about the underlying problem.

You also changed the topic of this part of the thread to something
much more interesting and important - lack of responses to RFH bugs -
and then put nothing in the body of the reply to actually relate to the
new subject. Please don't waste time on specifics - there is a much
wider, much more important, systemic problem here which you have
identified in the subject and then abandoned.

Can the rest of us now actually ask if there is anything we can do to
get more people involved in helping packaging teams which are openly
asking for help?

If Debian isn't doing the right things to attract helpers, then there
is no solution for the users in this thread who are basically
complaining about packages with lots of bugs and not enough manpower.
Debian cannot afford to have multiple versions of big package sets -
especially where the current options already have lots of bugs. There
is not the manpower to have two complete boot systems or two versions
of a complete desktop environment, no matter what the upstream support.

People are complaining about lack of bug fixes (dressing that up as
accusations of poor maintenance in Debian) and DD's are replying with
examples of where there is simply not enough manpower to deal with the
bugs - we all know which packages and package sets are struggling to
handle the bug load. Making it specific / explicit doesn't help.

Replies often become sarcastic or humorous to try and deflect the guilt
that maintainers are not able to find enough people to work in their
teams. It's not that a particular maintainer or team of maintainers are
bad maintainers necessarily, there's no point making sweeping
statements that maintainers should step down. Who's going to volunteer
instead?

It's obvious from the QA pages and the RFH bug lists that nobody is
stepping up to take on the work.

Criticising those who are struggling to do the work - but at least are
still engaged with it and trying hard to fight the negativity of such a
workload - is not helpful! Even when a team is fatally under-resourced,
who would blame the remaining team from not wanting to work with
someone who is only ever criticising the team without doing the work
themselves?

Instead, what actually does happen is that overworked teams look for
help using the current systems, rants start on lists like this and
people in the overworked teams get individually picked on and bullied
by people who don't have time to help with the work themselves.

Result? People get even more negative about working in such overworked
teams and find something more enjoyable to do. Teams lose the few
contributors who did actually get things done and it all gets worse.

Criticising does not help an overworked team. Unless there are people
willing to join up and do the work, there is no point crying out for
ways to identify maintainers who should be replaced or forced to step
down.

The problem is a lack of manpower in critical teams. That's not new.

The symptom is an impossible number of bugs and a lack of time to
support multiple variants to satisfy different requirements.

The result is that Debian as a whole gravitates to one particular
solution which suits the needs of those willing to do the work. That is
inevitable. If nobody is willing to do the grunt work of maintaining
the alternative, the alternative does not get maintained. That's
obvious, isn't it?

Fix the problem not the symptom.

Stop moaning about the results of the problem and let's try again to
fix the problem. Moaning about it just makes it harder to actually get
things done! (Including wasting my time writing this long response when
all the problems in it are well known already.)

None of this is new, it's been a problem in Debian ever since I got
involved and from talking to others in Debian, for as long as they can
remember too.

Ignore the specifics, this is not about specific packages, specific
teams, specific sub-systems. This is and always has been a completely
general problem, not just to Debian but for all free software.

There are people out there willing to help but mostly they don't want
to work on the same areas as those which are providing the largest
source of complaints and that is often because of rants and criticisms
of those teams by people not actually tr

Re: Why is help so hard to find?

[Mike Bird]

On Sat January 15 2011 00:51:42 Neil Williams wrote:
> Mike, you missed the sarcasm completely and just went on another
> rant about two (unrelated) bugs which affect you directly. Guess what
> - I don't give two flying figs about those two specific issues because
> they don't affect me. I care about the underlying problem.

We ran into those bugs while testing Squeeze and have for the most
part worked around them.  We now know never to enable insserv.  We
may even add some hacks to our systems to prevent sysv-rc from nagging
us.  And we know to remove KDE 4 and install Trinity.

However they are very serious bugs and Squeeze should not be released
with them in their current state.  They are not so much programming
bugs as process bugs - abuses of the packaging system to force or
trick people into switching to unwanted and undesirable software.

They are intentional bugs, and therefore unlikely to be fixed by the
packagers who created them without peer pressure from the majority
of Debian developers who care about the quality of Squeeze.

> You also changed the topic of this part of the thread to something
> much more interesting and important - lack of responses to RFH bugs -
> and then put nothing in the body of the reply to actually relate to the
> new subject.

You are mistaken Neil.  I indicated one important reason why experienced
programmers don't want to work on Debian.  They have no desire to spend
a year of their life humoring someone with a tenth of their expertise.

Debian has unfortunately moved from excellence-driven to time-serving.

The problem is curable.  Hopefully a DPL will tackle it one of these years.

--Mike Bird


-- 
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/201101150109.58736.mgb-deb...@yosemite.net

Re: Why is help so hard to find?

[Stéphane Glondu]

Le 15/01/2011 08:37, Tollef Fog Heen a écrit :
> This would also purge the configuration of packages where I have no wish
> to do so.  I sometimes uninstall packages without purging them, just
> because I want to keep the configuration around.

If you are so concerned about your configuration files, you probably
version your /etc with some $VCS... it is then easy to recover a
configuration file even when its package is purged.


Cheers,

-- 
Stéphane


--
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/4d316306.8020...@debian.org

Re: Why is help so hard to find?

[Stéphane Glondu]

Le 15/01/2011 01:40, Roger Leigh a écrit :
> Yes, and this is what I did.  It's just rather tedious to (IIRC)
> repeatedly run "dpkg-reconfigure sysv-rc" and then find out which file
> is offending, run "dpkg -S $file", and then purge it.  Because the error
> message only lists the first offending file, rather than listing them
> all, you then need to repeat this until you've weeded out all the files
> one by one until eventually it succeeds.

Why don't you just purge all uninstalled packages in one go?


Cheers,

-- 
Stéphane


--
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/4d31620b.1010...@debian.org

Re: Why is help so hard to find?

[Stéphane Glondu]

Le 15/01/2011 01:05, Roger Leigh a écrit :
> This is mostly due to removed packages which need fully purging to
> remove the last traces of old init scripts which break the process.

I've already experienced issues with configuration files from
uninstalled packages lying around. It wasn't with insserv, nor
initscripts... I don't remember exactly the circumstances. It was years
ago. My conclusion back then was to always purge uninstalled packages,
and so I do on most machines I administrate.


Cheers,

-- 
Stéphane


--
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/4d31652a.1040...@debian.org

Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl

[Charles Plessy]

Le Fri, Jan 14, 2011 at 12:09:33PM -0400, Joey Hess a écrit :
> 
> I probably misread DEP5 -- when it says "formatted text, no synopsis",
> it probably means that the entire field including the first line
> is treated as one thing. So both "Comment: foo\n" and "Comment:\n foo\n" are
> the same value.

The comment field was only briefly discussed, but nobody noted on the
impossibility to have a synopsis: 
http://lists.debian.org/1282769854.2242.54.camel@havelock

The absence of synopsis in the Comment and Disclaimer fields maybe originates
from the proposition that newlines are not significant there?
( http://lists.debian.org/1282080573.12989.179.camel@havelock )

Perhaps at that time it looked more simple like this. But I would definitely
agree to have the Disclaimer and Comment fields simply follow the same syntax
as debian/control's Description field, that is, ‘formatted text, with
synopsis’, if the consensus is that it reduces the complexity of the DEP's
syntax. I do not think that other control files contain fields with a similar
syntax. Rather, when no synopis is desired, the formatted field starts with an
empty line, like the Changes field of .changes files.

Source is the last field with a ‘formatted text, with synopsis’ syntax. The
reason for this is that it was designed to fit multiple purposes: be able to
indicate multiple URLs when a package aggregates multiple sources, and be the
place to record a comment when no URL can be given. But we have a Comment
field, so why not use it instead ? In that case, the format could be changed to
‘line based list’.

That would leave only three kind of syntaxes: white space separated lists, line
based lists and formatted text.

To better help the reader to leverage his understanding of the other Debian
control files and RFC 822 when learning the DEP-5 format, I think that we
should unify the vocabulary as much as possible. Unfortunately, the Policy
currently does not provide much abstraction of the syntax of the fields in
Debian control files. I have submitted #593909 to introduce three types:
simple, folded and multiline. It already has been seconded by two persons. If
it is accepted, the DEP could be clarified accordingly:

 - Single-line values → simple (hopefully removed from the DEP if we agree on 
the simplifications above).
 - white space separated lists → folded (this is RFC 822's terminology).
 - line based lists → multiline, like the Files field.
 - formatted text → multiline, like the Description field.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20110115095057.gc27...@merveille.plessy.net

Re: Why is help so hard to find?

[Julien BLACHE]

Mike Bird  wrote:

Hi,

> insserv breaks complex systems.  It throws away years of DD work
> and substitutes a few inane and inadequate rules.  It does so

In my experience, insserv makes it a lot easier to handle complex
systems with a lot of interdependent daemons and services. Handling the
initscripts on those systems with the legacy SysV init scheme was a
total pain in the rear.

insserv has issues, but it's still an improvement over the previous
situation and, unlike the other new init systems, it's actually
backward-compatible.

What more could you possibly ask for?

> And KDE 4 is a well known and very old and very stale joke.  Fun
> at parties, maybe, but not really appropriate for the workplace.

KDE4 is crap, world+dog know that. Use GNOME, XFCE or whatever. If you
want KDE3 in Debian, then put your money where your mouth is and
come maintain it.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
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/87d3nypjx1@sonic.technologeek.org

Re: Why is help so hard to find?

[Chris Carr]

On Sat, 2011-01-15 at 01:09 -0800, Mike Bird wrote:
> On Sat January 15 2011 00:51:42 Neil Williams wrote:
> > Mike, you missed the sarcasm completely and just went on another
> > rant about two (unrelated) bugs which affect you directly. Guess what
> > - I don't give two flying figs about those two specific issues because
> > they don't affect me. I care about the underlying problem.
> 
> We ran into those bugs while testing Squeeze and have for the most
> part worked around them.  We now know never to enable insserv.  We
> may even add some hacks to our systems to prevent sysv-rc from nagging
> us.  And we know to remove KDE 4 and install Trinity.

Sorry to de-lurk with a tangential question, but how can I as an
interested observer subscribe to the conversations where these decisions
get made, and contribute views *before* things get to this stage? I have
had the same frustrations as Mike and Roger with insserv, and although I
don't use KDE I have a third example of this problem, where a deeply
flawed "upgrade" broke several of my systems and the maintainers'
response was basically "too bad" (GRUB2).

Is there some forum in which the choice of a default for a package or
service gets made? I subscribe to debian-devel and debian-policy, but
neither seems to contain discussions about the risks of replacing
perfectly good defaults with significantly flawed ones.

On a completely separate note, where is the correct place to advertise
for a new sponsor? I have not heard from mine for nine months, and I
have a new version of my package and a new related package to upload.

Thanks,

CC


-- 
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/1295086204.2740.20.camel@junior.sadnet

Re: binNMU for Arch: all packages.

[Philipp Kern]

On 2011-01-15, Marco Túlio Gontijo e Silva  wrote:
> The best option to fix this issue I can see is if it was possible to do 
> binNMUs
> for Arch: all packages.  There are some options to workaround the fact that we
> can't binNMUs Arch: all packages, which are: change the -doc package to Arch:
> any; do sourceful uploads instead of binNMUs.  Both options are not ideal, but
> I prefer the first, because sourceful uploads for a 200 package stack would
> need a lot of work.

If the packages are team-maintained, nothing is stopping you from bumping the
revision with dch and do a build, sign, upload cycle.  Indeed without 
source-only
uploads you need to build it once.  But that's scriptable.  (And you can even
cache the key's passphrase through gpg-agent.)

Arch:all binNMUing will only work if you keep the invariant of
version(arch:all) = version(source) in some way.  IMHO sourceful uploading is
the way to go, however, it's frown upon because those are in fact NMUs for
packages you don't own.  For Haskell that shouldn't be a problem, for others we
might like to carve out a policy.

Kind regards
Philipp Kern


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

Re: Why is help so hard to find?

[Neil Williams]

On Sat, 15 Jan 2011 01:09:58 -0800
Mike Bird  wrote:

> On Sat January 15 2011 00:51:42 Neil Williams wrote:
> > Mike, you missed the sarcasm completely and just went on another
> > rant about two (unrelated) bugs which affect you directly. Guess
> > what
> > - I don't give two flying figs about those two specific issues
> > because they don't affect me. I care about the underlying problem.
> 
> We ran into those bugs while testing Squeeze and have for the most
> part worked around them.  We now know never to enable insserv.  We
> may even add some hacks to our systems to prevent sysv-rc from nagging
> us.  And we know to remove KDE 4 and install Trinity.

It's not about specifics, I'm trying to work on the underlying problem.
 
> They are not so much programming
> bugs as process bugs - abuses of the packaging system to force or
> trick people into switching to unwanted and undesirable software.

If the alternative software was maintained within Debian by an active
team then maybe the switch could be a choice. If nobody steps up to do
it, that choice is not available.

Lacking endless resources, Debian has to go with what people actually
doing the work want to work on.

If you want something different, work with people in Debian to provide
it but you do have to work with people with differing expertise.

Every great idea is worthless without someone to do the work.

Your issues may be valid, they might be invalid - I'm simply not
involved in those kinds of issues and I don't have time to worry about
it. Those who are willing to work on those issues within Debian get to
decide how Debian works in those areas.

Debian is a meritocracy - do the work and work with the people already
involved or it simply won't get done the way you want it done.

It makes no odds if your experience differs from others - my
experience / expertise exceeds yours in certain areas by at least as
much as you claim against those whom you criticise in Debian and your
experience / expertise in other areas exceeds mine by as much. Tough.
We're different, we work in completely different areas of Debian. Live
with it. Work with me and with others and respect different levels of
experience and expertise. Debian is simply not offering any other
choices.

You probably don't care about the kinds of systems which I work on and
I certainly don't care about the kinds of systems which you work on.
The fact remains that both sets can use Debian and we need to work
together to make that work better for both parties. If the current setup
suits my needs more than it does yours (which, AFAICT is the case
because I am completely unaffected by the bugs you find so troublesome)
then get involved, do the work and provide the alternative. Otherwise,
I will continue pushing for changes in Debian which suit me and doing
the work to provide those changes, test them, implement them and
continue helping Debian to become more like the system I want it to
become by being involved.

Those who do the work get to decide how the work is done. Nobody can
blame me for working towards what I want Debian to become unless that
person is willing to step up and do at least much work towards their
own goals as I put into achieving mine.

It really is that simple.

> They are intentional bugs, and therefore unlikely to be fixed by the
> packagers who created them without peer pressure from the majority
> of Debian developers who care about the quality of Squeeze.

I care about the quality of Squeeze but I don't care about your pet
issues and because there is nobody stepping up to provide the solutions
you want, it appears that nobody else does either.

If you can't scratch your own itch within Debian then you need to
persuade (not bully) someone else to help provide it within Debian or,
as you've done, work around it outside Debian. That is NOT the fault of
Debian. Debian works with those who work with Debian because the people
aren't there to work on other stuff.

I have pet issues of my own which aren't going to be fixed in Squeeze
and which I will have to work around in my day-to-day work for the next
couple of years until I can get the changes into Wheezy. Those are
release-critical to me too but I accept that my particular situation is
not the same as others in Debian. If I am to get Debian to work
the way I want it to work and fix these issues, I accept that I have to
work with people who have different expertise and probably know next to
nothing about my specific environment and needs. 

I'm a specialist - very few people within or outside Debian are doing
the precise work which occupies my daily life. (Think less than a
hundred world-wide and just a few dozen in free software, most of
whom I can name.) Can't help that - it's a small niche market. (It's
medical, so arguing that I should seek to increase the size of the
market could be seen as seeking for more people to be afflicted with a
debilitating life-long condition which isn't a nice thing to consider.)
Still, I 

Getting warned about and contributing to decisions (Re: Why is help so hard to find?)

[Jonathan Nieder]

Hi Chris,

Chris Carr wrote:

> Sorry to de-lurk with a tangential question, but how can I as an
> interested observer subscribe to the conversations where these decisions
> get made

Good question.  Subscribe to the PTS for the affected packages[1] and
test the versions in unstable and experimental.

> and contribute views *before* things get to this stage?

If by "views" you mean "overlooked use cases or bugs", then filing
bug reports is very welcome.  If by "views" you mean "telling
people what to do", the best way is to get involved in maintenance
(submitting patches, etc), so that the person to tell what to do is
yourself.

> I had the same frustrations as Mike and Roger with insserv

FWIW moving to LSB-style dependency-based boot (abbrev. "insserv") is
an interesting example.  It is a big change.  As mentioned in this
thread, there is a detail still to iron out: what exactly should be
done with stray init scripts without the LSB header?[2]

"Why do some developers like it, then?" you might wonder.  It removes
a huge source of maintenance headache --- the global allocation of
boot sequence numbers[3].

If a year and four months ago someone volunteered to take on that
burden (i.e., take responsibility for making sure the number-based
boot order still works, patching affected packages where appropriate)
for squeeze, then insserv could have been made optional.  I am not
aware of anyone stepping up to do that.

> a deeply
> flawed "upgrade" broke several of my systems and the maintainers'
> response was basically "too bad" (GRUB2).

You filed a bug against the grub-pc package and the response was "too
bad" rather than "here's how we can fix it"?  What is the bug number?

> On a completely separate note, where is the correct place to advertise
> for a new sponsor?

See http://wiki.debian.org/DebianMentorsFaq#HowdoIgetasponsorformypackage.3F

Hope that helps,
Jonathan

[1] 
http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system
[2] http://bugs.debian.org/598020
Maybe insserv can query dpkg itself for init scripts from packages in
the conffiles state.  Or maybe the release notes can provide detailed
instructions for getting past this hurdle.
[3] http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot


-- 
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/20110115105752.GB28165@burratino

Alioth is unreachable

[Grégoire Scano]

Hi,

Haven't seen a report yet, I was there http://www.debian.org/intro/help 
clicking on Alioth http://alioth.debian.org/ and got :
An error occured in the logger. ERROR: could not extend relation 
1663/132975/132988: No space left on device HINT: Check free disk space.


Greg


--
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/4d317df4.5030...@gmail.com

Re: Why is help so hard to find?

[Lars Wirzenius]

On la, 2011-01-15 at 10:10 +, Chris Carr wrote:
> Is there some forum in which the choice of a default for a package or
> service gets made? I subscribe to debian-devel and debian-policy, but
> neither seems to contain discussions about the risks of replacing
> perfectly good defaults with significantly flawed ones.

* debian-devel
* debian-project
* debian-policy
* debian-devel-announce
* debian-release
* debian-installer
* package-specific mailing lists, if any
* planet.debian.org

The lists are either @lists.debian.org or at @alioth.debian.org.
Additionally, you may subscribe to all bug discussion for specific
packages via packages.qa.debian.org or specific bugs via
bugs.debian.org. Also, some of the IRC channels mentioned in the Debian
Developers' Reference may be useful to follow, though the
signal-to-noise ratio varies much more on them than on lists.

Discussions tend to start with specific bugs, and get escalated to more
general lists if problems turn out to be severe enough, or affect many
packages. In order for discussions to start, it is necessary for people
who actually use Debian to participate by trying out the testing or
unstable distributions in their real environments (taking care to avoid
disruptions from inevitable breakage). It is not workable to assume all
Debian developers foresee everything, or to handle all situations
without any constructive feedback.

> On a completely separate note, where is the correct place to advertise
> for a new sponsor? I have not heard from mine for nine months, and I
> have a new version of my package and a new related package to upload.

debian-mentors, I believe.

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1295089336.3740.25.ca...@havelock.lan

Re: Why is help so hard to find?

[Andrei Popescu]

On Sb, 15 ian 11, 10:10:04, Chris Carr wrote:
> 
> Is there some forum in which the choice of a default for a package or
> service gets made? I subscribe to debian-devel and debian-policy, but
> neither seems to contain discussions about the risks of replacing
> perfectly good defaults with significantly flawed ones.

"replacing perfectly good defaults with significantly flawed ones" 
implies the respective maintainers are evil and trying to break your 
system on purpose. You surely don't mean that, do you?

BTW, I was quite aware that the mentioned changes are about to happen. I 
also subscribe to debian-devel-announce.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Alioth is unreachable

[Grégoire Scano]

Hi,

Haven't seen a report yet, I was there http://www.debian.org/intro/help
clicking on Alioth http://alioth.debian.org/ and got :

An error occured in the logger. ERROR: could not extend relation
1663/132975/132988: No space left on device HINT: Check free disk space.

Greg


--
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/4d31805c.7020...@gmail.com

Re: binNMU for Arch: all packages.

[Stéphane Glondu]

Le 15/01/2011 11:29, Philipp Kern a écrit :
> Arch:all binNMUing will only work if you keep the invariant of
> version(arch:all) = version(source) in some way.

Why is this needed?

-- 
Stéphane


--
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/4d318350.8030...@debian.org

Re: binNMU for Arch: all packages.

[Julien Cristau]

On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:

> Le 15/01/2011 11:29, Philipp Kern a écrit :
> > Arch:all binNMUing will only work if you keep the invariant of
> > version(arch:all) = version(source) in some way.
> 
> Why is this needed?
> 
Package: foo
Architecture: all

Package: bar
Architecture: any
Depends: foo (= ${source:Version})

If ${source:Version} is not version(arch:all) you've got yourself an
uninstallable package.  If ${source:Version} is not version(source)
things become slightly confusing.  Again.  We've had enough of that with
${Source-Version}.  And it'll probably break some other stuff as well.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: binNMU for Arch: all packages.

[Bastian Blank]

On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
> On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
> > Le 15/01/2011 11:29, Philipp Kern a écrit :
> > > Arch:all binNMUing will only work if you keep the invariant of
> > > version(arch:all) = version(source) in some way.
> > Why is this needed?
> If ${source:Version} is not version(arch:all) you've got yourself an
> uninstallable package.  If ${source:Version} is not version(source)
> things become slightly confusing.

Only if it is used. However the packages in question _don't_ have
versioned relations at all:

| Package: libghc6-zip-archive-doc
| Priority: extra
| Section: doc
| Installed-Size: 252
| Maintainer: Debian Haskell Group 

| Architecture: all
| Recommends: ghc6-doc
| Suggests: libghc6-zip-archive-dev

>Again.  We've had enough of that with
> ${Source-Version}.  And it'll probably break some other stuff as well.

Well. Who spoke about a change of source:Version at all?

Bastian

-- 
Killing is wrong.
-- Losira, "That Which Survives", stardate unknown


-- 
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/20110115125206.ga19...@wavehammer.waldi.eu.org

Re: binNMU for Arch: all packages.

[Bastian Blank]

On Sat, Jan 15, 2011 at 10:29:46AM +, Philipp Kern wrote:
> Arch:all binNMUing will only work if you keep the invariant of
> version(arch:all) = version(source) in some way.

This invariant comes from where? From my knowledge neither w-b nor dak
cares about it.

Bastian

-- 
Deflector shields just came on, Captain.


-- 
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/20110115125334.gb19...@wavehammer.waldi.eu.org

Re: binNMU for Arch: all packages.

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-01-14 22:22, Yves-Alexis Perez wrote:
> On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote:
>> This documentation is generated automatically
>> from the source code, using a documentation generator called haddock.  
>> Haddock
>> is part of the compiler and is also updated when the ghc is.  It would be
>> good to regenerate the documentation for each library too, when a new ghc
>> arrives. 
> 
> I don't really know anything about haskell, but is it really needed to
> regenerate library docs each time the compiler is updated? What does it
> give?

Hey,

It is possible the Java packages could use binNMU for arch: all packages
as well.  There was some talk about injecting "ABI" versioning in Java
Libraries at DebConf10, so we could handle ABI breakage in a similar way
to how it is done with regular libraries.

~Niels

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNMZp0AAoJEAVLu599gGRCG9AQAIkbZm70clVfWLOhqy12zZgC
EEytgjw9d8twNbY5kib+xWxGzOT7I/4LrC0ayoF5+VacYmgAhlBydoarHK1oJvyw
ExAxfYiADLKwoxsoFHZNlbBCEkoLYnx8sdmg/Yu6CVVeNtp+xwKCfk9QLGBSieJw
nzTDsd5+GTJrgH6FGW3RVwC7XQqhuGKVD34BxHnO3SqQiFjbiMgSxkU9qa3Vb5rp
G8qSm4oRm94B8k4DU920WgcjdISAY/ZnlILwYwsOjx5DFr5fEQjXTsIHEc9dad4S
+WZPOS2YkXdXbHOrS5c9rGJICHtjdcThRofr6onllOoBM8zbeU3B3Fexwf6Unm9v
0N/KpoTN787yfE78HJBOdOBTXQFGqtX4qvRvl2ZpXmULga5kZgjvu9Rrgf2+d5Ki
/31Fc8eSzNsFRV5/FDLXdQ55ak98m+Fh5s0tVtD0oCs9hXxWWE8tl1FN/Z42/+y1
XNyuzkGhTPYRPCAubeCOGWX1yvIAwVino+CEQpWDeRzeJCTixng5V+JH+iwOZWIQ
VIwEIyj4TkbkK0fLycjzXMuelXmvAteZ6ANcOtGMYRTD99hCInKXPfu98vfu/4u0
ec01EIDphzcbpBoDwU9Qz4K/r7SDrThZpsHvesZnCYSYgs4/UuSv0rsHhfNKnRob
saOk9gZyM0BaVUhiBDTQ
=/CL/
-END PGP SIGNATURE-


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

Re: binNMU for Arch: all packages.

[Julien Cristau]

On Sat, Jan 15, 2011 at 13:52:06 +0100, Bastian Blank wrote:

> On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
> > On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
> > > Le 15/01/2011 11:29, Philipp Kern a écrit :
> > > > Arch:all binNMUing will only work if you keep the invariant of
> > > > version(arch:all) = version(source) in some way.
> > > Why is this needed?
> > If ${source:Version} is not version(arch:all) you've got yourself an
> > uninstallable package.  If ${source:Version} is not version(source)
> > things become slightly confusing.
> 
> Only if it is used. However the packages in question _don't_ have
> versioned relations at all:
> 
I don't think it's reasonable to say "arch:all binnmus are allowed for
$this_set_of_packages, but not for the rest".  So what this particular
set of packages does is irrelevant, as far as I'm concerned.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Alioth is unreachable

[Tollef Fog Heen]

]] Grégoire Scano 

Hi,

| Haven't seen a report yet, I was there
| http://www.debian.org/intro/help clicking on Alioth
| http://alioth.debian.org/ and got :
| An error occured in the logger. ERROR: could not extend relation
| 1663/132975/132988: No space left on device HINT: Check free disk
| space.

This has been fixed now, thanks for the heads-up.  In the future, it's
better to mail ad...@alioth.debian.org rather than debian-devel so you
both get the message to the right people and don't disturb all the
subscribers of -devel.

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


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

Bug#610120: RFP: inSSIDer -- graphical wifi scanner

[Arnout Engelen]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

Package name: inSSIDer
Version: 2
Upstream Author: MetaGeek LLC
URL: http://www.metageek.net/products/inssider
License: Apache License, Version 2.0
Description: inSSIDer is a graphical Wi-Fi scanner.
* Inspect your WLAN and surrounding networks to troubleshoot 
competing access points

* Track the strength of received signal in dBm over time
* Filter access points in an easy-to-use format
* Highlight access points for areas with high Wi-Fi concentration
* Export Wi-Fi and GPS data to a KML file to view in Google Earth.
* Filter through hundreds of scanned access points





--
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/4d31a95e.4080...@bzzt.net

Bug#610129: ITP: jshash -- calculate secure hash algorithms in JavaScript

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: jshash
  Version : 2.2
  Upstream Author : Paul Johnston 
* URL : http://pajhome.org.uk/crypt/md5/
* License : BSD-3-clause and RSA
  Programming Lang: JavaScript
  Description : calculate secure hash algorithms in JavaScript

 JavaScript implementation of some secure hash algorithms:
  * MD5 Message Digest Algorithm (RFC 1321)
  * RIPEMD-160 Algorithm
  * SHA-1 Secure Hash Algorithm (FIPS 180-1)
  * SHA-256 Secure Hash Algorithm (FIPS 180-2)
  * SHA-512 Secure Hash Algorithm (FIPS 180-2)
  * HMAC Keyed-Hashing for Message Authentication (RFC 2104)



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

Re: Why is help so hard to find?

[Olaf van der Spek]

On Sat, Jan 15, 2011 at 10:13 AM, Stéphane Glondu  wrote:
> Le 15/01/2011 01:05, Roger Leigh a écrit :
>> This is mostly due to removed packages which need fully purging to
>> remove the last traces of old init scripts which break the process.
>
> I've already experienced issues with configuration files from
> uninstalled packages lying around. It wasn't with insserv, nor
> initscripts... I don't remember exactly the circumstances. It was years
> ago. My conclusion back then was to always purge uninstalled packages,
> and so I do on most machines I administrate.

Couldn't that be done automatically if no local changes are present?

Olaf


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

Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl

[Joey Hess]

One more thing, "License: GPL-2+ | Expat" was an old syntax on the wiki,
and it seems the parser only looks for an expansion of the GPL-2+
license in this case, ignoring the Expat part.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Forwarding bugs upstream

[Marc Haber]

On Wed, 12 Jan 2011 13:27:23 + (UTC), Sune Vuorela
 wrote:
>On 2011-01-11, brian m. carlson  wrote:
>> I've noticed a trend lately that I am often asked to forward the bugs I
>> report to the Debian BTS upstream, either by the maintainers or
>> automatically by a bug script.  I believe, and I continue to believe,
>
>I have considered to take this one step further. Close bugs reported in
>Debian BTS with a severity of important or less that is a bug that
>should primarily be fixed upstream.

This attitute of the Qt/KDE team has stopped me from repoting bugs in
KDE packages completely.

>Currently, the debian Qt/KDE team has around 800 open, non-forwarded
>bugs reported against their packages. I would guess that maybe 20 of
>them is packaging issues. But we can't find them. 

Just usertag the non-packaging issues and filter them out in your
queries.

>The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is
>pure upstream issues. 

They're still issues present in current Debian.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1pe94q-0005yg...@swivel.zugschlus.de

Re: Alioth is unreachable

[Marc Haber]

On Sat, 15 Jan 2011 15:33:44 +0100, Tollef Fog Heen 
wrote:
>]] Grégoire Scano 
>| Haven't seen a report yet, I was there
>| http://www.debian.org/intro/help clicking on Alioth
>| http://alioth.debian.org/ and got :
>| An error occured in the logger. ERROR: could not extend relation
>| 1663/132975/132988: No space left on device HINT: Check free disk
>| space.
>
>This has been fixed now, thanks for the heads-up.  In the future, it's
>better to mail ad...@alioth.debian.org rather than debian-devel so you
>both get the message to the right people and don't disturb all the
>subscribers of -devel.

I wouldn't have counted on the mailing list being operational
regarding the machine running the list being out of disk space.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1pe9ow-0006jj...@swivel.zugschlus.de

Re: Why is help so hard to find?

[Roger Leigh]

On Sat, Jan 15, 2011 at 10:48:54AM +, Neil Williams wrote:
> On Sat, 15 Jan 2011 01:09:58 -0800
> Mike Bird  wrote:
> 
> > On Sat January 15 2011 00:51:42 Neil Williams wrote:
> > > Mike, you missed the sarcasm completely and just went on another
> > > rant about two (unrelated) bugs which affect you directly. Guess
> > > what
> > > - I don't give two flying figs about those two specific issues
> > > because they don't affect me. I care about the underlying problem.
> > 
> > We ran into those bugs while testing Squeeze and have for the most
> > part worked around them.  We now know never to enable insserv.  We
> > may even add some hacks to our systems to prevent sysv-rc from nagging
> > us.  And we know to remove KDE 4 and install Trinity.
> 
> It's not about specifics, I'm trying to work on the underlying problem.
>  
> > They are not so much programming
> > bugs as process bugs - abuses of the packaging system to force or
> > trick people into switching to unwanted and undesirable software.
> 
> If the alternative software was maintained within Debian by an active
> team then maybe the switch could be a choice. If nobody steps up to do
> it, that choice is not available.
> 
> Lacking endless resources, Debian has to go with what people actually
> doing the work want to work on.
> 
> If you want something different, work with people in Debian to provide
> it but you do have to work with people with differing expertise.
> 
> Every great idea is worthless without someone to do the work.

Dear Neil,

I just wanted to say thanks for your considered and thoughtful reply.
I agreed with everything you said, and really appreciated you taking
the time to write it.


Regards,
Roger

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


signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Mike Bird]

On Sat January 15 2011 01:59:06 Julien BLACHE wrote:
> insserv has issues, but it's still an improvement over the previous
> situation and, unlike the other new init systems, it's actually
> backward-compatible.

I have no objection to you using insserv.  I object to people
being tricked into using insserv.  It tends to break complex
systems and people should be warned about this danger rather
than being told that insserv is recommended and then making a
bad decision based on sysv-rc.postinst's faulty recommendation.

insserv is also irreversible, and if you restore /etc from
a backup without undocumented magic, insserv will destroy /etc
again.  That in my book seriously limits its compatibility.

For servers which may only be rebooted once a year, a second
saved in boot time is not worth the hassle, or even the mere
risk of hassle, due to actual or potential damage from insserv.

> KDE4 is crap, world+dog know that. Use GNOME, XFCE or whatever. If you
> want KDE3 in Debian, then put your money where your mouth is and
> come maintain it.

That is well known.  KDE 4 maintainers cannot keep up with
the bug reports now and will be totally overwhelmed when
Squeeze is released.  That is not what people expect of
Debian Stable.

The problem is that KDE 4 has moved to take over the package
namespace used by KDE 3.5.  This is totally unnecessary.
KDE 4 - the new package suite - can and should use new
non-conflicting package names.

KDE 4 packages should be able to co-exist alongside KDE 3.5,
at minimum within the package namespace, and ideally also
on the same workstation.  Trinity has achieved both, but
the upgrade from Lenny (including KDE 3.5) to Squeeze
(with KDE 3.5 from Trinity) is confusing because of all the
unnecessary package renaming.

If the KDE 4 maintainers would leave the KDE 3.5 package
namespace untouched, then it would be much easier for
people to continue to use KDE 3.5 whether as Debian
packages (preferred) or via external repositories such
as Trinity.

--Mike Bird


-- 
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/201101151051.43442.mgb-deb...@yosemite.net

Bug#610159: ITP: r-cran-gam -- Generalized Additive Models for R

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence 

* Package name: r-cran-gam
  Version : 1.04-1
  Upstream Author : Trevor Hastie 
* URL : http://cran.r-project.org/web/packages/gam/index.html
* License : GPL v2
  Programming Lang: C, Fortran
  Description : Generalized Additive Models for R

 Functions for fitting and working with generalized additive models,
 as described in chapter 7 of “Statistical Models in S” (Chambers and
 Hastie (eds), 1991), and “Generalized Additive Models” (Hastie and
 Tibshirani, 1990).



-- 
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/20110115184303.12921.18579.reportbug@campbell.localdomain

Bug#610160: ITP: r-cran-rjags -- R interface to the JAGS Bayesian statistics package

[Chris Lawrence]

Package: wnpp
Severity: wishlist
Owner: Chris Lawrence 

* Package name: r-cran-rjags
  Version : 2.2.0-2-1
  Upstream Author : Martyn Plummer 
* URL : http://calvin.iarc.fr/~martyn/software/jags/
* License : GPL v2
  Programming Lang: C++
  Description : R interface to the JAGS Bayesian statistics package

 rjags allows calling JAGS code from R to estimate Bayesian
 statistical models using Gibbs sampling.  Coupled with the coda
 package, it allows the researcher to set up data in R, run a model
 specified in the JAGS/BUGS language on the data, and then conduct
 post-estimation analysis using R's tools.



-- 
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/20110115184815.13001.13425.reportbug@campbell.localdomain

Re: Why is help so hard to find?

[Mike Bird]

On Sat January 15 2011 02:48:54 Neil Williams wrote:
> If the alternative software was maintained within Debian by an active
> team then maybe the switch could be a choice. If nobody steps up to do
> it, that choice is not available.


1. insserv

Legacy booting IS maintained in Debian.  The problem is that
sysv-rc.postinst contains an unwise recommendation to enable
insserv.

Enabling insserv is an irreversible step which can and does
cause damage and a serious waste of time.  It is not recoverable
even by restoring /etc without resort to undocumented magic.

Whether insserv actually breaks a particular server, or only
has the potential to do so, it is unwise to enable insserv
on any server as the actual or potential risks (hours or
days) far outweigh the actual or potential gains (seconds).

This is not to prevent people choosing to use insserv if they
wish.  This is not to prevent Debian from recommending that
people CONSIDER insserv.  But sysv-rc.postinst should not be
blinding recommending that people ENABLE insserv.

The fix is trivial, albeit any updated dialog will require
the attention of Debian's many hard-working translators.


2. KDE 3.5

Lenny has KDE 3.5.  KDE 3.5 is well-maintained upstream - by
Trinity now rather than KDE.  Many people prefer to use KDE
3.5 rather than KDE SC 4 - a radically different and far buggier
desktop with a similar name.

The problem is that KDE SC 4 has unnecessarily usurped the
KDE 3.5 package namespace.  This makes two things hard - upgrading
from Lenny to Squeeze+Trinity and maintaining KDE 3.5 within
Debian rather than outside.

This is not to prevent people from packaging and maintaining
KDE SC 4 if they so choose.  And this is not to prevent people
from choosing to install KDE SC 4 if they so choose.  Ideally
KDE 3.5 and KDE SC 4 would be co-installable (Trinity has
achieved this) but it is not essential.  What is important is
that KDE SC 4 not unnecessarily usurp the KDE 3.5 package
namespace and thereby make KDE 3.5 packaging and upgrades
unnecessarily difficult.


--Mike Bird


-- 
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/201101151115.38289.mgb-deb...@yosemite.net

Bug#610164: ITP: gmerlin-encoders -- encoder plugins for Gmerlin

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 


* Package name: gmerlin-encoders
  Version : 1.0.0
  Upstream Author : Members of the Gmerlin project 

* URL : http://gmerlin.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : encoder plugins for Gmerlin

 Gmerlin is a multiformat media player with tree-like virtual directory 
 structure, where you can save your files, webstreams or whatever. It 
 handles even large media collections gracefully. Hardware devices appear 
 also in the tree so you can open Audio-CDs, (S)VCDs, DVDs and 
 DVB-broadcasts.
 .
 This package includes a number of encoders to be used by Gmerlin



-- 
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/20110115182242.27296.64258.reportbug@ferrari.iemnet

Re: binNMU for Arch: all packages.

[Stéphane Glondu]

Le 15/01/2011 13:23, Julien Cristau a écrit :
> Package: foo
> Architecture: all
> 
> Package: bar
> Architecture: any
> Depends: foo (= ${source:Version})
> 
> If ${source:Version} is not version(arch:all) you've got yourself an
> uninstallable package.  If ${source:Version} is not version(source)
> things become slightly confusing.  Again.  We've had enough of that with
> ${Source-Version}.  And it'll probably break some other stuff as well.

Well... Someone could also make an arch:any package depend on the
${source:Version} of another arch:any package, if he wants to shoot
hisself in the foot. It doesn't prevents binNMUs of arch:any packages.


Cheers,

-- 
Stéphane


--
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/4d31f558.3040...@debian.org

Bug#610165: ITP: less.js -- JavaScript parser of LESS "Leaner CSS" macro language

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: less.js
  Version : 1.0.40~6b8a5c-1
  Upstream Author : Alexis Sellier 
* URL : https://github.com/cloudhead/less.js
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : JavaScript parser of LESS "Leaner CSS" macro language

 less.js is the next evolution of LESS, aiming to become LESS 2.0.
 less.js is a complete rewrite of LESS in JavaScript, allowing to run it
 dynamically in the browser, as well preparse server-side using node.js.
 .
 LESS is a macro language to produce CSS files.
 .
 LESS Homepage: http://lesscss.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/20110115193501.10383.13911.reportbug@localhost.localdomain

Re: binNMU for Arch: all packages.

[Philipp Kern]

On 2011-01-15, Stéphane Glondu  wrote:
> Le 15/01/2011 13:23, Julien Cristau a écrit :
>> Package: foo
>> Architecture: all
>> Package: bar
>> Architecture: any
>> Depends: foo (= ${source:Version})
>> If ${source:Version} is not version(arch:all) you've got yourself an
>> uninstallable package.  If ${source:Version} is not version(source)
>> things become slightly confusing.  Again.  We've had enough of that with
>> ${Source-Version}.  And it'll probably break some other stuff as well.
> Well... Someone could also make an arch:any package depend on the
> ${source:Version} of another arch:any package, if he wants to shoot
> hisself in the foot. It doesn't prevents binNMUs of arch:any packages.

You do realize that it's common to do the source:Version dependency stuff in
arch:all packages, right?  That kind of polemics you just raised doesn't seem
helpful to me.

Kind regards
Philipp Kern


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

Re: Alioth is unreachable

[Tollef Fog Heen]

]] Marc Haber 

| On Sat, 15 Jan 2011 15:33:44 +0100, Tollef Fog Heen 
| wrote:
| >]] Grégoire Scano 
| >| Haven't seen a report yet, I was there
| >| http://www.debian.org/intro/help clicking on Alioth
| >| http://alioth.debian.org/ and got :
| >| An error occured in the logger. ERROR: could not extend relation
| >| 1663/132975/132988: No space left on device HINT: Check free disk
| >| space.
| >
| >This has been fixed now, thanks for the heads-up.  In the future, it's
| >better to mail ad...@alioth.debian.org rather than debian-devel so you
| >both get the message to the right people and don't disturb all the
| >subscribers of -devel.
| 
| I wouldn't have counted on the mailing list being operational
| regarding the machine running the list being out of disk space.

Fair point, but then #alioth would be better too. :-)

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


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

Re: Why is help so hard to find?

[Tollef Fog Heen]

]] Mike Bird 

Hi,

| insserv is also irreversible, and if you restore /etc from
| a backup without undocumented magic, insserv will destroy /etc
| again.  That in my book seriously limits its compatibility.
| 
| For servers which may only be rebooted once a year, a second
| saved in boot time is not worth the hassle, or even the mere
| risk of hassle, due to actual or potential damage from insserv.

While I have no love for insserv, if you think the whole point of
dependency based boot (be it insserv, upstart, systemd) is boot speed, I
think you're mistaken.  It's a part of the goal, but much more important
is actually correctness.  Getting the dependencies between init scripts
correct is sometimes hard.

People have to test, test again and test more and people also have to
file bugs.  Bugs suck, but they're part of life and complaining about
decision made a long ago is much less productive than just living with
them, making the best out of them and filing bugs when things break.

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


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

wrong devices seen in squeeze

[Hans-J. Ullrich]

Dear maintainers,

on my (older) system, I discovered a weired behaviour: although I am using 
IDE-harddrives, they are seen as /dev/sdX (IDE-drives should be discovered as 
/dev/hdX). Is this a kernel-decision? In /etc/fstab are only entries with 
"/dev/hdX". Because of this, it is impossible to get grub-pc running (kernel-
panic). Strange: The system is runnning perfectly with grub-legacy and those 
wrong devices. Booting with a live-cd, all harddrives are recognized as 
/dev/hdX. 

Weired, eh? Thought, I should mention this

Best regards

Hans








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

Re: Bug#610165: ITP: less.js -- JavaScript parser of LESS "Leaner CSS" macro language

[Faidon Liambotis]

Jonas Smedegaard wrote:

  LESS is a macro language to produce CSS files.


I'd start with that and expand it a bit.

Regards,
Faidon


--
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/4d320095.60...@debian.org

Re: Bug#610129: ITP: jshash -- calculate secure hash algorithms in JavaScript

[brian m. carlson]

On Sat, Jan 15, 2011 at 03:33:25PM +0100, Jonas Smedegaard wrote:
>   Description : calculate secure hash algorithms in JavaScript
> 
>  JavaScript implementation of some secure hash algorithms:
>   * MD5 Message Digest Algorithm (RFC 1321)

I take exception with your description here.  MD5 is not in any way a
secure hash algorithm.  "Cryptographic", yes; "secure", no.

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


signature.asc
Description: Digital signature

Re: wrong devices seen in squeeze

[brian m. carlson]

On Sat, Jan 15, 2011 at 09:38:18PM +0100, Hans-J. Ullrich wrote:
> on my (older) system, I discovered a weired behaviour: although I am using 
> IDE-harddrives, they are seen as /dev/sdX (IDE-drives should be discovered as 
> /dev/hdX). Is this a kernel-decision? In /etc/fstab are only entries with 
> "/dev/hdX". Because of this, it is impossible to get grub-pc running (kernel-
> panic). Strange: The system is runnning perfectly with grub-legacy and those 
> wrong devices. Booting with a live-cd, all harddrives are recognized as 
> /dev/hdX. 

This is due to using the libata PATA drivers instead of the old IDE
ones.  libata drives all appear with the SCSI naming, regardless of
which bus they are connected to.  Since the libata drivers are now the
default in a Debian kernel, all your drives should appear as sd*.  I
believe new kernel packages should help you migrate to a UUID-based
naming method so that how exactly your disks are labelled becomes
irrelevant.

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


signature.asc
Description: Digital signature

Re: Can insserv made better?

[Jesús M. Navarro]

Hi, Mike:

On Saturday 15 January 2011 19:51:43 Mike Bird wrote:
> On Sat January 15 2011 01:59:06 Julien BLACHE wrote:
> > insserv has issues, but it's still an improvement over the previous
> > situation and, unlike the other new init systems, it's actually
> > backward-compatible.
>
> I have no objection to you using insserv.  I object to people
> being tricked into using insserv.  It tends to break complex
> systems and people should be warned about this danger rather
> than being told that insserv is recommended and then making a
> bad decision based on sysv-rc.postinst's faulty recommendation.

Well, we can try to be positive and change a lose for a win here, can't we?

I'd say that insserv main problem now is that of transtition: yes, it can 
break your system in the worst possible way, making it unable to boot, 
specially if you happen to be a professional system administrator caring 
about complex Debian servers.

But that's more a symptom of the problems of the old system which the new 
rises, than of the new system itself, and once your system is properly 
recovered, insserv tends to work properly (as it will work properly for newly 
installed systems) and it's expected to be easier to maintain for the years 
to come than the old one.

So the main problem is "only" transitioning the system, isn't it?  Why don't 
you have then a look at Squeeze's release notes (which any wise Debian system 
administrator will read upon upgrade) and make sure that it states the 
problem in the most clear way and/or propose the changes to that document 
that you percieve to be needed?  That would be feasible in current freeze 
condition of the distribution and it would be a good effort/benefit ratio for 
your effort.

Cheers.


-- 
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/201101152221.33941.jesus.nava...@undominio.net

Re: wrong devices seen in squeeze

[Ben Hutchings]

On Sat, 2011-01-15 at 21:38 +0100, Hans-J. Ullrich wrote:
> Dear maintainers,
> 
> on my (older) system, I discovered a weired behaviour: although I am using 
> IDE-harddrives, they are seen as /dev/sdX (IDE-drives should be discovered as 
> /dev/hdX). Is this a kernel-decision?

This is a kernel change.  If you are using the current kernel image
packages, you were informed of this during the upgrade.

> In /etc/fstab are only entries with 
> "/dev/hdX". Because of this, it is impossible to get grub-pc running
> (kernel-panic)
[...]

The kernel panics if you specify an invalid root device on the command
line.  During the upgrade, you were asked whether configuration files
should be modified to be independent of the device name changes.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#610175: ITP: mudlet -- Graphical MUD client with fast lua scripting support

[Craig Small]

Package: wnpp
Severity: wishlist
Owner: Craig Small 

* Package name: mudlet
  Version : 1.1.1
  Upstream Author : Heiko Koehn,Bruno Bigras,Vadim Peretokin and others
* URL : http://www.mudlet.org/
* License : GPL
  Programming Lang: C++
  Description : Graphical MUD client with fast lua scripting support

A completely redesigned MUD (Multi User Dungeon) client that is easy to
use and customise.  Both power users and plain gamers alike will feel at
home with Mudlet, without having to waste too much timer figuring out
how to do something.

Mudlet is designed to be very fast and efficient right from the start.
It's scripting engine is designed to handle thousands of lines under
one second. The scripting framework uses Lua - a small, fast and 
efficient scripting language.



-- 
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/20110115210058.20854.12148.report...@elmo.enc.com.au

Skilled manpower vs. grunt work (was: Why is help so hard to find?)

[Ben Finney]

Neil Williams  writes:

> Can the rest of us now actually ask if there is anything we can do to
> get more people involved in helping packaging teams which are openly
> asking for help?
[…]

> The problem is a lack of manpower in critical teams. That's not new.

Is the requirement for manpower alone? I thought the problem was a lack
of manpower with the appropriate specific skills.

For my part, the teams that appear to need help most desperately need
people with good skills in specific areas I don't have.

> If nobody is willing to do the grunt work of maintaining the
> alternative, the alternative does not get maintained. That's obvious,
> isn't it?

How much of it is grunt work? Is there a way for willing people, who
lack the specific skills needed by the maintenance team, to bring more
general programming and/or packaging skills to bear on the workload?

Is there an obvious way for people willing to do grunt work to help such
teams (as opposed to the highly skilled work done by the core people in
the maintenance team) to find that grunt work and begin contributing?

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)   to learn.” —Richard Stallman, 2002 |
Ben Finney


pgppGsWqHZrj6.pgp
Description: PGP signature

Re: wrong devices seen in squeeze

[Hans-J. Ullrich]

> This is due to using the libata PATA drivers instead of the old IDE
> ones.  libata drives all appear with the SCSI naming, regardless of
> which bus they are connected to.  Since the libata drivers are now the
> default in a Debian kernel, all your drives should appear as sd*.  I
> believe new kernel packages should help you migrate to a UUID-based
> naming method so that how exactly your disks are labelled becomes
> irrelevant.

Hi Brian!
Ah, thank you, that explains it. Yes, I am using libata and UUID. 
I will try grub-pc again.

Cheers

Hans 


-- 
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/201101152234.38269.hans.ullr...@loop.de

Re: Why is help so hard to find?

[Ben Finney]

Neil Williams  writes:

> Mike Bird  wrote:
> > I indicated one important reason why experienced programmers don't
> > want to work on Debian. They have no desire to spend a year of their
> > life humoring someone with a tenth of their expertise.
>
> Tough. […] If I hadn't spent the last ten years humouring people with
> less than 1% of my own expertise and (more importantly) being humoured
> by those who have a hundred times more expertise in their area than I
> do, I would have no friends in Debian and Debian would not work the
> way that I need.

[…]

> It's not up to the DPL. It's about finding people willing to work with
> other people and avoiding those who do nothing but complain.

That's an excellent distillation. Thank you, Neil.

-- 
 \   “I have one rule to live by: Don't make it worse.” —Hazel |
  `\  Woodcock |
_o__)  |
Ben Finney


pgppQmheaTnyX.pgp
Description: PGP signature

Re: DEP5: CANDIDATE and ready for use in squeeze+1

[Steve Langasek]

On Mon, Jan 10, 2011 at 10:56:31AM +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 10, 2011 at 01:03:21AM -0600, Steve Langasek wrote:
> > Pointing to particular revisions is ugly, but is less ugly IMHO than
> > introducing (again) the possibility of multiple incompatible specs
> > (subtly or otherwise) all referred to with the same "Format"
> > declaration.

> That is correct and this thought has bothered me as well. However, how
> is it any different than, say, the format of debian/changelog? Unlike
> the format of debian/control, not even a Standards-Version field is
> associated to it. There is just software that deal with it that will
> fail upon some (incompatible) format change.

The Standards-Version field is associated with the package as a whole, not
with debian/control alone.  So yes, Standards-Version is a perfectly
adequate declaration of the relevant policy for handling debian/changelog. 
Furthermore, the debian changelog format is quite stable (no
backwards-incompatible changes in well over a decade, notwithstanding the
deprecation of the never-used alternative changelog format support), and
dpkg-parsechangelog is the authoritative implementation of a parser for
debian/changelog.  None of these considerations apply to DEP5 parsing today.

> Arguably, once DEP5 will be integrated into debian-policy, one might
> consider the format of debian/copyright to be subject of
> Standards-Version (if and only if the maintainer will have chosen to go
> the readable debian/copyright way).

There has been no plan to subsume DEP5 into Debian Policy.  The only plan
I've seen is to turn *maintenance* of the machine-readable copyright format
over to the Debian Policy process and to *ship* a copy of the spec in the
debian-policy package; we will still need a way to point to unique URLs in
the Format: field to distinguish between incompatible revisions, unless and
until DEP5 is incorporated into Debian Policy itself at a later date.

-- 
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: binNMU for Arch: all packages.

[Steve Langasek]

On Sat, Jan 15, 2011 at 01:53:34PM +0100, Bastian Blank wrote:
> On Sat, Jan 15, 2011 at 10:29:46AM +, Philipp Kern wrote:
> > Arch:all binNMUing will only work if you keep the invariant of
> > version(arch:all) = version(source) in some way.

> This invariant comes from where? From my knowledge neither w-b nor dak
> cares about it.

From the de facto policy that was designed when binNMUs became common
practice, to ensure that we had a usable, binNMU-safe scheme to replace the
prior (= ${Source-Version}) usage.

Permitting arch: all binNMUs will break the assumption underlying all (=
${source:Version}) dependency declarations in use across all our packages,
making them instantly buggy, and require us to use a hackish (>= ), (<< )
construction for all arch:any -> arch:all dependencies just as we already
have to do for arch:all -> arch:any dependencies.

I agree that it's far preferable to do source NMUs in these cases.

-- 
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: Skilled manpower vs. grunt work (was: Why is help so hard to find?)

[Neil Williams]

On Sun, 16 Jan 2011 08:33:56 +1100
Ben Finney  wrote:

> Neil Williams  writes:
> 
> > Can the rest of us now actually ask if there is anything we can do
> > to get more people involved in helping packaging teams which are
> > openly asking for help?
> […]
> 
> > The problem is a lack of manpower in critical teams. That's not new.
> 
> Is the requirement for manpower alone? I thought the problem was a
> lack of manpower with the appropriate specific skills.

Bug triage doesn't need huge amounts of package-specific skills. It
just needs the people doing triage to be able to cooperate with the
maintainer(s).

> For my part, the teams that appear to need help most desperately need
> people with good skills in specific areas I don't have.

That is always possible. I'm not going to start working on kernels or
haskell or KDE. It's not just the skill set - if you don't use a
package (as is my case with KDE), it's not a good choice for various
perfectly valid reasons.

> > If nobody is willing to do the grunt work of maintaining the
> > alternative, the alternative does not get maintained. That's
> > obvious, isn't it?
> 
> How much of it is grunt work?

Depends on the perspective - someone coming in to help from the outside
may find it challenging (and therefore potentially enjoyable) -
maintainers who have been working on the problems for a while it can be
grunt work.

Many of the necessary skills can be learnt IF the new people have
sufficient interest in the package concerned and the wisdom to get
along with the existing team.

> Is there a way for willing people, who
> lack the specific skills needed by the maintenance team, to bring more
> general programming and/or packaging skills to bear on the workload?

RFH bugs and general QA is the obvious place to start - once we're
released Squeeze. 

Bug triage can be a good way to learn how the package works and how the
team works.

> Is there an obvious way for people willing to do grunt work to help
> such teams (as opposed to the highly skilled work done by the core
> people in the maintenance team) to find that grunt work and begin
> contributing?

Skills can be learnt, taught and developed - the missing component is
the person who can work alongside the existing team without lecturing
those in the team and without pestering the team with newbie questions.
That's fun for the whole team.

The more hard-pressed the team, the harder it is for new people to
learn the ropes. There's no answer to that problem except that new
people must want to learn, not lecture.

No matter what your expertise, the packaging team has different
expertise and everyone needs to get along to fix the actual problem.

-- 


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



pgpiqhSkHMsVD.pgp
Description: PGP signature

Re: DEP5: CANDIDATE and ready for use in squeeze+1

[Stefano Zacchiroli]

[ Cc:-ing policy integration bug report ]

On Sat, Jan 15, 2011 at 01:51:23PM -0600, Steve Langasek wrote:
> There has been no plan to subsume DEP5 into Debian Policy.  The only plan
> I've seen is to turn *maintenance* of the machine-readable copyright format
> over to the Debian Policy process and to *ship* a copy of the spec in the
> debian-policy package;

Well, I was assuming that DEP5 was going to become an "associated text"
under policy §5.6.11 and, as such, subject to Standards-Version. That
would bring IMHO various benefits such as: 1) the possibility of
dropping Format:, 2) have a lintian check that doesn't need to preserve
yet another version-format mapping; 3) documentation of format changes
into upgrade-checklist.

Clearly you disagree with that assumption and Lars has voiced his
opinion in favor of a separate---and versioned---Format field as well.
So be it.

I still don't get how the versioned Format URL will look like once DEP5
will be shipped by debian-policy though. Would it use the Vcs-Browser of
the debian-policy package or ...? Just curious.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Can insserv made better?

[Mike Bird]

Hi Jesús,

On Sat January 15 2011 13:21:33 Jesús M. Navarro wrote:
> So the main problem is "only" transitioning the system, isn't it?  Why
> don't you have then a look at Squeeze's release notes (which any wise
> Debian system administrator will read upon upgrade) and make sure that it
> states the problem in the most clear way and/or propose the changes to that
> document that you percieve to be needed?  That would be feasible in current
> freeze condition of the distribution and it would be a good effort/benefit
> ratio for your effort.

I have looked at the release notes, what little documentation there
is, and much but not all of the source code.

It would certainly help if a warning were included in the release
notes but the most critical fix is to the misleading statement in
sysv-rc.postinst that enabling insserv is "recommended" with no
warning about the potential adverse consequences.

I have attached a proposed patch.

--Mike Bird

diff -ruN sysvinit-2.88dsf/debian/sysv-rc.templates sysvinit-2.88dsf.NEW/debian/sysv-rc.templates
--- sysvinit-2.88dsf/debian/sysv-rc.templates	2011-01-15 14:30:43.0 -0800
+++ sysvinit-2.88dsf.NEW/debian/sysv-rc.templates	2011-01-15 14:38:16.0 -0800
@@ -12,13 +12,18 @@
 Default: true
 _Description: Migrate legacy boot sequencing to dependency-based sequencing?
  The boot system is prepared to migrate to dependency-based sequencing.
- This is an irreversible step, but one that is recommended: it allows
- the boot process to be optimized for speed and efficiency, and provides
- a more resilient framework for development.
+ This is an irreversible step - restoring your /etc will not undo it.  It
+ affords slightly faster booting and a different framework for sequencing
+ system start up which some people prefer.  However it may not correctly
+ boot a complex system without further effort on your part.
  .
  A full rationale is detailed in /usr/share/doc/sysv-rc/README.Debian.
  If you choose not to migrate now, you can do so later by running
  "dpkg-reconfigure sysv-rc".
+ .
+ If you do need to manually reverse this irreversible step first
+ "touch /etc/init.d/.legacy-bootordering" and then the files in
+ /var/lib/update-rc.d will help you to recover most of the way.
 
 Template: sysv-rc/unable-to-convert
 Type: note

Re: Why is help so hard to find?

[Russ Allbery]

Chris Carr  writes:

> Is there some forum in which the choice of a default for a package or
> service gets made? I subscribe to debian-devel and debian-policy, but
> neither seems to contain discussions about the risks of replacing
> perfectly good defaults with significantly flawed ones.

debian-devel contained *extensive* discussions about dependency-based boot
and about insserv.  I'm not sure how you could have missed them.  Having
followed those discussions at the time, I'm pretty confident that the
switch was supported by the consensus of the people who chose to
participate in those discussions.

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

Re: Why is help so hard to find?

[Russ Allbery]

Tollef Fog Heen  writes:

> While I have no love for insserv, if you think the whole point of
> dependency based boot (be it insserv, upstart, systemd) is boot speed, I
> think you're mistaken.  It's a part of the goal, but much more important
> is actually correctness.  Getting the dependencies between init scripts
> correct is sometimes hard.

Amen.

I'm in favor of dependency-based boot despite not caring about boot speed
much at all.  I like dependency-based boot because, as a system
administrator, I can edit an init script, add a dependency on something
that I want to run first for my own reasons, and reconfigure the boot
sequence, and all the right things happen, including fiddling with the
granularity of the numbering if necessary.  Under the old system where all
the sequence numbers were defaults created by the package and were often
annoyingly clustered, this was significantly harder to do.

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

Bug#610189: ITP: scolasync -- graphic tool to copy data to or from a set of USB storage media

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: scolasync
  Version : 2.1
  Upstream Author : Georges Khaznadar 
* URL : http://georges.khaznadar.fr/docs/scolasync
* License : GPL3
  Programming Lang: Python
  Description : graphic tool to copy data to or from a set of USB storage 
media

 Teachers may use this package to manage a set of USB sticks owned by their
 students. The keys are recognized (with their owner's name), and the teachers
 can copy assignments to them ans retrieve consistently the homeworks from
 the usb sticks.



-- 
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/20110116000639.29046.39128.report...@photos.khaznadar.fr

Re: Can insserv made better?

[Olaf van der Spek]

On Sat, Jan 15, 2011 at 11:39 PM, Mike Bird  wrote:
> I have looked at the release notes, what little documentation there
> is, and much but not all of the source code.
>
> It would certainly help if a warning were included in the release
> notes but the most critical fix is to the misleading statement in
> sysv-rc.postinst that enabling insserv is "recommended" with no
> warning about the potential adverse consequences.

If insserv meses up so bad, shouldn't it be able to detect that things
will go wrong too?
Got a concrete example of a case that fails?

Olaf


-- 
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/AANLkTi=A1DBU10W5SQzeTq+0n0ybEX9Laf=h+8tqz...@mail.gmail.com

Re: Why is help so hard to find?

[Adam Borowski]

On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
> Roger Leigh  writes:
> > I've yet to find a single system which upgraded to insserv cleanly.
> > This is mostly due to removed packages which need fully purging to
> > remove the last traces of old init scripts which break the process.
> 
> Huh.  Every system I've upgraded had no problems.

I find this strange, since every system that has ever been etch will have
at least libdevmapper1.02 which stops insserv from migrating.

> What is the failure mode?  What happens on those systems?

You get a long scary message that makes people search what the heck is going
wrong, but no actual damage.  You just stay with the legacy ordering which
currently suffers only from rare corner cases and being undermaintained.

> > This has proven to be the case on every system I've migrated so far, and
> > it is a real pain to identify each offending script and then find which
> > package it belonged to and purge it.
> 
> dpkg -S would generally tell you, no?  We could document how to do that in
> the release notes.

Documenting would be good -- especially in the fail message rather than in
release notes few people read; however, I think it would be better to fix at
least the common cases.

Sadly, just having insserv Conflicts: the culprits is not enough, a fix
could be one of:
* an otherwise empty package that removes the rc scripts
* Conflicts:+Replaces: in insserv and overwriting the known-buggy scripts
  (a nasty hack)

I've suggested having an empty "libdevmapper1.02" before, but I guess I
didn't shout loud enough.  I still think it's better to inject it into
squeeze than to suffer people's confusion.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110116001708.ga28...@angband.pl

Re: Can insserv made better?

[Mike Bird]

On Sat January 15 2011 16:33:28 Olaf van der Spek wrote:
> If insserv meses up so bad, shouldn't it be able to detect that things
> will go wrong too?

insserv completely discards the Snn/Knn values and generates a new
boot ordering based on much less information and which consequently
fails more often.

If you want insserv not to mess up then the solution a to have
insserv generate dependencies from the Snn/Knn values and then
allow sysadmins to delete/disable dependencies that aren't relevant.
(I don't recommend this but it is a solution.)

> Got a concrete example of a case that fails?

We ran into the Apache-Bind problem and the RequestTracker-Apache-Mysql
problems and then stopped using insserv.  Fortunately we have good
sysadmins who can read the source code as insserv is mostly undocumented
and there is no policy on which overrides are for Debian packagers and
which are sysadmins so many future conflicts will arise there too.

If you check on bugs.debian.org you'll see many more.  I had to read
through nearly 400 bugs on sysv-rc before submitting a proposed fix [1].

As we no longer enable insserv this is no longer a problem for us.

It is, however, a big problem for Squeeze and it needs to be fixed.

--Mike Bird

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


-- 
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/201101151747.24174.mgb-deb...@yosemite.net

Re: DEP5: CANDIDATE and ready for use in squeeze+1

[gregor herrmann]

On Sat, 15 Jan 2011 23:38:12 +0100, Stefano Zacchiroli wrote:

> I still don't get how the versioned Format URL will look like once DEP5
> will be shipped by debian-policy though. Would it use the Vcs-Browser of
> the debian-policy package or ...? Just curious.

From the attached diff in the first message in #609160:

+ * **`Format`**
+   * Required
+   * Syntax: single line
+   * URI of the format specification, such as:
+ * http://www.debian.org/doc/standards/copyright-format/1.0.html


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Rod Stewart


signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Russ Allbery]

Adam Borowski  writes:
> On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:

>> Huh.  Every system I've upgraded had no problems.

> I find this strange, since every system that has ever been etch will
> have at least libdevmapper1.02 which stops insserv from migrating.

Judging from further discussion, it looks like the reason why I've never
seen this is that I routinely purge deinstalled packages on all my
systems and most of the problems are with packages that have been
deinstalled but not purged and have obsolete init scripts.  I wonder if we
should suggest people consider doing that before the upgrade if they don't
have any old configuration files around that they care about.

> * Conflicts:+Replaces: in insserv and overwriting the known-buggy scripts
>   (a nasty hack)

Given that they're conffiles, I don't think this will even work properly.

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

Re: Why is help so hard to find?

[Mike Bird]

On Sat January 15 2011 18:02:06 Russ Allbery wrote:
> Judging from further discussion, it looks like the reason why I've never
> seen this is that I routinely purge deinstalled packages on all my
> systems and most of the problems are with packages that have been
> deinstalled but not purged and have obsolete init scripts.  I wonder if we
> should suggest people consider doing that before the upgrade if they don't
> have any old configuration files around that they care about.

I don't think that will work, although I don't understand why.  Here's
an example from one of our upgrade tests.  The package is installed
but has obsolete conffiles and thereby caused insserv setup to fail.

--Mike Bird

# dpkg -s bittorrent
Package: bittorrent
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 588
Maintainer: Michael Janssen 
Architecture: all
Version: 3.4.2-11.3
Depends: python (>= 2.3), python-support (>= 0.90.0), lsb-base (>= 3.0-10)
Recommends: mime-support
Suggests: bittorrent-gui
Conffiles:
 /etc/init.d/bittorrent 128966d79d03469e179f57d6210f2b47 obsolete
 /etc/default/bittorrent 1a6947090e36f417eb508953794dc303 obsolete
Description: Original BitTorent client - console tools



-- 
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/201101151825.37388.mgb-deb...@yosemite.net

Suggest to purge removed packages with init scripts before squeeze upgrade (was: Why is help so hard to find?)

[gregor herrmann]

Package: release-notes
Severity: wishlist


On Sat, 15 Jan 2011 18:02:06 -0800, Russ Allbery wrote:

> > I find this strange, since every system that has ever been etch will
> > have at least libdevmapper1.02 which stops insserv from migrating.
> Judging from further discussion, it looks like the reason why I've never
> seen this is that I routinely purge deinstalled packages on all my
> systems and most of the problems are with packages that have been
> deinstalled but not purged and have obsolete init scripts.  I wonder if we
> should suggest people consider doing that before the upgrade if they don't
> have any old configuration files around that they care about.

Now that Adam mentioned it I remember that I at least met this
removed-but-configured libdevmapper1.02 on each machine which tried
to convert to dependency based init scripts. (I think most other
issues I had came from home-grown init scripts without LSB headers.
-- And I also tend to purge removed packages; but not packages that
were both installed and removed automatically ...)

Suggesting to purge libdevmapper1.02 and maybe other
removed/configured packages in the release notes' "preparation"
section might indeed be helpful.

Cheers,
gregor, cc'ing the BTS 
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Simply Red: Holding Back The Years


signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Russ Allbery]

Mike Bird  writes:
> On Sat January 15 2011 18:02:06 Russ Allbery wrote:

>> Judging from further discussion, it looks like the reason why I've
>> never seen this is that I routinely purge deinstalled packages on all
>> my systems and most of the problems are with packages that have been
>> deinstalled but not purged and have obsolete init scripts.  I wonder if
>> we should suggest people consider doing that before the upgrade if they
>> don't have any old configuration files around that they care about.

> I don't think that will work, although I don't understand why.  Here's
> an example from one of our upgrade tests.  The package is installed
> but has obsolete conffiles and thereby caused insserv setup to fail.

It's the responsibility of packages to clean up obsolete conffiles as
they're upgraded.  If you run into the case of a package that's been
upgraded and not cleaned up its obsolete conffiles, and there isn't some
reason for that, that's worth a bug report.  Too late for this release,
probably, of course

-- 
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/8739otr22e@windlord.stanford.edu

Re: Why is help so hard to find?

[Don Armstrong]

On Sat, 15 Jan 2011, Russ Allbery wrote:
> Judging from further discussion, it looks like the reason why I've
> never seen this is that I routinely purge deinstalled packages on
> all my systems and most of the problems are with packages that have
> been deinstalled but not purged and have obsolete init scripts. I
> wonder if we should suggest people consider doing that before the
> upgrade if they don't have any old configuration files around that
> they care about.

A possible hack would be to have insserv ignore any initscripts which
are conffiles which when run without options exit with zero status.
But this probably has some ugly consequences which aren't totally
obvious to me right this second.


Don Armstrong

-- 
"There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence."
 -- Jeremy S. Anderson

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/20110116034223.gm5...@teltox.donarmstrong.com

Re: Why is help so hard to find?

[Mike Bird]

On Sat January 15 2011 18:54:01 Russ Allbery wrote:
> It's the responsibility of packages to clean up obsolete conffiles as
> they're upgraded.  If you run into the case of a package that's been
> upgraded and not cleaned up its obsolete conffiles, and there isn't some
> reason for that, that's worth a bug report.  Too late for this release,
> probably, of course

That test box alone has 48 obsolete conffiles belonging to
19 installed packages.  And I'm not sure if current package
maintainers would look favorably on bugs filed regarding
obsolete conffiles left by previous versions of packages.

I wonder if there is anything that should be done at the dpkg
level to prevent obsolete conffiles remaining after an upgrade?

Clearly a gnarly dpkg-query pipe could rm them, although I
worry that there might be unintended side effects.

In any event, I don't think we need to worry about them at
this stage of the release cycle.

--Mike Bird


-- 
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/201101152059.07452.mgb-deb...@yosemite.net

Re: Why is help so hard to find?

[Michael Biebl]

On 16.01.2011 03:54, Russ Allbery wrote:

> It's the responsibility of packages to clean up obsolete conffiles as
> they're upgraded.  If you run into the case of a package that's been
> upgraded and not cleaned up its obsolete conffiles, and there isn't some
> reason for that, that's worth a bug report.

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

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why is help so hard to find?

[Michael Biebl]

On 16.01.2011 05:59, Mike Bird wrote:
> 
> That test box alone has 48 obsolete conffiles belonging to
> 19 installed packages.  And I'm not sure if current package
> maintainers would look favorably on bugs filed regarding
> obsolete conffiles left by previous versions of packages.

If you do encounter such packages, please *do* file bugs.

Imho there are very few cases where it makes sense to keep obsolete conffiles
and for the majority not removing them on upgrades is a valid bug.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why is help so hard to find?

[Michael Biebl]

On 15.01.2011 21:57, Tollef Fog Heen wrote:
> ]] Mike Bird 
> 
> Hi,
> 
> | insserv is also irreversible, and if you restore /etc from
> | a backup without undocumented magic, insserv will destroy /etc
> | again.  That in my book seriously limits its compatibility.
> | 
> | For servers which may only be rebooted once a year, a second
> | saved in boot time is not worth the hassle, or even the mere
> | risk of hassle, due to actual or potential damage from insserv.
> 
> While I have no love for insserv, if you think the whole point of
> dependency based boot (be it insserv, upstart, systemd) is boot speed, I
> think you're mistaken.  It's a part of the goal, but much more important
> is actually correctness.  Getting the dependencies between init scripts
> correct is sometimes hard.

Completely agreed. The focus of dependency based boot is correctness.
The old system with static start/stop priorities was a pain to maintain and
actually had many bugs which were effectively impossible to change, because
changing the priority of *one* package can lead to a domino effect of required
changes to a *lot* of packages. With the dependency based system only a single
package needs to be fixed.

And to re-iterate what has already been said: if you do find scenarios where the
ordering is incorrect, please *do* file bugs. Such bugs are valuable.
Fixing incorrect orderings is actually quite simple now.

Please also follow the instructions on [1] and tag those bugs appropriately.

Michael

[1] http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
-- 
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

ObsoleteConffilesOfInstalledPackages

[Mike Bird]

Some people have expressed interested in obsolete config files
associated with currently installed packages.

Here's a (slow) script for finding them, plus the merged results
of running the script on a dozen servers and workstations - mostly
Lenny and a few Squeeze.

Output is space delimited, four fields:
debian-release package-name package-version obsolete-conffile

--Mike Bird


ObsoleteConffilesOfInstalledPackages
Description: application/shellscript
5.0.7 acpi-support 0.109-11 /etc/acpi/resume.d/13-915-resolution-set.sh
5.0.7 acpi-support 0.109-11 /etc/acpi/resume.d/49-915-resolution-set.sh
5.0.7 apache2.2-common 2.2.9-10+lenny9 
/etc/apache2/mods-available/sick-hack-to-update-modules
5.0.7 base-files 5lenny8 /etc/nsswitch.conf
5.0.7 bash 3.2-4 /etc/bash_completion
5.0.7 bind9 1:9.6.ESV.R3+dfsg-0+lenny1 /etc/apparmor.d/apparmor-profile
5.0.7 bittorrent 3.4.2-11.1 /etc/default/bittorrent
5.0.7 bittorrent 3.4.2-11.1 /etc/init.d/bittorrent
5.0.7 bluez-utils 3.36-3 /etc/modprobe.d/bluez
5.0.7 bluez-utils 3.36-3 /etc/modutils/bluez
5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Editres.ad
5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Emacs.ad
5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/General.ad
5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Motif.ad
5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Tk.ad
5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Xaw.ad
5.0.7 clamav-daemon 0.96.5+dfsg-1~volatile1 /etc/default/clamav-daemon
5.0.7 clamav-freshclam 0.96.5+dfsg-1~volatile1 /etc/logrotate.d/clamav-freshclam
5.0.7 desktop-file-utils 0.15-1 /etc/gnome/defaults.list
5.0.7 e2fsprogs 1.41.3-1 /etc/e2fsck.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/20-lohit-gujarati.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/30-amt-aliases.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/40-generic.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/README
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/autohint.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/no-bitmaps.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/no-sub-pixel.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/sub-pixel.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/unhinted.conf
5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/yes-bitmaps.conf
5.0.7 freeradius 2.0.4+dfsg-6 /etc/freeradius/oraclesql.conf
5.0.7 freeradius 2.0.4+dfsg-6 /etc/freeradius/x99.conf
5.0.7 freeradius 2.0.4+dfsg-6 /etc/freeradius/x99passwd.sample
5.0.7 gconf2 2.22.0-1 /etc/gconf/2/path
5.0.7 gksu 2.0.0-8 /etc/gksu.conf
5.0.7 gnome-games 1:2.22.3-3 /etc/sound/events/gnibbles.soundlist
5.0.7 gnome-games 1:2.22.3-3 /etc/sound/events/gnobots2.soundlist
5.0.7 gnome-games 1:2.22.3-3 /etc/sound/events/iagno.soundlist
5.0.7 gnome-menus 2.22.2-4 /etc/xdg/menus/applications.menu
5.0.7 gnome-menus 2.22.2-4 /etc/xdg/menus/preferences.menu
5.0.7 gnome-menus 2.22.2-4 /etc/xdg/menus/settings.menu
5.0.7 gnome-panel-data 2.20.3-5 
/etc/gnome-vfs-2.0/vfolders/applications.template
5.0.7 gnome-panel-data 2.20.3-5 /etc/menu-methods/gnome-panel-data
5.0.7 gnome-panel-data 2.20.3-5 /etc/menu-methods/gnome-vfolder-user
5.0.7 gnome-system-tools 2.22.0-4 /etc/gnome-system-tools/users/profiles.xml
5.0.7 hal 0.5.11-8 /etc/dev.d/block/hal-unmount.dev
5.0.7 hdparm 8.9-3 /etc/dev.d/block/hdparm.dev
5.0.7 icedove 2.0.0.24-0lenny1 /etc/icedove/global-config.js
5.0.7 iceweasel 3.0.6-3 /etc/iceweasel/profile/search.rdf
5.0.7 initramfs-tools 0.92o /etc/initramfs-tools/modules
5.0.7 java-common 0.30 /etc/jvm
5.0.7 kcontrol 4:3.5.9.dfsg.1-6+lenny1 /etc/hotplug/usb/logitechmouse
5.0.7 kcontrol 4:3.5.9.dfsg.1-6+lenny1 /etc/hotplug/usb/logitechmouse.usermap
5.0.7 kdemultimedia-kappfinder-data 4:3.5.9-2 
/etc/xdg/menus/kde-applications-merged/kde-multimedia-music.menu
5.0.7 libapache2-mod-perl2 2.0.4-5+lenny1 /etc/apache2/mods-available/perl.conf
5.0.7 libgeoip1 1.4.4.dfsg-3+lenny1 /etc/GeoIP.conf.default
5.0.7 libgphoto2-2 2.4.1-3 /etc/hotplug/usb/libgphoto2
5.0.7 libgphoto2-2 2.4.1-3 /etc/udev/libgphoto2_generic_ptp_support.rules
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/apt.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/dhcp.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/disk.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/dummy.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/ftp.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/http.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/load.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/mail.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/news.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/ntp.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/ping.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios-plugins/config/procs.cfg
5.0.7 nagios-plugins-basic 1.4.12-5 /etc/nagios