octave-dev — GNU Octave developers' list

Re: [OctDev] 2006.01.28 fails with octave 2.9.4

[David B. <Dav...@mo...>]

pki...@co... wrote:

>
>  -------------- Original message ----------------------
> From: Quentin Spencer <qsp...@ie...>
> > Orion Poplawski wrote:
> >
> > >
> > > Get lots of:
> > >
> > > make[1]: Entering directory
> > > `/builddir/build/BUILD/octave-forge-2006.01.28/FIXES'
> > > mkoctfile -DHAVE_OCTAVE_29 -v -DALLBITS -DHAVE_ND_ARRAYS rand.cc
> > > rm -f randn.octlink
> > > /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh
> > > rand.oct randn.octlink
> > > make[1]:
> > > /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh:
> > > Command not foun
> > > d
> > > make[1]: *** [randn.octlink] Error 127
> > > rm -f rande.octlink
> > >
> > > Looks like a change to configure.base was checked in to use
> > > octlink.sh, but that octlink.sh was never checked in?
> > >
> >
> > I got it to build fine with 2.1.72, but I'm seeing this error as well
> > with 2.9.x, and haven't looked any further into it. This error has been
> > reported a couple of times by others in the last week or so. Can 
> someone
> > who understands what is going on explain this (or fix it)?
>
> Sorry, my fault.
>
> Octave 2.9.x has a new autoload feature to tell the interpreter to look
> for multiple functions in the same .oct file.  I believe the syntax is
> something like:
>
>     autoload('full/path/to/octfile.oct','name');
>
> On 2.1.72, octave-forge should be using "ln -s" as usual. 
>
> On 2.9.4 it should be using "octlink.sh basename.oct name.octlink"
> to create 'name.octlink' which contains:
>
>     autoload(which('basename'),'name');
>
> Before install, mkpkgadd concatenates all the octlink files to the end
> of PKG_ADD.
>
> I don't have octlink.sh available remotely, and it will be a few days
> yet before I'm home.  I think something like the following should
> work.  Be sure to 'chmod a+x admin/octlink.sh' after creating yet.
> Please let me know.
>
> admin/octlink.sh:
> #!/bin/sh
>
> BASE=`echo $1 | sed -e's/.oct$//'`
> NAME=`echo $2 | sed -e's/.octlink$//'`
> echo "autoload(which('$BASE'),'$NAME')" > $2
>
>     - Paul
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642> 
>
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Ok, I committed the fix to the CVS.. Now just new a new package for 
octave-forge... Sorry Paul.....

D.

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

Re: [OctDev] 2006.01.28 fails with octave 2.9.4

[David B. <Dav...@mo...>]

pki...@co... wrote:

>
>  -------------- Original message ----------------------
> From: Quentin Spencer <qsp...@ie...>
> > Orion Poplawski wrote:
> >
> > >
> > > Get lots of:
> > >
> > > make[1]: Entering directory
> > > `/builddir/build/BUILD/octave-forge-2006.01.28/FIXES'
> > > mkoctfile -DHAVE_OCTAVE_29 -v -DALLBITS -DHAVE_ND_ARRAYS rand.cc
> > > rm -f randn.octlink
> > > /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh
> > > rand.oct randn.octlink
> > > make[1]:
> > > /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh:
> > > Command not foun
> > > d
> > > make[1]: *** [randn.octlink] Error 127
> > > rm -f rande.octlink
> > >
> > > Looks like a change to configure.base was checked in to use
> > > octlink.sh, but that octlink.sh was never checked in?
> > >
> >
> > I got it to build fine with 2.1.72, but I'm seeing this error as well
> > with 2.9.x, and haven't looked any further into it. This error has been
> > reported a couple of times by others in the last week or so. Can 
> someone
> > who understands what is going on explain this (or fix it)?
>
> Sorry, my fault.
>
> Octave 2.9.x has a new autoload feature to tell the interpreter to look
> for multiple functions in the same .oct file.  I believe the syntax is
> something like:
>
>     autoload('full/path/to/octfile.oct','name');
>
> On 2.1.72, octave-forge should be using "ln -s" as usual. 
>
> On 2.9.4 it should be using "octlink.sh basename.oct name.octlink"
> to create 'name.octlink' which contains:
>
>     autoload(which('basename'),'name');
>
> Before install, mkpkgadd concatenates all the octlink files to the end
> of PKG_ADD.
>
> I don't have octlink.sh available remotely, and it will be a few days
> yet before I'm home.  I think something like the following should
> work.  Be sure to 'chmod a+x admin/octlink.sh' after creating yet.
> Please let me know.
>
> admin/octlink.sh:
> #!/bin/sh
>
> BASE=`echo $1 | sed -e's/.oct$//'`
> NAME=`echo $2 | sed -e's/.octlink$//'`
> echo "autoload(which('$BASE'),'$NAME')" > $2
>
>     - Paul
>
Damn, it my fault again... Ok, I'll check a copy of octlink.sh in today 
to the CVS... However, Paul can we have an update of 2006.01.28 to 
address this, as I was counting on using a 2006.01.28 release with a 
Mingw build...

D.

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

Re: [OctDev] 2006.01.28 fails with octave 2.9.4

[<pki...@co...>]

 -------------- Original message ----------------------
