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
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.