Bug#976385: marked as pending in octave-vibes

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #976385 in octave-vibes reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-vibes/-/commit/3784be9e9a7eb6fc8150559a5f1731807e375b0d


d/p/build-against-octave-6.patch: New patch

Closes: #976385


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976385

Bug#977357: marked as pending in libgdf

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #977357 in libgdf reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/libgdf/-/commit/e1ecf1858c67cdf55bc1520493ed1954063ace20


d/p/check-system-endianness.patch: Update patch

This fixes the problem of detection of endianness on the s390x architecture, 
what was causing the FTBFS on that architecture.

Gbp-Dch: Full

Closes: #977357


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/977357

Bug#976436: marked as pending in octave-ltfat

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #976436 in octave-ltfat reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-ltfat/-/commit/b0cb4862e4f8766fae48144daea9d807f525116f


d/rules: Remove the arch-indep files for the octave-ltfat package

Closes: #976436


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976436

Bug#976198: marked as pending in octave-image

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #976198 in octave-image reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-image/-/commit/30c72bef7fa4a3b2b1b045663654453aff74741c


d/p/fix-bwdist-on-i386.patch: New patch

Closes: #976198


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/976198

Bug#974099: marked as pending in octave-database

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #974099 in octave-database reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-database/-/commit/4bfc7b345901e849bc931610933658ce16163af3


debian/{control,tests}/: Run tests with default postgresql version (Closes: 
#974099)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974099

Bug#957627: marked as pending in octave-optiminterp

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #957627 in octave-optiminterp reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-optiminterp/-/commit/f8dc3a7958377be990cabfd445318d26129cf0b9


d/p/compile-with-gfortran-10.patch: New patch

Closes: #957627


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/957627

Bug#964210: marked as pending in octave-nan

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #964210 in octave-nan reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-nan/-/commit/b4c7362a6c398613170e5f5d19e702c5bb0f7f7c


d/p/xtest-in-load-fisheriris.patch: New patch

Closes: #964210


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/964210

Bug#964211: marked as pending in octave-instrument-control

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #964211 in octave-instrument-control reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-instrument-control/-/commit/fe551915eca3e22024b49f9826b791775a86c54c


d/p/xtest-in-unit-tests.patch: Switch to xtest for tests involving remote 
servers

Closes: #964211


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/964211

Bug#962217: marked as pending in libgdf

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #962217 in libgdf reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/libgdf/-/commit/51a737871ecc665c70c8be6733b2867d621aa805


Allow stderr in unit tests

This allows autopkgtest to pass with libboost 1.71, since messages
regarding the deprecation of BOOST_*_ENDIAN BOOST_BYTE_ORDER are
issued at compilation time.  This is a quick fix while waiting for the
problem to be fixed upstream.

Gbp-Dch: Full
Closes: #962217


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/962217

Bug#960402: marked as pending in mwrap

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #960402 in mwrap reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/mwrap/-/commit/60d8f18ba09b242be7c6953f166683807907a03b


d/p/compile-with-bison-3.6.1.patch: New patch

Closes: #960402


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/960402

Bug#952274: marked as pending in octave-queueing

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #952274 in octave-queueing reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-queueing/-/commit/2ded09889d93d053e7637e051903cd7a766df16b


d/p/xseealso-texi2pdf.patch: New patch

This patch avoids a problem introduced with the introduction of macro
@seealso in Texinfo version 6.7, which clashes with the one defined in
Octave.

Gbp-Dch: Full
Closes: #952274


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/952274

Bug#945976: marked as pending in octave-dicom

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #945976 in octave-dicom reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-dicom/commit/b7964318613ba41820b8e5cbd1ee4a2bf1c6a251


d/p/gdcm-3-fallback-detection.patch: New patch

This patch changes the src/configure.ac file, which forces the
autoreconfiguration of the package.  For that to work, file
debian/autoreconf has been added, as well ass adjustments to
.gitignore and d/s/options.

Closes: #945976
Thanks: Peter Green, for reporting the bug, and Gianfranco Costamagna, for 
indicating the patch


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/945976

Bug#944718: marked as pending in octave-dicom

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #944718 in octave-dicom reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-dicom/commit/3eee9cf27b1d7fbcab981e868f75ff72655a0974


d/control: Build-depend on cmake and libgdcm-dev

Closes: #944718
Thanks: Steve Langasek, for the patch


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/944718

Bug#931914: marked as pending in octave-octproj

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #931914 in octave-octproj reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-octproj/commit/a683eb8245a9dce25cfa7fbced9e1d3d3ff85f65


d/p/build-against-proj-6.patch: New patch

Closes: #931914


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/931914

Bug#935584: marked as pending in octave-octclip

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #935584 in octave-octclip reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-octclip/commit/2c8351f28f59f6116180f56806d834e96d5f7c7a


d/p/compile-with-gcc-9.patch: Refresh for compilation with gcc version < 9

Closes: #935584


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/935584

Bug#925791: marked as pending in octave-octclip

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #925791 in octave-octclip reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-octclip/commit/0b6a9c0df5128682b0fbf08082786af219d4c4d6


d/p/compile-with-gcc-9.patch: New patch

Closes: #925791


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/925791

Bug#932975: marked as pending in octave

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #932975 in octave reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave/commit/21f5c108e9f777220526461d718d063c8a271012


d/control: Build-depend on texlive-plain-generic, instead of 
-generic-recommended

Closes: #932975


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/932975

Bug#919764: Bug #919764 in octave-image marked as pending

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #919764 in octave-image reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-image/commit/139f9f6522c80f0a5796e041dcded1267517f2db


d/p/xtest-bwpack-big-endian.patch: New patch

Closes: #919764


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/919764

Bug#918559: Bug #918559 in octave-geometry marked as pending

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #918559 in octave-geometry reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-geometry/commit/8a46637b83e51be34cc6c5a7eb89fa4ceb824e86


d/p/do-not-strip-debugging-symbols.patch: New patch

Closes: #918559


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/918559

Bug#905370: Bug #905370 in octave-queueing marked as pending

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #905370 in octave-queueing reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/octave-queueing/commit/613841044171b822638dad6644d9d9977e45ed7a


d/rules: Install the *.m files in the binary package

Closes: #905370



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/905370

Bug#897816: Bug #897816 in mwrap marked as pending

[Rafael Laboissiere]

Control: tag -1 pending

Hello,

Bug #897816 in mwrap reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/pkg-octave-team/mwrap/commit/a314a77d14aea1974840b40b57eb6c9c7cbbe072


d/p/compile-with-gcc-8.patch: New patch

Closes: #897816



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/897816

Bug#874143: [pkg-octave/master] d/p/nan-unit-test-calcmescd.patch: New patch

[Rafael Laboissiere]

tag 874143 pending
thanks

Date: Mon Sep 11 06:24:22 2017 -0300
Author: Rafael Laboissiere <raf...@debian.org>
Commit ID: e009cf318c5d7f02f0d104ef3ebc105cbf4251db
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-odepkg.git;a=commitdiff;h=e009cf318c5d7f02f0d104ef3ebc105cbf4251db
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-odepkg.git;a=commitdiff_plain;h=e009cf318c5d7f02f0d104ef3ebc105cbf4251db

d/p/nan-unit-test-calcmescd.patch: New patch

Fix failing unit test, avoing the package to FTBFS with
octave-pkg-dev 1.5.0.

Gbp-Dch: Full
Closes: #874143
  

Bug#874138: [pkg-octave/master] d/p/skip-dolfin-tests.patch: New patch

[Rafael Laboissiere]

tag 874138 pending
thanks

Date: Sat Sep 9 14:28:21 2017 -0300
Author: Rafael Laboissiere <raf...@debian.org>
Commit ID: a9988b3b911a35b08b045e6b38923a7fefcfa3f2
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-msh.git;a=commitdiff;h=a9988b3b911a35b08b045e6b38923a7fefcfa3f2
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-msh.git;a=commitdiff_plain;h=a9988b3b911a35b08b045e6b38923a7fefcfa3f2

d/p/skip-dolfin-tests.patch: New patch

Skip the unit tests related to the dolfin library, avoiding the
package to FTBFS.

Git-Dch: Full
Closes: #874138
  

Bug#874144: [pkg-octave/master] d/p/comment-out-failing-unit-tests.patch: New patch

[Rafael Laboissiere]

tag 874144 pending
thanks

Date: Mon Sep 4 13:00:30 2017 -0300
Author: Rafael Laboissiere <raf...@debian.org>
Commit ID: 394d4c8c32a2a39c83605396c687cbd963b5e04d
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-control.git;a=commitdiff;h=394d4c8c32a2a39c83605396c687cbd963b5e04d
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-control.git;a=commitdiff_plain;h=394d4c8c32a2a39c83605396c687cbd963b5e04d

d/p/comment-out-failing-unit-tests.patch: New patch

The package FTBFS with octave-pkg-dev 1.5.0 because it now exits with
a code error when unit tests fail.  We comment out, for now, the
failing tests, but this must be addressed in a proper way, since it
may hide problems in the package.

Gbp-Dch: Full
Closes: #874144
  

Bug#874139: [pkg-octave/master] d/p/comment-out-failing-unit-tests.patch: New patch

[Rafael Laboissiere]

tag 874139 pending
thanks

Date: Mon Sep 4 12:39:42 2017 -0300
Author: Rafael Laboissiere <raf...@debian.org>
Commit ID: 28028a1076fe8e32f9492207b0f8d00f691129f5
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-signal.git;a=commitdiff;h=28028a1076fe8e32f9492207b0f8d00f691129f5
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-signal.git;a=commitdiff_plain;h=28028a1076fe8e32f9492207b0f8d00f691129f5

d/p/comment-out-failing-unit-tests.patch: New patch

The package FTBFS with octave-pkg-dev 1.5.0 because it now exits with
a code error when unit tests fail.  We comment out, for now, the
failing tests, but this must be addressed in a proper way, since it
may hide problems in the package.

Gbp-Dch: Full
Closes: #874139
  

Bug#871214: [pkg-octave/master] d/rules: Pass -ffloat-store option to g++ on i386 architecture

[Rafael Laboissiere]

tag 871214 pending
thanks

Date: Sat Aug 12 06:30:37 2017 -0300
Author: Rafael Laboissiere <raf...@debian.org>
Commit ID: d383f06a10084cf511f385f46d569071fb2feef1
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-image.git;a=commitdiff;h=d383f06a10084cf511f385f46d569071fb2feef1
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-image.git;a=commitdiff_plain;h=d383f06a10084cf511f385f46d569071fb2feef1

d/rules: Pass -ffloat-store option to g++ on i386 architecture

This will ensure the precise definition of IEEE floating point, what
will, hopefully, avoid the endless loop (and the consequent FTBFS) in
the unit test for bwdist.

Gbp-Dch: Full
Closes: #871214
Thanks: Adrian Bunk for the diagnosis of the problem and the suggestion of 
the fix
  

Bug#865241: [pkg-octave/master] d/control: Build-depend on texlive-latex-recommended instead of latex-xcolor

[Rafael Laboissiere]

tag 865241 pending
thanks

Date: Tue Jun 20 03:42:13 2017 -0300
Author: Rafael Laboissiere <raf...@debian.org>
Commit ID: 08de6ed4d742af56f276c7fe6b56eb0c4fee7599
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-ocs.git;a=commitdiff;h=08de6ed4d742af56f276c7fe6b56eb0c4fee7599
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-ocs.git;a=commitdiff_plain;h=08de6ed4d742af56f276c7fe6b56eb0c4fee7599

d/control: Build-depend on texlive-latex-recommended instead of latex-xcolor

Closes: #865241
  

Bug#826390: [pkg-octave/master] octave-pkg-helper: Only parse the DESCRIPTION file when it exists

[Rafael Laboissiere]

tag 826390 pending
thanks

Date: Sun Jun 5 11:19:49 2016 -0300
Author: Rafael Laboissiere <raf...@laboissiere.net>
Commit ID: 1715b67a05640bd6738157ca6250b785a08d0a3e
Commit URL: 
https://anonscm.debian.org/gitweb/?p=pkg-octave/octave-pkg-dev.git;a=commitdiff;h=1715b67a05640bd6738157ca6250b785a08d0a3e
Patch URL: 
https://anonscm.debian.org/gitweb/?p=pkg-octave/octave-pkg-dev.git;a=commitdiff_plain;h=1715b67a05640bd6738157ca6250b785a08d0a3e

octave-pkg-helper: Only parse the DESCRIPTION file when it exists

Closes: #826390
  

Bug#815600: isympy: lacks a dependency on python-sympy | python3-sympy

[Rafael Laboissiere]

* Francesco Poli (wintermute)  [2016-02-22 22:41]:


Package: isympy
Version: 0.7.6.1-1
Severity: grave
Justification: renders package unusable

I think binary isympy lacks a dependency on python-sympy | python3-sympy. 
Without this dependency, installing it leaves the package in an unusable 
state:


 [snip]

Hence, isympy should depend on python-sympy | python3-sympy. 
Please add this dependency.


Actually, isympy must depend only on python-sympy.  If python3-sympy is 
installed and python-sympy is not, then isympy fails, because of this:


   $ head -n 1 /usr/bin/isympy
   #!/usr/bin/python

One might create a isympy3 package, but this is a different issue from 
the one concerning the present bug report.


Best,

Rafael Laboissière

Bug#807784: [Pkg-octave-devel] Bug#807784: octave-optim suggests `lyx`

[Rafael Laboissiere]

Control: severity -1 normal

* Hormet Yiltiz  [2015-12-12 19:29]:


Package: octave-optim
Version: 1.4.1-1+b1
Severity: serious
Justification: Policy 7.2

  octave-optim suggests lyx, which is a office suite that makes working
  with LaTeX easy, and implements a way for reproducable research.
  However, `lyx` then depends on `texlive`, which is a heavy
  dependency. Octave-optim is a package of GNU Octave, which is used
  for scientific computation. octave-optim, being a package for a
  octave that does the computation, should NOT depend or suggest a 3rd
  party software that is not very related to its usage.


I disagree with this interpretation.  Section 7.2 of the Policy manual 
does mandate that:


"Depends […] The Depends field should be used if the depended-on package 
is required for the depending package to provide a significant amount of 
functionality. […]"


However, there is no such requirement for the Suggests relationship:

"Suggests: This is used to declare that one package may be more useful 
with one or more others. Using this field tells the packaging system and 
the user that the listed packages are related to this one and can perhaps 
enhance its usefulness, but that installing this one without them is 
perfectly reasonable."


I am therefore downgrading the severity of this bug report to "normal" 
hereby.


That said, I agree with the bug submitter that having to install lyx, 
which pulls the whole TeX distribution, is an overkill for just reading 
part of the documentation.  I am now working on a solution that will ship 
the *.pdf instead of the *.lyx, as it is currently the case.  This will 
eventually fix the bug reported here.


Rafael

Bug#803958: critically affects Octave

[Rafael Laboissiere]

affects 803958 octave 
stop


This is just to register the fact that the graphicsmagick's 
soversion-bump-without-package-rename is also affecting Octave and the 
plethora of packages depending on it.


Please, fix this bug as soon as possible.

Rafael Laboissière

Bug#797992: [Pkg-octave-devel] Bug#797992: octave: ABI transition needed for libstdc++ v5

[Rafael Laboissiere]

* Simon McVittie  [2015-09-04 10:16]:


On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:

Looking at the C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.


Looking more closely at this, hdf5 has both a C and a C++ API, 
and octave appears to only use the C. If this is correct, then it does 
not need to wait for hdf5 after all.


The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
a rebuild really necessary?


Rafael

Bug#786888: [Pkg-octave-devel] Bug#786888: Fails to install

[Rafael Laboissiere]

Control: tags -1 wontfix

Hi Mike,

Thanks for your thorough reply.  There is nothing that we can do as 
maintainers regarding this bug.  I am hereby tagging this bug report, 
accordingly.


Best,

Rafael

* Mike Miller mtmil...@debian.org [2015-05-26 22:19]:


On Tue, May 26, 2015 at 14:53:42 +0200, Christoph Egger wrote:

octave-info fails to install:

$ dpkg -i octave-info_3.8.2-4_all.deb 21 | tee /tmp/octave 
dpkg: considering removing octave3.2-info in favour of octave-info ... 
dpkg: yes, will remove octave3.2-info in favour of octave-info 
(Reading database ... 608326 files and directories currently installed.) 
Preparing to unpack octave-info_3.8.2-4_all.deb ... 
install-info: No dir file specified; try --help for more information. 
dpkg: error processing archive octave-info_3.8.2-4_all.deb (--install): 
 subprocess installed pre-removal script returned error exit status 1 
Errors were encountered while processing: 
 octave-info_3.8.2-4_all.deb


Hmm, looks to me like you have remnants of octave3.2-info on your system 
that shouldn't be there. Installing octave-info is attempting to replace 
octave3.2-info and run its obsolete prerm. This package should have been 
purged after squeeze and before the install-info transition period was 
completed in jessie.


Can you create a local install-info wrapper script in your $PATH before 
/usr/bin/install-info and purge octave3.2-info and try installing again? 
See for example [1].


See [2] for full details on the install-info transition.

Anyway, I can install octave-info on a clean system without any octave* 
packages installed, I think you'll have success when octave3.2-info is 
purged first.


[1] http://unix.stackexchange.com/a/146393/16840 
[2] https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo


--
mike

___ 
Pkg-octave-devel mailing list 
pkg-octave-de...@lists.alioth.debian.org 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel





--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778745: [pkg-octave/master] Exclude ezplot and ezplot3 from the list of automatic unit testing

[Rafael Laboissiere]

tag 778745 pending
thanks

Date: Sun Mar 22 08:25:00 2015 -0300
Author: Rafael Laboissiere raf...@laboissiere.net
Commit ID: b2d9a2f0206b19bcd3a961d3210595f0fe5c5f5a
Commit URL: 
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-symbolic.git;a=commitdiff;h=b2d9a2f0206b19bcd3a961d3210595f0fe5c5f5a
Patch URL: 
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-symbolic.git;a=commitdiff_plain;h=b2d9a2f0206b19bcd3a961d3210595f0fe5c5f5a

Exclude ezplot and ezplot3 from the list of automatic unit testing

The tests for these functions require gnuplot, which is not included
in the list of build-dependencies.  This avoids the hanging octave-cli
processes in the buildd hosts.

Closes: #778745
  


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#761057: missing license in debian/copyright

[Rafael Laboissiere]

Hi Alan,

* Alan W. Irwin ir...@beluga.phys.uvic.ca [2014-09-17 14:19]:


[snip]

@Rafael (it's been a while we were last in contact so I CC'd you with 
two possible e-mail addresses): Do you agree with this summary for the 
historical origin of these static man pages, and do you give your 
agreement that there should (1a) be an explicit license embedded in those 
man page files, and also (1b) present in the pages displayed by the man 
application? If so, I know one way to deal with (1a) which is to 
prepend


.\ 
.\ Copyright (C) 2001-2004 Rafael Laboissiere raf...@debian.org 
.\ 
.\ This program is free software; [plus the remainder of the license 
boilerplate]


to each of these man page files.  [snip]


Do whatever you see fit to do.  Any DFSG-compatible license you choose 
will be fine with me.  Please, notice that my @debian.org email address 
does not exist anymore.


Thanks,

Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740984: [pkg-octave/master] scripts/pkg/private/fix_depends.m: Fix installing packages where dependency name contains '-'

[Rafael Laboissiere]

tag 740984 pending
thanks

Date: Mon Mar 10 13:57:48 2014 +0100
Author: Rafael Laboissiere raf...@laboissiere.net
Commit ID: b376eda9a11fb685d96d5f259cec35cc18feb48f
Commit URL: 
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff;h=b376eda9a11fb685d96d5f259cec35cc18feb48f
Patch URL: 
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff_plain;h=b376eda9a11fb685d96d5f259cec35cc18feb48f

scripts/pkg/private/fix_depends.m: Fix installing packages where dependency 
name contains '-'

This is an empty commit, just to ensure that we will not forget to add
the bug closing tag for this upstream fix in debian/changelog.

Closes: #740984
  


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736392: octave-plplot: FTBFS with Octave 3.8

[Rafael Laboissiere]

* Matthias Klose d...@ubuntu.com [2014-02-26 15:07]:


Am 26.02.2014 14:15, schrieb Rafael Laboissiere:


Is there a simple way to get your 5.10.0 preliminary package, for instance by 
using dget?


found in this ppa:

deb http://ppa.launchpad.net/doko/toolchain/ubuntu trusty main 
deb-src http://ppa.launchpad.net/doko/toolchain/ubuntu trusty main


just the package: https://launchpad.net/~doko/+archive/toolchain/+packages 
and look for the plplot dsc file.


I did now comment out the octave-plplot binary package in the control file for 
now.


I did a quick look at this.  It seems that the Octave binding to PLplot 
is not in a very good shape.  I am not following the upstream development 
anymore and I cannot tell whether is is really actively maintained or 
not.


At any rate, it is perhaps better for now to disable the octave-plplot 
package in Debian, as you did in your Ubuntu package.  Could you please 
propagate this change into Debian?  This will help with the octave 
3.6 - 3.8 transition.


Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736392: octave-plplot: FTBFS with Octave 3.8

[Rafael Laboissiere]

* Matthias Klose d...@ubuntu.com [2014-02-25 16:44]:


Am 25.02.2014 12:08, schrieb Matthias Klose:

trying to fix this in Ubuntu trusty (14.04), ...

 - applied the octave patch in swig2.0 (2.0.11-1ubuntu2)
 - plplot still fails to build, apparently with the
   very same error messages.
   https://launchpad.net/ubuntu/+source/plplot/5.9.9-5ubuntu8

Is there anything additional needed?


with a quickly updated 5.10.0, I don't see the build failure anymore, however 
the octave tests hang ...


did work around it, and built some test packages at: 
https://launchpad.net/~doko/+archive/toolchain/+sourcepub/3940349/+listing-archive-extra


tracking issues at 
https://bugs.launchpad.net/ubuntu/+source/plplot/+bug/1284689


could you point me at the changes required for 5.9.9 to build using octave-3.8?


Is there a simple way to get your 5.10.0 preliminary package, for 
instance by using dget?


Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736413: [xmds-devel] missing licenses in debian/copyright

[Rafael Laboissiere]

* Graham Dennis graham.den...@anu.edu.au [2014-01-29 16:09]:


[snip]

I have rewritten the offending code, which I release under the same 
license as the rest of XMDS2, i.e. GPL2.


Great, thanks, this was the critical issue.  I will soon release a new 
version of the package with the changes, and xmds2 will hopefully be able 
to migrate into Debian testing.


Best,

Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736413: missing licenses in debian/copyright

[Rafael Laboissiere]

Dear XMDS developers,

A bug with severity level serious has been filed against the Debian 
package for xmds2, regarding the licensing conditions of several files. 
You can find the details in http://bugs.debian.org/736413 (BTW, thanks to 
Thorsten Alteholz, who had the patience of verifying the licensing 
conditions of the files in the Debian xmds2 package).


