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. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson
Attachment:
signature.asc
Description: This is a digitally signed message part