Re: [gentoo-science] ntl bump
I completely forgot. I need a subslot to trigger rebuild, most notably singular. Francois On 07/11/15 02:16, Thomas Kahle wrote: OK, thanks. I also inherited the spread of death. Sorry for not removing it earlier. I added ntl-9.3 to the main tree (with singular patch). I'll aim for a new stable in 30 days and then we can clean up the intermediate versions too. Cheers, Thomas On 10/07/15 19:52, François Bissey wrote: die removed. Looked singular patch again. Building without it should be fine but problems would appear at run time if I am not mistaken. François On 10/07/2015, at 22:05, François Bissey frp.bis...@gmail.com wrote: I will clean up those “die” for you.
Re: [gentoo-science] ntl bump
Hi,
On 10/07/15 09:07, François Bissey wrote:
On 07/09/15 11:12, François Bissey wrote:
Hi,
Resurrecting the thread from the dead. Sage is moving
to ntl-9.2.0 plus a couple of patches (of which upstream is
aware and will do something about sooner rather than later).
We have patch for singular-3 cherry-picked from the singular-4
main github tree.
All matter of details here
http://trac.sagemath.org/ticket/18845
And upstream released ntl-9.3.0 and sage is moving to that.
And it is now in the sage-on-gentoo overlay to be used for
sage 6.8 when it comes out. It is free of patch originating
from sage! Yeah!
Hi,
I'd like to put 9.3 in the main tree, but there are some problems
with the ebuild. There are lots of unecessary || die and the
patch ${FILESDIR}/${PN}-9.2.0-singular.patch is also not there.
Is this patch necessary for the main tree? What does it do?
Cheers,
Thomas
--
Thomas Kahle
http://dev.gentoo.org/~tomka/
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-science] ntl bump
Hi Thomas,
On 10/07/2015, at 18:23, Thomas Kahle to...@gentoo.org wrote:
Hi,
On 10/07/15 09:07, François Bissey wrote:
On 07/09/15 11:12, François Bissey wrote:
Hi,
Resurrecting the thread from the dead. Sage is moving
to ntl-9.2.0 plus a couple of patches (of which upstream is
aware and will do something about sooner rather than later).
We have patch for singular-3 cherry-picked from the singular-4
main github tree.
All matter of details here
http://trac.sagemath.org/ticket/18845
And upstream released ntl-9.3.0 and sage is moving to that.
And it is now in the sage-on-gentoo overlay to be used for
sage 6.8 when it comes out. It is free of patch originating
from sage! Yeah!
Hi,
I'd like to put 9.3 in the main tree, but there are some problems
with the ebuild. There are lots of unecessary || die and the
patch ${FILESDIR}/${PN}-9.2.0-singular.patch is also not there.
Is this patch necessary for the main tree? What does it do?
I reckon you are right about the number of “|| die” they are not necessary
in EAPI 5.
Still the points you raise are interesting because they are all present in your
ntl-9.0.2.ebuild from which the 9.3.0 ebuild is based. The only thing is that
patches have been rebased on the new code and I added a “src_test” phase
because I think your handling of “test” is wrong - it is at least wrong the
way I have been using the ebuild command directly while I write them.
* As noted the singular patch is for compatibility with singular (at least
version 3, I do not know if it is with version 4). Without it singular won’t
build if I remember correctly.
I will clean up those “die” for you.
François
Re: [gentoo-science] ntl bump
die removed. Looked singular patch again. Building without it should be fine but problems would appear at run time if I am not mistaken. François On 10/07/2015, at 22:05, François Bissey frp.bis...@gmail.com wrote: I will clean up those “die” for you.
Re: [gentoo-science] ntl bump
OK, thanks. I also inherited the spread of death. Sorry for not removing it earlier. I added ntl-9.3 to the main tree (with singular patch). I'll aim for a new stable in 30 days and then we can clean up the intermediate versions too. Cheers, Thomas On 10/07/15 19:52, François Bissey wrote: die removed. Looked singular patch again. Building without it should be fine but problems would appear at run time if I am not mistaken. François On 10/07/2015, at 22:05, François Bissey frp.bis...@gmail.com wrote: I will clean up those “die” for you. -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-science] ntl bump
On 07/09/15 11:12, François Bissey wrote: Hi, Resurrecting the thread from the dead. Sage is moving to ntl-9.2.0 plus a couple of patches (of which upstream is aware and will do something about sooner rather than later). We have patch for singular-3 cherry-picked from the singular-4 main github tree. All matter of details here http://trac.sagemath.org/ticket/18845 And upstream released ntl-9.3.0 and sage is moving to that. And it is now in the sage-on-gentoo overlay to be used for sage 6.8 when it comes out. It is free of patch originating from sage! Yeah! Francois
Re: [gentoo-science] ntl bump
Hi, Resurrecting the thread from the dead. Sage is moving to ntl-9.2.0 plus a couple of patches (of which upstream is aware and will do something about sooner rather than later). We have patch for singular-3 cherry-picked from the singular-4 main github tree. All matter of details here http://trac.sagemath.org/ticket/18845 Francois
Re: [gentoo-science] ntl bump
On 3/04/2015, at 20:52, Thomas Kahle to...@gentoo.org wrote: Bump request was open for a while already: https://bugs.gentoo.org/show_bug.cgi?id=542682 I bumped it yesterday, is the ntl-62 compat patch essential? Well ntl 6.2.x only live in the sage-on-gentoo tree but I would imagine it helps with later version. My pull request has actually been merged in master before the 2.4.5 release but it seems to only live in master for future flint 2.5: https://github.com/wbhart/flint2/pull/95 Patrick reported a test failure that I cannot reproduce yet: https://bugs.gentoo.org/show_bug.cgi?id=545378 Do you know anything about it? No. I am running tests again to see if it is brought by a recent change. I’ll see if I can track to something. François On 03/04/15 00:53, François Bissey wrote: Speaking of flint would you mind importing 2.4.5 from the sage-on-gentoo overlay to the main tree. I should have opened a bump request last month when it was released. François On 3/04/2015, at 01:33, Thomas Kahle to...@gentoo.org wrote: Bumped, but now flint became incompatible: https://github.com/wbhart/flint2/issues/131 On 28/03/15 20:54, François Bissey wrote: And Victor just announce ntl 9.0 on sage-devel: With much trepidation, I have introduced a (hopefully minor) backward incompatibility into NTL. The interface to the single-precision modular arithmetic routines has been modified slightly. This interface change allows for more flexible and more efficient implementation of these routines, which play a crucial role at many levels in NTL. Basically, these changes to the interface abstract away some implementation details that arguably should never been there in the first place. By coding to the new interface, NTL clients will be able to benefit from the current and future improvements. In particular, on 64-bit x86/GCC platforms, single precision moduli can now be up to 60 bits, rather than 50 bits. While some operations may in fact be a little slower, the most important ones (like MulModPrecon) should not be. Using larger moduli speeds up a number of things, like ZZ_pX arithmetic, as fewer primes need to be used in Chinese Remaindering steps. Other applications benefit from larger moduli as well. It is expected that most NTL clients will not be affected at all. Moreover, any code that needs to be updated will be detected by the compiler, and the updates should be simple and mechanical. There is also a configuration flag that will enable the legacy interface (although this is not recommended practice). For more, go to http://www.shoup.net/ntl -- Thomas Kahle http://dev.gentoo.org/~tomka/ -- Thomas Kahle http://dev.gentoo.org/~tomka/
Re: [gentoo-science] ntl bump
Bump request was open for a while already: https://bugs.gentoo.org/show_bug.cgi?id=542682 I bumped it yesterday, is the ntl-62 compat patch essential? Patrick reported a test failure that I cannot reproduce yet: https://bugs.gentoo.org/show_bug.cgi?id=545378 Do you know anything about it? On 03/04/15 00:53, François Bissey wrote: Speaking of flint would you mind importing 2.4.5 from the sage-on-gentoo overlay to the main tree. I should have opened a bump request last month when it was released. François On 3/04/2015, at 01:33, Thomas Kahle to...@gentoo.org wrote: Bumped, but now flint became incompatible: https://github.com/wbhart/flint2/issues/131 On 28/03/15 20:54, François Bissey wrote: And Victor just announce ntl 9.0 on sage-devel: With much trepidation, I have introduced a (hopefully minor) backward incompatibility into NTL. The interface to the single-precision modular arithmetic routines has been modified slightly. This interface change allows for more flexible and more efficient implementation of these routines, which play a crucial role at many levels in NTL. Basically, these changes to the interface abstract away some implementation details that arguably should never been there in the first place. By coding to the new interface, NTL clients will be able to benefit from the current and future improvements. In particular, on 64-bit x86/GCC platforms, single precision moduli can now be up to 60 bits, rather than 50 bits. While some operations may in fact be a little slower, the most important ones (like MulModPrecon) should not be. Using larger moduli speeds up a number of things, like ZZ_pX arithmetic, as fewer primes need to be used in Chinese Remaindering steps. Other applications benefit from larger moduli as well. It is expected that most NTL clients will not be affected at all. Moreover, any code that needs to be updated will be detected by the compiler, and the updates should be simple and mechanical. There is also a configuration flag that will enable the legacy interface (although this is not recommended practice). For more, go to http://www.shoup.net/ntl -- Thomas Kahle http://dev.gentoo.org/~tomka/ -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-science] ntl bump
On 03/04/15 10:13, François Bissey wrote: Bump request was open for a while already: https://bugs.gentoo.org/show_bug.cgi?id=542682 I bumped it yesterday, is the ntl-62 compat patch essential? Well ntl 6.2.x only live in the sage-on-gentoo tree but I would imagine it helps with later version. My pull request has actually been merged in master before the 2.4.5 release but it seems to only live in master for future flint 2.5: https://github.com/wbhart/flint2/pull/95 In all likelihood we'll never stable any ntl-6 version, so let's ignore that for now. The new flint-2.4.5 seems to be in shape now. I added the gmp-6 compatibility from upstream to fix test failures. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-science] ntl bump
On 3/04/2015, at 23:12, Thomas Kahle to...@gentoo.org wrote: On 03/04/15 10:13, François Bissey wrote: Bump request was open for a while already: https://bugs.gentoo.org/show_bug.cgi?id=542682 I bumped it yesterday, is the ntl-62 compat patch essential? Well ntl 6.2.x only live in the sage-on-gentoo tree but I would imagine it helps with later version. My pull request has actually been merged in master before the 2.4.5 release but it seems to only live in master for future flint 2.5: https://github.com/wbhart/flint2/pull/95 In all likelihood we'll never stable any ntl-6 version, so let's ignore that for now. The new flint-2.4.5 seems to be in shape now. I added the gmp-6 compatibility from upstream to fix test failures. I’ll adopt the gmp patch in the overlay then and keep the flint ebuild forked in the overlay until sage migrate to some other version of ntl or my pull request gets into a release then. By the way here flint build and passed its test suite against ntl-9, no issues. readelf -d /usr/lib64/libflint.so Dynamic section at offset 0x18fc20 contains 31 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libmpfr.so.4] 0x0001 (NEEDED) Shared library: [libgmp.so.10] 0x0001 (NEEDED) Shared library: [libntl-9.0.2.so] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] François
Re: [gentoo-science] ntl bump
Speaking of flint would you mind importing 2.4.5 from the sage-on-gentoo overlay to the main tree. I should have opened a bump request last month when it was released. François On 3/04/2015, at 01:33, Thomas Kahle to...@gentoo.org wrote: Bumped, but now flint became incompatible: https://github.com/wbhart/flint2/issues/131 On 28/03/15 20:54, François Bissey wrote: And Victor just announce ntl 9.0 on sage-devel: With much trepidation, I have introduced a (hopefully minor) backward incompatibility into NTL. The interface to the single-precision modular arithmetic routines has been modified slightly. This interface change allows for more flexible and more efficient implementation of these routines, which play a crucial role at many levels in NTL. Basically, these changes to the interface abstract away some implementation details that arguably should never been there in the first place. By coding to the new interface, NTL clients will be able to benefit from the current and future improvements. In particular, on 64-bit x86/GCC platforms, single precision moduli can now be up to 60 bits, rather than 50 bits. While some operations may in fact be a little slower, the most important ones (like MulModPrecon) should not be. Using larger moduli speeds up a number of things, like ZZ_pX arithmetic, as fewer primes need to be used in Chinese Remaindering steps. Other applications benefit from larger moduli as well. It is expected that most NTL clients will not be affected at all. Moreover, any code that needs to be updated will be detected by the compiler, and the updates should be simple and mechanical. There is also a configuration flag that will enable the legacy interface (although this is not recommended practice). For more, go to http://www.shoup.net/ntl -- Thomas Kahle http://dev.gentoo.org/~tomka/
Re: [gentoo-science] ntl bump
no problem. I'll bump it (but not today). On 28/03/15 20:54, François Bissey wrote: And Victor just announce ntl 9.0 on sage-devel: With much trepidation, I have introduced a (hopefully minor) backward incompatibility into NTL. The interface to the single-precision modular arithmetic routines has been modified slightly. This interface change allows for more flexible and more efficient implementation of these routines, which play a crucial role at many levels in NTL. Basically, these changes to the interface abstract away some implementation details that arguably should never been there in the first place. By coding to the new interface, NTL clients will be able to benefit from the current and future improvements. In particular, on 64-bit x86/GCC platforms, single precision moduli can now be up to 60 bits, rather than 50 bits. While some operations may in fact be a little slower, the most important ones (like MulModPrecon) should not be. Using larger moduli speeds up a number of things, like ZZ_pX arithmetic, as fewer primes need to be used in Chinese Remaindering steps. Other applications benefit from larger moduli as well. It is expected that most NTL clients will not be affected at all. Moreover, any code that needs to be updated will be detected by the compiler, and the updates should be simple and mechanical. There is also a configuration flag that will enable the legacy interface (although this is not recommended practice). For more, go to http://www.shoup.net/ntl -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-science] ntl bump
Hi On 25/03/15 22:48, François Bissey wrote: On 03/26/15 05:08, Thomas Kahle wrote: dev-libs/ntl is at 8.1.2 already (we have 6.* in the tree). I'd work on the bump if nobody else is. For the 6.* versions there is a patch which implements an error callback mechanism which is used in sage. In the 8.* versions ntl has its own error callback, but it has a different interface than the one in our patch. Will sage (when?) be able to deal with ntl's native mechanism or do we need the patch? I can translate it to the new version, but it may make no sense. For now I think sage should stick with ntl-6.*. Victor (ntl upstream) is now on the sage-devel mailing list and is ready to help sage move on. Sage and packages used by sage are his main consumer after all. But right now no one has started the transistion. I think I may make noise for sage 6.7, at the moment we are re-organizing some of the code wrapping ntl and it may not be advisable to change the version at the same time. The following packages also need checking: flint singular (does 4.* depend on ntl as well) eclib linbox I bumped ntl to 8.1.2 in the tree. Both Singular and Macaulay2 fail with something like NTLconvert.cc:523:79: error: invalid cast from type ‘const NTL::WrappedPtrvoid, NTL::ZZ::Deleter’ to type ‘long int*’ int cc= mpn_get_str (cf_stringtemp, 16, (mp_limb_t *) (((long *) (a.rep)) + 2), sizeofrep); https://github.com/Macaulay2/M2/issues/214 https://github.com/Singular/Sources/issues/710 So I restricted the deps for now. Flint works, and eclib and linbox are not in the main tree or science overlay, so I consider those your business :) I'll have a look at the one that still belong to the s-o-g overlay. Great, thanks. Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-science] ntl bump
On 03/26/15 05:08, Thomas Kahle wrote: Hi, dev-libs/ntl is at 8.1.2 already (we have 6.* in the tree). I'd work on the bump if nobody else is. For the 6.* versions there is a patch which implements an error callback mechanism which is used in sage. In the 8.* versions ntl has its own error callback, but it has a different interface than the one in our patch. Will sage (when?) be able to deal with ntl's native mechanism or do we need the patch? I can translate it to the new version, but it may make no sense. For now I think sage should stick with ntl-6.*. Victor (ntl upstream) is now on the sage-devel mailing list and is ready to help sage move on. Sage and packages used by sage are his main consumer after all. But right now no one has started the transistion. I think I may make noise for sage 6.7, at the moment we are re-organizing some of the code wrapping ntl and it may not be advisable to change the version at the same time. The following packages also need checking: flint singular (does 4.* depend on ntl as well) eclib linbox I'll have a look at the one that still belong to the s-o-g overlay. Francois