From: Quentin Spencer <qsp...@ie...>
> Orion Poplawski wrote:
> 
> >
> > Get lots of:
> >
> > make[1]: Entering directory 
> > `/builddir/build/BUILD/octave-forge-2006.01.28/FIXES'
> > mkoctfile -DHAVE_OCTAVE_29 -v -DALLBITS -DHAVE_ND_ARRAYS rand.cc
> > rm -f randn.octlink
> > /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh 
> > rand.oct randn.octlink
> > make[1]: 
> > /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh: 
> > Command not foun
> > d
> > make[1]: *** [randn.octlink] Error 127
> > rm -f rande.octlink
> >
> > Looks like a change to configure.base was checked in to use 
> > octlink.sh, but that octlink.sh was never checked in?
> >
> 
> I got it to build fine with 2.1.72, but I'm seeing this error as well 
> with 2.9.x, and haven't looked any further into it. This error has been 
> reported a couple of times by others in the last week or so. Can someone 
> who understands what is going on explain this (or fix it)?

Sorry, my fault.

Octave 2.9.x has a new autoload feature to tell the interpreter to look
for multiple functions in the same .oct file.  I believe the syntax is
something like:

    autoload('full/path/to/octfile.oct','name');

On 2.1.72, octave-forge should be using "ln -s" as usual.  

On 2.9.4 it should be using "octlink.sh basename.oct name.octlink" 
to create 'name.octlink' which contains:

    autoload(which('basename'),'name');

Before install, mkpkgadd concatenates all the octlink files to the end
of PKG_ADD.

I don't have octlink.sh available remotely, and it will be a few days
yet before I'm home.  I think something like the following should
work.  Be sure to 'chmod a+x admin/octlink.sh' after creating yet.
Please let me know.

admin/octlink.sh:
#!/bin/sh

BASE=`echo $1 | sed -e's/.oct$//'`
NAME=`echo $2 | sed -e's/.octlink$//'`
echo "autoload(which('$BASE'),'$NAME')" > $2

    - Paul

Re: [OctDev] 2006.01.28 fails with octave 2.9.4

[Quentin S. <qsp...@ie...>]

Orion Poplawski wrote:

>
> Get lots of:
>
> make[1]: Entering directory 
> `/builddir/build/BUILD/octave-forge-2006.01.28/FIXES'
> mkoctfile -DHAVE_OCTAVE_29 -v -DALLBITS -DHAVE_ND_ARRAYS rand.cc
> rm -f randn.octlink
> /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh 
> rand.oct randn.octlink
> make[1]: 
> /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh: 
> Command not foun
> d
> make[1]: *** [randn.octlink] Error 127
> rm -f rande.octlink
>
> Looks like a change to configure.base was checked in to use 
> octlink.sh, but that octlink.sh was never checked in?
>

I got it to build fine with 2.1.72, but I'm seeing this error as well 
with 2.9.x, and haven't looked any further into it. This error has been 
reported a couple of times by others in the last week or so. Can someone 
who understands what is going on explain this (or fix it)?

-Quentin

[OctDev] 2006.01.28 fails with octave 2.9.4

[Orion P. <or...@co...>]

Get lots of:

