On Sun, Dec 19, 2010 at 19:30:58 +0100, Julien BLACHE wrote:
> I think it would be best if this matter would be decided upon before the
> release of Squeeze, or not too long after it, so as to avoid further
> breakages in early kernel updates for Squeeze.
>
We're getting close to the squeeze rele
Don Armstrong wrote:
Hi,
> Ok. My main concern here is what exactly would happen if we were to
> ignore the ABI change for this particular issue, and then put in place
> some kind of a process where the kernel team could be informed of
> downstream users of the ABI.
The harm is done now, revert
Ben Hutchings writes:
> DKMS does build real Debian packages. And that means that OOT module
> sources do not need to be packaged differently depending on where the
> modules will be built.
Oh, huh, I hadn't noticed that. Thanks for the pointer! I'll have to
play with that; I'd only previousl
On Tue, 2011-01-04 at 17:55 -0800, Russ Allbery wrote:
> Ben Hutchings writes:
> > On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote:
>
> >> With hundreds of servers, we'd rather not install compilers and DKMS on
> >> every one of them, and with lots of machines, the loss of
> >> reproducibil
Ben Hutchings writes:
> On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote:
>> With hundreds of servers, we'd rather not install compilers and DKMS on
>> every one of them, and with lots of machines, the loss of
>> reproducibility from separately compiling the modules on every system
>> is an
On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote:
> Ben Hutchings writes:
>
> > Do pay attention. We were discussing the implications of changing our
> > current practice of trying to avoid ABI bumps during freeze and stable
> > updates. We would then probably change the uname release (the
Ben Hutchings writes:
> Do pay attention. We were discussing the implications of changing our
> current practice of trying to avoid ABI bumps during freeze and stable
> updates. We would then probably change the uname release (the ABI
> identifier) in each version of the package.
This is certa
On Tue, 04 Jan 2011, Julien BLACHE wrote:
> Don Armstrong wrote:
> > Julien: Are you currently shipping a kernel in production which
> > would be affected by this change if we don't change the ABI
> > number? Or does this only affect cases where you are testing
> > squeeze? Could it be
>
> I have
On Tue, Jan 04, 2011 at 12:28:22PM +0100, Julien BLACHE wrote:
> Don Armstrong wrote:
[...]
> > worked around by using DKMS or similar with prebuilt binaries and
> > requiring exact kernel version dependencies?
>
> DKMS is useless if the ABI number doesn't change, in its current
> form. If DKMS w
Don Armstrong wrote:
Hi,
> Ok. For some reason, I hadn't originally noticed that this was
> concerning an OOT module which Debian itself didn't actually
> distribute. [Julien: I'm correct in that, right?] But that's probably
> fine.
You are correct.
> Julien: Are you currently shipping a kerne
On Mon, 27 Dec 2010, Ben Hutchings wrote:
> On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote:
> > Ok. And am I correct in assuming that if the ABI change would
> > break an OOT module, you would normally change the ABI number?
>
> In the time I've been involved in the kernel team, I haven't
On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote:
> On Sun, 26 Dec 2010, Ben Hutchings wrote:
> > On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote:
> > > or possibly by using Breaks: for all of the affected out-of-tree
> > > modules where the change wasn't wide-spread enough to bump the
On Sun, 26 Dec 2010, Ben Hutchings wrote:
> On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote:
> > or possibly by using Breaks: for all of the affected out-of-tree
> > modules where the change wasn't wide-spread enough to bump the ABI
> > number.
>
> No. Firstly, if we know that an ABI change
On Sun, 2010-12-26 at 12:23 -0800, Don Armstrong wrote:
> On Sun, 26 Dec 2010, Ben Hutchings wrote:
> > On Thu, 2010-12-23 at 12:08 -0800, Don Armstrong wrote:
> > > On Sun, 19 Dec 2010, Julien BLACHE wrote:
> > > > I think it would be best if this matter would be decided upon before
> > > > the re
Don Armstrong writes:
> So currently there is no guarantee that a specific ABI maintains any
> kind of compatibility for out of tree modules; it is a best effort based
> on the kernel maintainer's understanding of what symbols have changed
> and what out of tree (or even in-tree) modules are affe
On Sun, 26 Dec 2010, Ben Hutchings wrote:
> On Thu, 2010-12-23 at 12:08 -0800, Don Armstrong wrote:
> > On Sun, 19 Dec 2010, Julien BLACHE wrote:
> > > I think it would be best if this matter would be decided upon before
> > > the release of Squeeze, or not too long after it, so as to avoid
> > > f
On Sun, 19 Dec 2010, Julien BLACHE wrote:
> I think it would be best if this matter would be decided upon before
> the release of Squeeze, or not too long after it, so as to avoid
> further breakages in early kernel updates for Squeeze.
I have a couple of (possibly naïve) questions that would help
On Sun, Dec 19, 2010 at 08:19:22PM +0100, Stefano Zacchiroli wrote:
> On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
> > I am hereby asking the tech-ctte to decide how the kernel ABI should
> > be managed.
>
> Hi Julien, from the bug log it's pretty clear that there was no
> possib
On Sun, 2010-12-19 at 20:19 +0100, Stefano Zacchiroli wrote:
> On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
> > I am hereby asking the tech-ctte to decide how the kernel ABI should
> > be managed.
>
> Hi Julien, from the bug log it's pretty clear that there was no
> possibilities
On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
> I am hereby asking the tech-ctte to decide how the kernel ABI should
> be managed.
Hi Julien, from the bug log it's pretty clear that there was no
possibilities of agreement between you and the kernel team, so thanks
for bringing thi
Bug No longer marked as found in versions linux-2.6/2.6.32-28.
> retitle 607368 Please decide how kernel ABI should be managed
Bug #607368 [tech-ctte] linux-2.6: silent ABI change in 2.6.32.26 breaks
external modules (smp_ops changes)
Changed Bug title to 'Please decide how kernel ABI should
reopen 607368
tags 607368 - wontfix
reassign 607368 tech-ctte
retitle 607368 Please decide how kernel ABI should be managed
thanks
Hi,
I am hereby asking the tech-ctte to decide how the kernel ABI should be
managed.
Case in point: the kernel team decided to ignore changes to the smp_ops
symbol
22 matches
Mail list logo
