FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-14-2011, 05:11 PM
Mike Bird
 
Default Why is help so hard to find?

On Fri January 14 2011 03:51:48 Alexander Reichle-Schmehl wrote:
> Am 13.01.2011 11:54, schrieb Olaf van der Spek:
> > Instead of stepping down, it might be better to ask for a co-maintainer.
>
> You mean like this http://www.debian.org/devel/wnpp/help_requested?
> Let's have a look:
>
> # chromium-browser [..] requested 228 days ago.
> # dpkg [..] requested 2245 days ago.
> # grub2 [..] requested 2439 days ago.
> # libreoffice [..] requested 1368 days ago.
>
> Any other good ideas? Perhaps something new ideas, which isn't already
> practices?

On occasion when I've found a kernel bug or gcc bug or perl
bug, or wanted to add a new feature to inn, I've been able
to scratch my itch immediately.

The impression I get of Debian is that in order to contribute
I need to spend a year or so humoring somebody with a tenth my
programming experience.

If that impression is wrong, I'd really like to fix at least
two major bugs in Squeeze:

(1) sysv-rc upgrade should not bring in insserv and wreck
startup on systems more complicated than a basic laptops,
without adequate warning, and "irreversibly". (Note that due
to ass-backward design, restoring /etc does not prevent insserv
from wreaking havoc again. You have to also
"touch /etc/init.d/.legacy-bootordering".)

(2) KDE4 is not an upgrade from KDE3. It is despicable to
push KDE4 onto KDE3 users. The correct upgrade path is
Trinity. Not only is Trinity a continuation of KDE3, unlike
KDE4, but it is also far more stable and reliable. Debian's
KDE maintainers can't even keep up with the torrent of KDE4
bugs now, and that will increase enormously when Squeeze is
released. Last time I checked, and also six months ago, KDE4
doesn't even create a working KMail account due to missing
MySQL dependencies. If people want to install a kde4 package
in Squeeze that should be permitted if Debian's KDE maintainers
are willing to support it, but the correct upgrade path from
Lenny's kde is Trinity, not KDE4. (Thank you to Debian's KDE
maintainers for getting this right for Lenny.)

Note that we're not talking coding errors here. We're talking
about abuse of the Debian packaging system so that people can
push their favorite software at the expense of Debian's users.

Apart from the above, Squeeze is looking to be another excellent
Debian release.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101141011.51907.mgb-debian@yosemite.net">http://lists.debian.org/201101141011.51907.mgb-debian@yosemite.net
 
Old 01-14-2011, 08:44 PM
Ben Hutchings
 
Default Why is help so hard to find?

On Fri, Jan 14, 2011 at 10:11:51AM -0800, Mike Bird wrote:
> On Fri January 14 2011 03:51:48 Alexander Reichle-Schmehl wrote:
> > Am 13.01.2011 11:54, schrieb Olaf van der Spek:
> > > Instead of stepping down, it might be better to ask for a co-maintainer.
> >
> > You mean like this http://www.debian.org/devel/wnpp/help_requested?
> > Let's have a look:
> >
> > # chromium-browser [..] requested 228 days ago.
> > # dpkg [..] requested 2245 days ago.
> > # grub2 [..] requested 2439 days ago.
> > # libreoffice [..] requested 1368 days ago.
> >
> > Any other good ideas? Perhaps something new ideas, which isn't already
> > practices?
>
> On occasion when I've found a kernel bug or gcc bug or perl
> bug, or wanted to add a new feature to inn, I've been able
> to scratch my itch immediately.
>
> The impression I get of Debian is that in order to contribute
> I need to spend a year or so humoring somebody with a tenth my
> programming experience.

Debian maintainers are not necessarily master programmers, but they
will generally have more experience of packaging and bug triage than
you. These are very different skills.

> If that impression is wrong, I'd really like to fix at least
> two major bugs in Squeeze:
>
> (1) sysv-rc upgrade should not bring in insserv and wreck
> startup on systems more complicated than a basic laptops,

