[Debian-science-sagemath] Sage 7.6 testing migration blocked by giac

[Tobias Hansen]

On 06/20/2017 03:44 PM, Ximin Luo wrote:
> Tobias Hansen:
>> On 06/20/2017 01:05 PM, Tobias Hansen wrote:
>>> On 06/20/2017 11:55 AM, Ximin Luo wrote:
>>>> Tobias Hansen:
>>>>> On 06/20/2017 10:56 AM, Ximin Luo wrote:
>>>>>> Tobias Hansen:
>>>>>>> Hi,
>>>>>>>
>>>>>>> dependencies of sage 7.6 have now started to migrate to testing, but
>>>>>>> sage 7.6 can't migrate because giac is blocked due to missing builds on
>>>>>>> armel, armhf and mipsel due to #855078. That means until giac can
>>>>>>> migrate, we have a broken sage 7.4 in testing.
>>>>>>>
>>>>>>> Ximin, did you see that there are new comments on #855078? Maybe they help?
>>>>>>>
>>>>>> Hi, I took a look and the build failures look unrelated to #855078. This bug is a segfault on non-x86 64-bit arches, the build failures we're seeing seem like build rule issues, and fixable. I'll take a look later today.
>>>>>>
>>>>>>> Also, any ideas how we can prevent such incomplete migrations that break
>>>>>>> the old sage version in the future?
>>>>>>>
>>>>>> I actually was not expecting giac to built on armhf/mipsel and was surprised that it did before. But if it's too hard to fix, the easy way to force the migration (for this and future packages) is to upload a version that only declares Architecture: amd64 i386.
>>>>>>
>>>>> I meant more generally. This can happen every time we upload a new bunch
>>>>> of packages for a new Sage version to unstable. If we don't get
>>>>> everything to migrate to testing together it can easily break Sage in
>>>>> testing.
>>>>>
>>>> In those situations, if we control the package, we could do similar to what we did in brial (0.8.5-4) and add a Breaks: sagemath (<= XXX) to prevent testing migration, until the newer version of sagemath and all its dependencies are ready to go in.
>>>>
>>>> X
>>> If that works, we should start doing this routinely. But are you sure it
>>> really works? brial 0.8.5-4 and sagemath 7.4-6 migrated to testing
>>> together, but that was because this sagemath version was uploaded after
>>> brial and depended on the brial version.
>> No that doesn't make sense. Seems like it was the Breaks that caused
>> them to migrate together.
>>
> There's some more detailed info here which is where I got that from:
>
> https://www.debian.org/devel/testing
>
> It talks about "breaks" in the general sense and mentions when Depends: gets broken. I assumed this also includes explicit Breaks:, but it doesn't mention this specifically. Unfortunately number (4) and (5) reasons don't get displayed explicitly on the "migration excuses" page.
>
> X
>
Yes it's not really clear. Since it seemed to work with brial 0.8.5-4,
maybe we should just try it with the sage 8.0 dependencies. Even if the
packages migrate, it will behave better when users are updating and not
leave them with an installed but broken sage.

But this page mentions another thing. When using an architecture list
"i386 amd64" as you mentioned earlier, it still requires manual removal
of the packages from the other architectures:

"If you have explicitly dropped the architecture from the Architecture
list in the control file, and the package has been built for that
architecture before, you will need to request that the old binary
package for this architecture be removed from the archive before your
package can transition to testing. You need to file a bug against
"ftp.debian.org" requesting removal of the dropped architecture's
packages from the unstable archive. Generally the relevant porting list
should be informed as a matter of courtesy."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-science-sagemath/attachments/20170620/3c2d662f/attachment.html>