Re: Too much disruptive NMUs

[Lucas Nussbaum]

On 22/05/10 at 18:33 +0100, Neil Williams wrote:
> Does the MIA team take note of the WNPP reports of recently orphaned
> packages or is there a chance that an inactive maintainer whose only
> package is orphaned and then uploaded using QA, could drop off the
> radar of the MIA team? (Leaving the key in place but no packages.)

The MIA team focuses on maintainers, not on Debian Developers. DDs who
don't maintain packages are out of the scope of the MIA team. I think
that the DAMs are tracking DDs who don't maintain packages since it is
possible that some of them are inactive DDs.

Also, it's easy to find e.g developers who haven't uploaded any of
the packages in unstable with their current key in the keyring:
select login, gecos from ldap
where expire='f' and fingerprint not in (
select fingerprint from sources, upload_history
where sources.source = upload_history.source
and sources.version = upload_history.version
and sources.distribution='debian' and sources.release='sid');
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100523073911.ga14...@xanadu.blop.info

Re: Too much disruptive NMUs

[Jan Hauke Rahm]

On Sun, May 23, 2010 at 08:40:44AM +0200, Lucas Nussbaum wrote:
> On 22/05/10 at 15:07 +0200, Ana Guerrero wrote:
> > Hi,
> > 
> > It is good to care for packages from people who are currently too busy and
> > making NMUs to fix critical/very important bugs. However, lately I have been
> > seeing a lot of NMUs that are being very disruptive [0], you have a couple 
> > of
> > examples below [1]. (This is not against Jari or Nobihuro, they are just 
> > the 
> > latest examples I have seen today).
> > 
> > I know this is done with the best intentions but if you think the package 
> > is in bad shape or neglected by the maintainer then it might better write 
> > to mia@, debian-qa@ or open a bug asking whether the package should be 
> > orphaned (or even removed). Both examples below are candidates to be 
> > orphaned.
> > 
> > If you think this kind of changes are good, please start a discussion about
> > changing this in the developers-reference.
> 
> Our standard process for addressing issues with such packages is the MIA
> process. However, the MIA process takes quite a lot of time, and it has
> happen in the past that it was completely stalled due to a lack of
> manpower. Also, there are cases where the maintainer will respond to the
> MIA team, preventing the orphaning of his packages, despite not working
> on his packages.

Both true, unfortunately.

> So, I think that preparing an NMU that fixes small problems in the
> package at the same time as contacting the MIA team is a good thing. It
> helps to improve the quality of Debian, and alleviates the problem of
> temporarily busy maintainer.

Ack.

> I'd like to encourage Jari and Nobihuro to continue that work, but to
> make sure that:
> - they contact the MIA team about the maintainers of the packages they
>   NMU
> - the packages they NMU are really _useful_ and should be kept in Debian
> - they don't NMU actively maintained packages by mistake. If there are
>   documented efforts to contact the maintainer, using the DELAYED queue
>   with a long delay would help with that.

Ack but still:

- don't be too disruptive!

I don't think that changing to dh7, i.e. debian/rules to the tiniest
form, switching a package from dpatch to quilt to finally switch it to
3.0 (quilt) are changes that should be done, even if they seem useful.
And there are more examples.

I guess the problem is, as usual, where to draw the line.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: Translations copyrights/licences

[Neil Williams]

On Sun, 23 May 2010 07:53:14 +0200
Julien Valroff  wrote:

> The sources contain gettext translations, the copyrights and licences
> of which are sometimes unclearly stated, eg:

Nearly all packages with translations have "problems" like this. It
isn't actually a problem, there's nothing realistic that can be done
about it and nearly all packages with translations would have the same
"problem". If we accept that this is an issue, we'll have 14,000 RC
bugs overnight and we'll never release again.

Translators are often transient - a translation can turn up in a
package even with a Last-Translator but no further translations may
ever appear with no replies from the supplied address. Eventually
someone else might take over but a lot of packages have abandoned
translations and no usable details of Last-Translator.

I see no reason to specify these in debian/copyright.

Translator details can change more frequently than the wind and are
distributed under the same license as the package. To me, that's an end
to it.

> Sometimes, the name of the last translator isn't even stated.

s/Sometimes/Frequently/. Even when stated, the given name isn't
contactable anymore, so the prospect of getting anything in the
headers updated is zero. It's hard enough getting the translations
themselves updated.

With po files in top level po/ directories, there may be a
"translator-credits" msgid where the msgstr has a name but there's no
guarantee that this / these names are up to date.

Those details do appear in the UI of such programs, generally, so the
translators have some motivation to put their own names in that list,
so those can be a bit better but still not 100% up to date.

> I will obviously contact upstream so that they contact the translators
> and ask them to fix this, but I guess this will take some time and I
> would like to be able to get pino uploaded soon.

It isn't even possible in most cases. Only a minority of translators
would be able to respond. I don't think you should even contact
upstream - there's likely to be nothing upstream can do about it.

http://www.linux.codehelp.co.uk/?q=node/32

http://www.linux.codehelp.co.uk/?q=node/25

If you contacted *me* as upstream, I would refuse. Simple. It isn't
going to happen. You can threaten to remove the package from Debian,
you can threaten to remove all incomplete translations, it won't matter
- there is nothing that can be done because the people are either not
known or not contactable.

> How to deal with such unclear/incomplete headers?

As Debian Maintainer, you don't. Simple.

It's quite enough of a headache for upstream.
 
> In the case the copyright is "given" to the pino developers, wouldn't
> it be good to state the name of the last translator(s) in the
> copyright file? If so, is an X-Last-Translator field appropriate in
> the machine readable copyright format [2]?

NO!

Very, very, few translations are actively "maintained", despite the
best efforts of upstreams to hold string freezes and contact
translators to request updates. If a package has ~40 translations, only
a handful will be at 100% at any one release. Many translations are
effectively abandoned. Many translators do not complete the headers at
all, most do not keep the headers consistently updated.

It's not just the top level po/ files either, packages have help/po,
doc/po and debian/po and some have po/ as well as po-lib/ or po-bin/
and other subdirectories - expecting all of those to be constantly
updated in debian/copyright is insane!

