Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 175209 - sci-libs/cln-1.1.13 stable request
Summary: sci-libs/cln-1.1.13 stable request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Science Related Packages
URL: http://www.ginac.de/CLN/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-19 13:03 UTC by Markus Dittrich (RETIRED)
Modified: 2007-07-26 22:19 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Dittrich (RETIRED) gentoo-dev 2007-04-19 13:03:35 UTC
Dear all,

Could we please mark sci-libs/cln-1.1.13 stable! It has
been bug free and running smoothly for quite some time now.
cln comes with an extensive set of test routines that you may
use to verify that it works properly.

Thanks a bunch,
Markus
Comment 1 Ferris McCormick (RETIRED) gentoo-dev 2007-04-19 14:44:59 UTC
Some tests on sparc (e.g., test_I_mul.cc @ 24, 31) have problems.  Is this expected?  Does this indicate an error?  I'm holding off on stable for sparc until resolved.

This package is hard to test exhaustively because some tests (like _gcd tests) run for a very long time.
Comment 2 Matthias Langer 2007-04-19 15:50:30 UTC
on x86 (but most likely on any other arch):

is there a reason that sci-libs/cln-1.1.10 (currently stable) has SLOT="1", while sci-libs/cln-1.1.13 has SLOT="0"? I think that changing SLOT to "1" in the newer ebuild would resolve this:

"
[...]
existing file /usr/include/cln/SV_real.h is not owned by this package
existing file /usr/include/cln/SV_rational.h is not owned by this package
existing file /usr/lib/libcln.so.4 is not owned by this package
existing file /usr/lib/libcln.so is not owned by this package
[...]
package sci-libs/cln-1.1.13 NOT merged
[...]
 * sci-libs/cln-1.1.10:

     '/usr/bin/cln-config'
     '/usr/lib/libcln.a'
     '/usr/lib/libcln.la'
     '/usr/lib/pkgconfig/cln.pc'
[...]
"
Comment 3 Markus Dittrich (RETIRED) gentoo-dev 2007-04-19 21:36:07 UTC
(In reply to comment #1)
> Some tests on sparc (e.g., test_I_mul.cc @ 24, 31) have problems.  Is this
> expected?  Does this indicate an error?  I'm holding off on stable for sparc
> until resolved.
> 
> This package is hard to test exhaustively because some tests (like _gcd tests)
> run for a very long time.
> 

Hi Ferris,

Thanks for testing. Unfortunately, I personally can only test on x86 on
which all tests pass for me. If sparc has issues, we can drop it for now
since I won't be able to help out fixing any problems unless I get access
to a sparc box.

Thanks,
Markus

Comment 4 Markus Dittrich (RETIRED) gentoo-dev 2007-04-19 21:46:23 UTC
(In reply to comment #2)
> on x86 (but most likely on any other arch):
> 
> is there a reason that sci-libs/cln-1.1.10 (currently stable) has SLOT="1",
> while sci-libs/cln-1.1.13 has SLOT="0"? I think that changing SLOT to "1" in
> the newer ebuild would resolve this:
> 
Hi Matthias,

Thanks for testing!

I've changed the slot to "1" since I don't think cln should and can be 
slotted. Unfortunately, I don't know why cln was originally slotted in 
the first place. 
In order to avoid the package collisions I've just changed
the slot back to 1 despite what I said above.

cheers,
Markus

Comment 5 Ferris McCormick (RETIRED) gentoo-dev 2007-04-19 22:18:04 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Some tests on sparc (e.g., test_I_mul.cc @ 24, 31) have problems.  Is this
> > expected?  Does this indicate an error?  I'm holding off on stable for sparc
> > until resolved.
> > 
> > This package is hard to test exhaustively because some tests (like _gcd tests)
> > run for a very long time.
> > 
> 
> Hi Ferris,
> 
> Thanks for testing. Unfortunately, I personally can only test on x86 on
> which all tests pass for me. If sparc has issues, we can drop it for now
> since I won't be able to help out fixing any problems unless I get access
> to a sparc box.
> 
> Thanks,
> Markus
> 

It's OK to leave it ~sparc, but we can't mark it stable until we figure out what is going wrong.  I'll try it on a different system tomorrow to make sure it is not system dependent.  There are really few possibilities:  endian problems, source assuming that since we are on a 64-bit architecture, we build 64-bit applications (which for sparc/linux is not true), or some weird compiler failure because of the ultrasparc3 optimization.  Also I'd like to know why I_mul fails, I_div succeeds, and I_gcd appears to loop forever.

So, I'd like to keep it ~sparc and look at it more closely as time permits.

Thanks,
Ferris
Comment 6 Christian Faulhammer (RETIRED) gentoo-dev 2007-04-20 06:33:51 UTC
On amd64 it passes all test, so it is likely not a 64bit problem...

Markus, you can do a slotmove for them in the updates file.

x86/amd64 stable
Comment 7 Ferris McCormick (RETIRED) gentoo-dev 2007-04-20 11:18:26 UTC
(In reply to comment #6)
> On amd64 it passes all test, so it is likely not a 64bit problem...
> 
> Markus, you can do a slotmove for them in the updates file.
> 
> x86/amd64 stable
> 

I should clarify:  Some applications notice that they are being compiled (on sparc) on a sparc64 system and set themselves up as 64-bit user mode applications.  For sparc/linux, this is almost certain to lead to failure, because sparc/linux supports (officially) only 32-bit userland.  Think of it as an amd64 where you have only /usr/lib32 for some reason, but the compiler notices that you are amd64 and builds a 64-bit application.
Comment 8 Markus Dittrich (RETIRED) gentoo-dev 2007-04-20 12:34:26 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > On amd64 it passes all test, so it is likely not a 64bit problem...
> > 
> > Markus, you can do a slotmove for them in the updates file.
> > 
> > x86/amd64 stable
> > 
> 
> I should clarify:  Some applications notice that they are being compiled (on
> sparc) on a sparc64 system and set themselves up as 64-bit user mode
> applications.  For sparc/linux, this is almost certain to lead to failure,
> because sparc/linux supports (officially) only 32-bit userland.  Think of it as
> an amd64 where you have only /usr/lib32 for some reason, but the compiler
> notices that you are amd64 and builds a 64-bit application.
> 

Hi Ferris,

If there's anything I can help you with please let me know!

Thanks,
Markus
Comment 9 Markus Dittrich (RETIRED) gentoo-dev 2007-04-20 12:36:24 UTC
(In reply to comment #6)
> Markus, you can do a slotmove for them in the updates file.

Hi Christian,

Thanks a lot for reminding me! I completely forgot about this step
which tells you how often I have done this in the last 1.5 years ;)

Cheers,
Markus

Comment 10 Tobias Scherbaum (RETIRED) gentoo-dev 2007-04-22 18:14:55 UTC
ppc stable
Comment 11 Gustavo Zacarias (RETIRED) gentoo-dev 2007-07-26 22:19:57 UTC
So it doesn't look 100% good for sparc, so no stable, closing.