The package is currently unsuitable for inclusion in Debian, because it 
violates the DFSG (Debian Free Software Guidelines).  In order to avoid 
the exclusion of xmds2, we must address the problems indicated in the bug 
report:


* Thorsten Alteholz alteh...@debian.org [2014-01-23 13:03]:

please add the licenses of xmds-2.2.0/documentation/_static/* to 
debian/copyright. Most of these files are not GFDL.


Files *.css and *.js come from third-party projects, like Sphinx, jQuery 
and Underscore, which have DFSG-compliant licenses.  The file 
pygments.css has no copyright notice, but I think it is generated by 
Sphinx, so we are fine here.


There are several image files in documentation/_static/ whose licensing 
conditions are not clear.  I think that most of them come from Sphinx. 
As regards the ones specific from XMDS, like xmds_logo.png, I will assume 
that they are released under the GFDL.


xmds-2.2.0/documentation/latex/tabulary.sty seems to be LPPL, can you 
please check that this is really under v1.3


I can address this issue by removing the *.sty and *.cls files from the 
upstream tarball and repacking it.  At any rate, these files are not 
needed for the xmds2-doc package.


Parts of Vectors/VectorInitialisationFromXSIL.tmpl and thus 
Vectors/VectorInitialisationFromXSIL.py are licensed under APSL which 
is not compatible with DFSG. Can you please check with upstream?


This is really annoying since the APSL is really DFSG-incompatible, see:

https://wiki.debian.org/DFSGLicenses#Licenses_that_are_DFSG-incompatible

If this issue cannot be addressed, then xmds2 will never migrate into 
Debian stable.


If I understand correctly the situation, the C code scrap in 
VectorInitialisationFromXSIL.tmpl that was imported from CFByteOrder.h 
(which is released under the APSL v2), is included in the .cc file 
generated by xmds2 only if the input simulation file contains:


 initialisation kind=xsil

Simulation files with the above definition only work if XMDS1 is 
installed.  Do you think that we can drop the support for kind=xsil in 
the Debian package?  This would make the pacakge fully DFSG-compliant.


Another solution is to replace the offending parts of 
VectorInitialisationFromXSIL.tmpl by some free code.


Best,

Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736392: octave-plplot: FTBFS with Octave 3.8

[Rafael Laboissiere]

Package: octave-plplot
Version: 5.9.9-5+b1
Severity: serious
Tags: upstream
Justification: fails to build from source
Control: block 735557 by -1

The current version of the plplot package FTBFS when built against the 
octave package 3.8.0-2, currently in experimental.  This will block the 
transition of octave 3.6 - 3.8, as required in Bug#735557.


This problem with the upstream sources of plplot happens because there 
was a change in the header file version.h of Octave that triggered a bug 
in SWIG [1], the wrapper used for generating the Octave binding for 
PLplot.  The SWIG developpers have fixed this bug in Git [2] and 
announced that this fix will be included in the next release [3].  I 
suppose that a simple recompilation of plplot against the forthcoming 
release of SWIG will fix the present bug.


Rafael

[1] http://sourceforge.net/p/swig/bugs/1353/ 
[2] https://github.com/swig/swig/commit/5b167cc12daf9ea275c17fedaefc975450613ab2.patch 
[3] http://sourceforge.net/mailarchive/message.php?msg_id=31845761


-- System Information: 
Debian Release: jessie/sid 
  APT prefers testing 
  APT policy: (650, 'testing'), (600, 'unstable'), (550, 'stable'), (500, 'experimental') 
Architecture: i386 (i686)


Kernel: Linux 3.10-rc7-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696377: octave3.2: 35 octave-* packages fail to upgrade from lenny to squeeze: octave3.0: error while loading shared libraries: liblapack.so.3gf: cannot open shared object file: No such file or di

[Rafael Laboissiere]

* Thomas Weber twe...@debian.org [2012-12-23 18:09]:


On Thu, Dec 20, 2012 at 07:08:27AM +0100, Andreas Beckmann wrote:


Package: octave3.2 
Version: 3.2.4-8 
Severity: serious 
Tags: squeeze 
User: debian...@lists.debian.org 
Usertags: piuparts 
Control: affects -1 + octave-ad octave-zenity


during a test with piuparts I noticed many octave packages failing to 
upgrade from lenny to squeeze.


To be honest, I don't quite see the value of checking for upgrades from 
lenny to squeeze at this point of the release cycle - octave3.0 was 
removed in 2010. Putting it another way, how many users do we help by 
fixing this issue now?


I am curious: why is this bug popping out only now?  Why was it not discovered 
during the release cycle of squeeze?


Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695551: [Pkg-octave-devel] Bug#695551: panic: segfault at startup

[Rafael Laboissiere]

package octave 
tags 695551 unreproducible moreinfo 
stop


* Drew Parsons dpars...@debian.org [2012-12-10 13:03]:


Package: octave 
Version: 3.6.2-5 
Severity: grave 
Justification: renders package unusable


octave has just started failing to start, with the error message:

$ octave -q 
panic: Segmentation fault -- stopping myself... 
attempting to save variables to `octave-core'... 
save to `octave-core' complete 
Segmentation fault 
$ echo $? 
139


(so octave exits immediately with error code 139.)

The bug appears also in 3.6.3-2.

[snip]


I cannot reproduce this bug on my amd64 testing system.  We need more 
information on your problem.  As a first step, could you please check 
Bug#695434?


Thanks,

Rafael


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#681064: [Pkg-octave-devel] Bug#681064: octave: does not configure properly

[Rafael Laboissiere]

* Santiago Vila sanv...@unex.es [2012-07-11 16:02]:

 On Tue, 10 Jul 2012, Rafael Laboissiere wrote:
 
  I suspect that your system has some file left over from another package
  that may be causing the problem.  If this is true, then what you are
  reporting is a real bug that must be fixed, but it is perhaps not caused
  by the octave package.
 
 I can assure that there is a real bug here, because this happened on
 twenty different computers at work, and everything I did was normal,
 i.e. apt-get update, apt-get upgrade, apt-get dist-upgrade,
 dpkg --purge not-needed-package, etc.
 
 I will not change the severity again because I don't want to start a
 bug severity war, but I still think this bug deserves a freeze exception
 (i.e. it should be RC).
 
 After the analysis by Thomas Weber, do you still need a precise way to
 reproduce this?

At any rate, the following is a reproducible bug:

$ sudo rmdir /usr/share/octave/packages/
$ sudo octave --silent --no-history --no-init-file --no-window-system 
--eval pkg ('rebuild');
error: could not find the file or path /usr/share/octave/packages
error: called from:
error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 1234, column 5
error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 418, column 16
error:   /usr/share/octave/3.6.2/m/startup/octaverc at line 26, column 1

I think that this is an upstream problem and I agree with you that this
bug deserves a freeze exception.  Sébastien has already set the severity
level to serious again.

For fixing the bug, I propose the patch attached below, that changes the
code in pkg.m.  To the other members of the DOG: please, tell me what you
think about the patch.  I am also wondering what we should do now. 
Should we create a wheezy branch in our Git repository and make an
RC-fixing release with version number, say, 3.6.2-2.wheezy.1?

Rafael
Description: Create packages directory, if is does not exist
 This package avoids failing errors when pkg('rebuild') is called and
 the /usr/share/octave/packages does not exist.  Note that a similar
 code exists already in pkg.m when treating the directory in archprefix.
Author: Rafael Laboissiere raf...@laboissiere.net
Bug-Debian: http://bugs.debian.org/681064
Forwarded: no
Last-Update: 2012-07-11

--- octave-3.6.2.orig/scripts/pkg/pkg.m
+++ octave-3.6.2/scripts/pkg/pkg.m
@@ -415,7 +415,13 @@ function [local_packages, global_package
 global_packages = archprefix;
   elseif (length (files) = 1  nargout = 2  ischar (files{1}))
 prefix = files{1};
-prefix = absolute_pathname (prefix);
+try
+  prefix = absolute_pathname (prefix);
+catch
+  mkdir (prefix);
+  warning (creating the directory %s\n, prefix);
+  prefix = absolute_pathname (prefix);
+end_try_catch
 local_packages = prefix;
 user_prefix = true;
 if (length (files) = 2  ischar (files{2}))

Bug#681064: [Pkg-octave-devel] Bug#681064: Bug#681064: octave: does not configure properly

[Rafael Laboissiere]

* Jordi Gutiérrez Hermoso jord...@octave.org [2012-07-11 13:02]:

 On 11 July 2012 12:44, Rafael Laboissiere raf...@laboissiere.net wrote:
  At any rate, the following is a reproducible bug:
 
  $ sudo rmdir /usr/share/octave/packages/
  $ sudo octave --silent --no-history --no-init-file --no-window-system 
  --eval pkg ('rebuild');
  error: could not find the file or path /usr/share/octave/packages
  error: called from:
  error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 1234, column 5
  error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 418, column 16
  error:   /usr/share/octave/3.6.2/m/startup/octaverc at line 26, column 1
 [snip]
  For fixing the bug, I propose the patch attached below, that changes the
  code in pkg.m.
 
 I'm not sure the fix in the catch block is right. What if creating the
 directory fails? Or do we know at that point that this is a writable
 location?

Well, in pkg.m we have already this:

try
  archprefix = absolute_pathname (archprefix);
catch
  mkdir (archprefix);
  warning (creating the directory %s\n, archprefix);
  archprefix = absolute_pathname (archprefix);
end_try_catch

My fix regarding the prefix variable was inspired in the code above.
Your criticisms would also apply to this.

BTW, should we move this discussion to the octave-maintainers mailing
list?

Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#681064: [Pkg-octave-devel] Bug#681064: Bug#681064: Bug#681064: octave: does not configure properly

[Rafael Laboissiere]

* Rafael Laboissiere raf...@laboissiere.net [2012-07-11 19:58]:

 * Jordi Gutiérrez Hermoso jord...@octave.org [2012-07-11 13:02]:
 
  On 11 July 2012 12:44, Rafael Laboissiere raf...@laboissiere.net wrote:
   At any rate, the following is a reproducible bug:
  
   $ sudo rmdir /usr/share/octave/packages/
   $ sudo octave --silent --no-history --no-init-file --no-window-system 
   --eval pkg ('rebuild');
   error: could not find the file or path /usr/share/octave/packages
   error: called from:
   error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 1234, column 5
   error:   /usr/share/octave/3.6.2/m/pkg/pkg.m at line 418, column 16
   error:   /usr/share/octave/3.6.2/m/startup/octaverc at line 26, 
   column 1
  [snip]
   For fixing the bug, I propose the patch attached below, that changes the
   code in pkg.m.
  
  I'm not sure the fix in the catch block is right. What if creating the
  directory fails? Or do we know at that point that this is a writable
  location?
 
 Well, in pkg.m we have already this:
 
 try
   archprefix = absolute_pathname (archprefix);
 catch
   mkdir (archprefix);
   warning (creating the directory %s\n, archprefix);
   archprefix = absolute_pathname (archprefix);
 end_try_catch
 
 My fix regarding the prefix variable was inspired in the code above.
 Your criticisms would also apply to this.
 
 BTW, should we move this discussion to the octave-maintainers mailing
 list?

I submitted a bug report (#36830) about this bug on the Savannah bug
tracker.

Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676614: octave: Installation failure during setup phase

[Rafael Laboissiere]

package octave
reassign 676614 libatlas3-base 3.8.4-5
tags 676614 - unreproducible
tags 676614 + patch
thanks

* Sébastien Villemot sebastien.ville...@ens.fr [2012-06-08 11:02]:

 Arnaud Installe insta...@gmail.com writes:
 
  Package: octave
  Version: 3.6.2-1
  Severity: grave
  Justification: renders package unusable
 
  Dear Maintainer,
 
  I get the following error when trying to upgrade to the latest
  (unstable)
  version of octave:
 
  ==
  Setting up octave (3.6.2-1) ...
  octave: error while loading shared libraries: libblas.so.3gf: cannot
  open
  shared object file: No such file or directory
  dpkg: error processing octave (--configure):
   subprocess installed post-installation script returned error exit
  status 127
  ==
 
  This is caused by a transition from libblas3gf to libblas3. The latest
  libblas3gf package is a transitional, dummy package simply referring to
  libblas3. Due to this name change, the libblas3gf.so.3 library isn't
  available
  any more. Octave should be updated to accomodate this transition.
 
 The blas package provides a compatibility symlink for libblas.so.3gf, so
 octave needs not to be recompiled to accomodate this transition. On my
 system the upgrade went smoothly.
 
 Can you please send the result of:
 
  sudo update-alternatives --display libblas.so.3 
 
 On my system this command gives:
 
 libblas.so.3 - auto mode
   link currently points to /usr/lib/openblas-base/libopenblas.so.0
 /usr/lib/atlas-base/atlas/libblas.so.3 - priority 35
   slave libatlas.so.3: /usr/lib/atlas-base/libatlas.so.3
   slave libblas.so.3gf: /usr/lib/atlas-base/libblas.so.3
   slave libcblas.so.3: /usr/lib/atlas-base/libcblas.so.3
   slave libf77blas.so.3: /usr/lib/atlas-base/libf77blas.so.3
   slave liblapack_atlas.so.3: /usr/lib/atlas-base/liblapack_atlas.so.3
 /usr/lib/libblas/libblas.so.3 - priority 10
   slave libblas.so.3gf: /usr/lib/libblas/libblas.so.3
 /usr/lib/openblas-base/libopenblas.so.0 - priority 40
   slave libblas.so.3gf: /usr/lib/openblas-base/libopenblas.so.0
 Current 'best' version is '/usr/lib/openblas-base/libopenblas.so.0'.
 
 As you can see, there is a slave alternative providing libblas.so.3gf.

If the libopenblas-base package is removed and only libatlas3-base is
kept in the system (which satisfies, BTW, the octave dependencies), then
the failure reported above can be reproduced:

$ octave
octave: error while loading shared libraries: libblas.so.3gf: cannot open 
shared object file: No such file or directory

The problem comes from libatlas3-base and I am hereby reassiging this bug
report to that package.  A trivial patch for fixing the problem is
attached below.

Rafael
Index: debian/libatlas3-base.postinst
===
--- debian/libatlas3-base.postinst	(revision 44994)
+++ debian/libatlas3-base.postinst	(working copy)
@@ -14,7 +14,7 @@
 --slave /usr/lib/liblapack_atlas.so.3 liblapack_atlas.so.3   \
 /usr/lib/atlas-base/liblapack_atlas.so.3 \
 --slave /usr/lib/libblas.so.3gf libblas.so.3gf   \
-/usr/lib/atlas-base/libblas.so.3 
+/usr/lib/atlas-base/atlas/libblas.so.3 
 
 update-alternatives --install /usr/lib/liblapack.so.3 liblapack.so.3 \
 /usr/lib/atlas-base/atlas/liblapack.so.3 35  \

Bug#562316: xmds-doc: FTBFS: make[2]: epstopdf: Command not found

[Rafael Laboissiere]

* Lucas Nussbaum lu...@lucas-nussbaum.net [2009-12-24 11:50]:

 Source: xmds-doc
 Version: 0~svn.1884-2
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20091213 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part:
  make[1]: Entering directory 
  `/build/user-xmds-doc_0~svn.1884-2-amd64-G6zORG/xmds-doc-0~svn.1884/latex'
  /usr/bin/make --directory=figures
  make[2]: Entering directory 
  `/build/user-xmds-doc_0~svn.1884-2-amd64-G6zORG/xmds-doc-0~svn.1884/latex/figures'
  epstopdf advectionMatlabPlot.eps
  make[2]: epstopdf: Command not found
  make[2]: *** [advectionMatlabPlot.pdf] Error 127

This is caused by the fact that the epstopdf program was moved from the
texlive-extra-utils into the texlive-font-utils in unstable.  Adding the
later to Build-Depends-Indep should fix the present bug.

I am no more a DD, so if a good soul from the Debian Scientific Computing
Team is lurking this bug report, please fix it.

Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* John W. Eaton j...@jweaton.org [2009-06-17 14:24]:

 Are you sure you would want this?  It won't tell you if the printing
 is correct without manual inspection, and will clutter the output from
 running make check with
 
 src/pr-output.cc ...ans =  0 + 0i
   ans =0 + Infi
   ans =0 - Infi
   ans =0 + NaNi
   ans = Inf +   0i
   ans = Inf + Infi
   ans = Inf - Infi
   ans = Inf + NaNi
   ans = -Inf +   0i
   ans = -Inf + Infi
   ans = -Inf - Infi
   ans = -Inf + NaNi
   ans = NaN +   0i
   ans = NaN + Infi
   ans = NaN - Infi
   ans = NaN + NaNi
PASS1/1   
 
 Is there another way to test this without printing the output to the
 sreen?  Maybe use fdisp to put the output in a file and then compare
 the contents of the file to some expected value?

That would be surely better.  Actually, in the specific case I had in
mind (NaN problem on mips/mipsel) there would be no need to compare the
output, just to exercise the code in pr-output.cc.  So, the test could
be, for now:

/* 
%!test
%! format short
%! file = tempname ()
%! fd = fopen (file)
%! for r = [0, Inf -Inf, NaN]
%! for i = [0, Inf -Inf, NaN]
%! fdisp (fd, complex (r, i))
%! endfor
%! endfor
%! fclose (fd)
%! unlink (file)
*/ 

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-14 22:45]:

 Now, I am wondering whether the code in set_format() makes sense.  The
 function reads:
 
 ///
 static void
 set_format (const Complex c, int r_fw, int i_fw)
 {
   // [snip]
 
   double rp = c.real ();
   double ip = c.imag ();
 
   bool inf_or_nan = (xisinf (c) || xisnan (c));
 
   bool int_only = (D_NINT (rp) == rp  D_NINT (ip) == ip);
 
   double r_abs = rp  0.0 ? -rp : rp;
   double i_abs = ip  0.0 ? -ip : ip;
   
  
   int r_x = r_abs == 0.0 
 ? 0 : static_castint (floor (log10 (r_abs) + 1.0));
 
   // [snip]
 ///
 
 When r_abs is NaN (as in the bug-triggering case) what is the sense of
 computing log10 (r_abs) and propagating the result?  I am probably
 missing something but it seems just pure chance that r_x ends up being
 negative on amd64 and i386, what does not trigger the bug.

Attached below is a patch for pr-output.cc that makes Octave work as
expected for 'complex(NaN,0)' on mips (and amd64 as well, FWIW).  The
package is being built right now on mips and on amd64 and, if everything
goes well on both arches, I will upload to unstable a new version of the
package, octave3.2_3.2.0-2, containing the patch.

I am rushing with this because everything else is being held by this bug,
like the upload of the new octave-forge packages.

-- 
Rafael
--- a/pr-output.cc	2009-06-15 08:48:48.0 +0200
+++ b/pr-output.cc	2009-06-15 11:28:58.0 +0200
@@ -852,10 +852,12 @@
   double i_abs = ip  0.0 ? -ip : ip;
 
   int r_x = r_abs == 0.0
-? 0 : static_castint (floor (log10 (r_abs) + 1.0));
+? 0 : ((xisinf (rp) || xisnan (rp))
+	   ? INT_MIN : static_castint (floor (log10 (r_abs) + 1.0)));
 
   int i_x = i_abs == 0.0
-? 0 : static_castint (floor (log10 (i_abs) + 1.0));
+? 0 : ((xisinf (ip) || xisnan (ip))
+	   ? INT_MIN : static_castint (floor (log10 (i_abs) + 1.0)));
 
   int x_max, x_min;
 

Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* John W. Eaton j...@jweaton.org [2009-06-15 09:31]:

 To be consistent with what is done int set_format (double, ...), I
 think this should be
 
 diff --git a/src/pr-output.cc b/src/pr-output.cc
 --- a/src/pr-output.cc
 +++ b/src/pr-output.cc
 @@ -851,10 +851,10 @@
double r_abs = rp  0.0 ? -rp : rp;
double i_abs = ip  0.0 ? -ip : ip;
  
 -  int r_x = r_abs == 0.0
 +  int r_x = (xisinf (rp) || xisnan (rp) || xr_abs == 0.0)
  ? 0 : static_castint (floor (log10 (r_abs) + 1.0));
  
 -  int i_x = i_abs == 0.0
 +  int i_x = (xisinf (ip) || xisnan (ip) || i_abs == 0.0)
  ? 0 : static_castint (floor (log10 (i_abs) + 1.0));
  
int x_max, x_min;
 
 
 Does that work for you?

Thanks for the patch.  I will try it on mips as soon as the current build
will finish (it takes forever on this kind of hardware...).

Your solution is probably better.  In my patch, the use of INT_MIN was
intended to mimic the result of floor (log10 (NaN) + 1.0) on i386 and
amd64.  But a value of 0 as you suggest will probably work fine.

Anyway, it is funny to see how long this bug lived in the code and was
just awakened by the crappy mips/mipsel architecture...

 Similar changes may be needed in other functions in case all the
 elements of a matrix are NaN, for example.

As I wrote before, if my patch makes the package build and check
correctly on mips, I think I will do the upload with it, without waiting
for a full solution to the problem.  This bug is blocking the progress on
the octave-forge packages.

Cheers,

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* John W. Eaton j...@jweaton.org [2009-06-15 13:25]:

 On 15-Jun-2009, Rafael Laboissiere wrote:
 
 | Anyway, it is funny to see how long this bug lived in the code and was
 | just awakened by the crappy mips/mipsel architecture...
 
 Also strange that it didn't show up until now, even on mips.  Maybe a
 compiler change?

Probably.

Anyway, these differences on floating point representation/manipulation
among the architectures make me kinda nervous.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-15 21:55]:

 * John W. Eaton j...@jweaton.org [2009-06-15 13:25]:
 
  On 15-Jun-2009, Rafael Laboissiere wrote:
  
  | Anyway, it is funny to see how long this bug lived in the code and was
  | just awakened by the crappy mips/mipsel architecture...
  
  Also strange that it didn't show up until now, even on mips.  Maybe a
  compiler change?
 
 Probably.
 
 Anyway, these differences on floating point representation/manipulation
 among the architectures make me kinda nervous.

