According to the changelog, on 6 Dec, Lanius@gentoo.org added --with-force=yes to the ltmodem-8.26_alpha9-r1 ebuild. This breaks the ltmodem ebuild. It will always fail to build with this option added. It would seem he believes this will fix a chroot problem? There is a known problem with the scripts but adding this option will have no effect except to break the build. If you have a question on the ebuild please feel free to ask me. I've built rpms for the ltmodem project for several years and got the gentoo version functional.
this should fix bug 35066, i forgot to add ${KV}, should be fixed now, please test again
Short answer is no, it doesn't work after adding ${KV}. Long answer is it _might_ work with one particular config but will mysteriously fail in _many_ other configs. I have enough info to give you about a page or two of the how and why this isn't a good idea but let me ask a couple questions first. Why is building in a chroot even on the radar? Is chroot building a new feature of portage I don't know about yet or is this just a one user problem? If this is not a portage feature then how can we possibly know what the user made available in the chroot to make sane decisions? If it is a new feature of portage then where can I find what is available in the chroot?
Or is the chroot in question during an install using a live_cd or similiar? That seems the most likely...
Portage does support chroot builds: `ROOT=/mnt/chroot emerge ltmodem`
I'm trying to determine which type of chroot we are concered with here. I see at least three different examples of a chroot. 1. chroot to a gentoo stage image that is being installed. A full system is available to the chroot, just a different system than the one that was booted. If kernel sources are available LTModem will build. 2. chroot to a new, bare directory. Access is denied to the rest of the file system for security reasons. LTModem is a kernel module. It requires full and configured kernel sources to build. If this is not available to the chroot it _should_ fail. 3. A ported sandbox type of chroot. One that portage normally uses to fake a root directory for the install so portage can keep track of the files created. This type does not limit access to the rest of the filesystem. Which type of chroot are you referring to when you say "Portage does support chroot builds: `ROOT=/mnt/chroot emerge ltmodem` " This type seems to me to be type 3, just changeing the sandbox portage uses to fake the install from /var/temp/portage/ltmodem/ to /mnt/chroot/ltmodem/ and would have no effect on the ltmodem ebuild???
I started this with http://bugs.gentoo.org/show_bug.cgi?id=35066 suggesting that ${KV} --with-force=yes was needed for build_module. This is because I build and maintain all my boxen in separate chroots on a master box. To put it another way, I build for "laptop" on "desktop". This is Tom's type 1. The reason I added the force was that without it, build_module would work out what kernel "desktop" is running and then fail because, inside the chroot, "laptop" was being built with a different kernel. While this is perfectly sensible in the usual case of building on the target box, it must break my cross(ish) compiling unless I could keep all kernels up to the same version. Thinking further, surely this would also apply when upgrading a kernel and building on the target as well? Reading through the script, it looks like this is _exactly_ what forcing is for. As I said in my original bug report, I haven't tested it building on the target host but it looks like it should work. Hope this helps to clarify.
Yes, thanks george, it does help. I think the answer is to revert the change in the stable version and create a new ~x86 version of the ebuild. Till I can explain the many problems, shouldn't we keep the stable version _stable_ and test in ~x86???? This change broke the perfect record of no ltmodem bug reports since I helped get the ebuild working last january, almost a year ago... The latest bug reports on the boards... I'm sure more will follow.... http://forums.gentoo.org/viewtopic.php?t=111550&highlight=ltmodem http://forums.gentoo.org/viewtopic.php?t=111533&highlight=ltmodem I have more info but won't be able to get it out till tomorrow....Work keeps getting in the way...
A ~x86 version is fine by me - I'm more than happy to leave stability decisions to others ;) As I'm using ~x86 for this target anyway, it'll be no problem for me to test new versions. If they don't work for me I can always revert to my version in my portage overlay. As it sounds like I'm an unusual case here, if a new version wants testing, just say so in this bug report so I notice and can try it out. If I understand what I've read about catalyst, what I'm doing will become much more common, so it'll be good to sort this before then. btw I've found and reported a few problem ebuilds in my chroot :(
sorry for not looking close enough at it, i moved it to -r2 as you suggested and marked it ~x86
what's the status of this, i have to remove --with-force=yes again from -r3 which supports kernel 2.6 so we have a working kernel 2.6 version
The LTModem maintainers created the -force option for the exceptional cases - not the norm. It was added to the ebuild to "cross-compile" the kernal module under a different kernal version. Using -force will break in many subtle conditions, 2.6 seems to bring out some of them. This may change when the support is more mature, but for now, I don't think -force should be used in any ebuild.
i'll mark it later then
