Re: SAGE packages for Debian

[Timothy G Abbott]

Yes, I realize there is not much time left.  I'm also quite busy for the 
next week or two, after which point I should have time to work on this 
again.  The precise release timeline is very helpful.


I won't be able to reasonably maintain this much software in Debian in the 
long term, but I will try to get everything into a release-ready condition 
before the Lenny freeze.


The main task that needs doing is generating patches fixing the various 
(shared) library issues in upstream packages.  Help with this, especially 
during the next couple weeks, could be very high-impact work, since 
ideally we want to give the upstream time to do a release after applying 
the patches we generate to fix their library versioning issues.


Send mail to [EMAIL PROTECTED] to coordinate this, as we've 
done the relevant work for a couple of the packages already.


The other help that this effort needs is people to maintain these packages 
in Debian.  The list of packages needing maintainers is available from 
; looking at the individual package page 
RFP bugs blocking #455292, you can see whether each package is essentially 
ready for upload or require additional work (which I detail in each case).
If you're a Debian maintainer or developer and want to maintain any of 
these packages, feel free to take the packages, set yourself as 
maintainer, and upload them.


-Tim Abbott

On Sun, 11 May 2008, Holger Levsen wrote:


Hi,

wow, great! You're aware that you need to be done in just a bit more than six
weeks to achieve your goal of being part of lenny?
http://release.debian.org/emails/release-update-200801


regards,
Holger




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SAGE packages for Debian (fwd)

[Timothy G Abbott]

On Wed, 7 May 2008, Jordi Gutiérrez Hermoso wrote:


On 06/05/2008, Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote:

 For example, SAGE wanted a particular version of "gpari" with some
 patches. The actual version of "gpari" in Debian is different.


It's a bit worse than that. I asked William Stein about it a while ago
when I had wild dreams of embarking on the Sage packaging myself.

Sage patches pretty much all of the packages it ships. It patches
Maxima, for example, which apparently breaks everything with each new
release and Will Stein doesnt' like, and it also patches Octave. It
seems to me to be a bit worse than the problems that people faced when
packaging OO.o, which also shipped with its own Java implementation.


In SAGE 3.0.1, the Maxima spkg is stock 5.13.0 (except they seem to have 
removed some of the documentation to save disk space).


-Tim Abbott

Re: SAGE packages for Debian (fwd)

[Timothy G Abbott]

On Wed, 7 May 2008, Kapil Hari Paranjape wrote:


The primary problem that makes my packages
potentially unsuitable for uploading to Debian now is many of them may
violate Debian library policy:


Last time I looked at the problem of packaging SAGE, there was one
other issue.

SAGE required certain libraries/programs to be "fixed" at certain
upstream versions (with/without additional patches) in order to
ensure compatible behaviour.

For example, SAGE wanted a particular version of "gpari" with some
patches. The actual version of "gpari" in Debian is different.

If this has changed, then please correct me. Otherwise, it raises a
host of issues which would cause the package(s) to be incompatible with
Debian.


The SAGE folks ship a bundle with all their dependencies that they've 
tested completely, because it allows them to fix any bug in SAGE, 
regardless of whether the problem is in SAGE itself or one of their 
dependencies, and helps them limit the amount of time they spend debugging 
problems the developers can't reproduce.  So, they definitely tell anyone 
who asks about running SAGE with their own "gpari" that it's not a 
supported configuration.


In my experience running with whatever version of these packages is in 
Debian Lenny, the SAGE code doesn't rely heavily on a particular version 
of a dependency.  They do often include the latest versions of their 
dependencies, however, and the SAGE code sometimes starts using new 
features in these dependencies fairly quickly.  So, for example, my 
repository has at various points in time contained updated versions of 
cython, zodb, and matplotlib asking for them to update to a new version 
because SAGE used interfaces new in a later release than that available in 
Debian.  Cython should perhaps be considered an exception here because its 
development is tied to that of SAGE.  So, I've needed newer versions of 2 
of the 50 packages already in Debian that SAGE depends on.


SAGE also does maintain patches against upstream packages, though they 
have been working hard during 2008 to get their patches merged upstream (I 
think in part inspired by the fact that this needs to happen for SAGE to 
be packaged as anything other than a giant blob).  Most of these patches 
go away with the next upstream release; it's not the end of the world if 
the package for SAGE in Debian keeps using that buggy gpari (or whatever) 
package until upstream merges the fix.  My packages at present only apply 
a few patches against the upstream sources (though I obtain my upstream 
sources from SAGE's upstream portion of their spkgs; in most cases these 
are in fact clean upstream but I think a few are pre-release versions of 
the upstream because the upstream developer is working on SAGE).


