Re: "Team uploads"

[Matthew Johnson]

On Mon Apr 06 08:18, Lionel Elie Mamane wrote:
> On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote:
> 
> > In Debian we have several teams working on maintaining large numbers
> > of packages (pkg-games, pkg-perl, pkg-gnome for example). I
> > proposed[1] to silence the lintian NMU warnings in the case of "team
> > uploads"; where the person doing the upload is a member of the team
> > in Maintainers but is not present in Uploaders. Does anyone think
> > this concept of "team uploads" has merit?
> 
> It is a useful concept, but I would like to consider them as "special
> case NMUs" rather than "special case MUs".

Quite apart from the issue of deciding whether or not something is 'team
maintained' in all cases, if you are a member of the team and you are
making uploads to the package, then you should just add yourself to
uploaders, surely...?

That said, the option so far which is least bad is "Team Upload" in the
same way as "QA Upload", i.e. no NMU version number, no  NMU procedures,
no delay, etc, just something to ack the mismatch of changed-by and
uploaders/maintainer.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: "Team uploads"

[Michael Banck]

On Mon, Apr 06, 2009 at 08:18:33AM +0200, Lionel Elie Mamane wrote:
> On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote:
> 
> > In Debian we have several teams working on maintaining large numbers
> > of packages (pkg-games, pkg-perl, pkg-gnome for example). I
> > proposed[1] to silence the lintian NMU warnings in the case of "team
> > uploads"; where the person doing the upload is a member of the team
> > in Maintainers but is not present in Uploaders. Does anyone think
> > this concept of "team uploads" has merit?
> 
> It is a useful concept, but I would like to consider them as "special
> case NMUs" rather than "special case MUs".
> 
>  - NMU version number
>  - first changelog line contains "TU" / "team upload" / "team NMU" /
>...
>  - no need to put patch in bug
>  - no need for NMU delay
>  - no need to upload to delayed queue
> 
> My reasoning is that a package that has had only "team uploads" for
> three years is a package where effectively no human is taking charge
> for maintaining it, just as a package that has had only NMU uploads in
> three years; I'd like QA / potential adopters to see that in the
> sequence of version numbers as they do now.

I don't understand; what is the problem with team uploads?  Sure, there
can be problems in inactive teams, but just because some packages had
team uploads doesn't mean they need special QA attention.

Besides, I think the Gnome team still puts all team members into
Uploaders via some debian/control pre-processing, maybe for the above
reason.

Getting rid of debian/control.in (unless needed otherwise) due to better
team maintership handling might be good thing.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Matthew Johnson]

On Mon Apr 06 08:55, Frans Pop wrote:
> > This is a heads up mail for the D-I team.
> 
> I'm not sure where the original mail comes from, but IMO this should be 
> discussed on d-devel, especially since it impacts more than just D-I. I 
> suspect there are quite a few packages that make some sort of provisions 
> for lilo.
> There are also significant numbers of people still using lilo for, at 
> least for them, very good reasons.

Yes, please do discuss it here. I am one of those users, grub didn't
work on one of my machines for some reason.

Anyway, isn't grub1 equally unmaintained upstream? I thought they were
only working on grub2 (which isn't ready for use yet, or is it?)

> > Don't we have some install paths that still depend on LILO?
> 
> Yes: /boot on LVM is the main one.
 
We _certainly_ shouldn't throw it out if there are _known_ situations
for which it's required.

By all means print large warnings or only make it available in expert
mode, or whatever, but please don't break existing functionality.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: "Team uploads"

[Lionel Elie Mamane]

On Mon, Apr 06, 2009 at 09:27:53AM +0200, Michael Banck wrote:
> On Mon, Apr 06, 2009 at 08:18:33AM +0200, Lionel Elie Mamane wrote:
>> On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote:

>>> I proposed[1] to silence the lintian NMU warnings in the case of
>>> "team uploads"; where the person doing the upload is a member of
>>> the team in Maintainers but is not present in Uploaders.

>> It is a useful concept, but I would like to consider them as
>> "special case NMUs" rather than "special case MUs".

>>  - NMU version number
>>  - first changelog line contains "TU" / "team upload" / "team NMU" / ...
>>  - no need to put patch in bug
>>  - no need for NMU delay
>>  - no need to upload to delayed queue

>> My reasoning is that a package that has had only "team uploads" for
>> three years is a package where effectively no human is taking
>> charge for maintaining it, just as a package that has had only NMU
>> uploads in three years; I'd like QA / potential adopters to see
>> that in the sequence of version numbers as they do now.

> I don't understand; what is the problem with team uploads? Sure,
> there can be problems in inactive teams, but just because some
> packages had team uploads doesn't mean they need special QA
> attention.

Just like NMUs: just because a package had a small number of NMUs does
not mean it needs special QA attention. But a pattern of only NMUs is
a tag for QA attention. As Paul means them (I'm in the team, but for
this particular package I do work on it once, but don't take charge
for any future work), team uploads have the same characteristic: if
there are only team uploads, it is an indicator that nobody within the
team feels responsible for the package. Yes, there can be corner
cases where this is not the case.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Michael Meskes]

On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
> I'm putting the acpi-support package up for adoption. The RFA bug is here:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683

Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes,
the acpi team will welcome new members who like to help too. :-)

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: michaelmeskes, Jabber: mes...@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Charles Plessy]

Le Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise a écrit :
> 
> In Debian we have several teams working on maintaining large numbers
> of packages (pkg-games, pkg-perl, pkg-gnome for example). I
> proposed[1] to silence the lintian NMU warnings in the case of "team
> uploads"; where the person doing the upload is a member of the team in
> Maintainers but is not present in Uploaders. Does anyone think this
> concept of "team uploads" has merit?

Hi Paul,

I think that it is a good concept, but the linian warning has probably a good
reason to exist. For instance, if a bug is closed as part of a "Team upload",
won't the BTS expect a NMU acknowledgement anyway?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Bart Samwel]

Hi Steve,

On Mon, April 6, 2009 05:44, Steve Langasek wrote:
> On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
>> 1. The upstream for this package is Ubuntu. Ubuntu has never been very
>> cooperative at accepting changes, until recently: our contact Steve
>> Langasek has indicated that he is interested in merging most or all of
>> our changes, provided that we send them in in chunks, with proper
>> rationales.
>
> I have to say here in defense of Ubuntu that I don't see any record of
> these
> patches being submitted to the Ubuntu package via Launchpad, which, since
> Ubuntu does not have individual package maintainers, is the only reliable
> way to ensure that proposed changes are seen and considered by the people
> working on the package at any given time.

Yeah, I think it's probably mostly me being disappointed earlier, and not
so much the Ubuntu side. The feeling that I have had is that because there
are no individual package maintainers, it's hard to find somebody on the
other side who feels responsible for the package, and who is willing to
discuss merging of sets of patches etc., so that you can discuss the
chances of acceptance _before_ you do the work. It's so much easier if you
can talk to a person, launchpad sometimes feels like throwing stuff into a
black hole.  Things suddenly got much easier when I got into direct
contact with you. But I shouldn't be blaming Ubuntu, my expectations just
didn't match the way Ubuntu works.

> I don't have time to work on the Debian package myself (either as
> maintainer
> or for sifting through the delta between Debian and Ubuntu), but I
> definitely am happy to accept fixes "upstream" in reasonable-sized chunks.
>
> Anyway, as Bart points out, there's another issue:
>
>> 4. Ubuntu is PHASING OUT this package. They have already moved suspend
>> to pm-utils (but have failed to remove suspend support from
>> acpi-support). They're currently moving hotkey translation to hal. This
>> means that soon we will have no upstream that we can follow! Or we
>> should ensure that Ubuntu's hal changes are included in our version of
>> hal as well -- no clue how those packages are related, or whether
>> Ubuntu's changes are going into upstream hal.
>
> Since the last time I had a chance to speak with Bart about this, there's
> been quite a bit of progress on phasing out the package for Ubuntu; in
> jaunty, we've dropped a number of quirk scripts related to suspend/resume,
> as well as close to 30 of the ACPI event-handling scripts from /etc/acpi -
> basically:  all those scripts that were being used to synthesize key
> events (which doesn't work with recent kernels anyway) and which we could
> verify were being handled by hal.
>
> And yes, Martin Pitt works very closely with hal upstream to ensure fixes
> are incorporated.

Thanks for the update!

Cheers,
Bart


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Japanese Font Transition (step for applications)

[Josselin Mouette]

Le lundi 06 avril 2009 à 06:18 +0900, Hideki Yamane a écrit :
> On Thu, 20 Nov 2008 14:51:28 +0100
> Josselin Mouette  wrote:
> > In which case the correct approach, I think, is to remove all the
> > ttf-japanese-* in Provides:, and upload new ttf-japanese-gothic/mincho
> > packages that depend on a set of alternative fonts, with a reasonable
> > default.
> 
>  Does it mean that 
>   - craete virtual "ttf-japanese-gothic/mincho" package
>   - it depends on ttf-vlgothic or so
>  
>  Is it correct? If so, I'll make package for that and do ITP.

Yes, that’s the idea (although I’d call this a metapackage and not a
virtual package).

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Bug#522741: ITP: ieee-data -- Organizationally Unique Identifier listing

[Filippo Giunchedi]

Package: wnpp
Severity: wishlist
Owner: Filippo Giunchedi 

* Package name: ieee-data
  Version : 20090224
  Upstream Author : IEEE
* URL : http://standards.ieee.org/regauth/oui/index.shtml
* License : not clear if it can be public domain
  Programming Lang: Plain text
  Description : Organizationally Unique Identifier listing

Provide the OUI listing of identifiers registered with IEEE.
Include also Individual Address Block (IAB) listings.

Preliminary package available at
http://svn.debian.org/wsvn/collab-maint/deb-maint/ieee-data/trunk/#_deb-maint_ieee-data_trunk_
 

I've contacted IEEE to clear about the copyright/license of the
listings.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Michael Banck]

