Spec URL: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/1/liborc.spec SRPM URL: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/1/liborc-0.4.2-1.fc12.src.rpm Description: Orc is a library and set of tools for compiling and executing very simple programs that operate on arrays of data. The "language" is a generic assembly language that represents many of the features available in SIMD architectures, including saturated addition and subtraction, and many arithmetic operations. liborc is needed in future versions of libschroedinger
Koji Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=1724156
Some quick comments: - the package name should be "orc" without the leading "lib" - add Requires: pkgconfig to the devel package - remove the rpaths from libtool (see http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath) - in %files tools, swap the %doc and %defattr lines $ rpmlint /var/lib/mock/fedora-11-x86_64/result/liborc-* liborc.src:75: E: files-attr-not-set liborc.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/liborc-pixel-0.4.so.0.0.0 ['/usr/lib64'] liborc.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/liborc-test-0.4.so.0.0.0 ['/usr/lib64'] liborc.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/liborc-float-0.4.so.0.0.0 ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/generate_opcodes_sys ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/example1 ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/exec_opcodes_float ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/compile_opcodes_sys_c ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/generate_xml_table2 ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/compile_opcodes_float ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/test-schro ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/generate_xml_table ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/test_accsadubl ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/exec_opcodes_pixel ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/orcc ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/compile_opcodes_float_c ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/compile_opcodes_pixel_c ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/mt19937ar ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/compile_opcodes_sys ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/compile_opcodes_pixel ['/usr/lib64'] liborc-tools.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/orc/exec_opcodes_sys ['/usr/lib64'] 5 packages and 0 specfiles checked; 21 errors, 0 warnings.
Update resolving the issues named before. Spec URL: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/2/orc.spec SRPM URL: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/2/orc-0.4.2-2.fc12.src.rpm koji task: https://koji.fedoraproject.org/koji/taskinfo?taskID=1752912 There ois one rpmlint warning: orc.x86_64: W: conffile-without-noreplace-flag /etc/ld.so.conf.d/orc-x86_64.conf but this should be okay, as the named file usually shall not be edited by hand .. and does not contain any configuration options.
Fabian, I just had another look into your package and found a couple of issues that should also be addressed: - you can drop pkgconfig and autoconf from BuildRequires - remove %makeinstall - replace pkg-config by pkgconfig - replace "rm -Rf" by "rm -rf" - I suggest to replace %{_includedir}/* by %{_includedir}/%{name}-0.4/ to make clear that the header files go to a subfolder - add the doc files COPYING README to the base package and drop them from tools (even if rpmlint will print a warning about missing docs) - I suggest to add the compiler orcc to the devel package in order to remove the tools subpackage, since orcc is also a development tool, and it's a bit of overhead to create a separate package for just one small additional file. - the documentation is quite extensive so it's probably a good idea to put it into a doc subpackage - Could you explain the need for the .conf file? As far as I can see, it's not necessary
(In reply to comment #4) > - you can drop pkgconfig and autoconf from BuildRequires > - remove %makeinstall > - replace pkg-config by pkgconfig > - replace "rm -Rf" by "rm -rf" > - I suggest to replace %{_includedir}/* by %{_includedir}/%{name}-0.4/ to make > clear that the header files go to a subfolder > - add the doc files COPYING README to the base package and drop them from tools > (even if rpmlint will print a warning about missing docs) all done. > - I suggest to add the compiler orcc to the devel package in order to remove > the tools subpackage, since orcc is also a development tool, and it's a bit of > overhead to create a separate package for just one small additional file. done. I can not remeber why I put just the compiler into a different package. > - the documentation is quite extensive so it's probably a good idea to put it > into a doc subpackage done. Good idea. > - Could you explain the need for the .conf file? As far as I can see, it's not > necessary There are files located in ${_libdir}/orc/, so don't we need this conf file, to tell ldconfig to look in this folder too?
updates. Spec an srpm: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/3/ Kjoi: http://koji.fedoraproject.org/koji/taskinfo?taskID=1753060
(In reply to comment #5) > There are files located in ${_libdir}/orc/ Are they? According to the spec file, all libraries are directly placed into %{_libdir}. Here are the files added to this folder: $ rpmls orc-*.rpm | fgrep /usr/lib | grep -v debug lrwxrwxrwx /usr/lib64/liborc-0.4.so.0 -rwxr-xr-x /usr/lib64/liborc-0.4.so.0.0.0 lrwxrwxrwx /usr/lib64/liborc-float-0.4.so.0 -rwxr-xr-x /usr/lib64/liborc-float-0.4.so.0.0.0 lrwxrwxrwx /usr/lib64/liborc-pixel-0.4.so.0 -rwxr-xr-x /usr/lib64/liborc-pixel-0.4.so.0.0.0 lrwxrwxrwx /usr/lib64/liborc-test-0.4.so.0 -rwxr-xr-x /usr/lib64/liborc-test-0.4.so.0.0.0 lrwxrwxrwx /usr/lib64/liborc-0.4.so lrwxrwxrwx /usr/lib64/liborc-float-0.4.so lrwxrwxrwx /usr/lib64/liborc-pixel-0.4.so lrwxrwxrwx /usr/lib64/liborc-test-0.4.so -rw-r--r-- /usr/lib64/pkgconfig/orc-0.4.pc
Argh. The reason for including this file, was the rpath issue. Later I found out, that the files, which were located in libdir/orc, were just unit-tests or so and never used ... so next time i'd be better if i use my brain from the beginnig on :) (I even added a line to remove libdir/orc ...) Spec an srpm: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/4/ Kjoi: http://koji.fedoraproject.org/koji/taskinfo?taskID=1753125
It seems the package doesn't work on 64-bit architectures. At least, the test suite executed by "make check" fails on my x86_64 system while it succeeds in an i586 environment. Is orc supposed to be run on 32-bit architectures only? If you don't know, please ask upstream for clarification. Maybe you should also add %check make check to the spec file. All architectures on which the tests fail during a koji scratch build should probably be excluded from the build process. Finally, please always provide direct links to the spec and SRPM files. :)
(In reply to comment #9) > It seems the package doesn't work on 64-bit architectures. At least, the test > suite executed by "make check" fails on my x86_64 system while it succeeds in > an i586 environment. Is orc supposed to be run on 32-bit architectures only? If > you don't know, please ask upstream for clarification. Maybe you should also > add > %check > make check yes I will ask this upstream. But have you got some log with error informations?
Created attachment 365216 [details] local build log I've attached my build log. However, the tests succeed in a koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1753565 Currently, I have no clue why they fail on my system (F-11, x86_64). As you can see in the koji build logs, the tests also crash with a segfault on ppc systems.
Upstream has just released a new version of schroedinger, so it's time to finisch orc. In the menawhile there was also an update to orc, so here we go: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/1/orc.spec http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/1/orc-0.4.3-1.fc14.src.rpm After the issues with 0.4.2 this release builds fine on koji and just some rpmlint issues (do not understand the timeout, as the site is reachable). Even make check runs fine on x86_64. [makerpm@proprietary SPECS]$ rpmlint -v orc.spec ../SRPMS/orc-0.4.3-1.fc14.src.rpm ../RPMS/i686/orc-* orc.spec: I: checking-url http://code.entropywave.com/download/orc/orc-0.4.3.tar.gz (timeout 10 seconds) orc.src: I: checking orc.src: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc.src: I: checking-url http://code.entropywave.com/download/orc/orc-0.4.3.tar.gz (timeout 10 seconds) orc.i686: I: checking orc.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-debuginfo.i686: I: checking orc-debuginfo.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-devel.i686: I: checking orc-devel.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-devel.i686: W: no-documentation orc-doc.i686: I: checking orc-doc.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) 5 packages and 1 specfiles checked; 0 errors, 1 warnings. [makerpm@proprietary SPECS]$ koji build --scratch dist-f13 ../SRPMS/orc-0.4.3-1.fc14.src.rpm Uploading srpm: ../SRPMS/orc-0.4.3-1.fc14.src.rpm [====================================] 100% 00:00:16 527.57 KiB 31.88 KiB/sec Created task: 2030223 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2030223 None Watching tasks (this may be safely interrupted)... 2030223 build (dist-f13, orc-0.4.3-1.fc14.src.rpm): open (x86-06.phx2.fedoraproject.org) 2030225 buildArch (orc-0.4.3-1.fc14.src.rpm, i686): free 2030224 buildArch (orc-0.4.3-1.fc14.src.rpm, x86_64): free 2030224 buildArch (orc-0.4.3-1.fc14.src.rpm, x86_64): free -> open (x86-02.phx2.fedoraproject.org) 2030225 buildArch (orc-0.4.3-1.fc14.src.rpm, i686): free -> open (x86-07.phx2.fedoraproject.org) 2030224 buildArch (orc-0.4.3-1.fc14.src.rpm, x86_64): open (x86-02.phx2.fedoraproject.org) -> closed 0 free 2 open 1 done 0 failed 2030225 buildArch (orc-0.4.3-1.fc14.src.rpm, i686): open (x86-07.phx2.fedoraproject.org) -> closed 0 free 1 open 2 done 0 failed 2030223 build (dist-f13, orc-0.4.3-1.fc14.src.rpm): open (x86-06.phx2.fedoraproject.org) -> closed 0 free 0 open 3 done 0 failed 2030223 build (dist-f13, orc-0.4.3-1.fc14.src.rpm) completed successfully Sigh. :)
There are several problems with this package. - The testsuite is failing * Most problem seems related to libtool not patched to use /usr/lib64 by default, so it could be easier to use autoreconf -vif * One test is failing because of assembler code (on F-12 x86_64 AMD64) - There is still rpath on produced binaries (at least on x86_64) by disabled with autoreconf - building docs produce errors. (missing BR ?) - It's usually better to install with install -p to prevents timestamp change for headers, doing like: make install DESTDIR=%{buildroot} INSTALL="install -p" - rpmlint on installed file isn't quiet: rpmlint orc orc.x86_64: W: undefined-non-weak-symbol /usr/lib64/liborc-0.4.so.0.0.0 floor orc.x86_64: W: undefined-non-weak-symbol /usr/lib64/liborc-0.4.so.0.0.0 sqrtf orc.x86_64: W: unused-direct-shlib-dependency /usr/lib64/liborc-pixel-0.4.so.0.0.0 /lib64/libm.so.6 orc.x86_64: W: unused-direct-shlib-dependency /usr/lib64/liborc-pixel-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 -> liborc misses -lm at link time. - Contradiction with README: - Q: How big is the Orc library? A: Compiled with only one target (SSE), the library size is about 86 kB uncompressed, or 30 kB compressed. The goal is to keep the uncompressed size under about 100 kB. # ls -alh /usr/lib64/liborc-0.4.so.0.0.0 -rwxr-xr-x. 1 root root 293K mars 8 23:03 /usr/lib64/liborc-0.4.so.0.0.0 Do we know if this library grown abnormally or that was expected and the README need to be corrected ?
Argh. I did not rpmlint the packages of the others arches. I will look into these issues at the beginning o next week.
(In reply to comment #13) > There are several problems with this package. > - The testsuite is failing > * Most problem seems related to libtool not patched to use /usr/lib64 by > default, so it could be easier to use autoreconf -vif .. > - There is still rpath on produced binaries (at least on x86_64) by disabled > with autoreconf using autoreconf -vif did the trick. > - building docs produce errors. (missing BR ?) There are two missing files and another file not processed. I fixed the two missing files, btut do not know how to fix the version.entities-issue, but does not seem to be to critical ... > - It's usually better to install with install -p to prevents timestamp change > for headers, doing like: > make install DESTDIR=%{buildroot} INSTALL="install -p" if this way is better: why is it not the default? > - rpmlint on installed file isn't quiet: > rpmlint orc > orc.x86_64: W: undefined-non-weak-symbol /usr/lib64/liborc-0.4.so.0.0.0 floor > orc.x86_64: W: undefined-non-weak-symbol /usr/lib64/liborc-0.4.so.0.0.0 sqrtf > orc.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/liborc-pixel-0.4.so.0.0.0 /lib64/libm.so.6 > orc.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/liborc-pixel-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 > -> liborc misses -lm at link time. current rpmlint: [fabiand@proprietary Downloads]$ ls orc-* orc-0.4.3-2.fc14.i686.rpm orc-debuginfo-0.4.3-2.fc14.i686.rpm orc-devel-0.4.3-2.fc14.x86_64.rpm orc-0.4.3-2.fc14.src.rpm orc-debuginfo-0.4.3-2.fc14.x86_64.rpm orc-doc-0.4.3-2.fc14.i686.rpm orc-0.4.3-2.fc14.x86_64.rpm orc-devel-0.4.3-2.fc14.i686.rpm orc-doc-0.4.3-2.fc14.x86_64.rpm [fabiand@proprietary Downloads]$ rpmlint -v orc* orc.i686: I: checking orc.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc.src: I: checking orc.src: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc.src: I: checking-url http://code.entropywave.com/download/orc/orc-0.4.3.tar.gz (timeout 10 seconds) orc.x86_64: I: checking orc.x86_64: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-debuginfo.i686: I: checking orc-debuginfo.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-debuginfo.x86_64: I: checking orc-debuginfo.x86_64: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-devel.i686: I: checking orc-devel.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-devel.x86_64: I: checking orc-devel.x86_64: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-doc.i686: I: checking orc-doc.i686: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) orc-doc.x86_64: I: checking orc-doc.x86_64: I: checking-url http://code.entropywave.com/projects/orc/ (timeout 10 seconds) 9 packages and 0 specfiles checked; 0 errors, 0 warnings. > - Contradiction with README: > - Q: How big is the Orc library? > > A: Compiled with only one target (SSE), the library size is about > 86 kB uncompressed, or 30 kB compressed. The goal is to keep the > uncompressed size under about 100 kB. > # ls -alh /usr/lib64/liborc-0.4.so.0.0.0 > -rwxr-xr-x. 1 root root 293K mars 8 23:03 /usr/lib64/liborc-0.4.so.0.0.0 > Do we know if this library grown abnormally or that was expected and the > README need to be corrected ? Good question. I'm sending this question upstream ... Spec and srpm: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/2/orc.spec http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/2/orc-0.4.3-2.fc14.src.rpm
koji task: https://koji.fedoraproject.org/koji/taskinfo?taskID=2061190
Adding myself here so I can ebuild gstreamer-plugins-bad-free once this lib has landed.
Do we know if this package can build fine on AMD CPU? At least testsuite fails with my X2 4200+ , whereas it worked in the builder: http://koji.fedoraproject.org/koji/taskinfo?taskID=2076254 -------------- 8: retq /* compover inplace 4,4,4 */ /* compovera inplace 1,1,1 */ /* compadd inplace 4,4,4 */ XFAIL: exec_opcodes_pixel ==================== 1 of 11 tests failed ==================== make[4]: *** [check-TESTS] Erreur 1 make[4]: quittant le répertoire « /home/builder/rpmbuild/BUILD/orc-0.4.3/testsuite » make[3]: *** [check-am] Erreur 2 make[3]: quittant le répertoire « /home/builder/rpmbuild/BUILD/orc-0.4.3/testsuite » make[2]: *** [check-recursive] Erreur 1 make[2]: quittant le répertoire « /home/builder/rpmbuild/BUILD/orc-0.4.3/testsuite » make[1]: *** [check-recursive] Erreur 1 make[1]: quittant le répertoire « /home/builder/rpmbuild/BUILD/orc-0.4.3 » make: *** [check] Erreur 2 -------------- That's probably out of the scope of F-13, but ppc64 at least is failing: http://koji.fedoraproject.org/koji/taskinfo?taskID=2076263 I don't know if it worth to handle this, given that it's now a secondary arch in Fedora. Do we have more feeback on the library size ? I will do run-time tests with the Schrodinger update tomorrow.
The library sizes are for non-default configurations that are only intended for embedded use. The standard configuration includes all backends, plus the parser. The sizes listed here sound reasonable. The x86-64 testsuite failure is a real bug. I just fixed it in master, and will be releasing 0.4.4 shortly (todayish?) with the fix (along with a bunch of other fixes). The powerpc-64 bug appears to be a real bug, and it looks like it happens on powerpc-32 as well. I'll look into it after the release.
Shortly after this comment a new release appeard: http://code.entropywave.com/2010/03/orc-0-4-4-released/ SPEC: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/1/orc.spec SRPM: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/1/orc-0.4.4-1.fc14.src.rpm Corresponding koji task: http://koji.fedoraproject.org/koji/taskinfo?taskID=2083642 rpmlint shows no errors/warnings for any koji generated file. (In reply to comment #19) > The library sizes are for non-default configurations that are only intended for > embedded use. The standard configuration includes all backends, plus the > parser. The sizes listed here sound reasonable. Sounds good. > The x86-64 testsuite failure is a real bug. I just fixed it in master, and > will be releasing 0.4.4 shortly (todayish?) with the fix (along with a bunch of > other fixes). The koji build is running fine. @kwizart Can you still reproduce the problem on AMD arches? > The powerpc-64 bug appears to be a real bug, and it looks like it happens on > powerpc-32 as well. I'll look into it after the release. Ok. This should not be a problem for us, as ppc is no primary arch.
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. - 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. SHOULD: - doc subpackage can be set as noarch as it's rather big (450ko) - 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 - Untracked action from upstream build system: You need to do: rm -rf %{buildroot}/%{_libdir}/orc. Is it possible to have it handled upstream at some point ? - It should be possible to avoid usage of generated header in the API: orc/orc-stdint.h:#define _STDINT_HAVE_STDINT_H 1
(In reply to comment #21) > - 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. The output of orcc does not depend on the architecture it was compiled on/for. You only need one copy. > You need to do: rm -rf %{buildroot}/%{_libdir}/orc. Is it possible to have it > handled upstream at some point ? Oh bother. These are not supposed to be installed, as they are the testsuite programs.
(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 :)
(In reply to comment #23) ... > Done. Do you recommend this always, using -p ? If so this should be discussed > somewhere (ml, bz). This has been stated on the guidelines: http://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps Once that said, it's true that it could have been handled with another macro, the current %makeinstall macro been forbidden: http://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_macro_should_not_be_used > > - Installed binary in devel: %{_bindir}/orcc ... > So how can I handle this in the spec? The current multilibs scheme picks the -devel package and search for packages it depends on. If it bundles libraries, both versions of the dependent package are copied into the 64bit repository. If it contains binaries, only one version is copied into the 64bit repository. So the best way is to split %{_bindir}/orcc into another package which is required by the -devel. > > SHOULD: > > - doc subpackage can be set as noarch as it's rather big (450ko) > > How can I establish this? %ifdef noarch? You can use: BuildArch: noarch Within the %package -doc section. But this only work with newer Fedora. > > - 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. Indeed, Once that said you don't need to fix overlinking, only underlinking needs to be tracked as this often prevent preload to work with the underlinked library. It's only requested to warn upstream about that. > > - 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 :) In an ideal world, a given API shouldn't be platform specific, so headers generated at build time should be prevented (except for constant like for a package to know which version it is). We don't use native -devel headers to cross compile to mingw32 or another cross compilation target, so it doesn't matter that much. Once that said, this orc/orc-stdint.h will be generated at build time, and the 32bit version will have a different time-stamp than the 64bit version. So you need to do: touch -r stamp-h1 %{buildroot}%{_includedir}/%{name}-0.4/orc/orc-stdint.h
Thanks for those lengthy replies :) (In reply to comment #24) > (In reply to comment #23) ... > > > - Installed binary in devel: %{_bindir}/orcc done. I created a separate package -compiler > > > SHOULD: > > > - doc subpackage can be set as noarch as it's rather big (450ko) > > > > How can I establish this? %ifdef noarch? > You can use: > BuildArch: noarch > Within the %package -doc section. But this only work with newer Fedora. done > > > - It should be possible to avoid usage of generated header in the API: > > > orc/orc-stdint.h:#define _STDINT_HAVE_STDINT_H 1 done Spec and srpm: http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/2/orc.spec http://www.informatik.uni-bremen.de/~fabiand/fedora/orc/2/orc-0.4.4-2.fc14.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=2096454
Okay, but I then don't understand why the -devel sub-package doesn't requires -compiler. On the other side, the requirement of the -doc sub-package on the main is probably unneeded. (documentation doesn't need to be on the same computer than main or devel). Note: -DORC_ENABLE_UNSTABLE_API seems to be always enabled, it probably means packages using orc should be tested with care against API Changes and/or ABI incompatibility. Everything else is good, doing runtime tests now.
(In reply to comment #26) > Okay, but I then don't understand why the -devel sub-package doesn't requires > -compiler. It does: %package devel ... Requires: %{name}-compiler > On the other side, the requirement of the -doc sub-package on the main is > probably unneeded. (documentation doesn't need to be on the same computer than > main or devel). > > Note: -DORC_ENABLE_UNSTABLE_API seems to be always enabled, it probably means > packages using orc should be tested with care against API Changes and/or ABI > incompatibility. Ok ... > Everything else is good, doing runtime tests now. Yey :)
(In reply to comment #27) > (In reply to comment #26) > > Okay, but I then don't understand why the -devel sub-package doesn't requires > > -compiler. > > It does: > %package devel > ... > Requires: %{name}-compiler The spec file has the requirement indeed, but not the src.rpm ----------------------- This SPEC file is APPROVED by me ;) -----------------------
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > Okay, but I then don't understand why the -devel sub-package doesn't requires > > > -compiler. > > > > It does: > > %package devel > > ... > > Requires: %{name}-compiler > The spec file has the requirement indeed, but not the src.rpm Erm. Why is this? And: How can I check this? > ----------------------- > > This SPEC file is APPROVED by me ;) > > ----------------------- Fantastic :) I'm looking forward to a brand new shiny schroedinger :)
(In reply to comment #29) .. > Fantastic :) I'm looking forward to a brand new shiny schroedinger :) Good, but you are expected to make a CVS admin request now... http://fedoraproject.org/wiki/CVS_admin_requests
Fabian, please read again the CVS admin requests procedure.
Sorry ... New Package CVS Request ======================= Package Name: orc Short Description: The Oil Runtime Compiler Owners: fabiand Branches: F-13 InitialCC: kwizart
Is it alright to use the sponsor in the InitialCC field?
(In reply to comment #33) > Is it alright to use the sponsor in the InitialCC field? Not mandatory at least, and actually I'm not your sponsor since you were already sponsored. You can leave InitialCC blank and please edit again the fedora-cvs to +. once you corrected the 'New Package CVS Request'
New Package CVS Request ======================= Package Name: orc Short Description: The Oil Runtime Compiler Owners: fabiand Branches: F-13 InitialCC:
Is there still something missing?
sorry, i've made a misstake, fedora-cvs need to be set to ? instead of + (fixed)
CVS done (by process-cvs-requests.py).
So how shall we proceed now? Shall I push orc as an newpackage for F-13, so schroedinger can be updated to 1.0.9 in F-13?
Yes, please push it to F13 asap, so we can get new schroedinger and additional gst-plugins-bad-free plugins there. Is it in devel yet?
You can push orc to updates-testing in F-13, but You cannot have it to build the updated schoedinger until orc goes to stable updates or you ask rel-eng for a build override. Usually packages should go in updates-testing for few days, even for new packages, then pushed to stable once tested.
Okay I pushed it to F-13 updates-testing. But how can I also push it do devel/rawhide?
(In reply to comment #42) > Okay I pushed it to F-13 updates-testing. But how can I also push it do > devel/rawhide? > When you built it in the devel/ dir, it'll be pushed automatically. Have you filed it in bodhi? If so, please mark it as closing this bug. I'll then go and file the build override.
orc-0.4.4-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/orc-0.4.4-2.fc13
orc is tagged into f13-override (see<https://fedorahosted.org/rel-eng/ticket/3609 ), so you can build the new schroedinger easily now. I've already submitted updated gstreamer-plugins-bad-free packages.
(In reply to comment #26) > Note: -DORC_ENABLE_UNSTABLE_API seems to be always enabled, it probably means > packages using orc should be tested with care against API Changes and/or ABI > incompatibility. Code that wants to use unstable API must specifically define ORC_ENABLE_UNSTABLE_API before including headers. It is not ever enabled by default. Currently, there isn't really any unstable API.
orc-0.4.4-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update orc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/orc-0.4.4-2.fc13
orc-0.4.4-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 789192 has been marked as a duplicate of this bug. ***