Re: Release update: deep freeze, planned dates, and remaining bugs

[Steve McIntyre]

On Sat, Feb 07, 2009 at 11:48:44PM +0100, Daniel Baumann wrote:
>
>however, for cosmetic reasons, it would be nicer to build them against
>final lenny. otherwise the release files on lenny final images would
>claim it's testing (without any other technical consequence) which feels
> akward.

Sure, sounds better.

>> Anyway, if you need/want to build the images after the actual release
>> that will mean earliest Saturday afternoon and more probably Saturday
>> evening/Sunday.
>
>that would be nice.

Cool. I'll be doing builds during Saturday; let's co-ordinate as we go
so that we can release as quickly as possible.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews


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

Bug#514516: ITP: xfswitch-plugin -- user switching plugin for the Xfce4 panel

[Evgeni Golov]

Package: wnpp
Severity: wishlist
Owner: Evgeni Golov 

* Package name: xfswitch-plugin
  Version : 0.0.1
  Upstream Author : Jérôme Guelfucci 
* URL : 
http://goodies.xfce.org/projects/panel-plugins/xfswitch-plugin
* License : GPL-2+
  Programming Lang: C
  Description : user switching plugin for the Xfce4 panel

 Xfswitch-plugin is a user switching plugin for the Xfce4 Panel.
 It allows you to leave the current session opened and open a new session
 with another user.
 .
 At the moment it relies on GDM, but other display managers will be
 supported in the future. 

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



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

Should 32-bit apps work with a 64-bit kernel?

[Jörg Sommer]

Hi,

I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fixed
by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option
for all 32‐bit builds or does it have any drawbacks?

Bye, Jörg.
-- 
Wer einen Traum verwirklichen will, muss erst aufwachen.


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

Re: Should 32-bit apps work with a 64-bit kernel?

[Lionel Elie Mamane]

On Sun, Feb 08, 2009 at 10:46:42AM +, Jörg Sommer wrote:

> I have the bug report #489917 that complains that Jed can't handle
> 64‐bit kernel structures. (...) The error can be fixed by compiling
> Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all
> 32‐bit builds or does it have any drawbacks?

I'd think you should enable it for all 32 bit builds; it is, I think,
a step in having support for large files (files bigger than 2 or 4
gigabytes), something we wanted to have for... woody.

-- 
Lionel


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

Re: Should 32-bit apps work with a 64-bit kernel?

[sean finney]

hi,

On Sun, Feb 08, 2009 at 12:58:43PM +0100, Lionel Elie Mamane wrote:
> I'd think you should enable it for all 32 bit builds; it is, I think,
> a step in having support for large files (files bigger than 2 or 4
> gigabytes), something we wanted to have for... woody.

more specifically, what i think you really want is the output of
calling "getconf LFS_CFLAGS".  i.e. on my old 32-bit laptop it outputs:

-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

but keep in mind that this (either option i believe) breaks binary
compatibility, so if you're packaging a shared library or similar you may
have to tread a bit more carefully.


BR
sean




signature.asc
Description: Digital signature

Re: Bug#514485: ITP: globus-usage -- Globus Toolkit - Usage Library

[Chris Walker]

Steffen Moeller  writes:

> * Package name: globus-usage
> * URL : http://www.globus.org/
> * License : Apache 2
>   Programming Lang: C/C++
>   Description : Globus Toolkit - Usage Library
> 
Debian-science has been collecting packages useful for science into
task packages - for more information look at
wiki.debian.org/DebianScience

There isn't currently a grid task - but it might be an obvious thing
to add (or perhaps grid-client and grid-server tasks). If there are
other obvious candidate packages for such a task, perhaps you could
post them on debian-science too.

Chris


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

Re: Desktop standards, MIME info cache, and Lintian

[Michael Biebl]

Russ Allbery wrote:
> Loïc Minier  writes:
> 
>>  I can see how it would be useful to recommend calling dh_desktop as
>>  soon as you distribute .desktop files just like it would be more useful
>>  if we could inject any rules in packages via cdbs or the new "dh".
>>  However, this is really packaging style and using an extensible
>>  packaging style shouldn't be imposed by a checker tool like lintian;
>>  I'm not aware of any different dh_desktop usage which would justify
>>  raising a warning right now.
>>
>>  Also, would we have to do more things on .desktop files, we would have
>>  more options to implement them without requiring dh_desktop (triggers
>>  come to mind).
>>
>>  So not raising a lintian warning when dh_desktop isn't called on
>>  .desktop file would be more to my taste.
> 
> Okay, that matches my reasoning.  I'll remove that tag in the next version
> of Lintian.  Thank you very much!


Maybe i missinterpreted your conclusion, but this what I get in one of my 
packages:
 desktop-mimetype-without-update-call /usr/share/applications/...

Now that we have triggers, I really don't see the benefit of adding such a
lintian warning. Imho we should get rid of dh_icon and dh_desktop completely and
also any manual update-desktop-database calls, not recommend to add such a call
(to potentially a *lot* of packages).

Why should we update dozens if not hundreds of packages, if we can have the same
effect much more elegantly and efficiently with file triggers.

FWIW, I'd recommend to update desktop-file-utils (update-desktop-database),
shared-mime-info (update-mime-database) and libgtk2.0-bin (update-icon-caches),
to provide proper triggers support and as soon as that has happened even reverse
the lintian check, i.e. if it finds any dh_icons / dh_desktop /
update-desktop-database call, issue a warning with the recommendation to remove 
it.

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: Release update: deep freeze, planned dates, and remaining bugs

[Daniel Baumann]

Steve McIntyre wrote:
> Cool. I'll be doing builds during Saturday; let's co-ordinate as we go
> so that we can release as quickly as possible.

i'll be online the whole weekend, so best would be if someone would ping
me on irc when i can start the builds. once they are finished, i'll let
steve know where to sync them like i did the last times.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  daniel.baum...@panthera-systems.net
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: Desktop standards, MIME info cache, and Lintian

[Emilio Pozuelo Monfort]

Michael Biebl wrote:
> Maybe i missinterpreted your conclusion, but this what I get in one of my 
> packages:
>  desktop-mimetype-without-update-call /usr/share/applications/...
> 
> Now that we have triggers, I really don't see the benefit of adding such a
> lintian warning. Imho we should get rid of dh_icon and dh_desktop completely 
> and
> also any manual update-desktop-database calls, not recommend to add such a 
> call
> (to potentially a *lot* of packages).
> 
> Why should we update dozens if not hundreds of packages, if we can have the 
> same
> effect much more elegantly and efficiently with file triggers.

How would you know the trigger needs to be run then? If you remove the call from
all the packages, you will then have to call the trigger everytime dpkg is run,
no matter if you only install one package that doesn't need those triggers.

So AFAIUI, your package needs to call those, and then dpkg will not call those
for every package, but do one call at the end if it supports triggers.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Desktop standards, MIME info cache, and Lintian

[James Vega]

On Sun, Feb 08, 2009 at 09:21:10PM +0100, Emilio Pozuelo Monfort wrote:
> Michael Biebl wrote:
> > Maybe i missinterpreted your conclusion, but this what I get in one of my 
> > packages:
> >  desktop-mimetype-without-update-call /usr/share/applications/...
> > 
> > Now that we have triggers, I really don't see the benefit of adding such a
> > lintian warning. Imho we should get rid of dh_icon and dh_desktop 
> > completely and
> > also any manual update-desktop-database calls, not recommend to add such a 
> > call
> > (to potentially a *lot* of packages).
> > 
> > Why should we update dozens if not hundreds of packages, if we can have the 
> > same
> > effect much more elegantly and efficiently with file triggers.
> 
> How would you know the trigger needs to be run then? If you remove the call 
> from
> all the packages, you will then have to call the trigger everytime dpkg is 
> run,
> no matter if you only install one package that doesn't need those triggers.

The whole point of triggers is that they watch a set of
files/directories and when changes happen to those files/directories a
command gets run.  They're supposed to make it so that only one package (the
one providing the command that needs to be run) has to know that the command
needs to be run.  This is far less error-prone than relying on every developer
to remember which commands to run in which maintainer scripts.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: Desktop standards, MIME info cache, and Lintian