On Mon, Apr 06, 2009 at 05:05:40PM +0900, Charles Plessy wrote:
> Le Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise a écrit :
> > 
> > In Debian we have several teams working on maintaining large numbers
> > of packages (pkg-games, pkg-perl, pkg-gnome for example). I
> > proposed[1] to silence the lintian NMU warnings in the case of "team
> > uploads"; where the person doing the upload is a member of the team in
> > Maintainers but is not present in Uploaders. Does anyone think this
> > concept of "team uploads" has merit?
> 
> Hi Paul,
> 
> I think that it is a good concept, but the linian warning has probably a good
> reason to exist. For instance, if a bug is closed as part of a "Team upload",
> won't the BTS expect a NMU acknowledgement anyway?

But it's not an NMU, the Team is effectively the maintainer.

If the team isn't the maintainer, it's not team-maintained, by
definition, I'd say.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Bart Samwel]

Michael Meskes wrote:

On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:

I'm putting the acpi-support package up for adoption. The RFA bug is here:

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


Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes,
the acpi team will welcome new members who like to help too. :-)


Thanks for helping out! It sounds like a very good plan to move 
acpi-support to the acpi team. I will do what's necessary to transfer 
maintainership to you, I'll keep you informed of the progress.


Cheers,
Bart


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Raphael Hertzog]

On Mon, 06 Apr 2009, Bart Samwel wrote:
> black hole.  Things suddenly got much easier when I got into direct
> contact with you. But I shouldn't be blaming Ubuntu, my expectations just
> didn't match the way Ubuntu works.

To be fair, I proposed co-maintenance to Matthew Garrett when I 
integrated acpi-support in Debian and wanted him to use bzr or something
so that we could better collaborate but at that time he was already
telling me that acpi-support should/will die and he wasn't interested in
setting up something more complicated than "change & upload".

I didn' went further to try to collaborate and at that time was packaging
it mostly as a follower of Ubuntu but bugs did accumulate until Bart took
it over.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Romain Beauxis]

Le Monday 06 April 2009 08:18:33 Lionel Elie Mamane, vous avez écrit :
> My reasoning is that a package that has had only "team uploads" for
> three years is a package where effectively no human is taking charge
> for maintaining it, just as a package that has had only NMU uploads in
> three years; I'd like QA / potential adopters to see that in the
> sequence of version numbers as they do now.

I do not agree with you. In the ocaml team, I have prepared uploads for some 
transitions for package for which I am not in the uploader field.

I am not in the uploaders because I am not the main responsible for this 
packaging, however my upload uses the correct workflow, and does not mean 
that there is no maintainer, but only that for small repetitive tasks, 
another member of the team can take care of it.

Hence, requiring NMU versioning and external patch system would really be a 
waste of time that would anihilate the efficiency of working in a team.

That said, I have nothing strong against the lintian warning. After all, it is 
only a warning, and the NMU issues can be worked-out between human beings for 
sure... :-)


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Romain Beauxis]

Le Monday 06 April 2009 09:32:14 Matthew Johnson, vous avez écrit :
> > > Don't we have some install paths that still depend on LILO?
> >
> > Yes: /boot on LVM is the main one.
>
>  
> We _certainly_ shouldn't throw it out if there are _known_ situations
> for which it's required.
>
> By all means print large warnings or only make it available in expert
> mode, or whatever, but please don't break existing functionality.

Agreed 100% !

I also use lilo for /boot on LVM and I also clearly remember that was the 
major reason for the previous debate about the removal of lilo.

I don't see what has changed so far which may change the situation compared to 
that time..



Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Lionel Elie Mamane]

On Mon, Apr 06, 2009 at 10:46:19AM +0200, Romain Beauxis wrote:
> Le Monday 06 April 2009 08:18:33 Lionel Elie Mamane, vous avez écrit :

>> My reasoning is that a package that has had only "team uploads" for
>> three years is a package where effectively no human is taking charge
>> for maintaining it, just as a package that has had only NMU uploads in
>> three years; I'd like QA / potential adopters to see that in the
>> sequence of version numbers as they do now.

> I do not agree with you. In the ocaml team, I have prepared uploads
> for some transitions for package for which I am not in the uploader
> field.

> I am not in the uploaders because I am not the main responsible for
> this packaging, however my upload uses the correct workflow, and
> does not mean that there is no maintainer, but only that for small
> repetitive tasks, another member of the team can take care of it.

Yes, but if the "main responsible for this package" has done no work
on it for three years, it is a sign that maybe he doesn't feel
responsible anymore, or does not have time anymore or something like
that. Not proof, just a sign. Just like NMUs.

It falls in very well in the example you gave; some transitions were
handled by mass-bug filing + delay + NMU of packages that had not
transitioned, so the situation looks similar. For team uploads we
remove the bug filing, the delay, most of the NMU procedures (delay,
special handling of introduced patch, ...), but keep the NMU
numbering.

> Hence, requiring NMU versioning and external patch system

I did not say one should require an external patch system, quite the
contrary. I wrote "no need to put patch in bug", generalise that to
"no need to treat the change / patch specially; just commit it in the
team's VCS repository, if that's what is usually done in that team".

> would really be a waste of time that would anihilate the efficiency
> of working in a team.

The only "burden" I propose imposing is the NMU versioning, which does
not feel to me like it is additional work. Instead of writing "-3",
write "-2.1"; only two keystrokes more.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Paul Wise]

On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote:

> I also use lilo for /boot on LVM and I also clearly remember that was the
> major reason for the previous debate about the removal of lilo.

Grub2 in lenny and later contains an lvm module:

/usr/lib/grub/i386-pc/lvm.mod

Has anyone who uses lilo for this tried grub2?

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

Re: "Team uploads"

[Raphael Hertzog]

On Mon, 06 Apr 2009, Lionel Elie Mamane wrote:
> Just like NMUs: just because a package had a small number of NMUs does
> not mean it needs special QA attention. But a pattern of only NMUs is
> a tag for QA attention. As Paul means them (I'm in the team, but for

The point of team upload is precisely so that you can update the package
and not take responsibility for a package that you don't want to maintain
in the long run.

I was in many Uploaders field because lintian complain if you are not in
Uploaders/Maintainer, yet I was there only for a single team upload for a
perl or a python transition and using an NMU version would have been
wrong because everything was properly done in the team VCS and there
was no NMU to integrate for the next person working on the package.

So I object to using NMU version for team uploads but I would like to
have a mechanism for a team upload that doesn't lead to people adding
themselves in Uploaders when they don't have a (real/long-term) commitment
to the package.

Then, the Maintainer/Uploader field would be again more accurate to
know if we have people that care about the packages or not. So I see this
change as good move to better detect that nobody cares about the package.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Raphael Hertzog]

On Mon, 06 Apr 2009, Charles Plessy wrote:
> I think that it is a good concept, but the linian warning has probably a good
> reason to exist. For instance, if a bug is closed as part of a "Team upload",
> won't the BTS expect a NMU acknowledgement anyway?

IIRC that concept died when we introduced version tracking so it should
cause any problem. Bugs are always version closed (and no more tagged
fixed/fixed-in-nmu).

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Preparing for GTK 3.0 and GNOME 3

[Josselin Mouette]

Hi,

although for various reasons (mostly ongoing transitions) we are quite
late in packaging GNOME 2.26 in Debian, we should also look at the
future. GTK+ 3.0 is planned around march 2010, and GNOME 3.0 a little
while later. With them comes the final deprecation of many GNOME 2.X
interfaces.

It took a very long time (8 years!) to get rid of GTK+ 1.2 and the
process is in its final stage now. I’d like to avoid this horrible mess
for GTK+ 2.X and for the GNOME libraries that will stop being maintained
upstream after the 3.0 release. Fortunately, GTK+ 3.0 is an evolutionary
change, not a revolutionary one. Which means for some applications there
will be zero porting work, and for most of them there will only be minor
changes required. For GNOME libraries, the changes will be more radical.
This concerns less applications, but several libraries will simply
disappear.

What you can do right now is start to work on packages using the GNOME
library stack. For affected packages, you can start working on patches
right now, or at least pester your upstream so that they do.

Now for the various pieces.

GLIB
The changes in GLib will mostly concern in removing deprecated
APIs. If your packages build with -DG_DISABLE_DEPRECATED
-DG_DISABLE_SINGLE_INCLUDES, they are most likely to build with
GLib 3.0 with only compilation changes.

Removed functions have replacements described in the API
documentation.

GDK / GTK+
Same as GLib. If you can build your package with GTK+ 2.16 using
-DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED
-DGDK_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES, it
is very likely that your package can build with GTK+ 3.0.

ESOUND
Applications still using EsounD should be ported to using
libcanberra (for sound events) or GStreamer (for the rest).

GCONF
There are plans to replace GConf by dconf, but it is quite
certain that there will be at least a GConf compatiliby layer,
so there is nothing to be done here.

GNOME-VFS
GnomeVFS has been deprecated for a while in favor of GIO, but
porting is not something trivial.

The GIO API documentation has some notes on how to port from
GnomeVFS.

LIBART
It is now preferred to draw custom objects directly using Cairo,
using the gdk_cairo_* API.

LIBBONOBO / LIBBONOBOUI
This part is completely going away, and it’s not easy. Replacing
it generally means revamping parts of the application to use
D-Bus for communication instead.

LIBIDL / ORBIT
ORBit will stay as a general-purpose CORBA implementation, but
it is not meant to be used in GNOME applications anymore –
currently its primary users are GConf and Bonobo.

LIBGLADE
Libglade is going away in favor of GtkBuilder.

