Bug#360561: [cl-debian] Bug#360561: cmucl: CMUCL does not run under kernel version 2.6.16
Is there no resolution? Is nobody taking ownership of this conflict? I'm running Debian as a "testing" installation with the simple packages linux-image-2.6-686-smp cmucl So for cmucl I get version 19c-release-20051115-2. But the linux image for 2.6 recently upgraded in testing to 2.6.16-2-686-smp. And of course cmucl now fails to start with Couldn't mmap at 0xbe000000, len 1048576; got mapping at 0xa7cfe000 insteadensure_space: Failed to validate 1048576 bytes at 0xbe000000 So what's the current status? CMUCL is WONTFIX, and the kernel folks claim the same thing? Nobody cares that the application and the kernel are no longer compatible? At the very least, surely this means that the Debian CMUCL now needs some kind of new "Required:" package, to document that it is not (and will not be) compatible with the default 2.6 kernel. -- Don
Hello Don, Alle Monday 24 July 2006 19:27, Don Geddis ha scritto:
So what's the current status? CMUCL is WONTFIX, and the kernel folks claim the same thing? Nobody cares that the application and the kernel are no longer compatible?
I'm not going to create a separate memory layout for debian just because a non-standard kernel is used. The problem is still present the testing kernel 2.4.17-1-686, I updated to BTS entry of bug #360598 to this effect.
At the very least, surely this means that the Debian CMUCL now needs some kind of new "Required:" package, to document that it is not (and will not be) compatible with the default 2.6 kernel.
I'm open to suggestions on what I should 'require'. ;-) Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
Peter Van Eynde <pvaneynd@debian.org> wrote on Wed, 26 Jul 2006:
I'm not going to create a separate memory layout for debian just because a non-standard kernel is used.
I understand the conflict, that it appears the kernel guys did make an unintentional error. Nevertheless, I find the phrase "non-standard kernel" to be suspect. If a user tries to install the default linux-2.6 kernel in Debian ("testing"), this is the "standard" kernel that they get. This bug doesn't appear to bother most applications. Moreover, the kernel guys (while admitting an error) seem to claim that this kind of change is permitted by their API contract. Finally, Carl Shapiro suggests that CMUCL's current memory layout is an odd accident, and he has a simple patch to reorder the memory (on all platforms?) which happens to solve this problem and also make CMUCL compatible with Debian kernel 2.6.16. Given all of that, it seems like the right solution is to change CMUCL to be immune to these kinds of kernel changes. Although I can appreciate it if you would prefer to wait until a new 19d release of CMUCL from upstream, rather than making a Debian-specific patch to the CMUCL source.
I'm open to suggestions on what I should 'require'. ;-)
Well, hopefull this is only a short-term issue. I don't really know the Debian package syntax, but can't you can something like "requires linux-image-2.4, or linux-image-2.6 with version <= 2.6.15"? -- Don _______________________________________________________________________________ Don Geddis http://don.geddis.org/ don@geddis.org I don't use drugs; my dreams are frightening enough. -- M. C. Escher
Alle Wednesday 26 July 2006 16:41, Don Geddis ha scritto:
I understand the conflict, that it appears the kernel guys did make an unintentional error. Nevertheless, I find the phrase "non-standard kernel" to be suspect. If a user tries to install the default linux-2.6 kernel in Debian ("testing"), this is the "standard" kernel that they get.
I was unclear. I meant 'unmodified kernel from kernel.org with default options'. We had a similar problem a few years back when redhat decided to go for a 2/2 G split in memory. The cmucl maintainers ignored bugreports about this and redhat reversed the patch in the end.
This bug doesn't appear to bother most applications. Moreover, the kernel guys (while admitting an error) seem to claim that this kind of change is permitted by their API contract.
Finally, Carl Shapiro suggests that CMUCL's current memory layout is an odd accident, and he has a simple patch to reorder the memory (on all
Could you point me to that contract so I can check other assumptions made. As someone who got bitten numerous times by glibc's changing semantics I would appreciate such a document and to my knowledge it does not exist. platforms?)
which happens to solve this problem and also make CMUCL compatible with Debian kernel 2.6.16.
I can see what the solution would be but there are technical and cultural problems with it, basicly the debian package would be 'different' from a normal cmucl and this is often enough reason to distrust bug reports from debian users.
I'm open to suggestions on what I should 'require'. ;-)
Well, hopefull this is only a short-term issue. I don't really know the Debian package syntax, but can't you can something like "requires linux-image-2.4, or linux-image-2.6 with version <= 2.6.15"?
This would only require a specific version of the kernel to be installed, there is no general way to say 'this package only runs with kernels < 2.6.15 and > 2.7.17-5 (I hope). Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
On Wed, 2006-07-26 at 17:48 +0200, Peter Van Eynde wrote:
[... schnip ...] I can see what the solution would be but there are technical and cultural problems with it, basicly the debian package would be 'different' from a normal cmucl and this is often enough reason to distrust bug reports from debian users.
This is a _very_ good point!
I'm open to suggestions on what I should 'require'. ;-)
Well, hopefull this is only a short-term issue. I don't really know the Debian package syntax, but can't you can something like "requires linux-image-2.4, or linux-image-2.6 with version <= 2.6.15"?
This would only require a specific version of the kernel to be installed, there is no general way to say 'this package only runs with kernels < 2.6.15 and > 2.7.17-5 (I hope).
Well, isn't this a job for the 'Conflicts' section. Of course this would only protect the user from installing a not-working kernel image but those who compile their own kernels should know what they do. Cheers, Ralf Mattes
Groetjes, Peter
On Wed, 2006-07-26 at 17:48 +0200, Peter Van Eynde wrote:
I can see what the solution would be but there are technical and cultural problems with it, basicly the debian package would be 'different' from a normal cmucl and this is often enough reason to distrust bug reports from debian users.
Ralf Mattes <rm@seid-online.de> wrote on Wed, 26 Jul 2006:
This is a _very_ good point!
In this case, upstream has fixed this bug (for all platforms). In a (near-term) future release [19d?], the memory layout is more logical, and cmucl should no longer have this conflict with the debian kernel. In addition, since the change affects all platforms, there doesn't need to be any fear that the debian package is "different" from a "normal" cmucl. -- Don _______________________________________________________________________________ Don Geddis http://don.geddis.org/ don@geddis.org I made dinner. We didn't have any Hamburger, so it's just Helper. -- "Gabe", Penny Arcade
participants (3)
-
Don Geddis -
Peter Van Eynde -
Ralf Mattes