This is an exaggeration.

> without adequate warning, and "irreversibly". (Note that due
> to ass-backward design, restoring /etc does not prevent insserv
> from wreaking havoc again. You have to also
> "touch /etc/init.d/.legacy-bootordering".)

So, a *critical* priority debconf question is not enough control
for you?

> (2) KDE4 is not an upgrade from KDE3. It is despicable to
> push KDE4 onto KDE3 users. The correct upgrade path is
> Trinity.
[...]

Strange, I can't find your ITP for Trinity.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110114214412.GB3702@decadent.org.uk">http://lists.debian.org/20110114214412.GB3702@decadent.org.uk
 
Old 01-14-2011, 10:01 PM
Mike Bird
 
Default Why is help so hard to find?

On Fri January 14 2011 13:44:12 Ben Hutchings wrote:
> On Fri, Jan 14, 2011 at 10:11:51AM -0800, Mike Bird wrote:
> > The impression I get of Debian is that in order to contribute
> > I need to spend a year or so humoring somebody with a tenth my
> > programming experience.
<snip>
> > (1) sysv-rc upgrade should not bring in insserv and wreck
> > startup on systems more complicated than a basic laptops,
>
> This is an exaggeration.

How many systems with complex interelated services have you tested?
Why didn't your testing pick up on the problem with request-tracker
and Apache? Or the problem with Apache and bind?

You have no idea what configurations are in use on stable servers.

You have no idea how many stable servers you're going to break.

> > without adequate warning, and "irreversibly". (Note that due
> > to ass-backward design, restoring /etc does not prevent insserv
> > from wreaking havoc again. You have to also
> > "touch /etc/init.d/.legacy-bootordering".)
>
> So, a *critical* priority debconf question is not enough control
> for you?

