Panu Matilainen wrote:
On Fri, 27 Feb 2009, Thibault North wrote:
Le Friday, 27. February 2009 12:02:24 pm Florian Festi, vous avez écrit :
Panu Matilainen wrote:
%global _binaries_in_noarch_packages_terminate_build 0
Yup, that's the way to turn to turn it off from a spec.
Looks like it is not enough (same error). (Have put it right
after %description)
Me thinks you have a typo in there somewhere, I just tried a mock
rebuild of avr-libc and this makes it build just fine (it'll warn about
the binaries but it wont stop the build):
--- avr-libc.spec 24 Feb 2009 03:43:26 -0000 1.3
+++ avr-libc.spec 28 Feb 2009 08:55:23 -0000
@@ -1,3 +1,5 @@
+%global _binaries_in_noarch_packages_terminate_build 0
+
<sigh/> I consider this to be more a temporary ugly cludge, but a
generally feasible approach.
1) You are still invoking find-debuginfo.sh
...
/usr/lib/rpm/find-debuginfo.sh --strict-build-id
/builddir/build/BUILD/avr-libc-1.6.4
...
What is running find-debuginfo.sh on noarch packages supposed to do?
In theory, there may-be cases where some kind of "debuginfo" extraction
on noarch packages may make sense, however I am not aware of
rpm's/Fedora's find-debuginfo.sh doing anything useful on noarch packages.
2) Your approach doesn't cover the case of packages which contain
different kind of binaries, e.g. native, foreign and scripts (noarch) at
the same time.
How would you want to handle this?
So far, the only functional trick I am aware about is to hack
find-debuginfo.sh/brp-strip etc. from inside of rpm-specs such that
these tools do not run their "finds" in places they are not supposed to
look into.
This works fine, as long as packages don't mix up native and foreign
binaries into the same directory. But if they do, things become really
nasty.
Real world example: Older cross-GCCs do so, e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=485416
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list