https://bugzilla.novell.com/show_bug.cgi?id=683228 https://bugzilla.novell.com/show_bug.cgi?id=683228#c0 Summary: network:telephony:asterisk: dahdi-linux build bug for -desktop kernel Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: x86-64 OS/Version: openSUSE 11.3 Status: NEW Severity: Critical Priority: P5 - None Component: 3rd party software AssignedTo: vittorio@vitsoft.bz ReportedBy: novell@eddyg.promessage.com QAContact: opensuse-communityscreening@forge.provo.novell.com Found By: Customer Blocker: --- The '.spec' file supplied with the OpenSUSE dahdi-linux package in the OBS network:telephony:asterisk project does not build valid kernel modules for the '-desktop' kernel variant. In particular, there are several loops like this: for flavor in %flavors_to_build; do ... done where "%flavors_to_build" expands to "default desktop xen" during a build. Looking carefully through the output from "rpmbuild -bb", the 'dahdi-linux' build for "default" works fine (because it is the first flavor), but the next build (for "desktop") utilizes SOME output from the previous build (because 'make' doesn't think anything of note has changed?) thus resulting in a bogus version of the dahdi-linux-kmp RPM for '-desktop'. For example, the output shows 'dahdi-base.c' being compiled when flavor=default, but NOT when flavor=desktop. (The "xen" build appears to recompile more files, including dadhi-base.c, but it may or may not be affected by this bug.) This behavior (most likely) explains the HARD lock-ups that would always occur when the '-desktop' version of the dahdi-linux kernel modules attempted to actually use something like the wctdm24xxp driver. And since the '-default' version is built first, it also explains why that kernel version worked fine with the Digium AEX410P card. This caused a red-herring that initially implied there was a bug in the dahdi-linux codebase and/or a compatibility problem with dahdi-linux modules and the '-desktop' kernel configuration itself. The following context diff for the dahdi-linux.spec file corrects the problem, by ensuring completely independent copies of 'dahdi-linux' are built for each flavor variant. Based on the minimal number of changes needed to accomplish this, I think this was the original intention of the .spec author, and that it was just not implemented properly: *** dahdi-linux.spec Sat Mar 5 09:49:47 2011 --- dahdi-linux.spec.new Mon Mar 28 16:24:44 2011 *************** *** 91,102 **** %build export CFLAGS="%{optflags}" cd .. ! mkdir -p obj for flavor in %flavors_to_build; do ! rm -rf obj/$flavor ! cp -r dahdi-linux-%{version} obj/$flavor done %install --- 91,104 ---- %build export CFLAGS="%{optflags}" + rm -fr obj cd .. ! rm -fr %name-%{version}-obj ! mkdir %name-%{version}-obj for flavor in %flavors_to_build; do ! cp -a %name-%{version} %name-%{version}-obj/$flavor done + mv %name-%{version}-obj %name-%{version}/obj %install *************** *** 104,110 **** --- 106,114 ---- %{__mkdir_p} %{buildroot}%{_mandir}/man8 #make DESTDIR="%{buildroot}" ROOT_PREFIX="%{buildroot}" LIBDIR="%{_libdir}" install for flavor in %flavors_to_build; do + cd obj/$flavor make DESTDIR="%{buildroot}" ROOT_PREFIX="%{buildroot}" LIBDIR="%{_libdir}" KSRC=/usr/src/linux-obj/%_target_cpu/$flavor install + cd ../.. done With the above patch in place, the resulting 'dahdi-linux-kmp-desktop' RPM loads in to the '-desktop' kernel successfully without a hard lock-up of the system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.