(Not to mention the packages which have translations that don't use
gettext formats where there might be no declaration of the
translator's details whatsoever.)

Have you any idea how much work this would be for a package like
drivel, gnucash or gedit???

The only "solution" for this "problem" is for every package to drop
90% of translations. Should make the archive a whole lot smaller and
would be really helpful to our users, not.

It is not a problem, forget it and please, do some real work that makes
a release more likely, not less. (If you've got time to waste on this,
you certainly have time to fix some existing RC bugs to help out those
who want to but don't have time to do so.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpaCuNqcNBY3.pgp
Description: PGP signature

Re: Too much disruptive NMUs

[Jan Hauke Rahm]

On Sat, May 22, 2010 at 06:33:41PM +0100, Neil Williams wrote:
> On Sat, 22 May 2010 19:20:42 +0200
> Julien BLACHE  wrote:
> 
> > Either it's a QA upload or it's a NMU, but it can't be "a bit of
> > both".
> > 
> > If the package is effectively not maintained anymore, it's up to the
> > MIA team to investigate and eventually decide to orphan the package.
> 
> Do we have to wait for the MIA team or is a complete lack of response
> to a request to NMU in the BTS sufficient reason for someone who is
> interested in the package to file the bug to orphan the package
> themselves? As long as someone is interested in the package, shouldn't
> an email to the MIA team be sufficient? Someone has to be fairly
> interested in a package to consider an NMU in the first place.

I don't think that one or two mails to the BTS are sufficient to declare
a maintainer MIA and thus do all kinds of QA stuff on their packages,
regardless if those contacts have been NMU requests or whatever. On the
other hand, I acknowledge the problem that the MIA process sometimes
takes so much time, the interested NMUer even looses interest again.

Anyway, a mail to MIA is highly appreciated. Not that we can do much
more but at least we can note that as another contact attempt which
*can* lead to faster processing after all.

> Does the MIA team take note of the WNPP reports of recently orphaned
> packages or is there a chance that an inactive maintainer whose only
> package is orphaned and then uploaded using QA, could drop off the
> radar of the MIA team? (Leaving the key in place but no packages.)

There isn't enough manpower to do archive wide checks. I do from time to
time random checks, one of which being for maintainers without packages.
They are interesting to us as we have DDs who work as e.g. porters but
don't have packages. But as Lucas said, this is basically DAM's work.

> > This kind of NMUs don't help; they just help the unmaintained stuff
> > fly below the MIA radar longer.
> 
> Agreed - so in addition to my last email, a QA upload like this, IMHO,
> should make sure that the MIA team are aware. I'd assume that, once
> contacted, the MIA team would be happy for the package to be adopted
> whilst the rest of the MIA process goes ahead.

Of course we are happy for every orphaned package to be adpoted. I,
personally, am not happy about packages being hijacked after one
unanswered NMU mail to the BTS. There are maintainers who really took
some time off without telling anyone. It's not good but it happens, and
we shouldn't take their packages away for one such mistake.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: shutdown on power button?

[Michael Meskes]

On Sat, May 22, 2010 at 10:21:08AM +0200, Salvo Tomaselli wrote:
> I think i should also close the bug, and.. sorry :-)

Don't worry, stuff like this happens.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
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/20100523100810.ga1...@feivel.credativ.lan

Re: lilo removal in squeeze (or, "please test grub2")

[Cyril Brulebois]

(Dropping -release, which isn't a discussion list.)

William Pitcock  (22/05/2010):
> Given that there is no active upstream and that the Debian lilo
> package carries many patches for bug fixes that are alleviated by
> standardizing on grub2, this seems like the best option for Debian.

Speaking of upstream and bug fixing, what about that?
  http://bugs.debian.org/src:grub2

> This means that users should *test grub2 extensively* before Squeeze
> is released so that any issues can be resolved now.

There should also be some folks fixing the discovered issues.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, "please test grub2")

[Kurt Roeckx]

On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote:
> William Pitcock  (22/05/2010):
> > This means that users should *test grub2 extensively* before Squeeze
> > is released so that any issues can be resolved now.
> 
> There should also be some folks fixing the discovered issues.

grub2 currently seems to be having 18 RC bugs, plus a whole bunch
of merged bugs, while lilo only has 1 RC bug.  

I think the difference is that lilo will probably not work
for a lot of people while grub2 does work for a lot of people.
And I understand that Debian's lilo maintainer basicly doesn't want
to become upstream and rewrite everything when there is an
alternative.

But I agree that a call for extensive testing would be better if
number of RC bugs would be a lot lower.


Kurt


-- 
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/20100523114251.ga3...@roeckx.be

Re: Translations copyrights/licences

[Helge Kreutzmann]

Hello,
speaking both with my translator and my Debian Maintainer hat on, I
can state the following:

a) There are lots of "drive by" translators. Systems like launchpad or
   DDTP even *encourage* this. In this case, it is most likely not
   possible at all to contact individual translators.
b) In structured projects (Debian, Fedora, OOo, KDE, GNOME) there are
   often language teams. In this case, translations are often
   "channeled" via the team. So if you want, you can try to collect
   the names in the copyright, but a team adress is more valuable.
c) Licenses are often alien to translators. They focus on the content
   and do not fill in the header. I've asked to get at least "same
   license as package" filled in, sometimes people respond, sometimes
   they don't. 
d) I know translators who like to do an initial translation but not
   maintenance. So if you want, you could contact the teams from b)
   (if they exist) and ask if someone would maintain the translation
   or at least provide an update. This is a lot of work, given the
   number of languages available. Just watch the efforts for d-i on
   this list.

Notwithstanding a close examination of policy I would agree with Neil:
Take what you can get (see a),), hope that some review takes place
(see b)), assume that translators want their content to be distributed
(see c), why else would they invest the time on some "random" web
site) and be happy if updated come in (see d)). Unless there are bug
reports regarding translations I would also agree that fixing (RC)
bugs is more important than trying to "fix" the copyright file with
regard to translations (though I try). 

And regarding completeness: Send a call for translations regularly
(e.g. using podebconf-report-po), giving sufficient time for
responses (depending on the size, 10 days is a good time frame), and 
then upload. It's simply impossible to get all po files at 100%. (Of
course, having an active upstream relieves you from that).

Greetings

Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, "please test grub2")

[Darren Salt]

I demand that William Pitcock may or may not have written...

> After some discussion about lilo on #debian-devel in IRC, it has pretty
> much been determined that kernel sizes have crossed the line past where
> lilo can reliably determine the payload size.

Working fine here on i386, whether booting a stock kernel (testing with
2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
on amd64 for some time now, but I've seen no problems with my custom kernels
(which are all initrd-free).

[snip]
> This means that users should *test grub2 extensively* before Squeeze is
> released so that any issues can be resolved now.

Well... I recall an issue with the default boot menu item no. being left
untouched and, consequently, becoming out of sync with menu content as
kernels were added or removed, although that may just be grub1.

Still, it was enough of a reason to stick with lilo.

(However, I recall extlinux being mentioned when this last came up...)

> As for removal, the following things need to be done:

> (1) The release notes need to be updated to reflect that lilo is no
> longer a bootloader option;
> (2) The debian-installer team needs to remove the lilo-installer udeb;
> (3) The ftpmasters need to remove lilo from unstable (which will be done
> using the appropriate bug filing once the above steps are made);

Alternatively, document its limitations and bugs, and let it stay.

> (4) Users need to test grub2 now.

Need? I see no need...

[snip]
-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + I say leave it for squeeze+∞ :-)