No. It does not warn that years of work by Debian Developers is
to be thrown away, and without documentation on how to recover (a
restore of /etc doesn't fix it). The question says only:

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

There is nothing there about the very serious problems caused by
insserv.

No sane person could possible "recommend" insserv for a server. One
second a year saved in reboot versus hours or days repairing damage.

> > (2) KDE4 is not an upgrade from KDE3. It is despicable to
> > push KDE4 onto KDE3 users. The correct upgrade path is
> > Trinity.
>
> [...]
>
> Strange, I can't find your ITP for Trinity.

See my first paragraph.

Fortunately, it's very easy add Trinity to sources.list. There are a
couple of minor issues which I'm discussing with Tim but overall it's
a thousand percent more stable and user-friendly than KDE 4.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101141501.22431.mgb-debian@yosemite.net">http://lists.debian.org/201101141501.22431.mgb-debian@yosemite.net
 
Old 01-14-2011, 10:08 PM
Stephen Gran
 
Default Why is help so hard to find?

This one time, at band camp, Ben Hutchings said:
> Strange, I can't find your ITP for Trinity.

That's because he trolls without ever actually doing anything. Don't
feed the waste of time.

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 01-14-2011, 11:05 PM
Roger Leigh
 
Default Why is help so hard to find?

On Fri, Jan 14, 2011 at 09:44:12PM +0000, Ben Hutchings wrote:
> On Fri, Jan 14, 2011 at 10:11:51AM -0800, Mike Bird wrote:
> > If that impression is wrong, I'd really like to fix at least
> > two major bugs in Squeeze:
> >
> > (1) sysv-rc upgrade should not bring in insserv and wreck
> > startup on systems more complicated than a basic laptops,
>
> This is an exaggeration.

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.

I'm not sure that there's a great deal that can be done to mitigate
this without user intervention, but IMHO this one is a real concern
since it makes it virtually impossible to upgrade without having a
manual purge of all deinstalled packages with conffiles remaining.
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.


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.
 
Old 01-14-2011, 11:07 PM
Russ Allbery
 
Default Why is help so hard to find?

Roger Leigh <rleigh@codelibre.net> 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. What is the failure
mode? What happens on those systems?

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

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87oc7jt4f5.fsf@windlord.stanford.edu">http://lists.debian.org/87oc7jt4f5.fsf@windlord.stanford.edu
 
Old 01-14-2011, 11:15 PM
Mike Bird
 
Default Why is help so hard to find?

On Fri January 14 2011 15:08:13 Stephen Gran wrote:
> This one time, at band camp, Ben Hutchings said:
> > Strange, I can't find your ITP for Trinity.
>
> That's because he trolls without ever actually doing anything. Don't
> feed the waste of time.

The problem is not a lack of ITP. Lenny already has KDE 3.5.

The problem is that KDE 4 is hijacking the kde package
name from KDE 3.5 and kicking KDE 3.5 out of Debian.

KDE 4 exists in Lenny as kde4. It should remain kde4.

There is absolutely no legitimate reason for KDE 4 to kick
KDE 3.5 out. KDE 3.5 and KDE 4 co-existed just fine in Lenny.
KDE 3.5 has upstream support, an excellent code base, a stable
and well-loved product, and far far fewer bugs than KDE 4.

Kicking KDE 3.5 out of Debian is a grave disservice to
loyal Debian users.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101141615.13128.mgb-debian@yosemite.net">http://lists.debian.org/201101141615.13128.mgb-debian@yosemite.net
 
Old 01-14-2011, 11:21 PM
Mike Bird
 
Default Why is help so hard to find?

On Fri January 14 2011 16:07:58 Russ Allbery wrote:
> Roger Leigh <rleigh@codelibre.net> 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. What is the failure
> mode? What happens on those systems?

FWIW, roughly one third of our test systems "failed to upgrade" for this
reason. It's not really a failure. sysv-rc.postinst simply says

Tests have determined that problems in the boot system exist which
prevent migration to dependency-based boot sequencing:
.
${PROBLEMATIC}
.
If the reported problem is a local modification, it needs to be fixed
manually. If it's a bug in the package, it should be reported to the
BTS and fixed in the package. See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for more
information about how to fix the problems preventing migration.
.
To reattempt the migration process after the problems have been
fixed, run "dpkg-reconfigure sysv-rc".

We regard those systems as the lucky ones as they kept the reliable
legacy boot mechanism.

--Mike Bird


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101141621.13380.mgb-debian@yosemite.net">http://lists.debian.org/201101141621.13380.mgb-debian@yosemite.net
 
Old 01-14-2011, 11:40 PM
Roger Leigh
 
Default Why is help so hard to find?

On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
> Roger Leigh <rleigh@codelibre.net> 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. What is the failure
> mode? What happens on those systems?

Like Mike said in his reply, sysv-rc fails to configure fully due to
the presence of init scripts incompatible with insserv. It refuses
to complete until they are gone. You can live with this, but it's not
ideal.

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

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.

It would be better if an upgrade was possible without all this manual
work. It's been tedious for the handful of systems I've done this on
so far; I wouldn't like to need to do it for many more.


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.
 
Old 01-14-2011, 11:52 PM
Russ Allbery
 
Default Why is help so hard to find?

Roger Leigh <rleigh@codelibre.net> writes:

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

I've not looked at the mechanism involved at all, but it does seem like we
should be able to print out all of the files that would cause failures.
Maybe it's hard to continue from an error long enough to find additional
files?

That sounds like it's the thing that makes this the most tedious. If you
got a list of all offending init scripts, we could document in the release
notes that you need to run dpkg -S on each one to locate the relevant
package and purge that package if you're no longer using it.

> It would be better if an upgrade was possible without all this manual
> work. It's been tedious for the handful of systems I've done this on so
> far; I wouldn't like to need to do it for many more.

It does make sense to not continue with enabling inserv if it can't be
done safely, though, and I don't know how to distinguish programmatically
between init scripts that can just be removed and ones the local admin
needs to keep and fix.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ei8ft2de.fsf@windlord.stanford.edu">http://lists.debian.org/87ei8ft2de.fsf@windlord.stanford.edu
 

Thread Tools




All times are GMT. The time now is 11:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org