I am wondering whether we could add a regression test like the following
to data.cc (or wherever):

/*
%!test
%! format short
%! for r = [0, Inf -Inf, NaN]
%! for i = [0, Inf -Inf, NaN]
%! complex (r, i)
%! endfor
%! endfor
*/

Yes, the 'complex (r, i)' would lack the semicolon, just to exercise the
code in pr-output.cc.
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-13 09:15]:

 So, even if log2 returns a wrong value, the bug happens elsewhere. At any
 rate, the following works as expected:
 
 complex (NaN, NaN)
 complex (0, NaN)
 complex (NaN, Inf)
 
 I am puzzled with this problem and I cannot really debug it, since I am
 not versed in GDB.  The bug arises at line 1442 of pr-output.cc, in
 function pr_complex():
 
 pr_imag_float (os, i, i_fw); 


I think I found the culprit but I am stuck with the debugging (see
below). If I set a breakpoint at line 703 of pr-output.cc, I see the
following when I launch complex(NaN,0) at the octave prompt under gdb:

Breakpoint 4, set_complex_format (x_max=2147483647, x_min=0, 
r_x=2147483647, inf_or_nan=true, int_only=0, 
r_...@0x7facdd70, i_...@0x7facdd74) at pr-output.cc:703
703   int prec = Voutput_precision;

