[Pkg-octave-devel] State of the Union
Rafael Laboissiere
rafael at debian.org
Sat Feb 2 12:59:24 UTC 2008
0. Introduction
===============
This a (quite long) summary of the current state of the packages maintained
by the Debian Octave Group. We have had an exciting end of the year in 2007
with the release of Octave 3.0.0 and the pkg.m system for installing the
octave-forge packages. The Debian packaging work is still lagging behind in
some areas and this State of the Union message will address these points.
If you are a DOG member or are just lurking this mailing list and chasing
for a little project to do in your free time, you are at the right place:
just tackle one of the issues below!
1. Getting octave3.0 into testing
=================================
The octave3.0 package was uploaded to unstable on 2007-12-23 [1]. It has
been successfully built on all architectures [2], but it segfaults on arm
[3] when trying to load *.oct files. This bug is preventing the package
from migrating into testing. Soeren Sonnenburg has helped us on this by
compiling Octave on an arm machine and using gdb to track down the failure
(see Bug#458852).
Thomas Weber asked for help in the debian-arm mailing list [4], but his
request is still unanswered. Thomas generated then an image for using the
arm emulation under qemu [5]. I have also tried this image but was unable
to nail down the bug, even though I got some help from John W. Eaton [6].
I think we are stuck for now, unless an arm g++ guru can help us.
Otherwise, we are left with the following possibilities:
* Drop arm as an architecture for octave3.0. This is easy to do in
debian/control, but will very hard to be implemented institutionally.
The reason is because it is virtually impossible to drop an
architecture that has worked in the past. Besides, dropping octave3.0
for arm will imply dropping this architecture for all packages
depending on octave3.0 (pfstools, wims, shogun-octave, plplot, xmds,
all octave-* packages, and others that I forgot).
* Just wait until we migrate from g++ 4.1 into g++ 4.3 (see section 4.
below). Perhaps the problem will magically disappear.
[1] http://packages.qa.debian.org/o/octave3.0/news/20071223T210209Z.html
[2] http://people.debian.org/~igloo/status.php?packages=octave3.0
[3] http://bugs.debian.org/458852
[4] http://lists.debian.org/debian-arm/2008/01/msg00069.html
[5] http://www.aurel32.net/info/debian_arm_qemu.php
[6] http://www.nabble.com/octave-3.0.0-crashes-at-startup-on-ARM-td14729677.html
2. Removal of octave2.9 from the distribution
=============================================
As all of you know, the 2.9 series of octave was considered as a pre-release
of the 3.0 series, which is now the recommended branch. There is no reason
anymore for keeping octave2.9 in Debian. I already reassigned almost all
the bug reports from octave2.9 to octave3.0 and asked for removal of the
former from the distribution [7]. Joerg Jaspert, one of the ftp-master
admins, correctly remarked that there was several reverse-dependencies on
octave2.9 and that the removal is not yet possible. We have addressed the
issues already:
* All packages belonging to the DOG have been fixed.
* plplot-octave was also adapted to octave3.0 [8].
* The shogun-octave package has been fixed [9].
* pfstools is still waiting to be fixed, although there is a patch
available [10].
* The maintainer of wims will make his package depend on the virtual
package "octave" [11]. This will be fine.
In the meantime, Steve Langasek has filed a bug report with severity level
"serious", complaining on the fact that octave3.0 provides octave2.9 and
that this is bogus [12]. We agree with him and hope that everything will be
okay after the removal of octave2.9. We will then be able to completely
drop octave2.9 from Debian and the Provides line from octave3.0.
[7] http://bugs.debian.org/457675
[8] http://packages.qa.debian.org/p/plplot/news/20071224T121703Z.html
[9] http://bugs.debian.org/457979
[10] http://bugs.debian.org/458131
[11] http://bugs.debian.org/458845
[12] http://bugs.debian.org/463039
3. Removal of octave2.1 from the distribution
=============================================
We have to decide whether we also drop octave2.1 from sid/lenny. Upstream
development on the 2.1 branch of Octave has ceased and we should really
deprecate octave2.1. The only reason I am reluctant to do it right now is
because we have not yet packaged octave-forge for octave3.0 (see section 6.
below). Some users with old scripts still rely on the functions provided by
the octave2.1-forge package.
4. g77 -> gfortran transition
=============================
Use of the GCC 4.3 suite is now a goal for the lenny release [13]. We are
still using 4.1 because we build-depend on g77. Octave is one of the main
knots in the complex g77->gfortran transition [14]. Pascal Dupuis has
already started to make the tests and things are looking good [15] [16].
However, we are still waiting for the gfortran-compiled atlas3 package
(stuck in the NEW queue [17]), which seem to be the last one we need,
besides suitesparse.
Mathias Klose has formally requested that both octave3.0 [18] and octave2.1
[19] use GCC 4.3 for lenny.
[13] http://lists.debian.org/debian-devel-announce/2008/01/msg00005.html
[14] http://wiki.debian.org/GfortranTransition
[15] http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2008-January/003044.html
[16] http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2008-January/003066.html
[17] http://ftp-master.debian.org/new/atlas_3.6.0-21.1.html
[18] http://bugs.debian.org/463302
[19] http://bugs.debian.org/463301
5. Improving debian/rules for the octave*.* packages
====================================================
The debian/rules for the current octave3.0 package was inherited from Dirk
Eddelbuetel, who bravely maintained the packages alone in the pre-DOG days.
The code in that file has become brittle with inconsistencies in several
places. I would love to switch to CDBS, like the other DOG packages, but
that seems complicated due to the separated arch-dependent/arch-independent
builds.
On the other hand, we have a complex system from maintaining several
branches of Octave from the same source. Although not particularly clean,
this system was essential during the octave2.1/octave2.9 period and will
still be the case when the new development branch octave3.1 will be
released.
If someone is willing to start a overhaul of the debian/* files for the
octave*.* packages, I will fully support the project, provided that no
current functionality is lost.
6. Packaging the octave-forge components through pkg.m
======================================================
The pkg.m system for automatic installation of "Octave packages" (in the
octave-forge sense) was introduced into Octave almost two years ago [20] and
all octave-forge components [21] are now using this system. This forced us
to drop octave2.9-forge from Debian [22].
Our users have now to resort to using pkg.m directly to install Octave
packages. Ideally, we should have each octave-forge component pcakged
individually for Debian. Despite several discussions in the
octave-maintainers [23] [24] [25] and pkg-octave-devel [26] mailing lists,
we have not reached consensus on how to proceed. We have even created a
page on wiki.debian.org [27] to summarize the issues, but this project is
stalled.
Anyway, Ólafur Jens Sigurðsson started committing some octave-forge packages
to our SVN repository [28]. This is still work in progress an lots of
things need to be done in this area.
[20] http://velveeta.che.wisc.edu/cgi-bin/cvsweb.cgi/octave/scripts/pkg/pkg.m#rev1.1
[21] http://octave.sourceforge.net/packages.html
[22] http://bugs.debian.org/440777
[23] http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-April/002558.html
[24] http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-May/002802.html
[25] http://www.cae.wisc.edu/pipermail/octave-maintainers/2007-May/002815.html
[26] http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2007-May/002349.html
[27] http://wiki.debian.org/OctavePackaging
[28] http://svn.debian.org/wsvn/pkg-octave/octave-forge-pkgs/?rev=0&sc=0
7. Other packages from the DOG
==============================
Apart the problems discussed above, the other DOG-maintained packages seem
to be in good shape. There is though an important issue related to GCC 4.3
in the semidef-oct package [29] that must be addressed. This will probably
involve the upstream authors of the package.
[29] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=semidef-oct
8. Coda
=======
Thanks for reading this (long) summary until here. We are clearly lacking
manpower to tackle all the open issues. In summary, "We want you for DOG".
--
Rafael
More information about the Pkg-octave-devel
mailing list