LIBGNOME
This collection of random APIs with various uses is completely
going away. The replacements are scattered among various
libraries now:
  * GnomeProgram => GLib, libunique
  * gnome_execute_* => GLib (g_spawn)
  * gnome_gconf => GConf
  * gnome_help, gnome_url => GIO (g_app_info)
  * gnome_sound => libcanberra
  * Various stuff in GLib
  * More information: http://live.gnome.org/LibgnomeMustDie

LIBGNOMEUI
Same issue as with libgnome, the replacements depend on what the
API is originally about.
  * gnome_init => GLib (GOption)
  * GnomeClient => Session management will be added to GTK+,
it’s still missing AFAIK
  * The various widgets have replacements in GTK+ now.

LIBGNOMECANVAS
Deprecated in favor of libcairo.

LIBEEL
It has never been a widely used library, and it will be gone
after 2.24. Replacements can be found in GTK+ for some widgets,
for some others you will have to look at how it is now done in
Nautilus.

GTKSOURCEVIEW
GtkSourceView 1.X is already deprecated, you should upgrade to
GtkSourceView 2.X now.

LIBGNOMEPRINT / LIBGNOMEPRINTUI
Both deprecated in favor of gtk-unix-print (in GTK+) which is
based on Cairo.

LIBNAUTILUS-BURN
It is going to be replaced with libbrasero-burn which has a very
similar API.

Now let’s get to work. FWIW, the end of the evolution transition should
be tonight, so you’re going to see things move in the GNOME area really
soon.

Cheers,
-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: "Team uploads"

[Raphael Hertzog]

On Mon, 06 Apr 2009, Emilio Pozuelo Monfort wrote:
> Raphael Hertzog wrote:
> > So I object to using NMU version for team uploads but I would like to
> > have a mechanism for a team upload that doesn't lead to people adding
> > themselves in Uploaders when they don't have a (real/long-term) commitment
> > to the package.
> 
> You can put the team name and mailing list in the changelog. That will avoid 
> the
> lintian warning and you can look for team uploads by looking at uploads with 
> the
> team name in the Changed-By field. A recent example:

I have seen that already but it's ugly as well. Changelog are written by
humans and not lists and I like to have the name of someone (to blame) in
the changelog entry.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Charles Plessy]

Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit :
> On Mon, 06 Apr 2009, Charles Plessy wrote:
> > I think that it is a good concept, but the linian warning has probably a 
> > good
> > reason to exist. For instance, if a bug is closed as part of a "Team 
> > upload",
> > won't the BTS expect a NMU acknowledgement anyway?
> 
> IIRC that concept died when we introduced version tracking so it should
> cause any problem. Bugs are always version closed (and no more tagged
> fixed/fixed-in-nmu).

Good :) Does it mean that the Developers Reference must be updated?

Index: pkgs.dbk
===
--- pkgs.dbk(revision 6668)
+++ pkgs.dbk(working copy)
@@ -2073,13 +2073,6 @@
 work on it.
 
 
-
-To acknowledge an NMU, include its changes and changelog entry in your next
-maintainer upload.  If you do not acknowledge the NMU by including the
-NMU changelog entry in your changelog, the bugs will remain closed in the
-BTS but will be listed as affecting your maintainer version of the package.
-
-
 
 
 


By the way, the online copy is “ver. unknown”.

Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Lucas Nussbaum]

On 06/04/09 at 19:48 +0900, Charles Plessy wrote:
> Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit :
> > On Mon, 06 Apr 2009, Charles Plessy wrote:
> > > I think that it is a good concept, but the linian warning has probably a 
> > > good
> > > reason to exist. For instance, if a bug is closed as part of a "Team 
> > > upload",
> > > won't the BTS expect a NMU acknowledgement anyway?
> > 
> > IIRC that concept died when we introduced version tracking so it should
> > cause any problem. Bugs are always version closed (and no more tagged
> > fixed/fixed-in-nmu).
> 
> Good :) Does it mean that the Developers Reference must be updated?
> 
> Index: pkgs.dbk
> ===
> --- pkgs.dbk  (revision 6668)
> +++ pkgs.dbk  (working copy)
> @@ -2073,13 +2073,6 @@
>  work on it.
>  
>  
> -
> -To acknowledge an NMU, include its changes and changelog entry in your next
> -maintainer upload.  If you do not acknowledge the NMU by including the
> -NMU changelog entry in your changelog, the bugs will remain closed in the
> -BTS but will be listed as affecting your maintainer version of the package.
> -
> -
>  
>  
>  

No, that's still correct. If you don't include the changelog entry
fixing the bug, then the BTS' version tracking will be confused, and
think that your version still has the bug.
-- 
| 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

Re: Jack Audio Connection Kit transition

[Adeodato Simó]

* Felipe Sateler [Tue, 31 Mar 2009 08:58:23 +1100]:

> >  * plan for libjack0.100.0-0: there are 11 source packages left with
> >    dependencies on this old library. No sourceful uploads are needed
> >    for this: once you’ve gotten back to me that the plan is good, I
> >    will provide you with a list of packages and schedule Bin-NMUs; then
> >    you can do some work of checking if they built successfully
> >    everywhere, filing bugs, etc. Once all of them have been rebuilt
> >    (which will make them depend on libjack0), please check with us that
> >    they’ve migrated to testing, and at that point libjack0.100.0-0 can
> >    be dropped.

> > Sounds good?

> Amsynth will require a sourceful upload, since the dependency is not
> generated by dpkg-shlibdeps because it dlopens libjack. It is the only
> one I saw.

I’ve scheduled Bin-NMUs for this, for all packages except amsynth. You
can check for build-failures here: http://bit.ly/zLyiK, and for progress
of their migration here: https://buildd.debian.org/transitions/summary.html.

As mentioned above, please check with us before dropping the
libjack0.100.0-0 package.

Cheers,

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new virtual package: "readline-editor"

[Lionel Elie Mamane]

On Mon, Apr 06, 2009 at 12:44:54PM +0200, Stefano Zacchiroli wrote:

> Heya, we have several packages implementing line-editing
> capabilities. I know at least 3 of them: "cle", "ledit", and
> "rlwrap", but there might be others.

Oh yes. Hmm... cle is dead upstream, rather buggy with no progress
whatsoever in a very long time; it was mainly useful before rlwrap
appeared in the real world (not as C source code in
/usr/share/doc/libreadline-dev/examples/, but in /usr/bin/), so I'd
think we should rather remove it.

> (...) they all seem to offer a common interface "NAME command" that
> will run command equipped with line editing capabilities.

> Some packages benefit generically from line editing capabilities
> without caring about the actual tool implementing it. (...)

> I hereby propose to introduce a new virtual package called
> "readline-editor" [1] provided by all tools offering line editing
> capabilities as a command wrapper.

For the rest, yes, sure, that's good progress.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Again: Bug#503367: plink: file conflict with putty-tools

[Steffen Moeller]

Andreas Tille wrote:
> On Fri, 3 Apr 2009, Steffen Moeller wrote:
> 
>> we should ask the technical committee to rule over it. And maybe this
>> needs some voting in the end.
> 
> Who is this *we*?  Do you volunteer?
:) no, since I personally see no preferable alternative to the current 
conflicting state.

> IMHO plink should be renamed because it is way less popular than the
> putty tool.  So we will loose this voting anyway and there is much effort
> for an foreseable outcome.  IMHO the solution I described in README.Debian
> is reasonable for plink users even with existing scripts.

Morten's suggestion of a rename to purcell_plink (or plink_purcell) seems
reasonable to me. snplink I find strange and as it was mentioned in the initial 
thread,
there an earlier program with that name.

>> I personally think that we should not rename it. And putty's plink
>> should not be renamed
>> either. The two are in a technical conflict, though with little
>> practical consequences. To
>> me, this situation is preferable over the renaning of the binary of
>> either.
> 
> This is a worse solution than a rename.

In your view, I know.

>> Please keep in mind that we don't need to package everything.
>> (sn)plink can just be
>> removed from the archive. Or could it move to non-free si it does
>> not adhere to
>> Debian's principles? I need to reread the policy here.
> 
> Moving to non-free will not solve the problem and is just wrong
> (because it is actually not non-free).  Trying to solve a problem
> by pretending wrong facts is a no go.

I know what you mean.

> I'd strongly recommend to settle (together with upstream) for
> a reasonable alternative name (I don't care whether it is
> snplink, Plink, PLINK or something else) but we should find
> a reasonable decision in a short time frame (to not spend to
> power into an issue which does not bring anybody foreward).

If _I_ was upstream, with a program that has such a strong name in the 
community, I would
not change it lightheartedly. PLINK would certainly remain PLINK, the only 
chance I'd see
is that upstream leaves the name PLINK for its software and renames the binary 
alone and
then towards something that is very similar to the old one, maybe p_link or so. 
But this
should possibly be synced with a general API overhaul or so.

The conflict in my view is a problem of Debian or of UNIX in general, not of 
either of the
two plinks. We should have namespaces of some sort and not everything in one 
directory.

Best,

Steffen




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Charles Plessy]

Le Mon, Apr 06, 2009 at 12:52:22PM +0200, Lucas Nussbaum a écrit :
> On 06/04/09 at 19:48 +0900, Charles Plessy wrote:
> > Le Mon, Apr 06, 2009 at 12:13:45PM +0200, Raphael Hertzog a écrit :
> > > On Mon, 06 Apr 2009, Charles Plessy wrote:
> > > > I think that it is a good concept, but the linian warning has probably 
> > > > a good
> > > > reason to exist. For instance, if a bug is closed as part of a "Team 
> > > > upload",
> > > > won't the BTS expect a NMU acknowledgement anyway?
> > > 
> > > IIRC that concept died when we introduced version tracking so it should
> > > cause any problem. Bugs are always version closed (and no more tagged
> > > fixed/fixed-in-nmu).
> > 
> > Good :) Does it mean that the Developers Reference must be updated?
> 
> No, that's still correct. If you don't include the changelog entry
> fixing the bug, then the BTS' version tracking will be confused, and
> think that your version still has the bug.

