[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

2.6.11-1 status, ready for an upload this WE ?



Hello,

I have looked at the 2.6.11 kernel status again, and it seems to me that from
the remaining TODO items of the 2.6.10->2.6.11 porting, we had the following
things still on TODO :

  1) the ia64 patch. Those will be dropped and new patches need to be
  provided. that can happen post -1 though, especially as there was no
  activity from the ia64 kernel guys yet.

  2) tg3 firmware pruning, and other stuff relative to the non-free firmware
  issue.

And naturally any other stuff we would see happening, but none are really
important as to block -1 i think.

So i would like that we aim at a 2.6.11-1 upload somewhen this WE, maybe on
sunday, does this sound possible ? Who is ready to upload 2.6.11-1
kernel-images ? I will be able to provide powerpc images together with the
kernel-source upload.

Also, since this is not a sarge candidate kernel, the consensus on irc seems
to be to not continue with the firmware module pruning, but to drop the
modules altogether, and package them in non-free.

I would suggest that we go at this in two ways, with maybe a temporary
non-freeness in main :

  1) we package the plain 2.6.11 as provided by upstream in main and upload
  it. Those non-free firmware blobs are for the most part in main already, and
  it seems the RM (well ex-RM but he was RM back then), said that it was
  acceptable for sarge, so ...

  2) once we have the packages build, we identify the modules with firmware
  non-free issues, we solve the copyright attribution in the source files,
  list all affected modules in a file in the toplevel of the source tree.
  We try to get those copyright attribution changes and toplevel list
  upstream.

  3) then we start building the kernel with these modules in non-free
  (including .udebs), but with the source still in main.

  4) the last step would be to move the source of the affected modules to
  non-free too. This is a huge amount of work, and needs to be revised at each
  new upstream kernel upload. It would be nice if we could stay at 3), but i
  don't think this would be acceptable to debian.

Friendly,

Sven Luther



Reply to: