Menu
▾
▴
octave-dev
|
From: Paul K. <pki...@ja...> - 2003-05-15 21:34:38
|
All,
We need a new release to support octave-2.1.48 since
OCTAVE_LOCAL_BUFFER now requires #include <memory>.
I've updated the half-dozen files that require it
(inc. comm/gf.cc and sparse/make_sparse.h).
Here is my take on the changes since the last release.
Please correct any errors in octave-forge/RELEASE-NOTES
* Support for octave 2.1.36-2.1.48.
* Communications:
- sqrt over Galois field
- BCH code, modulator
- bug fixes and documentation improvements
* Image:
- add rotate_scale()
* Optimization:
- add Nick Higham's adsmax, mdsmax nmsmax for fmins
- lp() fix range error
* Plotting:
- surf()/surfc() support gnuplot 3.8i shaded surfaces
- add peaks()
- legend() inside/ouside/boxon/boxoff/right/left
* Signal Processing
- return statespace and laplacian IIR filters (butter, cheby1, cheby2, ellip)
- fix aryule
* Statistics:
- add normplot()
- scatter() optimization
* Symbolic:
- added poly2sym, sym2poly, numden, findsymbols, findsym, symlsolve,
symfsolve, syminfo
- subs() accepts cell arrays
* TSA/NaN:
- many bug fixes and documentation improvements
- quantiles -> Quantile
* Miscellaneous:
- add cellstr()
- fieldnames() now returns cell array
- listen() bugfixes
- ellipke() supports m < 0
- extend deal() to handle [a,b] = deal(b,a)
- dlmread() converted to C++ for speed and more flexible input
* administration:
- target specific build instructions (MacOSX, windows, Irix)
|
|
From: Paul K. <pki...@us...> - 2004-06-14 22:38:06
|
I would like make a new octave-forge release. Please let me know when you all are ready. - Paul |
|
From: David B. <Dav...@mo...> - 2004-06-15 07:57:10
|
The stuff in the directory main/fixed/examples doesn't build on OS X, but as I don't have this OS I can't debug it. It was Per Persson who pointed this out, and suggested he might find time to fix it, but as he hasn't yet, I just added a test to disable building of this code if the canonical_host_type includes the string "darwin". The only other possible thing in my code was a bug report by Tom G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate his problem, and I can make no sense of why this problem occurs for him, except to think he might have a problem with the install of his compiler. So at this point I can propose no fix. If you really want to be on the save side, I can disable the building of the parts of the code that caused his problem as it only occurs in the classes for fixed point NDArrays. As I haven't integrated this with the rest of the code yet, they could only be used from within an oct-file in any case. during the lead-up to a release I expect more people will do builds of octave-forge and we'll see if other people have the same problems as Tom G. Smith and if so we can then think about disabling the build.. Cheers David Dapr=E8s Paul Kienzle <pki...@us...> (le 15/06/2004): > I would like make a new octave-forge release. Please let me > know when you all are ready. >=20 > - Paul >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN= D > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: Per P. <per...@ma...> - 2004-06-15 15:34:02
|
On Jun 15, 2004, at 09:56, David Bateman wrote:
> The stuff in the directory main/fixed/examples doesn't build on OS X,
> but as I don't have this OS I can't debug it. It was Per Persson who
> pointed this out, and suggested he might find time to fix it, but as
> he hasn't yet, I just added a test to disable building of this code
> if the canonical_host_type includes the string "darwin".
Thanks!
>
> The only other possible thing in my code was a bug report by Tom
> G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate
> his problem, and I can make no sense of why this problem occurs for
> him, except to think he might have a problem with the install of his
> compiler.
FWIW, I'm seeing the same thing here:
fixedCNDArray.cc: In member function `FixedComplexNDArray
FixedComplexNDArray::sumsq(int) const':
fixedCNDArray.cc:638: error: operands to ?: have different types
make[2]: *** [fixedCNDArray.o] Error 1
make[1]: *** [fixed/] Error 2
make: *** [main/] Error 2
Mac OS X 10.3, GCC 3.3
/Per
(just now checking octave-forge CVS against octave 2.1.57 and CVS on OS=20=
X...)
> So at this point I can propose no fix. If you really want to
> be on the save side, I can disable the building of the parts of the
> code that caused his problem as it only occurs in the classes for
> fixed point NDArrays. As I haven't integrated this with the rest of
> the code yet, they could only be used from within an oct-file in any
> case. during the lead-up to a release I expect more people will do
> builds of octave-forge and we'll see if other people have the same
> problems as Tom G. Smith and if so we can then think about disabling
> the build..
>
> Cheers
> David
>
> Dapr=E8s Paul Kienzle <pki...@us...> (le =
15/06/2004):
>> I would like make a new octave-forge release. Please let me
>> know when you all are ready.
>>
>> - Paul
>>
>>
|
|
From: David B. <Dav...@mo...> - 2004-06-15 15:40:18
|
Dapr=E8s Per Persson <per...@ma...> (le 15/06/2004): > >The only other possible thing in my code was a bug report by Tom > >G. Smith about the building of fixedCNDArray::sumsq. I can't duplicate > >his problem, and I can make no sense of why this problem occurs for > >him, except to think he might have a problem with the install of his > >compiler. >=20 > FWIW, I'm seeing the same thing here: > fixedCNDArray.cc: In member function `FixedComplexNDArray > FixedComplexNDArray::sumsq(int) const': > fixedCNDArray.cc:638: error: operands to ?: have different types > make[2]: *** [fixedCNDArray.o] Error 1 > make[1]: *** [fixed/] Error 2 > make: *** [main/] Error 2 >=20 > Mac OS X 10.3, GCC 3.3 Damn, so its likely a bug then. What a pain I can't generate it myself. Time to dig a bit further into the issue... cheers David --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: David B. <Dav...@mo...> - 2004-06-15 15:50:46
|
Dapr=E8s Per Persson <per...@ma...> (le 15/06/2004):
> FWIW, I'm seeing the same thing here:
> fixedCNDArray.cc: In member function `FixedComplexNDArray
> FixedComplexNDArray::sumsq(int) const':
> fixedCNDArray.cc:638: error: operands to ?: have different types
> make[2]: *** [fixedCNDArray.o] Error 1
> make[1]: *** [fixed/] Error 2
> make: *** [main/] Error 2
Ok, on the assumption that the "pow" function is returning double,=20
and that the "if" statement is basically a costing me speed, I
eliminated both in an attempt to resolve this issue. This is=20
probably the best thing to do in any case. The function "sumsq"
in fixedCNDArray.cc should now read
FixedComplexNDArray
FixedComplexNDArray::sumsq (int dim) const
{
FixedPointComplex zero;
MX_ND_REDUCTION (acc +=3D elem (iter_idx) * conj (elem (iter_idx)),
retval.elem (iter_idx) =3D acc, zero,=20
FixedPointComplex acc =3D zero, FixedComplexNDArray);
}
I've committed this to the cvs, but unless you have access to the develop=
ers
site you won't see this change for a few hours. Could you check and see
that this fixes all the build problems you are/were having...
Cheers
David
--=20
David Bateman Dav...@mo...
Motorola CRM +33 1 69 35 48 04 (Ph)=20
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:=20
[x] General Business Information=20
[ ] Motorola Internal Use Only=20
[ ] Motorola Confidential Proprietary
|
|
From: Quentin S. <qsp...@ie...> - 2004-06-15 17:00:25
|
I finally got octave-forge to build with qhull support using the patches John sent to the octave list yesterday. I can't build without the changes (I'm using Fedora Core 2). I'm surprised this problem hasn't come up sooner. Are the lines he removed necessary for anyone? This definitely needs to be fixed before a release, but I'm not very familiar with the geometry functions, so I would prefer to defer to someone who is to make these changes. -Quentin |
|
From: Quentin S. <qsp...@ie...> - 2004-06-15 20:53:48
|
Here's another bug I found recently: hammgen's documentation claims it can take input arguments M between 3 and 16, but it actually fails for M>6. This appears to be an undocumented limitation in cyclgen. Looking at the source code to cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit number is used in the computation. I would love to see someone figure out how to support larger sizes than 64 (like up to 65535 as hammgen suggests, for example), but I don't have time to figure this out by myself. If this isn't fixed before a new release, at least the documentation of hammgen should be modified until it is. -Quentin |
|
From: David B. <Dav...@mo...> - 2004-06-16 08:00:45
|
Hummm, another one of my bugs.... Ok, I'll look at it... Cheers David Dapr=E8s Quentin Spencer <qsp...@ie...> (le 15/06/2004): > Here's another bug I found recently: >=20 > hammgen's documentation claims it can take input arguments M between 3 > and 16, but it actually fails for M>6. This appears to be an > undocumented limitation in cyclgen. Looking at the source code to > cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit > number is used in the computation. I would love to see someone figure > out how to support larger sizes than 64 (like up to 65535 as hammgen > suggests, for example), but I don't have time to figure this out by > myself. If this isn't fixed before a new release, at least the > documentation of hammgen should be modified until it is. >=20 > -Quentin >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN= D > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: David B. <Dav...@mo...> - 2004-06-16 14:03:36
|
Quentin, I wrote the hammgen function over a year ago now and I'm scratching my head to think why I wrote the test for an irreducible polynomial the way I did in cyclgen.cc and cyclpoly.cc. I vaguely remember that there was a reason, but not the details. I think it might have been=20 a limitation elsewhere that I later removed and have now fixed. In any case hammgen upto 16 seems to work correctly and a quick test of cyclgen and cyclpoly seperately seem to be ok.=20 However, if you have any specific tests of these three functions,=20 could you try them and see that they now give the right result, with the code I just checked into the CVS... Regards David Dapr=E8s Quentin Spencer <qsp...@ie...> (le 15/06/2004): > Here's another bug I found recently: >=20 > hammgen's documentation claims it can take input arguments M between 3 > and 16, but it actually fails for M>6. This appears to be an > undocumented limitation in cyclgen. Looking at the source code to > cyclgen, the ceiling appears to be fixed at 64 bits because a 64-bit > number is used in the computation. I would love to see someone figure > out how to support larger sizes than 64 (like up to 65535 as hammgen > suggests, for example), but I don't have time to figure this out by > myself. If this isn't fixed before a new release, at least the > documentation of hammgen should be modified until it is. >=20 > -Quentin >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN= D > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: Quentin S. <qsp...@ie...> - 2004-06-16 15:28:52
|
David, Thanks. The updates fixed hammgen. However, now I've found another bug. I don't know if it was there all along or newly introduced. The following command should produce the 16x255 parity check matrix for a BCH 2-error correcting code: cyclgen(255,bchpoly(255,239)) The result instead is: error: cyclgen: generator polynomial does not produce cyclic code I verified the resulting polynomial against MATLAB and they matched. regards, Quentin David Bateman wrote: >Quentin, > >I wrote the hammgen function over a year ago now and I'm scratching >my head to think why I wrote the test for an irreducible polynomial >the way I did in cyclgen.cc and cyclpoly.cc. I vaguely remember that >there was a reason, but not the details. I think it might have been >a limitation elsewhere that I later removed and have now fixed. In >any case hammgen upto 16 seems to work correctly and a quick test >of cyclgen and cyclpoly seperately seem to be ok. > >However, if you have any specific tests of these three functions, >could you try them and see that they now give the right result, >with the code I just checked into the CVS... > >Regards >David > > |
|
From: David B. <Dav...@mo...> - 2004-06-16 23:09:41
|
According to Quentin Spencer <qsp...@ie...> (on 06/16/04): > David, > > Thanks. The updates fixed hammgen. However, now I've found another bug. > I don't know if it was there all along or newly introduced. The > following command should produce the 16x255 parity check matrix for a > BCH 2-error correcting code: > cyclgen(255,bchpoly(255,239)) > > The result instead is: > error: cyclgen: generator polynomial does not produce cyclic code > > I verified the resulting polynomial against MATLAB and they matched. Ok, I'm a bit draft. The test I added checks if the polynomial is primitive rather than just irreducible. I'd previously tried to adapt this test in the older code, but failed. So I went back to the basic implementation of dividing x^n-1 by the polynomial and checking that there was no remainder. It appears to work correctly for you test case now. Though maybe you want to give it a bit more testing.. Changes checked into the CVS Regards David -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Quentin S. <qsp...@ie...> - 2004-06-18 17:49:50
|
OK, I tested your changes to the coding stuff and this is what I found: bchpoly appears to give correct results for the cases I tested cyclgen(255,bchpoly(255,247)) gives the correct result cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the first 8x8 submatrix, and zeros everywhere else !? cyclpoly gives a vector containing all zeros for every input I tried. Well, I guess there's at least some progress since one case worked. I'm sorry the news isn't better. -Quentin David Bateman wrote: >According to Quentin Spencer <qsp...@ie...> (on 06/16/04): > > >>David, >> >>Thanks. The updates fixed hammgen. However, now I've found another bug. >>I don't know if it was there all along or newly introduced. The >>following command should produce the 16x255 parity check matrix for a >>BCH 2-error correcting code: >>cyclgen(255,bchpoly(255,239)) >> >>The result instead is: >>error: cyclgen: generator polynomial does not produce cyclic code >> >>I verified the resulting polynomial against MATLAB and they matched. >> >> > >Ok, I'm a bit draft. The test I added checks if the polynomial is primitive >rather than just irreducible. I'd previously tried to adapt this test in >the older code, but failed. > >So I went back to the basic implementation of dividing x^n-1 by the >polynomial and checking that there was no remainder. It appears to >work correctly for you test case now. Though maybe you want to give >it a bit more testing.. Changes checked into the CVS > >Regards >David > > > |
|
From: David B. <Dav...@mo...> - 2004-06-21 07:16:26
|
I believe it probably still works correctly for small values of n, since that was all I tested previously. Oh, well it looks like the method I used to create the generator matrix is too naive... Cheers David According to Quentin Spencer <qsp...@ie...> (on 06/18/04): > OK, I tested your changes to the coding stuff and this is what I found: > > bchpoly appears to give correct results for the cases I tested > cyclgen(255,bchpoly(255,247)) gives the correct result > cyclgen(255,bchpoly(255,239)) gives a matrix that is correct in the > first 8x8 submatrix, and zeros everywhere else !? > cyclpoly gives a vector containing all zeros for every input I tried. > > Well, I guess there's at least some progress since one case worked. I'm > sorry the news isn't better. > > -Quentin > > > David Bateman wrote: > > >According to Quentin Spencer <qsp...@ie...> (on 06/16/04): > > > > > >>David, > >> > >>Thanks. The updates fixed hammgen. However, now I've found another bug. > >>I don't know if it was there all along or newly introduced. The > >>following command should produce the 16x255 parity check matrix for a > >>BCH 2-error correcting code: > >>cyclgen(255,bchpoly(255,239)) > >> > >>The result instead is: > >>error: cyclgen: generator polynomial does not produce cyclic code > >> > >>I verified the resulting polynomial against MATLAB and they matched. > >> > >> > > > >Ok, I'm a bit draft. The test I added checks if the polynomial is primitive > >rather than just irreducible. I'd previously tried to adapt this test in > >the older code, but failed. > > > >So I went back to the basic implementation of dividing x^n-1 by the > >polynomial and checking that there was no remainder. It appears to > >work correctly for you test case now. Though maybe you want to give > >it a bit more testing.. Changes checked into the CVS > > > >Regards > >David > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Paul K. <pki...@us...> - 2004-06-21 11:19:56
|
So are all the issues addressed that we are going to address? If I've been following correctly, the comm and fixed toolboxes are now ready. Arguably there are still bugs in symbolic and sparse since neither use the new concatenation mechanism and neither use the new save mechanism that David put into place. And there is the issue of what to do about shadowed octave functions which I wrote about earlier. If no one volunteers, I'm content to leave this issues into the next release in order to get this release out now. It will be a couple of weeks at least before I can get to it. In which case, we are ready for Dirk to build a new Debian version, assuming he is not too busy at the moment. Paul Kienzle pki...@us... |
|
From: David B. <Dav...@mo...> - 2004-06-21 11:34:54
|
Dapr=E8s Paul Kienzle <pki...@us...> (le 21/06/2004): > So are all the issues addressed that we are going to address? >=20 > If I've been following correctly, the comm and fixed toolboxes > are now ready. I think the fixed point and cyclgen/cyclpoly bugs are fixed... > Arguably there are still bugs in symbolic and sparse since > neither use the new concatenation mechanism and neither > use the new save mechanism that David put into place. What new concatenation method? Do you mean "cat", in that case it can be argued that neither does the galois or fixed point types. In any case either if these are implemented there is nothing to stop a user using "[]" and getting the wrong result, so implementing these functions just gives a=20 false sense of security.... Still need to get "[]" fixed within octave itself.. > And there is the issue of what to do about shadowed > octave functions which I wrote about earlier. >=20 > If no one volunteers, I'm content to leave this issues into the > next release in order to get this release out now. It will be > a couple of weeks at least before I can get to it. Which? The next release or this one :-) Cheers David --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: Dirk E. <ed...@de...> - 2004-06-21 11:57:15
|
On Mon, Jun 21, 2004 at 07:19:43AM -0400, Paul Kienzle wrote: > In which case, we are ready for Dirk to build a new Debian > version, assuming he is not too busy at the moment. Sure, let me know where to grab a tarball from, or if I must, I'd attempt a CVS checkout. This should fix three open Debian bugs http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=octave-forge so a release is probably a good idea indeed. Dirk -- FEATURE: VW Beetle license plate in California |
|
From: David B. <Dav...@mo...> - 2004-06-21 12:14:23
|
Dirk, It seems hdf5-1.6.2-3 is a valid candidate for debian testing, but is stalled since it says it breaks octave, python, etc. Without this=20 octave-forge can't migrate into testing. Does this mean that octave, etc in testing need to be rebuilt against the new hdf5 library, so it also can migrate to testing? Regards David Dapr=E8s Dirk Eddelbuettel <ed...@de...> (le 21/06/2004): > On Mon, Jun 21, 2004 at 07:19:43AM -0400, Paul Kienzle wrote: > > In which case, we are ready for Dirk to build a new Debian > > version, assuming he is not too busy at the moment. >=20 > Sure, let me know where to grab a tarball from, or if I must, I'd attem= pt a > CVS checkout. =20 >=20 > This should fix three open Debian bugs >=20 > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=3Doctave-forge >=20 > so a release is probably a good idea indeed. >=20 > Dirk >=20 > --=20 > FEATURE: VW Beetle license plate in California >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKN= D > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: Dirk E. <ed...@de...> - 2004-06-21 12:59:50
|
On Mon, Jun 21, 2004 at 02:14:15PM +0200, David Bateman wrote: > > Dirk, > > It seems hdf5-1.6.2-3 is a valid candidate for debian testing, but is > stalled since it says it breaks octave, python, etc. Without this > octave-forge can't migrate into testing. Does this mean that octave, > etc in testing need to be rebuilt against the new hdf5 library, so > it also can migrate to testing? Possibly. I have no insights other than the (helpful) page 'why is package X not in testing' (at http://bjorn.haxx.se/debian/) says. Rafael is up to snuff on these things as octave influences his octave-* packages, incl. plplot. Dirk -- FEATURE: VW Beetle license plate in California |
|
From: Rafael L. <ra...@de...> - 2004-06-21 14:49:09
|
* Dirk Eddelbuettel <ed...@de...> [2004-06-21 07:59]: > On Mon, Jun 21, 2004 at 02:14:15PM +0200, David Bateman wrote: > > > > Dirk, > > > > It seems hdf5-1.6.2-3 is a valid candidate for debian testing, but is > > stalled since it says it breaks octave, python, etc. Without this > > octave-forge can't migrate into testing. Does this mean that octave, > > etc in testing need to be rebuilt against the new hdf5 library, so > > it also can migrate to testing? > > Possibly. I have no insights other than the (helpful) page 'why is package X > not in testing' (at http://bjorn.haxx.se/debian/) says. > > Rafael is up to snuff on these things as octave influences his octave-* > packages, incl. plplot. The problem is that there are circular dependencies between the new hdf5 packages and lots of others (including octave2.1, octave-forge and octave-plplot). This can be seen at: http://bjorn.haxx.se/debian/testing.pl?package=hdf5 The only way to fix this dead-lock situation is by manually adding a hint to the program that promotes packages from unstable to testing (britney). The hints can be seen at: http://ftp-master.debian.org/testing/hints/ One thing that complicates the situation is that the number of packages involved is quite high and new versions are constantly uploaded to unstable. Since the 10-days rule must be obeyed, the joint promotion of all packages keep being delayed. Should we impose a freeze on the involved packages until they get all together into testing? [ N.B.: Steve Langasek is one of the ftp-admins who is helping us with this issue. Josselin Mouette is the maintainer of the Debian hdf5 packages. I am CC:ing this message to them. ] -- Rafael |
|
From: David B. <Dav...@mo...> - 2004-06-21 14:51:31
|
Dapr=E8s Rafael Laboissiere <ra...@de...> (le 21/06/2004): > Should we impose a freeze on the involved packages until they get all > together into testing? Yes, please... :-) D. --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: Dirk E. <ed...@de...> - 2004-06-21 15:06:14
|
On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote: > Dapr?s Rafael Laboissiere <ra...@de...> (le 21/06/2004): > > Should we impose a freeze on the involved packages until they get all > > together into testing? > > Yes, please... :-) Before or after the tarball for octave-forge that spawned this discussion is added? Dirk -- FEATURE: VW Beetle license plate in California |
|
From: David B. <Dav...@mo...> - 2004-06-21 15:09:08
|
Dapr=E8s Dirk Eddelbuettel <ed...@de...> (le 21/06/2004): > On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote: > > Dapr?s Rafael Laboissiere <ra...@de...> (le 21/06/2004): > > > Should we impose a freeze on the involved packages until they get a= ll > > > together into testing? > >=20 > > Yes, please... :-) >=20 > Before or after the tarball for octave-forge that spawned this discussi= on is > added? I can wait two times ten days to get it... So before I suppose. Unless on= e of the other blocking packages just added something and we can slip somet= hing in with further delays being implied... Cheers David --=20 David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph)=20 Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)=20 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as:=20 [x] General Business Information=20 [ ] Motorola Internal Use Only=20 [ ] Motorola Confidential Proprietary |
|
From: Dirk E. <ed...@de...> - 2004-07-03 14:31:20
|
Hi all,
On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote:
> Dapr?s Rafael Laboissiere <ra...@de...> (le 21/06/2004):
> > Should we impose a freeze on the involved packages until they get all
> > together into testing?
>
> Yes, please... :-)
It looks like things moved according to plan and octave2.1 and octave-forge
are now in testing.
So shall we release a new octave-forge tarball for Debian unstable and/or
the world at large? I'm CCing to the the submitter and bug report of a
recent BTS request for a fresher octave-forge.
Dirk
--
White House officials praised the performance of the controversial
new Diebold electronic voting machines, which successfully tabulated
final results from Florida before a single vote was cast.
-- Andy Borowitz, http://borowitzreport.com, 29 June 2004
|
|
From: Paul K. <pki...@us...> - 2004-07-03 17:27:19
|
Will it cause problems for you if the build succeeds even when it fails? That is, if I put in the -k business so that people can ignore things that don't build on their architecture unless they really need them, it won't generate an exit status on Debian builds. On second thought, I can put in a make parameter such as: make STOP=1 Use this if you want to build and stop at the first error. If nobody disagrees, that's what I will do. I'll skip the nice report of what doesn't build for now. Paul Kienzle pki...@us... On Jul 3, 2004, at 10:29 AM, Dirk Eddelbuettel wrote: > > Hi all, > > On Mon, Jun 21, 2004 at 04:51:21PM +0200, David Bateman wrote: >> Dapr?s Rafael Laboissiere <ra...@de...> (le 21/06/2004): >>> Should we impose a freeze on the involved packages until they get all >>> together into testing? >> >> Yes, please... :-) > > It looks like things moved according to plan and octave2.1 and > octave-forge > are now in testing. > > So shall we release a new octave-forge tarball for Debian unstable > and/or > the world at large? I'm CCing to the the submitter and bug report of a > recent BTS request for a fresher octave-forge. > > Dirk > > -- > White House officials praised the performance of the controversial > new Diebold electronic voting machines, which successfully tabulated > final results from Florida before a single vote was cast. > -- Andy Borowitz, http://borowitzreport.com, 29 June 2004 > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X