Aah thank you, that is clearer: I thought that it was meaning that it is still
needed to re-iterate the Closes: command.

So if we assume that in the case of “team uploads” the changes would be
commited in the teams repository, as opposed to NMUs were the diff is sent to
the BTS, it would definitely be useful to have the Debian tools to understand
that it is correct that the person signing the changelog is not listed in the
Uploaders: not the Maintainer: field. Would it be wrong to use the “ * QA
upload” special first line, or is it better to reserve it to the QA team ?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#522753: ITP: primrose -- compelling tile-placement puzzle game

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-CC: debian-devel-ga...@lists.debian.org

* Package name: primrose
  Version : 5
  Upstream Author : Jason Rohrer
* URL : http://primrose.sf.net
* License : None (Public Domain)
  Programming Lang: C++, PHP
  Description : compelling tile-placement puzzle game

Long description will be a distillation of the description linked from
the above URL.

This will be maintained by the pkg-games team.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Preparing for GTK 3.0 and GNOME 3

[Holger Levsen]

Hi, 

I wonder whether this shouldnt have been on d-d-a. I think it should have :)


regards,
Holger, now also wondering if I should send this mail in private ;-)



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

Bug#522770: RM: cle -- ROM; dead uptream; buggy; better alternatives available

[Lionel Elie Mamane]

Package: ftp.debian.org
Severity: normal

Please remove package cle from unstable / testing; source and
binaries. It is dead upstream (no release since 1999), and since I
uploaded it to Debian better alternatives have appeared (such as
rlwrap).

Some Debian-local work has been done in the rather distant past to fix
bugs in it, but they never converged to something that works well in
all cases: when trying to get one program to work, it breaks
others. As far as I know, rlwrap does not share any of the bugs of any
version of cle, making it a strictly better alternative; it is what I
use myself now.

-- 
Lionel



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Goswin von Brederlow]

Matthew Johnson  writes:

> On Mon Apr 06 08:55, Frans Pop wrote:
>> > This is a heads up mail for the D-I team.
>> 
>> I'm not sure where the original mail comes from, but IMO this should be 
>> discussed on d-devel, especially since it impacts more than just D-I. I 
>> suspect there are quite a few packages that make some sort of provisions 
>> for lilo.
>> There are also significant numbers of people still using lilo for, at 
>> least for them, very good reasons.
>
> Yes, please do discuss it here. I am one of those users, grub didn't
> work on one of my machines for some reason.
>
> Anyway, isn't grub1 equally unmaintained upstream? I thought they were
> only working on grub2 (which isn't ready for use yet, or is it?)

So lets get grub2 working everywhere. :) A worthy goal.

>> > Don't we have some install paths that still depend on LILO?
>> 
>> Yes: /boot on LVM is the main one.
>  
> We _certainly_ shouldn't throw it out if there are _known_ situations
> for which it's required.

We just shouldn't have /boot on lvm. At least there should be one
place outside lvm to store /etc/lvm/archive and /etc/lvm/backup so
that in the case lvm breaks (gets broken by the user) one can repair
it. Linking them to /boot/lvm/archive and /boot/lvm/backup with /boot
outside lvm seem like a good idea.

The problem with /boot on lvm is that moving or resizing it can break
it. So I always found it a good partition to keep outside lvm.

> By all means print large warnings or only make it available in expert
> mode, or whatever, but please don't break existing functionality.
>
> Matt
> -- 
> Matthew Johnson

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

new virtual package: "readline-editor"

[Stefano Zacchiroli]

Heya, we have several packages implementing line-editing
capabilities. I know at least 3 of them: "cle", "ledit", and "rlwrap",
but there might be others.  Some are implemented on top of GNU
readline, some are not (e.g. "ledit"), nevertheless they all seem to
offer a common interface "NAME command" that will run command equipped
with line editing capabilities.

Some packages benefit generically from line editing capabilities
without caring about the actual tool implementing it. My example is
"ocaml" which has an interactive top-level with no built-in line
editing capabilities, but there are others.

I hereby propose to introduce a new virtual package called
"readline-editor" [1] provided by all tools offering line editing
capabilities as a command wrapper. The implementation should be via
alternatives; as priorities I propose having higher priority for those
implemented on top of GNU readline, because apparently they are
superior to ledit (e.g., they share a persistent history).

If there are no objections I'll submit patches to the three mentioned
packages, and possibly to the other matching the category.

Comments?

Cheers.

[1] An apparently more natural name could have been "line editor", but
in the UNIX world it has been traditionally used to refer to
things like "ed", and can be misleading.

-- 
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: "Team uploads"

[Emilio Pozuelo Monfort]

Raphael Hertzog wrote:
> So I object to using NMU version for team uploads but I would like to
> have a mechanism for a team upload that doesn't lead to people adding
> themselves in Uploaders when they don't have a (real/long-term) commitment
> to the package.

You can put the team name and mailing list in the changelog. That will avoid the
lintian warning and you can look for team uploads by looking at uploads with the
team name in the Changed-By field. A recent example:

python-markdown (1.7-2) unstable; urgency=low

  [ Sandro Tosi ]
  * debian/control
- switch Vcs-Browser field to viewsvn

  [ Emilio Pozuelo Monfort ]
  * debian/rules: Don't rely on python-support directory
structure. Thanks Josselin Mouette. Closes: #517061.
  * Standards-Version is 3.8.0. No changes needed.

 -- Debian Python Modules Team 
Wed, 25 Feb 2009 23:35:20 +0100



signature.asc
Description: OpenPGP digital signature

Re: New architectures

[Goswin von Brederlow]

> Joerg Jaspert  disait :
>
>> we just added two new architectures to the Debian archive. Everybody
>> please welcome
>
>>   kfreebsd-i386 AKA GNU/kFreeBSD i386
>>   kfreebsd-amd64 AKA GNU/kFreeBSD amd64

Hi Joerg,

What should be done with amd64-libs and ia32-libs now? Can we add
those archs to it as they are?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Raphael Hertzog]

On Mon, 06 Apr 2009, Lionel Elie Mamane wrote:
> > would really be a waste of time that would anihilate the efficiency
> > of working in a team.
> 
> The only "burden" I propose imposing is the NMU versioning, which does
> not feel to me like it is additional work. Instead of writing "-3",
> write "-2.1"; only two keystrokes more.

Too many tools assume that an NMU version is an NMU… for example the PTS
would warn that a NMU has to be integrated/acknowledged.

I don't see what the NMU versioning buys us. The fact that Uploaders is no
more cluttered by entries for people that don't feel responsible seems
like to compensate what the NMU versioning would bring us. 

You can also count the number of consecutive entries that use an email not
listed in Uploaders to get a somewhat similar statistic than the one
you're looking for.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Romain Beauxis]

Le Monday 06 April 2009 12:27:22 Raphael Hertzog, vous avez écrit :
> > You can put the team name and mailing list in the changelog. That will
> > avoid the lintian warning and you can look for team uploads by looking at
> > uploads with the team name in the Changed-By field. A recent example:
>
> I have seen that already but it's ugly as well. Changelog are written by
> humans and not lists and I like to have the name of someone (to blame) in
> the changelog entry.

Hummm...
For blaming, there should be the specific name of the responsible in the 
changelog. Also, it seems meaningful to me that the changelog is named after 
the team, it seems to be equivalent to the real world "on behalf of the XXX 
team".

A correct semantics could then be:
$PACKAGE ($VERSION) unstable; urgency=low

  [ Romain Beauxis ]
  * Did a very bad thing

 -- Package Team 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#522772: ITP: CDO -- Climate Data Operators

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: CDO
  Version : 1.3.0
  Upstream Author : Uwe Schulzweida  uwe.schulzwe...@zmaw.de
* URL : http://www.mpimet.mpg.de/fileadmin/software/cdo/
* License : GPL2
  Programming Lang: C
  Description : Climate Data Operators - tools for climate data manipulation

CDO is a collection of command line Operators to manipulate and analyse Climate 
model Data.
Supported data formats are GRIB, netCDF, SERVICE, EXTRA and IEG. There are more 
than 400
operators available. The following table provides a brief overview of the main 
categories. 

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#522775: ITP: EMOSLIB -- ECMWF Interpolation Library

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: EMOSLIB
  Version : 000360
  Upstream Author : European Centre for Medium-range Weather Forecasts
* URL : 
http://www.ecmwf.int/products/data/software/interpolation.html
* License : LGPL v2
  Programming Lang: F, Fortran
  Description : ECMWF Interpolation Library

The Interpolation library (EMOSLIB) includes Interpolation software and GRIB, 
BUFR, CREX encoding/decoding routines. It 
is used by the ECMWF meteorological archival and retrieval system (MARS) and 
also by the ECMWF graphics packag MetView.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Matthew Johnson]

On Mon Apr 06 11:07, Goswin von Brederlow wrote:
> 
> So lets get grub2 working everywhere. :) A worthy goal.
> 
Sure, but don't remove lilo until we're happy that grub2 does work
everywhere.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: "Team uploads"

[Raphael Hertzog]

On Mon, 06 Apr 2009, Romain Beauxis wrote:
> For blaming, there should be the specific name of the responsible in the 
> changelog. Also, it seems meaningful to me that the changelog is named after 
> the team, it seems to be equivalent to the real world "on behalf of the XXX 
> team".

Except when you have multiple people listed you don't know who uploaded
without resorting to who-uploads (or gpg check). Anyway, it's a matter of
taste mainly. For me a changelog signature should refer to a human and not a
mailing list.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Otavio Salvador]

Frans Pop  writes:

> On Monday 06 April 2009, Christian Perrier wrote:

[...]

>> > I do not have time to manage the removal at this point, but it will
>> > be gone by June.
>
> Has the package already been offered for adoption? Preferably with an 
> overview of its current (upstream) status and main issues. I'd say that 
> if there's anybody willing to (actively) maintain it, it should not be 
> removed.

