Bug#719267: RM: opencascade -- ROM; obsoleted by oce
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: ftp.debian.org Severity: normal Hello, OCE stands for Opencascade Community Edition, this is a fork which is easier to package. Opencascade package can be removed, all reverse dependencies have been updated. A couple of science tasks still Suggests: libopencascade-dev, I updated the repository but do not know when those tasks will be uploaded. Thanks, Denis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFSBWi88Ri1lR4WGvsRArIvAKDQg6rYDXn1DmASfQlbWEBzc5cODgCg0xBy A5Nm6E3P/sGelqzTd9sHtt4= =ZnQh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717829: RM: openturns [mips mipsel] -- ROM; ANAIS; requires 1GB RAM to build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: ftp.debian.org Severity: normal Hello, openturns requires more than 1GB of RAM in order to build; it had been quite hard to have openturns 1.0 built on mips and mipsel, but openturns 1.1 could not get built and it is likely that 1.2 is even worse. The only rdepends is feel++, and this package is not built on those architectures. Thanks, Denis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFR8SaC8Ri1lR4WGvsRAsyUAJ49l9HRiDeAAqu4+qbzRD4koE+0EQCgrouI wLrFUAwnWCRCi0TviYqAOBk= =Kpru -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673298: transition: openturns
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We would like to have openturns 1.0 in wheezy. It has only one reverse dependency, feel++, which is in unstable only. I did not check whether feel++ builds fine with openturns 1.0, but am pretty sure that Christophe already took care of that. Openturns 1.0 has been uploaded into experimental, and already passed the NEW queue. Can you please tell me whether I can upload it into unstable? Thanks for your time. Denis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFPtSht8Ri1lR4WGvsRAmcDAKC1MI4lNeWvZFfDj6YnWCSbvThxsQCgmSZu 5uApDdGWDfiF4r2Q5+nQ5iA= =sXKG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670066: python-openturns is unusable
Package: python-openturns Version: 0.15-3 Severity: grave Justification: renders package unusable Hello, It seems that python-openturns 0.15-3 is unusable: $ python Python 2.7.2+ (default, Jan 20 2012, 17:51:10) [GCC 4.6.2] on linux2 Type help, copyright, credits or license for more information. import openturns Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/dist-packages/openturns/__init__.py, line 87, in module import openturns_preload ImportError: No module named openturns_preload 0.15-2 worked fine, I guess that this is due to the move to dh_python2. Denis -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages python-openturns depends on: ii ghostscript9.05~dfsg-2 ii libc6 2.13-26 ii libgcc11:4.7.0-1 ii libopenturns0 0.15-3 ii libstdc++6 4.7.0-1 ii python 2.7.2-10 ii python-qt4 4.9.1-1 ii python-rpy22.2.5-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-13 python-openturns recommends no packages. python-openturns suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625924: po4a: [pod]? nested commands S...S......
On 2011/5/7 David Prévot wrote: Package: po4a Version: 0.41-1 Severity: normal Hi, I've just noticed an error while processing devscript manpages. For example, in bts(1), the string (non breaking space only around quotes): « Bmutt -f %s » is processed as: S« Bmutt -f S%s » so the bold is lost, and non breaking spaces are spread everywhere inside the quotes. Hello, We could try to fix this special case, but I wonder why those non-breaking spaces are replaced by S Does anyone see a reason for this behavior? I am inclined to make post_trans a no-op in Locale::Po4a::Pod. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625935: po4a: [INTL:ru] Russian manpage translation update
reassign 625935 debconf retitle 625935 debconf: [INTL:ru] Russian manpage translation update thanks 2011/5/7 Yuri Kozlov yu...@komyakino.ru: Package: po4a Version: 1.5.39 Severity: wishlist Tags: l10n patch Russian manpage translation update is attached. These are manual pages for debconf, not po4a, thus reassigning. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
On 2011/3/21 Adam C Powell IV wrote: On Mon, 2011-03-21 at 07:01 -0400, Adam C Powell IV wrote: On Fri, 2011-03-18 at 16:21 -0400, Adam C Powell IV wrote: I can build and upload on Monday, but I'm afraid I don't have time until then. Sylvestre, if you can do it before Monday, then feel free to go ahead. Otherwise I will post to the bug again when I start to build. Just finished the build and am about to dupload. The finished package will be at http://lyre.mit.edu/~powell/opencascade/ (along with a bunch of old versions). D'oh! Forgot to change from UNRELEASED to unstable. Building again... Please upload to experimental. AFAICT one has to ask debian-release before uploading a new library, can someone confirm? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
On 2011/3/11 Denis Barbier wrote: On 2011/3/11 Adam C Powell IV: [...] I just removed .bak files from 'upstream', and pushed 'master', 'upstream' and 'pristine-tar' branches on Alioth. As an alternative, you may now generate a tar.bz2 by running pristine-tar checkout ../opencascade_6.5.0.dfsg.orig.tar.bz2 My new one contains 40389652 bytes and: $ md5sum opencascade_6.5.0.dfsg.orig.tar.bz2 537699c4d4018c118dd1ca306bdd9861 opencascade_6.5.0.dfsg.orig.tar.bz2 Hmm, checked out the pristine-tar branch, but the pristine-tar command failed with: $ pristine-tar checkout ../opencascade_6.5.0.dfsg.orig.tar.bz2 fatal: Path 'opencascade_6.5.0.dfsg.orig.tar.bz2.delta' exists on disk, but not in 'refs/remotes/alioth/pristine-tar'. /usr/bin/pristine-tar: git show refs/remotes/alioth/pristine-tar:opencascade_6.5.0.dfsg.orig.tar.bz2.delta failed That's weird. Here: $ git show-ref refs/remotes/alioth/pristine-tar de09af9a0c65d4a058123a5dbce84005b8cb7797 refs/remotes/alioth/pristine-tar And you can see at http://git.debian.org/?p=debian-science/packages/opencascade.git;a=tree;h=de09af9a0c65d4a058123a5dbce84005b8cb7797;hb=pristine-tar that opencascade_6.5.0.dfsg.orig.tar.bz2.delta does exist. What does the above command display in your repo? Or maybe the error message is wrong, you simply have to delete your existing tarball? Ping. Adam, do you know when you will have time to compile these packages? IMO the current git can be uploaded into experimental. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
On 2011/3/11 Adam C Powell IV: [...] I just removed .bak files from 'upstream', and pushed 'master', 'upstream' and 'pristine-tar' branches on Alioth. As an alternative, you may now generate a tar.bz2 by running pristine-tar checkout ../opencascade_6.5.0.dfsg.orig.tar.bz2 My new one contains 40389652 bytes and: $ md5sum opencascade_6.5.0.dfsg.orig.tar.bz2 537699c4d4018c118dd1ca306bdd9861 opencascade_6.5.0.dfsg.orig.tar.bz2 Hmm, checked out the pristine-tar branch, but the pristine-tar command failed with: $ pristine-tar checkout ../opencascade_6.5.0.dfsg.orig.tar.bz2 fatal: Path 'opencascade_6.5.0.dfsg.orig.tar.bz2.delta' exists on disk, but not in 'refs/remotes/alioth/pristine-tar'. /usr/bin/pristine-tar: git show refs/remotes/alioth/pristine-tar:opencascade_6.5.0.dfsg.orig.tar.bz2.delta failed That's weird. Here: $ git show-ref refs/remotes/alioth/pristine-tar de09af9a0c65d4a058123a5dbce84005b8cb7797 refs/remotes/alioth/pristine-tar And you can see at http://git.debian.org/?p=debian-science/packages/opencascade.git;a=tree;h=de09af9a0c65d4a058123a5dbce84005b8cb7797;hb=pristine-tar that opencascade_6.5.0.dfsg.orig.tar.bz2.delta does exist. What does the above command display in your repo? Or maybe the error message is wrong, you simply have to delete your existing tarball? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
Hi again,
I just found that current tree does not compile because of one of my
patches, I do not know why I did not detect this problem earlier.
Here is a fix I am currently testing and will commit later today, feel
free to commit it if you want.
Denis
diff --git a/debian/patches/compatibility-occ630-Value.patch b/debian/patches/compatibility-occ630-Value.patch
index 216d052..622cdf4 100644
--- a/debian/patches/compatibility-occ630-Value.patch
+++ b/debian/patches/compatibility-occ630-Value.patch
@@ -33,7 +33,7 @@ Index: opencascade/ros/inc/BRepExtrema_ExtCC.hxx
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, Value() has been renamed into SquareDistance(). Add an alias to not break existing code
+Standard_EXPORT Standard_Real Value(const Standard_Integer N) const { return SquareDistance(N); }
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, TrimmedDistances() has been renamed into TrimmedSquareDistances(). Add an alias to not break existing code
-+Standard_EXPORT void TrimmedDistances(Standard_Real dist11,Standard_Real distP12,Standard_Real distP21,Standard_Real distP22,gp_Pnt P11,gp_Pnt P12,gp_Pnt P21,gp_Pnt P22) const { return TrimmedSquareDistances(dist11, distP12, distP21, distP22, P11, P12, P21, P22) ;}
++Standard_EXPORT void TrimmedDistances(Standard_Real dist11,Standard_Real distP12,Standard_Real distP21,Standard_Real distP22,gp_Pnt P11,gp_Pnt P12,gp_Pnt P21,gp_Pnt P22) const { TrimmedSquareDistances(dist11, distP12, distP21, distP22, P11, P12, P21, P22) ;}
protected:
@@ -74,7 +74,7 @@ Index: opencascade/ros/inc/BRepExtrema_ExtPC.hxx
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, Value() has been renamed into SquareDistance(). Add an alias to not break existing code
+Standard_EXPORT Standard_Real Value(const Standard_Integer N) const { return SquareDistance(N); }
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, TrimmedDistances() has been renamed into TrimmedSquareDistances(). Add an alias to not break existing code
-+Standard_EXPORT void TrimmedDistances(Standard_Real dist1,Standard_Real dist2,gp_Pnt pnt1,gp_Pnt pnt2) const { return TrimmedSquareDistances(dist1, dist2, pnt1, pnt2) ;}
++Standard_EXPORT void TrimmedDistances(Standard_Real dist1,Standard_Real dist2,gp_Pnt pnt1,gp_Pnt pnt2) const { TrimmedSquareDistances(dist1, dist2, pnt1, pnt2) ;}
protected:
@@ -168,7 +168,7 @@ Index: opencascade/ros/inc/Extrema_ELPCOfLocateExtPC.hxx
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, Value() has been renamed into SquareDistance(). Add an alias to not break existing code
+Standard_EXPORT Standard_Real Value(const Standard_Integer N) const { return SquareDistance(N); }
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, TrimmedDistances() has been renamed into TrimmedSquareDistances(). Add an alias to not break existing code
-+Standard_EXPORT void TrimmedDistances(Standard_Real dist1,Standard_Real dist2,gp_Pnt P1,gp_Pnt P2) const { return TrimmedSquareDistances(dist1, dist2, P1, P2) ;}
++Standard_EXPORT void TrimmedDistances(Standard_Real dist1,Standard_Real dist2,gp_Pnt P1,gp_Pnt P2) const { TrimmedSquareDistances(dist1, dist2, P1, P2) ;}
protected:
@@ -183,7 +183,7 @@ Index: opencascade/ros/inc/Extrema_ELPCOfLocateExtPC2d.hxx
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, Value() has been renamed into SquareDistance(). Add an alias to not break existing code
+Standard_EXPORT Standard_Real Value(const Standard_Integer N) const { return SquareDistance(N); }
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, TrimmedDistances() has been renamed into TrimmedSquareDistances(). Add an alias to not break existing code
-+Standard_EXPORT void TrimmedDistances(Standard_Real dist1,Standard_Real dist2,gp_Pnt P1,gp_Pnt P2) const { return TrimmedSquareDistances(dist1, dist2, P1, P2) ;}
++Standard_EXPORT void TrimmedDistances(Standard_Real dist1,Standard_Real dist2,gp_Pnt2d P1,gp_Pnt2d P2) const { TrimmedSquareDistances(dist1, dist2, P1, P2) ;}
protected:
@@ -250,7 +250,7 @@ Index: opencascade/ros/inc/Extrema_ExtCC.hxx
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, Value() has been renamed into SquareDistance(). Add an alias to not break existing code
+Standard_EXPORT Standard_Real Value(const Standard_Integer N = 1) const { return SquareDistance(N); }
+// DEBIAN SPECIFIC CHANGES: In OCC 6.5.0, TrimmedDistances() has been renamed into TrimmedSquareDistances(). Add an alias to not break existing code
-+Standard_EXPORT void TrimmedDistances(Standard_Real dist11,Standard_Real distP12,Standard_Real distP21,Standard_Real distP22,gp_Pnt2d P11,gp_Pnt2d P12,gp_Pnt2d P21,gp_Pnt2d P22) const { return TrimmedSquareDistances(dist11, distP12, distP21, distP22, P11, P12, P21, P22) ;}
++Standard_EXPORT void TrimmedDistances(Standard_Real dist11,Standard_Real distP12,Standard_Real distP21,Standard_Real distP22,gp_Pnt P11,gp_Pnt P12,gp_Pnt P21,gp_Pnt P22) const { TrimmedSquareDistances(dist11, distP12, distP21, distP22, P11, P12, P21, P22) ;}
protected:
@@ -265,7 +265,7 @@ Index:
Bug#616736: opencascade: please update to 6.5.0
On 2011/3/10 Adam C Powell IV wrote: On Thu, 2011-03-10 at 15:15 +0100, Denis Barbier wrote: Hi again, I just found that current tree does not compile because of one of my patches, I do not know why I did not detect this problem earlier. Here is a fix I am currently testing and will commit later today, feel free to commit it if you want. Denis Thanks again Denis. BTW, the tarball I make with tar cjf is about 1.8 MiB larger than yours, with the .bak files removed. Is there a way to pass --best to bzip2 using tar? I don't see it in the tar manpage. Mathieu already answered, but please do not run tar directly, use instead git archive --prefix=opencascade-6.5.0.dfsg/ upstream \ | bzip2 --best ../opencascade_6.5.0.dfsg.orig.tar.bz2 This will preserve file attributes, and the tarball will be identical whether you or me (or anyone else) generate it, it will only depend on the commit 'upstream' is pointing to. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
On 2011/3/10 Denis Barbier wrote: On 2011/3/10 Adam C Powell IV wrote: On Thu, 2011-03-10 at 15:15 +0100, Denis Barbier wrote: Hi again, I just found that current tree does not compile because of one of my patches, I do not know why I did not detect this problem earlier. Here is a fix I am currently testing and will commit later today, feel free to commit it if you want. Denis Thanks again Denis. BTW, the tarball I make with tar cjf is about 1.8 MiB larger than yours, with the .bak files removed. Is there a way to pass --best to bzip2 using tar? I don't see it in the tar manpage. Mathieu already answered, but please do not run tar directly, use instead git archive --prefix=opencascade-6.5.0.dfsg/ upstream \ | bzip2 --best ../opencascade_6.5.0.dfsg.orig.tar.bz2 This will preserve file attributes, and the tarball will be identical whether you or me (or anyone else) generate it, it will only depend on the commit 'upstream' is pointing to. Update: back on the machine I use to hack on this package, history shows that I ran git-buildpackage --pristine-tar --git-verbose --git-ignore-new to generate my tar.bz2. I do not remember where I found the --pristine-tar option, it is not documented. Anyway it generates the exact same tarball as 'git archive' above. I just removed .bak files from 'upstream', and pushed 'master', 'upstream' and 'pristine-tar' branches on Alioth. As an alternative, you may now generate a tar.bz2 by running pristine-tar checkout ../opencascade_6.5.0.dfsg.orig.tar.bz2 My new one contains 40389652 bytes and: $ md5sum opencascade_6.5.0.dfsg.orig.tar.bz2 537699c4d4018c118dd1ca306bdd9861 opencascade_6.5.0.dfsg.orig.tar.bz2 Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617545: freecad: will FTBFS with opencascade 6.5.0
Package: freecad Version: 0.10.3247.dfsg-2 Severity: normal Tags: patch Hello, Your package will FTBFS with opencascade 6.5.0, here is a patch to fix that (it will still compile with 6.3.0). Denis diff --git a/src/Mod/Part/App/PrimitiveFeature.cpp b/src/Mod/Part/App/PrimitiveFeature.cpp index 30c951f..5147e24 100644 --- a/src/Mod/Part/App/PrimitiveFeature.cpp +++ b/src/Mod/Part/App/PrimitiveFeature.cpp @@ -141,9 +141,6 @@ App::DocumentObjectExecReturn *Plane::execute(void) case BRepBuilderAPI_ParametersOutOfRange: error = parameters out of range; break; -case BRepBuilderAPI_SurfaceNotC2: -error = surface not C2; -break; default: error = unknown error; break; diff --git a/src/Mod/Part/App/TopoShape.cpp b/src/Mod/Part/App/TopoShape.cpp index d16e81f..3391900 100644 --- a/src/Mod/Part/App/TopoShape.cpp +++ b/src/Mod/Part/App/TopoShape.cpp @@ -131,8 +131,6 @@ const char* BRepBuilderAPI_FaceErrorText(BRepBuilderAPI_FaceError et) return Curve projection failed; case BRepBuilderAPI_ParametersOutOfRange: return Parameters out of range; -case BRepBuilderAPI_SurfaceNotC2: -return Surface not C2-continous; default: return Unknown creation error; }
Bug#616736: opencascade: please update to 6.5.0
2011/3/10 Adam C Powell IV wrote: [...] Is there a problem with the patch, or the .orig? I just did git pull alioth master and git-buildpackage created the .orig for me. Can you post your DFSG .orig somewhere? Hi Adam, This may be because you did not git pull alioth upstream and git-buildpackage tries to apply this patch against the old 6.3.0 sources. I just tried git-buildpackage --pristine-tar here, and put the generated tarball at http://alioth.debian.org/~barbier-guest/tmp/opencascade_6.5.0.dfsg.orig.tar.bz2 (bz2 cuts tarball size from 49MiB down to 40MiB). Maybe we should remove samples/mfc/04_Viewer3d/src/TexturesExt_Presentation.cpp.bak samples/mfc/09_Animation/src/AnimationView3D.cpp.bak from this tarball? They are removed by running make clean. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
On 2011/3/7 Denis Barbier wrote: Package: opencascade Version: 6.3.0.dfsg.1-6 Severity: wishlist Tags: pending Hello, I updated opencascade to 6.5.0 in our git repository. It builds fine, but this required a lot of work and I do not have time to perform extensive testing. There is one issue which has to be fixed before uploading, libopencascade-foundation-6.5.0 depends on libx11-6 and libxt6, one has to check why those dependencies have been introduced, and fix them. This issue has been fixed, the package is IMHO in a good shape. More testing is needed, of course; I will try to provide binary packages so that interested people can test them, but I will be busy until the end of the week, so if someone can produce those packages and put them online, that would be great. Sources are available at git://git.debian.org/debian-science/packages/opencascade.git Thanks Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616668: k3d: Please do not depend on obsolete opencascade-dev
Package: k3d Version: 0.8.0.2-6 Severity: normal Tags: patch Hello, Your package build-depends on libopencascade-dev; this is a transitional package which is going to be dropped. As there is a new upstream version of opencascade, I would like to drop it now. You can simply remove this dependency since your package does not use opencascade at all. Its support can no more be enabled, your opencascade module uses k3d::gprim_factory which has been removed. Thanks Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616736: opencascade: please update to 6.5.0
Package: opencascade Version: 6.3.0.dfsg.1-6 Severity: wishlist Tags: pending Hello, I updated opencascade to 6.5.0 in our git repository. It builds fine, but this required a lot of work and I do not have time to perform extensive testing. There is one issue which has to be fixed before uploading, libopencascade-foundation-6.5.0 depends on libx11-6 and libxt6, one has to check why those dependencies have been introduced, and fix them. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614134: vtk: FTBFS on kfreebsd:Syntax error on token enum, interface expected
tags 614134 pending
severity 614134 serious
thanks
Hi Dominique,
I just fixed this bug in git.
Denis
2011/2/19 Dominique Belhachemi domi...@debian.org:
Source: vtk
Version: 5.6.1-2
Hi,
The package doesn't longer build on kfreebsd, there seems to be a issue with
the Java language compliance level. Java's enum needs at least level 1.5.
cd Build cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
[...]
-- Java version 1.5.0 configured successfully!
[...]
1. ERROR in
/build/buildd-vtk_5.6.1-2-kfreebsd-amd64-cCPTMt/vtk-5.6.1/Build/java/vtk/CellType.java
(at line 8)
public enum CellType {
Syntax error on token enum, interface expected
[...]
The full build logs for kfreebsd-amd64 and kfreebsd-i386 can be found here:
https://buildd.debian.org/fetch.cgi?pkg=vtkarch=kfreebsd-amd64ver=5.6.1-2stamp=1298088790file=logas=raw
https://buildd.debian.org/fetch.cgi?pkg=vtkarch=kfreebsd-i386ver=5.6.1-2stamp=1298088215file=logas=raw
Thanks
Dominique
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614134: vtk: FTBFS on kfreebsd:Syntax error on token enum, interface expected
On 2011/2/20 Dominique Belhachemi wrote:
I am CC'ing debian-java to get some additional help.
Hi Denis,
thanks for looking into this issue.
Unfortunately, the wrapper around gcj-4.4 is filtering out the -source
option.
$ less /usr/bin/gcj-wrapper-4.4
elsif ($arg eq '-source' or $arg eq '-sourcepath' or $arg eq '-target')
{
# An unsupported option with a following argument.
$ignoreNextArg = 1;
}
If I call the compiler directly I am getting
gcj-4.4: unrecognized option '-source'
I think cmake is looking for the 'java -version' value.
$ java -version
java version 1.5.0
gij (GNU libgcj) version 4.4.5
That is probably the reason why it reports misleadingly
-- Java version 1.5.0 configured successfully!
But the compiler seems to be using a different language compliance level
( 1.5). Otherwise it would know the 'enum' type.
So, how do I set the language compliance level? Or should I use a
different compiler on kfreebsd and hppa?
Hello Dominique,
You do not have to change anything, my patch works as is with
default-jdk on all architectures. A similar fix has already been
applied months ago, see
http://git.debian.org/?p=collab-maint/vtk.git;a=commit;h=db81316
We need this new one in VTK 5.6 because new files have been added into
Wrapping/Java/vtk/, and they use Java 5 features. The previous fix
dealt with automatically generated Java files.
I do not know how to best emulate architectures which do not default
to openjdk; but you can try
# rm /usr/lib/jvm/default-java
# ln -s java-1.5.0-gcj /usr/lib/jvm/default-java
Do not forget to reset this symlink when you have finished ;)
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606702: podebconf-display-po: stops on errors with debconf variable substitution
Martin Eberhard Schauer wrote:
It should be considered whether the intended intentation is a must.
#. Type: text
#. Description
#. The - is used to indicate indentation. Leading spaces may not work.
#: ../grub-pc.templates.in:6001
#| msgid ${DEVICE} (${SIZE} MB, ${MODEL})
msgid - ${DEVICE} (${SIZE} MB, ${PATH})
msgstr - ${DEVICE} (${SIZE} MB, ${PATH})
There are no error messages without the minus sign.
This bug can be reproduced by running the following command:
$ whiptail --msgbox '- ${DEVICE} (${SIZE} Mo, ${PATH})' 7 35
- ${DEVICE} (${SIZE} Mo, ${PATH}): unknown option
See whiptail(1):
NOTES
whiptail interprets arguments starting with a dash - as being
arguments. To avoid this, and start some text in, for example, a
menubox item, with a dash, whiptail honours the getopt convention of
accepting the special argument -- which means that all following
arguments with dashes are to be treated verbatim and not parsed as
options.
IMHO this bugreport should be reassigned to debconf, frontends should
take care of their peculiarities. Here is a patch against
/usr/share/perl5/Debconf/FrontEnd/Dialog.pm to show how this problem
could get fixed.
I did not carefully check, but grub-pc seems to use this string to
substitute text, so it may not be affected by this bug.
Denis
--- /usr/share/perl5/Debconf/FrontEnd/Dialog.pm.orig
+++ /usr/share/perl5/Debconf/FrontEnd/Dialog.pm
@@ -119,10 +119,13 @@
my @lines = split(/\n/, $text);
my $num;
my @args=('--msgbox', join(\n, @lines));
+ if ($this-program eq 'whiptail' $text =~ m/^-/s) {
+ @args=('--msgbox', '--', join(\n, @lines));
+ }
if ($lines - 4 - $this-borderheight = $#lines) {
$num=$lines - 4 - $this-borderheight;
if ($this-program eq 'whiptail') {
- push @args, '--scrolltext';
+ unshift @args, '--scrolltext';
}
else {
my $fh=Debconf::TmpFile::open();
Bug#502611: po-debconf: podebconf-report-po should be able to use /usr/sbin/sendmail
Hello, Nicolas is right, AFAICT one can run $ podebconf-report-po --postpone=/tmp/msg.out $ formail -s /usr/sbin/sendmail -t /tmp/msg.out Does this fit your needs? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609034: manpages-fr-dev: incorrect isgreater(3) description
On 2011/1/6 Vincent Lefevre wrote: On 2011-01-05 22:09:13 +0100, Denis Barbier wrote: The French isgreater(3) man page says: L'opérateur normal de relation (comme , « inférieur à ») échouera si l'un des opérandes est le non nombre NaN. Ceci déclenche une exception. Pour l'éviter, C99 définit ces macros. Elles garantissent de n'évaluer leurs opérandes qu'une seule fois. Les opérandes peuvent être n'importe quel type réel. This is incorrect, and it has been incorrectly translated from the English version, which says: The normal relation operations (like , less than) will fail if one of the operands is NaN. This will cause an exception. To avoid this, C99 defines these macros. The macros are guaranteed to evaluate their operands only once. The operands can be of any real floating-point type. So, type réel should be replaced by something like type flottant réel (I don't know the correct term in French). Thanks for your report. What do you think about this translation ? Les opérations de relation usuelles (comme , « inférieur à ») échouent si l'un des opérandes vaut NaN (« Not a Number », ce qui signifie « pas un nombre »). Ceci déclenche une exception. Pour l'éviter, C99 définit ces macros. Elles garantissent de n'évaluer leurs opérandes qu'une seule fois. Les opérandes peuvent être de n'importe quel type flottant. No, type flottant is incorrect because complex numbers are also floating types (and are forbidden here). C99 has the following definitions: * There are three /real floating types/, designated as float, double, and long double. * There are three /complex types/, designated as float t_Complex, double _Complex, and long double _Complex. * The real floating and complex types are collectively called the /floating types/. * The type char, the signed and unsigned integer types, and the enumerated types are collectively called /integer types/. * The integer and real floating types are collectively called /real types/. * Integer and floating types are collectively called /arithmetic types/. Thanks Vincent for these clarifications. After more thinking I also agree that operand is misleading in this context. As type flottant réel seems to not be widely used, it is IMO better to be more explicit in French. Here is another try: Les opérations de relation usuelles (comme , « inférieur à ») échouent si l'un des paramètres vaut NaN (« Not a Number », ce qui signifie « pas un nombre »), et déclenchent une exception. Pour l'éviter, C99 définit ces macros. Elles garantissent de n'évaluer leurs paramètres qu'une seule fois. Les paramètres peuvent être de n'importe quel type flottant réel (float, double ou long double). Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609034: manpages-fr-dev: incorrect isgreater(3) description
Le 5 janvier 2011 17:41, Vincent Lefevre a écrit : Package: manpages-fr-dev Version: 3.27fr1.4-1 Severity: normal The French isgreater(3) man page says: L'opérateur normal de relation (comme , « inférieur à ») échouera si l'un des opérandes est le non nombre NaN. Ceci déclenche une exception. Pour l'éviter, C99 définit ces macros. Elles garantissent de n'évaluer leurs opérandes qu'une seule fois. Les opérandes peuvent être n'importe quel type réel. This is incorrect, and it has been incorrectly translated from the English version, which says: The normal relation operations (like , less than) will fail if one of the operands is NaN. This will cause an exception. To avoid this, C99 defines these macros. The macros are guaranteed to evaluate their operands only once. The operands can be of any real floating-point type. So, type réel should be replaced by something like type flottant réel (I don't know the correct term in French). Thanks for your report. What do you think about this translation ? Les opérations de relation usuelles (comme , « inférieur à ») échouent si l'un des opérandes vaut NaN (« Not a Number », ce qui signifie « pas un nombre »). Ceci déclenche une exception. Pour l'éviter, C99 définit ces macros. Elles garantissent de n'évaluer leurs opérandes qu'une seule fois. Les opérandes peuvent être de n'importe quel type flottant. Other corrections could be done, as suggested in bug 609033 (concerning the English version): [...] I have no strong opinion about your other comments, and would like to see if upstream is going to make the requested changes. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605637: man-db: lexgrog/apropos issues with some manual pages
On 2010/12/2, David Prévot wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 02/12/2010 06:31, Omar Campagne a écrit : On Wed, Dec 01, 2010 at 08:44:51PM -0400, David Prévot wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Omar, The appropriate cloned bug is #605637. Do you agree to s/NOMBRE DE REFERENCIA/NOMBRE/ in Spanish manpages? Absolutely, I don't even know how that got there :| Seriously, I'm, surprised, sorry making it into a problem. After having a better look at this issue, it seems like “NOMBRE DE REFERENCIA” was defined in XML, so I wonder if it should be fix there (and maybe can we push a workaround in po4a in the meantime). More precisely it can be found in /usr/share/xml/docbook/stylesheet/docbook-xsl/common/es.xml Spanish translator had been confused, he/she translated the key name, whereas the English string to translate can be found in /usr/share/xml/docbook/stylesheet/docbook-xsl/common/en.xml David, can you please explain to Omar how to report this bug, since you made similar bugreports for French few months ago? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604104: po4a: [INTL:ru] Russian program translation update
2010/11/20 Yuri Kozlov yu...@komyakino.ru: Package: po4a Version: 0.41-1 Severity: wishlist Tags: l10n patch Russian program translation update is attached. Hello Yuri, Your file contains errors: $ msgfmt -v -c -o /dev/null ru.po ru.po:1230: a format specification for argument 'l' doesn't exist in 'msgstr' ru.po:1235: a format specification for argument 'l' doesn't exist in 'msgstr' ru.po:1240: a format specification for argument 'l' doesn't exist in 'msgstr' ru.po:1245: a format specification for argument 'l' doesn't exist in 'msgstr' ru.po:1250: a format specification for argument 'l' doesn't exist in 'msgstr' ru.po:1255: a format specification for argument 'l' doesn't exist in 'msgstr' msgfmt: found 6 fatal errors 201 translated messages. In these msgids, $l contains the language code (for instance 'ru'). Can you please fix these errors? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603279: libopencascade-foundation-6.3.0: TKjcas lib is missing from package
On 2010/11/12 Yorik van Havre: Package: libopencascade-foundation-6.3.0 Version: 6.3.0.dfsg.1-6 Severity: normal Hi there, the libTKjcas-6.3.0.so library is missing from some of the packages (amd64, i386), although it is informed in the package description and appears in some other packages (hppa,kfreebsd). I'm not totally sure what it is used for, but it is needed by pythonOCC, so I suppose it makes sense to be included... I think if I recall correctly in ealier versions that library was included too... Hello, You are right, Java detection is broken, I guess that libgcj-common should be added to Build-Depends. Anyway libTKjcas-6.3.0.so is not needed to compile python-occ; you should try to build their SVN version, several fixes have been made to help building on Linux. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602387: po4a: out-of-tree builds can modify source PO files
On 2010/11/4 Colin Watson wrote: [...] The next thing in the build sequence would be debian/build/man. cjwat...@sarantium ~/src/debian/man-db/trunk/man-db$ svn st M debian M debian/changelog M debian/rules cjwat...@sarantium ~/src/debian/man-db/trunk/man-db$ make -C debian/build/man/po4a make: Entering directory `/home/cjwatson/src/debian/man-db/trunk/man-db/debian/build/man/po4a' make[1]: Entering directory `/home/cjwatson/src/debian/man-db/trunk/man-db/debian/build' make[1]: Leaving directory `/home/cjwatson/src/debian/man-db/trunk/man-db/debian/build' po4a --variable srcdir=../../../../man --variable builddir=../../man --keep 0 ../../../../man/po4a/po4a.cfg make: Leaving directory `/home/cjwatson/src/debian/man-db/trunk/man-db/debian/build/man/po4a' Thanks for this detailed bug report. Please note that technically this is not an out-of-tree build, your command works like gcc -I../../src -o ../../src/foo.o ../../src/foo.c To me, an out-of-tree build would be po4a --srcdir ../../../../man ../../../../man/po4a/po4a.cfg with po4a.cfg containing [po4a_langs] id pl ru [po4a_paths] po4a/po/man-db-manpages.pot $lang:po4a/po/$lang.po [po4a_alias:man] man opt:-L UTF-8 -o groff_code=verbatim [type:man] man1/apropos.man1 $lang:$lang/man1/apropos.man1 add_$lang:$lang/translator.add [type:man] man1/lexgrog.man1 $lang:$lang/man1/lexgrog.man1 add_$lang:$lang/translator.add [type:man] man1/man.man1 $lang:$lang/man1/man.man1 add_$lang:$lang/translator.add [type:man] man1/manconv.man1 $lang:$lang/man1/manconv.man1 add_$lang:$lang/translator.add [type:man] man1/manpath.man1 $lang:$lang/man1/manpath.man1 add_$lang:$lang/translator.add [type:man] man1/whatis.man1 $lang:$lang/man1/whatis.man1 add_$lang:$lang/translator.add [type:man] man1/zsoelim.man1 $lang:$lang/man1/zsoelim.man1 add_$lang:$lang/translator.add [type:man] man5/manpath.man5 $lang:$lang/man5/manpath.man5 add_$lang:$lang/translator.add [type:man] man8/accessdb.man8 $lang:$lang/man8/accessdb.man8 add_$lang:$lang/translator.add [type:man] man8/catman.man8 $lang:$lang/man8/catman.man8 add_$lang:$lang/translator.add [type:man] man8/mandb.man8 $lang:$lang/man8/mandb.man8 add_$lang:$lang/translator.add Unfortunately, an error is reported with po4a 0.40.1, this one is already fixed in our SVN repository. Next, this command may update POT and PO files (this depends on timestamps), which is the point of this bugreport. cjwat...@sarantium ~/src/debian/man-db/trunk/man-db$ svn st M debian M debian/changelog M debian/rules M man/po4a/po/ru.po M man/po4a/po/pl.po M man/po4a/po/id.po It would be very helpful if there were a way to force this not to happen. When I'm doing out-of-tree builds, I certainly do not want PO and POT files to be updated. In fact, in general I would prefer to be able to cause the 'make' step never to update PO and POT files, only 'make dist' or similar. Oh, this statement reminds me that I forgot to state my opinion about that in the other bug report. The 'make dist' target had been invented long before VCS were in common usage, tarballs were the most common way to publish sources. My interpretation is that gettext maintainers wanted to make sure that distributed PO files where up-to-date, that is why 'make dist' rebuilds them. But nowadays the situation is very different, translators have access to PO files at any time. If they were designing gettext now, IMHO they could let 'make' update PO files. I have to think more about your problem. I could use --translate-only, but that seems rather more tedious to use. Right, this option has been introduced to solve a very different problem: manpages contains hundreds of files, and a l10n team did not want to rebuild all manual pages to check their changes. With this option, they can run po4a --translate-only man3/foo.3 man3/man3.cfg Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599179: po4a: --rm-translations also updates PO/POT files
On 2010/10/5 Colin Watson wrote: On Tue, Oct 05, 2010 at 11:39:20AM +0100, Colin Watson wrote: If a master document is more recent than the POT, calling 'po4a --rm-translations' will have the side-effect of updating it and the PO files based on it. This is annoying because it makes it difficult to write a minimal patch for a Debian package that uses po4a upstream; the clean rule can end up changing source files, which is normally undesirable. Could you please either make --rm-translations do nothing except removing the translated files, or else add an option to inhibit updating the PO/POT files? In fact, ordinary calls to 'po4a' to generate translations (which I do during 'make') also involve updating the PO/POT files. I've had to do this in the man-db packaging: override_dh_auto_build: set -e; for preserve in man/po4a/po/*.pot man/po4a/po/*.po; do \ [ ! -e $$preserve.safe ] || continue; \ cp -a $$preserve $$preserve.safe; \ done dh_auto_build override_dh_auto_clean: dh_auto_clean set -e; for preserve in man/po4a/po/*.pot man/po4a/po/*.po; do \ [ -e $$preserve.safe ] || continue; \ mv $$preserve.safe $$preserve; \ done This is really pretty ugly, though. GNU gettext only updates these files on explicit request or when you say 'make dist', which I think is much better behaviour. Hello Colin, To be honest in our SVN trunk I already removed the --no-backups/--rm-backups flags (backup files are no more generated) and am inclined to also remove --rm-translations. These options do more harm than good, and I would much prefer if people do not run po4a to clean up generated files. Also your man/Rules.man file contains distclean-hook: @if [ x$(PO4A_LINGUA) = xyes ]; then \ -rm -rf man1 man5 man8; \ fi Thus I wonder why you need to remove files generated by po4a, aren't they already removed by 'debian/rules clean'? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599179: po4a: --rm-translations also updates PO/POT files
On 2010/11/3 Colin Watson wrote: [...] The other thing that may help would be if I made sure to build anything that uses po4a out-of-tree, so that any translated files are only changed in the separate build directory which is then thrown away. Right, IMO this is the best option. If it does not work, please file another bug report, I am definitely willing to support out-of-tree builds. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601982: pO4a: Should add support for translating the same string in two different ways
On 2010/11/1 Christian PERRIER wrote: Quoting David Prévot: I have two ideas of quirty fix for this one: either translate “None.” to “Sans.” in French, or add in the source file some invisible (non-break) space at the end of the one that doesn't have the same gender (at least in French). Actually, in apt, the problem has been solved at the source by dropping the two offendign sections, which are not very relevant anyway.:-) I already noticed a similar problem (in the maint-guide) I had to solve the second way, but wonder if it could be possible to force po4a to propose a different translation for the same string, using for example a tag (something similar to the “.if !'po4a'hide'” trick in roff). When I mentioned this problem during his po4a talk at Paris miniDebConf, Denis suggested that somethign similar to what is possible with po-debconf could be done (bracketed comments in the original string). Right, but I changed my mind. Po-debconf can use bracketed comments because debconf templates are processed by a program, whereas nroff documents are unmodified. Thus I do not know how to solve that problem for now. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595946: [text] improve support for asciidoc titles
tags 595946 +patch
thanks
2010/9/7 Michal Čihař ni...@debian.org:
Package: po4a
Version: 0.40.1-1
Severity: wishlist
File: /usr/share/perl5/Locale/Po4a/Text.pm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
currently po4a parses asciidoc titles properly, however it includes new
line in the po file. I think this should be avoided.
Hi,
Here is a patch against SVN trunk; unit tests are updated.
Denis
diff --git a/lib/Locale/Po4a/Text.pm b/lib/Locale/Po4a/Text.pm
index 8f703c8..9c58d1a 100644
--- a/lib/Locale/Po4a/Text.pm
+++ b/lib/Locale/Po4a/Text.pm
@@ -273,14 +273,15 @@ sub parse {
$wrapped_mode = 0;
my $level = $line;
$level =~ s/^(.).*$/$1/;
+$paragraph =~ s/\n$//s;
my $t = $self-translate($paragraph,
$self-{ref},
Title $level,
wrap = 0);
-$self-pushline($t);
+$self-pushline($t.\n);
$paragraph=;
$wrapped_mode = 1;
-$self-pushline(($level x (length($t)-1)).\n);
+$self-pushline(($level x (length($t))).\n);
} elsif ($asciidoc and
($line =~ m/^(={1,5})( +)(.*?)( +\1)?$/)) {
my $titlelevel1 = $1;
diff --git a/t/data-30/Attributes.po b/t/data-30/Attributes.po
index 02117ce..47f3485 100644
--- a/t/data-30/Attributes.po
+++ b/t/data-30/Attributes.po
@@ -18,7 +18,7 @@ msgstr
#. type: Title =
#: ../data-30/Attributes.asciidoc:2
#, no-wrap
-msgid Test Attributes\n
+msgid Test Attributes
msgstr
#. type: Attribute :Author:
diff --git a/t/data-30/BlockId.po b/t/data-30/BlockId.po
index 0227fc0..9e8d3de 100644
--- a/t/data-30/BlockId.po
+++ b/t/data-30/BlockId.po
@@ -18,7 +18,7 @@ msgstr
#. type: Title =
#: ../data-30/BlockId.asciidoc:2
#, no-wrap
-msgid Test BlockId Element\n
+msgid Test BlockId Element
msgstr
#. type: Plain text
diff --git a/t/data-30/BlockTitles.po b/t/data-30/BlockTitles.po
index 3109817..927b763 100644
--- a/t/data-30/BlockTitles.po
+++ b/t/data-30/BlockTitles.po
@@ -18,7 +18,7 @@ msgstr
#. type: Title =
#: ../data-30/BlockTitles.asciidoc:2
#, no-wrap
-msgid Test BlockTitles\n
+msgid Test BlockTitles
msgstr
#. type: Block title
diff --git a/t/data-30/Callouts.po b/t/data-30/Callouts.po
index ce9d48a..8f8aa54 100644
--- a/t/data-30/Callouts.po
+++ b/t/data-30/Callouts.po
@@ -18,7 +18,7 @@ msgstr
#. type: Title =
#: ../data-30/Callouts.asciidoc:2
#, no-wrap
-msgid Test Callouts\n
+msgid Test Callouts
msgstr
#. type: Block title
diff --git a/t/data-30/DelimitedBlocks.po b/t/data-30/DelimitedBlocks.po
index 12be7df..c3bec53 100644
--- a/t/data-30/DelimitedBlocks.po
+++ b/t/data-30/DelimitedBlocks.po
@@ -18,13 +18,13 @@ msgstr
#. type: Title =
#: ../data-30/DelimitedBlocks.asciidoc:2
#, no-wrap
-msgid Test Delimited Blocks\n
+msgid Test Delimited Blocks
msgstr
#. type: Title -
#: ../data-30/DelimitedBlocks.asciidoc:5
#, no-wrap
-msgid Predefined Delimited Blocks\n
+msgid Predefined Delimited Blocks
msgstr
#. type: Plain text
diff --git a/t/data-30/Footnotes.po b/t/data-30/Footnotes.po
index 2ae88a9..69b7a50 100644
--- a/t/data-30/Footnotes.po
+++ b/t/data-30/Footnotes.po
@@ -18,7 +18,7 @@ msgstr
#. type: Title =
#: ../data-30/Footnotes.asciidoc:2
#, no-wrap
-msgid Test Footnotes\n
+msgid Test Footnotes
msgstr
#. type: Plain text
diff --git a/t/data-30/Lists.po b/t/data-30/Lists.po
index 00beaac..0b9b5d0 100644
--- a/t/data-30/Lists.po
+++ b/t/data-30/Lists.po
@@ -18,13 +18,13 @@ msgstr
#. type: Title =
#: ../data-30/Lists.asciidoc:2
#, no-wrap
-msgid Test Lists\n
+msgid Test Lists
msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:5
#, no-wrap
-msgid Bulleted and Numbered Lists\n
+msgid Bulleted and Numbered Lists
msgstr
#. type: Plain text
@@ -97,7 +97,7 @@ msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:38
#, no-wrap
-msgid Vertical Labeled Lists\n
+msgid Vertical Labeled Lists
msgstr
#. type: Labeled list
@@ -154,7 +154,7 @@ msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:59
#, no-wrap
-msgid Horizontal Labeled Lists\n
+msgid Horizontal Labeled Lists
msgstr
#. type: Labeled list
@@ -193,7 +193,7 @@ msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:76
#, no-wrap
-msgid Question and Answer Lists\n
+msgid Question and Answer Lists
msgstr
#. type: Labeled list
@@ -221,7 +221,7 @@ msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:83
#, no-wrap
-msgid Glossary Lists\n
+msgid Glossary Lists
msgstr
#. type: Labeled list
@@ -244,7 +244,7 @@ msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:91
#, no-wrap
-msgid Bibliography Lists\n
+msgid Bibliography Lists
msgstr
#. type: Plain text
@@ -274,7 +274,7 @@ msgstr
#. type: Title -
#: ../data-30/Lists.asciidoc:102
#, no-wrap
-msgid Bibliography\n
+msgid Bibliography
msgstr
#. type: Plain text
@@ -287,7 +287,7
Bug#595579: unblock po4a/0.40.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock On 2010/8/17 Julien Cristau wrote: Hi Denis, On Sun, Aug 15, 2010 at 21:43:30 +0200, Denis Barbier wrote: Hello, I am an upstream maintainer of po4a. We released po4a 0.40 in late July 2010 with a very short string freeze, and we told translators that they will have a much longer string freeze to update their translations in 0.40.1. Po4a 0.40 already migrated into testing, and we will release 0.40.1 on 2010-08-25. We fixed many inconsistencies in documentation, and received translation updates, which is why we would like to have po4a 0.40.1-1 shipped in squeeze instead of 0.40-1. Can this version be uploaded into unstable when it is released? (And later on migrated into testing) Documentation and translation updates are ok for freeze exceptions (at least at this stage of the freeze), so feel free to upload and tell us when you need the unblock. Po4a 0.40.1-1 is in unstable for 10 days. As said in my original mail, the diff is huge because it contains many documentation and translation fixes. Here is the changelog entry: po4a (0.40.1-1) unstable; urgency=low [ Denis Barbier ] * New upstream release. + Style update in documentation. + Mention po4a-build in po4a(1). Closes: #565422 + Use 'Software in the Public Interest'. Closes: #590502 + Change header entry in PO files to be consistent with xgettext when creating POT files. + Trailing spaces must not be removed from translations if they are escaped. Closes: #593106 * debian/control: Upstream repository has switched from CVS to SVN, update Vcs-* fields. [ Updated program translations ] * French, by David Prévot * Spanish, by Omar Campagne * Japanese, by KURASAWA Nozomu * Esperanto, by Joop Eggen * Swedish, by Martin Bagge * Russian, by Yuri Kozlov (Closes: #592041) * Estonian, by Annika * Ukrainian, by Yuri Chornoivan * Czech, by Michal Šimůnek (Closes: #592330) * Portuguese, by António Moreira * German, by Thomas Müller (Closes: #594258) [ Updated documentation translations ] * French, by David Prévot * Spanish, by Omar Campagne * Japanese, by KURASAWA Nozomu -- Nicolas FRANCOIS (Nekral) nicolas.franc...@centraliens.net Wed, 25 Aug 2010 23:16:59 +0200 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592756: 592756-submit...@bugs.debian.org
Hello Neil, You missed the point about AUTHORS, the problem is that the word itself is not translated in the generated manual page. For instance in French, we want to have .SH AUTEURS instead of .SH AUTHORS xsltproc is able to produce translated section names in manual pages, but only if it knows in which language the XML document is written. This is why David added lang=en; po4a will extract this attribute, then translating msgid en msgstr fr in fr.po will add lang=fr in French translated XML file, and xsltproc will provide fully translated manual pages. Please note that AUTHORS is not a good example here, it won't be translated in French just now because of #594649, you may try with AUTHOR instead if you want to test. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593657: salome: cannot find libStdPlugin.so
On 2010/8/20 Adam C Powell IV wrote:
[...]
It's also worth asking: could a change like this let us drop the salome
dependency on libopencascade-visualization-dev? As I recall, that
dependency was added to avoid a similar error while loading a
non-versioned plugin.
[...]
Your log message for f995e2cb is not detailed enough, so it is hard to tell.
BTW I had a look at your recent commits, and was surprised to see that
you truncated my log message to keep only the first line on these
commits:
* Add AM_MAINTAINER_MODE into all configure.ac files
* Add --disable-dependency-tracking to configure flags
Do not ask me in 4 months why these changes are good for, I won't
remember why without detailed log messages ;)
And just curious, why don't you use gitk to cherry-pich commits? I
find this tool extremely useful.
Now back to your question, you set
export CSF_GraphicShr=${CASROOT}/lib/libTKOpenGl.so
in runSalome, which is shipped by libopencascade-visualization-dev. I
do not understand why, everything should work fine without setting
this variable, maybe you could simply remove this line from runSalome?
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593656: salome: strange warnings with dash
Package: salome Version: 5.1.3-9 Severity: minor Tag: pending For instance when closing a project, this error is printed: sh: Syntax error: Bad fd number This is because at several places, upstream uses csh construct instead of 2. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593657: salome: cannot find libStdPlugin.so
Package: salome Version: 5.1.3-9 Severity: grave When switching to the MESH module, salome throws a fatal error, and console contains this message: could not open: StdPlugin ; reason: libStdPlugin.so: cannot open shared object file: No such file or directory Unable to load component Since salome cannot access the MESH module, it is IMO unusable, hence the severity of this bug. There are at least 2 ways to fix this problem: * Let salome depend on libopencascade-ocaf-dev. * Modify /usr/share/salome/resources/geom/Plugin to append -6.3.0 to library names I prefer the latter. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591906: manpages-fr-extra: LC_ALL=fr_FR.UTF-8 man sh gives the man page of bash instead of dash
Vincent Lefevre wrote:
Package: manpages-fr-extra
Version: 20100723
Severity: normal
I have: /bin/sh - dash. But when I type:
LC_ALL=fr_FR.UTF-8 man sh
I get the man page of bash instead of the man page of dash.
No such problem with the English version.
The English version is managed by
/var/lib/dpkg/info/dash.{postinst,prerm}, IMO these scripts should
take care of translated manual pages as well.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573820: podebconf-display-po: Broken text on buttons
Yuri Kozlov wrote: Running podebconf-display-po ru.po give a broken text on buttons (random unexpected symbols). Hi Yuri, I cannot reproduce this bug, do you still have this issue? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571262: po-debconf: avoid bloating templates with translations identical to C text
reassign 571262 intltool-debian
found 571262 0.35.0+20060710.1
tag 571262 patch
thanks
There are some corner cases, consider this example:
Template: partman-xfs/text/xfs
Type: text
Description: xfs
Description-pt.UTF-8: XFS
Description-pt_BR.UTF-8: xfs
pt_BR translation must not be dropped, otherwise XFS will be displayed
instead of xfs.
Here is a patch, translation is removed only if language does not
contain locale modifiers (i.e. _ or @ characters).
Here is also a slightly updated tarball, in case Nicolas or someone
else want to update intltool-debian.
Denis
--- /usr/share/intltool-debian/intltool-merge
+++ /usr/share/intltool-debian/intltool-merge
@@ -1340,8 +1340,12 @@
next unless $is_translated;
$str_translated =~ s/\s+$//;
-$str_translated = ' '.$str_translated if length ($str_translated) $str_translated !~ /^\n/s;
+# To save space, do not print translation if it is identical to
+# original text and if translation cannot be found in another language
+next if ($str_translated eq $stripped $lang !~ m/[...@]/);
+
+$str_translated = ' '.$str_translated if length ($str_translated) $str_translated !~ /^\n/s;
$_ = $non_translated_line;
s/^(\w+):\s*.*/$newline${1}-$lang.$encodings{$lang}:$str_translated/s;
print OUTPUT;
intltool-debian_0.35.1+1.tar.gz
Description: GNU Zip compressed data
Bug#556296: po4a: wrong encoding in output of po4a-gettextize fixed?
tags 556296 - moreinfo tags 556296 + pending thanks On 2010/7/27 David Prévot wrote: [...] Just tested your files on my box, which use fr_FR.UTF-8: ИМЯ now seems to be correctly handled. If you you don't experience this issue anymore, maybe could we close this bug ? [...] Hi David, I fixed this bug in CVS but forgot to tag it pending, sorry about that. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589883: podebconf-report-po: print a list of recipients before sending mails
Package: po-debconf
Version: 1.0.16
Severity: wishlist
Tags: patch
Hi,
When podebconf-report-po prompts whether to send mails, it would be
nice to print a list of files and recipients in case checkboxes have
been unchecked or deleted.
Here is a proposed patch.
Denis
--- podebconf-report-po
+++ podebconf-report-po
@@ -877,6 +877,12 @@
my $with_mutt = ;
$with_mutt = (with mutt) if $MUTT;
QUESTION:
+ print The following files have been selected:\n;
+ foreach my $poFile (sort keys %$poFiles) {
+ next unless defined $To{$poFile};
+ print $poFile To: $To{$poFile}\n;
+ }
+ print End of files\n;
if ($SUBMIT_ARG) {
print Ready to send$with_mutt the bug report against the package $PACKAGE_ARG, are you sure? $answers ;
} elsif (length $CALL) {
Bug#585139: po4a: [xhtml module] span tag should not be an inline tag
Patrick Zanon wrote: Hi all, I am using the great po4a package and I would like to propose a little change in the Xhtml package. The span tag should not be an inline tag since it is used to break the line into smaller pieces which should have an independent treatment, especially for translations. Here is an example: spanLast update:/span spanSeptember 10, 2009/span spanby pkz/span In this line of xhtml the only translation that should be updated each time the page is changed is the date (the second span object), while the first and the last piece should not be changed. At present, if the page is changed, the whole line with the three span objects should be re-translated completely. Hello Patrick, I disagree, when a sentence is cut into smaller pieces, it is almost always a bad idea to translate pieces separately. Maybe in some languages you will have a different order, or Last update may change depending on the gender of who made that change, etc. These pieces may be separate lexical units in English, but you cannot be sure that they are also independent in any language, thus it is better to translate the full sentence. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584624: po4a: strange warning about You should translate the source file
Hello Yuri, This warning is printed because po4a tries to guess when manual pages are generated by looking for the generated word in comment. The full comment is printed to help you determining whether this page is really generated or not. If it has indeed been generated, you should translate the original file. If not, as is the case here, you can add opt:-o generated into your .cfg file to hide this warning. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588879: po4a: [man] Add support for TQ macro
Many thanks, James, I have tested and committed your patch. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571740: po4a: Add example to po4a(1)
tags 571740 + pending thanks Hi Helge, Since Nicolas made no objection in the mentioned thread, I applied your patch http://alioth.debian.org/scm/viewvc.php/po4a/po4a?root=po4ar1=1.101r2=1.102 with minor modifications: * I removed all Debianisms, po4a is used outside of Debian * I did not undestand your point about using -f flag when calling po4a Please tell me if you have problems with these changes. Thanks for your help. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581620: atlas: FTBFS on hppa
Hi Sylvestre, To help digging into this issue, the build system should abort as soon as an unexpected error occurs. I do not know whether this is enforced by upstream Makefiles, but you should at least fix debian/rules, patch attached. Is it normal that 'check' and 'ptcheck' targets are allowed to fail? This does not make much sense to me to run tests in this case, but I did not add 'set -e' there. Please also consider applying vcs.patch to fix Vcs metadata in debian/control. Thanks Denis rules.patch Description: Binary data vcs.patch Description: Binary data
Bug#584590: salome: New binary package organization
On 2010/6/16 Adam C Powell IV wrote: [...] I think the release goals for -10 should be as follows: * This change for faster development * Separate build tree(s) as you implemented before in a patch * Split the package as described above (plus salome-dev) * Bug fixes already in alioth Sounds good? Any others? I think this is doable by the end of next week. The salome package contains many files /usr/lib/salome/lib/_lib*.so which are not libraries but python modules, and must thus be installed elsewhere in order to be loaded by python. I started working on this issue, see the wip/python branch in my repository. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584590: salome: New binary package organization
On 2010/6/16 Adam C Powell IV wrote: [...] IMO the main problem just now is that this package is very difficult to manage due to its size and to the resources needed to build it. I modified debian/rules to help with testing packaging changes. New targets are provided for each salome module individually: reconfigure (by calling build_configure), configure, build and install. I added AM_MAINTAINER_MODE into all configure.ac files so that one can modify Makefile.am files without having to always rebuild everything, this can save a lot of time. This work has been done in the 'dev' branch of a cloned repo, see http://git.debian.org/?p=users/barbier-guest/salome.git;a=log;h=refs/heads/dev It has not been fully tested, some things may have to be fixed, but I believe that this branch should be committed anyway. This sounds good to me. Is there a way you can make this into a patch or two? That will make it easier for me to get it into alioth. Hi Adam, It is IMO much better to keep logical patchsets. You can run these commands: git remote add barbier git://git.debian.org/users/barbier-guest/salome.git git fetch barbier git checkout -b dev barbier/dev to retrieve my changes and then you can play with patches as usual. If you really want to squash patches together, you can run git rebase -i master dev This opens up an editor containing this text: pick 92fa1d3 New target: reconfigure-stamp pick bacf6e6 Add AM_MAINTAINER_MODE into all configure.ac files pick 6bb56d8 Add --disable-dependency-tracking to configure flags [etc] Replace all 'pick' words but the first one by 'squash', and voila. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584590: salome: New binary package organization
On 2010/6/4 Adam C Powell IV wrote: Package: src:salome Version: 5.1.3-8 Severity: wishlist X-Debbugs-CC: andre.esp...@logilab.fr Greetings, To reduce the demand on users' disks, it would be helpful to split the salome package into multiple separate packages according to utility. André Espaze and I discussed this last month in debian-science [1] and the parameters discussed there would make a good division of the package: * The main salome package with core modules KERNEL, GUI, GEOM, MED, SMESH, YACS, VISU * A salome-extras package including MULTIPR, NETGENPLUGIN (when it works), RANDOMIZER and SIERPINSKY * Pre-compiled salome-example-modules with LIGHT, PYLIGHT, COMPONENT, HELLO, PYHELLO, CALCULATOR and PYCALCULATOR * A salome-test package with all of the binaries containing test Test TEST etc. in their name, and if practical, a script to automate running all of the tests * Separate salome-doc for non-built docs, and salome-user-doc and salome-dev-doc for docs built using the usr_docs and dev_docs make targets (once Debian has the disk space for all ~600 MiB of docs!) [1] http://lists.debian.org/debian-science/2010/04/msg6.html Thoughts and contributions are welcome. This will probably happen in the -10 release. Hi Adam, IMO the main problem just now is that this package is very difficult to manage due to its size and to the resources needed to build it. I modified debian/rules to help with testing packaging changes. New targets are provided for each salome module individually: reconfigure (by calling build_configure), configure, build and install. I added AM_MAINTAINER_MODE into all configure.ac files so that one can modify Makefile.am files without having to always rebuild everything, this can save a lot of time. This work has been done in the 'dev' branch of a cloned repo, see http://git.debian.org/?p=users/barbier-guest/salome.git;a=log;h=refs/heads/dev It has not been fully tested, some things may have to be fixed, but I believe that this branch should be committed anyway. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585615: salome: FTBFS on many architectures
Package: src:salome Version: 5.1.3-9 Severity: serious Tags: patch Hello, Here are 2 patches: * kernel-cleanup.patch Fix FTBFS when compiling with lam * geom-fix-powerpc.patch Fix FTBFS on powerpc Denis kernel-cleanup.patch Description: Binary data geom-fix-powerpc.patch Description: Binary data
Bug#584590: salome: New binary package organization
On 2010/6/4 Adam C Powell IV wrote: [...] * Separate salome-doc for non-built docs, and salome-user-doc and salome-dev-doc for docs built using the usr_docs and dev_docs make targets (once Debian has the disk space for all ~600 MiB of docs!) [...] Hello, we faced a similar problem in VTK, the vtk-doc package became huge at some point because a newer doxygen generates images with antialiased fonts. Our first workaround has been to not use antialiased fonts by wrapping /usr/bin/dot: http://git.debian.org/?p=collab-maint/vtk.git;a=commitdiff;h=45a29f66 Later won e generated images into SVG format, this is supported since doxygen 1.6.2; images are rendered much better and IIRC size is even smaller than with PNG non-antialiased fonts. http://git.debian.org/?p=collab-maint/vtk.git;a=commitdiff;h=3d9afe06 I suggest to generate docs in SVG and see if salome-doc's size becomes reasonable. In KERNEL_SRC_5.1.3/doc/salome/gui/doxyfile.in: -DOT_IMAGE_FORMAT = jpg +DOT_IMAGE_FORMAT = svg I am busy with other stuff and won't try that now. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584172: Disabling GetIDMapper inlining for building VISU
On 2010/6/7 Andre Espaze wrote: [...] $ patch -p1 no-template-function-inline.patch $ patch -p1 debian/patches/visu-no-template-inline.patch Thanks André for these detailed explanations, but why do you apply both patches? I thought that visu-no-template-inline.patch was superseding no-template-function-inline.patch. (Adam too since he committed only the former) To make it clear, my point is that #if macro can be dropped from visu-no-template-inline.patch, the result will be unchanged: * When compiled in debug mode, functions are not inlined and 4 symbols are exported. * When compiled with optimization, only one symbol is exported. Since those macros do nothing, it is better to strip them off and follow what is described in the C++ faq. If you want no-template-function-inline.patch to be applied, then visu-no-template-inline.patch should be dropped. $ cd VISU_SRC_5.1.3/src/CONVERTOR $ mv Makefile.orig Makefile $ make $ readelf -s .libs/libVisuConvertor_la-VISU_MergeFilterUtilities.o | \ grep GetIDMapper 89: 113 FUNC WEAK DEFAULT 48 _ZN4VISU11GetIDMapperINS_ 95: 54 FUNC WEAK DEFAULT 50 _ZN4VISU11GetIDMapperINS_ 96: 54 FUNC WEAK DEFAULT 52 _ZN4VISU11GetIDMapperINS_ 97: 113 FUNC WEAK DEFAULT 54 _ZN4VISU11GetIDMapperINS_ [...] These symbols are exported because of no-template-function-inline.patch, not visu-no-template-inline.patch. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584172: Disabling GetIDMapper inlining for building VISU
On 2010/6/7 Andre Espaze wrote: On Mon, Jun 07, 2010 at 06:06:58PM +0200, Denis Barbier wrote: On 2010/6/7 Andre Espaze wrote: [...] $ patch -p1 no-template-function-inline.patch $ patch -p1 debian/patches/visu-no-template-inline.patch Thanks André for these detailed explanations, but why do you apply both patches? If you check out revision f57b74db488c, visu-no-template-inline.patch does not exist yet, so the first patch adds it. [...] Okay, I obviously did not carefully read your message and thought that we were discussing about visu-template-export.patch, sorry for the trouble. Actually Adam did apply your visu-template-export.patch, and not visu-no-template-inline.patch, hence my confusion. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584285: salome: FTBFS: hxx2salome.cpp:247: error: 'system' is not a member of 'std'
Hello, Here is a new series of patches. I am still unable to build salome; disk space is okay now, but dpkg-shlibdeps aborted due to memory allocation errors on my laptop with 2GB of RAM. - 0001 Add 'set -e' before loops on modules in build and install targets - 0002 Add Vcs fields into debian/control - 0003 Add missing Build-Depends: libqt4-opengl-dev - 0004 Remove libcppunit-dev from Build-Depends. Tests are not run, so there is little value in compiling them - 0005 Add --disable-dependency-tracking --disable-maintainer-mode to configure flags. This remove some targets in Makefiles and should speed up a little bit compilation. Unfortunately the speed up is quite low, around 9%. Denis 0001-Also-add-set-e-before-loops-on-modules-in-build-and-.patch Description: Binary data 0002-Add-Vcs-fields-into-debian-control.patch Description: Binary data 0003-Add-missing-Build-Depends-libqt4-opengl-dev.patch Description: Binary data 0004-Remove-libcppunit-dev-from-Build-Depends.patch Description: Binary data 0005-Add-disable-dependency-tracking-disable-maintainer-m.patch Description: Binary data
Bug#584285: salome: FTBFS: hxx2salome.cpp:247: error: 'system' is not a member of 'std'
On 2010/6/4 Adam C Powell IV wrote: [...] Ah, right, I didn't use pbuilder, so I likely had all of the Build-Depends-Indep packages installed already. Okay. I am building a package right now within pbuilder, and it failed due to missing Build-Depends: libqt4-opengl-dev required by GUI component. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584285: salome: FTBFS: hxx2salome.cpp:247: error: 'system' is not a member of 'std'
On 2010/6/3 I wrote: [...] The problem is that patches are unapplied by autobuilders, they have to be applied before running configure. A patch will look like --- debian/rules +++ debian/rules @@ -84,7 +84,10 @@ clean: rm -f *-stamp dh_clean -configure-stamp: +patch-stamp: + QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2 Oops, I forgot touch $@ here. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584285: salome: FTBFS: hxx2salome.cpp:247: error: 'system' is not a member of 'std'
On 2010/6/4 Adam C Powell IV wrote: [...] Well, everything seems to work now, all four bugs are closed, and it runs. I think I'm going to merge the salome, libsalome5.1.3-0, libsalome-dev and python2.5-salome binary packages, then declare victory and upload -9. If that gets into testing, I'll be happy. Sounds good? Did you check by running binary-arch target only, as mentioned in my first reply? I am surprised that it works, I would expect that all packages listed in Build-Depends-Indep should be moved into Build-Depends, but I did not try to build it. If only doxygen had to be moved, this is of course fine. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'
On 2010/6/3 Adam C Powell IV wrote: [...] Unfortunately this will likely require the use of rpath to get to the libs, this is frowned upon in general in Debian. [...] Are those libraries private to salome? (In other words, are you sure that no other package will be linked against them?) * If yes, there is no reason to provide libsalome5.1.3-0 and libsalome-dev packages, these libs are shipped by another package (python2.5-salome?) and can safely be moved into /usr/lib/salome/ * If no, they should indeed go into /usr/lib/ but name collisions will happen. Maybe the answer is a mix of both, some libs are private and some others are public. BTW when looking at this issue, I found that python2.5-salome contains shared libraries, it thus must be arch:any and not arch:all. It also contains static libraries which can surely be dropped. BTW2, I wonder whether salome, python2.5-salome, libsalome5.1.3-0 and libsalome-dev could be merged into a single package (if all libs are private, of course). Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584285: salome: FTBFS: hxx2salome.cpp:247: error: 'system' is not a member of 'std'
On 2010/6/3 Adam C Powell IV wrote: severity 584285 serious thanks Hello Cyril, I started seeing this error as well when building on Ubuntu Jaunty -- not at first, but more recently. It's curious, why would a C++ standard interface bug start showing up in Jaunty, when Sid continued to build just fine? I suspect my unstable chroot has a build dependency not listed in Build-Depends, but what would alleviate this error? I'm afraid I'm not a C++ expert. Denis or André, I hate to keep calling on you, but do you know how we might fix this? Hi Adam, I am working on it. This error looks indeed strange, but in fact it is not related to C++, this is because configure silently fails, and no Makefile was generated for KERNEL_SRC. If you use pbuilder, you should be able to reproduce this bug by running sudo pbuilder --binary-arch The problem is that patches are unapplied by autobuilders, they have to be applied before running configure. A patch will look like --- debian/rules +++ debian/rules @@ -84,7 +84,10 @@ clean: rm -f *-stamp dh_clean -configure-stamp: +patch-stamp: + QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2 + +configure-stamp: patch-stamp dh_testdir # Move aside obsolete files for obsoletefile in KERNEL_SRC_$(SALOME_VERSION)/bin/runSalome \ But there are other problems, I will try to provide working patches tonight. P.S.: no need to Cc me, I subscribed to PTS. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584285: salome: FTBFS: hxx2salome.cpp:247: error: 'system' is not a member of 'std'
On 2010/6/3 Adam C Powell IV wrote: [...] A patch will look like --- debian/rules +++ debian/rules @@ -84,7 +84,10 @@ clean: rm -f *-stamp dh_clean -configure-stamp: +patch-stamp: + QUILT_PATCHES=debian/patches quilt push -a || test $$? = 2 + +configure-stamp: patch-stamp dh_testdir # Move aside obsolete files for obsoletefile in KERNEL_SRC_$(SALOME_VERSION)/bin/runSalome \ But there are other problems, I will try to provide working patches tonight. Wonderful, thanks! Here are several patches: * 0001 is the patch mentioned above * 0002 and 0003 make build abort when something goes wrong * 0004 implements what is described in /usr/share/doc/autotools-dev/README.Debian.gz as best practice. It is more complicated than I would like, because of the way upstream uses autotools. It has not been fully tested. * 0005 tries to make removal of generated files simpler, it has been even less tested. Thus I suggest you to commit 0001-003. 0004 could also be committed after review. About 0005, you decide whether building out of source tree is a good idea. This will not fix all FTBFS, I also saw problems related to doxygen. I did not have time to investigate yet, but I believe that docs are also generated when running the build-arch target; doxygen will not be installed on autobuilders and build will fail. Denis 0001-Fix-FTBFS-patches-must-be-applied-before-building.patch Description: Binary data 0002-Abort-in-clean-target-if-quilt-pop-fails.patch Description: Binary data 0003-Abort-when-a-module-cannot-be-configured.patch Description: Binary data 0004-DO-NOT-COMMIT-NOT-FULLY-TESTED-In-clean-target-remov.patch Description: Binary data 0005-DO-NOT-COMMIT-NOT-FULLY-TESTED-Build-out-of-tree.patch Description: Binary data
Bug#584172: Disabling GetIDMapper inlining for building VISU
On 2010/6/2 Andre Espaze wrote: It is finally not necessary to build the module with the -g option, I have enclosed a patch that disable the GetIDMapper function inlining when built with g++ and optimizations. Hello, I am no C++ expert, but this looks very similar to http://www.parashift.com/c++-faq-lite/templates.html#faq-35.13 and it is thus not clear whether this is really a g++ bug. Here is a different fix, I tested this approach with Andre's test.cpp, but not with salome. Denis instantiation.patch Description: application/empty
Bug#584172: Disabling GetIDMapper inlining for building VISU
On 2010/6/2 Andre Espaze wrote: Hello Denis, On Wed, Jun 02, 2010 at 10:30:15AM +0200, Denis Barbier wrote: On 2010/6/2 Andre Espaze wrote: It is finally not necessary to build the module with the -g option, I have enclosed a patch that disable the GetIDMapper function inlining when built with g++ and optimizations. I am no C++ expert, but this looks very similar to http://www.parashift.com/c++-faq-lite/templates.html#faq-35.13 and it is thus not clear whether this is really a g++ bug. Here is a different fix, I tested this approach with Andre's test.cpp, but not with salome. Thank you very much for the suggestion, it works but it seems to me that you forgot a 'template' keyword before the symbol export. Oops, you are fully right, sorry. A new patch is attached for reference. I have enclosed a patch tested on my machine, fell free to correct it if I was wrong. [...] I do not understand why you added #if tests, just adding 'template' at the very beginning is enough. It was not explicit in my previous mail, but I tried to find an alternative solution because your's works only with g++, and you will need those #if tests if you want to forward it upstream. OTOH mine is portable, and it could be adopted more easily by upstream, I guess. Within Debian, which patch is checked in does not matter. Denis instantiation2.patch Description: application/empty
Bug#584172: Disabling GetIDMapper inlining for building VISU
On 2010/6/2 Andre Espaze wrote: [...] Your solution is however better because the exported symbols are in control while in my case I remove every GetIDMapper function inlining. [...] It seems that there is some disagreement between us, I believe that the sentence above is the root cause. You say that my solution gives a better control on symbols which are exported, but my opinion is that both solutions provide the exact same API. Can you please explain the differences induced by those patches? (For instance by running objdump, readelf,... on generated libraries and comparing output) Thanks. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584300: libvtk5-dev: Remove information about wrapped languages from VTKConfig.cmake
Package: libvtk5-dev Version: 5.4.2-7 Severity: wishlist Tags: patch Hello, The file /usr/lib/vtk-5.4/VTKConfig.cmake contains configuration used when building package, in particular information about wrapped languages are hardcoded. For instance VTK_WRAP_PYTHON is always set to true even if python-vtk is not installed. This patch puts snippets about wrapped languages into separate files, which are shipped by python-vtk, vtk-tcl and libvtk-java. Please tell me whether I could create a branch on git.d.o with this patch, maybe it will be easier to discuss this feature. Denis split-vtkconfig.patch Description: Binary data
Bug#582565: vtk: FTBFS with python 2.6 because of hard-coded site-packages directory
On 2010/5/25 Sandro Tosi wrote: [...] this happened some days ago: do you need sponsoring for the upload? we (as in python folks) would like to see this fixed asap, so if need some help just ask :) I do not maintain vtk. Maitland, can you please tell python folks if you will upload soon or if they can NMU? Thanks. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582505: python-rpy2: No modules compiled for Python 2.5
According to http://www.python.org/dev/peps/pep-3123/ the attached patch should work. I have tested that python-rpy2 compiles, but do not know whether it works fine. Denis rpy2-python2.5.patch Description: application/empty
Bug#582505: python-rpy2: No modules compiled for Python 2.5
On 2010/5/25 Dirk Eddelbuettel wrote: Denis, On 25 May 2010 at 11:56, Denis Barbier wrote: | According to | http://www.python.org/dev/peps/pep-3123/ | the attached patch should work. I have tested that python-rpy2 | compiles, but do not know whether it works fine. Wow, that would be a good catch. I guess Laurent may have been unaware too. I just applied the three-line patch -- but it does not work: [...] Here is a revised patch against rpy2 2.1.2. It builds fine with python2.5 and python2.6, but I do not know how to test it. Regards, Denis --- rpy2-2.1.2.orig/rpy/rinterface/rpy_rinterface.h +++ rpy2-2.1.2/rpy/rinterface/rpy_rinterface.h @@ -25,7 +25,7 @@ typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **); #endif #if (PY_VERSION_HEX 0x0206) -typedef Py_SIZE Py_Size; +#define Py_SIZE(ob) (((PyVarObject*)(ob))-ob_size) #endif
Bug#582565: vtk: FTBFS with python 2.6 because of hard-coded site-packages directory
On 2010/5/21 Fabrice Coutadeur wrote: Package: vtk Version: 5.4.2-6 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu maverick ubuntu-patch Hi, After applying the patch to fix the FTBFS with boost1.42, the package FTBFS in Ubuntu because of python 2.6. *** /tmp/tmpUOfWSo In Ubuntu, the following changes are required to make the package build with python 2.6: * debian/rules: deleted commands to copy the python package * python-vtk.install: install also the python part, deleted from debian/rules We thought you might be interested in doing the same. Hi Fabrice, I tried your patch, but contents of python-vtk differ: * VTK-5.4.2.egg-info is installed into /usr/share/pyshared/vtk/ whereas it was shippad into /usr/share/pyshared/ * With your patch, files are shipped both in /usr/lib/python2.5/site-packages/vtk and /usr/share/pyshared/vtk/ I am not a Python guy, so any help is welcome to fix those errors. Thanks Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582565: vtk: FTBFS with python 2.6 because of hard-coded site-packages directory
tags 582565 + pending thanks On 2010/5/22 Jakub Wilk wrote: [...] * With your patch, files are shipped both in /usr/lib/python2.5/site-packages/vtk and /usr/share/pyshared/vtk/ Hmm, are they? Could you post full output of dpkg -c python-vtk*.deb? Okay, something went wrong during my rebuild last night, I ran out of disk space, and I must have made some error when running debian/rules again to finish the build. I just retried and everything works fine now, thus I committed Fabrice's patch. Thanks for your help. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582455: vtk: FTBFS with boost1.42 because of missing boost/vector_property_map.hpp
tags 582455 + pending thanks On 2010/5/20 Fabrice Coutadeur wrote: Package: vtk Version: 5.4.2-6 Severity: important Justification: fails to build from source Hi, when trying to build vtk in sid, I'm getting the following error: ... [ 92%] Building CXX object Infovis/CMakeFiles/vtkInfovis.dir/vtkBoostBiconnectedComponents.cxx.o /build/fabrice-vtk_5.4.2-6-amd64-S7TpoQ/vtk-5.4.2/Infovis/vtkBoostBiconnectedComponents.cxx:35:41: error: boost/vector_property_map.hpp: No such file or directory This is because boost1.42 changed the place of some hpp files. A patch has been applied by gentoo, to fix this FTBFS: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/vtk/files/vtk-5.4.2-boost-property_map.patch?rev=1.1content-type=text/plain Hi Fabrice, A patch has already been applied in git repository, see http://git.debian.org/?p=collab-maint/vtk.git;a=commitdiff;h=cfa93fd Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561396:
On 2010/5/19 Mathieu Malaterre wrote:
[...]
Information about needed libraries are already embedded within ELF
shared objects.
BTW I just tried and have been able to build gdcm package after
echo /usr/lib/vtk-5.4/VTKLibraryDepends.cmake
I think Brad King rejected your patch because you were not propagating
vtkCommon or vtksys as an automatic dep.
I do not remember exactly and will read those mails again, but please
note that our situation is very different from upstream: we do not
support static linking (there is no static library in libvtk5-dev),
and we already have transitive linking via the ELF format, so IMHO
VTKLibraryDepends.cmake may be different from upstream.
So if you have an empty /usr/lib/vtk-5.4/VTKLibraryDepends.cmake, you
should be able to produce a simple example that does:
add_executable(bla bla.cxx)
target_link_libraries(bla vtkFiltering) # cmake will pull
vtkCommon/vtksys dep automatically.
In this case you can produce a different behavior for an installed
tree VTK vs a build tree VTK.
Sorry, I do not understand your test case, it seems to work just fine here:
sudo sed -i -e 's/^/#/' /usr/lib/vtk-5.4/VTKLibraryDepends.cmake
echo 'int main() { }' B.cxx
echo 'FIND_PACKAGE(VTK REQUIRED)
ADD_EXECUTABLE(B B.cxx)
TARGET_LINK_LIBRARIES(B vtkFiltering)' CMakeLists.txt
cmake .
make
ldd B | grep vtk
libvtkFiltering.so.5.4 = /usr/lib/libvtkFiltering.so.5.4 (0xb7448000)
libvtkCommon.so.5.4 = /usr/lib/libvtkCommon.so.5.4 (0xb6f81000)
libvtksys.so.5.4 = /usr/lib/libvtksys.so.5.4 (0xb6f4c000)
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561396:
On 2010/5/17 Mathieu Malaterre wrote: Since VTK is in pretty good shape I'd like to introduce the same hack I used in GDCM, to clean the VTKLibraryDepends.cmake file. I am thinking in running something like: sed -e 's...@general;/usr/lib[64]*/lib[a-z0-9]\+.so;@@' VTKLibraryDepends.cmake to remove any link to /usr/lib/lib* files. I have not found how to run this sed expression multiple times on the same line. This would solve bug #561396 I fully agree, but it won't help here, your regexp does not catch /usr/lib/jvm/default-java/jre/lib/*/libjawt.so You may try instead sed -e 's...@general;/usr/[^;]*\.so;@@g' VTKLibraryDepends.cmake Is this file needed at all on Debian systems? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561396:
On 2010/5/17 Mathieu Malaterre wrote: On Mon, May 17, 2010 at 9:43 PM, Denis Barbier bou...@gmail.com wrote: [...] You may try instead sed -e 's...@general;/usr/[^;]*\.so;@@g' VTKLibraryDepends.cmake Is this file needed at all on Debian systems? Yes ! See for instance use-case: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579642 This is a different issue; it is caused by overlinking, it would not hurt to have an empty VTKLibraryDepends.cmake cmake does not use pkgconfig and such but instead read this kind of file to track dependant library (which is really only usefull for static lib...). Information about needed libraries are already embedded within ELF shared objects. BTW I just tried and have been able to build gdcm package after echo /usr/lib/vtk-5.4/VTKLibraryDepends.cmake Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457075: Salomé packaging
Greetings, I am not a Salome user, but here are some (hopefully not too stupid) remarks about http://ftp-master.debian.org/new/salome_5.1.3-8.html * Binary packages are under the contrib/ section, AFAICT they can be moved into main * libsalome and libsalome-dev ships a lot of shared libraries, some of which with very generic names libe libHELLO.so or libLauncher.so. This is a potential source of conflict, can all these libraries be moved into a private directory like /usr/lib/salome/ ? * Libraries generated by swig have an underscore prepended, which means that they are not opened by the dynamic loader and should be moved into a private directory. * Ditto for binaries; and there is a concrete conflict, salome ships /usr/bin/display which means that many people will not be able to install this package since imagemagick is very popular. Can binaries be moved into a private directory, like /usr/lib/salome/bin/ ? I guess that runSalome and killSalome have to be put under /usr/bin/, I can't tell for other binaries. * Binary packages seem to contain lots of tests (/usr/bin/*[tT][eE][sS][tT]* or /usr/lib/lib*[tT][eE][sS][tT]*), can they be dropped? * Description of the salome binary package has to be updated, AFAICT there is no binary under /usr/bin/salome/ * salome-common is quite large, are files under /usr/share/salome/resources/med/ really needed? It looks like *.med files are already provided by salome-examples. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580816: [Debian-med-packaging] Bug#580816:
On 2010/5/9 Mathieu Malaterre wrote:
This is an interesting bug ! I am wondering if this should be part of
some sort of cmake-debian policy.
This issue can be found in all other cmake prepare package such as VTK:
$ cat /usr/lib/vtk-5.4/VTKBuildSettings.cmake
...
message(FATAL_ERROR
This VTK was built by CMake 2.8.0, but this is CMake
${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION}.
Please upgrade CMake to a more recent version.)
Should the vtk-dev or gdcm-dev package add a dependency including the
cmake version ?
No, you only have to drop calls to CMAKE_EXPORT_BUILD_SETTINGS from
these projects (and may also drop CMAKE_IMPORT_BUILD_SETTINGS from
callers), see comments in
/usr/share/cmake-2.8/Modules/CMakeExportBuildSettings.cmake
IMO there is no need to add a versioned dependency against cmake.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580527: [Debian-med-packaging] Bug#580527: insighttoolkit: FTBFS on many architectures, build-depend on unavailable default-jdk
On Thu, May 6, 2010 at 11:41 AM, Julien Cristau wrote: [...] - new insighttoolkit FTBFS on many architectures, see https://buildd.debian.org/status/package.php?p=insighttoolkit - new insighttoolkit build-depends on default-jdk = 1.6-34, while 3 architectures have 1.5-36, which means it's not going to get built there [...] Those build failures did already occur with 3.16.0-2, which is when Java wrapping has been introduced. A look at build logs seems to show that these failures are indeed related to Java wrapping: make[3]: *** [Wrapping/CSwig/VXLNumerics/wrap_vnl_matrix.xml] Error 1 make[3]: Leaving directory `/build/buildd-insighttoolkit_3.18.0-1-powerpc-WDzc0H/insighttoolkit-3.18.0/Build' make[2]: *** [Wrapping/CSwig/VXLNumerics/CMakeFiles/VXLNumericsJava.dir/all] Error 2 make[2]: Leaving directory `/build/buildd-insighttoolkit_3.18.0-1-powerpc-WDzc0H/insighttoolkit-3.18.0/Build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-insighttoolkit_3.18.0-1-powerpc-WDzc0H/insighttoolkit-3.18.0/Build' make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Can it please be disabled until ITK 3.18 enters testing? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558998: FTBFS [hppa] - undefined reference to `void_vnl_c_vector_inf_norm...'
Those link errors on hppa are caused by http://vxl.svn.sourceforge.net/viewvc/vxl?view=revrevision=11383 You may revert this patch, it is harmless on other architectures, and see how it goes. Moreover it is not clear at all whether this patch fixed anything on Linux, it may be related to HP-UX and not hppa. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558998: [Debian-med-packaging] Bug#558998: FTBFS [hppa] - undefined reference to `void_vnl_c_vector_inf_norm...'
2010/5/7 Mathieu Malaterre mathieu.malate...@gmail.com: On Fri, May 7, 2010 at 12:12 PM, Denis Barbier bou...@gmail.com wrote: Those link errors on hppa are caused by http://vxl.svn.sourceforge.net/viewvc/vxl?view=revrevision=11383 You may revert this patch, it is harmless on other architectures, and see how it goes. Moreover it is not clear at all whether this patch fixed anything on Linux, it may be related to HP-UX and not hppa. This is odd, the vxl package seems to build fine on hppa, both vxl 1.13 and 1.14 can be found: http://packages.qa.debian.org/v/vxl.html Technically the next upload of ITK will use a system installed VXL. But do you link some executables against libvxl when building your package? I guess not. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558998: [Debian-med-packaging] Bug#558998: FTBFS [hppa] - undefined reference to `void_vnl_c_vector_inf_norm...'
On 2010/5/7 Mathieu Malaterre wrote: On Fri, May 7, 2010 at 2:53 PM, Denis Barbier bou...@gmail.com wrote: 2010/5/7 Mathieu Malaterre mathieu.malate...@gmail.com: On Fri, May 7, 2010 at 12:12 PM, Denis Barbier bou...@gmail.com wrote: Those link errors on hppa are caused by http://vxl.svn.sourceforge.net/viewvc/vxl?view=revrevision=11383 You may revert this patch, it is harmless on other architectures, and see how it goes. Moreover it is not clear at all whether this patch fixed anything on Linux, it may be related to HP-UX and not hppa. This is odd, the vxl package seems to build fine on hppa, both vxl 1.13 and 1.14 can be found: http://packages.qa.debian.org/v/vxl.html Technically the next upload of ITK will use a system installed VXL. But do you link some executables against libvxl when building your package? I guess not. I guess I am missing -Wl,--no-undefined then. I'll update the package do add this flag. You may also set BUILD_TESTING=on. I just tried, it failed with [ 85%] Building CXX object core/vnl/tests/CMakeFiles/vnl_test_all.dir/test_sparse_matrix.o Linking CXX executable vnl_test_all /usr/bin/ld: cannot find -lvpl But building tests seemed to be pretty light, it may be worth fixing that to ensure that libvxl is usable. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580148: [s390, armel] gcj: libgcj.spec: No such file or directory
I do not have access to those boxes, but IMHO gcj does not find libgcj.spec because gcj from gcj-4.4-jdk_4.4.4-1 looks for /usr/lib/gcc/s390-linux-gnu/4.4.4/libgcj.spec whereas it ships /usr/lib/gcc/s390-linux-gnu/4.4/libgcj.spec, and the 4.4.4 - 4.4 symlink is provided by gcc-4.4-base_4.4.4-1 but not gcc-4.4-base_4.4.3-9. Thus gcj is broken when compiling with gcj-4.4-jdk_4.4.n and gcc-4.4-base_4.4.(n-1). The same problem occurs when compiling code wrapped by jni: on my x86 box $ ls -l /usr/lib/jvm/java-gcj-4.4/include total 4 lrwxrwxrwx 1 root root 43 6 mai 12:08 gcj - ../../../gcc/i486-linux-gnu/4.4/include/gcj lrwxrwxrwx 1 root root 48 6 mai 12:08 jawt.h - ../../../gcc/i486-linux-gnu/4.4.4/include/jawt.h lrwxrwxrwx 1 root root 47 6 mai 12:08 jni.h - ../../../gcc/i486-linux-gnu/4.4.4/include/jni.h drwxr-xr-x 2 root root 4096 6 mai 12:08 linux It would help if gcj (and friends) did search for files under triplet/4.4/ instead of triplet/4.4.n/, ditto for symlinks. Note that gcc-4.4-base_4.4.4-1 is now installed on armel, but not on s390. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548500: Help with slicer FTBFS on alpha - #548500
Hello, Slicer did not build on mips because of the same file, but for a different reason, cc1plus got killled. I know nothing about Slicer, so this may be a stupid idea, anyway here it is: AffineRegistration seems to be a plugin, can it be disabled at compile time (at least on alpha and mips, and surely also mipsel) to avoid these issues? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569436: blas: zgesvd seems to give incorrect results
Hi, For the record, thanks to the GCC compile farm, I determined that this bug has been fixed in gcc trunk by http://gcc.gnu.org/viewcvs?view=revisionrevision=145494 Unfortunately this is a merge from a branch (alias-improvements) which is not mirrored by git, so I had not been able to run git-bisect on it to find the atomic commit. And since this portion of code has been heavily modified, I doubt that it could be backported to gcc 4.4. I do not know what can be done now. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569436: Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
On 2010/3/3 Kumar Appaiah wrote: Dear Denis, On Wed, Mar 03, 2010 at 11:41:50AM +0100, Denis Barbier wrote: Hi, For the record, thanks to the GCC compile farm, I determined that this bug has been fixed in gcc trunk by http://gcc.gnu.org/viewcvs?view=revisionrevision=145494 Unfortunately this is a merge from a branch (alias-improvements) which is not mirrored by git, so I had not been able to run git-bisect on it to find the atomic commit. And since this portion of code has been heavily modified, I doubt that it could be backported to gcc 4.4. I do not know what can be done now. I think we can still file a bug report. Could you please test the attach test case, and let me know if it is reproducible? [...] Waow, you did it, congratulations. I can indeed reproduce this bug with your small testcase. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572189: libvtk5-dev: should depend on tcl8.5-dev
On 2010/3/2 A. Maitland Bottoms wrote: What about also depending upon tk8.5-dev? That seems the next logical step. Well, no, this bugreport does not explain why a dependency against tcl8.5-dev is needed. IMHO the dependency against tcl is due to VTK_WRAP_TCL being set to ON because this wrapping had been enabled when vtk is compiled. It should be enabled only when vtk-tcl is installed; for instance, vtk-tcl could provide a cmake snippet to enable it, and VTKConfig.cmake would load this snippet if present. Ditto for other wrappers, of course. Michal, can you please install tcl8.5-dev and see if you are then able to compile your application? And after installing vtk-tcl? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572139: python-vtk: no libvtkCommonPython
On 2010/3/1 Michal Suchanek wrote: Package: python-vtk Version: 5.4.2-5 Severity: normal Hello I am trying to build InstghtApplications against the Debian itk/vtk packages and the build cannot find libvtkCommonPython: [ 64%] Building CXX object ConnectVTKITK/CMakeFiles/_ConnectVTKITKPyt hon.dir/ConnectVTKITK_wrapPython.o Linking CXX shared module ../VolviewPlugIns/bin/_ConnectVTKITKPython. so /usr/bin/ld: cannot find -lvtkCommonPython There is libvtkCommonPythonD so I am wondering if some cmake voodoo failed to determine the correct library name or there is a symlink missing. vtkCommonPython and vtkCommonPythonD are different things, the former is located at /usr/lib/pyshared/python2.5/vtk/libvtkCommonPython.so Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572139: python-vtk: no libvtkCommonPython
On 2010/3/2 Michal Suchanek wrote: On 03/02/2010 04:09 PM, Denis Barbier wrote: On 2010/3/1 Michal Suchanek wrote: [...] [ 64%] Building CXX object ConnectVTKITK/CMakeFiles/_ConnectVTKITKPyt hon.dir/ConnectVTKITK_wrapPython.o Linking CXX shared module ../VolviewPlugIns/bin/_ConnectVTKITKPython. so /usr/bin/ld: cannot find -lvtkCommonPython There is libvtkCommonPythonD so I am wondering if some cmake voodoo failed to determine the correct library name or there is a symlink missing. vtkCommonPython and vtkCommonPythonD are different things, the former is located at /usr/lib/pyshared/python2.5/vtk/libvtkCommonPython.so Yes, I found the libraries in pyshared and linked them to /usr/lib and now the build works. I am still not sure if cmake should have figured out to include -L/usr/lib/pyshared/python2.5/vtk/ and if so why it did not or if these symlinks should have been installed. I do not remember exactly how these libvtk*Python.so libraries are generated upstream, I guess that they are generated along with non-wrapped libraries libvtk*.so, and are thus found by InsightApplications. But this is wrong, InsightApplications should be told how to look for libvtk*Python.so into Python modules path. There is some discussion about cmake and python at http://www.itk.org/Bug/view.php?id=2257 According to /usr/share/doc/python-support/README.gz, Python extensions under /usr/lib/pyshared are copied into /usr/lib/pymodules where they can be found by python, and indeed $ python -c 'import sys;print sys.path' lists '/usr/lib/pymodules/python2.5'. Maybe a solution would be to look for libvtkCommonPython.so in 'vtk' subdirs of all paths listed in sys.path? Anyway I am afraid that there is nothing to be done in python-vtk, maybe this bug can be closed? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569436: blas: zgesvd seems to give incorrect results
Hi, I played with the example provided by Kumar Appaiah, and narrowed the problem down to zdrot; after copying zdrot.f into the same directory as zgesvd_ex.f: $ gfortran -O2 -c zgesvd_ex.f $ gfortran -O2 -c zdrot.f $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack $ ./zgesvd_ex gives the expected result (with libblas3gf 1.2-4), but $ gfortran -O2 -ftree-vectorize -c zdrot.f $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack $ ./zgesvd_ex gives the wrong result. This looks like a bug in the gcc vectorizer, and it cannot be reproduced with gcc 4.5 from experimental. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571572: Bug#569436: blas: zgesvd seems to give incorrect results
On 2010/2/27 Kumar Appaiah wrote: (Also CCing #571572) Dear Denis, On Sat, Feb 27, 2010 at 05:44:45PM +0100, Denis Barbier wrote: Hi, I played with the example provided by Kumar Appaiah, and narrowed the problem down to zdrot; after copying zdrot.f into the same directory as zgesvd_ex.f: $ gfortran -O2 -c zgesvd_ex.f $ gfortran -O2 -c zdrot.f $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack $ ./zgesvd_ex gives the expected result (with libblas3gf 1.2-4), but $ gfortran -O2 -ftree-vectorize -c zdrot.f $ gfortran -o zgesvd_ex zgesvd_ex.o zdrot.o -llapack $ ./zgesvd_ex gives the wrong result. This looks like a bug in the gcc vectorizer, and it cannot be reproduced with gcc 4.5 from experimental. This was fantastic analysis. I actually would like to know how you zeroed in onto zdrot to find the problem. Hi, I used brute force ;) libblas3gf 1.2-4 is installed on my system, object files from libblas3gf 1.2-3 have been unpacked into dir1, half files are moved into dir2. then I compiled gfortran zgesvd_ex.o dir1/*.o -llapack and by dichotomy found which object file is causing trouble. I shall now try to play around with zdrot to see if I can create a test case which reproduces the bug, so that I can file a bug report with GCC. I am afraid that this is not easy, and anyway GCC folks will discard your bugreport since this bug has been fixed in 4.5. But I am very interested to know the exact reason, and if there is a way to prevent this bug by modifying source files. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457075: Salomé packaging
On 2010/2/11 Andre Espaze: [...] - it seems to lack the 'config.h' file in the libopencascade-* packages. Else do you know where that file could be? I fear that some components (like GEOM) really need it. [...] Hi André, This file has been dropped intentionnally, it does not make sense to ship a config.h file in a -dev package, you would have trouble if you build an application that uses autotools and ship its own config.h. See http://git.debian.org/?p=debian-science/packages/opencascade.git;a=blob;f=debian/patches/drop-config-h.patch Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568964: FTBFS: ./../bin/libvtkRenderingJava.so.5.2.1: undefined reference to `JAWT_GetAWT'
tags 568964 + pending thanks On 2010/2/9 Nobuhiro Iwamatsu wrote: Source: vtk Version: 5.4.2-4 Severity: important Tags: patch User: debian-...@superh.org Usertags: sh4 X-Debbugs-CC: debian-sup...@lists.debian.org Hi, I am now trying to run Debian on Renesas SH(sh4) CPU. http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4 vtk FTBFS on SH4. Because vtk does not support Renesas SH. Hi, Your patch has been applied, thanks. FYI FindJNI.cmake is normally shipped by cmake; we use a modified version in VTK because we had trouble on some arches in the past. It would be really nice if you could also file a bugreport against cmake to fix it so that VTK does not break again if we switch to cmake's FindJNI.cmake file. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567877: vtk: source package will not build
severity 567877 normal thanks 2010/1/31 Lee Azzarello l...@rockingtiger.com: Package: vtk Version: vtk-5.4.2 Severity: serious Justification: Policy 4.2 Fails to build from source. Error when linking to the TCL executable. make[3]: Entering directory `/home/lee/bsp/vtk-5.4.2/Build' [100%] Building CXX object Wrapping/Tcl/CMakeFiles/pvtk.dir/vtkParaTkAppInit.cxx.o Linking CXX executable ../../bin/pvtk ../../bin/libvtkIOTCL.so.5.4.2: undefined reference to `dirac_decoder_close' ../../bin/libvtkIOTCL.so.5.4.2: undefined reference to `dirac_encoder_close' ../../bin/libvtkIOTCL.so.5.4.2: undefined reference to `theora_info_clear' ../../bin/libvtkIOTCL.so.5.4.2: undefined reference to `dirac_parse' [...] Hi, I am downgrading severity; VTK obviously builds fine, see https://buildd.debian.org/build.cgi?pkg=vtk Either there is an error on your side, or some build dependencies must be versioned. Did you install ffmpeg related packages from another source? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563859: manpages: Remove obsolete Debian patches
Package: manpages Version: 3.23-1 Severity: minor Tags: patch Hi Joey, Several patches included in manpages_3.23-1.diff.gz are obsolete, here is a description of these changes: * man3/system.3 Contrary to the comment, the patch has been accepted upstream, and thus the added text appears twice. * man4/ttys.4 This file is useless, upstream added ttyS.4 in 2.72 * man2/FD_CLR.2 man2/FD_ISSET.2 man2/FD_SET.2 man2/FD_ZERO.2 These files are useless, upstream added them in man3 section in 2.33 * man2/adjtime.2 This file is useless, upstream added adjtime.3 in 2.35 * man2/socket.2 Your patch can be dropped, upstream added a slightly different version in 2.61 * man5/networks.5 Your patch can be dropped, upstream added a slightly different version in 3.09 The included patch is an excerpt of manpages_3.23-1.diff.gz, and must thus be reversed. Best regards, Denis manpages_3.23-1.diff Description: Binary data
Bug#562387: Bug#562775: Bug#562387: Bug#533193: [Debian-med-packaging] Bug#562387: gdcm: FTBFS: cmake error
On 2010/1/4 Mathieu Malaterre wrote: [...] As explained in a previous mail, it had accidentally been dropped from libvtk-java. Dominique uploaded 5.4.2-2 to fix this issue. I think this upload did not fix this particular issue: http://packages.debian.org/experimental/i386/libvtk-java/filelist Mathieu, I do not know why, but this page is wrong; if you download the i386 package, you will see that vtk.jar is present. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562387: Bug#562775: Bug#562387: Bug#533193: [Debian-med-packaging] Bug#562387: gdcm: FTBFS: cmake error
On 2010/1/3 Mathieu Malaterre wrote:
Could someone please let me know what is going on ?
http://packages.debian.org/search?suite=experimentalarch=anymode=pathsearchon=contentskeywords=vtk.jar
Where is vtk.jar ?
Hi Mathieu,
As explained in a previous mail, it had accidentally been dropped from
libvtk-java. Dominique uploaded 5.4.2-2 to fix this issue.
Dominique, I am not sure I understand your patch. Until I see a
correct libvtk-java package I do not think I need to patch anything in
GDCM.
Dominique is right, when vtk.jar is found, you do no more pass into the
else(EXISTS ${VTK_JAVA_JAR})
branch and libraries in /usr/lib/jni are not found.
But maybe it would be better to set a variable in VTKConfig.cmake to
let VTK tell where it puts JNI libraries?
There are other problems, you asked to enable more VTK_USE_* features,
and as a consequence more dependencies have been defined in
/usr/lib/vtk-5.4/VTKLibraryDepends.cmake, libvtk5-dev must depend on
all the .so libraries listed there (except for the wrappings).
Hopefully this is now fixed in the git repository.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562387: Bug#533193: [Debian-med-packaging] Bug#562387: gdcm: FTBFS: cmake error
On 2010/1/2 Dominique Belhachemi wrote: Hi Mathieu, You are right. Using /usr/share/java/vtk/vtk.jar solves the problem. BTW, I was playing with vtk-5.4 in experimental and tried to compile gdcm. There is another java related problem. [...] Be warned that libvtk-java from experimental is also screwed up, vtk.jar is absent from this package. This is due to commit 6f4a938, it should have been reverted in b3e7451. It has now been fixed in git. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562387: Bug#533193: [Debian-med-packaging] Bug#562387: gdcm: FTBFS: cmake error
On 2009/12/27 Mathieu Malaterre wrote: [...] Does this help ? Even if the path is wrong in VTKConfig.cmake, GDCM can cope with that. In the end /usr/share/java/vtk/vtk.jar should be the vtk jar file. [...] I was confused by your message, /usr/share/java/vtk.jar is the expected location of the jar file. and this is what your commit does, thanks! Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562387: Bug#533193: [Debian-med-packaging] Bug#562387: gdcm: FTBFS: cmake error
tags 562387 + pending thanks On 2009/12/24 Mathieu Malaterre wrote: Package libvtk-java is *again* totally busted. This is total junk, and I am getting fed up dealing with all bug in libvtk-java. I am not adding a second patch in GDCM just for the debian system. My bad, I was somehow abused by the error message about VTK_JAVA_JAR and my comment in bug #533193 was wrong. This value is ignored when installing files and generating VTKConfig.cmake, and moreover vtk.jar is installed at the wrong place because of this upstream bug: http://www.vtk.org/Bug/view.php?id=8750 I committed a workaround a couple of weeks ago, vtk.jar is installed into debian/tmp/usr/share/java/vtk/vtk.jar and then copied into debian/libvtk-java/usr/share/java/vtk.jar . This is really ugly, I would love to see a better way. I am pretty sure that this bug has been introduced when trying to play with versioned jars in order to be able to install both VTK 5.2 and 5.4 Java wrappers, but this seems to be very fragile, any advice would surely be helpful. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552352: libvtk5.2: Please turn VTK_X3D_USE_JAVA option ON
tags 552352 +wontfix
thanks
On 2009/12/14 Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
reopen 552352
Bug #552352 {Done: bott...@debian.org (A. Maitland Bottoms)} [libvtk5.2]
libvtk5.2: Please turn VTK_X3D_USE_JAVA option ON
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to use 'found' to remove fixed versions.
Mathieu, this feature introduced serious bugs (558714, 559629, 558675).
The only solution is to wait for 5.4, which dropped this option by
reimplementing this feature in C++; this bug will then become
meaningless.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558716: FTBFS: The return type is incompatible with vtkMultiProcessController.CreateSubController(vtkProcessGroup)
On 2009/11/30 Cyril Brulebois wrote:
Package: vtk
Version: 5.2.1-13
Severity: serious
Justification: FTBFS
Hi,
your package FTBFS on kfreebsd-* with this error:
| 65. ERROR in
/build/buildd-vtk_5.2.1-13-kfreebsd-i386-uedLVA/vtk-5.2.1/Build/java/vtk/vtkMPIController.java
(at line 47)
| public vtkMPIController CreateSubController(vtkProcessGroup id0) {
|
| The return type is incompatible with
vtkMultiProcessController.CreateSubController(vtkProcessGroup)
[...]
Hi Cyril,
This FTBFS bug can be reproduced on any architecture when compiling
with gcj. The error just above is caused by covariant return types,
which have been introduced in Java 5. A fix has been committed.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558675: libvtk5.2, version 5.2.1-13 problem - libjvm.so not found
severity 558675 grave
thanks
On 2009/11/29 MišoLietavec wrote:
Package: libvtk5.2
Version: 5.2.1-13
Bumping severity, python-vtk is unusable :
$ python
Python 2.5.4 (r254:67916, Nov 19 2009, 19:46:21)
[GCC 4.3.4] on linux2
Type help, copyright, credits or license for more information.
import vtk
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/pymodules/python2.5/vtk/__init__.py, line 76, in module
__helper.refine_import_err('hybrid', 'vtkHybridPython', exc)
File /usr/lib/pymodules/python2.5/vtk/__helper.py, line 32, in
refine_import_err
raise LinkError, str(exc)
vtk.__helper.LinkError: libjvm.so: cannot open shared object file: No
such file or directory
(Package python-vtk, vers. 5.2.1-13 also affected.)
The library /usr/lib/libvtkHybrid.so.5.2.1 (and others) require
libjvm.so, which is not found.
[...]
Most certainly introduced when fixing #552352, it should IMHO be reverted.
Unfortunately there will be similar problems with VTK 5.4 due to
upstream changes in git 29292641:
ENH: Adding vtkJavaProgrammableFilter
The filter allows a user to write a VTK algorithm in Java and use
it from C++.
It uses vtkJVMManager to manage an instance of the Java VM and
to call functions through the JNI layer.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
