Bug#929967: #929967 CMake: use TBBConfig instead of FindTBB
tags 929967 patch
thanks
Hello,
Here is a patch to fix this issue. It replaces FindTBB.cmake by
TBBConfig.cmake.
diff --git a/debian/libtbb-dev.install b/debian/libtbb-dev.install
index 8f44bd13..6deacb46 100755
--- a/debian/libtbb-dev.install
+++ b/debian/libtbb-dev.install
@@ -3,4 +3,4 @@ include/tbb usr/include
build/linux_*_release/lib*.so usr/lib/${DEB_HOST_MULTIARCH}
debian/tbb.pc usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
cmake/*usr/share/cmake/Modules
-debian/cmake/* usr/share/cmake/Modules
+build/linux_*_release/TBBConfig*.cmake usr/lib/${DEB_HOST_MULTIARCH}/cmake/TBB
diff --git a/debian/rules b/debian/rules
index 872d4207..966be016 100755
--- a/debian/rules
+++ b/debian/rules
@@ -58,6 +58,13 @@ override_dh_auto_build-arch:
-e "s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g" \
debian/tbb.pc.in > debian/tbb.pc
dh_auto_build -- $(BUILD_FLAGS)
+ # Build cmake config files
+ cmake -DINSTALL_DIR=$(wildcard build/linux_*_release) \
+ -DSYSTEM_NAME=Linux \
+ -DTBB_VERSION_FILE=include/tbb/tbb_stddef.h \
+ -DLIB_REL_PATH="../../" \
+ -DINC_REL_PATH="../../../../include" \
+ -P cmake/tbb_config_installer.cmake
override_dh_auto_build-indep:
$(MAKE) doxygen
Bug#902513: openturns: FTBFS in buster/sid (nlopt.hpp: No such file or directory)
fixed 902513 openturns/1.11-2 stop On 2018-06-27 14:50 GMT+02:00 Santiago Vila wrote: > Package: src:openturns > Version: 1.10-5 > Severity: serious > Tags: ftbfs [...] > /<>/lib/src/Base/Optim/NLopt.cxx:27:11: fatal error: nlopt.hpp: > No such file or directory > # include >^~~ > compilation terminated. > lib/src/CMakeFiles/OT.dir/build.make:3302: recipe for target > 'lib/src/CMakeFiles/OT.dir/Base/Optim/NLopt.cxx.o' failed > make[4]: *** [lib/src/CMakeFiles/OT.dir/Base/Optim/NLopt.cxx.o] Error 1 Hello, This bug is already fixed in experimental, but I have to fix FTBFS on several architectures before uploading to unstable. Denis
Bug#882147: transition: openturns
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to upload openturns 1.9 from experimental into unstable. This package will also fix #881706. There are no reverse dependencies except science metapackages. Denis Ben file: title = "openturns"; is_affected = .depends ~ "libopenturns0.8" | .depends ~ "libopenturns0.10"; is_good = .depends ~ "libopenturns0.10"; is_bad = .depends ~ "libopenturns0.8";
Bug#790327: openturns: FTBFS on mipsel "package requires more than 1GB RAM; do not build on mips/mipsel. Stop."
tags 790327 wontfix severity 790327 wishlist thanks On 2015-08-03 10:09 GMT+02:00 Gustavo Prado Alkmim wrote: > Hi. > > Please, can you take a look on the patch? It is building ok on mips now. [...] >>> I enabled the build on mipsel. I made a test on my ci20 board and it >>> built fine. >>> >>> Tooked 46 hours, ~6GB of space, 1 GB of RAM and ~500GB of swap memory [...] Hi, Sorry for the delay, I took a long break. I won't apply your patch, 46 hours to build this package is unreasonable, this means I won't be able to debug any problem. Denis
Bug#775738: ITP: hmat-oss -- hierarchical matrix library
Package: wnpp Severity: wishlist Owner: "D. Barbier" * Package name: hmat-oss (libhmat-oss-dev, libhmat-oss1, libhmat-oss1-dbg) * Version : 1.0.4 * Upstream Author : Airbus Group SAS * URL : https://github.com/jeromerobert/hmat-oss/ * License : GPL2+ * Programming Lang: C, C++ * Description : hierarchical matrix library Hierarchical matrices are sparse approximations of dense matrices, based on low rank approximations. This library implements basic algebraic operations on H-matrices, as well as LU, LLt and LDLt factorizations. This package is needed by upcoming OpenTURNS 1.5 release, there is a license exception which allows using it in this package. It will be maintained within Debian science. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770718: unblock: openturns/1.3-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello I'd like to upload openturns 1.3-3 to fix #769260. As it build-depends on r-base-core, my understanding is that it has to be uploaded to testing-proposed-updates, right? Previous GCC versions were giving slightly different results on *-i386 architectures for a single test, and I had to change output to let it pass. According to #769260, a newer GCC version had been installed on i386 which fixes this issue, so I will joyfully drop this patch. I have verified on fischer (kfreebsd-i386, in a testing schroot) that this patch must be dropped there too, and am currently running the same check on exodar (hurd-i386, but in a sid chroot since there is no testing one). Here is the debdiff between 1.3-2 and 1.3-3, okay to upload? diff -Nru openturns-1.3/debian/changelog openturns-1.3/debian/changelog --- openturns-1.3/debian/changelog 2014-04-19 20:42:22.0 +0100 +++ openturns-1.3/debian/changelog 2014-11-23 14:43:57.0 + @@ -1,3 +1,10 @@ +openturns (1.3-3) testing-proposed-updates; urgency=medium + + * debian/patches/modify-tests-O0-i386.patch: Drop patch, it is +no more needed with recent GCC. Closes: #769260 + + -- Denis Barbier Sun, 23 Nov 2014 11:38:35 + + openturns (1.3-2) unstable; urgency=medium * tests-disable-broken-R.patch: New patch, to disable 3 diff -Nru openturns-1.3/debian/patches/modify-tests-O0-i386.patch openturns-1.3/debian/patches/modify-tests-O0-i386.patch --- openturns-1.3/debian/patches/modify-tests-O0-i386.patch 2014-03-06 21:16:38.0 + +++ openturns-1.3/debian/patches/modify-tests-O0-i386.patch 1970-01-01 01:00:00.0 +0100 @@ -1,37 +0,0 @@ -Description: Modify output of TrapezoidalFactory tests. - There is a bug in GCC 4.8 on *-i386 architectures, several tests - hang. In order to avoid these problems, algocobyla.c is compiled - without optimization; but those tests must be modified. - This patch is applied only on *-i386 architectures. -Author: Denis Barbier -Origin: Debian -Forwarded: no -Last-Update: 2013-07-02 - openturns-1.1.orig/lib/test/t_TrapezoidalFactory_std.expout -+++ openturns-1.1/lib/test/t_TrapezoidalFactory_std.expout -@@ -1,8 +1,8 @@ - Distribution =class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 --Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 -+Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 - Default distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 b=-1 c=1 d=2 h=0.33 - Distribution from parameters=class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 - Trapezoidal =class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 --Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 -+Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 - Default trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 b=-1 c=1 d=2 h=0.33 - Trapezoidal from parameters=class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 openturns-1.1.orig/python/test/t_TrapezoidalFactory_std.expout -+++ openturns-1.1/python/test/t_TrapezoidalFactory_std.expout -@@ -1,8 +1,8 @@ - distribution= class=Trapezoidal name=Trapezoidal dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 --Estimated distribution= class=Trapezoidal name=Trapezoidal dimension=1 a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 -+Estimated distribution= class=Trapezoidal name=Trapezoidal dimension=1 a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 - Default distribution= Trapezoidal(a = -2, b = -1, c = 1, d = 2) - Distribution from parameters= Trapezoidal(a = 1, b = 2.3, c = 4.5, d = 5) - Trapezoidal = Trapezoidal(a = 1, b = 2.3, c = 4.5, d = 5) --Estimated trapezoidal= Trapezoidal(a = 1.006, b = 2.275, c = 4.545, d = 4.99) -+Estimated trapezoidal= Trapezoidal(a = 1.005, b = 2.279, c = 4.545, d = 4.99) - Default trapezoidal= Trapezoidal(a = -2, b = -1, c = 1, d = 2) - Trapezoidal from parameters= Trapezoidal(a = 1, b = 2.3, c = 4.5, d = 5) - diff -Nru openturns-1.3/debian/rules openturns-1.3/debian/rules --- openturns-1.3/debian/rules 2014-03-06 21:16:38.0 + +++ openturns-1.3/debian/rules 2014-11-23 14:43:57.0 + @@ -53,18 +53,6 @@ -mkdir -p $(debRlib) R CMD INSTALL --library=$(debRlib) utils/rot_1.4.5.tar.gz -ifneq (,$(findstring $(shell dpkg-architecture -qDEB_HOST_ARCH), i386 kfreebsd-i386 hurd-i386)) -override_dh_quilt_patch: - dh_quilt_patch - test -e debian/patches/modify-tests-O0-i386.applied || patch -p1 < debian/patches/modify-tests-O0-i386.patch - touch debian/patches/modify-tests-O0-i386.applied - -override_dh_quilt_unpatch: - test ! -e debian/patches/m
Bug#769260: openturns: FTBFS in jessie/i386: Tests failures
tags 769260 pending thanks 2014-11-14 13:27 GMT+00:00 Cyril Brulebois : [...] >> > The following tests FAILED: >> > 234 - cppcheck_TrapezoidalFactory_std (Failed) >> > Errors while running CTest >> > make[2]: *** [test] Error 8 >> > Makefile:140: recipe for target 'test' failed > > Reproduced locally in a jessie i386 chroot (amd64 is passing the tests > just fine). Relevant lines seem to be: > | 273/359 Test #234: cppcheck_TrapezoidalFactory_std > ..***Failed3.77 sec > | --- > /home/kibi/hack/bsp/i386/openturns-1.3/lib/test/t_TrapezoidalFactory_std.expout > 2014-11-14 12:06:07.425831849 + > | +++ > /home/kibi/hack/bsp/i386/openturns-1.3/obj-i586-linux-gnu/lib/test/t_TrapezoidalFactory_std.out > 2014-11-14 12:24:12.176560743 + > | @@ -1,8 +1,8 @@ > | Distribution =class=Trapezoidal name=Trapezoidal dimension=1 a=1 > b=2.3 c=4.5 d=5 h=0.322581 > | -Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 > a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 > | +Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 > a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 > | Default distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 > b=-1 c=1 d=2 h=0.33 > | Distribution from parameters=class=Trapezoidal name=Trapezoidal > dimension=1 a=1 b=2.3 c=4.5 d=5 h=0.322581 > | Trapezoidal =class=Trapezoidal name=Trapezoidal dimension=1 a=1 > b=2.3 c=4.5 d=5 h=0.322581 > | -Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 > a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 > | +Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 > a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 > | Default trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 > b=-1 c=1 d=2 h=0.33 > | Trapezoidal from parameters=class=Trapezoidal name=Trapezoidal dimension=1 > a=1 b=2.3 c=4.5 d=5 h=0.322581 > > Not quite the expected results but almost… Right, this test used to produce different results on x86, see http://anonscm.debian.org/cgit/debian-science/packages/openturns.git/tree/debian/patches/modify-tests-O0-i386.patch?id=9a477a3 It looks like there is a newer GCC version which fixed this issue, I will drop this 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#761128: transition: oce
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Hello, I would like to upload oce 0.16 into unstable, it is currently in experimental. This source package provides several development libraries, their soname version have been bumped. The following packages build-depend on oce and have been successfully rebuilt without source changes: gmsh 2.8.5+dfsg-1.1 freecad 0.14.3702+dfsg-2 netgen4.9.13.dfsg-8 Ben file: title = "oce"; is_affected = .build-depends ~ /liboce-.*-dev/; is_good = .depends ~ /liboce-foundation9/; is_bad = .depends ~ /liboce-foundation8/; 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#753594: openturns FTBFS on mips/mipsel
On 2014-07-03 14:13 GMT+02:00 Dejan Latinovic wrote: > > Package: openturns > Version: 1.3-2 > Tags: sid patch > Severity: important > Justification: FTBFS > User: debian-mips-dev-disc...@lists.alioth.debian.org > Usertags: mips-patch > > > > Package openturns FTBFS on mips/mipsel with an error: > >> debian/rules:48: *** This package requires more than 1GB RAM; do not build >> on mips/mipsel. Stop. > > > As I see, all mips/mipsel debian buildd machines beside rem > have 1G RAM or above. > > > I tested it on a few local boards, > and on most of them build finished successfully. > On some boards build failed, > but I believe that the reason for that is a parallel build. > After I disabled a parallel build for mips/mipsel, > openturns was built successfully on all boards that I have tested it on. > > > > A patch that disables a parallel build for mips/mipsel is attached. > > Could you please consider including this patch? Hello, Unfortunately I am going to revert your patch in the next upload; 1.4-2 FTBFS on mipsel, and mips autobuilders seems to be reluctant to build this package. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748101: libstarpu-dev depends on opencl-headers
Package: libstarpu-dev Version: 1.1.1+dfsg-2 Severity: important Hello, libstarpu-dev is unusable without opencl-headers, and should thus depend on it: $ echo '#include ' | gcc -c $(pkg-config --cflags starpu-1.1) -x c - In file included from /usr/include/starpu/1.1/starpu.h:41:0, from :1: /usr/include/starpu/1.1/starpu_opencl.h:26:19: fatal error: CL/cl.h: No such file or directory #include ^ compilation terminated. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743073: openturns: FTBFS: Tests failures
On 2014-03-30 19:08 GMT+02:00 David Suárez wrote: > Source: openturns > Version: 1.3-1 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20140329 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): [...] >> The following tests FAILED: >> 239 - cppcheck_TruncatedNormalFactory_std (Failed) >> 360 - cppcheck_HypothesisTest_std (Failed) >> 361 - cppcheck_LinearModelTest_std (Failed) >> make[2]: *** [test] Error 8 Thanks David, I can reproduce these failures on my sid box. These 3 tests call R; after downgrading r-base, r-base-core and r-recommended to 3.0.3-1, these failures disappear. I am still investigating. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731491: transition: oce
On 2014-02-20 16:41 GMT+01:00 D. Barbier wrote: > On 2014-02-20 16:33 GMT+01:00 Julien Cristau wrote: >> On Thu, Feb 20, 2014 at 11:49:43 +0100, Julien Cristau wrote: >> >>> On Wed, Feb 19, 2014 at 11:51:37 +0100, D. Barbier wrote: >>> >>> > Uploaded, thanks. >>> > >>> Scheduled binNMUs for freecad and netgen. I'll give gmsh 2.8.4 a couple >>> days to see if it gets in to testing first. >> >> freecad FTBFS: >>> make[3]: *** No rule to make target `/usr/lib/libfreeimage.so', needed by >>> `lib/Driver.so'. Stop. >> >> Somebody should file a bug. > > I will take care of that, it looks like this bug comes from oce. Hello, There was indeed a bug in oce 0.15-2, my pbuilder did not catch it because oce build dependencies were installed there. This is fixed in oce 0.15-3, which is now built on all architectures. Can you please reschedule freecad builds? Thanks and sorry for the trouble. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731491: transition: oce
On 2014-02-20 16:33 GMT+01:00 Julien Cristau wrote: > On Thu, Feb 20, 2014 at 11:49:43 +0100, Julien Cristau wrote: > >> On Wed, Feb 19, 2014 at 11:51:37 +0100, D. Barbier wrote: >> >> > Uploaded, thanks. >> > >> Scheduled binNMUs for freecad and netgen. I'll give gmsh 2.8.4 a couple >> days to see if it gets in to testing first. > > freecad FTBFS: >> make[3]: *** No rule to make target `/usr/lib/libfreeimage.so', needed by >> `lib/Driver.so'. Stop. > > Somebody should file a bug. I will take care of that, it looks like this bug comes from oce. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731491: transition: oce
On 2014-02-18 20:03 GMT+01:00 Julien Cristau wrote: > On Tue, Feb 18, 2014 at 12:54:45 +0100, D. Barbier wrote: [...] >> oce 0.15-1 is now in experimental, and soname has been bumped, thus >> is_good becomes >> is_good = .depends ~ /liboce-foundation8/; >> >> This version fixes long standing issues with OpenCASCADE licensing, as >> the new version is now LGPL 2.1 (with a runtime exception). >> > yay. > >> Current unstable versions of its rdepends (gmsh, freecad, netgen) do >> not need source changes, and oce binaries have been built on all >> architectures. >> > Feel free to upload to sid. I'll update the tracker in a bit. Uploaded, 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#731491: transition: oce
On 2013-12-05 23:07 GMT+01:00 D. Barbier wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Hello, > > I would like to upload oce 0.13 into unstable, it is in experimental > for several weeks. oce 0.13-4 is not yet built on armel and mipsel, > but it should build just fine. This source package provides several > development libraries, their soname version have been bumped. > > The following packages build-depend on oce and have been successfully > rebuilt without source changes: > gmsh 2.8.3+dfsg-4 > freecad 0.13.2800-dfsg-1 > netgen4.9.13.dfsg-7 > On the other hand, elmerfem FTBFS, but it is not in testing. > > Ben file: > > title = "oce"; > is_affected = .build-depends ~ /liboce-.*-dev/; > is_good = .depends ~ /liboce-foundation7/; > is_bad = .depends ~ /liboce-foundation6/; Hello, oce 0.15-1 is now in experimental, and soname has been bumped, thus is_good becomes is_good = .depends ~ /liboce-foundation8/; This version fixes long standing issues with OpenCASCADE licensing, as the new version is now LGPL 2.1 (with a runtime exception). Current unstable versions of its rdepends (gmsh, freecad, netgen) do not need source changes, and oce binaries have been built on all architectures. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736249: [oce] please upgrade to 0.14.1
retitle 736249 [oce] please upgrade to 0.15 as soon as it is released thanks On 2014/1/21 trophime wrote: > Package: oce > Version: 0.14.1 > Severity: wishlist > > Please upgrade to 0.14.1 > It will solve the licenses issues (#680738) > as OpenCasCade moved to LGPL v2.1. Hello Christophe, OCE 0.14.1 is based on OCCT 6.6.0 and is thus still licensed under OCCT Public License. OCE 0.15 will be LGPL, but is not yet released. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731491: transition: oce
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Hello, I would like to upload oce 0.13 into unstable, it is in experimental for several weeks. oce 0.13-4 is not yet built on armel and mipsel, but it should build just fine. This source package provides several development libraries, their soname version have been bumped. The following packages build-depend on oce and have been successfully rebuilt without source changes: gmsh 2.8.3+dfsg-4 freecad 0.13.2800-dfsg-1 netgen4.9.13.dfsg-7 On the other hand, elmerfem FTBFS, but it is not in testing. Ben file: title = "oce"; is_affected = .build-depends ~ /liboce-.*-dev/; is_good = .depends ~ /liboce-foundation7/; is_bad = .depends ~ /liboce-foundation6/; 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#725931: random order in SGML tags
On 2013/10/19 David Prévot wrote: [...] > Please find attached a minimal test case that could make it into t/data-20: > > po4a-gettextize -f sgml -o force -m debiandoc.sgml -p debiandoc.po > > It currently gives random results. Hello David, Thanks, your example is very useful. I made some changes in po4a in order to have attributes in the same order as in input file, but then realized that SGMLS.pm itself returns attributes in random order, so there is no hope here :-( Please have a look at http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks I suggest to run po4a with PERL_PERTURB_KEYS=0 PERL_HASH_SEED=0 it should give the same output as before. At the moment I have no better idea. I could sort attributes to avoid this randomization, but I would really like to preserve attributes order. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725931: random order in SGML tags
On 2013/10/10 David Prévot wrote: > Package: po4a > Version: 0.45-1 > Severity: normal > Control: block 725586 by -1 > > Hi, > > It seems like, with the new Perl version, the order of items inside a > tag is not respected anymore: running “make update-po” inside the > debian-faq source triggers dozens of changes like the following: > > msgid "" > -"http://lists.debian.org/\"; name=\"Debian Mailing Lists > Archives\">," > +" id=\"http://lists.debian.org/\";>," > > running “make update-po” again and again continue to flush the order. > > I’ve been able to reproduce the issue with po4a 0.42-1, while the issue > was not present in Wheezy, that’s why I suspect a behaviour change in > Perl. Hello David, This is strange, never heard of this problem before. Did you try to run po4a tests? ./Build 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#718675: po4a: Uninformative error message when '<' is left alone in a HTML file
tags 718675 pending thanks On 2013/8/4 Martin Quinson wrote: > Hello there, > > Yes, that's true, I'm using po4a again for my own use. I'm very pleased to see > that you guys keep up with the good work and that po4a is still alive. This > may > even motivate me to come back and fix a few bugs with you guys. > > Meanwhile, I did a typo in the HTML file I wanted to translate and typed "<" > alone, at the end of a line. The error message I got was: > > po4a::xml: Unknown tag type: < > > Not quite informative, actually. So I wrote the attached patch to make it more > informative, and here we are. > > Thanks for commiting this very simple patch in the next release of po4a, and > please please, keep up the good work! Hello Martin, Glad to hear from you. I applied your patch in the SVN repository, 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#710695: po4a-gettextize: wrong timezone in POT-Creation-Date
On 2013/6/3 Jakub Wilk wrote: > Sorry, I just realized there's one more bug, this time not related to DST. > If $diff is negative and not a multiply of 60 (think of TZ=America/Caracas), > then this: > >> my $h = floor($diff / 60); >> my $m = $diff%60; > > > is wrong. Thanks again Jakub, now fixed in our SVN 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#719528: dh-python: Typo in plugin_cmake.py make pybuild unusable with cmake
Package: dh-python Version: 1.20130807-1 Severity: normal Tags: patch Hello, Thanks a lot for writing pybuild, it will be very useful for one of my packages in order to provide both python2 and python3 bindings. Unfortunately, build failed with: dh binary --buildsystem=pybuild --with python2,python3 --with quilt --parallel dh_auto_install -O--buildsystem=pybuild -O--parallel I: pybuild pybuild:85: detected build system: BuildSystem(cmake) (certainty: 99%) E: pybuild pybuild:243: install: plugin cmake failed with: 'dest_dir' This is due to a typo in dhpython/build/plugin_cmake.py, see attached patch. Denis plugin_cmake.patch Description: Binary data
Bug#717829: RM: openturns [mips mipsel] -- ROM; ANAIS; requires > 1GB RAM to build
2013/7/25 Denis Barbier wrote: > 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. Hello, Those missing binaries on mips and mipsel prevent openturns' migration into 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#710778: transition: oce
Le 10 juil. 2013 00:33, "Julien Cristau" a écrit : [...] > Please go ahead, and let us know when oce is built everywhere so we can > schedule binNMUs. Hello, oce is now built everywhere, but Anton told in this bugreport that he is planning source uploads, so binNMUs are not needed. Thanks Denis
Bug#714915: openturns: FTBFS on any-i386: small difference in cppcheck_TrapezoidalFactory_std output
On 2013/7/4 Samuel Thibault wrote: > Package: openturns > Version: 1.1-6 > Severity: serious > Justification: FTBFS > > Hello, > > openturns currently FTBFS on any-i386, due to a small output difference: > > --- /«PKGBUILDDIR»/lib/test/t_TrapezoidalFactory_std.expout 2013-01-03 > 14:01:36.0 + > +++ /«PKGBUILDDIR»/obj-i486-linux-gnu/lib/test/t_TrapezoidalFactory_std.out > 2013-07-03 22:54:04.041954105 + > @@ -1,8 +1,8 @@ > Distribution =class=Trapezoidal name=Trapezoidal dimension=1 a=1 > b=2.3 c=4.5 d=5 h=0.322581 > -Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 > a=1.006 b=2.275 c=4.545 d=4.99 h=0.3198 > +Estimated distribution=class=Trapezoidal name=Trapezoidal dimension=1 > a=1.005 b=2.279 c=4.545 d=4.99 h=0.32 > Default distribution=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 > b=-1 c=1 d=2 h=0.33 > Distribution from parameters=class=Trapezoidal name=Trapezoidal dimension=1 > a=1 b=2.3 c=4.5 d=5 h=0.322581 > Trapezoidal =class=Trapezoidal name=Trapezoidal dimension=1 a=1 > b=2.3 c=4.5 d=5 h=0.322581 > -Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=1.006 > b=2.275 c=4.545 d=4.99 h=0.3198 > +Estimated trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=1.005 > b=2.279 c=4.545 d=4.99 h=0.32 > Default trapezoidal=class=Trapezoidal name=Trapezoidal dimension=1 a=-2 b=-1 > c=1 d=2 h=0.33 > Trapezoidal from parameters=class=Trapezoidal name=Trapezoidal dimension=1 > a=1 b=2.3 c=4.5 d=5 h=0.322581 > > I've also seen that in sphinxbase, where this is due to libc 2.17 which > has small libmath fixes compared to libc 2.13. Hello Samuel, I disabled optimization on *-i386 arches because of #714411. I checked on fischer.d.o, but I ran two builds, one with -O0 and the other one with -fno-cse-follow-jumps -fno-caller-saves -fno-guess-branch-probability, and unfortunately it is likely that I switched results, only the latter works. I could adjust test output, but I now wonder whether this is the best choice. Maybe you have some ideas why those -f flags are needed on *-i386? With GCC < 4.8, only -fno-cse-follow-jump was needed, but now we need two more flags. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714804: po4a: [xml] disseminated comments of a source paragraph are stacked at the top of the translated paragraph
On 2013/7/3 Pierre Mazière wrote: > Package: po4a > Version: 0.42-2 > Severity: important > Tags: upstream > > Hi, > > When using po4a Xhtml module on a file that includes Internet Explorer > conditional comments, I noticed that, when these comments are > disseminated in what is considerated as a paragraph by the xml module, > po4a groups all of these comments at the top of the translated > paragraph. > > As an example the following source: > > > This is displayed by any browsers. > > This is displayed by any non IE browsers > > > > submitted to po4a without translation files, is translated as: > > > > > This is displayed by any browsers. > This is displayed by any non IE browsers > > > which breaks the "benefit" of conditional comments. > > It should instead output the exact same content as the source. > > The reason why it is done this way can be found in the file > /usr/share/perl5/Locale/Po4a/Xml.pm > The treat_content function collects all comments embedded in a paragraph > separately from the non-comment content. Afterward, the translate_paragraph > function first push the comments, then the non-comment content. > > Comments and non-comment content should be collected in the same array > to avoid the inapropriate reorganisation of the original document. > > Thanks for trying to fix this issue Hello, It would not work, text within those conditional comments cannot be translated since it is rightfully considered as a comment. Comments are extracted because they are useful to give hints to translators. If they are not comments but provide some real contents, po4a will not know what to do. I won't try to fix it, sorry. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714411: openturns: FTBFS on {hurd,kfreebsd}-i386: tests hang
tags 714411 +pending thanks 2013/6/29 D. Barbier : > On 2013/6/29 Aaron M. Ucko wrote: >> Source: openturns >> Version: 1.1-4 >> Severity: serious >> Justification: fails to build from source (but built successfully in the >> past) >> >> The latest openturns builds for hurd-i386 and kfreebsd-i386 failed due >> to test suite timeouts, hitting cppcheck_TrapezoidalFactory_std on >> kFreeBSD and cppcheck_WhittleFactory_std on the Hurd (admittedly not a >> release architecture). Oddly, the essentially identical 1.1-3 release >> seems to have had no such trouble; perhaps a change to some build >> dependency triggered a latent bug. >> >> Could you please take a look? > > Hello, > > This looks similar to #666782, t_TrapezoidalFactory_std hangs in algocobyla.c. > Still investigating. Tests do no more hang when compiling algocobyla.c with -fno-caller-saves. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714411: openturns: FTBFS on {hurd,kfreebsd}-i386: tests hang
On 2013/6/29 Aaron M. Ucko wrote: > Source: openturns > Version: 1.1-4 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > The latest openturns builds for hurd-i386 and kfreebsd-i386 failed due > to test suite timeouts, hitting cppcheck_TrapezoidalFactory_std on > kFreeBSD and cppcheck_WhittleFactory_std on the Hurd (admittedly not a > release architecture). Oddly, the essentially identical 1.1-3 release > seems to have had no such trouble; perhaps a change to some build > dependency triggered a latent bug. > > Could you please take a look? Hello, This looks similar to #666782, t_TrapezoidalFactory_std hangs in algocobyla.c. Still investigating. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710782: transition: openturns
On 2013/6/2 D. Barbier wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hello, > > openturns 1.1 has been uploaded into experimental, and introduces a > soname bump. Version 1.1-3 uploaded few days ago should build fine > everywhere if buildds have enough RAM, all issues found in earlier > versions should now be fixed. > Thus I would like to upload this version into unstable. > > No packages depend directly on libopenturns0.1, but eficas > build-depends on python-openturns (which itself depends on > libopenturns0.1/0.2) and feel++ build-depends on libopenturns-dev. It > is not clear to me whether these dependencies are really necessary, > but this is another story. > > Please tell me whether uploading openturns 1.1-3 into unstable is fine by you. Hello, Here is an update: * openturns 1.0-4 just received an RC bug (#713524), which is already fixed in experimental. * openturns 1.1-3 has still not been built on armel, mips and mipsel, and build failed on sparc with a cryptic message (The bug is not reproducible, so it is likely a hardware or OS problem) * Upstream is preparing a new release; I would really like to move 1.1 into sid so that I can upload 1.2 into experimental. Please tell me whether I can upload opennturns 1.1 into sid. 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#713524: openturns: FTBFS: ERROR: a 'NAMESPACE' file is required
tags 713524 fixed-in-experimental thanks 2013/6/22 Lucas Nussbaum : > Source: openturns > Version: 1.0-4 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20130620 qa-ftbfs > Justification: FTBFS on amd64 Hello, This build failure is already fixed in 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#710782: transition: openturns
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, openturns 1.1 has been uploaded into experimental, and introduces a soname bump. Version 1.1-3 uploaded few days ago should build fine everywhere if buildds have enough RAM, all issues found in earlier versions should now be fixed. Thus I would like to upload this version into unstable. No packages depend directly on libopenturns0.1, but eficas build-depends on python-openturns (which itself depends on libopenturns0.1/0.2) and feel++ build-depends on libopenturns-dev. It is not clear to me whether these dependencies are really necessary, but this is another story. Please tell me whether uploading openturns 1.1-3 into unstable is fine by you. 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#710778: transition: oce
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Hello, I would like to upload oce 0.12 into unstable, it is in experimental for a couple of months. This source package provides several development libraries, their soname version have been bumped. The only issue is on mips, a single test timeouts because this architecture is slow, I will change the default timeout value so that it does no more fail (1800s should be fine, but I will take 3600s). The following packages build-depend on oce: gmsh freecad netgen The first two can be rebuilt without trouble by a binNMU; netgen must be patched due to API changes, but it is currently not in testing. My understanding about Ben's documentation is that this is the information you want, please correct me if I am wrong; testing against liboce-foundation since other binary packages depend on this one. title = "oce"; is_affected = .depends ~ "liboce-foundation2" | .depends ~ "liboce-foundation6"; is_good = .depends ~ "liboce-foundation6"; is_bad = .depends ~ "liboce-foundation2"; 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#710695: po4a-gettextize: wrong timezone in POT-Creation-Date
tags 710695 pending thanks 2013/6/1 Jakub Wilk : > Package: po4a > Version: 0.42-2 > > po4a-gettextize puts wrong timezone in the POT-Creation-Date field (+0300 > when +0200 is correct): > > $ export TZ=Europe/Warsaw > $ echo dummy > dummy.txt > $ po4a-gettextize -f text -m dummy.txt -p dummy.po > $ grep POT-Creation dummy.po > "POT-Creation-Date: 2013-06-01 17:39+0300\n" > $ date -R > Sat, 01 Jun 2013 17:39:37 +0200 Hello, This one is already fixed in upstream SVN: http://anonscm.debian.org/viewvc/po4a?view=revision&revision=2720 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#706591: po4a: [INTL:pt_BR] Brazilian Portuguese PO translation of binary
tags 706591 pending thanks 2013/5/2 rafael ff1 : > Package: po4a > Version: 0.44 > Tags: l10n patch > Severity: wishlist > > Hi there, > > Can you please update the Brazilian Portuguese translation for po4a binary? > > As an attachment you will find the file po4a-bin.pt_BR.po. It is UTF-8 > encoded and it is tested with msgfmt. Thanks, Your file has been committed into the upstream repository and will be shipped in 0.45. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696997: po4a-gettextize doesn't work with localised ini
tags 696997 pending tags 696992 pending thanks 2012/12/30 Didier Raboud : > Package: po4a > Version: 0.42-1 > Severity: important > > Hi, > > I'm trying to use po4a with ini files (as transient files towards > various other formats), but I can't use po4a-gettextize to back-generate > a useful .po file: > > $ po4a-gettextize -f ini -m scene101.ini -l scene101.fr.ini > Use of uninitialized value $typeorig in string eq at > /usr/share/perl5/Locale/Po4a/Po.pm line 633. > po4a gettextize: Internal error: type of original string number 0 isn't > provided > > The corresponding files are attached; what am I doing wrong? Hello, Ini support was outdated, each msgid does now contain information about text type. I applied the attached patch into our repository, it fixes both 696992 and 696997. Thanks for your reports. Denis 0001-Ini-Include-key-parameter-as-an-automatic-comment.patch Description: Binary data
Bug#693266: po4a: Couldn't determine the input document's charset.
On 2012/11/14 Jakub Wilk wrote: > Package: po4a > Version: 0.44-1 > Severity: normal > > Document encoding detection for the Docbook input form appears to be broken > in this version: > > $ po4a-gettextize -f docbook -m test.xml -p test.po > po4a: Couldn't determine the input document's charset. Please specify it on > the command line. (non-ASCII char at test.xml:4) > > But the document _has_ a correct encoding declaration. > > I didn't have this problem with po4a 0.42-1. Hello, This is indeed a regression, it will be fixed in 0.45. Thanks for your report. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691946: Debconf templates are not translated
On 2012/10/31 David Prévot wrote: > Package: gcl > Version: 2.6.7-108 > Severity: important > Tags: l10n > Justification: Policy 3.9.1 > > Hi, > > The debconf templates are not showed translated. > /var/lib/dpkg/info/gcl.templates does indeed only contain the English > version. > > According to the build logs, debconf-updatepo is called before > dh_installdebconf, so I have no idea where does the problem come from, > debian-i18n is X-CC, and hopefully someone may spot what is going wrong > here. The clean target generates debian/gcl.templates, this file is then installed by dh_installdebconf. But text in this file is different from what is in PO files. po2debconf must instead be called first, then sed to replace @EXT@. You can for instance rename debian/in.gcl.templates into debian/_in.gcl.templates (do not forget to modify debian/po/POTFILES.in) and add a rule like this: debian/in.gcl.templates: debian/_in.gcl.templates FORCE po2debconf debian/_in.gcl.templates > $@ and add FORCE to .PHONY. Another way is to rename debian/in.gcl.templates into debian/gcl.templates (ditto in POTFILES.in) and add sed -i -e 's,@EXT@,$(EXT),g' debian/gcl$(EXT)/DEBIAN/templates after dh_installdebconf. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684137: po4a: Incorrect handling of in docbook, should be inline?
tags 684137 pending thanks 2012/10/28 Petter Reinholdtsen : > [D. Barbier] >> A placeholder is not a good idea; in fact, you should even drop >> in the translation. It does not make sense to mark >> break pages found in the English document. Maybe the better option >> is to preprocess the XML documents to remove those tags. > > Actually, it make sense in my case, as it make it a lot easier to > check the original paper book when I find errors in the docbook text, > and also make it easier to insert indexterm entries into the correct > location and with the correct range. > > Sorry to hear you do not want to apply the simple patch, but I can > live with the workaround. Okay, I am usually conservative, but this change should be harmless. Your patch has been applied in the upstream repository. Thanks for your report. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684137: po4a: Incorrect handling of in docbook, should be inline?
On 2012/8/7 Petter Reinholdtsen wrote: > [David Prévot] >> Note that you can simply (temporarily) override the distribution >> file to test if it behaves as expected, and before it get fixed in >> po4a, you can use the following options to override the default >> behavior: >> >> -o nodefault='' -o inline='' > > Ah, great. It resulted in this: > > msgid "" > "A single paragraph of text at the end of one page, which eventually moved > on " > "to the next page." > msgstr "" > > And it is OK for my purpose. It might be better to put a placeholder > in there, but I am not sure. > > If you want to look at the docbook project I am working on, it is > available from https://github.com/petterreinholdtsen/free-culture-lessig >. > I create/update a docbook version of Free Culture by Lawrence Lessig, > and translate it to Norwegian using po4a. :) Hello Petter, The beginpage tag is called ubiquitous in Docbook DTD, so I guess that it can appear either inline or not. Marking it inline may have been a better choice, yes. But it has been removed in Docbook v5: http://www.docbook.org/tdg5/en/html/ch01.html#t.removed So I believe that it is not worth changing it now, David's workaround can be applied if needed. A placeholder is not a good idea; in fact, you should even drop in the translation. It does not make sense to mark break pages found in the English document. Maybe the better option is to preprocess the XML documents to remove those tags. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564245: po4a: explicit master in split mode / is split mode still advised?
tags 564245 pending thanks On 2010/7/27 David Prévot wrote: > Hi, > > On Fri, Feb 05, 2010 at 03:51:31PM +0100, Yann Dirson wrote: >> >> Here is a simple patch allowing the following construct: >> >> [type: xml] foo/res/gui.xml $lang:/dev/null master:foo >> [type: xml] bar/res/gui.xml $lang:/dev/null master:bar > > I just updated your patch, against the current version of po4a. Anyway, > since [po4a_paths] is deprecated since [po_directory] can be used, I > wonder if split mode is still advised (if so, there must be some work > left in order to make your patch useful). > > If the goal is to split parts of the translation, one can always use > different sub-directories, e.g. pod, bin and www in tho po4a program. Hello, I also believe that the splitted is almost useless, compendia is IMO a better solution. However I may be wrong, and this usage seems to be quite common, so I applied this patch upstream. With two minor changes: 1. Options could not be specified along with master 2. I did not like any of your proposed syntax, and chose master:file=gui-foo. Thanks Yann, and sorry for the delay. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661708: po4a --msgmerge-opt should also affect the POT file
On 2012/2/29 David Prévot wrote: > Package: po4a > Version: 0.41-1 > Severity: wishlist > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, Hello David, > The msgmerge option only affects the PO files. Absolutely. > It would be nice if it would also affect the POT file. I disagree; msgmerge only modifies PO files, so it would be quite confusing if users request changes in POT file by setting some --msgmerge-opt flag. > See e.g. --msgmerge-opt --no-location where the line references are only > skipped from the PO files. The --porefs=none flag had been added years ago to po4a-updatepo for this exact purpose, but unfortunately this support had not been added to the po4a command-line tool. I just fixed it in SVN. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679137: po4a: updatepo and gettextize have != outputs when using multiple masters
On 2012/6/26 Jérémy Lal wrote:
> Package: po4a
> Version: 0.42-1
> Severity: minor
>
> $ po4a-gettextize -f xhtml -M UTF-8 -m "xxx.html" -m "yyy.html" ... -p
> test.po
> ouputs :
> #. type: Attribute 'lang' of:
> #: site/html_fr/actualites.html:19 site/html_fr/contacts.html:19
> site/html_fr/courriel.html:18 site/html_fr/courriel-ok.html:18
> msgid "fr"
> msgstr ""
>
> Then i change something in one.html and want to update test.po :
> po4a-updatepo -f xhtml -M UTF-8 -m "xxx.html" -m "yyy.html" ... -p test.po
> outputs :
> #. type: Attribute 'lang' of:
> #: site/html_fr/actualites.html:19 site/html_fr/contacts.html:19
> #: site/html_fr/courriel.html:18 site/html_fr/courriel-ok.html:18
> msgid "fr"
> msgstr ""
>
> I guess the later format is cleaner, but it would be nicer if they
> were the same.
Hello,
Thanks for your report.
Po4a-gettextize is run only once, this discrepancy thus appears only
the first time po4a-updatepo is run, this is why nobody cares.
Anyway, if there is a simple solution, we could apply it.
Can you please tell me whether the following patch does address your concern?
--- /usr/share/perl5/Locale/Po4a/Po.pm
+++ /usr/share/perl5/Locale/Po4a/Po.pm
@@ -429,7 +429,7 @@ sub write{
$output .= format_comment($self->{po}{$msgid}{'type'},". type: ")
ifdefined($self->{po}{$msgid}{'type'})
&& length ($self->{po}{$msgid}{'type'});
-$output .= format_comment($self->{po}{$msgid}{'reference'},": ")
+$output .= format_comment(wrap($self->{po}{$msgid}{'reference'}),": ")
ifdefined($self->{po}{$msgid}{'reference'})
&& length ($self->{po}{$msgid}{'reference'});
$output .= "#, ". join(", ", sort
split(/\s+/,$self->{po}{$msgid}{'flags'}))."\n"
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:
On 2012/3/12 Mathieu Malaterre wrote:
> Started discussion at:
>
> http://www.cmake.org/pipermail/cmake/2012-March/049596.html
Hello Mathieu,
A solution is to move targets related to wrapped languages from
VTKTargets.cmake into VTKTargets${lang}.cmake and install this file
into ${lang}-vtk. Here is a (mostly tested) patch. I used this
approach in oce source package (in experimental).
There is one problem though, cmake complains about missing targets:
CMake Error: INSTALL(EXPORT "VTKTargetsPythonD" ...) includes target
"vtkCommonPythonD" which requires target "vtksys" that is not in the
export set.
...
Files are generated, but cmake returns 1, so errors have to be ignored
which is quite annoying.
Denis
split-VTKTargets.patch
Description: Binary data
Bug#683484: cmake: Please add multiarch libdir into CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
Package: cmake
Version: 2.8.9~rc1-1
Severity: wishlist
Hello,
One of my packages uses RPATH because some libraries are put into
/usr/lib/package.
I use ${CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES} to remove system
paths from RPATH.
It worked fine, but after migrating this package to multiarch, RPATH
now contains
/usr/lib/ because this directory is not listed in
CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES.
Can you please add it?
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#683374: oce: trouble loading plugin
On 2012/7/31 Julien Cristau wrote:
> Package: oce
> Version: 0.10-1
> Severity: normal
>
> Plugin::Load in src/Plugin/Plugin.cxx basically does
> dlopen("lib" + $name_of_the_plugin + ".so"). When $name_of_the_plugin
> is FWOSPlugin that fails unless liboce-ocaf-lite-dev is installed, which
> seems like it shouldn't be necessary. I'm not sure if this is a bug in
> the application, if Plugin::Load should be able to find the versioned
> file, or if libFWOSPlugin.so should be shipped in the runtime lib
Hello Julien,
We may move libFWOSPlugin.so into /usr/lib/oce-0.10. DRAWEXE will
work just fine (because of its rpath settings), but Plugin::Load would
have to be taught to look into this directory if we want to not break
other applications.
Another idea is to edit /usr/share/oce-0.10/src/StdResource/Plugin and replace
a148e300-5740-11d1-a904-080036aaa103.Location: FWOSPlugin
by
a148e300-5740-11d1-a904-080036aaa103.Location: FWOSPlugin-3
A symlink libFWOSPlugin-3.so --> libFWOSPlugin.so.3 will then do the
trick. I prefer this solution, no change is required in 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#677561: Fix build with oce 0.10
On 2012/6/15 Julien Cristau wrote: > On Thu, Jun 14, 2012 at 22:42:25 +0200, D. Barbier wrote: > >> Package: freecad >> Version: 0.12.5284-dfsg-7 >> Severity: wishlist >> Tags: patch >> >> Hello, >> >> This patch is needed to compile freecad with oce 0.10 currently >> in experimental. >> >> Denis > >> diff --git a/src/3rdParty/salomesmesh/src/Controls/SMESH_Controls.cpp >> b/src/3rdParty/salomesmesh/src/Controls/SMESH_Controls.cpp >> index d03237f..13eec35 100644 >> --- a/src/3rdParty/salomesmesh/src/Controls/SMESH_Controls.cpp >> +++ b/src/3rdParty/salomesmesh/src/Controls/SMESH_Controls.cpp >> @@ -52,6 +52,7 @@ >> #include >> #include >> #include >> +#include >> >> #include "SMDS_Mesh.hxx" >> #include "SMDS_Iterator.hxx" > > Shouldn't that (and a couple others) be ? IMHO it does not matter, this include is needed only to get the M_PI macro definition. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677561: Fix build with oce 0.10
Package: freecad Version: 0.12.5284-dfsg-7 Severity: wishlist Tags: patch Hello, This patch is needed to compile freecad with oce 0.10 currently in experimental. Denis freecad-oce-0.10.patch Description: Binary data
Bug#677558: Fix build with oce 0.10
Package: netgen Version: 4.9.13.dfsg-4 Severity: wishlist Tags: patch Hello, This patch is needed to compile netgen with oce 0.10 currently in experimental. Denis netgen-oce-0.10.patch Description: Binary data
Bug#677544: Fix to build gmsh with oce 0.10
Package: gmsh Version: 2.5.1~beta2~svn12143~dfsg-2 Severity: wishlist Tags: patch Hello, This patch is needed to compile gmsh with oce 0.10 currently in experimental. It has been committed upstream: http://geuz.org/pipermail/gmsh/2012/007320.html Denis gmsh-oce-0.10.patch Description: Binary data
Bug#676776: [liboce-foundation-dev] static pathnames in OCE-libraries-release.cmake makes it impossible to build to other architectures than amd64
On 2012/6/9 Sandro Knauß wrote: > Package: liboce-foundation-dev > Version: 0.9.1-2 > Severity: important > > Hello, > > in /usr/lib/oce-0.9.1/OCE-libraries-release.cmake are used static pathnames to > libaries. An example ( /usr/lib/oce-0.9.1/OCE-libraries-release.cmake line > 225): > IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "TKMath;TKernel;/usr/lib/x86_64- > linux-gnu/libXmu.so;/usr/lib/x86_64-linux-gnu/libSM.so;/usr/lib/x86_64-linux- > gnu/libICE.so;/usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux- > gnu/libXext.so" > > So if I try to compile any package with cmake for other architectures than > x86_64, this naturally fails :) Hello, liboce-foundation-dev indeed contains several files which are architecture-dependent, it must be declared as Architecture: any and not all, I will fix that. Thanks for your report. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669150: RM: liboce-*1 -- RoM
On 2012/5/30 Anton Gladky wrote: > Sorry to rise the question again. The new upload of elmerfem did not > fix the problem [1] > (not supposed to. but...). > > What about removing elmerfem on armel and armhf? I understand, it is > not the best > solution. But, for example, freecad is hanging in sid since March not > being able to > migrate to testing because of this. > > Thank you. > > Anton > > [1] https://buildd.debian.org/status/package.php?p=elmerfem Hello, AFAICT there has been no progress on the R front (#672749) and OCE is ready to migrate, so your suggestion seems reasonable. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669150: RM: liboce-*1 -- RoM
On 2012/5/30 Anton Gladky wrote: > Sorry to rise the question again. The new upload of elmerfem did not > fix the problem [1] > (not supposed to. but...). > > What about removing elmerfem on armel and armhf? I understand, it is > not the best > solution. But, for example, freecad is hanging in sid since March not > being able to > migrate to testing because of this. > > Thank you. > > Anton > > [1] https://buildd.debian.org/status/package.php?p=elmerfem Hello Anton, gmsh still FTBFS on kfreebsd-*, isn't this also a problem for this transition? This happens since auto-tests are enabled, maybe you can disable them on kfreebsd-*? Not a perfect solution, but AFAICT this is not a regression. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646173: Typos found while translating the po4a documentation into German
On 2012/4/30 Helge Kreutzmann wrote: > Hello David, > On Sun, Apr 29, 2012 at 03:57:22PM -0400, David Prévot wrote: >> Le 25/03/2012 10:11, Helge Kreutzmann a écrit : >> > On Wed, Feb 29, 2012 at 07:49:02PM +0100, Helge Kreutzmann wrote: >> >> the translation is finished, now the second last set of fixes for the >> >> translations are attached. I have a few more issues in the pipe, but >> > >> > Did you have a chance to review these last set of fixes yet? >> >> The proposed po4a-build.xml change, already discussed [0] in this bug >> log, actually discouraged me to review it. >> >> > 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646173#32 > > No problem; simply accept / change those which you concur, the other > ones we can discuss later. > >> Denis, if you were waiting for me [2], I apologize. Maybe those typos >> can be addressed later, or if you disagree, I can try and brace myself >> into it (eventually committing only changes that can be trivially >> unfuzzy, and keeping other ones for later, eventually keeping them in >> another bug report). >> >> > 2: >> > http://lists.alioth.debian.org/pipermail/po4a-devel/2012-February/002071.html > > I wish I could join the discussion over there, maybe then things would > have gotten smoother… > > But great to see that a release is indeed in the pipe. > > Thanks for your work, looking forward to the release and do not > hesitate to contact me if there is anything I can do to ease the > process (though I might be a little slow in the coming weeks in > answering). Hallo Helge, The website is now regenerated and contains your German translation. Thanks, and sorry again for the delay. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673544: openturns: FTBFS on s390: 'ptrdiff_t& {aka int&}' vs. 'long int'
On 2012/5/19 Cyril Brulebois wrote:
> Source: openturns
> Version: 1.0-2
> Severity: serious
> Justification: FTBFS
>
> Hi,
>
> your package no longer builds on s390:
> |
> /build/buildd-openturns_1.0-2-s390-WUP9uL/openturns-1.0/obj-s390-linux-gnu/python/src/common_modulePYTHON_wrap.cxx:4146:5:
> error: invalid initialization of reference of type 'ptrdiff_t& {aka int&}'
> from expression of type 'long int'
>
> Full build log:
> https://buildd.debian.org/status/fetch.php?pkg=openturns&arch=s390&ver=1.0-2&stamp=1337413625
Hello,
This looks very similar to
http://bugs.debian.org/672332
http://old.nabble.com/swig-2.05%3A-swig%3A%3Agetslice-errors-to33739521.html#a33739521
The last succesful build of openturns on s390 used swig 2.0.4, so it
is very likely that this FTBFS is due to swig 2.0.5 and should be
fixed by swig 2.0.6 (thus Cc'ing swig2.0 maintainer)
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670066: Bug #670066 python-openturns is unusable
On 2012/5/17 D. Barbier wrote: > On 2012/5/17 Christophe Prud'homme wrote: >> I think It should go in unstable. I don't think there are that many users >> and OT1.0 fixes a few things as well as provide many new features > > Hello Christophe, > > Too late, it has been uploaded into experimental ;-) > I followed the procedure about library transitions and filed a bug > against release.d.o to ask whether I can upload into unstable. I uploaded 1.0-2 into unstable with their approval. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670066: Bug #670066 python-openturns is unusable
On 2012/5/17 Christophe Prud'homme wrote: > I think It should go in unstable. I don't think there are that many users > and OT1.0 fixes a few things as well as provide many new features Hello Christophe, Too late, it has been uploaded into experimental ;-) I followed the procedure about library transitions and filed a bug against release.d.o to ask whether I can upload into unstable. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670066: Bug #670066 python-openturns is unusable
On 2012/5/15 D. Barbier wrote: > On 2012/5/15 trophime wrote: >> On Tue, 2012-05-15 at 01:43 +0200, D. Barbier wrote: >>> On 2012/5/14 Aron Xu wrote: >>> > The test build failed on amd64 and i386, at the same place. Attached >>> > is my change to your git tree and the build log produced on amd64. >>> >>> Hello, >>> >>> Here is an updated status; I did not encounter your problems because >>> my upstream tarball was buggy, we should now be in sync: >>> * a patch is needed to build with g++ 4.7 >>> * few runtime tests fail with g++ 4.7, this is why it now >>> Build-Depends: g++-4.6 >>> * add Build-Depends: bc, it is needed by a single test >>> * fix handling of the rotRPackage R package during tests >>> >>> It builds fine in pbuilder, but I did not yet check upgrade path from >>> openturns 0.15. I believe that it could be uploaded in experimental >>> or unstable when this is done. >>> >>> Denis >> >> Hi, >> I had to explicitly specify python version in debian/rules to avoid an >> FTBS when python 3.2 is installed. Please find attached the patch. > > Thanks Christophe, > > Patch applied. Hello, When testing upgrades from current openturns packages, I realized that libopenturns0 and libopenturnss0.1 are not coinstallable because of several file conflicts, and added the following changes: * rotRPackage is moved into its own binary package r-openturns-utils * install openturns.conf into /etc/openturns-1.0/openturns/ * install wrappers into /usr/lib/openturns-1.0/ All changes have now been pushed into OT svn repository. IMHO it can be uploaded after editing debian/changelog. The remaining questions are: should it be uploaded into unstable or experimental? What else is needed? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670066: Bug #670066 python-openturns is unusable
On 2012/5/15 trophime wrote: > On Tue, 2012-05-15 at 01:43 +0200, D. Barbier wrote: >> On 2012/5/14 Aron Xu wrote: >> > The test build failed on amd64 and i386, at the same place. Attached >> > is my change to your git tree and the build log produced on amd64. >> >> Hello, >> >> Here is an updated status; I did not encounter your problems because >> my upstream tarball was buggy, we should now be in sync: >> * a patch is needed to build with g++ 4.7 >> * few runtime tests fail with g++ 4.7, this is why it now >> Build-Depends: g++-4.6 >> * add Build-Depends: bc, it is needed by a single test >> * fix handling of the rotRPackage R package during tests >> >> It builds fine in pbuilder, but I did not yet check upgrade path from >> openturns 0.15. I believe that it could be uploaded in experimental >> or unstable when this is done. >> >> Denis > > Hi, > I had to explicitly specify python version in debian/rules to avoid an > FTBS when python 3.2 is installed. Please find attached the patch. Thanks Christophe, Patch applied. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670066: Bug #670066 python-openturns is unusable
On 2012/5/14 Aron Xu wrote: > The test build failed on amd64 and i386, at the same place. Attached > is my change to your git tree and the build log produced on amd64. Hello, Here is an updated status; I did not encounter your problems because my upstream tarball was buggy, we should now be in sync: * a patch is needed to build with g++ 4.7 * few runtime tests fail with g++ 4.7, this is why it now Build-Depends: g++-4.6 * add Build-Depends: bc, it is needed by a single test * fix handling of the rotRPackage R package during tests It builds fine in pbuilder, but I did not yet check upgrade path from openturns 0.15. I believe that it could be uploaded in experimental or unstable when this is done. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670066: Bug #670066 python-openturns is unusable
On 2012/5/10 Aron Xu wrote: > Hi, > > Freeze is approaching, is there any news on version 1.0? Or do we need > to fix open bugs and release with 0.15? Hello, IMO https://github.com/dbarbier/deb-ot is in a pretty good shape. Some polishing may be needed, my laptop is not powerful and take hours to build it. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671827: libcurl3-gnutls: git over HTTPS hangs if behind a proxy
On 2012/5/9 Alessandro Ghedini: > On Wed, May 09, 2012 at 05:03:03PM +0200, D. Barbier wrote: >> On 2012/5/9 Alessandro Ghedini wrote >> > On Mon, May 07, 2012 at 10:38:09AM +0200, D. Barbier wrote: >> >> Hello, >> > >> > Hi, >> > >> >> Symptoms look similar to #627335: behind a proxy, git over HTTP works >> >> fine but not HTTPS. >> >> >> >> $ git ls-remote --heads http://github.com/jeromerobert/jCAE.git >> >> f1fdb01741f8aab4108222d3ca6fa9c095e09727 refs/heads/master >> >> >> >> But >> >> $ git ls-remote --heads https://github.com/jeromerobert/jCAE.git >> >> hangs. >> >> >> >> [...] >> >> >> >> Downgrading libcurl3-gnutls to the stable version fixes this problem. >> > >> > I was not able to reproduce this, but AFAICT it may have something to do >> > with >> > the NTLM authentication. Could you please be more specific about your setup >> > (e.g. what proxy and configuration you use, ...) so that I can try to >> > reproduce >> > it? >> >> Hello, >> >> This is a corporate proxy, I know nothing about it, sorry. >> Here are two logs when running the command above with >> GIT_CURL_VERBOSE=1. User/password are set in $HOME/.gitconfig: >> [http] >> proxy = http://U.S.E.R:p.a.s.s.w.o@ppp.rrr.ooo.xxx.yyy:9092 >> >> Please note also that as in #627335, curl >> https://github.com/jeromerobert/jCAE.git does its job, this problem >> only appears with git. > > Hmmm, this is just a wild try but, according to the libcurl docs, the NTLM > authentication works only with OpenSSL and NSS, unless a working "ntml_auth" > executable is present. Could you please install the winbind package (which > provides that program) and try again? It is weird that it works with the > stable > libcurl though. Hello, Installing winbind did not 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#671827: libcurl3-gnutls: git over HTTPS hangs if behind a proxy
On 2012/5/9 Alessandro Ghedini wrote > On Mon, May 07, 2012 at 10:38:09AM +0200, D. Barbier wrote: >> Hello, > > Hi, > >> Symptoms look similar to #627335: behind a proxy, git over HTTP works >> fine but not HTTPS. >> >> $ git ls-remote --heads http://github.com/jeromerobert/jCAE.git >> f1fdb01741f8aab4108222d3ca6fa9c095e09727 refs/heads/master >> >> But >> $ git ls-remote --heads https://github.com/jeromerobert/jCAE.git >> hangs. >> >> [...] >> >> Downgrading libcurl3-gnutls to the stable version fixes this problem. > > I was not able to reproduce this, but AFAICT it may have something to do with > the NTLM authentication. Could you please be more specific about your setup > (e.g. what proxy and configuration you use, ...) so that I can try to > reproduce > it? Hello, This is a corporate proxy, I know nothing about it, sorry. Here are two logs when running the command above with GIT_CURL_VERBOSE=1. User/password are set in $HOME/.gitconfig: [http] proxy = http://U.S.E.R:p.a.s.s.w.o@ppp.rrr.ooo.xxx.yyy:9092 Please note also that as in #627335, curl https://github.com/jeromerobert/jCAE.git does its job, this problem only appears with git. Denis good-with-libcurl3-gnutls_7.21.0-2.log Description: Binary data bad-with-libcurl3-gnutls_7.25.0-1.log Description: Binary data
Bug#671827: libcurl3-gnutls: git over HTTPS hangs if behind a proxy
Package: libcurl3-gnutls Version: 7.25.0-1 Severity: normal Hello, Symptoms look similar to #627335: behind a proxy, git over HTTP works fine but not HTTPS. $ git ls-remote --heads http://github.com/jeromerobert/jCAE.git f1fdb01741f8aab4108222d3ca6fa9c095e09727refs/heads/master But $ git ls-remote --heads https://github.com/jeromerobert/jCAE.git hangs. Running the same command with GIT_CURL_VERBOSE=1 prints: [...] * Received HTTP code 407 from proxy after CONNECT * STATE: WAITPROXYCONNECT => CONNECT handle 0x121e818; (connection #-5000) * About to connect() to proxy proxy.XXX.XXX port 8080 (#1) * Trying XXX.XXX.XXX.XXX... * 0x12158b8 is at send pipe head! * STATE: CONNECT => WAITCONNECT handle 0x121e818; (connection #1) * Connected to proxy.XXX.XXX (XXX.XXX.XXX.XXX) port 8080 (#1) * Connected to proxy.XXX.XXX (XXX.XXX.XXX.XXX) port 8080 (#1) * Establish HTTP proxy tunnel to github.com:443 * Proxy auth using NTLM with user '' > CONNECT github.com:443 HTTP/1.1 Host: github.com:443 Proxy-Authorization: NTLM TlRMTVNTUAABBoIIAAA= User-Agent: git/1.7.10 Proxy-Connection: Keep-Alive Pragma: no-cache * STATE: WAITCONNECT => WAITPROXYCONNECT handle 0x121e818; (connection #1) * Multi mode finished polling for response from proxy CONNECT < HTTP/1.1 407 Proxy Authentication Required < Proxy-Authenticate: NTLM TlRMTVNTUAACBAAEADgGgokCJ+N51b5YAfwAAIAAgAA8BQLODg9JV0ZSAgAIAEkAVwBGAFIAAQAQAFMARgBSAFMAMQAwADAAMQAEABgAaQB3AGYAcgAuAGgAcQAuAGMAbwByAHAAAwAqAFMARgBSAFMAMQAwADAAMQAuAGkAdwBmAHIALgBoAHEALgBjAG8AcgBwAAUADgBoAHEALgBjAG8AcgBwAAA= < Cache-Control: no-cache < Pragma: no-cache < Content-Type: text/html; charset=utf-8 < Proxy-Connection: Keep-Alive < Set-Cookie: BCSI-CS0AFB947C=2; Path=/ < Connection: Keep-Alive < Content-Length: 830 < * Ignore 830 bytes of response-body and nothing more. Downgrading libcurl3-gnutls to the stable version fixes this problem. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666782: [openturns] Test 150: "Trapezoidal Factory" blocks build on i386 architectures
tags 666782 patch thanks Le 19 avril 2012 11:54, D. Barbier a écrit : > Le 1 avril 2012 21:50, Aron Xu a écrit : >> Package: src:openturns >> Version: 0.15-3 >> >> After the upload of 0.15-3, which enables `make test` by dh_auto_test, >> the package FTBFS on i386 and kfreebsd-i386. After some investigation >> it was discovered that Test 150, "Trapezoidal Factory" hangs on i386 >> architectures (confirmed on i386 and kfreebsd-i386), thus make the >> build process timed out and finally being terminated on buildd. There >> are two obvious ways of resolving the problem: >> 1. Disable test, as before. >> 2. Patch the build system, to make it kill the test after some >> reasonable timeout. >> >> Option 2 sounds more ideal, but needs more time to implement. >> >> Due to the nature of this package, I decided not to make an upload >> (and press the buildds, especially architectures that are not so fast) >> for changing a test option. I've made binary uploads for the two >> archs, which was built (in pbuilder) and signed by me to the archive. >> During the build I killed the process of "Trapezoidal Factory" test >> manually so the package can be produced. If there is a need of >> rebuilding/updating this package, then we'd choose from the above two >> options. > > Hello, > > Upstream workarounds this bug by compiling everything with > -fno-cse-follow-jumps. It would be nice to know which file gets > miscompiled. Hello, I built openturns 0.15-3 on an old x86 laptop yesterday, here is the result of my experiments: * TrapezoidalFactory test hanged too on my box * After recompiling lib/src/Base/Optim/Cobyla/algocobyla.c by adding -fno-cse-follow-jumps, test does no more hang (hmmm, I forgot to check that it passes then) * There are only 2 non-trivial C files, everything else is C++ (and Fortran), so building with CFLAGS+=-fno-cse-follow-jumps is the easiest solution * I looked again at upstream building instructions, and in fact this is exactly what they suggest, they use this flag only for C files, not C++. So here is a patch. Another point: mipsel failed on another buildd (phrixos) but this machine is not listed at http://db.debian.org/machines.cgi so I do not know how much RAM is available there. Denis trapezoidal-unblock.patch Description: Binary data
Bug#669425: openturns: new upstream version
[Moving discussion from 670066]
Do we want to build python-openturns against all available python
versions (which is smarter, but builds will take much longer), or do
we build only against the default version?
In the latter case, we should not let python-openturns Provides:
${python:Provides}.
IMO we can use the latter and see if builds run much faster with
CMake, in which case we may enable other python versions.
Denis
--
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
Le 23 avril 2012 07:14, Christophe Prud'homme a écrit : > Denis > > This work(debian packaging) is also done by Phimeca who maintains > openturns, or did you use their work ? > > I do not have preferences for the soname I did not use their packaging, mostly because it was simpler for me to work on 0.15-3 (dh vs. cdbs). I will have a look tonight. Denis -- 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
Le 22 avril 2012 22:11, D. Barbier a écrit : > Le 22 avril 2012 20:31, D. Barbier a écrit : >> Le 22 avril 2012 20:19, Christophe Prud'homme a écrit : >>> Denis >>> >>> I received some patches for openturns from J. Schueller. >>> >>> I will apply them and upload a new version for 0.15 then work on 1.0 >> >> Christophe, I already almost finished packaging for 1.0, the only >> issue is with python. But I do not know where to push these changes >> so that you can review them. >> BTW, we should IMHO change the SONAME, do you have any preference? > > Christophe, I just created a git repository to publish my changes: > https://github.com/dbarbier/deb-ot > > There are instructions at > https://github.com/dbarbier/deb-ot/wiki > to transform it into a git-svn repository. Hi again, I do not know why, but it seems that this is due to python extensions being linked against python2.7 library. It now works fine in my CMake build. Denis -- 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
Le 22 avril 2012 20:31, D. Barbier a écrit : > Le 22 avril 2012 20:19, Christophe Prud'homme a écrit : >> Denis >> >> I received some patches for openturns from J. Schueller. >> >> I will apply them and upload a new version for 0.15 then work on 1.0 > > Christophe, I already almost finished packaging for 1.0, the only > issue is with python. But I do not know where to push these changes > so that you can review them. > BTW, we should IMHO change the SONAME, do you have any preference? Christophe, I just created a git repository to publish my changes: https://github.com/dbarbier/deb-ot There are instructions at https://github.com/dbarbier/deb-ot/wiki to transform it into a git-svn 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#670066: python-openturns is unusable
Le 22 avril 2012 20:19, Christophe Prud'homme a écrit : > Denis > > I received some patches for openturns from J. Schueller. > > I will apply them and upload a new version for 0.15 then work on 1.0 Christophe, I already almost finished packaging for 1.0, the only issue is with python. But I do not know where to push these changes so that you can review them. BTW, we should IMHO change the SONAME, do you have any preference? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670067: python-openturns is unusable
Package: python-openturns Version: 0.15-3 Justification: renders package unusable Severity: grave 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 "", line 1, in File "/usr/lib/python2.7/dist-packages/openturns/__init__.py", line 87, in 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#669425: openturns: new upstream version
Source: openturns Version: 0.15-3 Severity: wishlist Hello, Openturns 1.0 has been released this week. I would like to help in getting this version into Debian, but before that, we have to check in previous versions into SVN. I plan to first commit changes for 0.15-1, 0.15-2 and 0.15-3 packages into svn://svn.debian.org/svn/debian-science/packages/openturns/trunk, is there any reason not to do 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#666782: [openturns] Test 150: "Trapezoidal Factory" blocks build on i386 architectures
Le 19 avril 2012 15:41, Aron Xu a écrit : > Hi Denis, > > Thanks for your information! I believe it's helpful for next upload, :) Hello, BTW your upload failed on mipsel because rem has less than 512 MB of RAM, do you know how to requeue it on a more powerful buildd? This prevents openturns from migrating into 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#666782: [openturns] Test 150: "Trapezoidal Factory" blocks build on i386 architectures
Le 1 avril 2012 21:50, Aron Xu a écrit : > Package: src:openturns > Version: 0.15-3 > > After the upload of 0.15-3, which enables `make test` by dh_auto_test, > the package FTBFS on i386 and kfreebsd-i386. After some investigation > it was discovered that Test 150, "Trapezoidal Factory" hangs on i386 > architectures (confirmed on i386 and kfreebsd-i386), thus make the > build process timed out and finally being terminated on buildd. There > are two obvious ways of resolving the problem: > 1. Disable test, as before. > 2. Patch the build system, to make it kill the test after some > reasonable timeout. > > Option 2 sounds more ideal, but needs more time to implement. > > Due to the nature of this package, I decided not to make an upload > (and press the buildds, especially architectures that are not so fast) > for changing a test option. I've made binary uploads for the two > archs, which was built (in pbuilder) and signed by me to the archive. > During the build I killed the process of "Trapezoidal Factory" test > manually so the package can be produced. If there is a need of > rebuilding/updating this package, then we'd choose from the above two > options. Hello, Upstream workarounds this bug by compiling everything with -fno-cse-follow-jumps.It would be nice to know which file gets miscompiled. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664207: oce: freecad FTBFS against oce-0.9.1
notfound 664207 0.9.1-1
reassign 664207 freecad
found 664207 0.12.5284-dfsg-4
tags 664207 patch
thanks
Le 16 mars 2012 17:42, Anton Gladky a écrit :
> Source: oce
> Version: 0.9.1-1
> Severity: serious
>
> freecad fails to build against oce-0.9.1, but built ok against the
> previous version of oce.
> There is the end of compile log:
[...]
Hello,
Here is a patch.
Denis
diff --git a/src/Mod/Part/App/AppPartPy.cpp b/src/Mod/Part/App/AppPartPy.cpp
index 763f6da..e04a0f8 100644
--- a/src/Mod/Part/App/AppPartPy.cpp
+++ b/src/Mod/Part/App/AppPartPy.cpp
@@ -492,7 +492,7 @@ static PyObject * makePlane(PyObject *self, PyObject *args)
d.SetCoord(vec.x, vec.y, vec.z);
}
Handle_Geom_Plane aPlane = new Geom_Plane(p, d);
-BRepBuilderAPI_MakeFace Face(aPlane, 0.0, length, 0.0, width);
+BRepBuilderAPI_MakeFace Face(aPlane, 0.0, length, 0.0, width, Precision::Confusion());
return new TopoShapeFacePy(new TopoShape((Face.Face(;
}
catch (Standard_DomainError) {
diff --git a/src/Mod/Part/App/Geometry.cpp b/src/Mod/Part/App/Geometry.cpp
index bd58b32..f547f32 100644
--- a/src/Mod/Part/App/Geometry.cpp
+++ b/src/Mod/Part/App/Geometry.cpp
@@ -1252,7 +1252,7 @@ TopoDS_Shape GeomSurface::toShape() const
Handle_Geom_Surface s = Handle_Geom_Surface::DownCast(handle());
Standard_Real u1,u2,v1,v2;
s->Bounds(u1,u2,v1,v2);
-BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2);
+BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2, Precision::Confusion());
return mkBuilder.Shape();
}
diff --git a/src/Mod/Part/App/GeometrySurfacePyImp.cpp b/src/Mod/Part/App/GeometrySurfacePyImp.cpp
index 9f38b29..67dfde8 100644
--- a/src/Mod/Part/App/GeometrySurfacePyImp.cpp
+++ b/src/Mod/Part/App/GeometrySurfacePyImp.cpp
@@ -79,7 +79,7 @@ PyObject* GeometrySurfacePy::toShape(PyObject *args)
s->Bounds(u1,u2,v1,v2);
if (!PyArg_ParseTuple(args, "|", &u1,&u2,&v1,&v2))
return 0;
-BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2);
+BRepBuilderAPI_MakeFace mkBuilder(s, u1, u2, v1, v2, Precision::Confusion());
TopoDS_Shape sh = mkBuilder.Shape();
return new TopoShapeFacePy(new TopoShape(sh));
}
diff --git a/src/Mod/Part/App/PrimitiveFeature.cpp b/src/Mod/Part/App/PrimitiveFeature.cpp
index 2e4a5cf..8c0a6db 100644
--- a/src/Mod/Part/App/PrimitiveFeature.cpp
+++ b/src/Mod/Part/App/PrimitiveFeature.cpp
@@ -191,7 +191,7 @@ App::DocumentObjectExecReturn *Plane::execute(void)
gp_Pnt pnt(0.0,0.0,0.0);
gp_Dir dir(0.0,0.0,1.0);
Handle_Geom_Plane aPlane = new Geom_Plane(pnt, dir);
-BRepBuilderAPI_MakeFace mkFace(aPlane, 0.0, L, 0.0, W);
+BRepBuilderAPI_MakeFace mkFace(aPlane, 0.0, L, 0.0, W, Precision::Confusion());
const char *error=0;
switch (mkFace.Error())
diff --git a/src/Mod/Part/App/TopoShape.cpp b/src/Mod/Part/App/TopoShape.cpp
index 0ee407d..6a6b05b 100644
--- a/src/Mod/Part/App/TopoShape.cpp
+++ b/src/Mod/Part/App/TopoShape.cpp
@@ -1335,7 +1335,7 @@ TopoDS_Shape TopoShape::makeTube(double radius, double tol) const
double u1,u2,v1,v2;
surf->Bounds(u1,u2,v1,v2);
-BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, v1, v2);
+BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, v1, v2, Precision::Confusion());
return mkBuilder.Face();
}
@@ -1388,7 +1388,7 @@ TopoDS_Shape TopoShape::makeTube() const
Standard_Real u1,u2,v1,v2;
mySurface->Bounds(u1,u2,v1,v2);
-BRepBuilderAPI_MakeFace mkBuilder(mySurface, u1, u2, v1, v2);
+BRepBuilderAPI_MakeFace mkBuilder(mySurface, u1, u2, v1, v2, Precision::Confusion());
return mkBuilder.Shape();
}
@@ -1440,7 +1440,7 @@ TopoDS_Shape TopoShape::makeSweep(const TopoDS_Shape& profile, double tol, int f
mkSweep.Perform(tol, Standard_False, GeomAbs_C1, BSplCLib::MaxDegree(), 1000);
const Handle_Geom_Surface& surf = mkSweep.Surface();
-BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, vmin, vmax);
+BRepBuilderAPI_MakeFace mkBuilder(surf, umin, umax, vmin, vmax, Precision::Confusion());
return mkBuilder.Face();
}
diff --git a/src/Mod/Part/App/TopoShapeFacePyImp.cpp b/src/Mod/Part/App/TopoShapeFacePyImp.cpp
index 00f864f..148e18c 100644
--- a/src/Mod/Part/App/TopoShapeFacePyImp.cpp
+++ b/src/Mod/Part/App/TopoShapeFacePyImp.cpp
@@ -135,7 +135,7 @@ int TopoShapeFacePy::PyInit(PyObject* args, PyObject* /*kwd*/)
return -1;
}
-BRepBuilderAPI_MakeFace mkFace(S);
+BRepBuilderAPI_MakeFace mkFace(S, Precision::Confusion());
if (bound) {
Py::List list(bound);
for (Py::List::iterator it = list.begin(); it != list.end(); ++it) {
Bug#662800: openturns: please move rotRPackage files from python-openturns into libopenturns0
Package: src:openturns Version: 0.15-2 Severity: normal Hello, rotPackage can be used from C++ classes and not only from Python, please move /usr/lib/R/site-library/rotRPackage from python-openturns into libopenturns0. 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#662792: [openturns] rotRPackage is unusable
Package: src:openturns Version: 0.15-2+b1 Severity: important Hello Christophe, rotRPackage as shipped in python-openturns is unusable: $ python -c 'from openturns import *; LinearModelFactory().build(Normal(2).getNumericalSample(10),Normal().getNumericalSample(10))' Welcome to OpenTURNS version 0.15 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/openturns/statistics.py", line 1616, in build return _statistics.LinearModelFactory_build(self, *args) RuntimeError: InternalException : Error: unable to execute the system command /usr/bin/R --no-save --silent < "/tmp/RCmd.R.gPKO3y" > /dev/null 2>&1 returned code is 256 Real message error is: $ echo 'library(rotRPackage)' | R --no-save [...] > library(rotRPackage) Error in library(rotRPackage) : package 'rotRPackage' does not have a NAMESPACE and should be re-installed Execution halted According to http://comments.gmane.org/gmane.comp.lang.r.debian/1649 R packages have to be rebuilt against the new R Debian packages, thus rebuilding openturns should just work. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659132: netgen: Please switch from deprecated opencascade to oce
tags 659132 patch
thanks
Hello Adam,
Here is a patch. It looks like netgen is the last package depending
on opencascade, maybe we can get rid of it soon ;)
I am pretty sure that netgen needs only -foundation and -modeling, but
I did not investigate this issue in order to provide a minimal patch.
I had to patch debian/patches/occ-6.5.0.patch because a method has
been renamed between OCCT 6.3.0 and 6.5.0. I added an alias in OCC
Debian packages in order to help upgrades (this is why you did not
notice this breakage), but I do not want to maintain it forever and
dropped it in OCE.
Denis
diff --git a/debian/control b/debian/control
index 2e909b9..59643c7 100644
--- a/debian/control
+++ b/debian/control
@@ -7,9 +7,9 @@ DM-Upload-Allowed: yes
Build-Depends: quilt, cdbs, debhelper (>= 7), autotools-dev, automake, libtool,
g++ (>= 4.0), tcl8.5-dev, tk8.5-dev, tix-dev (>= 8.4.3-2),
docbook-to-man, libxmu-dev, libglu1-mesa-dev,
- libgl1-mesa-dev|nvidia-glx-dev, libopencascade-foundation-dev,
- libopencascade-modeling-dev (>= 6.5.0.dfsg-1), libopencascade-visualization-dev,
- libopencascade-ocaf-dev, libopencascade-ocaf-lite-dev, libtogl-dev (>= 1.7),
+ libgl1-mesa-dev|nvidia-glx-dev, liboce-foundation-dev,
+ liboce-modeling-dev, liboce-visualization-dev,
+ liboce-ocaf-dev, liboce-ocaf-lite-dev, libtogl-dev (>= 1.7),
libswscale-dev, libavformat-dev, libavcodec-dev, libjpeg62-dev, libbz2-dev
Standards-Version: 3.9.1
Vcs-Git: git://git.debian.org/git/debian-science/packages/netgen.git
diff --git a/debian/patches/configure-occ.patch b/debian/patches/configure-occ.patch
index 6313a7a..12df9ad 100644
--- a/debian/patches/configure-occ.patch
+++ b/debian/patches/configure-occ.patch
@@ -9,7 +9,7 @@ Index: netgen/configure.ac
if test a$occon = atrue ; then
- AC_SUBST([OCCFLAGS], ["-DOCCGEOMETRY -I$occdir/inc"])
-+ AC_SUBST([OCCFLAGS], ["-DOCCGEOMETRY -I$occdir/include/opencascade"])
++ AC_SUBST([OCCFLAGS], ["-DOCCGEOMETRY -I$occdir/include/oce"])
AC_SUBST([OCCLIBS], ["-L$occdir/lib -lTKernel -lTKGeomBase -lTKMath -lTKG2d -lTKG3d -lTKXSBase -lTKOffset -lTKFillet -lTKShHealing -lTKMesh -lTKMeshVS -lTKTopAlgo -lTKGeomAlgo -lTKBool -lTKPrim -lTKBO -lTKIGES -lTKBRep -lTKSTEPBase -lTKSTEP -lTKSTL -lTKSTEPAttr -lTKSTEP209 -lTKXDESTEP -lTKXDEIGES -lTKXCAF -lTKLCAF -lFWOSPlugin"])
# -lTKDCAF
diff --git a/debian/patches/occ-6.5.0.patch b/debian/patches/occ-6.5.0.patch
index 3ac30ef..7b23c39 100644
--- a/debian/patches/occ-6.5.0.patch
+++ b/debian/patches/occ-6.5.0.patch
@@ -1,3 +1,16 @@
+Index: netgen/libsrc/occ/Partition_Inter3d.cxx
+===
+--- netgen.orig/libsrc/occ/Partition_Inter3d.cxx 2012-03-03 20:29:19.823206572 +0100
netgen/libsrc/occ/Partition_Inter3d.cxx 2012-03-03 20:29:35.227282960 +0100
+@@ -243,7 +243,7 @@
+ Standard_Integer i, nbExt = anExtPS.NbExt();
+ Extrema_POnSurf aPOnSurf;
+ for (i = 1; i <= nbExt; ++i )
+-if (anExtPS.Value( i ) <= TolE) {
++if (anExtPS.SquareDistance( i ) <= TolE) {
+ aPOnSurf = anExtPS.Point( i );
+ break;
+ }
Index: netgen/libsrc/occ/Partition_Loop2d.cxx
===
--- netgen.orig/libsrc/occ/Partition_Loop2d.cxx
@@ -27,3 +40,16 @@ Index: netgen/libsrc/occ/Partition_Loop2d.cxx
Standard_Real U, f, l;
BRep_Tool::Range (DegEdge, f, l);
+Index: netgen/libsrc/occ/Partition_Spliter.cxx
+===
+--- netgen.orig/libsrc/occ/Partition_Spliter.cxx 2012-03-03 20:29:19.827206593 +0100
netgen/libsrc/occ/Partition_Spliter.cxx 2012-03-03 20:29:35.231282976 +0100
+@@ -1169,7 +1169,7 @@
+ for (; j<=nbj && ok; ++j) {
+ if (Extrema.IsMin(j)) {
+ hasMin = Standard_True;
+- ok = Extrema.Value(j) <= tol;
++ ok = Extrema.SquareDistance(j) <= tol;
+ }
+ }
+ }
Bug#622492: Bug #622492: openturns: Getting rid of unneeded *.la / emptying dependency_libs
tags 622492 patch thanks Hello, Here is a patch. Those .la files are useless and can be dropped, they are a side effect of compiling Python extensions. Christophe, it looks like debian-science SVN repository does not contain your 0.15-* uploads. Denis --- openturns-0.15/debian/rules 2012-03-03 19:51:26.0 +0100 +++ openturns-new/debian/rules 2012-03-03 20:05:30.428118606 +0100 @@ -56,6 +56,7 @@ binary-install/python-openturns:: -rm debian/python-openturns/usr/lib/python$(PYVER)/site-packages/openturns/*.pyc + -rm debian/python-openturns/usr/lib/python$(PYVER)/dist-packages/openturns/*.la -for i in debian/python-openturns/usr/lib/python$(PYVER)/site-packages/openturns/*.so; do \ chrpath -d $$i; \ done
Bug#656838: oce FTBFS on Alpha: Alpha Linux is misdetected as Alpha OSF1 Unix
Le 28 février 2012 00:35, Adam C Powell IV a écrit : > Hello, > > On Mon, 2012-02-27 at 15:45 +0100, D. Barbier wrote: >> Le 27 février 2012 15:24, Adam C Powell IV a écrit : >> > On Sun, 2012-02-26 at 08:54 -0500, Adam C Powell IV wrote: >> > [snip] >> > There are a couple of issues in the git repository though. I >> > accidentally merged pristine-tar into Debian on January 8, and am not >> > sure how to un-merge it, though was able to build in spite of it, sorry >> > about that! >> >> Hello Adam, >> >> Try: >> $ git rebase --onto fd53673 9a7eb41 debian >> $ git diff HEAD origin/debian >> $ >> >> You will have to use the --force command-line flag of git push in >> order to upload this new head. > > Great, I think this worked. Hello, No, your branch still merges pristine-tar. I just uploaded a 'debian-fixed' branch to show how it should look like. It is identical to your 'debian' branch and also 'debian/0.9.1-1' tag, but its history is 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#656838: oce FTBFS on Alpha: Alpha Linux is misdetected as Alpha OSF1 Unix
Le 27 février 2012 15:24, Adam C Powell IV a écrit : > Hi Denis, > > On Sun, 2012-02-26 at 08:54 -0500, Adam C Powell IV wrote: >> On Sun, 2012-02-26 at 09:29 +0100, D. Barbier wrote: >> > Le 26 février 2012 06:29, Adam C Powell IV a écrit : >> > > Would you like me to upload the new oce with this change, or wait for a >> > > new upstream or other changes? >> > >> > Hello Adam, >> > >> > You can upload, yes, but please be aware that: >> > * I did not check packaging (lintian and Standards-Version). >> > * sonames have been bumped. >> >> Okay. Hadn't realized this would be new upstream, that's certainly >> worth uploading. >> >> I'm building now, will see what lintian comes up with. > > It built just fine, and is lintian-clean -- was even able to remove the > old source lintian-overrides with the newest lintian. > > There are a couple of issues in the git repository though. I > accidentally merged pristine-tar into Debian on January 8, and am not > sure how to un-merge it, though was able to build in spite of it, sorry > about that! Hello Adam, Try: $ git rebase --onto fd53673 9a7eb41 debian $ git diff HEAD origin/debian $ You will have to use the --force command-line flag of git push in order to upload this new head. > And the last upstream tag is 0.7.0, can you please merge in the newer > upstream tags? There are normal tags, and not annotated ones, see http://anonscm.debian.org/gitweb/?p=debian-science/packages/oce.git;a=tags Does this cause trouble? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656838: oce FTBFS on Alpha: Alpha Linux is misdetected as Alpha OSF1 Unix
Le 26 février 2012 06:29, Adam C Powell IV a écrit : > Hello Denis, > > Would you like me to upload the new oce with this change, or wait for a > new upstream or other changes? Hello Adam, You can upload, yes, but please be aware that: * I did not check packaging (lintian and Standards-Version). * sonames have been bumped. 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#656838: oce FTBFS on Alpha: Alpha Linux is misdetected as Alpha OSF1 Unix
tags 656838 pending thanks Le 22 janvier 2012 04:37, Michael Cree a écrit : > Source: oce > Version: 0.8.0-1 > Severity: Normal > User: debian-al...@lists.debian.org > Usertags: alpha > X-Debbugs-CC: debian-al...@lists.debian.org > > oce FTBFS on alpha with the error: > > [ 39%] Building CXX object > adm/cmake/TKService/CMakeFiles/TKService.dir/__/__/__/src/MFT/MFT_FontManager.cxx.o > cd > /build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/obj-alpha-linux-gnu/adm/cmake/TKService > && /usr/bin/c++ -DTKService_EXPORTS -D_OCC64 -DHAVE_FTGL_NEWER212 > -DHAVE_CONFIG_H -DCSFDB -DOCC_CONVERT_SIGNALS -DNDEBUG -O3 -DNDEBUG > -fPIC > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/obj-alpha-linux-gnu/build_inc > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/inc > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/AlienImage > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/AlienImage > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/Aspect > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/Aspect > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/CGM > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/CGM > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/Image > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/Image > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/MFT > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/MFT -I/bui > ld/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/PS > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/PS > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/PlotMgt > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/PlotMgt > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/SelectBasics > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/SelectBasics > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/TColQuantity > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/TColQuantity > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/Viewer > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/Viewer > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/ImageUtility > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/ImageUtility > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/Xw > -I/build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/drv/Xw -o > CMakeFiles/TKService.dir/__/__/__/src/MFT/MFT_FontManager.cxx.o -c > /build/buildd-oce_0.8.0-1-alpha- > nfIXQh/oce-0.8.0/src/MFT/MFT_FontManager.cxx > /build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/MFT/MFT_FontManager.cxx: > In static member function 'static Standard_Boolean > MFT_FontManager::Read(MFT_FileRecord&)': > /build/buildd-oce_0.8.0-1-alpha-nfIXQh/oce-0.8.0/src/MFT/MFT_FontManager.cxx:2870:23: > error: 'MAP_VARIABLE' was not declared in this scope > > Full build log is at: > http://buildd.debian-ports.org/status/fetch.php?pkg=oce&arch=alpha&ver=0.8.0-1&stamp=1326555718 > > The build error is caused by a misdetection of Alpha Linux as Alpha OSF1 > Unix in inc/MFT_FileRecord.hxx beginning at line 50 with: > > #if defined ( __alpha ) || ( DECOSF1 ) > #include > #define MMAP(file_addr,mmap_size,fildes) \ > mmap((caddr_t) 0x10,(size_t) mmap_size,PROT_READ, \ > MAP_FILE | MAP_PRIVATE | MAP_VARIABLE,fildes,(off_t) > file_addr) > #define MUNMAP(mmap_addr,mmap_size) \ > munmap((caddr_t) mmap_addr,(size_t) mmap_size) > #endif // __alpha > > The pre-defined compiler macro __alpha is defined if the hardware is > Alpha whatever the OS and so the above code, intended only for OSF1, > gets compiled under Linux. > > Maybe modifying the conditional to be something like: > > #if (defined ( __alpha ) || ( DECOSF1 )) && ! defined( linux ) > > would fix it --- but I don't know what is the appropriate macro to > detect Linux. Hello, Thanks for your report, your patch has been applied in our repository, it should work fine. > I did a quick grep and check of all other defined(__alpha) occurences > and they look fine to me, but did notice issues that might affect other > architectures supported by Debian, that is, the code has the appearance > of being written with the assumption that Linux is Intel only. You may be right, but we did not get any feedback about such issues yet. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#653525: msguntypot: doesn't respect formatting and removes too much
tags 653525 pending
thanks
Le 23 février 2012 17:28, David Prévot a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Denis,
>
> Le 23/02/2012 10:38, D. Barbier a écrit :
>> Le 29 décembre 2011 04:13, David Prévot a écrit :
>> [...]
>>> I also took care of the trivial unfuzzy, using msguntypot (I usually
>>> used the old “manual” sed way), that's a nice tool! ;-). It changes a
>>> bit the formatting (so msgcat is needed after it to minimize the actual
>>> changes in the PO files), and it removes the useless and old strings
>>> from the PO file (maybe this should only be optional). I noticed it
>>> removed a lot of stuff at the end of your PO file, that's why I mention
>>> it: you may wish to restore those from your last r2522 commit.
>
>> I do not use msguntypot, can you please post an example to show what is
>> wrong?
>
> You can run it blank, in po4a source:
>
> $ cd po/pod/
> $ msguntypot -o po4a-pod.pot -n po4a-pod.pot *.po
> Modification de 0 entrées dans 8 fichiers.
>
> Then look at “{svn,git} diff”: the strings are messed up (the msgcat issue).
>
> Fix the msgcat issue:
>
> $ for i in *.po; do msgcat $i | sponge $i; done
>
> And notice that all previous strings at the end of the German file are
> gone (I removed the previous strings of other languages after running
> msguntypot a few time ago, around Christmas according to the bug report).
Fixed in SVN.
By the way, you can run
msgcat -o $i $i
instead of using sponge.
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660953: po4a --translate-only should behave like po4a-translate
tags 660953 pending thanks Le 23 février 2012 17:09, D. Barbier a écrit : > Le 23 février 2012 16:52, David Prévot a écrit : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> retitle 660953 po4a should cope with options after config_file >> thanks >> >> Hi Denis, >> >> Le 23/02/2012 11:28, D. Barbier a écrit : >> >>> Just checked against debian-edu-doc-1.4~20120222~6.0.4~rc2 package, >>> everything works fine >>> $ cd >>> debian-edu-doc-1.4~20120222~6.0.4~rc2/documentation/debian-edu-squeeze >>> $ po4a --translate-only debian-edu-squeeze-manual.fr.xml po4a.cfg >> >> Ho! Silly me! I put the config file name before the option. Thanks a lot >> for spotting my misuse. >> >> I retitled the bug report, since it would be nice if po4a wouldn't mind >> the order of arguments, but feel free to close it if you disagree: it's >> cristal clear looking at the manpage or the output of « po4a --help » >> (that is not translated BTW) that options should be given first. > > This is caused by l.566-567 > # remove the config file > pop @ORIGINAL_ARGV; > > I have to check why this pop has been added. I could not find any good reason and dropped it from SVN repository, thanks for your report. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660953: po4a --translate-only should behave like po4a-translate
Le 23 février 2012 16:52, David Prévot a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > retitle 660953 po4a should cope with options after config_file > thanks > > Hi Denis, > > Le 23/02/2012 11:28, D. Barbier a écrit : > >> Just checked against debian-edu-doc-1.4~20120222~6.0.4~rc2 package, >> everything works fine >> $ cd debian-edu-doc-1.4~20120222~6.0.4~rc2/documentation/debian-edu-squeeze >> $ po4a --translate-only debian-edu-squeeze-manual.fr.xml po4a.cfg > > Ho! Silly me! I put the config file name before the option. Thanks a lot > for spotting my misuse. > > I retitled the bug report, since it would be nice if po4a wouldn't mind > the order of arguments, but feel free to close it if you disagree: it's > cristal clear looking at the manpage or the output of « po4a --help » > (that is not translated BTW) that options should be given first. This is caused by l.566-567 # remove the config file pop @ORIGINAL_ARGV; I have to check why this pop has been added. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606387: po4a: XML module: please include docbook comments in po/pot
Le 8 décembre 2010 21:19, Simon Paillard a écrit :
> Package: po4a
> Severity: wishlist
>
> As mentionned by helix below, that would be great that po4a supports using
> Docbook xml comments as po/pot comments.
>
> On Wed, Dec 08, 2010 at 02:14:48PM +0100, helix84 wrote:
>> On Wed, Dec 8, 2010 at 13:20, Osamu Aoki wrote:
>> > You are right. It now generates only:
>> >
>> > #. type: Attribute 'lang' of:
>> > #. type: Attribute 'lang' of:
>> > #: entries.dbk:4
>> >
>> > So what is needed is parser to record comments and output routine to
>> > generate following and reset such record to null.
>> >
>> > XML INPUT:
>> >
>> > baz
>> > bar
>> >
>> > PO OUTPUT:
>> > #. SGML_comment: foo
>> > #. DocBok_comment: baz
>> > msgid "bar"
>> > msgstr ""
>> >
>> > That will be nice :-)
>>
>> Yes, that's how it should work. The code that outputs the current code
>> in package po4a is in
>> lib/Locale/Po4a/Xml.pm
>> under
>> sub found_string {
>>
>> Unfortunately, I don't speak Perl very much, so adding this feature is
>> not very simple for me.
>
> Wishlist against po4a.
Hello,
This cannot be done easily, but on the other hand, one can write:
bar
Denis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660953: po4a --translate-only should behave like po4a-translate
Le 23 février 2012 05:15, David Prévot a écrit : > Package: po4a > Version: 0.41-1 > Severity: wishlist > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > In debian-edu-doc, I noticed that: > > po4a po4a.cfg --translate-only $(name).$(LINGUA).xml > > doesn't work: > > po4a::xml: Tag '' both in the translated and > untranslated categories. > > while the long form (with po4a-translate) works as expected: > > po4a-translate -o nodefault=' ' \ > -o untranslated=' ' \ > -M UTF-8 -k 5 -f docbook -m $(name).xml \ > -p $(name).$(LINGUA).po -l $(name).$(LINGUA).xml > > The related trivial po4a.cfg is attached. Just checked against debian-edu-doc-1.4~20120222~6.0.4~rc2 package, everything works fine $ cd debian-edu-doc-1.4~20120222~6.0.4~rc2/documentation/debian-edu-squeeze $ po4a --translate-only debian-edu-squeeze-manual.fr.xml po4a.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#653525: msguntypot: doesn't respect formatting and removes too much
Le 29 décembre 2011 04:13, David Prévot a écrit : [...] > I also took care of the trivial unfuzzy, using msguntypot (I usually > used the old “manual” sed way), that's a nice tool! ;-). It changes a > bit the formatting (so msgcat is needed after it to minimize the actual > changes in the PO files), and it removes the useless and old strings > from the PO file (maybe this should only be optional). I noticed it > removed a lot of stuff at the end of your PO file, that's why I mention > it: you may wish to restore those from your last r2522 commit. Hello David, I do not use msguntypot, can you please post an example to show what is wrong? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646173: Typos found while translating the po4a documentation into German
Le 7 février 2012 19:55, Helge Kreutzmann a écrit : > Hello David, > On Mon, Feb 06, 2012 at 08:15:37PM -0400, David Prévot wrote: >> Please, no need to CC me or the po4a-devel list when replying to the bug >> report. > > Ok. The CC to the list should not have worked as discussed anyway. > >> Le 01/01/2012 12:24, Helge Kreutzmann a écrit : >> > -So, when the same paragraph appears twice in the original but are not >> > +So, when the same paragraph appears twice in the original but both are not >> > translated in the exact same way each time, you will get the feeling that >> > a >> > paragraph of the original disappeared. Just kill the new translation. If >> > you >> > prefer to kill the first translation instead when it was actually better, >> > -remove the second one from where it is and put it in place of the first >> > one. >> > +remove the second one from where it is and put the first one in place of >> > the second one. >> >> The sense is not the same (it's even the contrary), and I don't think >> your proposal is accurate. > > Well, then I don't understand the sentence. I just wanted to clarify > the "it". So if I understand you correctly, it should read. > remove the second one from where it is and put the second one in the > place of the first one Hallo Helge, Consider this example: foo.en.txt contains foo bar foo and foo.fr.txt contains tata titi toto There can be only one msgid "foo" in the gettextized PO file, but two different msgstr are provided. The paragraph tries to explain that you can replace (in foo.fr.txt) toto by tata if you want to keep the first translaton, or tata by toto if you prefer the second. This paragraph is easier to understand if you read it within its full context - Sometimes, you get the strong feeling that po4a ate some parts of the text, either the original or the translation. gettextization.failed.po indicates that both of them where gently matching, and then the gettextization fails because it tried to match one paragraph with the one after (or before) the right one, as if the right one disappeared. Curse po4a as I did when it first happened to me. Generously. This unfortunate situation happens when the same paragraph is repeated over the document. In that case, no new entry is created in the PO file, but a new reference is added to the existing one instead. So, when the same paragraph appears twice in the original but are not translated in the exact same way each time, you will get the feeling that a paragraph of the original disappeared. Just kill the new translation. If you prefer to kill the first translation instead when it was actually better, remove the second one from where it is and put it in place of the first one. The author explains that one has to edit files (original and translation) until msgid and msgstr match. The problem is that this description makes sense only when you face this problem for real, otherwise it looks way too abstract. Moreover in such a case, po4a-gettextize will not complain and generate something like: #. type: Plain text #: foo.en.txt:2 foo.en.txt:5 #, fuzzy msgid "foo" msgstr "" "#-#-#-#-# foo.fr.txt:2 #-#-#-#-#\n" "tata\n" "#-#-#-#-# foo.fr.txt:5 #-#-#-#-#\n" "toto" Thus I wonder whether this piece of advice is still accurate, maybe it would be better to drop it entirely. 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:
tags 584300 - moreinfo + patch
thanks
2011/12/8 Mathieu Malaterre :
> Denis,
>
> Do you think you can update your patch for VTK 5.8.0 ?
Hello Mathieu,
Here it is. I checked that vtk builds fine, but did not try this time
to use the generated packages; it should work since I did test it last
time, but have no time just now to check.
Denis
commit e5dd0bdc11f7cbbea5f126b5c4c99745b8733078
Author: Denis Barbier
Date: Fri Dec 16 12:44:10 2011 +0100
Remove information about wrapped languages from VTKConfig.cmake
The file /usr/lib/vtk-5.8/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, tcl-vtk
and libvtk-java.
diff --git a/VTKConfig-Java.cmake.in b/VTKConfig-Java.cmake.in
new file mode 100644
index 000..30f01b5
--- /dev/null
+++ b/VTKConfig-Java.cmake.in
@@ -0,0 +1,14 @@
+# The list of available languages.
+SET(VTK_LANGUAGES ${VTK_LANGUAGES} JAVA)
+
+SET(VTK_WRAP_JAVA 1)
+
+# The Java configuration.
+SET(VTK_JAVA_JAR "@VTK_JAVA_JAR_CONFIG@")
+SET(VTK_PARSE_JAVA_EXE "@VTK_PARSE_JAVA_EXE_CONFIG@")
+SET(VTK_WRAP_JAVA_EXE "@VTK_WRAP_JAVA_EXE_CONFIG@")
+SET(VTK_JAVA_INCLUDE_DIR "@JAVA_INCLUDE_PATH@;@JAVA_INCLUDE_PATH2@")
+SET(VTK_JAVA_AWT_LIBRARY "@JAVA_AWT_LIBRARY@")
+SET(VTK_JVM_LIBRARY "@JAVA_JVM_LIBRARY@")
+
+
diff --git a/VTKConfig-Python.cmake.in b/VTKConfig-Python.cmake.in
new file mode 100644
index 000..2b4e259
--- /dev/null
+++ b/VTKConfig-Python.cmake.in
@@ -0,0 +1,14 @@
+# The list of available languages.
+SET(VTK_LANGUAGES ${VTK_LANGUAGES} PYTHON)
+
+SET(VTK_WRAP_PYTHON 1)
+
+# The Python configuration.
+# If VTK_CONFIGURATION_TYPES is set (see below) then the VTK_PYTHONPATH_DIRS
+# will have subdirectories for each configuration type.
+SET(VTK_PYTHONPATH_DIRS "@VTK_PYTHONPATH_DIRS_CONFIG@")
+SET(VTK_WRAP_PYTHON_EXE "@VTK_WRAP_PYTHON_EXE_CONFIG@")
+SET(VTK_WRAP_PYTHON_INIT_EXE "@VTK_WRAP_PYTHON_INIT_EXE_CONFIG@")
+SET(VTK_PYTHON_INCLUDE_DIR "@PYTHON_INCLUDE_DIR@")
+SET(VTK_PYTHON_LIBRARY "@PYTHON_LIBRARY@")
+
diff --git a/VTKConfig-Tcl.cmake.in b/VTKConfig-Tcl.cmake.in
new file mode 100644
index 000..fedf000
--- /dev/null
+++ b/VTKConfig-Tcl.cmake.in
@@ -0,0 +1,21 @@
+# The list of available languages.
+SET(VTK_LANGUAGES ${VTK_LANGUAGES} TCL)
+
+SET(VTK_WRAP_TCL 1)
+
+# The Tcl/Tk configuration.
+SET(VTK_TCL_TK_STATIC "@VTK_TCL_TK_STATIC@")
+SET(VTK_TCL_TK_COPY_SUPPORT_LIBRARY "@VTK_TCL_TK_COPY_SUPPORT_LIBRARY@")
+SET(VTK_TCL_SUPPORT_LIBRARY_PATH "@VTK_TCL_SUPPORT_LIBRARY_PATH_CONFIG@")
+SET(VTK_TK_SUPPORT_LIBRARY_PATH "@VTK_TK_SUPPORT_LIBRARY_PATH_CONFIG@")
+SET(VTK_TCL_TK_MACROS_MODULE "@VTK_TCL_TK_MACROS_MODULE_CONFIG@")
+SET(VTK_TCL_HOME "@VTK_TCL_HOME_CONFIG@")
+SET(VTK_WRAP_TCL_EXE "@VTK_WRAP_TCL_EXE_CONFIG@")
+SET(VTK_WRAP_TCL_INIT_EXE "@VTK_WRAP_TCL_INIT_EXE_CONFIG@")
+SET(VTK_TK_INTERNAL_DIR "@VTK_TK_INTERNAL_DIR_CONFIG@")
+SET(VTK_TK_RESOURCES_DIR "@VTK_TK_RESOURCES_DIR_CONFIG@")
+SET(VTK_TCL_INCLUDE_DIR "@TCL_INCLUDE_PATH@")
+SET(VTK_TCL_LIBRARY "@TCL_LIBRARY@")
+SET(VTK_TK_INCLUDE_DIR "@TK_INCLUDE_PATH@")
+SET(VTK_TK_LIBRARY "@TK_LIBRARY@")
+
diff --git a/VTKConfig.cmake.in b/VTKConfig.cmake.in
index 6aa6e77..ff52a5c 100644
--- a/VTKConfig.cmake.in
+++ b/VTKConfig.cmake.in
@@ -64,7 +64,7 @@ SET(VTK_CMAKE_EXTENSIONS_DIR "@VTK_CMAKE_EXTENSIONS_DIR_CONFIG@")
SET(VTK_KITS "@VTK_KITS@")
# The list of available languages.
-SET(VTK_LANGUAGES "@VTK_LANGUAGES@")
+SET(VTK_LANGUAGES "")
# VTK Configuration options.
SET(VTK_BUILD_SHARED_LIBS "@BUILD_SHARED_LIBS@")
@@ -110,10 +110,16 @@ SET(VTK_USE_VIDEO_FOR_WINDOWS "@VTK_USE_VIDEO_FOR_WINDOWS@")
SET(VTK_USE_VIEWS "@VTK_USE_VIEWS@")
SET(VTK_USE_VOLUMEPRO_1000 "@VTK_USE_VOLUMEPRO_1000@")
SET(VTK_USE_X "@VTK_USE_X@")
-SET(VTK_WRAP_JAVA "@VTK_WRAP_JAVA@")
-SET(VTK_WRAP_PYTHON "@VTK_WRAP_PYTHON@")
-SET(VTK_WRAP_TCL "@VTK_WRAP_TCL@")
-SET(VTK_WRAP_PYTHON_SIP "@VTK_WRAP_PYTHON_SIP@")
+
+SET(VTK_WRAP_JAVA 0)
+SET(VTK_WRAP_PYTHON 0)
+SET(VTK_WRAP_TCL 0)
+SET(VTK_WRAP_PYTHON_SIP 0)
+
+INCLUDE("${VTK_DIR}/VTKConfig-Java.cmake" OPTIONAL)
+INCLUDE("${VTK_DIR}/VTKConfig-Python.cmake" OPTIONAL)
+INCLUDE("${VTK_DIR}/VTKConfig-Tcl.cmake" OPTIONAL)
+# Python_sip is not provided by Debian packages
# The Hybrid and VolumeRendering kits are now switched with Rendering.
SET(VTK_USE_HYBRID "@VTK_USE_RENDERING@")
@@ -133,44 +139,11 @@ SET(VTK_MPI_SERVER_PREFLAGS "@VTK_MPI_SERVER_PREFLAGS_CONFIG@")
SET(VTK_MPI_INCLUDE_DIR "@MPI_INCLUDE_PATH@")
SET(VTK_MPI_LIBRARIES "@MPI_LIBRARY@;@MPI_EXTRA_LIBRARY@")
-# The Tcl/Tk configuration.
-SET(VTK_TCL_TK_STATIC "@VTK_TCL_TK_STATIC@")
-SET(VTK_TCL_TK_COPY_SUPPORT_LIBRARY "@VTK_TCL_TK_COPY_SUPPORT_LIBRARY@")
-SET(VTK_TCL_SUPPORT_LIBRARY_PATH "@VTK_TCL_SUPPORT_LIBRARY_PATH_CONFIG@")
-SET
Bug#644943: Please switch source package to OCE
On 2011/11/21 D. Barbier wrote: > On 2011/11/21 Adam C Powell IV: >> Hi Denis, >> >> On Thu, 2011-11-17 at 07:49 +0100, D. Barbier wrote: >>> Thanks Adam for your upload. >> >> You're welcome, sorry it took so long. >> >> There's a problem with the package copyright, see the attached. I think >> this will only require a simple patch to debian/copyright, and can get >> to it in a couple of days. > > Indeed, I forgot about those new files. We also added > src/OSD/gettime_osx.h (BSD3), that should be all. Hello Adam, I updated debian/copyright, can you please check and upload? 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#644943: Please switch source package to OCE
On 2011/11/21 Adam C Powell IV : > Hi Denis, > > On Thu, 2011-11-17 at 07:49 +0100, D. Barbier wrote: >> Thanks Adam for your upload. > > You're welcome, sorry it took so long. > > There's a problem with the package copyright, see the attached. I think > this will only require a simple patch to debian/copyright, and can get > to it in a couple of days. Indeed, I forgot about those new files. We also added src/OSD/gettime_osx.h (BSD3), that should be all. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644943: Please switch source package to OCE
Thanks Adam for your upload. After it enters unstable, I will take care of providing patches for packages Build-Depending on opencascade; this may not be necessary, our OCE team already sent patches to various upstreams. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644943: Please switch source package to OCE
On 2011/11/13 Adam C Powell IV wrote: [...] > But can't seem to be able to push my one change: > > $ git push --all origin > Enter passphrase for key '/home/hazelsct/.ssh/id_rsa': > Counting objects: 7, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (4/4), done. > Writing objects: 100% (4/4), 428 bytes, done. > Total 4 (delta 3), reused 0 (delta 0) > error: unable to create temporary sha1 filename ./objects/ea: Read-only file > system > > fatal: failed to write object > error: unpack failed: unpack-objects abnormal exit > To git+ssh://anonscm.debian.org/git/debian-science/packages/oce.git > ! [remote rejected] debian -> debian (n/a (unpacker error)) > error: failed to push some refs to > 'git+ssh://anonscm.debian.org/git/debian-science/packages/oce.git' I do not remember about Alioth setup, but http://anonscm.debian.org/gitweb/?p=debian-science/packages/oce.git;a=summary tells to use git+ssh://git.debian.org/git/debian-science/packages/oce.git and indeed I have ssh://barbier-gu...@git.debian.org/git/debian-science/packages/oce.git in my .git/config and this works. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644943: Please switch source package to OCE
On 2011/11/13 Adam C Powell IV : [...] > I know, I used pristine-tar to generate .orig.tar.gz for my build. But > as a formality, when sponsoring or otherwise uploading packages, I like > to verify that it's the same as what comes from upstream, which is still > not working. Okay, I do not know what is wrong, it works for me: at https://github.com/tpaviot/oce/tags when mouse is over 0.7.0, there is a tar.gz link which points to https://github.com/tpaviot/oce/tarball/OCE-0.7.0 My browser can download it (it saves it under the name tpaviot-oce-OCE-0.7.0-0-ga384024.tar.gz), or $ wget https://github.com/tpaviot/oce/tarball/OCE-0.7.0 --2011-11-13 17:47:34-- https://github.com/tpaviot/oce/tarball/OCE-0.7.0 Resolving github.com (github.com)... 207.97.227.239 Connecting to github.com (github.com)|207.97.227.239|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://nodeload.github.com/tpaviot/oce/tarball/OCE-0.7.0 [following] --2011-11-13 17:47:36-- https://nodeload.github.com/tpaviot/oce/tarball/OCE-0.7.0 Resolving nodeload.github.com (nodeload.github.com)... 207.97.227.252 Connecting to nodeload.github.com (nodeload.github.com)|207.97.227.252|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 22763046 (22M) [application/octet-stream] Saving to: `OCE-0.7.0' 2011-11-13 17:48:25 (460 KB/s) - `OCE-0.7.0' saved [22763046/22763046] Maybe your /tmp is full? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644943: Please switch source package to OCE
On 2011/11/11 Adam C Powell IV wrote: > On Fri, 2011-11-11 at 07:51 -0500, Adam C Powell IV wrote: >> On Thu, 2011-11-10 at 23:57 +0100, D. Barbier wrote: >> > On 2011/11/5 D. Barbier wrote: >> > [...] >> > > Hello again, >> > > >> > > Current master looks good to me, it can IMO be uploaded. >> > > There is a pristine-tar branch, one can run >> > > pristine-tar checkout ../oce_0.7.0.orig.tar.gz >> > > to generate upstream tarball. >> > >> > ping? >> >> Sorry, busy week at work. Started to get to it yesterday, should be >> able to report back to you later today. > > Hi Denis, > > I'm having trouble downloading the tarball from upstream, I get an error > "/tmp/mphB79b0.bin.part could not be saved, because the source file > could not be read. Try again later, or contact the server > administrator." Hi Adam, You do not have to download upstream tarball; as said above you can run pristine-tar checkout ../oce_0.7.0.orig.tar.gz It is strictly identical to tpaviot-oce-OCE-0.7.0-0-ga384024.tar.gz > When I get that, I'll finish verifying the source package. Great, thanks a lot! Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644943: Please switch source package to OCE
On 2011/11/5 D. Barbier wrote: [...] > Hello again, > > Current master looks good to me, it can IMO be uploaded. > There is a pristine-tar branch, one can run > pristine-tar checkout ../oce_0.7.0.orig.tar.gz > to generate upstream tarball. ping? Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644943: Please switch source package to OCE
On 2011/11/5 D. Barbier wrote: > On 2011/11/4 Adam C Powell IV wrote: > [...] >> I went ahead and did this: >> git://git.debian.org/git/debian-science/packages/oce.git >> >>> BTW please do not use the Downloads direct link, this will create a >>> tar.gz based on current master, which is different from latest >>> release. Instead, use Tags to download 0.7.0.tar.gz: >>> https://github.com/tpaviot/oce/tarball/OCE-0.7.0 >>> Unless I am mistaken, it can be renamed into .orig.tar.gz, all >>> non-DFSG stuff has been dropped. >> >> Great, I just left it empty for now, feel free to push stuff into it. > > It is now populated. I did not test it yet, but it should be almost usable. Hello again, Current master looks good to me, it can IMO be uploaded. There is a pristine-tar branch, one can run pristine-tar checkout ../oce_0.7.0.orig.tar.gz to generate upstream 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#644943: Please switch source package to OCE
On 2011/11/4 Adam C Powell IV wrote: [...] > I went ahead and did this: > git://git.debian.org/git/debian-science/packages/oce.git > >> BTW please do not use the Downloads direct link, this will create a >> tar.gz based on current master, which is different from latest >> release. Instead, use Tags to download 0.7.0.tar.gz: >> https://github.com/tpaviot/oce/tarball/OCE-0.7.0 >> Unless I am mistaken, it can be renamed into .orig.tar.gz, all >> non-DFSG stuff has been dropped. > > Great, I just left it empty for now, feel free to push stuff into it. It is now populated. I did not test it yet, but it should be almost 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#644943: Please switch source package to OCE
On 2011/11/2 Adam C Powell IV wrote: > On Wed, 2011-11-02 at 14:58 +0100, D. Barbier wrote: >> On 2011/11/1 D. Barbier wrote: >> > On 2011/11/1 Adam C Powell IV wrote: >> [...] >> >> That's a good question. I could go either way: >> >> 1. tart a brand new repository, since it's a new package with new >> >> names -- but then start with a new changelog; or >> >> 2. Use the oce tarball as a new "upstream" on a renamed or cloned >> >> repository, or a branch, to more clearly show the changes >> >> between OCC and OCE. >> >> >> >> I think #1 makes more sense, particularly because it's perfectly easy >> >> for someone to "diff -ur" the two trees and see the changes, and we >> >> aren't trying to track patch-by-patch changes -- that's OCE upstream's >> >> job. We can leave opencascade.git in place, and start a new oce.git in >> >> the same place. >> > >> > Great, I also prefer #1. Can you please request its creation? (I can >> > also do it if you prefer) >> > Are there some guidelines about the preferred git workflow when >> > upstream has a git repository? >> >> Hi again, >> >> I just found >> http://debian-science.alioth.debian.org/debian-science-policy.html >> http://lists.debian.org/debian-science/2008/05/msg00118.html >> Adam, can you please run the commands given in the 2nd link in order >> to create oce.git repository on Alioth? > > It's funny you mention that, I use that exact email from Teemu, which is > flagged in my local client, every time I make a new Alioth > repository. :-) > > I have a tight schedule today, but should be able to do this tomorrow. Great; you can create an empty repository if you have no time, I will push contents. BTW please do not use the Downloads direct link, this will create a tar.gz based on current master, which is different from latest release. Instead, use Tags to download 0.7.0.tar.gz: https://github.com/tpaviot/oce/tarball/OCE-0.7.0 Unless I am mistaken, it can be renamed into .orig.tar.gz, all non-DFSG stuff has been dropped. Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