Fully agree; it should be properly offered for adoption.

>> This is a heads up mail for the D-I team.
>
> I'm not sure where the original mail comes from, but IMO this should be 
> discussed on d-devel, especially since it impacts more than just D-I. I 
> suspect there are quite a few packages that make some sort of provisions 
> for lilo.
> There are also significant numbers of people still using lilo for, at 
> least for them, very good reasons.
>
> Anyone remember the fairly big upset when lilo was removed from testing 
> around D-I Lenny Beta2?

I also share the feeling that a lot of people still uses LILO; if
possible I do belive it should be kept.


[...]

-- 
O T A V I OS A L V A D O R
-
 E-mail: ota...@debian.org  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Cyril Brulebois]

Raphael Hertzog  (06/04/2009):
> Except when you have multiple people listed you don't know who
> uploaded without resorting to who-uploads (or gpg check).

Not to mention cases where 5 people are listed there, and the package
got sponsored by even someone else (any idea how many NMs there were in
pkg-games?).

> For me a changelog signature should refer to a human and not a mailing
> list.

Indeed, I like to know who took the “this package can be uploaded”
decision, which is a bit more important than just committing a fix in
$VCS and adding ones name to the changelog. A bit of final review has to
be done, to ensure the whole is consistent; and I expect the trailer
line to tell me who did that work.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: lilo about to be dropped?

[Harald Braumann]

On Mon, 6 Apr 2009 17:03:10 +0800
Paul Wise  wrote:

> On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote:
> 
> > I also use lilo for /boot on LVM and I also clearly remember that
> > was the major reason for the previous debate about the removal of
> > lilo.
> 
> Grub2 in lenny and later contains an lvm module:
> 
> /usr/lib/grub/i386-pc/lvm.mod
> 
> Has anyone who uses lilo for this tried grub2?

Yes, I do and it works without problems. There are some inconveniences,
though, with grub2, which might make some stick with LILO:

* on boot it takes quite some time for grub2 to scan the disks for LVM
volumes

* configuration of grub2 is really a PITA

The is no simple configuration file that one could edit. You have to
write scripts to add entries.

You can't specify the default entry (only the number of the entry,
which changes if a new kernel is installed) and there is no
vmlinuz/vmlinuz.old (unless you add a script that adds these entries)

You can't specify boot options per entry (there's only a global option
in /etc/default grub, that applies to all entries).

Cheers,
harry


signature.asc
Description: PGP signature

Re: lilo about to be dropped?

[Darren Salt]

I demand that Otavio Salvador may or may not have written...

> Frans Pop  writes:
[snip]
>> Anyone remember the fairly big upset when lilo was removed from testing 
>> around D-I Lenny Beta2?

> I also share the feeling that a lot of people still use LILO; if possible
> I do belive it should be kept.

. I for one use it, and intend to continue using it.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 => avoid massive flooding.TIME IS RUNNING OUT *FAST*.

Under Windows, a program will expand to fill all available virtual memory.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Gunnar Wolf]

Petter Reinholdtsen dijo [Sat, Apr 04, 2009 at 06:42:29AM +0200]:
> Not quite sure what the question is.  As far as I know, Debian
> supported tmpfs mounted /var/run when I become co-maintainer of
> sysvinit, and I have tried to keep it this way.  The only recent
> changes it that it has become easier to enable it.  Very good to
> notice that this now is documented in the policy.
> 
> If you wonder what the advantages of tmpfs in /var/run is, I know of
> several, but do not really have time to track down them all.  One of
> them I care specially about is the fact that it allow a computer to
> boot with a read-only local file system (think diskless workstations
> and thin clients booting LTSP, machines with flash disks and files
> with problems with their file systems), and I believe this is a clear
> advantage.  Having tmpfs there also make it more obvious that the
> content of /var/run/ will be erased at boot.

It does achieve not having bogus information on. If your system
crashed, some crappy daemons will refuse to start if
/var/run/crappyserver.pid exists, or will try to communicate with
their peers using /var/run/sloppydaemon.socket, possibly failing
cleanly, but possibly leading to head-scratching

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Romain Beauxis]

Le Monday 06 April 2009 16:08:36 Cyril Brulebois, vous avez écrit :
> Indeed, I like to know who took the “this package can be uploaded”
> decision, which is a bit more important than just committing a fix in
> $VCS and adding ones name to the changelog. A bit of final review has to
> be done, to ensure the whole is consistent; and I expect the trailer
> line to tell me who did that work.

Couldn't this also be a line in the changelog ?
This is not a standard but this is done in many cases:

 [ Romain Beauxis ]
 * Upload to $TARGET


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote:
> On Mon, 6 Apr 2009 17:03:10 +0800
> Paul Wise  wrote:
> 
> > On Mon, Apr 6, 2009 at 4:49 PM, Romain Beauxis wrote:
> > 
> > > I also use lilo for /boot on LVM and I also clearly remember that
> > > was the major reason for the previous debate about the removal of
> > > lilo.
> > 
> > Grub2 in lenny and later contains an lvm module:
> > 
> > /usr/lib/grub/i386-pc/lvm.mod
> > 
> > Has anyone who uses lilo for this tried grub2?
> 
> Yes, I do and it works without problems. There are some inconveniences,
> though, with grub2, which might make some stick with LILO:

The LVM support in LILO is hideously broken, so these arguments do not
really matter. It only works in certain conditions and is known to break
horribly if you have say, a kernel spanning multiple PVs.

Only a true idiot boots off an LVM volume anyway, since there is risk of
metadata corruption, etc. The real reasoning for carrying LILO around is
for machines where grub1 does not work, and we have ext2linux for those
situations now.

> 
> * on boot it takes quite some time for grub2 to scan the disks for LVM
> volumes
> 
> * configuration of grub2 is really a PITA
> 
> The is no simple configuration file that one could edit. You have to
> write scripts to add entries.

/boot/grub/{menu.lst,grub.conf} is hard to edit...?

> 
> You can't specify the default entry (only the number of the entry,
> which changes if a new kernel is installed) and there is no
> vmlinuz/vmlinuz.old (unless you add a script that adds these entries)

"default X" in the config file, and "setdefault", works for me.

> 
> You can't specify boot options per entry (there's only a global option
> in /etc/default grub, that applies to all entries).

Sure you can, just don't use update-grub(1) and update it yourself
instead. Same as lilo, really.

William


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

Re: lilo about to be dropped?

[Giacomo A. Catenazzi]

Frans Pop wrote:

On Monday 06 April 2009, Christian Perrier wrote:

Quoting William Pitcock (neno...@dereferenced.org):

lilo is due for removal anyway due to being unmaintained upstream and
the widespread availability of alternatives.


I think that last part is debatable.


I do not have time to manage the removal at this point, but it will
be gone by June.


Has the package already been offered for adoption? Preferably with an 
overview of its current (upstream) status and main issues. I'd say that 
if there's anybody willing to (actively) maintain it, it should not be 
removed.



This is a heads up mail for the D-I team.


I'm not sure where the original mail comes from, but IMO this should be 
discussed on d-devel, especially since it impacts more than just D-I. I 
suspect there are quite a few packages that make some sort of provisions 
for lilo.
There are also significant numbers of people still using lilo for, at 
least for them, very good reasons.


I totally agree.
But I think that lilo package description must be changed, warning new
users that lilo have several limits (thus not all kernel within debian
are bootable with lilo).

Maybe we could also require grub{,2} when installing lilo (chained
as other in lilo, for emergency, new debian kernel policies, etc),
but I don't know if it is feasible (e.g. when lilo is not in MBR).

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 15:09 +0100, Darren Salt wrote:
> I demand that Otavio Salvador may or may not have written...
> 
> > Frans Pop  writes:
> [snip]
> >> Anyone remember the fairly big upset when lilo was removed from testing 
> >> around D-I Lenny Beta2?
> 
> > I also share the feeling that a lot of people still use LILO; if possible
> > I do belive it should be kept.
> 
> . I for one use it, and intend to continue using it.

Have you looked into ext2linux? It is intended to supercede lilo. I
think your usage requirements will be satisfied by it.

William


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

Re: lilo about to be dropped?

[Mike Hommey]

On Mon, Apr 06, 2009 at 10:24:54AM -0500, William Pitcock 
 wrote:
> On Mon, 2009-04-06 at 16:17 +0200, Harald Braumann wrote:
> > You can't specify boot options per entry (there's only a global option
> > in /etc/default grub, that applies to all entries).
> 
> Sure you can, just don't use update-grub(1) and update it yourself
> instead. Same as lilo, really.

Even with update-grub, you can:
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##  kopt_2_6_8=root=/dev/hdc1 ro
##  kopt_2_6_8_2_686=root=/dev/hdc2 ro

This suits most needs.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 10:44 -0300, Otavio Salvador wrote:
> Frans Pop  writes:
> 
> > On Monday 06 April 2009, Christian Perrier wrote:
> 
> [...]
> 
> >> > I do not have time to manage the removal at this point, but it will
> >> > be gone by June.
> >
> > Has the package already been offered for adoption? Preferably with an 
> > overview of its current (upstream) status and main issues. I'd say that 
> > if there's anybody willing to (actively) maintain it, it should not be 
> > removed.
> 
> Fully agree; it should be properly offered for adoption.
> 
> >> This is a heads up mail for the D-I team.
> >
> > I'm not sure where the original mail comes from, but IMO this should be 
> > discussed on d-devel, especially since it impacts more than just D-I. I 
> > suspect there are quite a few packages that make some sort of provisions 
> > for lilo.
> > There are also significant numbers of people still using lilo for, at 
> > least for them, very good reasons.
> >
> > Anyone remember the fairly big upset when lilo was removed from testing 
> > around D-I Lenny Beta2?
> 
> I also share the feeling that a lot of people still uses LILO; if
> possible I do belive it should be kept.