[Michael Biebl]

Emilio Pozuelo Monfort wrote:
> Michael Biebl wrote:
>> Maybe i missinterpreted your conclusion, but this what I get in one of my 
>> packages:
>>  desktop-mimetype-without-update-call /usr/share/applications/...
>>
>> Now that we have triggers, I really don't see the benefit of adding such a
>> lintian warning. Imho we should get rid of dh_icon and dh_desktop completely 
>> and
>> also any manual update-desktop-database calls, not recommend to add such a 
>> call
>> (to potentially a *lot* of packages).
>>
>> Why should we update dozens if not hundreds of packages, if we can have the 
>> same
>> effect much more elegantly and efficiently with file triggers.
> 
> How would you know the trigger needs to be run then? If you remove the call 
> from
> all the packages, you will then have to call the trigger everytime dpkg is 
> run,
> no matter if you only install one package that doesn't need those triggers.
> 
> So AFAIUI, your package needs to call those, and then dpkg will not call those
> for every package, but do one call at the end if it supports triggers.
> 

See /usr/share/doc/dpkg-dev/triggers.txt.gz, w.r.t file triggers.
The trigger will one be run if it matches a file (e.g. /usr/share/icons or
/usr/share/applications).

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: Should 32-bit apps work with a 64-bit kernel?

[Ron Johnson]

On 02/08/2009 04:46 AM, Jörg Sommer wrote:

Hi,

I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fixed
by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option
for all 32‐bit builds or does it have any drawbacks?


All of the 32-bit apps that I've had need to install run just fine 
with a 64-bit kernel.


$ uname -m
x86_64

$ dpkg-architecture
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i486-linux-gnu

--
Ron Johnson, Jr.
Jefferson LA  USA

Supporting World Peace Through Nuclear Pacification


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

Data packages.

[Charles Plessy]

Le Sun, Feb 08, 2009 at 10:03:09PM +0100, Joey Schulze a écrit :
> 
> The data archive will contain huge packages that cannot be distributed
> through the regular archive due to their sheer size.  The number of free
> large data packages, such as medical and statistical data sets, and also
> game data, is increasing and we ask for a new service to make them
> available to Debian users.

Dear Joey,

that sounds very, very interesting! Is there a place where we can know better
about this data archive? In Debian Med, we are already working on a system to
get data and, and I am exploring the possibility to to use it to produce binary
packages but no source packages. Would it be compatible with your plans?

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: Data packages.

[Peter Palfrader]

On Mon, 09 Feb 2009, Charles Plessy wrote:

> Le Sun, Feb 08, 2009 at 10:03:09PM +0100, Joey Schulze a écrit :
> > 
> > The data archive will contain huge packages that cannot be distributed
> > through the regular archive due to their sheer size.  The number of free
> > large data packages, such as medical and statistical data sets, and also
> > game data, is increasing and we ask for a new service to make them
> > available to Debian users.
> 
> Dear Joey,
> 
> that sounds very, very interesting! Is there a place where we can know better
> about this data archive? In Debian Med, we are already working on a system to
> get data and, and I am exploring the possibility to to use it to produce 
> binary
> packages but no source packages. Would it be compatible with your plans?

The data.debian.org thing is actually Joerg's proposal, he first raised
it at http://lists.debian.org/debian-devel/2008/05/msg00970.html last
year.

Cheers,
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


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

Re: Data packages.

[Charles Plessy]

Le Mon, Feb 09, 2009 at 12:57:12AM +0100, Peter Palfrader a écrit :
> 
> The data.debian.org thing is actually Joerg's proposal, he first raised
> it at http://lists.debian.org/debian-devel/2008/05/msg00970.html last
> year.

Hi Peter,

thanks for the pointer.

I think that I will keep on exploring the possibility of distributing data in
Debian binary format with no Debian source package for the moment.  Jorg's
proposal just doubles the bandwith requirements for the uploads, and many
databases are updated monthly… I plan to use our getData tool to update some
mirrors locally, and build Debian packages from this. By the way, I am
wondering about the possiblity to use hard links during this process to avoid
unnecessary duplication of large files. Any hint ?

