|
From: H. <so...@ha...> - 2006-08-21 12:35:17
|
Hi, man, 21 08 2006 kl. 14:10 +0200, skrev David Bateman: [snip] > Some comments. I get the error message >=20 > date: unrecognized option `--rfc-3339=3Ddate' > Try `date --help' for more information. Okay, I must have used some Ubuntu specific option for the date command -- I'll change that > when running release.sh. The packages are created, but without the > date... I don't like the fact that the release.sh existing in the main > sub-directory, only. I'd prefer to run something from the top level. I don't like it either, I just wanted something the rest of you could use quickly. So I don't consider that script to be a long term solution. > Though there is a release.sh script already there from Paul, that is > missing the execute permission. So you'll either need another name, or > you'll need to ask for execute permission to be added by the sourceforg= e > admin... >=20 > Probably better would be to use the Makefile to call the release.sh in > the sub-directories. Agreed. I just didn't want to overwrite Paul's Makefiles just yet. > Also can we include some means of removing the > packages in the makefile, though the inclusion of the date in the > package file name might make that interesting to do in a sensible way. Perhaps, we just shouldn't use the date command? The individual packages have versions, so the date command is only interessting in order to create a bundle package that contains all the packages. > Can we exclude the CVS and the .cvsignore files from the packages? This > might be done with the --exclude option of tar, or alternatively with > the --exclude-from (or -X) option and create an excludes file in each o= f > the sub-directories. Yes, we should do this. I'll look at it when I get home from work. I simply missed that detail. > You've moved many of the source files, is src/ and inst/ > sub-directories. The corresponding .cvsignore files should also be > moved, and maybe even split into two parts for each of these > sub-directories. I don't really know the first thing about CVS. What does .cvsignore do? And what should I do with them? > The version numbers you added to fixed doesn't correspond to the > existing version number used internally in the code. Fixed should be > 0.7.0... Sorry :-) Since I didn't know anything about the internal version numbers, I've chosen that all packages are at version 1.0.0, which needs to be changed in the individual packages. Also, information about maintainers (etc.) needs to be corrected on a per package basis. > > The file called octave-forge-main-<date>.tar.gz is a bundle of all t= he > >packages, but it can't be installed without a patch to pkg that you ca= n > >find on the octave-bug list. > > > > I can't install the packages called "parallel", "comm", "fixed", and > >"linear-algebra" due to a problem in ./configure. However, that proble= m > >has been hunting me since before the move to the package system, so my > >problems shouldn't be related to the package system. > > =20 > > > I'll look at comm and fixed as these are my stuff. My problems are related to the configure script, but once the #ifdef's go away, so will my problems. > > If you guys don't have any problems with the packages, I'll move > >"nonfree" (and "extra"?) to the package system. The next step is then = to > >clean up the individual packages, so we can get rid of all the #ifdef'= s > >(right?) > There is a lot of ifdef junk in the code that should be stripped in the > C++ code. However, there is equally some try-catch blocks in the m-file= s > for features that are present or not in various versions of octave. Okay, but this stuff can be handled on a per package basis, and we can easily make releases even though the #ifdef's, etc. haven't been removed (my point: we're not in a hurry). Thanks, S=C3=B8ren |