The only way it is feasible to do so is to drop all of the Debian
patches. Without this, upstream is not cooperative with us.

However, I think ext2linux is a feasible upgrade path and that lilo will
become unnecessary by the release of squeeze.

William



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Giacomo A. Catenazzi]

William Pitcock wrote:

On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:

Frans Pop wrote:

On Monday 06 April 2009, Christian Perrier wrote:

Quoting William Pitcock (neno...@dereferenced.org):

lilo is due for removal anyway due to being unmaintained upstream and
the widespread availability of alternatives.

I think that last part is debatable.


I do not have time to manage the removal at this point, but it will
be gone by June.
Has the package already been offered for adoption? Preferably with an 
overview of its current (upstream) status and main issues. I'd say that 
if there's anybody willing to (actively) maintain it, it should not be 
removed.



This is a heads up mail for the D-I team.
I'm not sure where the original mail comes from, but IMO this should be 
discussed on d-devel, especially since it impacts more than just D-I. I 
suspect there are quite a few packages that make some sort of provisions 
for lilo.
There are also significant numbers of people still using lilo for, at 
least for them, very good reasons.

I totally agree.
But I think that lilo package description must be changed, warning new
users that lilo have several limits (thus not all kernel within debian
are bootable with lilo).

Maybe we could also require grub{,2} when installing lilo (chained
as other in lilo, for emergency, new debian kernel policies, etc),
but I don't know if it is feasible (e.g. when lilo is not in MBR).


chainloader will work with lilo, but lilo is only kept around for the
people who are crazy and booting off LVMs as it is.


Yes, but it works if you have an additional partition (for boot
record). I don't know if they could live in the same partition
(with some magic).

But IIRC lilo fails also in other cases: some xen immages, on very big
images (which can be reached in some initram).


Booting off LVMs is supported directly by grub2 and ext2linux could
probably be modified to support it in a much better way than lilo does
it, so this is not really a compelling argument for keeping it.


What is ext2linux? packages.d.o and google doesn't give me relevant
informations.

ciao
cate




William




--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
> Frans Pop wrote:
> > On Monday 06 April 2009, Christian Perrier wrote:
> >> Quoting William Pitcock (neno...@dereferenced.org):
> >>> lilo is due for removal anyway due to being unmaintained upstream and
> >>> the widespread availability of alternatives.
> > 
> > I think that last part is debatable.
> > 
> >>> I do not have time to manage the removal at this point, but it will
> >>> be gone by June.
> > 
> > Has the package already been offered for adoption? Preferably with an 
> > overview of its current (upstream) status and main issues. I'd say that 
> > if there's anybody willing to (actively) maintain it, it should not be 
> > removed.
> > 
> >> This is a heads up mail for the D-I team.
> > 
> > I'm not sure where the original mail comes from, but IMO this should be 
> > discussed on d-devel, especially since it impacts more than just D-I. I 
> > suspect there are quite a few packages that make some sort of provisions 
> > for lilo.
> > There are also significant numbers of people still using lilo for, at 
> > least for them, very good reasons.
> 
> I totally agree.
> But I think that lilo package description must be changed, warning new
> users that lilo have several limits (thus not all kernel within debian
> are bootable with lilo).
> 
> Maybe we could also require grub{,2} when installing lilo (chained
> as other in lilo, for emergency, new debian kernel policies, etc),
> but I don't know if it is feasible (e.g. when lilo is not in MBR).

chainloader will work with lilo, but lilo is only kept around for the
people who are crazy and booting off LVMs as it is.

Booting off LVMs is supported directly by grub2 and ext2linux could
probably be modified to support it in a much better way than lilo does
it, so this is not really a compelling argument for keeping it.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Cyril Brulebois]

Romain Beauxis  (06/04/2009):
> Couldn't this also be a line in the changelog ?

Like the trailer line, yes.

> This is not a standard but this is done in many cases:
> 
>  [ Romain Beauxis ]
>  * Upload to $TARGET

Dunno about others, but I just see that as: this person chose to target
this or that suite (e.g. unstable after a while in experimental, or
experimental to keep things clear for testing/freeze), rather than a
final decision.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: lilo about to be dropped?

[Dmitry E. Oboukhov]

OS> I also share the feeling that a lot of people still uses LILO; if
OS> possible I do belive it should be kept.

I use lilo, I like lilo.
I don't like grub because it has unlogically config, unlogically
behavior, strange reconfig-system. I don't like the programs with
perverse intellect. Grub is not unixway.

I shall use lilo until it is possible.

Dear, lilo maintainers! Please don't remove lilo*.deb from debian.

--
... mpd paused: Accept - Can't Stand The Night

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: lilo about to be dropped?

[Mike Hommey]

On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov  
wrote:
> OS> I also share the feeling that a lot of people still uses LILO; if
> OS> possible I do belive it should be kept.
> 
> I use lilo, I like lilo.
> I don't like grub because it has unlogically config, unlogically
> behavior, strange reconfig-system. I don't like the programs with
> perverse intellect. Grub is not unixway.

Which is more perverse to read a kernel?
- reading actual files from actual filesystems
- reading hardcoded blocks on the device

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 17:40 +0200, Giacomo A. Catenazzi wrote:
> William Pitcock wrote:
> > On Mon, 2009-04-06 at 17:26 +0200, Giacomo A. Catenazzi wrote:
> >> Frans Pop wrote:
> >>> On Monday 06 April 2009, Christian Perrier wrote:
>  Quoting William Pitcock (neno...@dereferenced.org):
> > lilo is due for removal anyway due to being unmaintained upstream and
> > the widespread availability of alternatives.
> >>> I think that last part is debatable.
> >>>
> > I do not have time to manage the removal at this point, but it will
> > be gone by June.
> >>> Has the package already been offered for adoption? Preferably with an 
> >>> overview of its current (upstream) status and main issues. I'd say that 
> >>> if there's anybody willing to (actively) maintain it, it should not be 
> >>> removed.
> >>>
>  This is a heads up mail for the D-I team.
> >>> I'm not sure where the original mail comes from, but IMO this should be 
> >>> discussed on d-devel, especially since it impacts more than just D-I. I 
> >>> suspect there are quite a few packages that make some sort of provisions 
> >>> for lilo.
> >>> There are also significant numbers of people still using lilo for, at 
> >>> least for them, very good reasons.
> >> I totally agree.
> >> But I think that lilo package description must be changed, warning new
> >> users that lilo have several limits (thus not all kernel within debian
> >> are bootable with lilo).
> >>
> >> Maybe we could also require grub{,2} when installing lilo (chained
> >> as other in lilo, for emergency, new debian kernel policies, etc),
> >> but I don't know if it is feasible (e.g. when lilo is not in MBR).
> > 
> > chainloader will work with lilo, but lilo is only kept around for the
> > people who are crazy and booting off LVMs as it is.
> 
> Yes, but it works if you have an additional partition (for boot
> record). I don't know if they could live in the same partition
> (with some magic).
> 
> But IIRC lilo fails also in other cases: some xen immages, on very big
> images (which can be reached in some initram).
> 
> > Booting off LVMs is supported directly by grub2 and ext2linux could
> > probably be modified to support it in a much better way than lilo does
> > it, so this is not really a compelling argument for keeping it.
> 
> What is ext2linux? packages.d.o and google doesn't give me relevant
> informations.

Oops. It is extlinux. It's syslinux except it boots off a hard-disk
instead of a floppy or CD. Quite similar to lilo in featureset.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Vincent Zweije]

On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote:

||  On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
 wrote:

||  > I use lilo, I like lilo.
||  > I don't like grub because it has unlogically config, unlogically
||  > behavior, strange reconfig-system. I don't like the programs with
||  > perverse intellect. Grub is not unixway.
||
||  Which is more perverse to read a kernel?
||  - reading actual files from actual filesystems
||  - reading hardcoded blocks on the device

I think this question should be:

Which is more perverse to read without a kernel?

The answer could still fall either way.

Personally, as one point of measurement, I prefer lilo because it's
lightweight.

Ciao.  Vincent.
-- 
Vincent Zweije | "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature

Re: "Team uploads"

[gregor herrmann]

On Mon, 06 Apr 2009 11:52:54 +0800, Paul Wise wrote:

> In Debian we have several teams working on maintaining large numbers
> of packages (pkg-games, pkg-perl, pkg-gnome for example). 

True :)

> I
> proposed[1] to silence the lintian NMU warnings in the case of "team
> uploads"; where the person doing the upload is a member of the team in
> Maintainers but is not present in Uploaders. Does anyone think this
> concept of "team uploads" has merit?

I agree that having to add yourself to Uploaders to avoid NMU
warnings (or listings under "sponsored uploads" on the DDPO page) is
a pain.

I'm just not sure about a viable solution; adding "Team upload" to
the changelog is clumsy too and only helps against the lintian
warnings but not against other mechanisms.

(And I agree with statements by others that NMU versions are wrong
and that group-address-in-changelog-trailer is at least weird.)


IMO the general problem is that our tools (both the locally installed
ones and the infrastructures ones) don't have a concept of "teams"
and "team membership" in itself. If we had a possibility to
declare/detect "this package is team-maintained by $team, and $person
is member of $team", it would be easier ...


Cheers,
gregor
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Joan Baez: For Sasha


signature.asc
Description: Digital signature

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 18:06 +0200, Mike Hommey wrote:
> On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
>  wrote:
> > OS> I also share the feeling that a lot of people still uses LILO; if
> > OS> possible I do belive it should be kept.
> > 
> > I use lilo, I like lilo.
> > I don't like grub because it has unlogically config, unlogically
> > behavior, strange reconfig-system. I don't like the programs with
> > perverse intellect. Grub is not unixway.
> 
> Which is more perverse to read a kernel?
> - reading actual files from actual filesystems
> - reading hardcoded blocks on the device

