get Macaulay2 into Debian

[DanGrayson]

Doug Torrance [email protected] is working on that now, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439888 and https://groups.google.com/forum/#!topic/macaulay2/jxtKZFRDKDA .

[d-torrance]

We're currently waiting on a number of build dependencies to make it into Debian before Macaulay2 can be uploaded. Currently in the NEW queue are singular, frobby, and memtailor. Once memtailor goes in, we'll upload mathic and then mathicgb. Packages often sit in the NEW queue for months, so this will take some time.

My packaging work so far can be seen at https://github.com/d-torrance/M2/tree/master. Currently there's an issue with gmp (See #285).

[d-torrance]

Dependency update: memtailor has been accepted into Debian unstable.

[mikestillman]

Great!

On Jun 8, 2015, at 9:48 PM, Doug Torrance [email protected] wrote:

Dependency update: memtailor has been accepted into Debian unstable.

—
Reply to this email directly or view it on GitHub #286 (comment).

[d-torrance]

Dependency update: mathic has been accepted into Debian unstable.

[DanGrayson]

Good progress, thanks!

How does one get into "stable"?

[d-torrance]

Debian packages are first uploaded to "unstable", then migrate to "testing" after a few days (10 in mathic's case). At some point in the future, "testing" is frozen and becomes the next "stable" release. Debian just did this recently (Debian 8, or "jessie", was released in April), so the next release (Debian 9, or "stretch") will probably occur in 2 years or so.

Ubuntu moves much more quickly. They migrate packages directly from Debian unstable and release every 6 months. So mathic should be in 15.10 (Wily Werewolf), which will be released in October.

[dimpase]

I wonder if anyone is involved in updating Fedora M2 packages. It's still version 1.5.

[DanGrayson]

Maybe Rex Dieter fell behind or stopped? See
http://www.math.illinois.edu/Macaulay2/Downloads/GNU-Linux/Fedora/index.html

On Fri, Jul 10, 2015 at 9:24 AM Dmitrii Pasechnik [email protected]
wrote:

I wonder if anyone is involved in updating Fedora M2 packages. It's still
version 1.5.

—
Reply to this email directly or view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Macaulay2_M2_issues_286-23issuecomment-2D120410191&d=AwMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=PAZ_jTPLrSb1btCfAu4RkycWe57N0sGyzbjgeOn2wN0&m=Wej3yI2zW7KJZ9huOAE-50HfsfKuhnCik-jATizgnn0&s=du6FB5lsWXZxnl0DAZvJEP0baaXYx8j749My4-eMtMs&e=
.

[rdieter]

Fedora 22 ships Macaulay2-1.6

I've been fighting trying to get more recent versions unsuccessfully. Will
probably be pinging this group for help/advice sometime soon.
On Jul 8, 2015 11:23 AM, "Doug Torrance" [email protected] wrote:

Dependency update: mathic has been accepted into Debian unstable.

—
Reply to this email directly or view it on GitHub
#286 (comment).

[d-torrance]

Dependency update: mathicgb has been accepted into Debian unstable.

[d-torrance]

Dependency update: frobby has been accepted into Debian unstable.

[DanGrayson]

Thanks!

[rdieter]

Last I knew, frobby's licensing was nonfree (is why it's not in fedora at
least), has the situation changed?

On Fri, Jul 24, 2015 at 12:49 PM, Daniel R. Grayson <
[email protected]> wrote:

Thanks!

—
Reply to this email directly or view it on GitHub
#286 (comment).

[rdieter]

Hrm, looking closer I was mistaken here, sorry for the noise.

On Wed, Jul 29, 2015 at 12:06 PM, Rex Dieter [email protected] wrote:

Last I knew, frobby's licensing was nonfree (is why it's not in fedora at
least), has the situation changed?

On Fri, Jul 24, 2015 at 12:49 PM, Daniel R. Grayson <
[email protected]> wrote:

Thanks!

—
Reply to this email directly or view it on GitHub
#286 (comment).

[d-torrance]

Belated dependency update: singular was accepted into Debian unstable on August 3.

At this point, I believe all of the dependencies are now in Debian.

[DanGrayson]

Thanks!

