So, since something drew my attention to this bug again
We made a decision by default to not override the kernel team for squeeze
already. Reviewing the thread, it seems to me like the kernel team both
has good reasons for their decisions and has a reasonable grasp of the
issues, and is
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
Don Armstrong d...@debian.org 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
Don Armstrong d...@debian.org 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
On Tue, Jan 04, 2011 at 12:28:22PM +0100, Julien BLACHE wrote:
Don Armstrong d...@debian.org 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.
On Tue, 04 Jan 2011, Julien BLACHE wrote:
Don Armstrong d...@debian.org 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
Ben Hutchings b...@decadent.org.uk 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
On Tue, 2011-01-04 at 17:23 -0800, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk 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
Ben Hutchings b...@decadent.org.uk 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
On Tue, 2011-01-04 at 17:55 -0800, Russ Allbery wrote:
Ben Hutchings b...@decadent.org.uk 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
Ben Hutchings b...@decadent.org.uk 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;
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 yet
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
further breakages in early kernel updates for Squeeze.
I
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
further
Don Armstrong d...@debian.org 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)
Don Armstrong d...@debian.org wrote:
Hi,
For out of tree modules, these problems can either be resolved by
changing the ABI number, 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. A slightly wilder
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 release of
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 would
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 ABI
Don Armstrong d...@debian.org wrote:
Hi Don,
You should bounce your mail to the kernel team as they were not Cc:ed
and the questions are directed to them.
My main concern is that there seems to be no way for oot modules like
the vmware modules to sanely keep in step with the kernel ABI. While
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
Julien BLACHE jbla...@debian.org wrote:
Hi,
Furthermore it is indeed quite unclear if said company is not effectively
violating GPL and several core dev do indeed think so.
Uh? [citation needed] please, especially given VMware modules ship as
source although I can't remember their licensing
maximilian attems m...@stro.at wrote:
Hi,
The submitter shows a clear confusion between the requirements of a shared
lib userspace and the linux-2.6 kernel.
Be assured there is no confusion on my end on this topic.
Furthermore it is indeed quite unclear if said company is not effectively
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
On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
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
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 this
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 of
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
possibilities
28 matches
Mail list logo