Not to mention that it breaks if the blocks span multiple devices. See
also: LVM.

William



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

Re: lilo about to be dropped?

[William Pitcock]

On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote:
> On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote:
> 
> ||  On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
>  wrote:
> 
> ||  > I use lilo, I like lilo.
> ||  > I don't like grub because it has unlogically config, unlogically
> ||  > behavior, strange reconfig-system. I don't like the programs with
> ||  > perverse intellect. Grub is not unixway.
> ||
> ||  Which is more perverse to read a kernel?
> ||  - reading actual files from actual filesystems
> ||  - reading hardcoded blocks on the device
> 
> I think this question should be:
> 
> Which is more perverse to read without a kernel?
> 
> The answer could still fall either way.

No, the answer is always the second one.

William



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

Re: lilo about to be dropped?

[Christian Perrier]

Quoting Frans Pop (elen...@planet.nl):

> I'm not sure where the original mail comes from, but IMO this should be 

From lilo package BTS which I was tracking for l10n purposes. So I
just happened to notice William's answer to a bug report and thought
it would be good for this to be discussed in public.

Clearly, I didn't choose the right place to discuss and the topic has
wider implications than just D-I, as the followups show. Good thing
that you made the discussion wider.

> > Don't we have some install paths that still depend on LILO?
> 
> Yes: /boot on LVM is the main one.
> 
> > Anyway, even if we don't, I think we should track that lilo removal
> > and coordinate with William, in order to stop providing
> > lilo-installer.
> >
> > And, I think this should be mentioned as a release goal (dropping
> > lilo). Either high priority if we have install paths depending on
> > lilo, or normal priority otherwise.
> 
> D-I release goal or Debian release goal [1]?

Clearly Debian release "goal".

> IMO the latter could well be justified as there will also need to be some 
> kind of upgrade strategy for existing users that does not make 
> uncontrolled changes on their hard disk or loses them the ability to boot 
> alternative OSes on dual (or multi) boot systems.

Which might be very tricky

But, as William mentioned in his original mail, upstream activity
seems to be low so we need to figure out if we want to keep yet
another unmaintained software in Debian. What later puzzled me if the
mention in non collaboratve upstream *if we don't drop Debian
patches*.

That's not exactly inactive upstream so it would be good to clarify
the situation of lilo upstream.



signature.asc
Description: Digital signature

Re: lilo about to be dropped?

[Martin Wuertele]

* William Pitcock  [2009-04-06 17:48]:

> chainloader will work with lilo, but lilo is only kept around for the
> people who are crazy and booting off LVMs as it is.
>
> Booting off LVMs is supported directly by grub2 and ext2linux could
> probably be modified to support it in a much better way than lilo does
> it, so this is not really a compelling argument for keeping it.

Actually lilo is installed by lenny d-i if you use root-sw-raid with
LVM, even if your /boot is an differen partition/sw-raid. Therefore lilo
should at least remain for sqeeze to ensure a proper upgrade path.

Furthermore I still have 2 machines that refuse to boot with either grub
or grub2 but work fine with lilo.

And finally your continous insulting of users is not beneficial to the
discussion so please refrain from calling others "crazy" or "stupid".

yours
Martin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Gunnar Wolf wrote:
> Petter Reinholdtsen dijo [Sat, Apr 04, 2009 at 06:42:29AM +0200]:
>> Not quite sure what the question is.  As far as I know, Debian
>> supported tmpfs mounted /var/run when I become co-maintainer of
>> sysvinit, and I have tried to keep it this way.  The only recent
>> changes it that it has become easier to enable it.  Very good to
>> notice that this now is documented in the policy.
>>
>> If you wonder what the advantages of tmpfs in /var/run is, I know of
>> several, but do not really have time to track down them all.  One of
>> them I care specially about is the fact that it allow a computer to
>> boot with a read-only local file system (think diskless workstations
>> and thin clients booting LTSP, machines with flash disks and files
>> with problems with their file systems), and I believe this is a clear
>> advantage.  Having tmpfs there also make it more obvious that the
>> content of /var/run/ will be erased at boot.
> 
> It does achieve not having bogus information on. If your system
> crashed, some crappy daemons will refuse to start if
> /var/run/crappyserver.pid exists, or will try to communicate with
> their peers using /var/run/sloppydaemon.socket, possibly failing
> cleanly, but possibly leading to head-scratching

/etc/init.d/mountall-bootclean.sh will take care of cleaning up /var/tmp.

If not, it would be a bug in mountall-bootclean.sh.


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



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Steve Langasek wrote:
> On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote:
>>> Ubuntu.  The FHS is silent about directories in /var/run across reboots
>>> but requires that all files in /var/run be deleted on reboot.
> 
 4.) You have to manually cleanup in postrm. (I guess most packages will 
 forget
 that, leaving cruft around)
> 
>>> If you're creating any files in /var/run during the operation of the
>>> package (and if not, why do you have a directory in /var/run in the first
>>> place?), then you have to do this anyway, so this isn't new.  (Well, I
>>> suppose you could just rely on the next reboot deleting them, but that
>>> doesn't feel very clean and I'm not sure that's really in the spirit of
>>> our requirements.)
> 
>> Not really. Say you have a pretty standard system daemon
>> When the daemon is stopped in postinst, the pid file will be automatically
>> deleted and dpkg will cleanup the remaining /var/run/$foo directory.
> 
> I think he's referring to the fact that the FHS requires all files in
> /var/run to be cleared on boot.  We have an init script
> (/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system
> level, though, on behalf of all packages; the trouble is it's a lot less
> efficient, overall, to have to repeatedly clean /var/run on boot than it is
> to just write it to a tmpfs and let the contents be lost on reboot.

I think that is one of them main questions:

Is it more efficient, to cleanup /var/tmp (i.e. remove everything besides
directories) on boot in a single place (mountall-bootclean), or is it more
efficient to use a tmpfs and let every package create it's run directory on 
boot.
It's probably hard to tell without proper benchmarking.
What can be said though is, that all packages that need a /var/run/ directory
must be fixed. (for the numbers: maybe a new archive scan with the new lintian
would help to see, how many packages are affected) so it at least requires work
by the maintainers.


 5.) If your package does not have an init script (I happen to maintain
 two such packages), I now have to create init scripts simply to create a
 /var/run directory. That's insane and even more wasting cpu cycles.
> 
>>> Could you provide more details about what package without an init script
>>> uses /var/run?  The only other case that I can think of is packages that
>>> create transient UNIX-domain sockets.
> 
>> policykit is such an example. Potentially as D-Bus system bus activated 
>> system
>> services are affected by this, because they (usually) don't ship any init 
>> script.
> 
> $ grep -A4 'start)' /etc/init.d/policykit 
>   start)
> mkdir -p /var/run/PolicyKit
> chown root:polkituser /var/run/PolicyKit
> chmod 770 /var/run/PolicyKit
>   ;;
> $
> 
> That's what I have on an Ubuntu system; why can't the Debian package do the
> same?

Sure it can. But I consider this solution very ugly and refused to do this so
far. For the reasons already mentioned it also makes the (previouly init system
agnostic) D-Bus service dependend on sysv-rc.

> (Yes, this is the only function of this init script.  But still, either you
> create the directories on boot or you have to clean all the files on boot.)
> 
>> We will se such services more and more in the future (like it or not).
> 
> No.  Services that work that way are Doing It Wrong, and we should not
> accept this as inevitable.

Ok, what do you think are they doing wrong: Being started on-demand via D-Bus,
i.e. not shipping a sysv init script?

>> I provided a list of cons of tmpfs (you could probably also add, that it
>> breaks selinux). Is there actually a list of pros?
> 
> "Probably"?  In what case does this break selinux?

I'm not a selinux expert, but I read somewhere, that the security context is
lost, so you'd have to relabel the directory. I don't know, how costly that
operation is (and if this is necessary for a directory in /var/tmp).
Maybe Russell or Manoj can chime in here, if they read this.

Cheers,
Michael


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



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Michael Biebl  writes:

> What can be said though is, that all packages that need a /var/run/
> directory must be fixed. (for the numbers: maybe a new archive scan with
> the new lintian would help to see, how many packages are affected) so it
> at least requires work by the maintainers.

This is in progress now.  Lintian is still sadly slower than we'd like, so
it's only about two-thirds done and probably won't be finished until
Wednesday or so.  (I have some additional ideas to speed it up, but
haven't had a lot of time to work on it.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Russ Allbery]

Raphael Hertzog  writes:

> The point of team upload is precisely so that you can update the package
> and not take responsibility for a package that you don't want to
> maintain in the long run.
>
> I was in many Uploaders field because lintian complain if you are not in
> Uploaders/Maintainer, yet I was there only for a single team upload for
> a perl or a python transition and using an NMU version would have been
> wrong because everything was properly done in the team VCS and there was
> no NMU to integrate for the next person working on the package.
>
> So I object to using NMU version for team uploads but I would like to
> have a mechanism for a team upload that doesn't lead to people adding
> themselves in Uploaders when they don't have a (real/long-term)
> commitment to the package.
>
> Then, the Maintainer/Uploader field would be again more accurate to know
> if we have people that care about the packages or not. So I see this
> change as good move to better detect that nobody cares about the
> package.

Yeah, this is where I'm at with it too.  There still should be some humans
in Maintainer/Uploaders who are taking primary responsibility for the
package, but I think other team members should be able to do QA-style
fixes and transition uploads without using NMU versioning or add
themselves to Uploaders and hence imply that they're taking ongoing
responsibility for the package.

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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Julian Blake Kongslie]

On Mon, 2009-04-06 at 20:42 +0200, Michael Biebl wrote:
> Sure it can. But I consider this solution very ugly and refused to do this so
> far. For the reasons already mentioned it also makes the (previouly init 
> system
> agnostic) D-Bus service dependend on sysv-rc.