On my amd64 system I see the following, instead:

Breakpoint 6, set_complex_format (x_max=0, x_min=-2147483648, 
r_x=-2147483648, inf_or_nan=true, int_only=0, 
r_...@0x7fffd1dd6afc, i_...@0x7fffd1dd6af8) at pr-output.cc:703
703   int prec = Voutput_precision;

I think that the different values of x_max and x_min explain the bug on
the mips system.  I guess that this is caused by the following lines in
pr-output.cc (function set_format):

  int x_max = max_abs == 0.0
   
? 0 : static_castint (floor (log10 (max_abs) + 1.0)); 
   

   
  int x_min = min_abs == 0.0
   
? 0 : static_castint (floor (log10 (min_abs) + 1.0)); 
   
 
However, I cannot debug the problem because the variables are not
visible from gdb and many things seem to be inlined.

Would it be possible to write a simple C++ test program that would expose
the problem on mips?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-14 12:25]:

 I think that the different values of x_max and x_min explain the bug on
 the mips system.  I guess that this is caused by the following lines in
 pr-output.cc (function set_format):
 
   int x_max = max_abs == 0.0  
  
 ? 0 : static_castint (floor (log10 (max_abs) + 1.0));   
  
   
  
   int x_min = min_abs == 0.0  
  
 ? 0 : static_castint (floor (log10 (min_abs) + 1.0));   
  

I meant lines 854 to 858 in pr-output.cc, in function 
set_format (const Complex c, int r_fw, int i_fw)

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-14 15:39]:

 * Rafael Laboissiere raf...@debian.org [2009-06-14 12:25]:
 
  I think that the different values of x_max and x_min explain the bug on
  the mips system.  I guess that this is caused by the following lines in
  pr-output.cc (function set_format):
  
int x_max = max_abs == 0.0
 
  ? 0 : static_castint (floor (log10 (max_abs) + 1.0)); 
 
  
 
int x_min = min_abs == 0.0
 
  ? 0 : static_castint (floor (log10 (min_abs) + 1.0)); 
 
 
 I meant lines 854 to 858 in pr-output.cc, in function 
 set_format (const Complex c, int r_fw, int i_fw)

I think I found the cause of the bug.  The simple program:

///
#include cmath
#include iostream

int
main (void)
{
std::cerr  static_castint (floor (log10 (0.0/0.0)))  std::endl;
return 0;
}
///

when compiled on mips yields 2147483647, while on amd64 and i386 it
yields -2147483648.  This explains the different behavior on both
architectures.

Now, I am wondering whether the code in set_format() makes sense.  The
function reads:

///
static void
set_format (const Complex c, int r_fw, int i_fw)
{
  // [snip]

  double rp = c.real ();
  double ip = c.imag ();

  bool inf_or_nan = (xisinf (c) || xisnan (c));

  bool int_only = (D_NINT (rp) == rp  D_NINT (ip) == ip);

  double r_abs = rp  0.0 ? -rp : rp;
  double i_abs = ip  0.0 ? -ip : ip;

   
  int r_x = r_abs == 0.0 
? 0 : static_castint (floor (log10 (r_abs) + 1.0));

  // [snip]
///

When r_abs is NaN (as in the bug-triggering case) what is the sense of
computing log10 (r_abs) and propagating the result?  I am probably
missing something but it seems just pure chance that r_x ends up being
negative on amd64 and i386, what does not trigger the bug.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-12 23:09]:

 * John W. Eaton j...@jweaton.org [2009-06-12 13:20]:
 
  On 11-Jun-2009, Rafael Laboissiere wrote:
  | (gdb) bt
  | #0  0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, 
  std::char_traitschar  ::_M_insert_floatdouble () from 
  /usr/lib/libstdc++.so.6
  | #1  0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, 
  std::char_traitschar  ::do_put () from /usr/lib/libstdc++.so.6
  | #2  0x2e18fd44 in std::ostream::_M_insertdouble () from 
  /usr/lib/libstdc++.so.6
  | #3  0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out)
  | at /usr/include/c++/4.3/ostream:214
  | #4  0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, 
  d=2.2661800709135971, fw=0)
  | at pr-output.cc:1394
  | #5  0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, 
  | r_fw=value optimized out, i_fw=0, scale=value optimized out) at 
  pr-output.cc:1412
  | #6  0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at 
  pr-output.cc:1958
  
  Can you move to this frame and examine the value of C?
 
 Breakpoint 2, octave_print_internal (o...@0x4328b0, c...@0x455cc8) at 
 pr-output.cc:1958
 1958  pr_complex (os, c);
 Current language:  auto; currently c++
 (gdb) print c
 $1 = (const Complex ) @0x455cc8: {_M_value = nan(0x7) + 
 2.2661800709135971 * I}

The real part should be Inf, not NaN, right?  I discovered that the octave
on mips also hungs for this :

complex (NaN, 0)

So, even if log2 returns a wrong value, the bug happens elsewhere. At any
rate, the following works as expected:

complex (NaN, NaN)
complex (0, NaN)
complex (NaN, Inf)

I am puzzled with this problem and I cannot really debug it, since I am
not versed in GDB.  The bug arises at line 1442 of pr-output.cc, in
function pr_complex():

pr_imag_float (os, i, i_fw); 

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression t

[Rafael Laboissiere]

* John W. Eaton j...@jweaton.org [2009-06-12 13:20]:

 On 11-Jun-2009, Rafael Laboissiere wrote:
 | (gdb) bt
 | #0  0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, 
 std::char_traitschar  ::_M_insert_floatdouble () from 
 /usr/lib/libstdc++.so.6
 | #1  0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, 
 std::char_traitschar  ::do_put () from /usr/lib/libstdc++.so.6
 | #2  0x2e18fd44 in std::ostream::_M_insertdouble () from 
 /usr/lib/libstdc++.so.6
 | #3  0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out)
 | at /usr/include/c++/4.3/ostream:214
 | #4  0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, 
 d=2.2661800709135971, fw=0)
 | at pr-output.cc:1394
 | #5  0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, 
 | r_fw=value optimized out, i_fw=0, scale=value optimized out) at 
 pr-output.cc:1412
 | #6  0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at 
 pr-output.cc:1958
 
 Can you move to this frame and examine the value of C?

Breakpoint 2, octave_print_internal (o...@0x4328b0, c...@0x455cc8) at 
pr-output.cc:1958
1958pr_complex (os, c);
Current language:  auto; currently c++
(gdb) print c
$1 = (const Complex ) @0x455cc8: {_M_value = nan(0x7) + 
2.2661800709135971 * I}

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]:

 * Peter De Schrijver p...@debian.org [2009-06-10 19:40]:
 
  Package: octave3.2
  Version: 3.2.0-1
  Severity: serious
  
  There was an error while trying to autobuild your package:
  
   Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999
   Build started at 20090607-1015
 
 Thanks, we are already aware of it.  It also heppens on mipsel.
 
 I am currently investigating the problem using mahler.debian.org.

I got the culprit.  The test of data.cc never returns because the code below
makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever:

log2(complex(0,Inf))
 
Any idea on how to debug this?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-06-11 16:07]:

 * Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]:
 
  * Peter De Schrijver p...@debian.org [2009-06-10 19:40]:
  
   Package: octave3.2
   Version: 3.2.0-1
   Severity: serious
   
   There was an error while trying to autobuild your package:
   
Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999
Build started at 20090607-1015
  
  Thanks, we are already aware of it.  It also heppens on mipsel.
  
  I am currently investigating the problem using mahler.debian.org.
 
 I got the culprit.  The test of data.cc never returns because the code below
 makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever:
 
 log2(complex(0,Inf))

FWIW, the following works:

octave:1 complex(0,Inf)
ans = 0 + Infi

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* John W. Eaton j...@bevo.che.wisc.edu [2009-06-11 11:27]:

 So first, can you determine precisely where Octave is actually
 hannging?  Does the following program work, or does it also hang in
 the same way?
 
   #include cmath
   #include complex
   #include iostream
 
   typedef std::complexdouble Complex;
 
   Complex
   xlog2 (const Complex x)
   {
   #if defined (M_LN2)
 static double ln2 = M_LN2;
   #else
 static double ln2 = log (2);
   #endif
 
 return std::log (x) / ln2;
   }
 
   int
   main (void)
   {
 std::complexdouble inf_i (0.0, 1.0/0.0);
 std::cerr  inf_i  std::endl;
 std::complexdouble result = xlog2 (inf_i);
 std::cerr  result  std::endl;
 return 0;
   }
 
 I expect this program to print:
 
   (0,inf)
   (inf,2.26618)
 
 but if it hangs, then I think the problem is in the C++ or C library
 functions, not Octave.

