<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/20/2017 03:44 PM, Ximin Luo
      wrote:<br>
    </div>
    <blockquote
      cite="mid:a07d90c7-45a8-a07e-3781-6b468ebbaaf8@debian.org"
      type="cite">
      <pre wrap="">Tobias Hansen:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 06/20/2017 01:05 PM, Tobias Hansen wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On 06/20/2017 11:55 AM, Ximin Luo wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Tobias Hansen:
</pre>
            <blockquote type="cite">
              <pre wrap="">On 06/20/2017 10:56 AM, Ximin Luo wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">Tobias Hansen:
</pre>
                <blockquote type="cite">
                  <pre wrap="">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?

</pre>
                </blockquote>
                <pre wrap="">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.

</pre>
                <blockquote type="cite">
                  <pre wrap="">Also, any ideas how we can prevent such incomplete migrations that break
the old sage version in the future?

</pre>
                </blockquote>
                <pre wrap="">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.

</pre>
              </blockquote>
              <pre wrap="">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.

</pre>
            </blockquote>
            <pre wrap="">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
</pre>
          </blockquote>
          <pre wrap="">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.
</pre>
        </blockquote>
        <pre wrap="">
No that doesn't make sense. Seems like it was the Breaks that caused
them to migrate together.

</pre>
      </blockquote>
      <pre wrap="">
There's some more detailed info here which is where I got that from:

<a class="moz-txt-link-freetext" href="https://www.debian.org/devel/testing">https://www.debian.org/devel/testing</a>

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

</pre>
    </blockquote>
    <p>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.<br>
    </p>
    <p>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:</p>
    <p>"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 <q><a class="moz-txt-link-abbreviated" href="ftp://ftp.debian.org">ftp.debian.org</a></q>
      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."</p>
  </body>
</html>