Re: Why is help so hard to find?

[Chris Carr]

On Sat, 2011-01-15 at 13:07 +0200, Andrei Popescu wrote:
> 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?

Certainly not. There was an exchange in this thread about the pros and
cons of insserv during which it was acknowledged that there are some
significant issues with insserv. The previous paradigm may have been a
"pain in the rear", but from the perspective of some proportion of users
it was perfectly good. My assumption is that the issues with insserv
were known before the decision to roll it out in Testing was made - my
curiosity is about where those discussions took place.

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

I am more interested in the discussions which precede the announcement,
but thank you for the advice. Thanks also to Lars and Jonathan for their
helpful responses.

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

hii friends

[deepahosting Solutions]

hee  friends
plzz  add  this  id  for
link  exchange.
outsource project

www.deepahosting.com

Re: Why is help so hard to find?

[Marc Haber]

On Sat, 15 Jan 2011 18:02:06 -0800, Russ Allbery 
wrote:
>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

$ cat lennyupdate/update.d/060_dpkg-purge-removed 
#!/bin/bash

echo "purge removed packages"
dpkg --purge $(dpkg --list | grep  '^rc' | awk '{print $2}') foo

RESULT="done"

# end of file

Good to hear that I won't be having _this_ problem.

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/e1peqon-0006lp...@swivel.zugschlus.de

Lighting Fixtures - Luminaires

[electricals designing]

New products for lighting applications!
 
Post-top and radial-waves overhead CutOff luminaires (lighting fixtures), as 
well low-voltage overhead fixtures are already available now. Please look-up at 
all. 

http://post-top.electrical-contractor.net/ds_posttop_stand/sect_view_cutoff/pack_pt_sect.html
 
Standard "Post-top" full open details !!

 


From: electricals_design...@hotmail.com
To: debian-devel@lists.debian.org
Subject: Luminaires
Date: Sun, 16 Jan 2011 21:27:10 +1100




 
New products for lighting applications!
 
Post-top and radial-waves overhead CutOff luminaires (lighting fixtures), as 
well low-voltage overhead fixtures are already available now. Please look-up at 
all. 
 
http://www.post-top.serversway.com/ds_posttop_stand/mapsect1.html
 
  Standard "Post-top" full open details !!

  

Re: Why is help so hard to find?

[Hans-J. Ullrich]

Am Sonntag, 16. Januar 2011 schrieb Marc Haber:
> On Sat, 15 Jan 2011 18:02:06 -0800, Russ Allbery 
> 
> wrote:
> >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
> 
> $ cat lennyupdate/update.d/060_dpkg-purge-removed
> #!/bin/bash
> 
> echo "purge removed packages"
> dpkg --purge $(dpkg --list | grep  '^rc' | awk '{print $2}') foo
> 
> RESULT="done"
> 
> # end of file
> 
> Good to hear that I won't be having _this_ problem.
> 
> Greetings
> Marc

Hi Marc,

I believe "aptitude purge ~c" does the same. Also you might want to take a 
look at "orphaner" or "deborphan" to get rid of orphaned libs.

Using those regularly I keep my system clean now since debian sarge.

Good luck!

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

Re: "Mass" (non invasive) NMUs planned to fix debconf translations broken in multiple packages

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):
> Quoting Christian PERRIER (bubu...@debian.org):
> 
> > I have ready NMUs for most of the affeted packages. I can upload them
> > soon.
> 
> My plans are to upload before the end of the upcoming week-end an NMU
> for each of the affected package(s).

This happened yesterday.

A few packages were uploaded in t-p-u, when unstable had a newer
upstream version that never entered testing.

Unblocks have been requested for packages uploaded to unstable. I did
nothing special for packages uploaded to t-p-u as my understanding is
that they're monitored by the release team anyway.




signature.asc
Description: Digital signature

Re: Why is help so hard to find?

[Marc Haber]

On Sun, 16 Jan 2011 12:14:45 +0100, "Hans-J. Ullrich"
 wrote:
>I believe "aptitude purge ~c" does the same.

I avoid using aptitude for non-interactive things since I am falling
over two annoying bugs in aptitude for months without seeing them
fixed.

> Also you might want to take a 
>look at "orphaner" or "deborphan" to get rid of orphaned libs.

I regularly use debfoster to keep the systems clean.

