| Summary: | FTBFS against 3.2.9-1.fc16 for catalyst | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Nicolas Chauvet <kwizart> |
| Component: | catalyst-kmod | Assignee: | Stewart Adam <s.adam> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ben.lewis, jan.public, kendrew71, kwizart, lubek, nikkej, pierre-bugzilla, rpmfusion, sharp, stotty, thomas.frick |
| Priority: | P5 | ||
| Version: | 16 | ||
| Hardware: | i386 | ||
| OS: | GNU/Linux | ||
| namespace: | |||
| Attachments: |
the possible fix for catalyst-kmod-12-2 and kernel >= 3.2.9
the possible fix for catalyst-kmod-12-2 and kernel >= 3.2.9.ix86 build patch |
||
|
Description
Nicolas Chauvet
2012-03-02 13:31:39 CET
*** Bug 2214 has been marked as a duplicate of this bug. *** Created attachment 827 [details]
the possible fix for catalyst-kmod-12-2 and kernel >= 3.2.9
I cannot test it currently without a required hardware.
The catalyst-kmod-12-2 package builds cleanly with this fix for F16.
Apply it similarly like the compat_alloc patch.
Oops! It does not solve the missing FP identifier. Going back to work. :-) Created attachment 828 [details] the possible fix for catalyst-kmod-12-2 and kernel >= 3.2.9.ix86 See http://forums.opensuse.org/forums/english/other-forums/development/programming-scripting/449058-upgrading-ati-driver-atiupgrade-14.html Both patches are required for the successful build. 1/ I'm not interested to ear anyone that cannot do runtime tests. 2/ I would like to avoid using crap found in over the web. As I said ALREADY! please look at kvm/vmx.c that looks to have the right way to fix the situation. OK, I've read the patch again and it seems to use the same kind of fix as kvm/vmx.c. I thought it was different because of + preempt_disable(); but it is disabled in both cases. Now I wonder if this would apply on 12.2 and If it won't be better to wait for 12.3 instead to avoid applying a patch that would possibly brick any hardware. (remembering the nvidia update that was bricking laptop from a given vendor). *** Bug 2230 has been marked as a duplicate of this bug. *** Ok, So now I need someone to volunteer to take over maintainance of catalyst (along with stewart, the current maintainer). With taking the responsability to apply the patch, I would like someone to update to the lastest catalyst to date. (12.02) same as a review process. Please reminds that I have no care for this package personnaly. so don't ask me to blindly apply anything. Again, I'm only seeking for a responsible for the package. (In reply to comment #8) > Ok, So now I need someone to volunteer to take over maintainance of catalyst > (along with stewart, the current maintainer). > With taking the responsability to apply the patch, I would like someone to > update to the lastest catalyst to date. (12.02) same as a review process. > > Please reminds that I have no care for this package personnaly. so don't ask me > to blindly apply anything. Again, I'm only seeking for a responsible for the > package. I got a change to look at this briefly today, but I realized that during my OS reinstallation I accidentally installed from my i686 LiveUSB key instead of x86_64. I don't have the time to reinstall x86_64 and test if it works there (the last few posts in OpenSuSE forum claim problems patching on x86_64) so if someone wants to look into this it would be much appreciated. I think the last build failed on x86_64 also for F-15 http://buildsys.rpmfusion.org/logs/fedora-15-rpmfusion_nonfree/12436-catalyst-kmod-11.11-1.fc15.17/x86_64/build.log *** Bug 2238 has been marked as a duplicate of this bug. *** *** Bug 2241 has been marked as a duplicate of this bug. *** *** Bug 2247 has been marked as a duplicate of this bug. *** As a comment for attachment 827 [details], I think it is not programmatic-ally correct to tie pair #ifdef WARN #undef WARN to Linux kernel version because it doesn't really depend on it. Instead, Macro WARN from bug.h is colliding with kcl_debug.h when CONFIG_DEBUG_VM is defined so #undef WARN should depend on CONFIG_DEBUG_VM. But even then, enumeration elements kcl_debug.h shall not have overlapping names so they should be prefixed properly. See http://forums.fedoraforum.org/showthread.php?t=277547 Created attachment 844 [details] build patch (In reply to comment #14) > As a comment for attachment 827 [details], I think it is not programmatic-ally correct to > tie pair #ifdef WARN #undef WARN to Linux kernel version because it doesn't > really depend on it. Instead, Macro WARN from bug.h is colliding with > kcl_debug.h when CONFIG_DEBUG_VM is defined so #undef WARN should depend on > CONFIG_DEBUG_VM. But even then, enumeration elements kcl_debug.h shall not have > overlapping names so they should be prefixed properly. See > http://forums.fedoraforum.org/showthread.php?t=277547 Your patch addresses the build issue. Processing files: catalyst-kmod-debuginfo-12.2-1.fc16.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/leigh/rpmbuild/BUILDROOT/catalyst-kmod-12.2-1.fc16.x86_64 Wrote: /home/leigh/rpmbuild/RPMS/x86_64/akmod-catalyst-12.2-1.fc16.x86_64.rpm Wrote: /home/leigh/rpmbuild/RPMS/x86_64/kmod-catalyst-12.2-1.fc16.x86_64.rpm Wrote: /home/leigh/rpmbuild/RPMS/x86_64/kmod-catalyst-3.3.0-4.fc16.x86_64-12.2-1.fc16.x86_64.rpm Wrote: /home/leigh/rpmbuild/RPMS/x86_64/catalyst-kmod-debuginfo-12.2-1.fc16.x86_64.rpm |