Drive must be A: or B:, 0:1


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512157417c%li...@youmustbejoking.demon.co.uk

Re: Too much disruptive NMUs

[Jari Aalto]

Ana Guerrero  writes:
>
> It is good to care for packages from people who are currently too busy and
> making NMUs to fix critical/very important bugs. However, lately I have been
> seeing a lot of NMUs that are being very disruptive

Hi Ana,

The packages I took under close look have been carefully selected and
any possible "active" were either contacted or notified about the
upcoming NMU. I also participated #debian-qa to ask for MIA of certain
people when in doubt.

Via email, those that I contacted, were happy to responded "OK" with the
changes.

We've coordinated the uploads with Tony during period of 3 months, for
the upcoming release. The uploads were always put to DELAYED/NN, and
extra time (14 days) were given for some packaged for developers to
react.

The debian/changes lists may look "verbose", but the actual chages are
really minor. I prefer explicit changelogs so that peer-review is
possible.

In addition to fixing the RC bugs, minor updates were usually done at
the same time. This was done for the reasons that in case the packages
were later orphaned or the maintainer were MIA, it would be more
desireable to have a well shaped package in archive. The minor changes
include:

- update to latest debhelper (In many times no debian/rules changes;
  possibly update deprecated dh_clean to dh_prep")
- use packaging format 3.0 (delete quilt if it was used)
- update compat to 7

The DEP1 does't specifially encourage fixing anything else than the BUG
at hand, and that's a very good rule for actively maintained packages.

However these uploads you were seeing were for packages that:

- had very old bugs
- or were not actively maintained (developer not seen in years).

So I felt a "shaping up" would be in the spirit of good maintenance.

Jari

[1] http://dep.debian.net/deps/dep1.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hblyg3dx@jondo.cante.net

Re: Too much disruptive NMUs

[Alexander Wirt]

Jari Aalto schrieb am Sunday, den 23. May 2010:

Hi, 

*snip*
> In addition to fixing the RC bugs, minor updates were usually done at
> the same time. This was done for the reasons that in case the packages
> were later orphaned or the maintainer were MIA, it would be more
> desireable to have a well shaped package in archive. The minor changes
> include:
> 
> - update to latest debhelper (In many times no debian/rules changes;
>   possibly update deprecated dh_clean to dh_prep")
> - use packaging format 3.0 (delete quilt if it was used)
> - update compat to 7
I don't find anything of them acceptable for an nmu.
> The DEP1 does't specifially encourage fixing anything else than the BUG
> at hand, and that's a very good rule for actively maintained packages.
That dep thingys are no policy. imho these uploads violate the nmu policy. 

 
Alex


-- 
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/20100523132511.ge16...@lisa.snow-crash.org

Re: lilo removal in squeeze (or, "please test grub2")

[Julien BLACHE]

Darren Salt  wrote:

Hi,

> Working fine here on i386, whether booting a stock kernel (testing with
> 2.6.33 from experimental) or a custom kernel. I've not checked a stock kernel
> on amd64 for some time now, but I've seen no problems with my custom kernels
> (which are all initrd-free).

No problems to report on amd64 either, with or without an initrd.

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/871vd268d2@sonic.technologeek.org

Permission to NMU gcc-mingw32

[Ove Kaaven]

The lack of a suitable (i.e. non-buggy) mingw32 cross-compiler has 
blocked Wine updates for half a year now. Both the mingw32 package (gcc 
4.2.1) and the gcc-mingw32 package (gcc 4.4.2) have a bug which was 
fixed in upstream gcc 4.4.3. At least one of these should be updated, if 
we want a fully featured Wine, but neither of them seems to be updating. 
The maintainer of gcc-mingw32, Robert Millan, appears MIA, and mingw32 
appears to be blocked on some politics issue (apparently not helped by 
the existence of gcc-mingw32?).


Anyway, for me, the easiest way to be able to build an updated Wine 
package would be to NMU gcc-mingw32. Doing so seems to be just a matter 
of putting in a new gcc tarball in the source package, and I've 
confirmed that updating it to gcc 4.4.4 seems to work for what Wine needs.


Is it okay if I go ahead and do such a NMU?

Ove


--
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/4bf9320e.6020...@arcticnet.no

Re: Too much disruptive NMUs

[Stefano Zacchiroli]

On Sun, May 23, 2010 at 03:25:11PM +0200, Alexander Wirt wrote:
> > The DEP1 does't specifially encourage fixing anything else than the BUG
> > at hand, and that's a very good rule for actively maintained packages.
> That dep thingys are no policy. imho these uploads violate the nmu policy. 

Well, DEP1 got implemented in developer's reference, which kind of
define the NMU policy. However that's not the point IMO. At least
according to Tony reply I can see that the work-flow for NMU has been
followed properly for most parts (e.g. by using the DELAYED queue,
fixing important bugs---which *is* allowed by NMU guidelines, etc.).

The main problem is that the changes performed have been a bit too much
overzealous, even if with the best intentions. All would have been fine
if things like "switching to quilt" have been avoided, and we would have
been here thanking the NMU-ers.

All in all, I can also understand the desire to fix that kind of things
in a package which is clearly unmaintained, but that should come with an
upload which also orphan the package or change the maintainer (of course
according to the processes for that). The guiding principle AFAICT is
that when you NMU a package you generally hope that the proper
maintainer will eventually integrate your changes, that's why they
should be minimized. If, on the contrary, the package is de facto
orphaned, it's pointless to strive for minimality (but then, again, the
package should be orphaned or worse).


Finally, just a plea for everybody participating in this thread. NMU
guidelines should be followed properly, that's out of discussion.
Nevertheless please try not to discourage too much (properly done) NMUs,
as we've a big inertia problem in Debian about maintainers with
less-than-stellar reaction time, and NMUs are one of the best tools we
have to counter that.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Too much disruptive NMUs

[Jari Aalto]

Alexander Wirt  writes:
>> Jari Aalto schrieb am Sunday, den 23. May 2010:
>>
>> [When package was not maintained]
>>
>> In addition to fixing the RC bugs, minor updates were usually done at
>> the same time. This was done for the reasons that in case the packages
>> were later orphaned or the maintainer were MIA, it would be more
>> desireable to have a well shaped package in archive. The minor changes
>> include:
>> 
>> - update to latest debhelper (In many times no debian/rules changes;
>>   possibly update deprecated dh_clean to dh_prep")
>> - use packaging format 3.0 (delete quilt if it was used)
>> - update compat to 7
>
> I don't find anything of them acceptable for an nmu.
>
>> The DEP1 does't specifially encourage fixing anything else than the BUG
>> at hand, and that's a very good rule for actively maintained packages.
>
> That dep thingys are no policy. imho these uploads violate the nmu policy.

It was later turned into policy.

So there is not room for discreet judgement for cases like:

- active maintainer

- non-active maintainer and for case like: years old package, 6+
  months old FTBFS, or ancient 3.[56].x policy in debian/control?

That'd be a loss, quality wise.

Jari


-- 
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/8739xid80z@jondo.cante.net

Re: lilo removal in squeeze (or, "please test grub2")

[Marc Haber]

On Sat, 22 May 2010 22:39:52 -0500, William Pitcock
 wrote:
>This means that users should *test grub2 extensively* before Squeeze is
>released so that any issues can be resolved now.

This also means that the grub2 maintainers (both Debian and Upstream)
need to work on the regressions that exist in regard to moving from
lilo or grub "legacy" to grub2. There are too many bug reports in the
BTS which are completely unaddressed.

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/e1og9zh-0003pu...@swivel.zugschlus.de

Re: Too much disruptive NMUs

[Stefano Zacchiroli]

On Sun, May 23, 2010 at 05:09:32PM +0300, Jari Aalto wrote:
> - non-active maintainer and for case like: years old package, 6+
>   months old FTBFS, or ancient 3.[56].x policy in debian/control?

On -qa, we tried to define some time ago work-flow for dealing with
cases like that (essentially, how to have something "NMU-like" which
permits to orphan a package not being the maintainer, without inducing
too much steps, too much bottlenecks, etc.). Please take this discussion
to -qa if you're interested in helping out; you can start at
.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, "please test grub2")

[Stefano Zacchiroli]

On Sun, May 23, 2010 at 02:08:59PM +0200, Marc Haber wrote:
> This also means that the grub2 maintainers (both Debian and Upstream)
> need to work on the regressions that exist in regard to moving from
> lilo or grub "legacy" to grub2. There are too many bug reports in the
> BTS which are completely unaddressed.

Right, but also note that there's an open RFH on grub2 #248397
(retitled/refreshed recently, despite the low bug number).

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, "please test grub2")