Greetings
Marc, still hating the idea of migrating head- and consoleless servers
in remote, non-enterable locations to insserv
-- 
-- !! 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/e1peqgc-00076t...@swivel.zugschlus.de

Re: Why is help so hard to find?

[Bjørn Mork]

Michael Biebl  writes:

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

Although I do agree with the improved simplicity, I do not agree that
*all* incorrect orderings are simple to fix (or necessarily package
bugs).  Unfortunately, there are some packages which require system
dependent ordering.  The most obvious example is the set packages
modifying the block device layers.  Do you run LVM on top of LUKS on top
of MD, or was it the other way round?  



Bjørn


-- 
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/87lj2lax0f@nemi.mork.no

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

[Christoph Anton Mitterer]

On Fri, 2011-01-14 at 07:58 +0900, Charles Plessy wrote:
> In the candidate version of the DEP, it is not recommended anymore to add an 
> X-
> prefix to extra fields.
btw: Why was this removed? Adding the X- is not only conventional style
in email headers and many other RFCs but also (in a similar form) by the
Debian Policy with respect to control files.

And it would make parsing a lot more easier, even if it's possible to
find out by the revision what's "official" and what not in a given
version.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

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

[Christoph Anton Mitterer]

On Fri, 2011-01-14 at 12:09 -0400, Joey Hess wrote:
> 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.
I've also stumbled across this, and I guess the same is true for
Disclaimer,...

Can DEP5 perhaps be clarified with respect to such things? And maybe
useing RFC2119 MUSTs, SHOULDs, etc.

I've also wondered whether it is allowed (or not), when having a Files
paragraph, that contains the verbatim license (not referring to a
standalone License tag), e.g.:
>Files: *
>License: FOO
> This is my wonderful license.
...to omit the first line synopsis:
>Files: *
>License: 
> This is my wonderful license.
... and if so, whether a " " should follow the "License:" or not.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

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

[Christoph Anton Mitterer]

Oh, and I've also would like to see the "X-" on personal license short
names.


Perhaps one could also add a namespace that is "privately" managed, but
still global, e.g. in the style of:
"org.example.license.foobar"
Specifying globally unique a license "foobar" from Example Org.

But not sure whether this is really necessary.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Can insserv made better?

[Olaf van der Spek]

On Sun, Jan 16, 2011 at 2:47 AM, Mike Bird  wrote:
> 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.

AFAIK insserv doesn't guess. "Much less info" is the dependencies
listed in the scripts themselves, right? Isn't this enough?
Is the problem insserv itself or wrong dependency lists?

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

Re: Why is help so hard to find?

[Olaf van der Spek]

On Sun, Jan 16, 2011 at 3:54 AM, 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

Shouldn't this be the responsibility of the package manager?
Otherwise it sounds like a big code duplication problem.

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/AANLkTincbMNFysJ=m4r-sj9qryasmw2kk22eth0e0...@mail.gmail.com

Re: Skilled manpower vs. grunt work

[Chris Carr]

On 15/01/2011 22:18, Neil Williams wrote:

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

[snip]

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.


