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

Re: Outdated linux-2.6 backport

On Wed, 2012-01-18 at 00:40 +0100, Marcus Osdoba wrote:
> Am 19.10.2011 15:05, schrieb Ben Hutchings:
> >
> > Please keep linux-2.6 up-to-date in backports [..]
> >
> Hello debian kernel maintainers,
> I've created a private backport of kernel 3.1.8 from testing for i386/amd64.
> The packages I considered are:
> linux-image-amd64
> linux-image-i386-686-pae
> linux-image-i386-486
> linux-headers-all (and common)
> linux-kbuild-3.1 (linux-tools)

Sorry, I've just done that myself and am preparing to upload.

> cpufrequtils (007-2)
> A separate build-container for each architecture was used to be sure, 
> that there are only stable packages installed. I reverted the compiler 
> back to gcc 4.4. Cpufrequtils is needed for newer kernels to have the 
> cpufreq modules work properly.

I had forgotten that.  Thanks.

> Now that I finished with building up
> linux-image-3.1.0-1-486_3.1.8-2~bpo60+1_i386.deb

This is wrong; modules built for '3.1.0-1-486' in testing/unstable will
not be loadable in a backported kernel due to the compiler version
change.  (I don't believe that gcc 4.4 and 4.6 are at all incompatible,
but the module loader does check this.)

In the past the part after the upstream version was changed from <n> to
bpo.<n> in backports.  However, that makes the backported kernel version
sort later than <n>.  I have used 0.bpo.<n>.

> It's unclear if gcc 4.4 is acceptable for a backport (original from 
> wheezy takes 4.6 - so there may arise problems just because of the 
> different compiler version while kernel version remains identical).

Upstream continues to support a wide range of compiler versions, so this
should generally be fine.


Ben Hutchings
When in doubt, use brute force. - Ken Thompson

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

Reply to: