[Debian-science-sagemath] Sage 7.5 and Singular patches

[Tobias Hansen]

On 03/15/2017 11:03 PM, Tobias Hansen wrote:
> On 03/14/2017 09:15 AM, Ximin Luo wrote:
>> Tobias Hansen:
>>> On 03/11/2017 03:22 PM, Ximin Luo wrote:
>>>> Tobias Hansen:
>>>>> On 03/10/2017 12:57 PM, Ximin Luo wrote:
>>>>>> Tobias Hansen:
>>>>>>> Thanks! All the singular related test failures I reported last time are
>>>>>>> gone except the one attached to this mail. That means we don't have any
>>>>>>> timeouts or segfaults anymore, just normal failures. Mostly ones that we
>>>>>>> already had for 7.4.
>>>>>>>
>>>>>>> [..]
>>>>>>
>>>>>> Hey, shall we release this soon? I can do a test build over the weekend as well.
>>>>>>
>>>>>> X
>>>>>>
>>>>>
>>>>> Yes, sure. I'm traveling until Monday and can't do much until then.
>>>>>
>>>>> The new 3D plotting with threejs works, but it loads threejs from the
>>>>> web. Can we leave it like that for experimental? Otherwise we need to
>>>>> either disable it or backport the patches from Sage 7.6 for using a
>>>>> local version of threejs. And update the threejs package.
>>>>>
>>>>
>>>> I think if upstream do that then we should stick with it, but I'll see if I can trivially patch in a "warning notice" somewhere in the UI.
>>>>
>>>> Afterwards, we can immediately begin packaging 7.6.beta directly after we release 7.5.1, and possibly have 7.5.1 in unstable with 7.6.beta in experimental.
>>>>
>>>> I think this is better, since it means we'd stay mostly-ahead rather than mostly-behind. (I'm also suggesting this approach for the Debian rust team.)
>>>>
>>>> X
>>>>
>>>
>>> I think we should not upload new versions to unstable during the freeze,
>>> to keep the possibility to fix RC bugs in testing via unstable, no?
>>> Whether we want to package beta versions depends a lot on how much
>>> manpower and motivation we have, since that is even more work than just
>>> uploading every stable release. I'd be already happy if we upload every
>>> stable release (to unstable, during the freeze to experimental),
>>> possibly using beta or rc versions when working on a package for a new
>>> sage version.
>>>
>>
>> I had thought there was a "testing-proposed-updates" mechanism but I can't find documentation on it now. I think it does exist though. Since sagemath does not have any build-dependencies on it at the moment I think uploading to unstable should not interfere with the stretch release, even for other packages.
>>
>> In terms of manpower and motivation, I think we can make it work with no extra overhead - just do exactly the same thing we have been doing, except target the current beta/rc version of Sage, and build+upload it to experimental. When that is released upstream, for Debian it should simply be a case of rebuild+upload to unstable, with minimal extra effort since we already did that for experimental.
>>
>> Then we can release 7.7 in Debian (perhaps even 7.6) within a week or so of it being release upstream, which is much better for everyone.
>>
>> X
>>
> 
> It's more work because we need to get everything into a working state
> more often.
> 
> Even if there is a testing-proposed-updates mechanism (I also didn't
> find anything about it when I looked), the freeze policy only allows
> updates for severity important bugs when done via unstable.
> 
> So I guess we can upload Sage 7.5.1 to experimental now, right?
> 
> Best,
> Tobias
> 

But sure, if we happen to get a beta or rc version ready we can upload
it. I would say during the freeze to deb-sci-sage and otherwise to
experimental. I don't think we should aim to package all beta/rc releases.

I uploaded 7.5.1 to experimental. I'll probably soon update to 7.6.rcx
and upload the packages required for that to deb-sci-sage.
I'll update ecl and maxima and upload them and eclib (already packaged
in git by Julien) to deb-sci-sage. The other packages were we are behind
are just ntl and some jupyter packages. (And there's a chance the new
versions are not strictly required for sage to build.)

Best,
Tobias