[Darren Salt]

I demand that Julien BLACHE may or may not have written...

> Darren Salt  wrote:
>> Working fine here on i386, whether booting a stock kernel (testing with
>> 2.6.33 from experimental) or a custom kernel. I've not checked a stock
>> kernel on amd64 for some time now, but I've seen no problems with my
>> custom kernels (which are all initrd-free).

> No problems to report on amd64 either, with or without an initrd.

You removed too much context; I'm assuming that you were testing lilo...

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

Beauty is only skin deep, but ugly goes clear to the bone.


-- 
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/512165675c%li...@youmustbejoking.demon.co.uk

Re: lilo removal in squeeze (or, "please test grub2")

[Julien BLACHE]

Darren Salt  wrote:

Hi,

>>> Working fine here on i386, whether booting a stock kernel (testing with
>>> 2.6.33 from experimental) or a custom kernel. I've not checked a stock
>>> kernel on amd64 for some time now, but I've seen no problems with my
>>> custom kernels (which are all initrd-free).
>
>> No problems to report on amd64 either, with or without an initrd.

Yes indeed.

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

Bug#582782: ITP: serp -- Java Virtual Machine bytecode manipulation framework

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: serp
  Version : 1.14.1
  Upstream Author : A. Abram White 
* URL : http://serp.sourceforge.net/
* License : BSD
  Programming Lang: Java
  Description : Java Virtual Machine bytecode manipulation framework

The goal of the serp bytecode framework is to tap the full
power of bytecode modification while lowering its associated
costs.

The framework provides a set of high-level APIs for
manipulating all aspects of bytecode, from large-scale
structures like class member fields to the individual
instructions that comprise the code of methods.

While in order to perform any advanced manipulation, some
understanding of the class file format and especially of the
JVM instruction set is necessary, the framework makes it as
easy as possible to enter the world of bytecode development.

This package is needed to package OpenJPA library, which
in turn, it is needed to package Spring Framework 3.0.

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche



-- 
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/20100523154356.ga24...@miguel.cc

Re: Too much disruptive NMUs

[Osamu Aoki]

Hi,

On Sat, May 22, 2010 at 06:23:25PM +0100, Neil Williams wrote:
> On Sat, 22 May 2010 09:32:02 -0700
> tony mancill  wrote:
> 
> > I sponsored the upload of a number of Jari's fixes.  You state that
> > they were disruptive, but I'm wondering to whom.  The uploads were to
> > delayed queues and the maintainer notified via the BTS, and in all
> > cases where the maintainer actually ACK'd the bug report or NMU, we
> > discussed the matter with the maintainer and/or removed the NMU from
> > the delayed queue.
> > 
> > In most cases (it may be all for the packages Jari and I worked on),
> > the maintainers never responded whatsoever to bug reports that were
> > over a year old, nor to the intent to NMU, so in a sense they could be
> > considered them QA uploads.  I.e., if a developer can't be bothered to
> > even respond to a bug in the Debian BTS, then the package is
> > essentially orphaned. 
> 
> Then the process, as I see it, would be for the person making the
> proposed NMU to file the bug to orphan the package instead, wait the
> length of time that the proposed upload would have waited in the
> delayed queue, or maybe a bit longer, and then make a QA upload (or
> adopt the package) without using the delayed queue.

I have made few NMU upload like this myself.

Maintainer was very quiet on BTS and not updating package at all for
something like a year.

But he always responded at the last moment that he wanted to keep the
maintainer position.  After a NMU and several months, it repeated and I
made delayed NMU and got the same response.  (I told him to orphan but
he practically rejected idea by action.)  Now I got him to accept me as
uploader, next upload may not be NMU but I feel this is not the optimal
situation.

Since original package had no-so-optimal cdbs usage and funny unused
codes, I decided to use dh7 and clean these up.  In the course, I
switched from cdbs -p0 patch to 3.0 (quilt).

Really, issue is "Debian does not have reasonable rule for hijacking or
automatic orphaning". If some maintainer is totally quiet on BTS report
for over 2 months, he should loose maintainer-ship.  The same goes if
the maintainer has not uploaded new upload after reminded by bug report
for 2 months without reply, he should loose maintainer-ship.  If he had
"I am maintaining this" without clear technical reason not-to-package
new version, this should apply too. (If he has real reason, of course he
should keep it.)

(I like idea of DM but DM should not think that their first upload
can be changing only "DM-Upload-Allowed: yes" without bug fix.  Is this
documnted somewhere?)

Osamu

PS: mail made with "From: os...@debian.org" got bounced.


-- 
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/20100523161537.ga32...@osamu.debian.net

Re: Too much disruptive NMUs

[Lucas Nussbaum]