Wait, now I'm confused. Why wouldn't this same init script work in
file-rc? Or are you saying something else?

--
-Julian Blake Kongslie 
If this is a mailing list, please CC me on replies.

vim: set ft=text :


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Michael Biebl wrote:
> Gunnar Wolf wrote:

> /etc/init.d/mountall-bootclean.sh will take care of cleaning up /var/tmp.
  
  /var/run, of
course.



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



signature.asc
Description: OpenPGP digital signature

Re: lilo about to be dropped?

[Dmitry E. Oboukhov]

WP> No, the answer is always the second one.

If they add a scheduler (why not? :-\) into the
grub it will be become Linux.

--
... mpd paused: Accept - Can't Stand The Night

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: "Team uploads"

[Jan Hauke Rahm]

On Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery wrote:
> Raphael Hertzog  writes:
> 
> > The point of team upload is precisely so that you can update the package
> > and not take responsibility for a package that you don't want to
> > maintain in the long run.
> >
> > I was in many Uploaders field because lintian complain if you are not in
> > Uploaders/Maintainer, yet I was there only for a single team upload for
> > a perl or a python transition and using an NMU version would have been
> > wrong because everything was properly done in the team VCS and there was
> > no NMU to integrate for the next person working on the package.
> >
> > So I object to using NMU version for team uploads but I would like to
> > have a mechanism for a team upload that doesn't lead to people adding
> > themselves in Uploaders when they don't have a (real/long-term)
> > commitment to the package.
> >
> > Then, the Maintainer/Uploader field would be again more accurate to know
> > if we have people that care about the packages or not. So I see this
> > change as good move to better detect that nobody cares about the
> > package.
> 
> Yeah, this is where I'm at with it too.  There still should be some humans
> in Maintainer/Uploaders who are taking primary responsibility for the
> package, but I think other team members should be able to do QA-style
> fixes and transition uploads without using NMU versioning or add
> themselves to Uploaders and hence imply that they're taking ongoing
> responsibility for the package.

+1, IANADD though.

Hauke


signature.asc
Description: Digital signature

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Michael Biebl]

Steve Langasek wrote:
> On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote:
>> 1. The upstream for this package is Ubuntu. Ubuntu has never been very
>> cooperative at accepting changes, until recently: our contact Steve
>> Langasek has indicated that he is interested in merging most or all of
>> our changes, provided that we send them in in chunks, with proper
>> rationales.
> 
> I have to say here in defense of Ubuntu that I don't see any record of these
> patches being submitted to the Ubuntu package via Launchpad, which, since
> Ubuntu does not have individual package maintainers, is the only reliable
> way to ensure that proposed changes are seen and considered by the people
> working on the package at any given time.
> 
> I don't have time to work on the Debian package myself (either as maintainer
> or for sifting through the delta between Debian and Ubuntu), but I
> definitely am happy to accept fixes "upstream" in reasonable-sized chunks.
> 
> Anyway, as Bart points out, there's another issue:
> 
>> 4. Ubuntu is PHASING OUT this package. They have already moved suspend
>> to pm-utils (but have failed to remove suspend support from
>> acpi-support). They're currently moving hotkey translation to hal. This
>> means that soon we will have no upstream that we can follow! Or we
>> should ensure that Ubuntu's hal changes are included in our version of
>> hal as well -- no clue how those packages are related, or whether
>> Ubuntu's changes are going into upstream hal.
> 
> Since the last time I had a chance to speak with Bart about this, there's
> been quite a bit of progress on phasing out the package for Ubuntu; in
> jaunty, we've dropped a number of quirk scripts related to suspend/resume,
> as well as close to 30 of the ACPI event-handling scripts from /etc/acpi -
> basically:  all those scripts that were being used to synthesize key
> events (which doesn't work with recent kernels anyway) and which we could
> verify were being handled by hal.
> 
> And yes, Martin Pitt works very closely with hal upstream to ensure fixes
> are incorporated.

I can confirm that. Martin is doing an awesome job, submitting patches upstream
or to Debian ftm.

As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
standardizing on one power management stack in Debian (and not install 3 by
default [1]), i.e. I'd support in phasing out acpi-support and would gladly
accept patches for hal and pm-utils which add (if there are) any missing bits
from acpi-support.

Cheers,
Michael

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

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



signature.asc
Description: OpenPGP digital signature

Re: lilo about to be dropped?

[Darren Salt]

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

[snip]
> Have you looked into ext2linux? It is intended to supercede lilo. I think
> your usage requirements will be satisfied by it.

No; I've not heard of it before.

And I can't find it, at least not reasonably easily... :-|

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

I have never let my schooling interfere with my education.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Iustin Pop]

On Mon, Apr 06, 2009 at 11:42:42AM -0500, William Pitcock wrote:
> On Mon, 2009-04-06 at 18:19 +0200, Vincent Zweije wrote:
> > On Mon, Apr 06, 2009 at 06:06:38PM +0200, Mike Hommey wrote:
> > 
> > ||  On Mon, Apr 06, 2009 at 08:02:04PM +0400, Dmitry E. Oboukhov 
> >  wrote:
> > 
> > ||  > I use lilo, I like lilo.
> > ||  > I don't like grub because it has unlogically config, unlogically
> > ||  > behavior, strange reconfig-system. I don't like the programs with
> > ||  > perverse intellect. Grub is not unixway.
> > ||
> > ||  Which is more perverse to read a kernel?
> > ||  - reading actual files from actual filesystems
> > ||  - reading hardcoded blocks on the device
> > 
> > I think this question should be:
> > 
> > Which is more perverse to read without a kernel?
> > 
> > The answer could still fall either way.
> 
> No, the answer is always the second one.

Err, why? I've seen grub failing more often, and heard way more report
of this, than of lilo. Please explain why you say so.

The grub installer also used to read the blockdevice while the
filesystem was mounted, which is never the right answer. It has always
seemed hackish to me, duplicating fs functionality (and not always
correctly, e.g. related to journal replaying on ext3/xfs).

A simple block list is just that.

iustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Stephen Gran]

This one time, at band camp, Paul Wise said:
> Grub2 in lenny and later contains an lvm module:
> 
> /usr/lib/grub/i386-pc/lvm.mod
> 
> Has anyone who uses lilo for this tried grub2?

hadrian:~# mount
/dev/mapper/HADRIAN-ROOT on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/mapper/HADRIAN-HOME on /home type ext3 (rw,relatime)
/dev/mapper/HADRIAN-TMP on /tmp type ext3 (rw,relatime)
/dev/mapper/HADRIAN-USR on /usr type ext3 (rw,relatime)
/dev/mapper/HADRIAN-VAR on /var type ext3 (rw,relatime)
/dev/mapper/HADRIAN-SRV on /srv type ext3 (rw,relatime)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

ii  grub-pc1.96+20080724-16

It works just fine, once you abandon the expectation that the maintainer
scripts will do anything at all on fresh in install.  Kudos to the d-i
team for hiding how little the grub maintainer scripts do.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: lilo about to be dropped?

[Stephen Gran]

This one time, at band camp, William Pitcock said:
> The only way it is feasible to do so is to drop all of the Debian
> patches. Without this, upstream is not cooperative with us.

Why is this?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Packaging ltp selinux tests

[Jiri Palecek]

Hello,

I'd like to package the selinux tests from the ltp test suite. The tests  
need a special selinux policy to be loaded and some files to be relabeled.  
I haven't found any standard way of packaging this, so I made an  
experimental package (see [1]; it sort of works - not completely, like 10 tests 
out of 30, but that's not an issue now) and I would like to hear your opinion 
on these issues:

1. The package loads the policy on "postinst configure" with semodule -i, is 
that right? (And did I implement it properly in the scripts?) There were some 
avc message during package install (semodule was denied access to a terminal 
with type apt_t), can this be solved?

2. The relabeling has to be done manually with fixfiles relabel; is there a way 
to do it  (and should it be done) automatically?

3. The runtime packages depend on selinux-policy-default; should it 
(alternatively) depend on the other policies too? Would this need a separate 
policy package?

4. Should the policy package be in /usr/share?

Thanks in advance.

Regards
Jiri Palecek

[1]: http://mentors.debian.net/debian/pool/main/l/ltp/



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Frans Pop]

Martin Wuertele wrote:
> Actually lilo is installed by lenny d-i if you use root-sw-raid with
> LVM, even if your /boot is an differen partition/sw-raid. Therefore lilo
> should at least remain for sqeeze to ensure a proper upgrade path.

I'm afraid you're mistaken here. Lenny D-I should (and AFAIK does) default 
to grub for that setup.

/boot on normal partition or RAID1 + / on whatever combination of RAID+LVM 
is supported fine by grub. Unless there is some other factor that you've 
not mentioned D-I does not fall back to lilo for that.

Cheers,
FJP


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Team uploads"

[Charles Plessy]

Le Mon, Apr 06, 2009 at 11:51:54AM -0700, Russ Allbery a écrit :
> 
> There still should be some humans
> in Maintainer/Uploaders who are taking primary responsibility for the
> package, but I think other team members should be able to do QA-style
> fixes and transition uploads without using NMU versioning or add
> themselves to Uploaders and hence imply that they're taking ongoing
> responsibility for the package.

Hi all,

so in the end, can we use the “ * QA upload.” special first line for
non-uploader uploads without breaking the QA infrastructure?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lilo about to be dropped?

[Henrique de Moraes Holschuh]

On Mon, 06 Apr 2009, Matthew Johnson wrote:
> On Mon Apr 06 11:07, Goswin von Brederlow wrote:
> > So lets get grub2 working everywhere. :) A worthy goal.
> Sure, but don't remove lilo until we're happy that grub2 does work
> everywhere.

And that we have something resembling acceptable, up-to-date documentation
for it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org