On 12/16/18 10:24 PM, Bill Allombert wrote: > On Sun, Dec 16, 2018 at 08:25:17PM +0100, Tobias Hansen wrote: >> Package: src:gap >> Version: 4r10p0-2 >> Severity: wishlist >> Tags: sid buster patch >> Control: block 912980 by -1 >> >> Hi Bill, >> >> the sagemath developers managed to get sagemath to work with gap 4.10 >> [1], however they require some changes to GAP. I'm filing this bug in >> order to discuss how we can get a gap in Debian before the buster >> freeze that works with sagemath. I updated the sagemath package in git >> and it works fine when I apply the attached patch to gap. This debdiff >> applies three patches and installs libgap to /usr/lib/triplet, so that >> it can be found. > Hello Tobias, > > As you see, I still did not manage to get GAP 4.9 in testing...
It migrated today. > Do you not also need some kind of symbol mangling to avoid conflicts with > other Sage component ? No, sagemath removed the "libGAP_" prefixes in order to work with the official libgap. If there were any conflicts they were resolved. > The Sage patches change the interface to the library. However it seems > likely libgap in Debian will only be used by Sagemath in Buster, so > maybe we could arrange for those patches to be applied only to libgap > and not to /usr/bin/gap. However the side effect is that each time you > will need to update those extra patches, I will need to reupload gap. > > So there might be benefits to have a separate source package. The aim is to use upstream gap in sage and it might well be that already the next version of gap can be used unpatched with sage. I don't think it makes sense to set up a new package just because we need two or three patches at the moment. > On the other hand, if we decide against a separate source package, > then we need to get 4.10 updated as soon as possible at least in > experimental. I agree, a working sagemath should also be uploaded as soon as possible. > Does that answer your questions ? > >> + * Install libgap to /usr/lib/triplet. > Do you need this now ? When the interface to libgap has stabilized, then > probably we will split libgap from gap-dev and move it to > /usr/lib/triplet, but as long as it is an experimental feature it is > best to keep it in a subdirectory. I would prefer not having to apply yet another workaround to find this library. It is possible though. >> +From: "Erik M. Bray" <erik.b...@lri.fr> >> +Date: Tue, 4 Dec 2018 12:44:23 +0000 >> +Subject: [PATCH 1/3] a version of the writeandcheck.patch from Sage that >> works >> + against 4.10 > This patch looks extremly fragile. This is likely to break /usr/bin/gap. Maybe we don't really need this patch. Sage already had a similar patch before and we didn't. I now tried building sage with a gap without this patch and there were no test failures due to this. >> diff -Nru >> gap-4r10p0/debian/patches/0002-kernel-add-helper-function-for-writing-error-message.patch >> >> gap-4r10p0/debian/patches/0002-kernel-add-helper-function-for-writing-error-message.patch >> --- >> gap-4r10p0/debian/patches/0002-kernel-add-helper-function-for-writing-error-message.patch >> 1970-01-01 01:00:00.000000000 +0100 >> +++ >> gap-4r10p0/debian/patches/0002-kernel-add-helper-function-for-writing-error-message.patch >> 2018-12-07 16:20:43.000000000 +0100 >> @@ -0,0 +1,122 @@ >> +From 0cecb79ff97c73a24acacf8afdc3edba93507661 Mon Sep 17 00:00:00 2001 >> +From: "Erik M. Bray" <erik.b...@lri.fr> >> +Date: Thu, 22 Nov 2018 10:53:31 +0100 >> +Subject: [PATCH 2/3] kernel: add helper function for writing error messages >> to >> + the file/stream referenced by the ERROR_OUTPUT global variable > This one changes the interface to the library. > >> +From: "Erik M. Bray" <erik.b...@lri.fr> >> +Date: Thu, 6 Dec 2018 16:11:35 +0000 >> +Subject: [PATCH 3/3] Prototype for GAP_Enter/Leave macros to bracket use of >> + libgap and stack local GAP objects in code which embeds libgap > This one also changes the interface to the library. Would you be ok with applying these two patches? Best, Tobias