make[1]: Entering directory 
`/builddir/build/BUILD/octave-forge-2006.01.28/FIXES'
mkoctfile -DHAVE_OCTAVE_29 -v -DALLBITS -DHAVE_ND_ARRAYS rand.cc
rm -f randn.octlink
/builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh rand.oct 
randn.octlink
make[1]: /builddir/build/BUILD/octave-forge-2006.01.28/admin/octlink.sh: 
Command not foun
d
make[1]: *** [randn.octlink] Error 127
rm -f rande.octlink

Looks like a change to configure.base was checked in to use octlink.sh, 
but that octlink.sh was never checked in?

-- 
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301   http://www.co-ra.com

Re: [OctDev] branch and purge

[H. <so...@ha...>]

man, 30 01 2006 kl. 17:08 +0000, skrev pki...@co...:
> > Waiting of John to include the packaging manager in the CVS...
>=20
> I believe this exercise will be good for refining the package
> manager, so it should be done sooner rather than later.
Agreed.

> Does the package manager change any core Octave=20
> functions, or can it be installed independently?
No.

> - Paul
/S=C3=B8ren (who's currently busy with school, but will look into Octave
stuff very soon)

Re: [OctDev] branch and purge

[<pki...@co...>]

 -------------- Original message ----------------------
From: David Bateman <Dav...@mo...>
> Paul Kienzle wrote:
> 
> > With the final 2.1.x release of octave-forge, we are
> > ready to make a 2.1.x branch and purge the trunk of
> > support for 2.1 series octave.  Can someone with
> > familiarity with CVS please perform the branch
> > operation on tag R2006-01-28.
> >
> Shouldn't the branch be for the 2.1.x releases as they are considered 
> secondary. I'd say the main branch should be kept for 2.9.x developments 
> as that is the future. That being the case, we can always create a 2.1.x 
> branch from the R2006-01-28 tag at any time, if we feel there is a need 
> for a bug fix for the 2.1.x releases of octave-forge.
> 
> Therefore, I'd suggest just purging stuff without a branch.

I think we are saying the same thing.  The main line 2.9.x stuff should 
be on the trunk.  There should be a 2.1.x branch off the R2006-01-28 tag 
for support purposes.  I don't know if the branch needs to be created
now, or if it can be created later when needed.

> 
> > For purge, we do not need to support earlier than
> > 2.9.4.  Feel free to remove #ifdef's for older
> > versions from your code.  Similarly, m-files can
> > assume octave 2.9.x syntax and libraries.
> >
> Maybe there is a means of doing these semi-automatically at least for 
> the *.cc files. That is we might use a hand editted Makeconf from a 
> 2.9.4 build to create a list of basic defines, and using that with a 
> perl script to search all of the .h and .cc files and remove the 
> irrelevant clauses. This should make the first purge fairly easy, though 
> care will have to be taken to keep necessary ifdef's for architecture, 
> and installed library dependent stuff. Things like
> 
> #ifdef DEFINE1
> #ifdef DEFINE2
> ....
> #endif
> #else
> ...
> #endif
> 
> might cause problems as well, but should be possible to work around with 
> a well crafted perl script. The harder things to purge are things like
> 
>   try ar = automatic_replot;
>   catch ar = 0;
>   end
> 
>   unwind_protect
>     ...
>   unwind_protect_cleanup
>     automatic_replot = ar;
>   end_unwind_protect
> 
> which appear in a number if .m files to handle various versions of 
> octave's built-in variables. I think this is going to be a gradual process..

Maybe it would be worthwhile for some of these:

  grep -rh "^#if" octave-forge | sort | uniq -c | sort | tail -23

> 
> > This would be an excellent time to redo the build
> > system so that it is a set of independent packages.
> > Any bits of common configuration information should
> > be added to Octave.  Volunteers needed.
> >
> Waiting of John to include the packaging manager in the CVS...

I believe this exercise will be good for refining the package
manager, so it should be done sooner rather than later.

Does the package manager change any core Octave 
functions, or can it be installed independently?

- Paul

Re: [OctDev] branch and purge

[David B. <Dav...@mo...>]

Paul Kienzle wrote:

> With the final 2.1.x release of octave-forge, we are
> ready to make a 2.1.x branch and purge the trunk of
> support for 2.1 series octave.  Can someone with
> familiarity with CVS please perform the branch
> operation on tag R2006-01-28.
>
Shouldn't the branch be for the 2.1.x releases as they are considered 
secondary. I'd say the main branch should be kept for 2.9.x developments 
as that is the future. That being the case, we can always create a 2.1.x 
branch from the R2006-01-28 tag at any time, if we feel there is a need 
for a bug fix for the 2.1.x releases of octave-forge.

Therefore, I'd suggest just purging stuff without a branch.

> For purge, we do not need to support earlier than
> 2.9.4.  Feel free to remove #ifdef's for older
> versions from your code.  Similarly, m-files can
> assume octave 2.9.x syntax and libraries.
>
Maybe there is a means of doing these semi-automatically at least for 
the *.cc files. That is we might use a hand editted Makeconf from a 
2.9.4 build to create a list of basic defines, and using that with a 
perl script to search all of the .h and .cc files and remove the 
irrelevant clauses. This should make the first purge fairly easy, though 
care will have to be taken to keep necessary ifdef's for architecture, 
and installed library dependent stuff. Things like

#ifdef DEFINE1
#ifdef DEFINE2
....
#endif
#else
...
#endif

might cause problems as well, but should be possible to work around with 
a well crafted perl script. The harder things to purge are things like

  try ar = automatic_replot;
  catch ar = 0;
  end

  unwind_protect
    ...
  unwind_protect_cleanup
    automatic_replot = ar;
  end_unwind_protect

which appear in a number if .m files to handle various versions of 
octave's built-in variables. I think this is going to be a gradual process..

> This would be an excellent time to redo the build
> system so that it is a set of independent packages.
> Any bits of common configuration information should
> be added to Octave.  Volunteers needed.
>
Waiting of John to include the packaging manager in the CVS...

D.

-- 
David Bateman                                Dav...@mo...
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

[OctDev] branch and purge

[Paul K. <pki...@us...>]

With the final 2.1.x release of octave-forge, we are
ready to make a 2.1.x branch and purge the trunk of
support for 2.1 series octave.  Can someone with
familiarity with CVS please perform the branch
operation on tag R2006-01-28.

For purge, we do not need to support earlier than
2.9.4.  Feel free to remove #ifdef's for older
versions from your code.  Similarly, m-files can
assume octave 2.9.x syntax and libraries.

This would be an excellent time to redo the build
system so that it is a set of independent packages.
Any bits of common configuration information should
be added to Octave.  Volunteers needed.

Thanks,

	- Paul

Re: [OctDev] Building Octave-Forge with octave-2.9.4

[Quentin S. <qsp...@ie...>]

Colin Ingram wrote:

>[sorry for the noise in the mailling list...my previous msg had my CC
>as the subject and the subject was....well I don't know where it went]
>
>I started working on the 2.9 transition again.  Octave-Forge fails to
>build on my system.  I attemted to build with these changes to
>debian/rules
>
>Index: rules
>===================================================================
>--- rules    (revision 466)
>+++ rules    (working copy)
>@@ -6,25 +6,25 @@
> PACKAGE        = octave-forge
>
> include /usr/share/dpatch/dpatch.make
> include /usr/share/octave/debian/defs.make
>
> altname         = octave-forge-alternatives
> debtmp        := $(CURDIR)/debian/$(PACKAGE)
> debdoc          := $(debtmp)/usr/share/doc/$(PACKAGE)
> octdir      := $(OCTDIR)
> mdir          := $(MDIR)
> altoctdir       := /usr/lib/$(altname)
> altmdir         := /usr/share/$(altname)
>-octbin        := $(shell octave-config-2.1.72 -p LOCALARCHLIBDIR)
>+octbin        := $(shell octave-config-2.9.4 -p LOCALARCHLIBDIR)
>
> mycheck:
>        @echo "debtmp $(debtmp)"
>        @echo "debdic $(debdoc)"
>        @echo "otdir  $(octdir)"
>        @echo "mdir   $(mdir)"
>        @echo "octbin $(octbin)"
>
> arch         := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
>
> ## edd 22 Feb 2003 now use 3.2 versions everywhere
> ## edd 27 Jun 2003  now that gcc 3.3 is in unstable and testing, relax this
>@@ -56,24 +56,26 @@
> configure-stamp: patch-stamp
>        dh_testdir
>        mv configure configure-orig
>        touch extra/MacOSX/NOINSTALL
>        [ -f autogen.sh ] && ./autogen.sh && chmod 0755 configure
>        CC=$(compilerpath)            \
>        CXX=$(cpppath)                \
>        FC=$(fcpath)                \
>        F77=$(fcpath)                \
>        CFLAGS=$(compilerflags)            \
>        CXXFLAGS=$(compilerflags)        \
>        FFLAGS=$(compilerflags)            \
>+        OCTAVE="octave-2.9.4"            \
>+        MKOCTFILE="mkoctfile-2.9.4"        \
>        ./configure --prefix=/usr --with-altmpath=$(altmdir)
>                # clean the tsa/ directory
>                # ( cd extra/tsa && ../../debian/tsacleanup.pl )
>        touch configure-stamp
>
> build:         configure-stamp build-stamp
> build-stamp:
>        $(MAKE)
>                # $(MAKE) index.html
>        touch build-stamp
>
> install:     install-stamp
>@@ -87,25 +89,25 @@
>                OPATH=$(debtmp)/$(octdir)/$(PACKAGE)     \
>                XPATH=$(debtmp)/$(octbin)        \
>                ALTMPATH=$(debtmp)/$(altmdir)           \
>                ALTOPATH=$(debtmp)/$(altoctdir)         \
>                prefix=$(debtmp)/usr            \
>                mandir=$(debtmp)/usr/share/man
>        rm -vf $(debtmp)/rasmol.sh
>        touch install-stamp
>
> check:        check-stamp
> check-stamp:
>        dh_testdir
>-        -$(MAKE) check     OCTAVE=octave2.1
>+        -$(MAKE) check     OCTAVE=octave-2.9.4
>        touch check-stamp
>
> clean: unpatch
>        dh_testdir
>        dh_testroot
>        -test -f configure-orig && mv configure-orig configure
>        rm -f configure-stamp build-stamp install-stamp check-stamp
>        -test -f Makefile && $(MAKE) clean
>        -rm -rf *~ $(debtmp) debian/*~ debian/files* build    \
>            config.status config.cache config.log conftest    \
>            extra/symband/*.oct build.log            \
>            main/fixed/doc/fixed.ps             \
>
>
>with the command:
>
># touch main/sparse/NOINSTALL && debuild -us -uc -i.
>
>It looks like there is a problem with fixedNDArray (full log at
>http://webpages.charter.net/synergymusic/octave-forge_2005.06.13-11_amd64.build)
>
>
> Compiling fixedNDArray.o
> /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.9.4
>-I/usr/include/octave-2.9.4/octave -O2 -DHAVE_OCTAVE_29 -DOCTAVE_FORGE
>-DHAVE_ND_ARRAYS -DTYPEID_HAS_CLASS -DCLASS_HAS_LOAD_SAVE
>-DHAVE_OCTAVE_CONCAT -DHAVE_SWAP_BYTES -DHAVE_OCTAVE_UPLUS
>fixedNDArray.cc -o fixedNDArray.o
> fixedNDArray.cc:407:59: error: macro "MX_ND_REDUCTION" passed 5
>arguments, but takes just 3
> fixedNDArray.cc:421:61: error: macro "MX_ND_REDUCTION" passed 5
>arguments, but takes just 3
> fixedNDArray.cc:436:61: error: macro "MX_ND_REDUCTION" passed 5
>arguments, but takes just 3
> fixedNDArray.cc: In member function 'FixedNDArray
>FixedNDArray::prod(int) const':
> fixedNDArray.cc:406: error: 'MX_ND_REDUCTION' was not declared in this scope
> fixedNDArray.cc: In member function 'FixedNDArray
>FixedNDArray::sum(int) const':
> fixedNDArray.cc:420: error: 'MX_ND_REDUCTION' was not declared in this scope
> fixedNDArray.cc: In member function 'FixedNDArray
>FixedNDArray::sumsq(int) const':
> fixedNDArray.cc:434: error: 'MX_ND_REDUCTION' was not declared in this scope
> make[3]: *** [fixedNDArray.o] Error 1
>
>---snip--
>
>make[3]: Leaving directory
>`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/main/symbolic'
>make[2]: Target `all' not remade because of errors.
>make[2]: Leaving directory
>`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/main'
>Processing nonfree/
>cd nonfree/ && /usr/bin/make -k  2>&1 || \
>          echo "nonfree/ not complete. See log for details" >>../build.fail \
>       | tee -a build.log
>make[2]: Entering directory
>`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/nonfree'
>make[2]: Nothing to be done for `all'.
>make[2]: Leaving directory
>`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/nonfree'
>Build finished.
>Please read FIXES/README before you install.
>main/ not complete. See log for details
>make[1]: *** [all] Error 1
>make[1]: Leaving directory
>`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13'
>make: *** [build-stamp] Error 2
>
>
> any suggestions?
>  
>

