[gentoo-science] ntl bump

[gentoo-science] ntl bump

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

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.

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

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

Re: [gentoo-science] ntl bump

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

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::WrappedPtr<void, 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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-science] ntl bump

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On 03/26/2015 11:18 AM, Thomas Kahle wrote:
> 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::WrappedPtr<void, 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

This happens inside factory and Singular folks have patched it already
some time ago.  I added the patch for in-tree singular and it works now.
For Macaulay2 it is more complicated as factory is built internally, but
I'll figure something out.

Cheers,
Thomas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

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

Re: [gentoo-science] ntl bump

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-science] ntl bump

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

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 <tomka@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

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

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 <tomka@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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

> On 3/04/2015, at 20:52, Thomas Kahle <tomka@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 <tomka@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

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 536 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

> On 3/04/2015, at 23:12, Thomas Kahle <tomka@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:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libmpfr.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libgmp.so.10]
 0x0000000000000001 (NEEDED)             Shared library: [libntl-9.0.2.so]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

François

Re: [gentoo-science] ntl bump

[François Bissey]

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

[François Bissey]

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

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

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/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 522 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

Hi Thomas,
> On 10/07/2015, at 18:23, Thomas Kahle <tomka@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

[François Bissey]

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.bissey@gmail.com> wrote:
> 
> I will clean up those “die” for you.

Re: [gentoo-science] ntl bump

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

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.bissey@gmail.com> wrote:
>>
>> I will clean up those “die” for you.
> 
> 

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 522 bytes --]

Re: [gentoo-science] ntl bump

[François Bissey]

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.bissey@gmail.com> wrote:
>>>
>>> I will clean up those “die” for you.
>>
>>
>