No, it does not hang, but produces the following:

(0,inf)
(nan,nan)

On my Debian sid chroot on amd64, it produces:

(0,inf)
(inf,nan)

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* John W. Eaton j...@octave.org [2009-06-11 15:42]:

 Did you compile the simpler program with the same options used to
 build Octave?

Probably not.

 Can you run Octave under gdb and find where it hangs, either by
 running
 
   log2 (complex (0, inf))
 
 and interrupting it when the hang happens and getting a stack trace,
 or by stepping through the log2 function (and the functions it calls)
 to find where it hangs?

When I run it through ./run-octave -g, the command above does not hang,
but gives immediately this, even when I set a breakpoint at log2:

octave:1 log2 (complex (0, inf))

Program received signal SIGBUS, Bus error.
[Switching to Thread 0x2aad4d80 (LWP 11231)]
0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, 
std::char_traitschar  ::_M_insert_floatdouble () from 
/usr/lib/libstdc++.so.6

Here is the stack:

(gdb) bt
#0  0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, 
std::char_traitschar  ::_M_insert_floatdouble () from 
/usr/lib/libstdc++.so.6
#1  0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, 
std::char_traitschar  ::do_put () from /usr/lib/libstdc++.so.6
#2  0x2e18fd44 in std::ostream::_M_insertdouble () from 
/usr/lib/libstdc++.so.6
#3  0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out)
at /usr/include/c++/4.3/ostream:214
#4  0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, 
d=2.2661800709135971, fw=0)
at pr-output.cc:1394
#5  0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, 
r_fw=value optimized out, i_fw=0, scale=value optimized out) at 
pr-output.cc:1412
#6  0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at 
pr-output.cc:1958
#7  0x2b17d504 in octave_base_scalarstd::complexdouble ::print 
(this=0x2e1fcd60, 
o...@0x20, pr_as_read_syntax=value optimized out) at ov-base-scalar.cc:121
#8  0x2b114d14 in octave_base_value::print_with_name (this=0x455cc0, 
output_b...@0x4328b0, 
name=value optimized out, print_padding=true) at ov-base.cc:358
#9  0x2b0d1450 in bind_ans (v...@0x7faa61a8, print=true) at ov.h:961
#10 0x2b36a1a0 in tree_evaluator::visit_statement (this=0x2bac17dc, 
stmt=value optimized out) at pt-eval.cc:698
#11 0x2b366174 in tree_evaluator::visit_statement_list (this=0x2bac17dc, 
l...@0x595ca0)
at pt-eval.cc:731
#12 0x2b0bba84 in main_loop () at toplev.cc:570
#13 0x2b02bd1c in octave_main (argc=6, argv=0x7faa6544, embedded=0) at 
octave.cc:878
#14 0x2e266bac in __libc_start_main () from /lib/libc.so.6
#15 0x004009e8 in _ftext ()

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Peter De Schrijver p...@debian.org [2009-06-10 19:40]:

 Package: octave3.2
 Version: 3.2.0-1
 Severity: serious
 
 There was an error while trying to autobuild your package:
 
  Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999
  Build started at 20090607-1015

Thanks, we are already aware of it.  It also heppens on mipsel.

I am currently investigating the problem using mahler.debian.org.

Cheers,

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532693: [Pkg-scicomp-devel] Bug#532693: libsuitesparse-dev and libsofa1-dev: error when trying to install together

[Rafael Laboissiere]

* Ralf Treinen trei...@free.fr [2009-06-10 21:25]:

 Package: libsofa1-dev,libsuitesparse-dev
 Version: libsofa1-dev/1.0~beta4-1
 Version: libsuitesparse-dev/1:3.4.0-1
 Severity: serious
 User: trei...@debian.org
 Usertags: edos-file-overwrite
 
 Date: 2009-06-10
 Architecture: amd64
 Distribution: sid
 
 [snip]

 Here is a list of files that are known to be shared by both packages
 (according to the Contents file for sid/amd64, which may be slightly
 out of sync):
 
   usr/lib/libcsparse.so

This library is built from the a version of SuiteSparse's CSparse
library.  More precisely, the file extlibs/csparse/csparse.c in
sofa-framework is a like a concatenation of the files CSparse/Source/*.c
in the suitesparse package.

I tried to build sofa-framework against libsuitesparse-dev using the
simple patch attached below.  However, the compilation fials.  I did not
investigate this issuedeeply, but it seems that extlibs/csparse/csparse.c
contains an old version of SuiteSparse's CSparse.

I see the following solutions for this:

1) Ask the upstream authors to link agaisnt SuiteSparse instead of
   shipping a copy of the CSparse library and adapt their code for working
   with a modern version of the library.
   
2) Link against an internal version of CSparse but put it somewhere else
   (e.g. /usr/lib/sofa/libcsparse*).  I do not now if this is fully
   appropriate for the libcsparse.so symlink included in libsofa1-dev.

Cheers,

-- 
Rafael
--- sofa-framework-1.0~beta4.orig/Sofa.pro
+++ sofa-framework-1.0~beta4/Sofa.pro
@@ -21,7 +21,7 @@
 #CSParse
 
 contains(DEFINES,SOFA_HAVE_CSPARSE){
-	SUBDIRS += extlibs/csparse
+#	SUBDIRS += extlibs/csparse
 }
 
 
--- sofa-framework-1.0~beta4.orig/sofa.cfg
+++ sofa-framework-1.0~beta4/sofa.cfg
@@ -253,7 +253,7 @@
 contains(DEFINES,SOFA_HAVE_CSPARSE){
   SOFA_EXT_LIBS *= -lcsparse$$LIBSUFFIX
   # use csparse headers included in extlibs
-  INCLUDEPATH *= $$SOFA_DIR/extlibs/csparse
+#  INCLUDEPATH *= $$SOFA_DIR/extlibs/csparse
 }
 
 
--- sofa-framework-1.0~beta4.orig/modules/sofa/component/linearsolver/SparseLUSolver.h
+++ sofa-framework-1.0~beta4/modules/sofa/component/linearsolver/SparseLUSolver.h
@@ -32,7 +32,7 @@
 #include sofa/component/linearsolver/FullMatrix.h
 #include sofa/helper/map.h
 #include math.h
-#include csparse.h
+#include suitesparse/cs.h
 
 namespace sofa {
 
--- sofa-framework-1.0~beta4.orig/modules/sofa/component/linearsolver/SparseCholeskySolver.h
+++ sofa-framework-1.0~beta4/modules/sofa/component/linearsolver/SparseCholeskySolver.h
@@ -34,7 +34,7 @@
 #include sofa/component/component.h
 #include sofa/helper/map.h
 #include math.h
-#include csparse.h
+#include suitesparse/cs.h
 
 namespace sofa {
 

Bug#531538: another dangling symlink

[Rafael Laboissiere]

* Raphael Hertzog hert...@debian.org [2009-06-03 08:54]:

 On Tue, 02 Jun 2009, Rafael Laboissiere wrote:
  The libmtp7 package contains the file /etc/udev/rules.d/libmtp7.rules. This
  file is not touched by libmtp8, AFAIK.
  
  On the other hand, libmtp5 seems to be affected by the following offending
  code in postinst:
  
  if dpkg --compare-versions $2 lt-nl 0.3.7-3 ; then
  mv_conffile /etc/udev/$PACKAGE.rules \
  /etc/udev/rules.d/45-$PACKAGE.rules
  fi
  
  I do not remember why the above is necessary.  Could you please refresh my
  memory, Savvas?
 
 (On a somewhat unrelated note) Maybe the udev files should be moved to
 libmtp-common to avoid similar problems in the future and to avoid
 duplication of udev rules if you have several versions of the library
 installed?

I am not sure this would be useful, since the The udev rules file is
versioned now:

$ dpkg -L libmtp8 | grep rules$
/lib/udev/rules.d/45-libmtp8.rules

I think that each libmtpn package will need its specific rules file.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#531538: another dangling symlink

[Rafael Laboissiere]

* Savvas Radevic vice...@gmail.com [2009-06-03 12:51]:

  Rafael, you are right, it probably will. But I'm worried about these:
  (1) Is the remaining /etc/udev/libmtp.rules (and symlink
  /etc/udev/rules.d/libmtp.rules) going to affect libmtp8? We'll have to
  ask upstream I guess.
 
 http://sourceforge.net/tracker/?func=detailatid=809062aid=2800399group_id=158745
 
 Rafael, I have a followup question though. Say for example I have
 libmtp7 and libmtp8 on my machine.
 Does that mean that libmtp7.rules is *only* used with libmtp7, or will
 libmtp8 read that file as well (and vice versa, is libmtp8.rules only
 for libmtp8)? I mean, we install a separate libmtp8.rules for libmtp8,
 is the library linked to only the rules we provide?

I have looked more closely to this issue.  I do not know much of the
internals of udev, but is seems that all the files in /etc/udev/rules.d/
are read when udev is initialized.  It does not seem that different
version of libmtp (say, libmtmp7 and libmtp8) will use different *.rules.
This is beyond libmtp control and is in the realm of udev, it seems.

That said, i am wondering why the libmtp.rules files should be versioned,
as we are doing currently.  Perhaps, the 45-libmpt8.rules files would
work just fine with previous versions (5, 6, and 7) of the package. I
think we must test this.

What do you think?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#531538: another dangling symlink

[Rafael Laboissiere]

* Savvas Radevic vice...@gmail.com [2009-06-02 12:50]:

 I'm not completely sure, but I think the package is missing
 Conflicts and Replaces for older libmtp* packages?
 
 Something like:
 
 Conflicts: libmtp7, libmtp6, libmtp5
 Replaces: libmtp7, libmtp6, libmtp5
 
 ..in debian/control.in and debian/control files.

This is something that should absolutely *_never_* be done with shared
library packages.  Newer SONAME versions do not replace older ones. Some
packages depend on libmtp5, says, because they contain programs that link
against /usr/lib/libmtp.so.5.*.  If you make libmtp6, say, replace
libmtp5, then the library above will be gone and... BOOM! packages
depending on libmtp5 will crash.

This is the very reason we change the package name when a version of the
library is backward-incompatible with previous version.  Those package
_*must_* co-exist in peace in the system.

In sum: never, ever try to implement Conflicts/Replaces as proposed
above.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#531538: another dangling symlink

[Rafael Laboissiere]

[Cc:ing to the BTS, this time, sorry.]

* Savvas Radevic vice...@gmail.com [2009-06-02 15:51]:

 Ah wait, now I get it. Rafael, is Breaks allowed on older libmtp* packages?

No, for the same reason Replaces is not allowed.

 It seems like libmtp5-7 might require the older rules (not in /lib)

The libmtp7 package contains the file /etc/udev/rules.d/libmtp7.rules. This
file is not touched by libmtp8, AFAIK.

On the other hand, libmtp5 seems to be affected by the following offending
code in postinst:

if dpkg --compare-versions $2 lt-nl 0.3.7-3 ; then
mv_conffile /etc/udev/$PACKAGE.rules \
/etc/udev/rules.d/45-$PACKAGE.rules
fi

I do not remember why the above is necessary.  Could you please refresh my
memory, Savvas?

-- 
Rafael




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#528506: octave-ad - Don't cleanup files written outside the build root

[Rafael Laboissiere]

package octave-ad
tags 528506 confirmed
reassign 528506 octave-dev-pkg
thanks

* Bastian Blank wa...@debian.org [2009-05-13 12:45]:

 Package: octave-ad
 Version: 1.0.4-2
 Severity: serious
 
 octave-ad and several other octave packages writes files outside the
 build directory.
 
 The build was done, according to the log[1], in
 /build/buildd/octave-ad-1.0.4/. After the build, a file called
 /build/buildd/octave-ad-1.0.4. was left behind. Contents:
 
 [snip]

This is a bug in octave-dev-pkg, more precisely in file octave-pkg.mk.in.
I am looking at it.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#528522: libsuitesparse-3.2.0: Please link umfpack library with -lamd

[Rafael Laboissiere]

* Adam C Powell IV hazel...@debian.org [2009-05-13 09:34]:

 On Wed, 2009-05-13 at 15:06 +0200, Rafael Laboissiere wrote:
  
  This has been already reported as Bug#526422 and the fix is already in
  Git [1].  I am hereby merging the bug reports accordingly.
 
 I'm sorry, that was careless of me to file this without checking
 existing bugs.

No problem.  I prefer a duplicate bug report than no report at all.  :-)
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: give back drivel on mips and mipsel ?

[Rafael Laboissiere]

* Philipp Kern pk...@debian.org [2009-05-08 11:13]:

 On Fri, May 08, 2009 at 09:51:05AM +0200, Adeodato Simó wrote:
  + Rafael Laboissiere (Fri, 08 May 2009 08:51:05 +0200):
That's caused by a kernel bug on the mipsen buildds. It's not fixed, but
a workaround has been introduced in glibc 2.9-9 or so that enables 
popen()
et al. to work again. :-)
   Is there any chance that this problem is also causing Bug#524745?
  No, I don't think so, since IIRC it also happened in (at least) powerpc
  and armel. Hopefully somebody can confirm that (Phil CC'ed for that).
 
 At that time I happened almost everywhere, so it's certainly not a kernel
 bug on mipsen only.  (I raised that to the bug report.)
 
 I didn't see it again since then, though.  Don't know if nothing octave-ish
 has been retried or if there was a  fix somewhere.

To the best of my knowledge, no buildd of the octave-* packages has been
attempted on mipsel since a while.  I did send a give-back request to
debian-wb-t...@l.d.o, but nothing seems to happen.

I am really frustrated with this bug and I have the impression we
are going nowhere.  I cannot believe that there is something wrong with
the packages, since some of them had successful buildds against
octave3.0, version 1:3.0.5-2:

https://buildd.debian.org/fetch.cgi?pkg=octave-adver=1.0.4-2arch=mipselstamp=1239700431file=log
https://buildd.debian.org/fetch.cgi?pkg=octave-audiover=1.1.2-2arch=mipselstamp=1239700600file=log
https://buildd.debian.org/fetch.cgi?pkg=octave-bioinfover=0.1.1-2arch=mipselstamp=1239700701file=log
https://buildd.debian.org/fetch.cgi?pkg=octave-combinatoricsver=1.0.7-2arch=mipselstamp=1239700838file=log
https://buildd.debian.org/fetch.cgi?pkg=octave-data-smoothingver=1.1.1-2arch=mipselstamp=1239721086file=log

Curiously enough, the builds above were done on April 14, 2009.  The
failed builds due to the hanging octave3.0 postinst script seem to have
happened after that date.  Did anything change on the mipsel autobuilders
around that date? 

-- 
Rafael



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: give back drivel on mips and mipsel ?

[Rafael Laboissiere]

* Luk Claes l...@debian.org [2009-05-09 12:55]:

 Rafael Laboissiere wrote:
 
  I am really frustrated with this bug and I have the impression we
  are going nowhere.  I cannot believe that there is something wrong with
  the packages, since some of them had successful buildds against
  octave3.0, version 1:3.0.5-2:
 
 The bug (and the buildd) was stuck for quite some days on your input on
 how to debug it...
 
 We still don't know what caused it nor what fixed it, but it seems to be
 fixed now, so I'm closing this bug and will give back all packages.

And the first autobuild just completed successfully:

https://buildd.debian.org/fetch.cgi?pkg=octave-financialver=0.3.0-2arch=mipselstamp=1241864949file=log

It is so reassuring!  Thanks for that.  I hope that all autobuilds for
the other  40 packages will also succeed.
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Martin Michlmayr t...@cyrius.com [2009-05-05 11:19]:

 * Thomas Weber thomas.weber.m...@gmail.com [2009-05-05 11:10]:
  On Tue, Apr 28, 2009 at 06:31:32PM +0200, Martin Michlmayr wrote:
   Just for the record, I see the same problem on an amd64 system (Intel
   EM64T chip).
  
  Is this a normal installation or as part of a build process?
 
 build process.  It installs fine in my normal sid chroot.
 
 BTW, I should be able to give people root on this machine if you
 haven't been able to track down the issue yet.

That would be great.  One question: is the bug deterministic or does it
happen randomly?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Rafael Laboissiere raf...@debian.org [2009-05-02 17:42]:

 * Luk Claes l...@debian.org [2009-05-02 14:19]:
 
  There is only one of them really stalled on the buildd, the others just  
  did not get retried. It being stalled is to debug the problem and it's  
  kind of waiting on your input how to debug it AFAIK.
 
 I am afraid, I have no idea on how to debug this, specially if I do not have
 access to the machine.
 
 Ideas are welcome.

Is this problem caused by the popen() bug mentioned in:

http://lists.debian.org/debian-release/2009/05/msg00063.html
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

I am revisiting this buildd problem conerning the postinst script of the
octave3.0.  I see in the buildd status page for mipsel [1], the following:

State: Building (16)

tbb (26d 00:44, 3/7, mayer) octave-communications (18d 00:24, 10/10, rem)
octave-financial (18d 00:24, 11/11, rem) octave-fixed (17d 17:32, 11/11,
mayer) octave-nan (14d 21:44, 11/11, mayer) octave-linear-algebra (14d
21:44, 11/11, mayer) octave-plot (14d 19:05, 11/11, rem) octave-sockets (11d
23:34, 11/11, rem) octave-specfun (11d 23:34, 11/11, rem) zoneminder (10d
07:11, 10/10, mayer) dballe (10d 03:16, 4/9, mayer) protobuf (9d 16:24, 8/9,
mayer) nikwi (9d 06:14, 5/6, mayer) usplash-theme-debian (9d 01:54, tried 7
times, 4/6, mayer) synce-trayicon (1d 15:16, tried 3 times, 10/10)
gurlchecker (1d 10:10, tried 3 times, 10/10) 

[1] https://buildd.debian.org/~luk/status/architecture.php?suite=a=mipsel

If I interpret this correctly, there are at least eight octave-* packages
with the build stalled right now, aren't there?  Either we kill the
processes or we take oportunity to debug the problem.  I think developers
have not access to either rem or mayer, right?  Otherwise, if you
discover anything interesting, please drop me a note.
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Luk Claes l...@debian.org [2009-05-02 14:19]:

 There is only one of them really stalled on the buildd, the others just  
 did not get retried. It being stalled is to debug the problem and it's  
 kind of waiting on your input how to debug it AFAIK.

I am afraid, I have no idea on how to debug this, specially if I do not have
access to the machine.

Ideas are welcome.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Martin Michlmayr t...@cyrius.com [2009-04-28 18:31]:

 Just for the record, I see the same problem on an amd64 system (Intel
 EM64T chip).

Thanks for your report.

This bug is driving me crazy.  It seems to be a random problem and I have
no clue on how to debug this.  Out of desperation, I just upload
octave3.0_3.0.5-3 with some changes in the postinst.  I am not very
optimistic but let us see what happens.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Stephen Gran sg...@debian.org [2009-04-26 18:50]:

 We currently have another process wedged on mayer.debian.org:
 
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 
 ioctl(0, TIOCNXCL unfinished ...
 Process 31649 detached
 sg...@mayer:~$ sudo ls -l /proc/31649/fd
 total 0
 lrwx-- 1 root root 64 2009-04-26 17:41 0 - /dev/pts/2
 lrwx-- 1 root root 64 2009-04-26 17:41 1 - /dev/pts/2
 lrwx-- 1 root root 64 2009-04-26 17:41 2 - /dev/pts/2

I have no access to mayer, so I cannot help much here.  What about:

lsof -p 31649

 I assume this will be some problem with debconf and file descriptors?

Neither octave3.0 nor the octave-forge packages use debconf.
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

Hi,

I am contacting you guys who gave me feedback on Bug#524745.  I asked
debian-admin to install octave3.0 on the sid chroot of some architectures
where the bug happened.  They did it on merulo (ia64) and pescetti
(powerpc).  

I can perfcetly launch octave on those machines and successfully run the
offending command in postinst:

octave-3.0.5 --silent --no-history --no-init-file --eval pkg ('rebuild');

(although not as root).

I am simply lost here and have no idea on how I can debug this random
bug.

Suggestions?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Martin Zobel-Helas zo...@ftbfs.de [2009-04-23 13:17]:

 On Thu Apr 23, 2009 at 12:07:58 +0200, Rafael Laboissiere wrote:
  
  I am simply lost here and have no idea on how I can debug this random
  bug.
 
 As soon as i have that bug again on the buildd, i will inform you, so
 wen can debug together.

Thanks.
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525113: [Pkg-octave-devel] Bug#525113: Bug#525113: Inconsistant complex matrix multiplication

[Rafael Laboissiere]

* Thomas Weber thomas.weber.m...@gmail.com [2009-04-22 23:04]:

 On Wed, Apr 22, 2009 at 12:01:19PM +0200, Laurent Mazet wrote:
  Package: octave3.0
  Version: 1:3.0.1-7
  Arch: i386
  Severity: grave
 
  Hi,
 
  I've just realized that I can multiply a real 2x2 matrix by a complex 
  vector.
 
 Uh, yes. Why shouldn't this work? Or in other words, how do you
 distinguish the real matrix from a complex matrix with its complex
 coefficients being zero
 
 [ 1, 2; 3,4] is the same as [1+0i, 2+0i; 3+0i, 4+0i], isn't it?

I think Laurent meant I've just realized that I CANNOT multiply [...]

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#481786: ttf2tex: freetype1 deprecation

[Rafael Laboissiere]

* Barry deFreese bdefre...@debian.org [2009-04-16 11:27]:

 My apologies but I cannot see keeping freetype1 in Debian just for  
 ttf2tex.  Especially since ttf2tex has not been part of any recent stable 
 releases.

 Do you have any other thoughts or options before I request removal of  
 freetype1 and probably ttf2tex?

ttf2tex is dead upstream [1] and I am not willing to port it to freetype2
or whatever.  Let us just have both freetype1 and ttf2tex removed from
Debian.

[1] http://www.ctan.org/tex-archive/obsolete/support/ttf2tex/README

Thanks,

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Martin Zobel-Helas zo...@ftbfs.de [2009-04-21 21:17]:

 here some more infos:
 
 21029 ?S  0:00  \_ sh -c /usr/bin/sudo /usr/bin/apt-get 
 --purge -o 
 Dir::State::status=/home/buildd/build/chroot-unstable/var/lib/dpkg/status -o 
 DPkg::Options::=--root=/home/buildd/build/chroot-unstable -o DPkg::R
 21030 ?S  0:03  \_ /usr/bin/apt-get --purge -o 
 Dir::State::status=/home/buildd/build/chroot-unstable/var/lib/dpkg/status -o 
 DPkg::Options::=--root=/home/buildd/build/chroot-unstable -o 
 DPkg::Run-Directory=/ho
 22519 pts/0Ss+0:00  \_ /usr/bin/dpkg 
 --root=/home/buildd/build/chroot-unstable --force-confold --status-fd 14 
 --configure libmagic1 file gettext-base libkeyutils1 libkrb5support0 
 libk5crypto3 libkrb5-3 libgss
 23967 pts/0S+ 0:00  \_ /bin/sh -e 
 /var/lib/dpkg/info/octave3.0.postinst configure 
 23976 pts/0R+   1987:42  \_ octave-3.0.5 --silent 
 --no-history --no-init-file --eval pkg ('rebuild');
 
 strace -p 23976
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
 [...] runs infitive

Thanks for the info.  Is the hanging due to some file Octave is trying to
open/read/close?  Could you please run lsof on the octave-3.0.5 process
and post the results?  In the case above, it would be:

lsof -p 23976

Thanks,

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Stephen Gran sg...@debian.org [2009-04-21 23:55]:

 This one time, at band camp, Rafael Laboissiere said:
  * Martin Zobel-Helas zo...@ftbfs.de [2009-04-21 21:17]:
  
   here some more infos:
   
   21029 ?S  0:00  \_ sh -c /usr/bin/sudo /usr/bin/apt-get 
   --purge -o 
   Dir::State::status=/home/buildd/build/chroot-unstable/var/lib/dpkg/status 
   -o DPkg::Options::=--root=/home/buildd/build/chroot-unstable -o DPkg::R
   21030 ?S  0:03  \_ /usr/bin/apt-get --purge -o 
   Dir::State::status=/home/buildd/build/chroot-unstable/var/lib/dpkg/status 
   -o DPkg::Options::=--root=/home/buildd/build/chroot-unstable -o 
   DPkg::Run-Directory=/ho
   22519 pts/0Ss+0:00  \_ /usr/bin/dpkg 
   --root=/home/buildd/build/chroot-unstable --force-confold --status-fd 14 
   --configure libmagic1 file gettext-base libkeyutils1 libkrb5support0 
   libk5crypto3 libkrb5-3 libgss
   23967 pts/0S+ 0:00  \_ /bin/sh -e 
   /var/lib/dpkg/info/octave3.0.postinst configure 
   23976 pts/0R+   1987:42  \_ octave-3.0.5 --silent 
   --no-history --no-init-file --eval pkg ('rebuild');
   
   strace -p 23976
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   ioctl(0, TIOCNXCL, {0x1000 /* B??? */ -opost -isig -icanon echo ...}) = 0
   [...] runs infitive
  
  Thanks for the info.  Is the hanging due to some file Octave is trying to
  open/read/close?  Could you please run lsof on the octave-3.0.5 process
  and post the results?  In the case above, it would be:
  
  lsof -p 23976
 
 The process has been killed, so we no longer have that information for
 you.

Yes, I know, but could you try to launch the offending command:

octave-3.0.5 --silent --no-history --no-init-file --eval pkg ('rebuild');

in one of the machines where it fails and see what happens?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524745: [Pkg-octave-devel] Bug#524745: Bug#524745: Postinst seems to run forever on mipsel

[Rafael Laboissiere]

* Thomas Weber thomas.weber.m...@gmail.com [2009-04-20 00:11]:

 On Sun, Apr 19, 2009 at 05:47:11PM +0200, Luk Claes wrote:
  Package: octave3.0
  Version: 1:3.0.5-2
  Severity: grave
  
  Hi
  
  The postinst of octave3.0 seems to hang on at least the mipsel buildds (for 
  unstable) [1].
  
  This issue blocks the buildds from building any other package till the 
  octave3.0 process (mentioned in the build log) is killed manually. This has 
  already caused delays for security updates and transitions...
 
 Installation of octave3.0 in a mipsel (qemu) environment  works without
 a problem. Is there something specific about the mipsel buildds?

Indeed, this seems to be a random problem on the mipsel buildd.  Some
octave-* packages built correctly on mipsel recently, like
octave-econometrics on 2009-04-17 [1] and octave-data-smoothing on
2009-04-14 [2].  Both were built against octave3.0 3.0.5-2, so the postinst
script ran fine, without hanging.

[1] 
https://buildd.debian.org/fetch.cgi?pkg=octave-econometricsver=1%3A1.0.7-3arch=mipselstamp=1239954430file=log
[2] 
https://buildd.debian.org/fetch.cgi?pkg=octave-data-smoothingver=1.1.1-2arch=mipselstamp=1239721086file=log

