Bug 526916 - Review Request: orc - The Oil Runtime Compiler
Summary: Review Request: orc - The Oil Runtime Compiler
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nicolas Chauvet (kwizart)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 570452
TreeView+ depends on / blocked
 
Reported: 2009-10-02 13:56 UTC by Fabian Deutsch
Modified: 2012-02-16 15:27 UTC (History)
8 users (show)

Fixed In Version: orc-0.4.4-2.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-25 14:02:40 UTC
kwizart: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)
local build log (105.69 KB, text/plain)
2009-10-19 08:51 UTC, Martin Gieseking
no flags Details

Description Fabian Deutsch 2009-10-02 13:56:15 UTC
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

Comment 1 Fabian Deutsch 2009-10-02 13:57:11 UTC
Koji Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=1724156

Comment 2 Martin Gieseking 2009-10-02 15:42:11 UTC
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.

Comment 3 Fabian Deutsch 2009-10-18 15:54:22 UTC
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.

Comment 4 Martin Gieseking 2009-10-18 17:41:54 UTC
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

Comment 5 Fabian Deutsch 2009-10-18 18:01:52 UTC
(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?

Comment 7 Martin Gieseking 2009-10-18 18:28:18 UTC
(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

Comment 8 Fabian Deutsch 2009-10-18 18:41:30 UTC
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

Comment 9 Martin Gieseking 2009-10-18 20:09:52 UTC
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. :)

Comment 10 Fabian Deutsch 2009-10-18 21:55:56 UTC
(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?

Comment 11 Martin Gieseking 2009-10-19 08:51:02 UTC
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.

Comment 12 Fabian Deutsch 2010-03-04 11:19:21 UTC
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. :)

Comment 13 Nicolas Chauvet (kwizart) 2010-03-08 22:22:03 UTC
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 ?

Comment 14 Fabian Deutsch 2010-03-12 15:07:03 UTC
Argh. I did not rpmlint the packages of the others arches. I will look into these issues at the beginning o next week.

Comment 15 Fabian Deutsch 2010-03-18 14:49:32 UTC
(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

Comment 16 Fabian Deutsch 2010-03-18 14:50:21 UTC
koji task:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2061190

Comment 17 Benjamin Otte 2010-03-18 21:13:27 UTC
Adding myself here so I can ebuild gstreamer-plugins-bad-free once this lib has landed.

Comment 18 Nicolas Chauvet (kwizart) 2010-03-25 23:35:43 UTC
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.

Comment 19 David Schleef 2010-03-29 21:22:47 UTC
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.

Comment 20 Fabian Deutsch 2010-03-30 08:54:22 UTC
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.

Comment 21 Nicolas Chauvet (kwizart) 2010-03-30 22:15:06 UTC
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

Comment 22 David Schleef 2010-03-30 22:32:23 UTC
(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.

Comment 23 Fabian Deutsch 2010-03-31 06:08:25 UTC
(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 :)

Comment 24 Nicolas Chauvet (kwizart) 2010-03-31 22:34:10 UTC
(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

Comment 25 Fabian Deutsch 2010-04-05 23:29:15 UTC
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

Comment 26 Nicolas Chauvet (kwizart) 2010-04-07 11:28:05 UTC
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.

Comment 27 Fabian Deutsch 2010-04-07 12:02:14 UTC
(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 :)

Comment 28 Nicolas Chauvet (kwizart) 2010-04-07 12:25:55 UTC
(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 ;)

-----------------------

Comment 29 Fabian Deutsch 2010-04-07 13:10:12 UTC
(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 :)

Comment 30 Nicolas Chauvet (kwizart) 2010-04-09 13:20:09 UTC
(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

Comment 31 Nicolas Chauvet (kwizart) 2010-04-09 13:42:48 UTC
Fabian, please read again the CVS admin requests procedure.

Comment 32 Fabian Deutsch 2010-04-09 13:56:15 UTC
Sorry ...

New Package CVS Request
=======================
Package Name: orc
Short Description: The Oil Runtime Compiler
Owners: fabiand
Branches: F-13
InitialCC: kwizart

Comment 33 Fabian Deutsch 2010-04-09 13:57:14 UTC
Is it alright to use the sponsor in the InitialCC field?

Comment 34 Nicolas Chauvet (kwizart) 2010-04-09 14:06:12 UTC
(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'

Comment 35 Fabian Deutsch 2010-04-09 14:16:40 UTC
New Package CVS Request
=======================
Package Name: orc
Short Description: The Oil Runtime Compiler
Owners: fabiand
Branches: F-13
InitialCC:

Comment 36 Fabian Deutsch 2010-04-12 09:15:41 UTC
Is there still something missing?

Comment 37 Nicolas Chauvet (kwizart) 2010-04-12 09:22:28 UTC
sorry, i've made a misstake, fedora-cvs need to be set to ? instead of + (fixed)

Comment 38 Kevin Fenzi 2010-04-14 04:38:09 UTC
CVS done (by process-cvs-requests.py).

Comment 39 Fabian Deutsch 2010-04-14 12:56:08 UTC
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?

Comment 40 Benjamin Otte 2010-04-14 13:04:14 UTC
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?

Comment 41 Nicolas Chauvet (kwizart) 2010-04-14 13:07:26 UTC
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.

Comment 42 Fabian Deutsch 2010-04-14 13:20:14 UTC
Okay I pushed it to F-13 updates-testing. But how can I also push it do devel/rawhide?

Comment 43 Benjamin Otte 2010-04-14 13:27:16 UTC
(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.

Comment 44 Fedora Update System 2010-04-14 14:09:21 UTC
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

Comment 45 Benjamin Otte 2010-04-15 21:15:36 UTC
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.

Comment 46 David Schleef 2010-04-16 20:23:08 UTC
(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.

Comment 47 Fedora Update System 2010-04-16 23:29:51 UTC
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

Comment 48 Fedora Update System 2010-04-25 14:02:29 UTC
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.

Comment 49 Susi Lehtola 2012-02-16 15:27:01 UTC
*** Bug 789192 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.