Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=526916 --- Comment #23 from Fabian Deutsch <fabian.deutsch@xxxxxx> 2010-03-31 02:08:25 EDT --- (In reply to comment #21) > rpmbuild on AMD 64bit has succeeded. Good! > > NEEDWORK: > - Headers are still installed without preventing time-stamp changes. > There is currently no macro to set this by default, this have to be set > manually and will prevent multilibs conflicts when installing -devel from two > different arches. Done. Do you recommend this always, using -p ? If so this should be discussed somewhere (ml, bz). > - Installed binary in devel: %{_bindir}/orcc > This binary look like a pre-compiler tool. Is it possible (does it make sense) > for it, to produce 32bit code using x86_64 version ? In the current situation > orc-devel.i686 and orc-devel.x86_64 must be able to be installed together and > the 64bit version of the binary will be taken over the 32bit version. David already cleared that one build is generating code for all arches supported at buildtime. So how can I handle this in the spec? > > SHOULD: > - doc subpackage can be set as noarch as it's rather big (450ko) How can I establish this? %ifdef noarch? > - rpmlint on installed packages isn't clean: > # rpmlint orc > orc.x86_64: W: unused-direct-shlib-dependency /usr/lib64/liborc-0.4.so.0.0.0 > /lib64/librt.so.1 > orc.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/liborc-float-0.4.so.0.0.0 /lib64/librt.so.1 I'm not that into autotools, but it seems as if this is hardcoded for alle orc libs: configure.ac:117. > - It should be possible to avoid usage of generated header in the API: > orc/orc-stdint.h:#define _STDINT_HAVE_STDINT_H 1 Sorry, I've got no clue what to do :) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review