The 2005.06.13 release doesn't build with newer octave 2.9.x releases. 
This has been fixed in CVS. You can try to make a release based on CVS 
or wait for a new release. I'm maintaining Octave-forge in Fedora, and 
I've been tempted to release a CVS-based package, but for now I'm 
waiting in hopes that a new release is soon.

-Quentin

[OctDev] Building Octave-Forge with octave-2.9.4

[Colin I. <syn...@gm...>]

[sorry for the noise in the mailling list...my previous msg had my CC
as the subject and the subject was....well I don't know where it went]

I started working on the 2.9 transition again.  Octave-Forge fails to
build on my system.  I attemted to build with these changes to
debian/rules

Index: rules
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- rules    (revision 466)
+++ rules    (working copy)
@@ -6,25 +6,25 @@
 PACKAGE        =3D octave-forge

 include /usr/share/dpatch/dpatch.make
 include /usr/share/octave/debian/defs.make

 altname         =3D octave-forge-alternatives
 debtmp        :=3D $(CURDIR)/debian/$(PACKAGE)
 debdoc          :=3D $(debtmp)/usr/share/doc/$(PACKAGE)
 octdir      :=3D $(OCTDIR)
 mdir          :=3D $(MDIR)
 altoctdir       :=3D /usr/lib/$(altname)
 altmdir         :=3D /usr/share/$(altname)
-octbin        :=3D $(shell octave-config-2.1.72 -p LOCALARCHLIBDIR)
+octbin        :=3D $(shell octave-config-2.9.4 -p LOCALARCHLIBDIR)

 mycheck:
        @echo "debtmp $(debtmp)"
        @echo "debdic $(debdoc)"
        @echo "otdir  $(octdir)"
        @echo "mdir   $(mdir)"
        @echo "octbin $(octbin)"

 arch         :=3D $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

 ## edd 22 Feb 2003 now use 3.2 versions everywhere
 ## edd 27 Jun 2003  now that gcc 3.3 is in unstable and testing, relax thi=
s
@@ -56,24 +56,26 @@
 configure-stamp: patch-stamp
        dh_testdir
        mv configure configure-orig
        touch extra/MacOSX/NOINSTALL
        [ -f autogen.sh ] && ./autogen.sh && chmod 0755 configure
        CC=3D$(compilerpath)            \
        CXX=3D$(cpppath)                \
        FC=3D$(fcpath)                \
        F77=3D$(fcpath)                \
        CFLAGS=3D$(compilerflags)            \
        CXXFLAGS=3D$(compilerflags)        \
        FFLAGS=3D$(compilerflags)            \
+        OCTAVE=3D"octave-2.9.4"            \
+        MKOCTFILE=3D"mkoctfile-2.9.4"        \
        ./configure --prefix=3D/usr --with-altmpath=3D$(altmdir)
                # clean the tsa/ directory
                # ( cd extra/tsa && ../../debian/tsacleanup.pl )
        touch configure-stamp

 build:         configure-stamp build-stamp
 build-stamp:
        $(MAKE)
                # $(MAKE) index.html
        touch build-stamp

 install:     install-stamp
@@ -87,25 +89,25 @@
                OPATH=3D$(debtmp)/$(octdir)/$(PACKAGE)     \
                XPATH=3D$(debtmp)/$(octbin)        \
                ALTMPATH=3D$(debtmp)/$(altmdir)           \
                ALTOPATH=3D$(debtmp)/$(altoctdir)         \
                prefix=3D$(debtmp)/usr            \
                mandir=3D$(debtmp)/usr/share/man
        rm -vf $(debtmp)/rasmol.sh
        touch install-stamp

 check:        check-stamp
 check-stamp:
        dh_testdir
-        -$(MAKE) check     OCTAVE=3Doctave2.1
+        -$(MAKE) check     OCTAVE=3Doctave-2.9.4
        touch check-stamp

 clean: unpatch
        dh_testdir
        dh_testroot
        -test -f configure-orig && mv configure-orig configure
        rm -f configure-stamp build-stamp install-stamp check-stamp
        -test -f Makefile && $(MAKE) clean
        -rm -rf *~ $(debtmp) debian/*~ debian/files* build    \
            config.status config.cache config.log conftest    \
            extra/symband/*.oct build.log            \
            main/fixed/doc/fixed.ps             \


with the command:

# touch main/sparse/NOINSTALL && debuild -us -uc -i.

It looks like there is a problem with fixedNDArray (full log at
http://webpages.charter.net/synergymusic/octave-forge_2005.06.13-11_amd64.b=
uild)


 Compiling fixedNDArray.o
 /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.9.4
-I/usr/include/octave-2.9.4/octave -O2 -DHAVE_OCTAVE_29 -DOCTAVE_FORGE
-DHAVE_ND_ARRAYS -DTYPEID_HAS_CLASS -DCLASS_HAS_LOAD_SAVE
-DHAVE_OCTAVE_CONCAT -DHAVE_SWAP_BYTES -DHAVE_OCTAVE_UPLUS
fixedNDArray.cc -o fixedNDArray.o
 fixedNDArray.cc:407:59: error: macro "MX_ND_REDUCTION" passed 5
arguments, but takes just 3
 fixedNDArray.cc:421:61: error: macro "MX_ND_REDUCTION" passed 5
arguments, but takes just 3
 fixedNDArray.cc:436:61: error: macro "MX_ND_REDUCTION" passed 5
arguments, but takes just 3
 fixedNDArray.cc: In member function 'FixedNDArray
FixedNDArray::prod(int) const':
 fixedNDArray.cc:406: error: 'MX_ND_REDUCTION' was not declared in this sco=
pe
 fixedNDArray.cc: In member function 'FixedNDArray
FixedNDArray::sum(int) const':
 fixedNDArray.cc:420: error: 'MX_ND_REDUCTION' was not declared in this sco=
pe
 fixedNDArray.cc: In member function 'FixedNDArray
FixedNDArray::sumsq(int) const':
 fixedNDArray.cc:434: error: 'MX_ND_REDUCTION' was not declared in this sco=
pe
 make[3]: *** [fixedNDArray.o] Error 1

---snip--

make[3]: Leaving directory
`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/main/=
symbolic'
make[2]: Target `all' not remade because of errors.
make[2]: Leaving directory
`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/main'
Processing nonfree/
cd nonfree/ && /usr/bin/make -k  2>&1 || \
          echo "nonfree/ not complete. See log for details" >>../build.fail=
 \
       | tee -a build.log
make[2]: Entering directory
`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/nonfr=
ee'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13/nonfr=
ee'
Build finished.
Please read FIXES/README before you install.
main/ not complete. See log for details
make[1]: *** [all] Error 1
make[1]: Leaving directory
`/home/colin/data/debian/octave/2.9transition/octave-forge-2005.06.13'
make: *** [build-stamp] Error 2


 any suggestions?

[OctDev] Re: Octave Wiki

[Steve C. T. <sc...@uc...>]

Hi,

Please unblock my home IP, also:

Editing not allowed for 67.121.209.131 /
adsl-67-121-209-131.dsl.sndg02.pacbell.net: user, ip, or network
is blocked.

Thanks,
Steve

On 12 Jan 06 08:50AM, Steve C. Thompson wrote:
> Hi, 
> 
> Please unblock me.  Below is what wiki.octave.org has displayed
> in my browser:
> 
> Editing not allowed for 137.110.118.180 /
> dyn137-110-118-180.ucsd.edu: user, ip, or network is blocked.
> 
> Thanks in advance.
> 
> Steve Thompson

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[William P. Y. H. <wil...@gm...>]

On 1/14/06, Laurent Mazet <lau...@mo...> wrote:
>
> First, I found a bug on 1D cell argument (file attached). I will update t=
he
> octave-forge version as soon I managed to boot again my own coputer (HD
> controler broken :-( )
>

David Bateman says this is a bug fixed in 2.9.x :)

> Seconldy, I read the code you added for dimension and type checking but I=
 don't
> think it's efficient for a such function. This type of function has to be=
en run
> as fast as possible and usualy no-ones care of the error message (except
> during the debugging process). From my point of view, cell2mat don't have=
 to
> waste time on input checking.
>

Well, OK, since cat will let us know if there's a problem. Would you
like to submit the patch to bug-octave? I'm on a trip, so I might not
be able to post a fix until this weekend.

--
William Poetra Yoga Hadisoeseno

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[Etienne G. <et...@cs...>]

  Hello,

both cell2mat({1, 2, 3}) and cell2mat({1; 2; 3}) fail w/ 2.9.3.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
octave:12> cell2mat({1; 2; 3})

*** cat:

 -- Built-in Function:  cat (DIM, ARRAY1, ARRAY2, ..., ARRAYN)
     Return the concatenation of N-d array objects, ARRAY1, ARRAY2,
     ..., ARRAYN along dimension DIM.

[snip]

   See also: horzcat and vertcat.

error: evaluating assignment expression near line 65, column 14
error: evaluating for command near line 64, column 5
error: evaluating for command near line 60, column 3
error: called from `cell2mat'in file
`/home/etienne/prog/octave/octave-forge/octave-forge/main/cell/cell2mat.m=
'

octave:12> cell2mat({1, 2, 3})

*** cat:

 -- Built-in Function:  cat (DIM, ARRAY1, ARRAY2, ..., ARRAYN)
     Return the concatenation of N-d array objects, ARRAY1, ARRAY2,
     ..., ARRAYN along dimension DIM.

[snip]

error: evaluating assignment expression near line 69, column 5
error: called from `cell2mat'in file
`/home/etienne/prog/octave=F8ctave-forge/octave-forge/main/cell/cell2mat.=
m'
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

  version is 2.9.3, home-compiled. More info needed?

  Hth,

  Etienne


On Sat, Jan 14, 2006 at 12:57:57AM -0500, Paul Kienzle wrote:
# Laurent,
#=20
# I applied your fix to octave-forge.
#=20
# Someone with a working 2.9.x will have to check if the fix is needed
# there as well.  Here's the test:
#=20
#   assert (cell2mat({1, 2, 3}), [1, 2, 3]);
#   assert (cell2mat({1; 2; 3}), [1; 2; 3]);
#=20
# See attached for Laurent's fix as a patch to the current octave CVS.
#=20
# 	* general/cell2mat.m: support 1D cell argument.
#=20
# - Paul
#=20
# On Jan 13, 2006, at 12:16 PM, Laurent Mazet wrote:
#=20
# >On Thu, 8 Dec 2005 21:31:56 +0800
# >William Poetra Yoga Hadisoeseno <wil...@gm...> wrote:
# >...
# >
# >Hi,
# >
# >Sorry I'm late to comment the post.
# >
# >First, I found a bug on 1D cell argument (file attached). I will=20
# >update the
# >octave-forge version as soon I managed to boot again my own coputer (H=
D
# >controler broken :-( )
# >
# >Seconldy, I read the code you added for dimension and type checking=20
# >but I don't
# >think it's efficient for a such function. This type of function has to=
=20
# >been run
# >as fast as possible and usualy no-ones care of the error message=20
# >(except
# >during the debugging process). From my point of view, cell2mat don't=20
# >have to
# >waste time on input checking.
# >
# >       Laurent
# >--=20
# >Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de=20
# >MOTOROLA
# >Tel: +33 1 69 35 48 30 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Email:=20
# >lau...@mo...
# ><cell2mat.m>
#=20
#=20



--=20
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] Re: new release

[Quentin S. <qsp...@ie...>]

Paul Kienzle wrote:

>
> On Jan 13, 2006, at 11:12 AM, Stefan van der Walt wrote:
>
>> On Thu, Jan 12, 2006 at 07:42:27PM -0500, John W. Eaton wrote:
>>
>>> On 12-Jan-2006, Paul Kienzle wrote:
>>>
>>> | Do you just need gcvsplf.f excluded, with a note to download it from
>>> | netlib?
>>>
>>> According to the FSF, "user does the link" still amounts to a
>>> violation of the GPL.
>>
>>
>> Not sure what you are trying to say, but it doesn't make sense to me.
>> Octave forge does not build binaries that are illegal to distribute.
>> If the user links such binaries and distributes them outside the
>> license, then that would be wrong.  But it is perfectly acceptable to
>> distribute source code that could be linked to a commercial library
>> under the GPL, right?
>
>
> That has not yet been decided.
>
> If you search for "user does the link" or "indirect infringement"
> you get a lot of claims that the FSF believes this to be a violation
> of the GPL.  However a google search for either of these terms with
> site:www.gnu.org does not produce any hits.
>
> The best I can come up with is the following GPL FAQ:
>
>     http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
>
> which suggests that the license should be interpreted as a matter of
> intent rather than of specific technology.  Under this interpretation,
> even communication via RFC 1149 - Standard for the transmission of IP
> datagrams on avian carriers - between octave and the non-free subroutine
> would be a violation.
>
> Even if "user does the link" is legal, I encourage anyone who finds
> the algorithm useful to produce an unencumbered version of it.  I
> found the sensitivity of the result to the particular choice of
> smoothing parameter to be too subjective for my purposes so I have
> no desire to do so myself.


Actually, the original question that brought this up was so much about 
linking GPL and non-GPL code (there are plenty of different licenses in 
octave-forge), but the non-commercial distribution clause. The Fedora 
project does not want any packages that forbid commercial distribution 
because they would cause problems if a 3rd party wanted to burn CDs of 
Fedora and sell them, for example. Then there is the whole separate 
question of what constitutes non-commercial use...

-Quentin

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[Paul K. <pki...@us...>]

Laurent,

I applied your fix to octave-forge.

Someone with a working 2.9.x will have to check if the fix is needed
there as well.  Here's the test:

   assert (cell2mat({1, 2, 3}), [1, 2, 3]);
   assert (cell2mat({1; 2; 3}), [1; 2; 3]);

See attached for Laurent's fix as a patch to the current octave CVS.

	* general/cell2mat.m: support 1D cell argument.

- Paul

On Jan 13, 2006, at 12:16 PM, Laurent Mazet wrote:

> On Thu, 8 Dec 2005 21:31:56 +0800
> William Poetra Yoga Hadisoeseno <wil...@gm...> wrote:
> ...
>
> Hi,
>
> Sorry I'm late to comment the post.
>
> First, I found a bug on 1D cell argument (file attached). I will 
> update the
> octave-forge version as soon I managed to boot again my own coputer (HD
> controler broken :-( )
>
> Seconldy, I read the code you added for dimension and type checking 
> but I don't
> think it's efficient for a such function. This type of function has to 
> been run
> as fast as possible and usualy no-ones care of the error message 
> (except
> during the debugging process). From my point of view, cell2mat don't 
> have to
> waste time on input checking.
>
>        Laurent
> -- 
> Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de 
> MOTOROLA
> Tel: +33 1 69 35 48 30 =-=-=-=-=-=-=-= Email: 
> lau...@mo...
> <cell2mat.m>

Re: [OctDev] Re: new release

[Paul K. <pki...@us...>]

On Jan 13, 2006, at 11:12 AM, Stefan van der Walt wrote:

> On Thu, Jan 12, 2006 at 07:42:27PM -0500, John W. Eaton wrote:
>> On 12-Jan-2006, Paul Kienzle wrote:
>>
>> | Do you just need gcvsplf.f excluded, with a note to download it from
>> | netlib?
>>
>> According to the FSF, "user does the link" still amounts to a
>> violation of the GPL.
>
> Not sure what you are trying to say, but it doesn't make sense to me.
> Octave forge does not build binaries that are illegal to distribute.
> If the user links such binaries and distributes them outside the
> license, then that would be wrong.  But it is perfectly acceptable to
> distribute source code that could be linked to a commercial library
> under the GPL, right?

That has not yet been decided.

If you search for "user does the link" or "indirect infringement"
you get a lot of claims that the FSF believes this to be a violation
of the GPL.  However a google search for either of these terms with
site:www.gnu.org does not produce any hits.

The best I can come up with is the following GPL FAQ:

	http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

which suggests that the license should be interpreted as a matter of
intent rather than of specific technology.  Under this interpretation,
even communication via RFC 1149 - Standard for the transmission of IP
datagrams on avian carriers - between octave and the non-free subroutine
would be a violation.

Even if "user does the link" is legal, I encourage anyone who finds
the algorithm useful to produce an unencumbered version of it.  I
found the sensitivity of the result to the particular choice of
smoothing parameter to be too subjective for my purposes so I have
no desire to do so myself.

- Paul

Re: [OctDev] Proposed changes to cell2mat and inclusion in Octave

[Laurent M. <lau...@mo...>]

On Thu, 8 Dec 2005 21:31:56 +0800
William Poetra Yoga Hadisoeseno <wil...@gm...> wrote:
...

Hi,

Sorry I'm late to comment the post.

First, I found a bug on 1D cell argument (file attached). I will update the
octave-forge version as soon I managed to boot again my own coputer (HD
controler broken :-( )

Seconldy, I read the code you added for dimension and type checking but I don't
think it's efficient for a such function. This type of function has to been run
as fast as possible and usualy no-ones care of the error message (except
during the debugging process). From my point of view, cell2mat don't have to
waste time on input checking.

       Laurent
-- 
Dr. Laurent Mazet: Research Engineer /V\ Centre de Recherche de MOTOROLA
Tel: +33 1 69 35 48 30 =-=-=-=-=-=-=-= Email: lau...@mo...

Re: [OctDev] Re: new release

[Stefan v. d. W. <st...@su...>]

On Thu, Jan 12, 2006 at 07:42:27PM -0500, John W. Eaton wrote:
> On 12-Jan-2006, Paul Kienzle wrote:
>=20
> | Do you just need gcvsplf.f excluded, with a note to download it from=20
> | netlib?
>=20
> According to the FSF, "user does the link" still amounts to a
> violation of the GPL.

Not sure what you are trying to say, but it doesn't make sense to me.
Octave forge does not build binaries that are illegal to distribute.
If the user links such binaries and distributes them outside the
license, then that would be wrong.  But it is perfectly acceptable to
distribute source code that could be linked to a commercial library
under the GPL, right?

Regards
St=E9fan

Re: [OctDev] Re: new release

[John W. E. <jw...@be...>]

On 12-Jan-2006, Paul Kienzle wrote:

| Do you just need gcvsplf.f excluded, with a note to download it from 
| netlib?

According to the FSF, "user does the link" still amounts to a
violation of the GPL.

jwe

Re: [OctDev] Re: new release

[Paul K. <pki...@us...>]

On Jan 12, 2006, at 9:22 AM, Quentin Spencer wrote:

> John W. Eaton wrote:
>
>> On 29-Dec-2005, David Bateman wrote:
>>
>> | > I think decrufting and supporting older versions of octave at the 
>> same | > time is not practical, so I'm arguing for a clean break.
>>
>> Sorry, I was traveling for a week, then out of commission with some
>> flu-like thing, then traveling again.  I have a backlog of patches
>> (including the code for the package system) that I will try to work
>> through as soon as possible.
>>
>
> While we're still discussing a new release sometime soon, I'd like to 
> repeat a request I made a while ago. Can we remove the nonfree 
> directory from octave-forge and make it a separate package? Even 
> though it's not installed by default, I am required to use a modified 
> version of the source package to comply with Fedora Extras policies. 
> When I brought this up before, I believe the Debian maintainer said 
> they should technically be doing the same thing as well.

The source included in the octave-forge/nonfree is free.

The file splines/gcvsplf.f has a non-commercial clause, but the rest 
are GPL or public domain.

The resulting oct-files cannot be redistributed under the terms of the 
GPL which is why they are not built.

Do you just need gcvsplf.f excluded, with a note to download it from 
netlib?

- Paul

Re: [OctDev] Octave Wiki

[Etienne G. <et...@cs...>]

  Hi Steve,

welcome amongst the Octave Wiki contributers! You should now be
allowed to edit the wiki. Please let me know whether you can edit as
you like.

  Cheers and thanks for your input,

  Etienne

On Thu, Jan 12, 2006 at 08:50:06AM -0800, Steve C. Thompson wrote:
# Hi, 
# 
# Please unblock me.  Below is what wiki.octave.org has displayed
# in my browser:
# 
# Editing not allowed for 137.110.118.180 /
# dyn137-110-118-180.ucsd.edu: user, ip, or network is blocked.
# 
# Thanks in advance.
# 
# Steve Thompson
# 
# 
# -------------------------------------------------------
# This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
# for problems?  Stop!  Download the new AJAX search engine that makes
# searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
# http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] Re: new release

[Quentin S. <qsp...@ie...>]

David Bateman wrote:

> Quentin Spencer a écrit :
>
>> John W. Eaton wrote:
>>
>> >On 29-Dec-2005, David Bateman wrote:
>> >
>> >| > I think decrufting and supporting older versions of octave at 
>> the same
>> >| > time is not practical, so I'm arguing for a clean break.
>> >
>> >Sorry, I was traveling for a week, then out of commission with some
>> >flu-like thing, then traveling again.  I have a backlog of patches
>> >(including the code for the package system) that I will try to work
>> >through as soon as possible.
>> > >
>>
>> While we're still discussing a new release sometime soon, I'd like to
>> repeat a request I made a while ago. Can we remove the nonfree directory
>> from octave-forge and make it a separate package? Even though it's not
>> installed by default, I am required to use a modified version of the
>> source package to comply with Fedora Extras policies. When I brought
>> this up before, I believe the Debian maintainer said they should
>> technically be doing the same thing as well.
>>
>> -Quentin
>>
> Quentin,
>
> Can you live with it for one more release? If so John has indicated 
> that he is currently incorporating Soren's package manager into 2.9.x 
> and if octave-forge then becomes a purely 2.9.x affair, excluding 
> non-free will become trivial..


Yes, it's really not too much trouble, just a little annoyance.

-Quentin

Re: [OctDev] Re: new release

[David B. <Dav...@mo...>]

Quentin Spencer a =E9crit :

> John W. Eaton wrote:
>
> >On 29-Dec-2005, David Bateman wrote:
> >
> >| > I think decrufting and supporting older versions of octave at the=20
> same
> >| > time is not practical, so I'm arguing for a clean break.
> >
> >Sorry, I was traveling for a week, then out of commission with some
> >flu-like thing, then traveling again.  I have a backlog of patches
> >(including the code for the package system) that I will try to work
> >through as soon as possible.
> >=20
> >
>
> While we're still discussing a new release sometime soon, I'd like to
> repeat a request I made a while ago. Can we remove the nonfree director=
y
> from octave-forge and make it a separate package? Even though it's not
> installed by default, I am required to use a modified version of the
> source package to comply with Fedora Extras policies. When I brought
> this up before, I believe the Debian maintainer said they should
> technically be doing the same thing as well.
>
> -Quentin
>
Quentin,

Can you live with it for one more release? If so John has indicated that=20
he is currently incorporating Soren's package manager into 2.9.x and if=20
octave-forge then becomes a purely 2.9.x affair, excluding non-free will=20
become trivial..

Regards
David

[OctDev] Octave Wiki

[Steve C. T. <sc...@uc...>]

Hi, 

Please unblock me.  Below is what wiki.octave.org has displayed
in my browser:

Editing not allowed for 137.110.118.180 /
dyn137-110-118-180.ucsd.edu: user, ip, or network is blocked.

Thanks in advance.

Steve Thompson