Re: Fwd: Debian 7.5 fails with kernel.org backports

[Steffen Dettmer <steffen.dettmer@gmail.com>]

Hi,

thanks a lot for your quick reply.

On Mon, May 12, 2014 at 3:02 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Mon, 2014-05-12 at 11:45 +0200, Steffen Dettmer wrote:
>> I also tried backports-3.13-rc8-1 [3] without success.
>
> I don't understand why you're picking random old versions.

I picked intentionally (but maybe not wisely :)):

3.10:
  After having issues with ath9k (not working in maybe ~2% of cold
  boots), we started using backported driver from 3.10 (some time
  ago) and extensively tested it (10,000 cold boots, multiple days
  test duration).

3.13:
  /usr/share/doc/linux-source-3.2/changelog.Debian.gz: linux (3.2.57-2)...
    * e1000e,igb: Backport changes up to Linux 3.13 (Closes: #705959)
  so I also tried 3.13, just to see whether at least backports from
  3.13 could be used.

>> It could be that it is related to some e1000e backport (the sources
>> also don't compile anymore, I did not yet tested whether the driver
>> included in 7.5 works without backported driver) as in #705959 [4]?
>>
>> How do I get wireless backports working again with 7.5?
>>
> Yes, it is normal for OOT modules to fail to build after we backport
> stuff. This also happens in all other distributions that backport
> drivers.

OK, thank you for the explanation.

But how could a solution look like?

  Is there a way to "remove"/"unpatch" such backports? This part of
  some "Debian" patch? We also integrate e1000e backport, so I
  think I wouldn't need it. I guess using a vanilla kernel is no
  option, because we would miss security fixes, at least.

  For now we just commented out the five (?) inline functions to
  avoid the linker error. Not sure what this will break next...
  Sorry for my silly questions, but as these topics are very
  complex and as I surely miss many aspects, I'm trying to avoid
  making mistakes.

> But you shouldn't *need* to rebuild them, as we do maintain binary
> compatibility as far as possible.

We are building a flash card image from sources under version
control. Needing kernel headers of an additional version to build
a kernel module doesn't look good; also I'm not sure whether dpkg
(on build system) likes that.

What would be the right way to deal with that? Submit a "bug"
asking to also include the ath9k drivers, such as it was done
with e1000e, like #705959?

Regards,
Steffen