I have had two experiences in this area: wanting to help get dmraid 
support added to d-i (2003-7) and wanting to add a new package to debian 
(#576029, which is now ready for upload). I am a competent sysadmin, but 
a novice programmer. In both cases I ended up "pestering the team with 
newbie questions" because of the complexities of d-i and of packaging, 
respectively - not because I was unintelligent or unmotivated, nor 
because I had failed to read the available docs.


I would welcome advice on how non-programmers should approach working 
with volunteer maintainers who have vastly more knowledge and skill than 
we do. To me it seems a bit like trying to play squash with a pro: it's 
no fun for them, but if you don't have anyone intermediate to practice 
with, you'll never get better.


I would happily volunteer to do bug triaging on certain packages, as I 
am certain I possess the skills to do this. Is it as simple as emailing 
the maintainer(s) and offering?


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/4d32e81a.5050...@gmail.com

Re: Why is help so hard to find?

[Chris Carr]

On 15/01/2011 23:50, Russ Allbery wrote:

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.


In which case I am in the right place, but simply not paying enough 
attention. My apologies for the noise.


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/4d32e845.3030...@gmail.com

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

[Charles Plessy]

Le Sun, Jan 16, 2011 at 01:12:46PM +0100, Christoph Anton Mitterer a écrit :
> On Fri, 2011-01-14 at 07:58 +0900, Charles Plessy wrote:
> > In the candidate version of the DEP, it is not recommended anymore to add 
> > an X-
> > prefix to extra fields.
> btw: Why was this removed? Adding the X- is not only conventional style
> in email headers and many other RFCs but also (in a similar form) by the
> Debian Policy with respect to control files.

Here is an URL to the latest discussion:

http://lists.debian.org/20101114023744.ga4...@merveille.plessy.net

An immediate advantage is that if a field is becoming popular and incorporated
in a revision of the DEP, tools will not have to be modified to deal with it.

The X[SBC]- prefixes in debian/control are different in nature. They indicate
to dpkg in which derived file the extra fields have to be propagated: the
source (S), changes (C) or binary (B) file. In these files, the X[SBC]- is
stripped. For instance, when the Homepage field was introduced, it was
XS-Homepage in debian/control, but Homepage in the source control (.dsc) file.
And it is in this file and its derivatives that parsers, from the very
befinning of the introduction, look for a Homepage field, with no prefix.

Given that there are only 9 different fields in the current DEP-5 syntax, I
think that parsers can simply incorporate the full list of them rather than
rely on a X- prefix to determine if a field is in the specification or not.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110116124855.ge28...@merveille.plessy.net

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

[Charles Plessy]

Le Sat, Jan 15, 2011 at 11:38:12PM +0100, Stefano Zacchiroli a écrit :
> 
> 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.

Note that there is at least one other control data file that has a Format field
whose version is independant of the Policy's version number, the Debian changes
files: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Format

There is another reason why I would not support an alignment on the Policy's
version number: from the begining we promised that DEP-5 was not an attempt to
modify the Policy. Even if it did not make a practical consequence, I think
that it would be appropriate to not go further than shipping the DEP and the
Policy in the same package. If in a second and separate step there is a
consensus for merging, I would be very pleased, but I really think that it
should be after a large number of packages use the DEP, and after parsers
produce data of which the benefits are widely recognised.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110116130141.gf28...@merveille.plessy.net

Re: Skilled manpower vs. grunt work

[Neil Williams]

On Sun, 16 Jan 2011 12:44:10 +
Chris Carr  wrote:

> > 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).
> [snip]
> >> 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.
> 
> I have had two experiences in this area: wanting to help get dmraid 
> support added to d-i (2003-7) and wanting to add a new package to
> debian (#576029, which is now ready for upload). I am a competent
> sysadmin, but a novice programmer. In both cases I ended up
> "pestering the team with newbie questions" because of the
> complexities of d-i and of packaging, respectively - not because I
> was unintelligent or unmotivated, nor because I had failed to read
> the available docs.

Sounds like the docs need to be improved (no surprise there).

Perhaps the best thing to do at this stage is to seek a different forum
for your newbie questions - mentors.debian.net may be one place, a local
LUG may also be useful. Google, as ever, is your friend too as most of
these problems have been solved before.

> I would welcome advice on how non-programmers should approach working 
> with volunteer maintainers who have vastly more knowledge and skill
> than we do. 

Filing bugs about the docs and discussing things at a level of "these
docs don't make sense to me as a newbie because the docs are, as ever,
written by the packaging team who know all the hidden assumptions
already" will make more sense than asking the questions to the
maintainers directly.

Providing a test case which is accessible to the maintainers is usually
a huge bonus. Nothing makes bugs harder than the maintainer(s) not
being able to reproduce your problem themselves. Maybe it would be a
simple script or even an account on the machine concerned.

> To me it seems a bit like trying to play squash with a
> pro: it's no fun for them, but if you don't have anyone intermediate
> to practice with, you'll never get better.

These things take time. (Then you might be able to be the intermediate
to help the next newbie.) If your motivation doesn't last as long as
the amount of learning required, there are plenty of other issues to
select.

> I would happily volunteer to do bug triaging on certain packages, as
> I am certain I possess the skills to do this. Is it as simple as
> emailing the maintainer(s) and offering?

My whole point in all of this is that the entire process takes time and
the current team will have a lot more time for you if you put in the
time to bring yourself up to speed with the team. Meritocracy - do the
work and those who you ask for help will have more time for your
questions.

-- 


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



pgpqYPrm95iIc.pgp
Description: PGP signature

Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: python-exif
  Version : 1.0.8
  Upstream Author : Ianar$(D+1(B S$(D+1(Bvi
* URL or Web page : http://sourceforge.net/projects/exif-py/
* License : BSD
  Description : Python library to extract EXIF data from tiff and jpeg files
Python library to extract EXIF data from tiff and jpeg files. Very easy to use 
- $ ./EXIF.py image.jpg. Originally written by Gene Cash / Thierry Bousch.



-- 
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/87k4i5klp2.wl%tak...@asis.media-as.org

Re: Can insserv made better?

[Konstantin Khomoutov]

On Sat, Jan 15, 2011 at 05:47:24PM -0800, Mike Bird wrote:

[...]
>> 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.
This one was reported and solved thanks to RT maintainers:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595054

[...]


-- 
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/20110116143722.GT5713@localhost.localdomain

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

[Dominique Dumont]

Le dimanche 16 janvier 2011 13:48:55, Charles Plessy a écrit :
> Given that there are only 9 different fields in the current DEP-5 syntax, I
> think that parsers can simply incorporate the full list of them rather than
> rely on a X- prefix to determine if a field is in the specification or not.

Sure. The only hitch is that the parser cannot distinguish between an extra 
field and a typo.

All the best.

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.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/201101161613.24844.domi.dum...@free.fr

Re: Why is help so hard to find?

[Tollef Fog Heen]

]] Bjørn Mork 

Hi,

| Although I do agree with the improved simplicity, I do not agree that
| *all* incorrect orderings are simple to fix (or necessarily package
| bugs).  Unfortunately, there are some packages which require system
| dependent ordering.  The most obvious example is the set packages
| modifying the block device layers.  Do you run LVM on top of LUKS on top
| of MD, or was it the other way round?

If you do this from the init scripts, you can't have non-trivial
ordering anyway and you want udev or something processing hotplug events
for this.

(Nontrivial ordering being X on Y on X.)

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


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

Re: Why is help so hard to find?

[Raphael Hertzog]

On Sun, 16 Jan 2011, Olaf van der Spek wrote:
> On Sun, Jan 16, 2011 at 3:54 AM, 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
> 
> Shouldn't this be the responsibility of the package manager?
> Otherwise it sounds like a big code duplication problem.

man dpkg-maintscript-helper

Olaf, I appreciate you are trying to help. But you are discussing too much
and doing too few research before posting mails over here.


When a thread gets to the point where 3 non-packagers are discussing (and
sometimes bashing) together the work of other Debian contributors, it's a
big FAIL.



Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110116164941.gf17...@rivendell.home.ouaza.com

Re: Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files

[D*-(Biha$(D+Z(B]

Hi

Dne Sun, 16 Jan 2011 22:44:09 +0900
TANIGUCHI Takaki  napsal(a):

> Package: wnpp
> Owner: tak...@debian.org
> Severity: wishlist
> 
> * Package name: python-exif
>   Version : 1.0.8
>   Upstream Author : Ianar$(D+1(B S$(D+1(Bvi
> * URL or Web page : http://sourceforge.net/projects/exif-py/
> * License : BSD
>   Description : Python library to extract EXIF data from tiff and jpeg 
> files
> Python library to extract EXIF data from tiff and jpeg files. Very easy to 
> use - $ ./EXIF.py image.jpg. Originally written by Gene Cash / Thierry Bousch.

Does it really make sense to package EXIF library, which is two years
dead and does not support any recently made cameras? Would not be
better to rather use something alive like pyexiv2?

-- 
Michal $(D*-(Biha$(D+Z(B | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Can insserv made better?

[Mike Bird]

On Sun January 16 2011 04:40:02 Olaf van der Spek wrote:
> AFAIK insserv doesn't guess. "Much less info" is the dependencies
> listed in the scripts themselves, right? Isn't this enough?

That is correct.  However there are far fewer dependencies
listed in the headers than implicit in the Snn/Knn numbers,
so some but not all previously working systems are broken.

> Is the problem insserv itself or wrong dependency lists?

The problem is wrong thinking.  Snn/Knn implicitly contain
many dependencies which are not needed on most systems, so
they are not included in the scripts.  However removing
those dependencies breaks some but not all systems.

That is why people should be given accurate information in
order to be able to make an informed choice, instead of
being tricked into using insserv and breaking their systems.

I filed a bug[1] with a simple patch[2] to give people fair
notice of the pros and cons of insserv but unfortunately
Julien Cristau simply closed the bug without explanation[3].

--Mike Bird

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610185
[2] 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=sysv-rc-postinst-clarification.patch;att=1;bug=610185
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=7;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/201101161048.24614.mgb-deb...@yosemite.net

Bug#610253: ITP: timeago -- jQuery plugin providing live-updated fuzzy timestamps

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: timeago
  Version : 0.9.2
  Upstream Author : Ryan McGeary 
* URL : http://timeago.yarp.com/
* License : Expat
  Programming Lang: JavaScript
  Description : jQuery plugin providing live-updated fuzzy timestamps

 Timeago is a jQuery plugin that makes it easy to support automatically
 updating fuzzy timestamps (e.g. "4 minutes ago" or "about 1 day ago")
 from ISO 8601 formatted dates and times embedded in your HTML (à la
 microformats).



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

Bug#610259: ITP: json-js -- JSON encoders/decoders implemented in JavaScript

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: json-js
  Version : 0~20101208
  Upstream Author : Douglas Crockford 
* URL : http://www.json.org/js.html
* License : PD
  Programming Lang: JavaScript
  Description : JSON encoders/decoders implemented in JavaScript

 JSON is a light-weight, language independent, data interchange format.
 See http://www.JSON.org/
 .
 The files in this collection implement JSON encoders/decoders in
 JavaScript.
 .
 JSON became a built-in feature of JavaScript when the ECMAScript
 Programming Language Standard - Fifth Edition was adopted by the ECMA
 General Assembly in December 2009. Most of the files in this collection
 are for applications that are expected to run in obsolete web browsers.



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

Re: ObsoleteConffilesOfInstalledPackages

[Roger Leigh]

On Sat, Jan 15, 2011 at 11:52:34PM -0800, Mike Bird wrote:
> 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

The main problem with this script is that all it does is spit out
the available information.  It doesn't actually check if the user
modified one of the conffiles.  An example is attached.  Modifying
it to automatically purge "safe" packages where the user made no
modifications would be fairly trivial.

-- 
  .''`.  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.
#!/bin/sh
#
# Check if a package may safely be purged.  A package is considered
# safe to purge if none of its conffiles have been changed from the
# default (i.e. its MD5SUMS match the original).
#
# Copyright © 2011  Roger Leigh 
#


set -e

dpkg --get-selections | grep 'deinstall$' | awk '{print $1}' | while read pkg
do
echo "Checking $pkg..."

(dpkg-query -W -f '${Conffiles}' "$pkg"; echo '') | while read line
do
if [ -n "$line" ]; then
FILE="$(echo "$line" | sed -e 
's/^[[:space:]]*\([[:print:]][[:print:]]*\)[[:space:]][[:space:]]*\([0-9a-f][0-9a-f]*\).*/\1/')"
OLDMD5="$(echo "$line" | sed -e 
's/^[[:space:]]*\([[:print:]][[:print:]]*\)[[:space:]][[:space:]]*\([0-9a-f][0-9a-f]*\).*/\2/')"
NEWMD5="$(md5sum "$FILE" | sed -e 
's/^\([0-9a-f][0-9a-f]*\)[[:space:]][[:space:]]*\([[:print:]][[:print:]]*\)$/\1/')"

echo -n "$FILE"
if [ "$OLDMD5" != "$NEWMD5" ]; then
echo ' keep'
else
echo ' purge'
fi
fi
done
done

signature.asc
Description: Digital signature

Re: ObsoleteConffilesOfInstalledPackages

[Mike Bird]

On Sun January 16 2011 12:15:18 Roger Leigh wrote:
> The main problem with this script is that all it does is spit out
> the available information.  It doesn't actually check if the user
> modified one of the conffiles.  An example is attached.  Modifying
> it to automatically purge "safe" packages where the user made no
> modifications would be fairly trivial.

Hi Roger,

There are no removed packages on our systems.  Obsolete conffiles
are unused and unusable, whether or not modified by the sysadmin.

The obsolete conffiles here belong to properly installed packages.

This data was collected not with a view to purging packages but
rather with a view to determining the prevalance of the problem
and ultimately a low-priority mass bug filing.

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

Re: Can insserv made better?

[Roger Leigh]

On Sat, Jan 15, 2011 at 05:47:24PM -0800, Mike Bird wrote:
> 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.)

This is complete and utter rubbish.  Please consider whether what you
are writing is adding anything useful or constructive before wasting
the time of all the people reading this list.  This is factually
incorrect, adds nothing new to the discussion, and the last paragraph
is just provocative trolling.  Bringing legitimate problems to our
attention in a non-provocative and constructive manner is acceptable;
pointless trolling is *not*.

You're saying that an unwieldy ad-hoc fixed list of numbers and names
is superior to detailed dependency information…  This is patently
untrue.

But whatever you personally believe, the reality is that the broad
consensus of the project has been to move to a dependency-based
boot system, and this was done nearly *18 months* ago.  At this point
complaining will achieve nothing: if you find any remaining dependency
issues the solution is to report bugs so that the issues are fixed.
We *have* moved to a dependency-based boot system, and you really don't
have a say in the matter at this point.  It's *done*, and you'll have
to live with it.

Your (rejected) patch was not addressing the issue.  Documenting the
pros and cons of moving to dependency-based boot is entirely beside the
point: we have moved to dependency-based boot.  *Your* choice is not if
to move, but when.  I can't say I'm the biggest fan of insserv myself,
but that's what is currently supported, and if you want something
different, then you'll need to step up and start doing the work
yourself.  I do hope we'll have systemd (preferred) or upstart
post-squeeze, but I don't see /any/ value in returning to fixed-order
scripts: we lived with their multitude of deficiencies for decades,
and now we have a working solution to that.  Your efforts would be best
focussed on finding, fixing and reporting any issues which are causing
you problems, not griping about decisions which were already taken.  It
was changed in July 2009 for crying out loud!  You've had 18 months to
report any issues…


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: Can insserv made better?

[Mike Bird]

On Sun January 16 2011 12:49:20 Roger Leigh wrote:
> You're saying that an unwieldy ad-hoc fixed list of numbers and names
> is superior to detailed dependency information…  This is patently
> untrue.

No, I'm saying that Snn/Knn values boot some systems where
insserv fails.  Therefore Snn/Knn is superior in some cases.
I readily concede that insserv is superior in some cases.

In order to avoid breaking Debian systems we should give
people a balanced overview of the pros and cons rather
than blindly telling them that insserv is "recommended"
when it is unnecessary and may break their systems.

I'm not asking for insserv to be removed.  I'm asking
that Debian users be given accurate information upon
which to base their decisions rather than dangerously
misleading information.

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

Re: Can insserv made better?

[Jesús M. Navarro]

Hi, Mike:

On Sunday 16 January 2011 19:48:24 Mike Bird wrote:
[...]

> I filed a bug[1] with a simple patch[2] to give people fair
> notice of the pros and cons of insserv but unfortunately
> Julien Cristau simply closed the bug without explanation[3].

Regarding your patch, I find the first part of it being quite to the point 
while the second paragraph is unneeded as long as the information is included 
in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be added to 
the package, maybe rewritten like this:

"This is an irreversible step.  While it is recommended because It allows the 
boot process to be optimized for speed and efficiency providing a more 
resilient framework for development, it may not correctly transition in 
complex systems without further effort on your part."

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

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

[Ben Finney]

Charles Plessy  writes:

> There is another reason why I would not support an alignment on the
> Policy's version number: from the begining we promised that DEP-5 was
> not an attempt to modify the Policy.

I don't recall that promise ever being made. Where did you see it?

The promise in the first revision of the wiki page for discussion was
“This is not a proposal to change the policy in the short term.”
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=1>

That leaves open, intentionally in my view, the option to become a
proposal to change Policy when it later became appropriate. The DEP
process seems a good route to achieveing that.

> If in a second and separate step there is a consensus for merging, I
> would be very pleased, but I really think that it should be after a
> large number of packages use the DEP, and after parsers produce data
> of which the benefits are widely recognised.

+1 to all that.

-- 
 \ “Oh, I realize it's a penny here and a penny there, but look at |
  `\  me: I've worked myself up from nothing to a state of extreme |
_o__)  poverty.” —Groucho Marx |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y66k7aim@benfinney.id.au

Re: Can insserv made better?

[Mike Bird]

On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote:
> Regarding your patch, I find the first part of it being quite to the point
> while the second paragraph is unneeded as long as the information is
> included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it should be
> added to the package, maybe rewritten like this:
>
> "This is an irreversible step.  While it is recommended because It allows
> the boot process to be optimized for speed and efficiency providing a more
> resilient framework for development, it may not correctly transition in
> complex systems without further effort on your part."

That's an excellent suggestion.  Would you care to post it to #610185[1]
to be sure the maintainer sees it?

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

Re: Skilled manpower vs. grunt work

[Serafeim Zanikolas]

On Sun, Jan 16, 2011 at 12:44:10PM +, Chris Carr wrote [edited]:
> In both cases I ended up "pestering the team with newbie questions" because
> of the complexities of d-i and of packaging, respectively - not because I
> was unintelligent or unmotivated, nor because I had failed to read the
> available docs.

The new maintainer's guide has a section on "Where to ask for help", which,
amongst others, mentions the debian mentors mailing list.

> I would happily volunteer to do bug triaging on certain packages, as
> I am certain I possess the skills to do this. Is it as simple as
> emailing the maintainer(s) and offering?

Yes, by all means go ahead (preferably picking up specific bugs, instead of
just asking "How can I help")

-S


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

Re: Bug#610234: ITP: python-exif -- Python library to extract EXIF data from tiff and jpeg files

[TANIGUCHI Takaki]

Hi, 

I submitted ITP for simple-image-reducer (#607237). That depends on
python-exif, if python-exif has not good support, anyway I need this
package.

Regards,
Takaki

> On Sun, 16 Jan 2011 19:07:05 +0100
> Michal.$ (D*-(Biha$(D+Z(B   said:
> 
> [1  ]
> Hi
> 
> Dne Sun, 16 Jan 2011 22:44:09 +0900
> TANIGUCHI Takaki  napsal(a):
> 
> > Package: wnpp
> > Owner: tak...@debian.org
> > Severity: wishlist
> > 
> > * Package name: python-exif
> >   Version : 1.0.8
> >   Upstream Author : Ianar$(D+1(B S$(D+1(Bvi
> > * URL or Web page : http://sourceforge.net/projects/exif-py/
> > * License : BSD
> >   Description : Python library to extract EXIF data from tiff and jpeg 
> > files
> > Python library to extract EXIF data from tiff and jpeg files. Very easy to 
> > use - $ ./EXIF.py image.jpg. Originally written by Gene Cash / Thierry 
> > Bousch.
> 
> Does it really make sense to package EXIF library, which is two years
> dead and does not support any recently made cameras? Would not be
> better to rather use something alive like pyexiv2?
> 
> -- 
>   Michal $(D*-(Biha$(D+Z(B | http://cihar.com | http://blog.cihar.com
> [2 signature.asc ]
> 
--
$BC+8}(B $B5.5*(B (TANIGUCHI Takaki)tak...@asis.media-as.org
http://takaki-web.media-as.org/ tak...@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/87pqrwqtnx.wl%tak...@asis.media-as.org

Bug#610284: ITP: tuxfootball -- great 2D soccer (sometimes called football) game

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: tuxfootball
  Version : 0.3.0
  Upstream Author : Jason Wood 
* URL or Web page : http://tuxfootball.sourceforge.net/
* License : GPL-2+
  Description : great 2D soccer (sometimes called football) game
 It's bringing old style gameplay from DOS times back to the desktop with up
 to date graphics! It's gameplay is similar to old classics such as Amco's
 Kick Off and Sensible Software's Sensible Soccer.
 .
 The gameplay is designed to be quick, responsive and fun. You are always
 in control of the player closest to the ball. The ball is controled via
 two differentn kick buttons - one for pass, and one for shoot. Aftertouch
 can be applied to shots by quickly pressing and holding the direction you
 want the ball to bend towards. Pushing in the opposite direction to what
 you kicked the ball makes it raise into the air, pushing in the same
 direction as the ball makes it dip towards the ground.




-- 
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/87oc7gqndh.wl%tak...@asis.media-as.org

Re: Can insserv made better?

[Jesús M. Navarro]

Hi, Mike:

On Sunday 16 January 2011 23:37:20 Mike Bird wrote:
> On Sun January 16 2011 13:40:58 Jesús M. Navarro wrote:
> > Regarding your patch, I find the first part of it being quite to the
> > point while the second paragraph is unneeded as long as the information
> > is included in /usr/share/doc/sysvr-rc/README.Debian, and I feel it
> > should be added to the package, maybe rewritten like this:
> >
> > "This is an irreversible step.  While it is recommended because It allows
> > the boot process to be optimized for speed and efficiency providing a
> > more resilient framework for development, it may not correctly transition
> > in complex systems without further effort on your part."
>
> That's an excellent suggestion.  Would you care to post it to #610185[1]
> to be sure the maintainer sees it?

Done.

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

How to build a 32-bit package in Debian?

[Steve M. Robbins]

Hi,

I've recently adopted a package (nyquist) that only builds in 32-bit
mode.  I'm struggling with supporting it on amd64 and other 64-bit
architectures in Debian.

First: yes, clearly the code should be migrated to 64-bits.  Upstream
is aware of that and it's a nontrivial effort.  I'm interested in
supporting the package as it exists today.

The solution adopted at present is that upstream packages 3 required
libraries (libsndfile, liblo, and portaudio) which are all built in
32-bit mode.  This generates a working binary, but is sub-optimal for
all the usual reasons: we don't benefit from fixes and upgrades.  I'd
like to link to the Debian-provided libsndfile, but of course it is
64-bit on my amd64 machine and the link fails.

What is the recommended course of action for such a package?

I just learned about the ia32-libs package.  It doesn't contain
the libraries I need (yet) but I imagine it may be possible to
add them.  Is there an equivalent package for other 64-bit
architectures?

Thanks,
-Steve


signature.asc
Description: Digital signature

Re: How to build a 32-bit package in Debian?

[Paul Wise]

On Mon, Jan 17, 2011 at 11:25 AM, Steve M. Robbins  wrote:

> What is the recommended course of action for such a package?

For now: build on a 32-bit system or in a 32-bit chroot.

Other options in increasing order of preference:

Add deps to ia32-libs.

Add lib32 packages for the deps.

Help fix squeeze RC bugs then start work on multi-arch when the wheezy
cycle starts.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian Installer 6.0 Release Candidate 1 release

[CaT]

On Wed, Jan 12, 2011 at 07:59:29PM -0200, Otavio Salvador wrote:
> We do need your help to find bugs and further improve the installer, so
> please try it. Installer CDs, other media and everything you else you
> will need are available at our web site[3].

Just did. VirtIO devices appear to be missing (I'm using the multi-arch
netinstall cd). Am I wrong about this? If not could they please be added?
It'd make life a lot simpler.

-- 
  "A search of his car uncovered pornography, a homemade sex aid, women's 
  stockings and a Jack Russell terrier."
- 
http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-118083480


-- 
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/20110117053211.gk3...@zip.com.au

Re: Can insserv made better?

[Thomas Hochstein]

Mike Bird schrieb:

> No, I'm saying that Snn/Knn values boot some systems where
> insserv fails.  Therefore Snn/Knn is superior in some cases.

Does insserv fail then because it is inherently unable to mimic the
Snn/Knn behaviour or due to wrong (missing, ...) dependency info in
the initscripts? If it's the latter, the right solution would be
fixing the scripts, I think.

-thh


-- 
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/ldd.1101170041@thorondor.akallabeth.de

Re: Can insserv made better?

[Mike Bird]

On Sun January 16 2011 15:41:40 Thomas Hochstein wrote:
> Mike Bird schrieb:
> Does insserv fail then because it is inherently unable to mimic the
> Snn/Knn behaviour or due to wrong (missing, ...) dependency info in
> the initscripts? If it's the latter, the right solution would be
> fixing the scripts, I think.

Nobody knows all the different configurations that are out
there.

To avoid all failures the initial insserv install would
have to examine the system's Snn/Knn (not the script headers)
and then create dependencies to replicate the same startup
order.  The sysadmin could later delete any dependencies she
didn't want.  I do not recommend this but it is the only
solution to avoid all failures.

A better solution is to avoid misleading sysadmins - to
give them fair and balanced information so that they can
decide if and when to enable insserv.

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

Re: Why is help so hard to find?

[Russ Allbery]

Olaf van der Spek  writes:
> On Sun, Jan 16, 2011 at 3:54 AM, 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

> Shouldn't this be the responsibility of the package manager?

The package manager doesn't have enough information to know what the
correct thing to do with obsolete conffiles is, and the package manager
doesn't know anything about non-conffile configuration files at all.

> Otherwise it sounds like a big code duplication problem.

That's why dpkg-maintscript-helper exists.

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