| Summary: | sci-libs/cln-1.1.13 stable request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markus Dittrich (RETIRED) <markusle> |
| Component: | New packages | Assignee: | Gentoo Science Related Packages <sci> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.ginac.de/CLN/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Markus Dittrich (RETIRED)
2007-04-19 13:03:35 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. 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'
[...]
"
(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 (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 (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 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 (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. (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 (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 ppc stable So it doesn't look 100% good for sparc, so no stable, closing. |