[d-torrance]

Status update:

I'm able to successfully build a Debian package using only Debian libraries if I pass --disable-pari to configure and patch out the pari functions giving problems in #396.

Note that this of course breaks these functions which rely on pari, and I don't intend to upload the package until #285 is resolved. But we're getting closer!

[DanGrayson]

Thanks, that makes #285 more important.

On Tue, Apr 12, 2016 at 6:57 AM, Doug Torrance [email protected]
wrote:

Status update:

I'm able to successfully build a Debian package using only Debian
libraries if I pass --disable-pari to configure and patch out the pari
functions giving problems in #396
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Macaulay2_M2_issues_396&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=PAZ_jTPLrSb1btCfAu4RkycWe57N0sGyzbjgeOn2wN0&m=vcAnxJs_V2oxwvYUnhD3wF3-F5pa2kXKfTspJC96obg&s=NOagxvsa5kvR7QRuIfQi3bnGbKhp3iaBV21onm_w4zo&e=
.

Note that this of course breaks these functions which rely on pari, and I
don't intend to upload the package until #285
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Macaulay2_M2_issues_285&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=PAZ_jTPLrSb1btCfAu4RkycWe57N0sGyzbjgeOn2wN0&m=vcAnxJs_V2oxwvYUnhD3wF3-F5pa2kXKfTspJC96obg&s=JyuGkrAIwGA3so_Pj9wRz00pFwgels1T15AFEyMN_6k&e=
is resolved. But we're getting closer!

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Macaulay2_M2_issues_286-23issuecomment-2D208864722&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=PAZ_jTPLrSb1btCfAu4RkycWe57N0sGyzbjgeOn2wN0&m=vcAnxJs_V2oxwvYUnhD3wF3-F5pa2kXKfTspJC96obg&s=oLhKMir7qOJ346RfT1hQIXlng0V_Apexw7_KOsHCVPs&e=

[d-torrance]

Also, a question:

/usr/share/doc/Macaulay2/*/example-output/*.out and /usr/lib/Macaulay2/$MACHINE/*/cache/*.db are installed by default and included in the *.deb packages on the M2 website.

If I'm understanding the code (which I certainly may not be), it looks like these files are intermediate steps in generating the documentation. Are they still needed after the initial installation?

[d-torrance]

I just realized these files must be used by the help function.

[DanGrayson]

The *.out files are retained in case someone wants to regenerate the documentation. The
*.db files allow quick loading of the documentation.

[d-torrance]

Makes sense. Thanks for clarifying!

[d-torrance]

Status update:

The freeze for the next version of Debian (version 9, codename "stretch") is 2017-01-05. It would be great if M2 could be uploaded by then. However, #285 is still the big blocker, as we need M2 to build against the Debian gmp package.

I also need to package a few Javascript libraries used by the new Visualize package.

[d-torrance]

Status update:

I noticed recently that cohomCalg and TOPCOM are now both installed by M2. I've packaged cohomCalg for Debian, and it was just uploaded (currently in the NEW queue pending approval by the FTP masters). I'll work on TOPCOM next. I also still need to package the Javascript libraries used by Visualize.

As for M2 itself, it currently won't build using the Debian packages of givaro and fflas-ffpack (both the latest upstream versions), so I'm waiting for #513. I imagine #285 is still a problem as well, but my builds don't get that far. :)

[mikestillman]

I am working on updating M2 to use the newest givaro, ffpack. The interfaces for these packages appear to have changed quite a bit, and it is taking longer to get it to work.

[DanGrayson]

Thanks, Doug!

[alexmyczko]

What's the current state, then?

[d-torrance]

Thanks for the bump. I haven't looked at this in a while while I waited for #513 and for the latest version of PARI to be uploaded to Debian so that I could implement the fix for #285. But it looks like both of these things have happened. :)

I should have some time over the holidays to see where we're at.

[alexmyczko]

Happy New Year... the holidays? Ping...

[d-torrance]

I did have some time to see where things are at.

After applying a patch to M2/Macaulay2/d/pari-c.c, we do get past #285. (I'll submit a pull request for this in the near future.)

However, then I ran into another problem. Since we're using the dynamically-linked Debian givaro package and not a statically-linked local copy of givaro, we run into #460.

A new version of givaro was released recently. I updated the givaro package in Debian, hoping that it might fix things. But it didn't. :(

So that's where things stand now.

[DanGrayson]

Okay!

If you're successful, does Macaulay2 end up in Ubuntu 20.10, 20.04, 19.10, etc. Or just in 21.04?

Once we're in, say to 21.04, do further releases of Macaulay2 find their way to the users of 21.04 promptly?

[d-torrance]

If you're successful, does Macaulay2 end up in Ubuntu 20.10, 20.04, 19.10, etc. Or just in 21.04?

Just 21.04. But I'm planning on releasing PPA packages (using the same ppa:macaulay2/macaulay2 archive that's used in the Github workflow for various build dependencies) for 18.04, 20.04, and 20.10. (19.10 has already reached its end of life.)

Once we're in, say to 21.04, do further releases of Macaulay2 find their way to the users of 21.04 promptly?

Not through the official Ubuntu archives. Ubuntu 21.04 will be released in April and likely will have 1.17.1 (it already has 1.16, at least for amd64). It will only get security updates after that. 1.18 will likely end up in 21.10 in October, and so on.

[d-torrance]

Macaulay2 1.17.1 is now in Debian unstable (and in Ubuntu hirsute-proposed, which eventually migrates into 21.04 "Hirsute Hippo"). The builds have been going well so far. As I write this, we're still waiting on two official Debian architectures (mips64el and mipsel), and the only build failures are for non-official architectures. Most of them have missing dependencies, but two got pretty far into the build:

• powerpc: Too many heap sections capturing check(8, "DiffAlg") on armhf #1728
• riscv64: signal 9 making example results for "projectivePoints" on riscv64 #1833

The Ubuntu builds have also been going pretty well. The amd64 build, strangely, has been running for 10 hours, but I expect it should be fine, and the only failures have been riscv64 (#1833 again) and s390x (a dependency issue with Emacs).

The continuous integration test for Debian unstable on i386 failed (see #1834), though. It's marked as a regression since it passed for the 1.16.99 package (before check "Core" was a thing). But if I'm reading the docs correctly, I don't think this will prevent migration to testing since 1.16.99 isn't in testing.

So fingers crossed, I think it's likely that it will migrate to both Debian testing and Ubuntu hirsute-release in a few days!

[DanGrayson]

Sounds good!

[d-torrance]

The 1.17.1 package has migrated from "proposed" into "release" for Ubuntu 21.04, so we're definitely in on the Ubuntu side of things! Still two more days until the Debian package might migrate -- I'm still not clear on whether #1834 will block it or not. It's fixed (with an ugly hack) in my current draft, but I'll wait until 1.17.2 is released.

I've also published PPA packages based on this for earlier Ubuntu releases (18.04, 20.04, and 20.10). Would it be worth announcing this on the Google Group and/or adding it as an alternate download location in the Ubuntu section of the webpage?

[mikestillman]

@d-torrance That is great! Thanks!!

Yes, we should announce it on the google group, and fix the webpage for that too. @DanGrayson what do you think?

[DanGrayson]

That's great!

[d-torrance]

#1834 indeed blocked the package from migrating to testing. Is there still a plan to release 1.17.2 soon? Or I could have 1.17.1 re-uploaded.

[DanGrayson]

#1834 indeed blocked the package from migrating to testing. Is there still a plan to release 1.17.2 soon? Or I could have 1.17.1 re-uploaded.

I'm not sure what you mean by re-uploading 1.17.1, but if you want to make a debian release based on something more modern than 1.17.1, I'm happy to bump the version number to 1.17.2 for you, and to make a tag based on that. Does #1834 have to be fixed before that, though?

[d-torrance]

I'm not sure what you mean by re-uploading 1.17.1

I'd keep the same upstream source, but add a -2 revision to the Debian version number. The Debian packaging itself would have a few changes.

but if you want to make a debian release based on something more modern than 1.17.1, I'm happy to bump the version number to 1.17.2 for you, and to make a tag based on that.

I don't really have a preference, but whatever version I use is likely to be a part of Debian 11 and so will be around for a while (and Ubuntu 21.04, but that's not an LTS release so it's less of an issue). So if there's a 1.17.2, it would be nice if it's pretty stable. I think most of the changes since 1.17.1 have been bug fixes and not new features, so that would probably be fine.

Does #1834 have to be fixed before that, though?

I've fixed it in the Debian package by avoiding capture in the Core tests on 32-bit architectures in this patch. I did propose the change (for all architectures) upstream in #1835, but withdrew it based on Mahrud's comments.

[DanGrayson]

I'm under the impression that the current master branch is pretty secure, and could serve as 1.17.2, but I also have no real preference. Perhaps Mike does. Mike? @mikestillman

[DanGrayson]

PS: I don't see anything wrong with your patch (for 32 bit machines) being incorporated in our code -- it won't affect 99% of our users.

[d-torrance]

PS: I don't see anything wrong with your patch (for 32 bit machines) being incorporated in our code -- it won't affect 99% of our users.

Alrighty -- see #1866.

[DanGrayson]

@d-torrance : Well, maybe we should just let 1.17.1 be the Ubuntu distribution. That seems simplest for now.

By the way, our release schedule is biannual, same as Ubuntu's, but our dates are a little after theirs: May 15 and Dec 15. Maybe we should rotate our release schedule to reduce the lag time between our release and the Debian/Ubuntu deadlines. What would be best?

[d-torrance]

@d-torrance : Well, maybe we should just let 1.17.1 be the Ubuntu distribution. That seems simplest for now.

Sounds good. I'll still try and get it in Debian using the patch from #1866.

By the way, our release schedule is biannual, same as Ubuntu's, but our dates are a little after theirs: May 15 and Dec 15. Maybe we should rotate our release schedule to reduce the lag time between our release and the Debian/Ubuntu deadlines. What would be best?

I think the current release schedule works pretty well. Ubuntu freezes migrations from Debian about two months before each release (so February and August for the April and October releases). So that gives plenty of time to package each new version, find a sponsor, fix build failures, etc.

[DanGrayson]

Okay, thanks!

[mikestillman]

I'm under the impression that the current master branch is pretty secure, and could serve as 1.17.2, but I also have no real preference. Perhaps Mike does. Mike? @mikestillman

I think that is fine.

[DanGrayson]

@mikestillman -- I now prefer to just stick with 1.17.1, and what you said above is a little ambiguous. Shall we?

@d-torrance

[mahrud]

For the record, for the brew build it is preferable to use a versioned tarfile, and that's easiest with a tag. For instance, a week ago a test build from the main branch passed, and today it failed. There's no cost to a tag, so why not? You don't need to make binary distribution for all of them.

[DanGrayson]

Yes, certainly, if we bump the version number to 1.7.2, there will be a tag (release-1.7.2) for that.

[d-torrance]

FYI, 1.17.1 has been re-uploaded to Debian unstable. In addition to the #1866 patch, it has a few others from the development branch that hopefully should help it to build on a few more architectures.

[DanGrayson]

Thanks!

[d-torrance]

Good news: The i386 and armhf continuous integration tests are passing! So they're not blocking the migration to testing any more.

Bad news: Now the ppc64el build is failing, which is blocking migration. This has happened twice so far. I've requested a third build, so fingers crossed. I'm not sure what's going on. Both times, it's been killed building relatively small examples.

[d-torrance]

Third time's the charm! The ppc64el package finally built, so things are looking very good for migration to testing in a few days.

[d-torrance]

We did it! Macaulay2 is in Debian 11 "Bullseye"!

From https://tracker.debian.org/news/1225012/macaulay2-1171ds-2-migrated-to-testing/:

FYI: The status of the macaulay2 source package
in Debian's testing distribution has changed.

  Previous version: (not in testing)
  Current version:  1.17.1+ds-2

Note that "testing" will become "stable" at some point later this spring when Bullseye is officially released. (Unlike Ubuntu, Debian doesn't have a set release date. It's released when it's ready.)

[d-torrance]

I suppose we can close this issue now.

[DanGrayson]

We did it! Macaulay2 is in Debian 11 "Bullseye"!

Great!!