It will be very hard for us to debug this random bug on the buildd.  Any
suggestions on how to proceed?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#523496: [Pkg-octave-devel] Bug#523496: octave3.0-headers: tight gcc dependencies incorrect

[Rafael Laboissiere]

* Aaron M. Ucko u...@debian.org [2009-04-10 13:04]:

 Package: octave3.0-headers
 Version: 1:3.0.5-1
 Severity: grave
 Justification: renders package unusable (uninstallable)
 
 octave3.0-headers now aims to depend on exact upstream gcc versions,
 but its approach is somewhat off, in that the dependencies are on
 metapackages that have epochs and don't depend so tightly on the
 actual compiler packages.  As such, I believe you'll need to generate
 dependencies along the following lines:
 
gcc (= 4:4.3), gcc ( 4:4.4), gcc-4.3 (= 4.3.3), gcc-4.3 ( 4.3.4)
 
 and likewise for g++ and gfortran.
 
 Could you please fix the dependencies, which currently leave the
 package uninstallable due to the epoch mismatch?

Sure, I have overseen this.  I will fix it tonight.

At any rate, I do not understand why you suggest to depend on both gcc and
gcc-4.3.  Would the following be okay?

gcc (= 4:4.3.3), gcc ( 4:4.3.4)

Unfortunately we need to depend on a precise version (4.3.3 currently
because paths containing this version number is hard-coded in mkoctave.
We should discuss with upstream about this.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#523042: [Pkg-octave-devel] Bug#523042: Bug#523042: octave3.0: loading a datafile skips every second line

[Rafael Laboissiere]

* John W. Eaton j...@bevo.che.wisc.edu [2009-04-08 21:19]:

 On  9-Apr-2009, Drew Parsons wrote:
 
 | About the severity, I appreciate you need to get the new version across
 | to testing but I don't think I could justify it with this bug.
 
 I agree that we should limit the spread of 3.0.4 as much as possible.
 3.0.5 is now available (there is just one patch applied to 3.0.4 to
 fix this bug) so it would seem to me that it is better to generate the
 3.0.5 package and upload that instead, and do whatever we can to keep
 3.0.4 from being used by anyone.

Fair enough.  Thomas Weber is taking care of this right now.  Version 3.0.4
will never make its way into testing.

Cheers,

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#523042: octave3.0: loading a datafile skips every second line

[Rafael Laboissiere]

package octave3.0
tags 523042 upstream confirmed pending
severity normal
thanks

* Drew Parsons dpars...@debian.org [2009-04-08 11:54]:

 Package: octave3.0
 Version: 1:3.0.4~rc7-1
 Severity: grave
 Justification: causes non-serious data loss
 
 Using the load function to read in a data file, it now skips every
 second line.
 
 You can see the bug with this simple test:
 
 $ cat  test.dat 
 0 100
 1 200
 2 300
 3 400
 4 500
 5 600
 $ octave -q
 octave:1 a = load(test.dat)
 a =
 
  0   100
  2   300
  4   500
 
 
 It was working fine two weeks ago, perhaps it is some bug in the new
 release candidate?

This bug has been confirmed upstream [1] and it also appears in the final
3.0.4 release.  The fix is already integrated in the next release
candidate tarball 3.0.5-rc1 [2].  I have already backported the patch
into the forthcoming 3.0.4-1 release of octave3.0 [3], which will be
uploaded soon to unstable [4].

I am hereby lowering the severity level of this bug report, otherwise
3.0.4~rc7-1 will be prevented from entering testing.  We have been
waiting months for this to happen and we have already scheduled the
uploads of all octave-forge pkgs that depend on it [5].  Feel free to
revert the severity level if you really think that the package should not
hit testing with this bug and we will discuss it further.

[1] http://www-old.cae.wisc.edu/pipermail/bug-octave/2009-April/008346.html
[2] 
http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-April/011761.html
[3] http://svn.debian.org/wsvn/pkg-octave/octave/trunk/debian/?rev=2786sc=1
[4] 
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2009-April/005646.html
[5] 
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2009-April/005644.html

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#523042: octave3.0: loading a datafile skips every second line

[Rafael Laboissiere]

package octave3.0
severity 523042 important
thanks

* Rafael Laboissiere raf...@debian.org [2009-04-08 08:53]:

 I am hereby lowering the severity level of this bug report, [snip]

Doing it now.  There was a typo in the header of my previous message.
 
-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#521726: python-pymtp: needs upating of depends fromlibmtp7 to libmtp8

[Rafael Laboissiere]

* Adeodato Simó d...@net.com.org.es [2009-04-02 12:32]:

 * Rafael Laboissiere [Tue, 31 Mar 2009 03:03:29 +0200]:

  [snip]
  I merged both version for pymtp.py and the resulting debdiff is attached
  below.  I tested it with a Zen Creative device and creation of a track
  from file worked using the modified sendtrack.py script in the package
  (notice that this script is patched to work with python-id3 instead of
  using the pyid3lib module, which does not seem to be available in Debian).
  [snip]
 
 Indeed. I’d like to push this transition sooner rather than latter, so
 I’m considering a temporary removal of pymtp from testing, or maybe
 leaving libmtp7 around for a bit in testing, but I like that less.

What about uploading a version of the package with my patch referenced
above?  I agree that it is not 100% tested, but the patch has the virtue to
make pymtp work with libmtp8, at least in a simple test case.  If things go
weird, for example if my patch introduces other serious bugs, then we remove
pymtp from testing.

What do you think?  Ig the Release Team gives me the approval and Thomas
Perl does not object, I would NMU pytmp, just to unblock the libmtp
transition.

Cheers,
 
-- 
Rafael



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#521726: python-pymtp: needs upating of depends fromlibmtp7 to libmtp8

[Rafael Laboissiere]

* Thomas Perl t...@thpinfo.com [2009-04-02 14:37]:

 I am fine with you NMUing pymtp. I can test your modifications locally
 with an MTP device here before you upload, if you want (or tell me if
 the debdiff you posted above is already what you intend to upload).

Please, test my changes.

Yes, it is what I intend to upload.  Notice that the debdiff contains the
changes to the upstream files in the .diff.gz. file.  It would be better
to use quilt for that.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#521726: python-pymtp: needs upating of depends fromlibmtp7 to libmtp8

[Rafael Laboissiere]

* Adeodato Simó d...@net.com.org.es [2009-04-02 20:41]:

 Great, I’ll be waiting for the upload and then do the migration.

I prepared the NMU, which can be accessed here:

dget http://people.debian.org/~rafael/pymtp/pymtp_0.0.4-1.1.dsc

Thomas, please test it.  I added quilt support to the package in order to
introduce my patch.  I also did a minimal change in debian/rule for
removing of the build/directory in the clean rule.  The entry in
debian/changelog reads as below.  The debdiff is attached to this
message.

If I do not hear from you soon I will assume that everything is okay and
upload the package to unstable.

Cheers,
 
Rafael Laboissiere

= debian/rules ==
pymtp (0.0.4-1.1) unstable; urgency=low

  * Non-maintainer upload, for unblocking the libmtp7 - libmtp8
transition (closes: #521726), with approval of the package maintainer
and the Debian Release Team, cf :
http://lists.debian.org/debian-release/2009/04/msg00018.html
  * debian/control:
+ (Depends) Depends on libmtp8
+ (Build-Depends) Add quilt
  * debian/patches/adapt-to-libmtp8.diff: Adapt upstream source to
libmtp8:
+ pymtp.py: Functions changed:
  - MTP.send_file_from_file
  - MTP.send_track_from_file
  - MTP.create_new_playlist
  - MTP.create_folder
+ examples/send{file,track}.py: Adjust
  * debian/rules (clean):
+ (build, clean) Adapt to quilt
+ (clean) Remove build/ directory

 -- Rafael Laboissiere raf...@debian.org  Thu, 02 Apr 2009 22:17:24 +0200
reverted:
--- pymtp-0.0.4/build/lib/pymtp.py
+++ pymtp-0.0.4.orig/build/lib/pymtp.py
@@ -1,1216 +0,0 @@
-#!/usr/bin/env python
-#
-# A Ctypes wrapper to LibMTP
-# Developed by: Nick Devito (n...@nick125.com)
-# (c) 2008 Nick Devito
-# Released under the GPLv3 or later.
-#
-
-
-	PyMTP is a pythonic wrapper around libmtp, making it a bit more 
-	friendly to use in python
-
-	Example Usage (or see examples/):
-		 import pymtp
-		 mtp = pymtp.MTP()
-	 mtp.connect()
-		PTP: Opening session
-	 print mtp.get_devicename()
-	Device name
-	 mtp.disconnect()
-		PTP: Closing session
-		
-
-
-__VERSION__ = 0.0.4
-__VERSION_MACRO__ = 4
-__VERSION_MINOR__ = 0
-__VERSION_MAJOR__ = 0
-__VERSION_TUPLE__ = (__VERSION_MAJOR__, __VERSION_MINOR__, __VERSION_MACRO__)
-__AUTHOR__ = Nick Devito (n...@nick125.com)
-__LICENSE__ = GPL-3
-__DEBUG__ = 1
-
-import os
-import ctypes
-import ctypes.util
-
-# NOTE: This code *may* work on windows, I don't have a win32 system to test
-# this on. 
-_module_path = ctypes.util.find_library(mtp) 
-_libmtp = ctypes.CDLL(_module_path)
-
-# --
-# Error Definitions
-# --
-class NoDeviceConnected(Exception): 
-	
-		Raised when there isn't a device connected to the USB bus 
-	
-
-	pass
-
-class AlreadyConnected(Exception):
-	
-		Raised when we're already connected to a device and there is 
-		an attempt to connect
-	
-
-	pass
-	
-class UnsupportedCommand(Exception): 
-	
-		Raised when the connected device does not support the command 
-		issued
-	
-
-	pass
-
-class CommandFailed(Exception): 
-	
-		Raised when the connected device returned an error when trying 
-		to execute a command
-	
-
-	pass
-
-class NotConnected(Exception): 
-	
-		Raised when a command is called and the device is not connected
-	
-
-	pass
-
-class ObjectNotFound(Exception):
-	
-		Raised when a command tries to get an object that doesn't exist
-	
-
-	pass
-
-# --
-# End Error Definitions
-# --
-
-# --
-# Data Model Definitions
-# --
-
-class LIBMTP_Error(ctypes.Structure):
-	
-		LIBMTP_Error
-		Contains the ctypes structure for LIBMTP_error_t
-	
-
-	def __repr__(self):
-		return self.errornumber
-
-LIBMTP_Error._fields_ = [(errornumber, ctypes.c_int),
- (error_text, ctypes.c_char_p),
- (next, ctypes.POINTER(LIBMTP_Error))]
-
-class LIBMTP_DeviceStorage(ctypes.Structure):
-	
-		LIBMTP_DeviceStorage
-		Contains the ctypes structure for LIBMTP_devicestorage_t
-	
-
-	def __repr__(self):
-		return self.id
-
-LIBMTP_DeviceStorage._fields_ = [(id, ctypes.c_uint32),
- (StorageType, ctypes.c_uint16),
- (FilesystemType, ctypes.c_uint16),
- (AccessCapability, ctypes.c_uint16),
- (MaxCapacity, ctypes.c_uint64),
- (FreeSpaceInBytes, ctypes.c_uint64),
- (FreeSpaceInObjects, ctypes.c_uint64),
- (StorageDescription, ctypes.c_char_p),
- (VolumeIdentifier, ctypes.c_char_p),
- (next, ctypes.POINTER(LIBMTP_DeviceStorage)),
- (prev, ctypes.POINTER(LIBMTP_DeviceStorage))]
-
-class LIBMTP_MTPDevice(ctypes.Structure):
-	
-		LIBMTP_MTPDevice
-		Contains the ctypes structure

Bug#521726: python-pymtp: needs upating of depends from libmtp7 to libmtp8

[Rafael Laboissiere]

* Thomas Perl t...@thpinfo.com [2009-03-30 13:00]:

 The following seems to work for users of MTP devices so far (see the
 attachment to that bug):
 
 http://bugs.gpodder.org/show_bug.cgi?id=307

Thanks for the info.  The changes to pymtp.py are different from those
that I proposed before.  I will test both versions eventually and will
let you know.

Cheers,

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#521726: python-pymtp: needs upating of depends from libmtp7 to libmtp8

[Rafael Laboissiere]

* Rafael Laboissiere raf...@laboissiere.net [2009-03-30 16:31]:

 * Thomas Perl t...@thpinfo.com [2009-03-30 13:00]:
 
  The following seems to work for users of MTP devices so far (see the
  attachment to that bug):
  
  http://bugs.gpodder.org/show_bug.cgi?id=307
 
 Thanks for the info.  The changes to pymtp.py are different from those
 that I proposed before.  I will test both versions eventually and will
 let you know.

My version was not working properly, so forget about the previous patch.

I merged both version for pymtp.py and the resulting debdiff is attached
below.  I tested it with a Zen Creative device and creation of a track
from file worked using the modified sendtrack.py script in the package
(notice that this script is patched to work with python-id3 instead of
using the pyid3lib module, which does not seem to be available in Debian).

I am Cc:ing this reply to the upstream author.  Let us see what he
thinks.  Although it would need more tests, I would go ahead and upload
this changed version of the package to unstable, otherwise the libmtp
transiton will be blocked.  Indeed python-pymtp is the last blocker for
the transition (Cc:ing also to debian-release, accordingly).

Cheers,

-- 
Rafael
diff -u pymtp-0.0.4/build/lib/pymtp.py pymtp-0.0.4/build/lib/pymtp.py
--- pymtp-0.0.4/build/lib/pymtp.py
+++ pymtp-0.0.4/build/lib/pymtp.py
@@ -167,6 +167,7 @@
 
 LIBMTP_File._fields_ = [(item_id, ctypes.c_uint32),
 (parent_id, ctypes.c_uint32),
+(storage_id, ctypes.c_uint32),
 (filename, ctypes.c_char_p),
 (filesize, ctypes.c_uint64),
 			(filetype, ctypes.c_int),
@@ -183,8 +184,10 @@
 		
 LIBMTP_Track._fields_ = [(item_id, ctypes.c_uint32),
 			(parent_id, ctypes.c_uint32),
+(storage_id, ctypes.c_uint32),
 			(title, ctypes.c_char_p),
 			(artist, ctypes.c_char_p),
+			(composer, ctypes.c_char_p),
 			(genre, ctypes.c_char_p),
 			(album, ctypes.c_char_p),
 			(date, ctypes.c_char_p),
@@ -277,6 +280,8 @@
 		return self.no_tracks
 
 LIBMTP_Playlist._fields_ = [(playlist_id, ctypes.c_uint32),
+	  		(parent_id, ctypes.c_uint32),
+(storage_id, ctypes.c_uint32),
 (name, ctypes.c_char_p),
 (tracks, ctypes.POINTER(ctypes.c_uint32)),
 (no_tracks, ctypes.c_uint32),
@@ -293,6 +298,7 @@
 
 LIBMTP_Folder._fields_ = [(folder_id, ctypes.c_uint32),
   (parent_id, ctypes.c_uint32),
+  (storage_id, ctypes.c_uint32),
   (name, ctypes.c_char_p),
   (sibling, ctypes.POINTER(LIBMTP_Folder)),
   (child, ctypes.POINTER(LIBMTP_Folder))]
@@ -819,7 +825,7 @@
 		else:
 			return LIBMTP_Filetype[UNKNOWN]
 
-	def send_file_from_file(self, source, target, parent=0, callback=None):
+	def send_file_from_file(self, source, target, callback=None):
 		
 			Sends a file from the filesystem to the connected device
 			and stores it at the target filename inside the parent.
@@ -831,9 +837,6 @@
 			@param source: The path on the filesystem where the file resides
 			@type target: str
 			@param target: The target filename on the device
-			@type parent: int or 0
-			@param parent: The parent directory for the file to go 
-			 into; If 0, the file goes into main directory
 			@type callback: function or None
 			@param callback: The function provided to libmtp to 
 			 receive callbacks from ptp. Callback function must
@@ -856,7 +859,7 @@
 		  filesize=os.stat(source).st_size)
 
 		ret = self.mtp.LIBMTP_Send_File_From_File(self.device, source, \
-		  ctypes.pointer(metadata), callback, None, parent)
+		  ctypes.pointer(metadata), callback, None)
 
 		if (ret != 0):
 			self.debug_stack()
@@ -864,7 +867,7 @@
 
 		return metadata.item_id
 		
-	def send_track_from_file(self, source, target, metadata, parent=0, callback=None):
+	def send_track_from_file(self, source, target, metadata, callback=None):
 		
 			Sends a track from the filesystem to the connected 
 			device
@@ -875,9 +878,6 @@
 			@param target: The target filename on the device
 			@type metadata: LIBMTP_Track
 			@param metadata: The track metadata
-			@type parent: int or 0
-			@param parent: The parent directory for the track;
-			 if 0, the track will be placed in the base dir.
 			@type callback: function or None
 			@param callback: The function provided to libmtp to
 			 receive callbacks from ptp. Callback function must
@@ -896,12 +896,11 @@
 			callback = Progressfunc(callback)
 		
 		metadata.filename = target
-		metadata.parent_id = parent
 		metadata.filetype = self.find_filetype(source)
 		metadata.filesize = os.stat(source).st_size
 
 		ret = self.mtp.LIBMTP_Send_Track_From_File(self.device, source, \
-		  ctypes.pointer(metadata), callback, None, parent)
+		  ctypes.pointer(metadata), callback, None)
 
 		if (ret

Bug#521726: python-pymtp: needs upating of depends from libmtp7 to libmtp8

[Rafael Laboissiere]

* Adeodato Simó d...@net.com.org.es [2009-03-29 20:08]:

 Package: python-pymtp
 Version: 0.0.4-1
 Severity: serious
 X-Debbugs-CC: Rafael Laboissiere raf...@debian.org
 
 pymtp hardcodes a dependency on libmtp7, which has been dropped in
 favour of libmtp8. Please take a look into uploading a package with an
 updated dependency, with source changes to adjust to the new library if
 needed. 

Source changes are needed.  The pymtp module uses ctypes to access the
shared library libmtp, so that runtime errors may occur with source
unchanged.

Below is a debdiff that may work.  I did not test it but merely adapted
the code to the changes in the API between libmtp7 and libmtp8.

It seems that upstream has not yet adapted to libmtp8 [1], although it is
staed in the README [2] at the Git repository that PyMTP 0.1.0 requires
LibMTP 0.3.3 or above.

[1] http://projects.nick125.com/repositories/entry/pymtp/pymtp/main.py
[2] http://projects.nick125.com/repositories/entry/pymtp/README
 
-- 
Rafael
diff -u pymtp-0.0.4/build/lib/pymtp.py pymtp-0.0.4/build/lib/pymtp.py
--- pymtp-0.0.4/build/lib/pymtp.py
+++ pymtp-0.0.4/build/lib/pymtp.py
@@ -819,7 +819,7 @@
 		else:
 			return LIBMTP_Filetype[UNKNOWN]
 
-	def send_file_from_file(self, source, target, parent=0, callback=None):
+	def send_file_from_file(self, source, target, callback=None):
 		
 			Sends a file from the filesystem to the connected device
 			and stores it at the target filename inside the parent.
@@ -831,9 +831,6 @@
 			@param source: The path on the filesystem where the file resides
 			@type target: str
 			@param target: The target filename on the device
-			@type parent: int or 0
-			@param parent: The parent directory for the file to go 
-			 into; If 0, the file goes into main directory
 			@type callback: function or None
 			@param callback: The function provided to libmtp to 
 			 receive callbacks from ptp. Callback function must
@@ -856,7 +853,7 @@
 		  filesize=os.stat(source).st_size)
 
 		ret = self.mtp.LIBMTP_Send_File_From_File(self.device, source, \
-		  ctypes.pointer(metadata), callback, None, parent)
+		  ctypes.pointer(metadata), callback, None)
 
 		if (ret != 0):
 			self.debug_stack()
@@ -864,7 +861,7 @@
 
 		return metadata.item_id
 		
-	def send_track_from_file(self, source, target, metadata, parent=0, callback=None):
+	def send_track_from_file(self, source, target, metadata, callback=None):
 		
 			Sends a track from the filesystem to the connected 
 			device
@@ -875,9 +872,6 @@
 			@param target: The target filename on the device
 			@type metadata: LIBMTP_Track
 			@param metadata: The track metadata
-			@type parent: int or 0
-			@param parent: The parent directory for the track;
-			 if 0, the track will be placed in the base dir.
 			@type callback: function or None
 			@param callback: The function provided to libmtp to
 			 receive callbacks from ptp. Callback function must
@@ -1038,7 +1032,7 @@
 
 		return ret
 
-	def create_new_playlist(self, metadata, parent=0):
+	def create_new_playlist(self, metadata):
 		
 			Creates a new playlist based on the metadata object
 			passed.
@@ -1046,8 +1040,6 @@
 			@type metadata: LIBMTP_Playlist
 			@param metadata: A LIBMTP_Playlist object describing 
 			 the playlist
-			@type parent: int or 0
-			@param parent: The parent ID or 0 for base
 			@rtype: int
 			@return: The object ID of the new playlist
 		
@@ -1055,7 +1047,7 @@
 		if (self.device == None):
 			raise NotConnected
 		
-		ret = self.mtp.LIBMTP_Create_New_Playlist(self.device, ctypes.pointer(metadata), parent)
+		ret = self.mtp.LIBMTP_Create_New_Playlist(self.device, ctypes.pointer(metadata))
 
 		if (ret == 0):
 			self.debug_stack()
@@ -1173,7 +1165,7 @@
 
 		return ret
 
-	def create_folder(self, name, parent=0):
+	def create_folder(self, name, parent=0, storage=0):
 		
 			This creates a new folder in the parent. If the parent 
 			is 0, it will go in the main directory.
@@ -1182,6 +1174,9 @@
 			@param name: The name for the folder
 			@type parent: int
 			@param parent: The parent ID or 0 for main directory
+@type storage: int
+@param storage: The storage id or 0 to create the new folder
+on the primary storage
 			@rtype: int
 			@return: Returns the object ID of the new folder
 		
@@ -1189,7 +1184,7 @@
 		if (self.device == None):
 			raise NotConnected
 			
-		ret = self.mtp.LIBMTP_Create_Folder(self.device, name, parent)
+		ret = self.mtp.LIBMTP_Create_Folder(self.device, name, parent, storage)
 
 		if (ret == 0):
 			self.debug_stack()
diff -u pymtp-0.0.4/debian/changelog pymtp-0.0.4/debian/changelog
--- pymtp-0.0.4/debian/changelog
+++ pymtp-0.0.4/debian/changelog
@@ -1,3 +1,16 @@
+pymtp (0.0.4-1.1) unstable; urgency=low
+
+  * Non-maintainer upload
+  * debian/control: Depends on libmtp8
+  * pymtp.py: Adapt to libmtp8.  Functions changed:
++ MTP.send_file_from_file
++ MTP.send_track_from_file

Bug#514655: Fixed gtick in s-p-u

[Rafael Laboissiere]

The RC Bug#514655 against gtick is damn easy to fix for lenny.  Should a
fixed package be uploaded to stable-proposed-updates?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#520460: [Pkg-scicomp-devel] Bug#520460: liblapack-doc: tries to overwrite file owned by qdbm-util

[Rafael Laboissiere]

* Ralf Treinen trei...@free.fr [2009-03-19 23:28]:

 Subject: liblapack-doc: tries to overwrite file owned by qdbm-util
 Package: qdbm-util,liblapack-doc
 Severity: serious

Thanks for the heads up.  This is indeed a bug in liblapack-doc.

I am taking care of it.  There is a bug in debian/rules that makes all
man pages that were intended to have .TH 3 to be installed in
/usr/share/man/man1.  I will fix this and set the extension to .3lapack,
avoiding further clashes.  The liblapack-doc has indeed a huge amount of
manpages:

$ dpkg -L liblapack-doc  | grep '/usr/share/man.*\.gz' | wc -l
1614


-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#520220: octave3.0: This release candidate snapshot should not enter testing

[Rafael Laboissiere]

Package: octave3.0
Version: 1:3.0.4~rc5-2
Severity: serious

This version of the octave3.0 package is based on a release candidate
snapshot for the upcoming 3.0.4 version.  The upstream authors have told 
us [1] that release candidates should not be distributed as Debian packages.

Let us keep this version in unstable for now.

[1] 
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2009-March/005548.html

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages octave3.0 depends on:
ii  libatlas3gf-base [libl 3.6.0-21.3Automatically Tuned Linear Algebra
ii  libblas3gf [libblas.so 1.2-1.5   Basic Linear Algebra Subroutines 3
ii  libc6  2.7-6 GNU C Library: Shared libraries
ii  libcolamd-3.2.01:3.2.0-4 column approximate minimum degree 
ii  libcurl3-gnutls7.18.0-1  Multi-protocol file transfer libra
ii  libfftw3-3 3.1.2-3   library for computing Fast Fourier
ii  libgcc11:4.3.2-1.1   GCC support library
ii  libgfortran3   4.3.2-1.1 Runtime library for GNU Fortran ap
ii  libglpk0   4.36-2linear programming kit with intege
ii  libhdf5-serial-1.6.6-0 1.6.6-4   Hierarchical Data Format 5 (HDF5) 
ii  liblapack3gf [liblapac 3.2.0-2   library of linear algebra routines
ii  libncurses55.6+20080119-1Shared libraries for terminal hand
ii  libpcre3   7.8-2 Perl 5 Compatible Regular Expressi
ii  libqhull5  2003.1-8  calculate convex hulls and related
ii  libreadline5   5.2-3 GNU readline and history libraries
ii  libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii  libsuitesparse-3.2.0   1:3.2.0-4 collection of libraries for comput
ii  octave3.0-common   1:3.0.4~rc5-2 architecture-independent files for
ii  texinfo4.11.dfsg.1-3 Documentation system for on-line i
ii  zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime

Versions of packages octave3.0 recommends:
ii  gnuplot   4.2.4-4A command-line driven interactive 
ii  libatlas3gf-base  3.6.0-21.3 Automatically Tuned Linear Algebra

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#519126: qrupdate fails to build in Debian on some architectures

[Rafael Laboissiere]

* Jaroslav Hajek high...@gmail.com [2009-03-11 09:46]:

 I removed the march=native flag from Makeconf. I have also uploaded an
 updated source tarball containing this fix and all the fixes to
 makefiles  configuration files contributed by Jordi (no actual source
 code changed).

Thanks.  

Jordi, are you planning to update the Debian package any soon?

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#517642: [Pkg-octave-devel] Bug#517642: octave3.0: FTBFS: Invalid conversions of function pointers

[Rafael Laboissiere]

package octave3.0
tags 517642 confirmed pending
thanks

* Daniel Schepler schep...@math.berkeley.edu [2009-02-28 22:09]:

 Package: octave3.0
 Version: 1:3.0.1-7
 Severity: serious
 
 When I tried to rebuild octave3.0 against the new suitesparse libraries, I got
 this in my pbuilder build log (on amd64):

This problem is normal and has already been fixed in experimental, version
1:3.0.4~rc5-1. We are waiting for the liblapack transition to be sorted out
before uploading to unstable.  This will hopefully happen soon.

-- 
Rafael



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org