[Pkg-octave-devel] Octave-forge for 2.9

[Rafael Laboissiere]

* Thomas Weber <thomas.weber.mail at gmail.com> [2006-05-02 17:29]:

> those of you who are subscribed to the commit list have probably noticed
> that I just commited 'some' changes to to 2.9transition branch. 
> 
> It should be possible to build octave-forge against 2.9 with these
> changes.

Thanks Thomas, I really appreciate your efforts.

I just gave it a try here and the package builds smoothly in my unstable
chroot.  However, make check failed (BTW, shouldn't we set
DEB_MAKE_CHECK_TARGET in debian/rules?):

$ make check
[...]
passes 683 out of 720 tests
see fntests.log for details

admin/run_forge octave --norc -q batch_test.m
[main/comm]
>comms

<< Random Signals Package >>
  Signal Creation:                          panic: Segmentation fault -- stopping myself...
admin/run_forge: line 53: 21259 Segmentation fault      $*
make: *** [check] Error 139

> This is *not* a dual-built[1]. I had some talks with Rafael about it;
> upstream is cleaning up the sources and is already relying on some
> features only found in Octave 2.9. So I guess it's easier to just have
> two different packages with two different upstream sources.

I have not yet investigated the dual-build issue.  Although the idea does
not please me completely, you may be right when saying that it is easier
to have separate packages instead of a dual build.  However:

> However, the rules file is quite generic (and CDBS-based), so we
> probably can take most of it for an octave-forge2.1 package.

I think we should set up things such that there will be unique SVN
sources for both packages.  There must be a script, to be run after svn
checking out, which will create the files with the version-specific
informations like debian/control.

> @Rafael: The binary package name is still octave-forge2.9; you
> suggested octave2.9-forge. I don't mind the change, but thought it
> easier to just check-in a version and let other people try it out.

Yes, this is my preference, because "2.1" or "2.9" refers to "octave",
not to "forge".  I would like to know what the other developers think,
though.

> Do ftp-admins allow two different packages in the pool which
> (currently) have the same upstream -orig tarball?

This is a good question.  I do not know the answer and will try to figure
it out.

-- 
Rafael