My current plan is :

 - Prepare a Debian Med image for the Amazon Elastic Computing Cloud, that
   would only contain programs packaged in Debian, with the exception of
   packages from backports.org, which I think are trustable enough even if they
   are not official.

 - From within the Amazon system, build binary packages of bioinformatical
   data, and distribute them on the Amazon Simple Storage system, if it is
   possible to open to the inside (free transfer), but not to the outside (costs
   me money).

 - See if people use the data packages in conjuction with the
   unofficial-but-gpg-signed Debian Med image that I indend to prepare.

 - Ask for sponsorship if it starts to cost too much :)


Of course, help from people interested is most welcome! There are a few started
threads on the debian-med mailing list, for which I have not found time to
answer properly because my lack of progress: in parallel to this project there
is a major update of BioPerl, that pulls many things by spaghetti effect. But
be sure that I welcome all feedback!

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: Should 32-bit apps work with a 64-bit kernel?

[Ben Hutchings]

On Sun, 2009-02-08 at 10:46 +, Jörg Sommer wrote:
> Hi,
> 
> I have the bug report #489917 that complains that Jed can't handle
> 64‐bit kernel structures. In this special case, the stat() return with
> EOVERFLOW Value too large to be stored in data type. Jed was compiled for
> a 32‐bit kernel and is run with a 64‐bit kernel.

You can get this error under 32-bit kernels too, because thankfully they
can handle >2 GB files.

> The error can be fixed
> by compiling Jed with -D_FILE_OFFSET_BITS=64. Should I set this option
> for all 32‐bit builds or does it have any drawbacks?

If jed can deal with files that large, sure.  But if it expects to be
able to load the entire file into memory - as most text editors do -
stat() will be only the first of its problems.

Ben.



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

Re: Data packages.

[Lukasz Szybalski]

On Sun, Feb 8, 2009 at 7:13 PM, Charles Plessy  wrote:
> Le Mon, Feb 09, 2009 at 12:57:12AM +0100, Peter Palfrader a écrit :
>>
>> The data.debian.org thing is actually Joerg's proposal, he first raised
>> it at http://lists.debian.org/debian-devel/2008/05/msg00970.html last
>> year.
>
> Hi Peter,
>
> thanks for the pointer.
>
> I think that I will keep on exploring the possibility of distributing data in
> Debian binary format with no Debian source package for the moment.  Jorg's
> proposal just doubles the bandwith requirements for the uploads, and many
> databases are updated monthly… I plan to use our getData tool to update some
> mirrors locally, and build Debian packages from this. By the way, I am
> wondering about the possiblity to use hard links during this process to avoid
> unnecessary duplication of large files. Any hint ?
>
> My current plan is :
>
>  - Prepare a Debian Med image for the Amazon Elastic Computing Cloud, that
>   would only contain programs packaged in Debian, with the exception of
>   packages from backports.org, which I think are trustable enough even if they
>   are not official.
>
>  - From within the Amazon system, build binary packages of bioinformatical
>   data, and distribute them on the Amazon Simple Storage system, if it is
>   possible to open to the inside (free transfer), but not to the outside 
> (costs
>   me money).
>
>  - See if people use the data packages in conjuction with the
>   unofficial-but-gpg-signed Debian Med image that I indend to prepare.
>
>  - Ask for sponsorship if it starts to cost too much :)
>
>
> Of course, help from people interested is most welcome! There are a few 
> started
> threads on the debian-med mailing list, for which I have not found time to
> answer properly because my lack of progress: in parallel to this project there
> is a major update of BioPerl, that pulls many things by spaghetti effect. But
> be sure that I welcome all feedback!
>


Is there a capability of creating a mirror that would use torrent technology?

If you have these .deb packages that are big (could you list few, with
their sizes), I was under the assumption that having torrent mirror
was possible but rejected because most packages are small <1m. If
torrent mirror is possible then one could create big.debian.org which
would be a mirror of big packages that are distributed via torrent
only.

Let me know what options we have there.
Thanks,
Lucas


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

Re: Desktop standards, MIME info cache, and Lintian

[Russ Allbery]

Michael Biebl  writes:
> Russ Allbery wrote:

>> Okay, that matches my reasoning.  I'll remove that tag in the next
>> version of Lintian.  Thank you very much!

> Maybe i missinterpreted your conclusion, but this what I get in one of
> my packages:

>  desktop-mimetype-without-update-call /usr/share/applications/...

> Now that we have triggers, I really don't see the benefit of adding such
> a lintian warning. Imho we should get rid of dh_icon and dh_desktop
> completely and also any manual update-desktop-database calls, not
> recommend to add such a call (to potentially a *lot* of packages).

I removed the requirement to call dh_desktop every time you have a
*.desktop file.  I didn't remove the tag entirely since at the time we had
no triggers and you still did need to call update-desktop-database if the
*.desktop file has a MimeType key.

If there's a trigger now that handles this, I'll remove that as well.  Was
one added?

-- 
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: Data packages. (with BitTorrent)

[Charles Plessy]

Le Sun, Feb 08, 2009 at 07:22:10PM -0600, Lukasz Szybalski a écrit :
> 
> Is there a capability of creating a mirror that would use torrent technology?
> 
> If you have these .deb packages that are big (could you list few, with
> their sizes), I was under the assumption that having torrent mirror
> was possible but rejected because most packages are small <1m. If
> torrent mirror is possible then one could create big.debian.org which
> would be a mirror of big packages that are distributed via torrent
> only.

Hi Lukasz,

A genome indexed for the BLAST search system takes between 500 and 1000 Mo.
Other databases can be bigger (GenBank – very comprehensive – is almost 100 Go,
I think), or smaller (for instance databases of protein-DNA interactions like
JASPAR or REBASE).

For the general-purpose databases that are updated on a regular basis, torrent
distribution would indeed make sense as we would expect sharp peaks of
parrallel downloads followed by calm periods. For other big datasets – for
instance the human genome – there is less than one update per year, so we would
lose the benefit of a peer-to-peer distribution strategy.

But definitely, torrent is something to keep in mind, especially if
infrastructure makes it transparent. Can debtorrent work with the torrenting
facilities of the Amazon Simple Storage system ?

Lastly, BitTorrent is strictly forbidden in some workplaces (like where I
work), so it will have to be optional.

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: Should 32-bit apps work with a 64-bit kernel?

[Martin Langhoff]

On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings  wrote:
> If jed can deal with files that large, sure.  But if it expects to be
> able to load the entire file into memory - as most text editors do -
> stat() will be only the first of its problems.

Old vi was able to work with files larger than available RAM. I wonder
if any modern text editor today can still handle that.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


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

Forthcoming changes in kernel-package

[Manoj Srivastava]

Hi,

This is a heads up for a major change in kernel-package, the
 tool to create user packaged kernel images and headers; which will
 make the make-kpkg script far less error prone, and far more
 deterministic.

   a. Every invocation of kernel-package will remove ./debian directory,
  and regenerate the changelog and control files. This will get rid
  of any remaining issues with the ./debian directory getting out of
  sync with the kernel sources; and will allow people to make small
  tweaks to the kernel sources and have  make-kpkg reflect those
  changes.
   b. make-kpkg will no longer have special case code to  run boot
  loaders and init ram fs creator invocations. Instead, it will pay
  attention to scripts dropped into  the directories
  /etc/kernel/{src_,header_,}{pre,post}{inst,rm}.d/
  This is far more flexible, and allows all  kinds of packages to
  drop in scripts there
   c. his means there will be no need for /etc/kernel-img.conf file any
  more.
   d. The make-kpkg infrastructure will try to leverage the KBUILD
  system far more than it has done in the past, which will make it
  more robust against  upstream kernel changes.

Since make-kpkg has been deprecated by the kernel team, and thei
 advice has been to not use kernel package for kernel image building,
 this should have no impact on official kernels.

manoj
-- 
Apples have meant trouble since eden. MaDsen Wikholm,
mwikh...@at8.abo.fi
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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