So, while I think that version issues was a big problem 6 months ago, I 
don't think it's a big problem now.



This aspect of SAGE seemed to make it more appropriate for a Custom
Debian Distribution rather than a package. It may be easier to start
this way in any case given the complexity. Over time, after
co-ordinating with the developers of SAGE dependencies within Debian
it should be possible to fold all the packages back into Debian. (Ref:
demudi and texlive)


I'm not familiar with how CDDs work.  Reading the description at 
, I'm not certain what running a CDD 
actually entails (the website talks about a lot of issues involved, but 
not about things like what apt repository CDD packages live in, how users 
install them, etc. -- maybe this depends on the CDD?).


-Tim Abbott


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

SAGE packages for Debian (fwd)

[Timothy G Abbott]

(reposted from debian-devel, since debian-science is more precisely my 
target audience for this message)


I've been working on packaging for Debian SAGE (http://sagemath.org), a 
large free mathematics software conglomeration that is competing with 
proprietary mathematical software systems such as Mathematica, Matlab, 
Maple, and Magma (Debian bug #455292).


This has been a rather large effort because a major contribution of SAGE 
is providing an excellent ipython-base interface to a number of other free 
software mathematics libraries; the SAGE distribution comes with some 71 
dependencies, of which only around 2/3 are available in Debian already.


I currently have a working apt repository from which one can "apt-get 
install sagemath" (some details on the repository are available at 
) with some 26 source packages in it 
that I created for the SAGE dependencies.  The repository also contains 
modified versions of various Debian packages with quick workarounds for 
bugs #472392, #474080, #474083.


The packages are tested to the extent that I have run a full set of SAGE 
doctests against them with two different SAGE releases, and they largely 
seem to work (though there are definitely a number of bugs remaining).


However, while it is nice to have a repository that people who want to use 
SAGE can add to their sources.list, it would be far better for SAGE to be 
available in Debian (I think having SAGE packages ready for lenny is a 
reasonable goal). The primary problem that makes my packages potentially 
unsuitable for uploading to Debian now is many of them may violate Debian 
library policy:
- shared libraries whose soname is 0.0.0 (suggesting the upstream may not 
actually be doing versioning)
- static libraries compiled with -fPIC (something strongly discouraged in 
the library packaging guide)

- shared libraries that don't have versioning at all (clearly a bug)

For the shared libraries that are missing sonames entirely, I am in 
contact with the upstream developers and they are working on getting some 
sort of shared library versioning implemented (the SAGE developers are 
very supportive of this effort and have offered to help the upstream 
developers with some of these library versioning issues).


Below I list new source packages categorized by roughly how ready they are 
for being uploaded to the Debian archive.  Many of them have 
"description-contains-homepage" and "out-of-date-standards-version 3.7.2" 
lintian warnings because I wrote most of the control files on etch, and 
several have slightly more serious "binary-without-manpage" warnings.



The secondary problem with getting these 26 source packages into Debian is 
that I simply don't have the time to responsibly maintain 26 source 
packages in Debian.  So, I'm looking for people and teams in Debian to 
adopt some of these SAGE dependencies and upload them in time for Lenny.


My guess is the right Debian protocol for coordinating this is for me to 
file RFP bugs for all the packages below, linking in each to my existing 
draft packaging and mark those RFP bugs as all blocking #455292.  But I'd 
appreciate feedback on this plan before I file 26 bug reports.


If you're interested in helping maintain SAGE and its dependencies in 
Debian, you should join us on the [EMAIL PROTECTED] mailing 
list (I have no objection to eventually migrating to a lists.debian.org 
list in the future, but that's what we've been using thus far).


Any feedback or suggestions would also be greatly appreciated.

-Tim Abbott

Packages with no problems worse than missing man pages:
python-arpack (from the scipy sandbox)
python-delaunay (from the scipy sandbox)
flintqs
genus2reduction
gfan [but depends on cddlib, see below]
palp
rubiks
sympow
lcalc
polybori

Packages with suspicious 0.0.0 sonames:
libfplll
iml
libm4ri [also needs description]
givaro
linbox-wrap

Packages with no shared library whose static library is compiled with -fPIC
linbox
symmetrica
tachyon
cddlib

Packages that have clear library policy issues:
eclib [no soname]
flint [no soname]
libzn-poly [no soname, though I've sent a patch for this upstream]
ntl [no soname, though I've sent a patch for this upstream]
singular [no soname]

Packages that have other oustanding issues:
guava [binaries under /usr/share/gap; also many lintian warnings will be fixed 
in the 3.5 upstream release]

sagemath [numerous issues]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]