On 24/05/10 at 01:15 +0900, Osamu Aoki wrote:
> Really, issue is "Debian does not have reasonable rule for hijacking or
> automatic orphaning".

I fully agree. There are many packages that are staying with totally
outdated upstream versions simply because the maintainer went inactive,
and MIA was not able to orphan his packages (because the maintainer,
despite being inactive, might still reply "I will come back in a month
and fix everything").

> If some maintainer is totally quiet on BTS report for over 2 months,
> he should loose maintainer-ship.  The same goes if the maintainer has
> not uploaded new upload after reminded by bug report for 2 months
> without reply, he should loose maintainer-ship.  If he had "I am
> maintaining this" without clear technical reason not-to-package new
> version, this should apply too. (If he has real reason, of course he
> should keep it.)

... but I disagree with having a strict rule that allows everybody to
hijack a package. I think that it should be the responsibility of the
hijacker to prove that he made enough efforts to contact the maintainer,
and that he is qualified to maintain the package.

For example, the candidate hijacker could send an "intend to hijack foo"
email to debian-devel@, with the reasons why he thinks the package
should be hijacked (date of last maintainer upload, list of open bugs
without any response from the maintainer, new upstream versions which
were not packaged, MIA status, etc).
That email would send receive public review, and if nobody objects after
some time, the hijacker could proceed.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100523173348.gb17...@xanadu.blop.info

Re: debian/watch problem due to http://code.google.com download page's link format change

[Iustin Pop]

On Sat, May 15, 2010 at 06:48:41PM +0900, Osamu Aoki wrote:
> Hi,
> 
> On Sat, May 15, 2010 at 05:16:08PM +0800, Asias He wrote:
> > Hi, All
> > 
> > Recently, code.google.com changed the download page link format.
> > As a result, the old debian/watch file in packages whose upstream source 
> > code
> > hosted on code.google.com did work anymore.
> > 
> > Take the ibus project for example:
> > $ cat ibus/debian/watch
> > version=3
> > http://code.google.com/p/ibus/downloads/list \
> > http://ibus.googlecode.com/files/ibus-([0-9].*)\.tar\.gz
> > 
> > The new download page contain the "detail" link, one has to follow
> > the new "detail" link in order to find the real download url.
> > something like this:
> > http://code.google.com/p/ibus/downloads/list
> > http://code.google.com/p/ibus/downloads/detail?name=ibus-1.3.3.tar.gz&can=2&q=
> > http://ibus.googlecode.com/files/ibus-1.3.3.tar.gz
> > 
> > I believe this problem affects all the packages whose upstream source
> > code is hosted on code.google.com.
> > 
> > Is there an easy way to deal this.
> 
> I guess we need to generarize situation on sf.net to other popular
> download sites.  This data is used mainly by uscan program.
> 
> When the watch file has an URL matching with the Perl regexp
> "^http://sf\.net/";, the uscan program substitutes it with
> "http://qa.debian.org/watch/sf.php/"; and then applies this rule. The URL
> redirector service at this http://qa.debian.org/ is designed to offer a
> stable redirect service to the desired file for the watch file having
> "http://sf.net/project/tar-name-(.+)\.tar\.gz". This solves issues
> related to the periodically changing URL there. 
> 
> So if someone impliment similar URL redirector service, we can have
> stable link.
> 
> Until then, we need to keep up each watch file manually.

I just checked and there's no open bug against code.google.com to
restore the old, plain style links. Note they do have a direct download
link, but now it's obfuscated behind a javascript "onclick" method.

Wouldn't it be better to ask and see if they're willing to either
restore the old link or remove the javascript bit, instead of going
ahead with a workaround?

regards,
iustin


-- 
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/20100523174659.ga16...@teal.hq.k1024.org

Possible boot ordering issues with the packages in Sid

[Petter Reinholdtsen]

Every day, I run a archive wide consistency check of all the init.d
scripts in Debian.  It detect dependencies on non-existing facilities,
duplicate provides and other problems.  Here is the complete list from
today, also available from http://lintian.debian.org/~pere/ >.

There are quite a few false positive here.  For example the missing
$remote_fs check look for /usr/s?bin in the script, and will report a
missing dependency also for scripts not using files in /usr/.  The
missing $syslog check look for a syslog symbol being mentioned in some
binary in the package, and do not really know if the binary is started
at boot.

Anyway, sharing this with you all, in the hope that some of you might
be motivated to review your packages init.d scripts to increase the
quality of the init.d script dependencies.  Please help me reduce the
number of init.d script dependency issues.  Most of these issues are
not reported to BTS, as it require time to verify that the reported
issue is a real problem, and I have not had time to do that for most
of these packages.

I know it would be better to order the list by maintainer, but have
not found a simple way to do that with the format I have available.

== 18 errors ==

error: script apcupsd/init.d/ups-monitor is unreadable
error: script netscript-2.4-upstart/init.d/netscript is unreadable
error: script netscript-2.4-upstart/init.d/netscript-interface is unreadable
error: script nvidia-glx-legacy-71xx/init.d/nvidia-glx-legacy-71xx is missing 
LSB header
error: script nvidia-glx-legacy-96xx/init.d/nvidia-glx-legacy-96xx is missing 
LSB header
error: script powstatd/init.d/powerfail is missing LSB header
error: script thin/init.d/thin is unreadable
error: scripts dicod/init.d/dicod,dicod/init.d/dictd provide duplicate 'dicod'
error: scripts genpower/init.d/genpower,genpower/init.d/ups-monitor provide 
duplicate 'genpower'
error: scripts busybox-syslogd/init.d/busybox-klogd,klogd/init.d/klogd provide 
duplicate 'klogd'
error: scripts postfix/init.d/postfix,xmail/init.d/xmail provide duplicate 
'mail-transport-agent'
error: scripts powstatd/init.d/powstatd,powstatd/init.d/ups-monitor provide 
duplicate 'powstatd'
error: scripts 
root-system-rootd/init.d/root-system-rootd,root-system-xrootd/init.d/root-system-xrootd
 provide duplicate 'root-file-server'
error: scripts samba/init.d/samba,samba4/init.d/samba4 provide duplicate 'samba'
error: scripts busybox-syslogd/init.d/busybox-syslogd,dsyslog/init.d/dsyslog 
provide duplicate 'syslogd'
error: script drbd8-utils/init.d/drbd do not start or stop in any runlevels
error: script honeyd/init.d/honeyd do not start or stop in any runlevels
error: script rabbitmq-server/init.d/rabbitmq-server do not start or stop in 
any runlevels

== 194 warnings ==

warning: script ample/init.d/ample possibly missing dependency on $syslog
warning: script argus-server/init.d/argus-server possibly missing dependency on 
$syslog
warning: script asterisk/init.d/asterisk possibly missing dependency on $syslog
warning: script atm-tools/init.d/atm possibly missing dependency on $syslog
warning: script auditd/init.d/auditd possibly missing dependency on $syslog
warning: script aumix-common/init.d/aumix relate to non-existing provides: 
devfsd
warning: script bastille/init.d/bastille-firewall possibly missing dependency 
on $remote_fs
warning: script blktrace/init.d/mountdebugfs possibly missing dependency on 
$remote_fs
warning: script blktrace/init.d/mountdebugfs does not start in the usual 
runlevels:  1 2 3 4 5 s
warning: script blootbot/init.d/blootbot relate to non-existing provides: 
mysql-ndb mysql-ndb-mgm
warning: script boinc-client/init.d/boinc-client possibly missing dependency on 
$syslog
warning: script c-icap/init.d/c-icap possibly missing dependency on $syslog
warning: script capi4hylafax/init.d/capi4hylafax relate to non-existing 
provides: faxq hfaxd capiinit isdnactivecards
warning: script chillispot/init.d/chillispot possibly missing dependency on 
$syslog
warning: script chrony/init.d/chrony possibly missing dependency on $syslog
warning: script clvm/init.d/clvm possibly missing dependency on $syslog
warning: script cman/init.d/cman possibly missing dependency on $remote_fs
warning: script cman/init.d/cman possibly missing dependency on $syslog
warning: script console-common/init.d/keymap.sh possibly missing dependency on 
$remote_fs
warning: script corosync/init.d/corosync possibly missing dependency on $syslog
warning: script cryptmount/init.d/cryptmount-early possibly missing dependency 
on $syslog
warning: script cryptsetup/init.d/cryptdisks possibly missing dependency on 
$remote_fs
warning: script cryptsetup/init.d/cryptdisks possibly missing dependency on 
$syslog
warning: script cryptsetup/init.d/cryptdisks-early possibly missing dependency 
on $remote_fs
warning: script cryptsetup/init.d/cryptdisks-early possibly missing dependency 
on $syslog
warning: script ctdb/init.d/ctdb possibly missing dependency on $syslog
wa

Re: Possible boot ordering issues with the packages in Sid

[Patrick Matthäi]

Am 23.05.2010 20:25, schrieb Petter Reinholdtsen:


Every day, I run a archive wide consistency check of all the init.d
scripts in Debian.  It detect dependencies on non-existing facilities,
duplicate provides and other problems.  Here is the complete list from
today, also available fromhttp://lintian.debian.org/~pere/>.

There are quite a few false positive here.  For example the missing
$remote_fs check look for /usr/s?bin in the script, and will report a
missing dependency also for scripts not using files in /usr/.  The
missing $syslog check look for a syslog symbol being mentioned in some
binary in the package, and do not really know if the binary is started
at boot.

Anyway, sharing this with you all, in the hope that some of you might
be motivated to review your packages init.d scripts to increase the
quality of the init.d script dependencies.  Please help me reduce the
number of init.d script dependency issues.  Most of these issues are
not reported to BTS, as it require time to verify that the reported
issue is a real problem, and I have not had time to do that for most
of these packages.

I know it would be better to order the list by maintainer, but have
not found a simple way to do that with the format I have available.


Thanks for the list, but wouldn't it be better to submit bugreports? :)

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/


--
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/4bf97797.5030...@debian.org

Re: Possible boot ordering issues with the packages in Sid

[Petter Reinholdtsen]

[Patrick Matthäi]
> Thanks for the list, but wouldn't it be better to submit bugreports? :)

Absolutely, and thank you for volunteering.

I submit bug reports as quickly as I find time to review issues and
report them (I have perhaps 5-10 minutes per day available for this),
and as you can see from the list, more people are needed to do this in
a reasonable amount of time. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flhblyzbsc@login1.uio.no

Re: Too much disruptive NMUs

[Ana Guerrero]

Hi Jari (also Tony and Nobuhiro):

On Sun, May 23, 2010 at 04:21:30PM +0300, Jari Aalto wrote:
> 

I am not going to answer you detailed to this email because you are trying
to explain you did nothing wrong and I agree you did nothing wrong 
trying to fix bug and improve the quality in the archive.
My original email mentioning your upload and Nobuhiro's was adding an example,
then I cc'ed you since I was mentioning you, and your point of view about
this was interesting for the discussion.

About your mail I want to mention that what your consider minor changes
are not minor changes for other people as you can see in this thread. 
And I want to highlight the idea that when you think a package is not 
properly maintained then you (we) should force orphaning it.  I am commenting
more about this in other thread.

If you think we should change the criteria about what is ok for a NMU or not,
please follow the thread in debian-qa.

I hope this mail explain my initial mail better and keep up the good work.

Ana


-- 
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/20100523191124.ga29...@ana.debian.net

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
> 
> After some discussion about lilo on #debian-devel in IRC, it has pretty
> much been determined that kernel sizes have crossed the line past where
> lilo can reliably determine the payload size.
> 
> This bug *can* be fixed, but not without a significant rewrite of the
> way that lilo's stage2 loader code works.  Given that there is no active
> upstream and that the Debian lilo package carries many patches for bug
> fixes that are alleviated by standardizing on grub2, this seems like the
> best option for Debian.
> 
> This means that users should *test grub2 extensively* before Squeeze is
> released so that any issues can be resolved now.
> 
> As for removal, the following things need to be done:
> 
> (1) The release notes need to be updated to reflect that lilo is no
> longer a bootloader option;
> (2) The debian-installer team needs to remove the lilo-installer udeb;
> (3) The ftpmasters need to remove lilo from unstable (which will be done
> using the appropriate bug filing once the above steps are made);
> (4) Users need to test grub2 now.

First of all, forgive me for cross-posting, which is generally a no-no.
But if you can cross-post, I can cross-reply.

Second, unless you reply to debian-user, to which I am subscribed, please
CC me.  I am not subscribed to any of the other lists.

I am not a Debian package maintainer or a Debian developer.  I am just an
ordinary system administrator.  So I'm sure that my opinion will not count
for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
grub-pc use sectors on the hard disk outside of the master boot record
(cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
sector 2 and possibly subsequent sectors on cylinder 0 head 0.  This breaks
the design of the backup software that my employer uses.  This backup software
backs up the master boot record and all partitions; but since the extra
sectors used by grub-legacy and grub-pc are outside the master boot record
and are not part of any partition, they don't get backed up.  Consequently,
if we have a hard drive failure and restore from a backup, we have an
unbootable machine.  Lilo uses only the master boot record.  A lilo-booted
machine can be backed up and restored with our existing backup software
just fine.  Given these requirements, I wouldn't use grub-pc even if it
were bug free and well documented.  (But neither is the case!)

As for the claims that kernels are too big now, I find that hard to
believe, especially now that we have the large-memory option available.
The standard stock Debian kernel image file that I use for Squeeze,
vmlinuz-2.6.32-3-686, is currently 2234080 bytes.  Are you trying to tell
me that there's no room for a 2M kernel below the start of the EBDA?

I am able to load *both* the kernel *and* the initial RAM filesystem
below the EBDA (i.e. the large-memory option is not used) if I use
MODULES=dep instead of MODULES=most in the initial RAM filesystem
under Lenny.  I'll bet I can do it with Squeeze too.

I realize that lilo doesn't work for everyone, and I'm not suggesting
that it be the default bootloader; but to get rid of it entirely is
unacceptable.  As far as I know, it's the only bootloader that meets
all of my requirements, and I will not voluntarily give it up.

No doubt you will tell me that I am welcome to maintain it myself.
Unfortunately, I do not have the requisite skills to do so.  All I
can do is to appeal in the name of reason that it not be dropped.

Also, please excuse my ignorance, but what exactly is this
"payload size" to which you refer?  Is that the same thing as the
size of the kernel?  Or is it something else?

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/698259750.358730.1274641482395.javamail.r...@md01.wow.synacor.com

Re: Possible boot ordering issues with the packages in Sid

[Kurt Roeckx]

On Sun, May 23, 2010 at 08:25:34PM +0200, Petter Reinholdtsen wrote:
> warning: script ircd-irc2/init.d/ircd-irc2 possibly missing dependency on 
> $syslog

We already covered this in #469605 and it's a false positive.


Kurt


-- 
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/20100523201504.ga10...@roeckx.be

Re: lilo removal in squeeze (or, "please test grub2")

[William Pitcock]

Hi,

- "Stephen Powell"  wrote:

> (blah blah blah blah)

Nobody cares if you are opposed to it.  Unless you are offering to become
lilo upstream, it's going away.

William


-- 
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/2152114.3751274645490011.javamail.r...@ifrit.dereferenced.org

Re: Too much disruptive NMUs

[Ana Guerrero]

Hi!

On Sun, May 23, 2010 at 10:01:22AM +0200, Jan Hauke Rahm wrote:
> On Sun, May 23, 2010 at 08:40:44AM +0200, Lucas Nussbaum wrote:
> > On 22/05/10 at 15:07 +0200, Ana Guerrero wrote:
> > > Hi,
> > > 
> > > It is good to care for packages from people who are currently too busy and
> > > making NMUs to fix critical/very important bugs. However, lately I have 
> > > been
> > > seeing a lot of NMUs that are being very disruptive [0], you have a 
> > > couple of
> > > examples below [1]. (This is not against Jari or Nobihuro, they are just 
> > > the 
> > > latest examples I have seen today).
> > > 
> > > I know this is done with the best intentions but if you think the package 
> > > is in bad shape or neglected by the maintainer then it might better write 
> > > to mia@, debian-qa@ or open a bug asking whether the package should be 
> > > orphaned (or even removed). Both examples below are candidates to be 
> > > orphaned.
> > > 
> > > If you think this kind of changes are good, please start a discussion 
> > > about
> > > changing this in the developers-reference.
> > 
> > Our standard process for addressing issues with such packages is the MIA
> > process. However, the MIA process takes quite a lot of time, and it has
> > happen in the past that it was completely stalled due to a lack of
> > manpower. Also, there are cases where the maintainer will respond to the
> > MIA team, preventing the orphaning of his packages, despite not working
> > on his packages.
> 
> Both true, unfortunately.

I suggested in my first email also "open a bug asking whether the package
should be orphaned" to avoid stalling possible qa-orphaning uploads. I really
think this is the way to go there.
A lot of people when notified about a NMU of their packages do nothing, because 
they are happy somebody else is caring about their packages while they are
busy.
However if the maintainer is really inactive and get an email asking if s/he
is still interested in working in the package it is different, you are being
asked something and you should answer.
This does not mean you should not mail the MIA team at the same time, but you 
do not need to wait action from them (specially if the maintainer agrees
on orphaning), and if we can help globally on removing some work from the
shoulders of the MIA team, the better :D
If the bug keeps unanswered you can ping after some time, it is kept open
even if you do a NMU and after some months without some action, it is time of
retitling it as an orphan bug.

Partially this solves the problem Lucas pointed here, when you have a few bugs 
like those open against a package and routinely closed by the maintainer 
saying "I am still interested I will work on it", you can see publically 
there is a pattern there...
Of course, private details keep going to the non public mia@ alias.


> > So, I think that preparing an NMU that fixes small problems in the
> > package at the same time as contacting the MIA team is a good thing. It
> > helps to improve the quality of Debian, and alleviates the problem of
> > temporarily busy maintainer.
> 
> Ack.

If you contact the MIA team we are not talking about a "temporarily
busy maintainer" we are talking about somebody who seems to have been MIA
for some time.
On my experience, a temporarily busy maintainer is somebody who tells 
you: "go ahead with your NMU I am busy" and usually this package does not need 
too many small fixes because it is more or less maintained.


> > I'd like to encourage Jari and Nobihuro to continue that work, but to
> > make sure that:
> > - they contact the MIA team about the maintainers of the packages they
> >   NMU
> > - the packages they NMU are really _useful_ and should be kept in Debian
> > - they don't NMU actively maintained packages by mistake. If there are
> >   documented efforts to contact the maintainer, using the DELAYED queue
> >   with a long delay would help with that.
> 
> Ack but still:
> 
> - don't be too disruptive!
> 
> I don't think that changing to dh7, i.e. debian/rules to the tiniest
> form, switching a package from dpatch to quilt to finally switch it to
> 3.0 (quilt) are changes that should be done, even if they seem useful.
> And there are more examples.
> 
> I guess the problem is, as usual, where to draw the line.

Yeah, we have here problems with the "don't be too disruptive" part, the 
concept of what a minimal changes seems to be *very* subjective :-)

Ana


-- 
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/20100523213425.ga30...@ana.debian.net

Re: lilo removal in squeeze (or, "please test grub2")

[Stanislav Maslovski]

On Mon, May 24, 2010 at 12:11:30AM +0400, William Pitcock wrote:
> Hi,
> 
> - "Stephen Powell"  wrote:
> 
> > (blah blah blah blah)
> 
> Nobody cares if you are opposed to it.  Unless you are offering to become
> lilo upstream, it's going away.

That is why I love reading d-dev. Some debian developers are so good
at argumentation!

-- 
Stanislav


-- 
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/20100523215431.ga6...@kaiba.homelan

Bug#582831: ITP: png2ico -- png2ico converts PNG files to Windows icon resource files.

[Chris Silva]

Package: wnpp
Severity: wishlist
Owner: Chris Silva 


* Package name: png2ico
  Version : 12.08.02-1
  Upstream Author : Matthias S. Benkmann 
* URL : http://www.winterdrache.de/freeware/png2ico/
* License : GPL-2
  Programming Lang: G++
  Description : png2ico converts PNG files to Windows icon resource files.

png2ico takes the input files and stores them in the out
put file as a Windows icon resource. Usually the input
files would all represent the same image in different
resolutions (common resolutions are 16x16, 32x32 and 64x64).
A program reading the icon resource will pick the image
closest to its desired resolution and will then scale it
if necessary.



-- 
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/20100523233826.6688.24145.report...@chris.makeworld.com

Bug#582835: ITP: ditchers -- tank digging and shooting game

[Jan Jeroným Zvánovec]

Package: wnpp
Severity: wishlist
Owner: "Jan Jeroným Zvánovec" 

* Package name: ditchers
  Version : 1.0.4
  Upstream Author : David Slabý 
* URL : http://ditchers.sourceforge.net/
* License : GPL
  Programming Lang: C++, Lua
  Description : tank digging and shooting game

Description from homepage:
Ditchers is an action game based on principles of the legendary game Tunneler.
Underground tanks dig tunnels in the soil and their goal is to find and
destroy the opponent using a variety of weapons.


signature.asc
Description: Digital signature

Re: lilo removal in squeeze (or, "please test grub2")

[Stephen Powell]

On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote:
> "Stephen Powell"  wrote:
>> (blah blah blah blah)
>
> Nobody cares if you are opposed to it.  Unless you are offering to become
> lilo upstream, it's going away.
> 
> William

I do understand why a Debian package maintainer does not wish to become
"upstream".  And I hope that someone who is both willing and able to do
so steps up to the plate.  But withdrawing it from the distribution seems
like overkill to me, especially since you want to withdraw it from Squeeze
and not Squeeze+1.  Lilo, as it exists today, works just fine for my
purposes.  And apparently it works just fine for a lot of other people too.

The Lord bless you, William.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
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/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com

Re: lilo removal in squeeze (or, "please test grub2")

[Don Armstrong]

On Sun, 23 May 2010, Stephen Powell wrote:
> But withdrawing it from the distribution seems like overkill to me,
> especially since you want to withdraw it from Squeeze and not
> Squeeze+1. Lilo, as it exists today, works just fine for my
> purposes.

If the maintainer doesn't wish to maintain it for another stable
release cycle, and no one steps up to the plate to handle it, it
should be removed.

It's not like the removal of the package from the next release will
cause your "working version" to be removed, after all... and you can
presumably install manually later if you actually want it.


Don Armstrong

-- 
He was wrong. Nature abhors dimensional abnormalities, and seals them
neatly away so that they don't upset people. Nature, in fact, abhors a
lot of things, including vacuums, ships called the Marie Celeste, and
the chuck keys for electric drills.
 -- Terry Pratchet _Pyramids_ p166

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/20100524030219.gk4...@teltox.donarmstrong.com

Re: lilo removal in squeeze (or, "please test grub2")

[Florian Zagler]

On Monday, 24. May 2010, Stephen Powell wrote:
> I do understand why a Debian package maintainer does not wish to become
> "upstream".  And I hope that someone who is both willing and able to do
> so steps up to the plate.  But withdrawing it from the distribution seems
> like overkill to me, especially since you want to withdraw it from Squeeze
> and not Squeeze+1.  Lilo, as it exists today, works just fine for my
> purposes.  And apparently it works just fine for a lot of other people too.

I think the best solution for all should be:
Don't drop lilo in squeeze but mark it orphaned. Leave it in Squeeze and 
schedule the removal for Squeeze+1. It may be unuseful for most users if the 
kernels are too large but if someone uses a (smaller) custom kernel lilo can 
be an alternative and in special cases sometimes the only way to go ...

This gives us all more time to test grub2 and other bootloaders and maybe 
someone finds a solution for Stephens backup problem (which is a good reason 
not to drop lilo now)

Florian


-- 
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/201005240518.27435...@alix.athome

Re: lilo removal in squeeze (or, "please test grub2")

[Christian PERRIER]

Quoting Stanislav Maslovski (stanislav.maslov...@gmail.com):

> > Nobody cares if you are opposed to it.  Unless you are offering to become
> > lilo upstream, it's going away.
> 
> That is why I love reading d-dev. Some debian developers are so good
> at argumentation!

Everybody has time constraints and I think the answer you're quoting
is pretty much well summarizing the point: yes, lilo is useful to some
people.yes, nobody stepped up to maintain it enough for being kept
in the archive, even among those peopleyes, keeping lilo in the
archive is a burden for some *other* people (security team, D-I
"team").

So, the conclusion is easy to drive: if some people are interested in
keeping the lilo package alive, then their only chance is to step up,
keep the package maintenance alive by taking it over (I'm sure nobody
will complain).

This is not much argumentation needed here...:-)

