[Debian-science-sagemath] Sage 8.4 and Debian buster

[Tobias Hansen]

On 10/31/2018 02:39 AM, Jerome BENOIT wrote:
>
> On 06/10/18 14:59, Tobias Hansen wrote:
>> On 10/06/2018 09:55 AM, Tobias Hansen wrote:
>>> On 10/06/2018 09:52 AM, Jerome BENOIT wrote:
>>>> Hello,
>>>>
>>>> On 06/10/18 01:22, Tobias Hansen wrote:
>>>>> On 10/05/2018 07:54 AM, Jerome BENOIT wrote:
>>>>>> On 04/10/18 12:15, Tobias Hansen wrote:
>>>>>>> On 10/04/2018 08:19 AM, Ximin Luo wrote:
>>>>>>>> Tobias Hansen:
>>>>>>>>> On 10/04/2018 06:43 AM, Ximin Luo wrote:
>>>>>>>>>> Jerome BENOIT:
>>>>>>>>>>> On 03/10/18 19:02, Ximin Luo wrote:
>>>>>>>>>>>> Tobias Hansen:
>>>>>>>>>>>>> On 10/01/2018 05:50 AM, Jerome BENOIT wrote:
>>>>>>>>>>>>>> On 30/09/18 23:03, Tobias Hansen wrote:
>>>>>>>>>>>>>>> [..]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We have to figure out what to do with singular (upload 4.1.1p2 to experimental or fix the problem otherwise) and then upload pynac 0.7.22 with a dependency on the new singular version to experimental.
>>>>>>>>>>>>>> Singular 4.1.1p3 is in experimental, I guess I can package 4.1.1p2: can we downgrade in experimental ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jerome
>>>>>>>>>>>>> I don't know. If you want to avoid increasing the epoch you could just try and see if the upload gets rejected.
>>>>>>>>>>>>>
>>>>>>>>>>>> I think for experimental you will have to use something like 4.1.1p3+actually4.1.1p2, epochs are now discouraged by Policy for "downgrade" purposes, see:
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-1-5
>>>>>>>>>>>>
>>>>>>>>>>>> I'm fairly sure you can upload to unstable a version X even if X < what's in experimental as long as it's > what's in unstable. I'm pre+tty sure I've done that before with rustc, e.g. uploaded 1.15.1-3 to unstable even though experimental had 1.16.1-1~exp1.
>>>>>>>>>>> May we upload Singular 4.1.1p2 to Sid ?
>>>>>>>>>>>
>>>>>>>>>> I think that is fine yes.
>>>>>>>>> No, it should conflict with sagemath 8.3. Why not experimental?
>>>>>>>>>
>>>>>>>> 4.1.1p3 is already in experimental. In order to upload 4.1.1p2 to experimental, we would have to version it as 4.1.1p3+actually4.1.1p2 by Debian policy. (As opposed to bumping the epoch, which is now discouraged.)
>>>>>>>>
>>>>>>>> What is wrong with uploading 4.1.1p2 directly to Debian unstable, and then uploading pynac again to force a rebuild? I don't think anything else depends on these.
>>>>>>>>
>>>>>>>> X
>>>>>>>>
>>>>>>> Ok, but then we need to test sagemath 8.3 (with the singular update patch) with these before we do that.
>>>>>> singular 4.1.1-p2+ds is the previous packaged version of singular in experimental.
>>>>>>
>>>>>> So, I guess that we have already the material to test.
>>>>>>
>>>>>> Jerome
>>>>> Ok, I tested sagemath 8.3 with singular 4.1.1-p2 and get the errors that are also discussed in [1] (I also got them with sage 8.4 and singular 4.1.1-p2):
>>>>>
>>>>> sage -t --long src/sage/libs/ntl/error.pyx  # Bad exit: 2
>>>>> sage -t --long src/sage/libs/ntl/ntl_ZZ_pX.pyx  # Bad exit: 2
>>>>> sage -t --long src/sage/matrix/matrix_integer_dense.pyx  # Bad exit: 2
>>>>>
>>>>> So we need to apply the patch [2] to singular.
>>>> I have just pushed to Salsa an ad hoc branch (experimental+actually4.1.1p2) which
>>>> is the former singular 4.1.1-p2+ds-1 with patch [2] .
>>>>
>>>> Please let me know if I can upload it to Sid.
>>>>
>>>> Thanks,
>>>> Jerome
>>> Ok, thanks. I'll do another test run.
>>>
>>> Best,
>>> Tobias
>> Ok, that fixes it. You can upload the patched singular 4.1.1-p2 to unstable. Thanks!
> Please note that 4.1.1-p2+ds-3 reached Sid: due to conflicts, libsingular4 must be replaced by libsingular4m1:
> sage must be built against libsingular4m1 .
>
> Sorry for the mess,
> Jerome
Yes, and pynac must be rebuilt first. I don't know if the intention of reopening #910808 was to achieve this or only ask for changing the package name the next time this happens (since everything was already fine in unstable and testing). But well, I guess that was the correct thing to do.

In the meantime sage FTBFS on mipsel and mips64el because some tests involving jmol are cracking our 4 hour timeout. I checked on a porterbox and there one of the tests* finished normally after 3-4 hours with java using 100% cpu. My plan is to disable long tests on mipsel and mips64el. Most of the tests give the same results on the different architectures and avoiding to spend at least 10 hours of buildd time on mipsel and mips64el just for the long tests is also a good thing.

Best,
Tobias

* It was the line
RootSystem(["F",4]).ambient_space().plot_hedron()
from
src/sage/combinat/root_system/root_lattice_realizations.py