And, yes, I agree that the same could be said about grub2, indeed..:)




signature.asc
Description: Digital signature

Bug#582851: RFP: asus-oled-driver -- Driver for Asus OLED display present in some Asus laptops.

[Roman V. Nikolaev]

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

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

   Package name: asus-oled-driver
Version: 0.03
Upstream Author: Jakub Schmidtke 
URL: http://lapsus.berlios.de/asus_oled.html
URL: http://developer.berlios.de/projects/lapsus/
License: GPL v2
Description: Driver for Asus OLED display present in some Asus laptops.

-- 

 Roman V. Nikolaev

mail:rsha...@rambler.ru
icq: 198-364-657
jabber:  rsha...@jabber.org
site:http://www.rshadow.ru



signature.asc
Description: OpenPGP digital signature

Re: Possible boot ordering issues with the packages in Sid

[Christian PERRIER]

> Christian Perrier 
>console-common (U)
>   warning: script console-common/init.d/keymap.sh possibly missing 
> dependency on $remote_fs

I wonder what in keymap.sh is triggerring this. TTBOMK,
/etc/init.d/keymap.sh is meant to work without /usr being mounted


>samba (U)
>   error: scripts samba/init.d/samba,samba4/init.d/samba4 provide 
> duplicate 'samba'

Error in samba4. Fixed in experimental.

>   warning: script samba/init.d/samba possibly missing dependency on 
> $syslog

samba is not using syslog by default in Debian. Still, I understand
this might be a problem for users who want to activate logging through
syslog. I don't really see any problem adding $syslog to dependencies


>samba4 (U)
>   error: scripts samba/init.d/samba,samba4/init.d/samba4 provide 
> duplicate 'samba'
>   warning: script samba4/init.d/samba4 possibly missing dependency on 
> $syslog
>   info: script samba4/init.d/samba4 does not provide its own name
> 


If we fix samba, we'll fix samba4




signature.asc
Description: Digital signature