Bug#669478: illuminator: FTBFS: build-dependency not installable: libpetsc3.1-dev
On Thu, 2012-04-19 at 21:35 +0200, Lucas Nussbaum wrote: Source: illuminator Version: 0.11.0-13 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20120419 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: ┌──┐ │ Install illuminator build dependencies (apt-based resolver) │ └──┘ Installing build dependencies Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: sbuild-build-depends-illuminator-dummy : Depends: libpetsc3.1-dev but it is not installable E: Unable to correct problems, you have held broken packages. apt-get failed. Indeed. PETSc changed its distributed array interface completely with version 3.2, I likely won't have time to port it for some time. Illuminator may need to leave Debian. :-( -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#659898: coinor-ipopt: FTBFS during doxygen latex step
On Tue, 2012-02-28 at 09:31 -0500, Roberto C. Sánchez wrote: On Mon, Feb 27, 2012 at 05:51:14PM -0500, Adam C Powell IV wrote: On Mon, 2012-02-27 at 21:05 +0100, trophime wrote: Hi, with the following patches the package builds fine. Thanks very much Christophe! This is incredibly helpful. Roberto, can you take care of applying these patches and uploading, or do you want me to do an NMU? This is holding up a pretty big transition. Hi Adam. My apologies for the delay. I missed this bug report when it was initially filed. I only just saw it late on Friday. I will have an upload later today. No problem, thanks very much! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#659898: coinor-ipopt: FTBFS during doxygen latex step
On Mon, 2012-02-27 at 21:05 +0100, trophime wrote: Hi, with the following patches the package builds fine. Thanks very much Christophe! This is incredibly helpful. Roberto, can you take care of applying these patches and uploading, or do you want me to do an NMU? This is holding up a pretty big transition. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#661301: src:med-fichier: FTBFS due to hdf5-tools conflict with libhdf5-mpi-dev
Package: src:med-fichier Version: 3.0.3-3 Severity: serious This requires hdf5-tools and libhdf5-mpi-dev to build, but they conflict because they depend on conflicting HDF5 shared library packages. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#659898: coinor-ipopt: FTBFS during doxygen latex step
Package: src:coinor-ipopt
Version: 3.10.1-1
Severity: serious
When I try to build this package, it FTBFS in latex while making doxygen
docs:
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
entering extended mode
(./_formulas.tex
LaTeX2e 2009/09/24
Babel v3.8l and hyphenation patterns for english, usenglishmax, dumylang,
nohyphenation, loaded.
(/usr/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo))
(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty
(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/etc/texmf/tex/latex/config/graphics.cfg)
(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def
No file _formulas.aux.
! Undefined control sequence.
l.5 ...t[\begin{array}{c}f\\g\end{array}\right]$\f
y will be stored in g at ...
?
The problem seems to be in lines 36-47 of
Ipopt/contrib/sIPOPT/src/SensDenseGenSchurDriver.hpp :
* \f$\left[\begin{array}{c|c}
* K E\\\hline
* E^T 0
* \end{array}
* \right]
* \left[\begin{array}{c}x\\y\end{array}\right] =
* \left[\begin{array}{c}f\\g\end{array}\right]$\f
*
* y will be stored in g at exit.
* Kf should hold
*
* \f$K^{-1}f$\f
Does a new version of doxygen/latex not parse this properly?
Also, this is called even when building with dpkg-buildpackage -B, which
is only supposed to build the arch-dependent packages, and probably
shouldn't be building documentation.
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Bug#659190: libelmer-dev: fails to upgrade from squeeze - trying to overwrite /usr/bin/elmerf90
Hi again, On Thu, 2012-02-09 at 22:30 +0100, Andreas Beckmann wrote: On 2012-02-09 22:25, Adam C Powell IV wrote: One thing though: do you mind if we downgrade the severity temporarily? There's a big transition about to happen [...] Adjust as you need it ... Turns out I'm wrong: elmerfem isn't in testing, so it doesn't need to be part of the transition. I'll fix it in the next day or two. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#659245: deal.ii: FTBFS with PETSc/SLEPc 3.2
Package: src:deal.ii Version: 7.0.0-3 Severity: serious This needs an upgrade for PETSc/SLEPc 3.2. 7.1.0 is almost there, but the version in alioth doesn't quite work with the new SLEPc interface. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#659245: deal.ii: FTBFS with PETSc/SLEPc 3.2
Hi Christophe, On Thu, 2012-02-09 at 16:01 +0100, trophime wrote: On Thu, 2012-02-09 at 09:25 -0500, Adam C Powell IV wrote: Package: src:deal.ii Version: 7.0.0-3 Severity: serious This needs an upgrade for PETSc/SLEPc 3.2. 7.1.0 is almost there, but the version in alioth doesn't quite work with the new SLEPc interface. Hi Adam, just tried to build 7.10 from alioth but It fails to build tohe orig.tar.gz: fatal: Not a valid object name upstream/7.1.0 Sorry, I forgot to push the tag, it's there now. You can get the .orig.tar.gz at http://lyre.mit.edu/~powell/deal.ii/ Feel free to complete the PETSc/SLEPc 3.2 port and upload, it won't affect the PETSc HDF5 etc. transition because deal.ii is not in testing right now. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#617613: FreeCAD OCTPL
On Sun, 2012-01-08 at 12:05 +0100, Juergen Riegel wrote: Hi together, I'm, together with Werner, the maintainer of FreeCAD. Based on the long history of license struggle with OCTPL I do not think they will change the license soon. So I decided to go for GPL free for the 0.13 release of FreeCAD. Fortunately Kongsberg, the company behind Coin3D, send a letter to all its paying customer that they decided to discontinue the commercial Version and plan to release the source under BSD. This switch and the removal of smaller libs (e.g. PyQt) will remove all GPL dependencies of FreeCAD. Wow, that's terrific news! Unfortunately we have to wait for the Coin switch. But there is a solution to this problem! Indeed. So we will have FreeCAD in Debian at last. Thanks Juergen! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#652061: elmerfem: FTBFS missing build-dependencvy?
found 652061 6.1.0.svn.5396.dfsg-4 reopen 652264 thanks Hi Sylvestre, The bug persists on mips(el?) and s390, but not on sparc. I wonder if the problem is related to bug 653616: -lmpich is not sufficient to build with MPICH2 because those libraries are not linked to libs whose symbols they need. ScaLAPACK works around this by explicitly linking to all of the MPICH2 libraries, and its dependencies (MUMPS, PETSc etc.) inherit this linkage so they don't break. To test I'll need to log into an s390 or mips test machine at some point... -Adam On Sat, 2012-01-07 at 11:54 -0800, Adam C Powell IV wrote: tags 652061 pending thanks On Thu, 2012-01-05 at 12:11 +0100, Jakub Wilk wrote: * Christoph Egger christ...@debian.org, 2011-12-14, 16:01: Your package failed to build on the buildds: checking for dseupd_ in -larpack... yes configure: WARNING: No parallel arpack found. checking for pdneupd_ in -lparpack... no checking for HYPRE_IJMatrixCreate in -lHYPRE_IJ_mv... yes checking for dmumps_ in -ldmumps_scotch... yes checking for umfpack_di_defaults in -lumfpack... yes checking for mtc_init in -lmatc... yes configure: error: The MPI version needs parpack. Disabling MPI. checking for main in -lm... yes make: *** [stamp-build] Error 1 Now that #652264 is fixed, the package was built successfully on most architectures. However, it still FTBFS (with the same error message) on mips* and s390: https://buildd.debian.org/status/fetch.php?pkg=elmerfemarch=mipsver=6.1.0.svn.5396.dfsg-3stamp=1325724137 https://buildd.debian.org/status/fetch.php?pkg=elmerfemarch=mipselver=6.1.0.svn.5396.dfsg-3stamp=1325723573 https://buildd.debian.org/status/fetch.php?pkg=elmerfemarch=s390ver=6.1.0.svn.5396.dfsg-3stamp=1325730212 Indeed. I just realized there's a new libparpack2-dev package, added that to the Elmer Build-Depends (it's fixed in alioth) and it should work when I upload -- when I have some free bandwidth. Sorry, should have realized that when this bug was first filed. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#652061: elmerfem: FTBFS missing build-dependencvy?
tags 652061 pending thanks On Thu, 2012-01-05 at 12:11 +0100, Jakub Wilk wrote: * Christoph Egger christ...@debian.org, 2011-12-14, 16:01: Your package failed to build on the buildds: checking for dseupd_ in -larpack... yes configure: WARNING: No parallel arpack found. checking for pdneupd_ in -lparpack... no checking for HYPRE_IJMatrixCreate in -lHYPRE_IJ_mv... yes checking for dmumps_ in -ldmumps_scotch... yes checking for umfpack_di_defaults in -lumfpack... yes checking for mtc_init in -lmatc... yes configure: error: The MPI version needs parpack. Disabling MPI. checking for main in -lm... yes make: *** [stamp-build] Error 1 Now that #652264 is fixed, the package was built successfully on most architectures. However, it still FTBFS (with the same error message) on mips* and s390: https://buildd.debian.org/status/fetch.php?pkg=elmerfemarch=mipsver=6.1.0.svn.5396.dfsg-3stamp=1325724137 https://buildd.debian.org/status/fetch.php?pkg=elmerfemarch=mipselver=6.1.0.svn.5396.dfsg-3stamp=1325723573 https://buildd.debian.org/status/fetch.php?pkg=elmerfemarch=s390ver=6.1.0.svn.5396.dfsg-3stamp=1325730212 Indeed. I just realized there's a new libparpack2-dev package, added that to the Elmer Build-Depends (it's fixed in alioth) and it should work when I upload -- when I have some free bandwidth. Sorry, should have realized that when this bug was first filed. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#653610: scalapack: FTBFS on mips(el) and s390
Thanks Muammar, it looks like everything worked and it built everywhere, except s390x which is waiting for a fix to PVM. I uploaded the new MUMPS, PETSc will go in as soon as MUMPS is ready. Thanks again! -Adam On Thu, 2011-12-29 at 20:39 +0100, Muammar El Khatib wrote: Source: scalapack Followup-For: Bug #653610 Hi Adam, Thanks again for all your help. I am building the package right now and then proceed to upload it. So, in an ½hour will be uploaded. Regards, -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-rc4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#653610: scalapack: FTBFS on mips(el) and s390
Package: src:scalapack
Severity: serious
Tags: patch
Hi Muammar,
I'm afraid scalapack FTBFS again on three platforms. On all three the
failure mechanism is the same: libmpich2.so is not linked to libmpl.so .
The workaround is in the attached patch: if you explicitly link -lmpich
-lmpl it should work.
I'm also filing a bug against mpich2 which should have libmpich.so link
to libmpl.so .
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
--- scalapack-1.8.0/debian/rules~ 2011-12-28 17:17:32.0 -0500
+++ scalapack-1.8.0/debian/rules 2011-12-29 14:09:39.0 -0500
@@ -184,7 +184,7 @@
ar x ../$${i}_mpich2.a ;\
cd .. ;\
gcc -shared -Wl,-soname=lib$$i-mpich2.so.$(version_major) -o \
- lib$$i-mpich2.so.$(version) tmp/*.o -lblas -llapack -lblacsCinit-mpich2 -lblacs-mpich2 -lmpich -lgfortran;\
+ lib$$i-mpich2.so.$(version) tmp/*.o -lblas -llapack -lblacsCinit-mpich2 -lblacs-mpich2 -lmpich -lmpl -lgfortran;\
ln -snf lib$$i-mpich2.so.$(version) lib$$i-mpich2.so.$(version_major) ;\
ln -snf lib$$i-mpich2.so.$(version_major) lib$$i-mpich2.so ;\
rm tmp/* ;\
signature.asc
Description: This is a digitally signed message part
Bug#650804: Bug#652313: Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
On Fri, 2011-12-23 at 20:50 +0100, Muammar El Khatib wrote: Hi Adam, On Fri, Dec 23, 2011 at 14:41, Adam C Powell IV hazel...@debian.org wrote: Hi Muammar, On Fri, 2011-12-23 at 11:59 +0100, Muammar El Khatib wrote: On Thu, Dec 22, 2011 at 23:28, Adam C Powell IV hazel...@debian.org wrote: tags 652313 patch thanks On Wed, 2011-12-21 at 13:23 -0500, Adam C Powell IV wrote: retitle 652313 Needs mpich2 targets in debian/rules block 652313 by 652312 thanks I have read the thread of this report. I'll proceed to upload blacs-mpi today, so that it gets built with the mpi-defaults = 1.0 as pointed out herein, and then proceed with scalapack. Tell me if I can go ahead, or if you have already taken any action and thus I don't interfere with it. I'm not doing anything. If you upload blacs-mpi, the upload should close 652312 and 650804 with out any changes. OK, I'll do it in some minutes. I am building it, for a next upload I'll change from format 1.0 to 3.0. Excellent, thanks, it is now built everywhere, and uploaded and installed on all platforms except PPC. Let me know when you fix and upload ScaLAPACK, and after that builds and installs I'll re-upload the fixed MUMPS. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#652313: Needs mpich2 targets in debian/rules
Hi Muammar, Reducing the recipients list as this concerns technical details. On Sun, 2011-12-25 at 20:31 +0100, Muammar El Khatib wrote: Source: scalapack Followup-For: Bug #652313 Hi, I have prepared a new revision of scalapack, but I have a doubt which is: do I have to provide a new binary package (e.g. libscalapack-mpich2)? Terrific! I don't think you need a binary package, the existing libscalapack-mpi1 and -mpi-dev packages with libscalapack-mpich2*.[so|a] files should be fine. As for blacs-mpi, it has been rebuilt successfully.¹ Indeed, thanks! I'll be waiting attentive for your replies, and thus proceed correctly with your advises. Thanks, I'll look for the upload and check the buildd logs, and upload mumps when scalapack finishes. PS. Adam, thanks for the patch. No problem, hope it was useful! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#653032: mumps: clean removes patches, nothing re-applies them
tags 653032 patch tags 653032 pending block 653032 by 652312 block 653032 by 652313 thanks This is fixed in alioth and I'll upload it when 652312 and 652313 are fixed. -Adam On Thu, 2011-12-22 at 18:00 -0500, Adam C Powell IV wrote: Package: src:mumps Version: 4.10.0-1 Severity: serious I got rid of the patch and unpatch targets, but forgot that clean removes the patches when dpkg-buildpackage starts, so the build starts with no patches applied. This either needs a patch target which build depends on, or to get rid of the unpatch stuff in clean. I'll fix this after the blacs-mpi and scalapack packages are newly uploaded and built with mpi-defaults 1.0 (mpich2 on non-openmpi arches). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#650804: Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
tags 652313 patch thanks On Wed, 2011-12-21 at 13:23 -0500, Adam C Powell IV wrote: retitle 652313 Needs mpich2 targets in debian/rules block 652313 by 652312 thanks Hi Julien, On Mon, 2011-12-19 at 21:03 +0100, Julien Cristau wrote: On Mon, Dec 19, 2011 at 08:43:12 -0500, Adam C Powell IV wrote: On Sat, 2011-12-17 at 17:32 +0100, Julien Cristau wrote: On Fri, Dec 16, 2011 at 08:00:15 -0500, Adam C Powell IV wrote: I think blacs-mpi, scalapack and suitesparse make sense for no-change rebuilds. But I've been procrastinating maintenance on the rest (just took care of spooles last night, working on hypre now) so this will motivate me to finish up hypre, scotch and mumps -- I'll take care of those three. What are the archs where those rebuilds are needed? Cheers, Julien armel, armhf, mips, mipsel, s390, s390x, sparc. Can't do that for blacs-mpi, it's broken: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650804 The bug is in the lam implementation, which does not include an f90 wrapper. When the rebuild happens, it will use mpich2 which does have an f90 wrapper so it should work. So please schedule this build. I've just confirmed that blacs-mpi builds with libmpich2-dev installed, and does not build with lam4-dev installed with the same failure mode as on the buildds. Simply rescheduling a build of blacs-mpi with the new mpi-defaults depending on mpich2 instead of lam should therefore close bug #650804. Please schedule this build on armel, mips, mipsel, s390, s390x and sparc. (armhf apparently has openmpi.) Scheduled rebuilds for scalapack. Unfortunately scalapack depends on blacs-mpi, so blacs-mpi needs to go first. Looking at the log of the scheduled build, scalapack failed because it doesn't have an mpich2 target, so that will need just a bit of work, please do not schedule a second build of scalapack. I'm attaching a patch which fixes #652313. But blacs-mpi needs to be built before uploading with this fix. Also, I thoughtlessly uploaded mumps earlier today, which depends on scalapack and blacs-mpi. :-( Oh it's failing everywhere, and I think I know why, will fix and re-upload after the new scalapack goes in. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ diff -ur scalapack-1.8.0.orig/debian/changelog scalapack-1.8.0/debian/changelog --- scalapack-1.8.0.orig/debian/changelog 2011-09-18 11:09:36.0 -0400 +++ scalapack-1.8.0/debian/changelog 2011-12-22 16:58:13.0 -0500 @@ -1,3 +1,11 @@ +scalapack (1.8.0-8) unstable; urgency=low + + [ Adam C. Powell, IV ] + * Non-maintainer upload. + * Works with mpich2 as mpi default. + + -- Muammar El Khatib muam...@debian.org Thu, 22 Dec 2011 16:58:01 -0500 + scalapack (1.8.0-7) unstable; urgency=low * Test command execution failure caused due to incompatible file location in diff -ur scalapack-1.8.0.orig/debian/patches/01_SLmake.inc.patch scalapack-1.8.0/debian/patches/01_SLmake.inc.patch --- scalapack-1.8.0.orig/debian/patches/01_SLmake.inc.patch 2011-09-18 10:28:24.0 -0400 +++ scalapack-1.8.0/debian/patches/01_SLmake.inc.patch 2011-12-22 16:04:43.0 -0500 @@ -1,7 +1,7 @@ Index: scalapack-1.8.0/SLmake.inc === scalapack-1.8.0.orig/SLmake.inc 2007-04-07 06:37:26.0 +0200 -+++ scalapack-1.8.0/SLmake.inc 2011-09-18 15:49:24.971359670 +0200 +--- scalapack-1.8.0.orig/SLmake.inc scalapack-1.8.0/SLmake.inc @@ -33,15 +33,30 @@ # # MPI setup; tailor to your system if using MPIBLACS @@ -35,7 +35,7 @@ BLACSFINIT= -lblacsF77init-lam BLACSCINIT= -lblacsCinit-lam BLACSLIB = -lblacs-lam -@@ -56,7 +71,7 @@ +@@ -56,13 +71,28 @@ BLACSCINIT= /usr/lib/libblacsCinit-mpich.a BLACSLIB = /usr/lib/libblacs-mpich.a else @@ -44,7 +44,28 @@ BLACSFINIT= -lblacsF77init-mpich BLACSCINIT= -lblacsCinit-mpich BLACSLIB = -lblacs-mpich -@@ -96,10 +111,10 @@ + endif + TESTINGdir= $(home)/TESTING + endif ++ifeq ($(MPI),mpich2) ++USEMPI= -DUsingMpiBlacs ++ifeq ($(BUILD),static) ++SMPLIB= -L/usr/lib/mpich2/lib/ -lmpich ++BLACSFINIT= /usr/lib/libblacsF77init-mpich2.a ++BLACSCINIT= /usr/lib/libblacsCinit-mpich2.a ++BLACSLIB = /usr/lib/libblacs-mpich2.a ++else ++SMPLIB= -L/usr/lib/mpich2/lib/ -lmpich ++BLACSFINIT= -lblacsF77init-mpich2 ++BLACSCINIT= -lblacsCinit-mpich2 ++BLACSLIB = -lblacs-mpich2 ++endif ++TESTINGdir= $(home)/TESTING ++endif + ifeq ($(MPI),pvm) + USEMPI= + ifeq ($(BUILD),static) +@@ -96,10 +126,10 @@ # # The fortran and C compilers, loaders, and their flags # @@ -57,7 +78,7 @@ F77FLAGS = -Wall -O6 -funroll-all-loops -ffast-math $(NOOPT) CCFLAGS = -Wall $(FPIC) -O6 -funroll-all-loops -ffast-math
Bug#652313: Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
retitle 652313 Needs mpich2 targets in debian/rules block 652313 by 652312 thanks Hi Julien, On Mon, 2011-12-19 at 21:03 +0100, Julien Cristau wrote: On Mon, Dec 19, 2011 at 08:43:12 -0500, Adam C Powell IV wrote: On Sat, 2011-12-17 at 17:32 +0100, Julien Cristau wrote: On Fri, Dec 16, 2011 at 08:00:15 -0500, Adam C Powell IV wrote: I think blacs-mpi, scalapack and suitesparse make sense for no-change rebuilds. But I've been procrastinating maintenance on the rest (just took care of spooles last night, working on hypre now) so this will motivate me to finish up hypre, scotch and mumps -- I'll take care of those three. What are the archs where those rebuilds are needed? Cheers, Julien armel, armhf, mips, mipsel, s390, s390x, sparc. Can't do that for blacs-mpi, it's broken: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650804 The bug is in the lam implementation, which does not include an f90 wrapper. When the rebuild happens, it will use mpich2 which does have an f90 wrapper so it should work. So please schedule this build. Scheduled rebuilds for scalapack. Unfortunately scalapack depends on blacs-mpi, so blacs-mpi needs to go first. Looking at the log of the scheduled build, scalapack failed because it doesn't have an mpich2 target, so that will need just a bit of work, please do not schedule a second build of scalapack. suitesparse doesn't seem to have any lam dependencies? D'oh! You're right. My mistake, closing that bug now. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
On Sat, 2011-12-17 at 17:32 +0100, Julien Cristau wrote: On Fri, Dec 16, 2011 at 08:00:15 -0500, Adam C Powell IV wrote: I think blacs-mpi, scalapack and suitesparse make sense for no-change rebuilds. But I've been procrastinating maintenance on the rest (just took care of spooles last night, working on hypre now) so this will motivate me to finish up hypre, scotch and mumps -- I'll take care of those three. What are the archs where those rebuilds are needed? Cheers, Julien armel, armhf, mips, mipsel, s390, s390x, sparc. Thanks! Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
On Fri, 2011-12-16 at 09:57 +0100, Julien Cristau wrote: Hi, On Thu, Dec 15, 2011 at 19:45:47 -0500, Adam C Powell IV wrote: Found the problem. PETSc built on November 16 with mpi-defaults 0.6 which depended on LAM on non-openmpi arches. Now mpi-defaults 1.0.1 released 12/4 depends on MPICH2, so we have a mix of architectures installed. And mpi-defaults just went into testing today... Crap! It may be that other PETSc dependencies need rebuilding too... and there are a lot of them! Let's see: suitesparse, spooles, hypre, scotch, blacs-mpi, scalapack, mumps, all have to be rebuilt with MPICH2! What was built when: * suitesparse: April 15 2010 * spooles: May 11 2010 * hypre: August 15 2010 * scotch: April 6 2011 * blacs-mpi: August 29 2011 * scalapack: September 18 2011 * mumps: March 31 2011 None was built recently, all need to be rebuilt. mpi-defaults should not be in testing until at least these are rebuilt, probably others. Note: HDF5 is not a problem for PETSc because PETSc only links to it on OpenMPI platforms. I forgot why that is, maybe it's worth a try building PETSc against HDF5-mpich2? Maybe later... Okay, cloning this bug to a bunch of packages, see above. I've been an uploader to all except blacs-mpi and scalapack, and many of them could use some maintenance, this is a good excuse to spend time on them. :-) If any of those can be fixed with a no-change rebuild on the buildds, rather than a source upload, let debian-release know, and we'll schedule them. Thanks Julien. I think blacs-mpi, scalapack and suitesparse make sense for no-change rebuilds. But I've been procrastinating maintenance on the rest (just took care of spooles last night, working on hypre now) so this will motivate me to finish up hypre, scotch and mumps -- I'll take care of those three. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#652061: elmerfem: FTBFS missing build-dependencvy?
clone 652061 -1 reassign -1 libarpack2-dev retitle -1 Removed symbols needed by other packages found -1 3.0.1-1 block 652061 by -1 thanks On Wed, 2011-12-14 at 14:31 -0500, Adam C Powell IV wrote: Hi Sylvestre, On Wed, 2011-12-14 at 18:50 +0100, Sylvestre Ledru wrote: Le mercredi 14 décembre 2011 à 11:58 -0500, Adam C Powell IV a écrit : Hi Christoph, On Wed, 2011-12-14 at 16:01 +0100, Christoph Egger wrote: Package: src:elmerfem Version: 6.1.0.svn.5396.dfsg-3 Severity: serious Tags: sid wheezy Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the buildds: checking for dseupd_ in -larpack... yes configure: WARNING: No parallel arpack found. checking for pdneupd_ in -lparpack... no checking for HYPRE_IJMatrixCreate in -lHYPRE_IJ_mv... yes checking for dmumps_ in -ldmumps_scotch... yes checking for umfpack_di_defaults in -lumfpack... yes checking for mtc_init in -lmatc... yes configure: error: The MPI version needs parpack. Disabling MPI. checking for main in -lm... yes make: *** [stamp-build] Error 1 Thanks for the report. Hmm, libparpack.so is still there, but doesn't have this symbol. Requires further investigation. I should be able to get to it in the next day or two. hmhm, this is likely to be my fault. We (Debian, Scilab Octave) released a new version of arpack (since upstream is dead) [1]. We applied some patches from gentoo to switch to autotools. It might be the cause of your issue. Do you know which symbol is missing ? From the build log, configure is looking for dseupd_ but I don't know all of the symbols which Elmer uses. Sounds like this is an arpack bug. Please do nm libparpack.so on the un-stripped libraries, old and new, to see what has been dropped and figure out why. I'll do so if I can get some time, but that might be mid-next week. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
On Thu, 2011-12-15 at 09:55 +0100, Alexander Reichle-Schmehl wrote: reopen 651452 found 651452 0.11.0-12 thanks Hi! * Adam C Powell IV hazel...@debian.org [111214 15:33]: Better to rip out the -llam and replace LLAM in the patch with -lmpi. I'll test then upload -12 with this change and let's see how it builds. That didn't work, too: It fails to build on armel, sparc due to that precise error (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte'). BTW: The build-depends in the sid chroot on smetana.debian.org, the sparc porter box, are still available. And the machine builds the package quite fast. Okay. I don't believe this is an illuminator error. The issue is that LAM should not be anywhere on the system, nothing should be linked with it, nothing should use its headers, nothing should try to link with it. The lam_mpi_byte symbol is probably a #define in the LAM headers, which shouldn't even be installed. libmpich2-dev has been the mpi-default-dev package on non-openmpi platforms for nearly seven months, so everything should have been rebuilt against it. So where is the LAM contamination coming from? I'll log into smetana and see what I can figure out. Furthermore it's unbuildable on mips, mipsel and s390 as configure doesn't find the PETSc libraries, which looks like the error I described in mail #27 of this bug. The PETSc libraries are installed, and the test is from petsc.m4 . But we don't know what the linking error is that causes it to fail, could be the same kind of error as the one in the tsview link. Please don't zero-day NMU! Of course. Just for the record: When I did a zero-day NMU it was a bug of an RC bug without any maintainer reaction for more than 7 days. So the 0-day NMU was covered by the developers reference. Now that you are working on the issue, I can't. Understood. The problem is on my end. I'm afraid since I subscribed to debian-science-maintainers there's been too much traffic on that list for me to read, and bug emails which used to come to my address and go into my bugs folder go into that folder instead. So I had no idea any of this was happening until I scanned d-s-m 8 days later... Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
clone 651452 -1 reassign -1 src:petsc retitle -1 Rebuild with mpi-defaults = 1.0 found -1 3.1.dfsg-11.1 block 651452 by -1 clone 651452 -2 reassign -2 src:suitesparse retitle -2 Rebuild with mpi-defaults = 1.0 found -2 3.4.0-2 block -1 by -2 clone 651452 -3 reassign -3 src:spooles retitle -3 Rebuild with mpi-defaults = 1.0 found -3 2.2-8 block -1 by -3 clone 651452 -4 reassign -4 src:hypre retitle -4 Rebuild with mpi-defaults = 1.0 found -4 2.4.0b-7 block -1 by -4 clone 651452 -5 reassign -5 src:scotch retitle -5 Rebuild with mpi-defaults = 1.0 found -5 5.1.11.dfsg-7 block -1 by -5 clone 651452 -6 reassign -6 src:blacs-mpi retitle -6 Rebuild with mpi-defaults = 1.0 found -6 1.1-30.1 block -1 by -6 clone 651452 -7 reassign -7 src:scalapack retitle -7 Rebuild with mpi-defaults = 1.0 found -7 1.8.0-7 block -1 by -7 clone 651452 -8 reassign -8 src:mumps retitle -8 Rebuild with mpi-defaults = 1.0 found -8 4.9.2.dfsg-7 block -1 by -8 clone 651452 -9 reassign -9 src:mpi-defaults retitle -9 Get this out of testing until its rdepends have rebuilt found -9 1.0.1 block -9 by 651452 block -9 by -1 block -9 by -2 block -9 by -3 block -9 by -4 block -9 by -5 block -9 by -6 block -9 by -7 block -9 by -8 thanks On Thu, 2011-12-15 at 14:36 -0500, Adam C Powell IV wrote: On Thu, 2011-12-15 at 09:55 +0100, Alexander Reichle-Schmehl wrote: reopen 651452 found 651452 0.11.0-12 thanks Hi! * Adam C Powell IV hazel...@debian.org [111214 15:33]: Better to rip out the -llam and replace LLAM in the patch with -lmpi. I'll test then upload -12 with this change and let's see how it builds. That didn't work, too: It fails to build on armel, sparc due to that precise error (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte'). BTW: The build-depends in the sid chroot on smetana.debian.org, the sparc porter box, are still available. And the machine builds the package quite fast. Okay. I don't believe this is an illuminator error. The issue is that LAM should not be anywhere on the system, nothing should be linked with it, nothing should use its headers, nothing should try to link with it. The lam_mpi_byte symbol is probably a #define in the LAM headers, which shouldn't even be installed. libmpich2-dev has been the mpi-default-dev package on non-openmpi platforms for nearly seven months, so everything should have been rebuilt against it. So where is the LAM contamination coming from? Found the problem. PETSc built on November 16 with mpi-defaults 0.6 which depended on LAM on non-openmpi arches. Now mpi-defaults 1.0.1 released 12/4 depends on MPICH2, so we have a mix of architectures installed. And mpi-defaults just went into testing today... Crap! It may be that other PETSc dependencies need rebuilding too... and there are a lot of them! Let's see: suitesparse, spooles, hypre, scotch, blacs-mpi, scalapack, mumps, all have to be rebuilt with MPICH2! What was built when: * suitesparse: April 15 2010 * spooles: May 11 2010 * hypre: August 15 2010 * scotch: April 6 2011 * blacs-mpi: August 29 2011 * scalapack: September 18 2011 * mumps: March 31 2011 None was built recently, all need to be rebuilt. mpi-defaults should not be in testing until at least these are rebuilt, probably others. Note: HDF5 is not a problem for PETSc because PETSc only links to it on OpenMPI platforms. I forgot why that is, maybe it's worth a try building PETSc against HDF5-mpich2? Maybe later... Okay, cloning this bug to a bunch of packages, see above. I've been an uploader to all except blacs-mpi and scalapack, and many of them could use some maintenance, this is a good excuse to spend time on them. :-) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#617613: FreeCAD not in Testing
On Fri, 2011-12-02 at 18:15 +0100, Joerg Jaspert wrote: Hi as we have been asked about this license problem and not yet provided an answer: Either the licensing is changed so that the incompatibility no longer is there (by either getting the license changed, or exceptions in the other parts, or by using replacement software which does not have license problems, whatever works), or failing that, the package(s) need to go from Debian. I'm sorry, can you be more specific? You have concluded that the OpenCASCADE Technology Public License (OCTPL) is incompatible with GPL? Which part(s) of OCTPL is/are incompatible? Or do you agree with Francesco's analysis based on the preamble, which is not legally binding? Thank you, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#617613: FreeCAD not in Testing
Hi Francesco, On Sun, 2011-11-13 at 19:30 +0100, Francesco Poli wrote: On Sun, 13 Nov 2011 11:49:10 -0500 Adam C Powell IV wrote: On Sun, 2011-11-13 at 15:20 +0100, Francesco Poli wrote: [...] Yes, but I think freecad should not be released in a stable version (again) with this serious issue unsolved. Indeed, a package with a copyright/licensing issue can't go into a release, and can't go into testing. IMO this isn't an issue, Please let me understand: (0) you (still) don't think that the OCTPL is GPL-incompatible or (1) you agree that the OCTPL is GPL-incompatible, but you think that this is not an issue for the package freecad linked with libopencascade-* Is it (0) or (1)? It's 0, I don't see any clauses in the OCTPL itself which render it GPL-incompatible, agreeing with Denis' interpretation. and the fact that Debian allowed it into unstable and the squeeze release indicates that the project probably doesn't think so either. [...] The issue may have been overlooked at first. If I recall correctly, the initial discussions about the OCTPL were mainly focused on its DFSG-freeness. The GPL-incompatibility issue was only raised later and was not immediately clear. Indeed. When I filed the bug report, the GPL-incompatibility had been acknowledged by Open CASCADE S.A.S. itself (that is to say, the authors of the OCTPL!). Do you have a link where they acknowledge GPL incompatibility? The preamble isn't part of the legally-binding text. But until there's an official ruling on this issue, the package can't go any further in Debian. An official ruling on the fact that a GPL'ed package which links with both a GPL'ed library and a GPL-incompatible library has a serious bug?!? I thought this was agreed upon long time ago within the Debian Project. I have seen so many packages with such issues reported as serious bugs (for instance for GPL programs linking with OpenSSL), that I think it goes without saying! No, I meant that until December 2, Debian had not given an official ruling indicating whether OCTPL is GPL-compatible. Now they have issued a ruling but without any clarity or justification. I'm going to ask Joerg for a clarification on his email of December 2. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
Hi Alexander, On Wed, 2011-12-14 at 10:09 +0100, Alexander Reichle-Schmehl wrote: reopen 651452 retitle 651452 illuminator: FTBFS on archs where petsc uses liblam (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte') found 651452 0.11.0-8.2 clone 651452 -1 retitle -1 illuminat: Build-Conflicts on libmpich2-dev to strict That's not going to work: illuminator Build-Depends on mpi-default-dev, which depends on libmpich2-dev on several arches. Better to rip out the -llam and replace LLAM in the patch with -lmpi. I'll test then upload -12 with this change and let's see how it builds. Please don't zero-day NMU! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#652061: elmerfem: FTBFS missing build-dependencvy?
Hi Christoph, On Wed, 2011-12-14 at 16:01 +0100, Christoph Egger wrote: Package: src:elmerfem Version: 6.1.0.svn.5396.dfsg-3 Severity: serious Tags: sid wheezy Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the buildds: checking for dseupd_ in -larpack... yes configure: WARNING: No parallel arpack found. checking for pdneupd_ in -lparpack... no checking for HYPRE_IJMatrixCreate in -lHYPRE_IJ_mv... yes checking for dmumps_ in -ldmumps_scotch... yes checking for umfpack_di_defaults in -lumfpack... yes checking for mtc_init in -lmatc... yes configure: error: The MPI version needs parpack. Disabling MPI. checking for main in -lm... yes make: *** [stamp-build] Error 1 Thanks for the report. Hmm, libparpack.so is still there, but doesn't have this symbol. Requires further investigation. I should be able to get to it in the next day or two. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#652061: elmerfem: FTBFS missing build-dependencvy?
Hi Sylvestre, On Wed, 2011-12-14 at 18:50 +0100, Sylvestre Ledru wrote: Le mercredi 14 décembre 2011 à 11:58 -0500, Adam C Powell IV a écrit : Hi Christoph, On Wed, 2011-12-14 at 16:01 +0100, Christoph Egger wrote: Package: src:elmerfem Version: 6.1.0.svn.5396.dfsg-3 Severity: serious Tags: sid wheezy Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the buildds: checking for dseupd_ in -larpack... yes configure: WARNING: No parallel arpack found. checking for pdneupd_ in -lparpack... no checking for HYPRE_IJMatrixCreate in -lHYPRE_IJ_mv... yes checking for dmumps_ in -ldmumps_scotch... yes checking for umfpack_di_defaults in -lumfpack... yes checking for mtc_init in -lmatc... yes configure: error: The MPI version needs parpack. Disabling MPI. checking for main in -lm... yes make: *** [stamp-build] Error 1 Thanks for the report. Hmm, libparpack.so is still there, but doesn't have this symbol. Requires further investigation. I should be able to get to it in the next day or two. hmhm, this is likely to be my fault. We (Debian, Scilab Octave) released a new version of arpack (since upstream is dead) [1]. We applied some patches from gentoo to switch to autotools. It might be the cause of your issue. Do you know which symbol is missing ? From the build log, configure is looking for dseupd_ but I don't know all of the symbols which Elmer uses. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651452: illuminator: FTBFS on sparc (tsview-tsview.o: undefined reference to symbol 'lam_mpi_byte')
X-Debbugs-Cc: Alexander Reichle-Schmehl alexan...@schmehl.info, Julien Cristau jcris...@debian.org Dear Alexander and Julien, Please accept my apologies for uploading just now without incorporating yoru recent changes. I had not seen your NMU uploads because they came via the BTS system to debian-science-maintainers, a very high traffic list which I'm unfortunately not able to read as frequently as I'd like. Your messages came during a particularly busy couple of weeks, and just now when I tried to catch up by preparing the illuminator upload, I did so before reading through the last two weeks of d-s-m traffic. I'll prepare a new -10 upload by the end of the day incorporating your recent changes. Regards, Adam On Mon, 2011-12-12 at 13:45 +0100, Alexander Reichle-Schmehl wrote: tags 651452 + patch tags 651452 + pending thanks Hi! * Alexander Reichle-Schmehl alexan...@schmehl.info [111209 14:41]: However I get now the same FTBFS as originally reported. I guess we call that progress... I think I solved the problem, however I only found a kind of grude workarround, not a real solution. The problem seems to be, that petsc is linked to liblam on sparc, and therefore the additional linkerflad -llam is needed on that arch. I have no idea, why this issue han't shown up on armel, mips, mipsel or s390, the other arches on which petsc uses lam. My patch adds the missing flag on sparc. A nicer fix would be to some detect automatically, if -llam is needed or not based upon... uh... Don't know what. That being said, I uploaded the fix to delayed/4. Please tell me, if I should delay it longer. As you can see I also added libmpich2-dev to the build-conflicts. That's to prevent FTBFS issues as seen while trying to fix the issue in the porter chroots (see bug log for details). Best Regards, Alexander -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651905: src:illuminator: FTBFS everywhere due to build: build-arch build-indep
Package: src:illuminator Version: 0.11.0-10 Severity: serious The conversion to build-arch and build-indep targets caused illuminator to FTBFS, because buildds do debian/rules build which triggers build-indep without installing the Build-Depends-Indep packages. Temporary workaround: change to build: build-arch without build-indep. At some point the buildds will become consistent with policy, perhaps when a lot more packages separate the build target. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651105: Fixed in git repo
On Fri, 2011-12-09 at 18:52 +0100, D. Barbier wrote: tags 651105 + pending thanks Adam, can you please upload? Dependencies should be fine now, I checked with pbuilder. It's building now, will upload in 12 hours or so. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#651905: src:illuminator: FTBFS everywhere due to build: build-arch build-indep
tags 651905 pending thanks The fix is in alioth, will build and upload within 12 hours or so. On Mon, 2011-12-12 at 19:32 -0500, Adam C Powell IV wrote: Package: src:illuminator Version: 0.11.0-10 Severity: serious The conversion to build-arch and build-indep targets caused illuminator to FTBFS, because buildds do debian/rules build which triggers build-indep without installing the Build-Depends-Indep packages. Temporary workaround: change to build: build-arch without build-indep. At some point the buildds will become consistent with policy, perhaps when a lot more packages separate the build target. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#617613: FreeCAD not in Testing
On Sun, 2011-11-13 at 15:20 +0100, Francesco Poli wrote: On Thu, 10 Nov 2011 19:18:01 +0100 Anton Gladky wrote: Can we decrease the severity of this bug to return the freecad back to testing? Why? I think the bug is still unfixed and still serious, unfortunately. The bug filed on March, but freecad was removed from testing on May because of FTBFS's (I think). Yes, but I think freecad should not be released in a stable version (again) with this serious issue unsolved. Indeed, a package with a copyright/licensing issue can't go into a release, and can't go into testing. IMO this isn't an issue, and the fact that Debian allowed it into unstable and the squeeze release indicates that the project probably doesn't think so either. (Ubuntu has had Freecad since from lucid to oneiric, so they don't seem to think there's a OCTPL-GPL incompatibility either.) But until there's an official ruling on this issue, the package can't go any further in Debian. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#617613: FreeCAD not in Testing
I think we leave it there pending a decision by the project, which will either allow it into testing or remove it from unstable. No need to do anything else in the meantime. I think we should continue to develop the package, so it's in top shape in case the project approves it, it's available to unstable users, and its updates flow to Ubuntu users as well. -Adam On Sun, 2011-11-13 at 18:29 +0100, Anton Gladky wrote: Ok, thanks for both opinions, I agree, that we cannot put freecad into testing. I was hoping, that OCE will fix the issue, but it is seems not... So, if the license issue is not resolved we will request deletion of freecad from unstable? Thanks. Anton On Sun, Nov 13, 2011 at 5:49 PM, Adam C Powell IV hazel...@debian.org wrote: On Sun, 2011-11-13 at 15:20 +0100, Francesco Poli wrote: On Thu, 10 Nov 2011 19:18:01 +0100 Anton Gladky wrote: Can we decrease the severity of this bug to return the freecad back to testing? Why? I think the bug is still unfixed and still serious, unfortunately. The bug filed on March, but freecad was removed from testing on May because of FTBFS's (I think). Yes, but I think freecad should not be released in a stable version (again) with this serious issue unsolved. Indeed, a package with a copyright/licensing issue can't go into a release, and can't go into testing. IMO this isn't an issue, and the fact that Debian allowed it into unstable and the squeeze release indicates that the project probably doesn't think so either. (Ubuntu has had Freecad since from lucid to oneiric, so they don't seem to think there's a OCTPL-GPL incompatibility either.) But until there's an official ruling on this issue, the package can't go any further in Debian. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#645930: src:med-fichier: FTBFS due to git checkout in clean target
Package: src:med-fichier Version: 3.0.3-1 Severity: serious Greetings, The git checkout in the clean target makes this package FTBFS. What blithering idiot could have thought that one up? Get rid of it at once! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#638214: Fails to build from source: libqwt5-qt4-dev no longer exists
Thank you for the update. I spent a little while trying to port to qwt6, it's good to know qwt5 is still an option. I'll see if there's anything I can do about this ICE... -Adam On Mon, 2011-08-29 at 19:02 +0200, Moritz Mühlenhoff wrote: retitle 638214 FTBFS: ICE on amd64 thanks On Wed, Aug 17, 2011 at 08:29:26PM +0200, Moritz Muehlenhoff wrote: Package: elmer Severity: serious Hi, It's currently impossible to build elmerfem from source: dpkg-buildpackage: source package elmerfem dpkg-buildpackage: source version 6.1.0.svn.5272.dfsg-1 dpkg-buildpackage: source changed by Adam C. Powell, IV hazel...@debian.org dpkg-buildpackage: host architecture amd64 dpkg-source --before-build elmerfem-6.1.0.svn.5272.dfsg dpkg-checkbuilddeps: Unmet build dependencies: libqwt5-qt4-dev dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) libqwt5-qt4-dev no longer exists in the archive, switching to libqwt-dev isn't sufficient, I received the following error: libqwt5-qt4-dev has been restored by the libqwt maintainer, but I'm now running into an ICE with GCC 4.6: . -I/usr/include -DFULL_INDUCTION -DUSE_ARPACK -I/usr/include/mpi -DHAVE_MUMPS ExchangeCorrelations.src ExchangeCorrelations.f90 gfortran -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -fPIC -m64 -fPIC -fPIC -I. -Ibinio -I/usr/include/mpi -I/usr/include -c ExchangeCorrelations.f90 gcc -DHAVE_CONFIG_H -I. -I.. -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -I/usr/include/freetype2 -I/usr/include/mpi -g -O2 -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -fPIC -m64 -fPIC -fPIC -I/usr/include -I/usr/include/mpi -MT SolveHypre.o -MD -MP -MF .deps/SolveHypre.Tpo -c -o SolveHypre.o SolveHypre.c mv -f .deps/SolveHypre.Tpo .deps/SolveHypre.Po gcc -DHAVE_CONFIG_H -I. -I.. -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -I/usr/include/freetype2 -I/usr/include/mpi -g -O2 -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -fPIC -m64 -fPIC -fPIC -I/usr/include -I/usr/include/mpi -MT SolveSuperLU.o -MD -MP -MF .deps/SolveSuperLU.Tpo -c -o SolveSuperLU.o SolveSuperLU.c mv -f .deps/SolveSuperLU.Tpo .deps/SolveSuperLU.Po gcc -DHAVE_CONFIG_H -I. -I.. -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -I/usr/include/freetype2 -I/usr/include/mpi -g -O2 -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -fPIC -m64 -fPIC -fPIC -I/usr/include -I/usr/include/mpi -MT umf4_f77wrapper.o -MD -MP -MF .deps/umf4_f77wrapper.Tpo -c -o umf4_f77wrapper.o umf4_f77wrapper.c mv -f .deps/umf4_f77wrapper.Tpo .deps/umf4_f77wrapper.Po /lib/cpp -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -DCONTIG=,CONTIGUOUS -P -traditional-cpp -I. -I/usr/include -DFULL_INDUCTION -DUSE_ARPACK -I/usr/include/mpi -DHAVE_MUMPS VankaCreate.src VankaCreate.f90 gfortran -I/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/debian/tmp/usr/include -fPIC -m64 -fPIC -fPIC -I. -Ibinio -I/usr/include/mpi -I/usr/include -c VankaCreate.f90 f951: internal compiler error: Speicherzugriffsfehler Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. make[4]: *** [VankaCreate.o] Fehler 1 make[4]: Leaving directory `/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/fem/src' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/fem/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/fem' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/home/jmm/deb/libav/elmerfem-6.1.0.svn.5272.dfsg/fem' make: *** [stamp-build] Fehler 2 dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2 Cheers, Moritz -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#637845: deal.ii: FTBFS: arch-dependent build runs debian/rules build-doc target without Build-Depends-Indep packages installed
Package: src:deal.ii Version: 7.0.0-2 Severity: serious For some reason, arch-dependent builds on the buildds are triggering the build-doc target, but doxygen is not installed because it's in Build-Depends-Indep but not Build-Depends. I can't figure out why it's doing this, and can't reproduce it. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#618696: closed by Adam C Powell IV hazel...@debian.org (Re: elmer: multiple licensing issues)
tags 618696 pending thanks On Wed, 2011-04-13 at 17:27 -0400, Adam C Powell IV wrote: On Wed, 2011-04-13 at 23:00 +0200, Francesco Poli wrote: On Wed, 13 Apr 2011 16:43:37 -0400 Adam C Powell IV wrote: Let me see if upstream will work with me on this, as they did a linking exception for OpenCASCADE. I think the possible solutions, in descending order of desirability, are: (A) SCOTCH copyright holders should be contacted and persuaded to re-license (or dual-license) it under GPLv2-compatible terms. (B) SCOTCH should be substituted with a GPLv2-compatible replacement, if any is available. (C) GPL-licensed work (Elmer and any other work that indirectly links with SCOTCH through Elmer) copyright holders should be asked to add license exceptions that give permission to link their work with code released under CeCILL-C v1.0 . I agree with this order. But B is very unlikely, I have been looking at this type of software, and it has taken several years for François to bring Scotch close to the capabilities of (Par)METIS. There are not many graph theorists/programmers in the world who can do this, and it takes a very long time. Before contacting Elmer upstream (and possibly other GPL-licensed work upstream), I would try solution (A), or maybe (B). Adding linking exception should be regarded as a last resort strategy... Okay, I'll try A, though I've already started on C. We'll see. Upstream came through with C, and it seems the QPL file which I copied in is not needed to build Elmer at all. So this is all resolved. Changes are in alioth. I'm chasing down an unrelated issue (introduced in upstream SVN since after the last Debian upload). I'll upload when this issue is resolved. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#622694: freecad: FTBFS on all arches
tags 622694 pending thanks Fixed in alioth. On Wed, 2011-04-13 at 18:54 -0400, Adam C Powell IV wrote: Source: freecad Version: 0.11.3729.dfsg-1 Severity: serious FreeCAD FTBFS on all arches. Looks like the problem is lack of a Fortran compiler. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#618241: Not fixed
found 618241 0.11.3729.dfsg-1 thanks This is not yet fixed, it requires libqtwebkit-dev in Build-Depends. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#618696: closed by Adam C Powell IV hazel...@debian.org (Re: elmer: multiple licensing issues)
On Wed, 2011-04-13 at 23:00 +0200, Francesco Poli wrote: On Wed, 13 Apr 2011 16:43:37 -0400 Adam C Powell IV wrote: [...] Hi Francesco, Hi Adam! You mentioned elsewhere (I think your bug against salome) that the CeCILL-C license of scotch is not GPL-compatible. (Can you describe why or send a link?) Sure, here's an analysis of the CeCILL-C license: http://lists.debian.org/debian-legal/2008/01/msg00171.html Very interesting, but also disappointing. Thanks for the link. If that's the case, then Elmer has a problem because it links with Scotch. Well spotted, I didn't notice it! That's not one of the original issues of this bug, but is very much a licensing issue. It definitely seems to be one. More seriously, upstream distributes Elmer with METIS, which is very non-free, and with no linking exception. (The .dfsg package removes the METIS code from the tree.) As the copyright holders, this is their prerogative, but anyone else who distributes them together risks a copyright violation. Let me see if upstream will work with me on this, as they did a linking exception for OpenCASCADE. I think the possible solutions, in descending order of desirability, are: (A) SCOTCH copyright holders should be contacted and persuaded to re-license (or dual-license) it under GPLv2-compatible terms. (B) SCOTCH should be substituted with a GPLv2-compatible replacement, if any is available. (C) GPL-licensed work (Elmer and any other work that indirectly links with SCOTCH through Elmer) copyright holders should be asked to add license exceptions that give permission to link their work with code released under CeCILL-C v1.0 . I agree with this order. But B is very unlikely, I have been looking at this type of software, and it has taken several years for François to bring Scotch close to the capabilities of (Par)METIS. There are not many graph theorists/programmers in the world who can do this, and it takes a very long time. Before contacting Elmer upstream (and possibly other GPL-licensed work upstream), I would try solution (A), or maybe (B). Adding linking exception should be regarded as a last resort strategy... Okay, I'll try A, though I've already started on C. We'll see. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#622694: freecad: FTBFS on all arches
Source: freecad Version: 0.11.3729.dfsg-1 Severity: serious FreeCAD FTBFS on all arches. Looks like the problem is lack of a Fortran compiler. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619931: netgen: will FTBFS with OpenCASCADE 6.5.0
found 619931 4.9.13.dfsg-2 thanks This builds with 6.5.0, but not 6.3.0, so the Build-Dep needs to reflect that by being versioned. -Adam On Wed, 2011-03-30 at 09:33 -0400, Adam C Powell IV wrote: severity 619931 serious thanks OCC 6.5.0 is now in unstable, so this bug is now serious. -Adam On Mon, 2011-03-28 at 09:33 -0400, Adam C Powell IV wrote: Package: src:netgen Version: 4.9.13.dfsg-1 With OpenCASCADE 6.5.0, now in the NEW queue, netgen FTBFS: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../../libsrc/include -DOCCGEOMETRY -I/usr/include/opencascade -D_OCC64 -DHAVE_IOSTREAM -DHAVE_LIMITS -DHAVE_LIMITS_H -DHAVE_IOMANIP -g -O2 -g -O2 -c Partition_Loop2d.cxx -fPIC -DPIC -o .libs/Partition_Loop2d.o Partition_Loop2d.cxx:25:45: fatal error: BRepOffset_DataMapOfShapeReal.hxx: No such file or directory compilation terminated. make[4]: *** [Partition_Loop2d.lo] Error 1 make[4]: Leaving directory `/home/hazelsct/repositories/netgen/libsrc/occ' -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621003: Give back gmsh on amd64 and powerpc
Greetings, Bug 621037 in scotch also bit gmsh [1], at least on amd64 and powerpc. (armel, mips[el] and s390 FTBFS because of what looks like a LAM bug.) Can you please give back gmsh on amd64 and powerpc? [1] http://bugs.debian.org/621003 In the near future, mpi-defaults may switch from LAM to MPICH2 an arches which don't have OpenMPI [2] and the other problem should go away too. [2] http://lists.debian.org/debian-science/2011/04/msg00011.html Thanks again, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#605294: PETSc bugs fixed in alioth
tags 602660 pending tags 605294 pending tags 608902 pending thanks Finally got some time for this package; these bugs are fixed in alioth (I think, didn't try to build on any LAM architectures) and I'll upload as soon as I get around to updating to upstream patch level 8 (bug ). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621003: gmsh: FTBFS: undefined references to `SCOTCH_*'
Hi Christophe, On Wed, 2011-04-06 at 09:14 +0200, trophime wrote: On Tue, 2011-04-05 at 21:41 +0200, Anton Gladky wrote: Adam, what do you think, can this bug be related to #619935? I think this is related to changes in scotch package. We should maybe add a define flag to CCFLAGS and for sure change -lmetis to -lmetis -lscotch Indeed, the scotch package has the bug, #621037. And to work around it, you'd need -lmetis -lscotch -lscotcherr -lscotcherrexit. In addition to gmsh, this breaks at least elmerfem, and probably mumps. I'm working on the scotch fix now so you won't need to work-around, hope to have it uploaded within a couple of hours. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621037: scotch: missing inter-library links
On Tue, 2011-04-05 at 21:18 -0400, Adam C Powell IV wrote: Pierre Johannes, On Tue, 2011-04-05 at 20:13 -0400, Adam C Powell IV wrote: Package: src:scotch Version: 5.1.11.dfsg-5 Severity: serious Justification: causes other packages to FTBFS X-DebBugs-CC: gladky.an...@gmail.com Greetings, In the last upload or two, the scotch package has lost its inter-library linkages. libscotchmetis should be linked -lscotch, and libscotch should be linked -lscotcherr and a couple of others, but they're not. I'm afraid this sends us back to the drawing board. We can't simply use AR = gcc ... to build shared libraries because they need to link to each other. What were the reasons for building this way again? I can see that it's helpful to build the static libraries without -fPIC, but one can do this by building .lo objects with -fPIC and making the shared libs with those, like libtool does. I'm afraid I'm going to have to revert much of the recent work to -4 and try to fix its problems a different way... Just put a fix in alioth, let me know if it gives you trouble. I plan to upload within 4-5 hours. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621037: scotch: missing inter-library links
Hi Johannes, On Wed, 2011-04-06 at 14:37 +0200, Johannes Ring wrote: Hi Adam, On Wed, Apr 6, 2011 at 1:47 PM, Adam C Powell IV hazel...@debian.org wrote: Just put a fix in alioth, let me know if it gives you trouble. I plan to upload within 4-5 hours. Sorry, I tried your fix but it gives me trouble because libptscotch is linked against libscotch. This is the same problem as reported in #612621. Right, I'm sorry about that. I just copied the link commands from -4, assuming that the changed CFLAGS and LDFLAGS would make the difference. It seems like the build-fixes.patch does not incorporate the fixes from libptscotch.patch [1] in that bug report. Would you like me to create a new patch against the latest git repository? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=29;filename=libptscotch.patch;att=1;bug=612621 Sure, is there anything else that needs to change? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621037: scotch: missing inter-library links
Thanks very much Johannes. On Wed, 2011-04-06 at 16:11 +0200, Johannes Ring wrote: On Wed, Apr 6, 2011 at 3:12 PM, Adam C Powell IV hazel...@debian.org wrote: Hi Johannes, On Wed, 2011-04-06 at 14:37 +0200, Johannes Ring wrote: Hi Adam, On Wed, Apr 6, 2011 at 1:47 PM, Adam C Powell IV hazel...@debian.org wrote: Just put a fix in alioth, let me know if it gives you trouble. I plan to upload within 4-5 hours. Sorry, I tried your fix but it gives me trouble because libptscotch is linked against libscotch. This is the same problem as reported in #612621. Right, I'm sorry about that. I just copied the link commands from -4, assuming that the changed CFLAGS and LDFLAGS would make the difference. It seems like the build-fixes.patch does not incorporate the fixes from libptscotch.patch [1] in that bug report. Would you like me to create a new patch against the latest git repository? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=29;filename=libptscotch.patch;att=1;bug=612621 Sure, is there anything else that needs to change? The attached patch fixes the problem for me. Thanks, this answers a couple of questions I had. One little detail: using $(AR) ... $(?) would include libptscotcherr.a in the ar command, wouldn't it? Is that intended? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621003: gmsh: FTBFS: undefined references to `SCOTCH_*'
Hello again, On Tue, 2011-04-05 at 20:04 -0400, Adam C Powell IV wrote: Hello Anton, On Tue, 2011-04-05 at 21:41 +0200, Anton Gladky wrote: Adam, what do you think, can this bug be related to #619935? Anton Possibly, but I think it's a new bug -- libmetis.so - libscotchmetis.so should be linked to libscotch.so but it's not. Yup, Elmer is also bombing there. Let me open a new bug and fix that. Darn, that would be three scotch uploads in two days. :-( Okay, three uploads in three days. Just uploaded, it's also updated in alioth, and on http://lyre.mit.edu/~powell/scotch/ . Let me know if it gives you trouble. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621003: gmsh: FTBFS: undefined references to `SCOTCH_*'
Hello Anton, On Tue, 2011-04-05 at 21:41 +0200, Anton Gladky wrote: Adam, what do you think, can this bug be related to #619935? Anton Possibly, but I think it's a new bug -- libmetis.so - libscotchmetis.so should be linked to libscotch.so but it's not. Yup, Elmer is also bombing there. Let me open a new bug and fix that. Darn, that would be three scotch uploads in two days. :-( -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621037: scotch: missing inter-library links
Package: src:scotch Version: 5.1.11.dfsg-5 Severity: serious Justification: causes other packages to FTBFS X-DebBugs-CC: gladky.an...@gmail.com Greetings, In the last upload or two, the scotch package has lost its inter-library linkages. libscotchmetis should be linked -lscotch, and libscotch should be linked -lscotcherr and a couple of others, but they're not. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#621037: scotch: missing inter-library links
Pierre Johannes, On Tue, 2011-04-05 at 20:13 -0400, Adam C Powell IV wrote: Package: src:scotch Version: 5.1.11.dfsg-5 Severity: serious Justification: causes other packages to FTBFS X-DebBugs-CC: gladky.an...@gmail.com Greetings, In the last upload or two, the scotch package has lost its inter-library linkages. libscotchmetis should be linked -lscotch, and libscotch should be linked -lscotcherr and a couple of others, but they're not. I'm afraid this sends us back to the drawing board. We can't simply use AR = gcc ... to build shared libraries because they need to link to each other. What were the reasons for building this way again? I can see that it's helpful to build the static libraries without -fPIC, but one can do this by building .lo objects with -fPIC and making the shared libs with those, like libtool does. I'm afraid I'm going to have to revert much of the recent work to -4 and try to fix its problems a different way... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619935: Bugs #619935 #612621 : most debian/* files rewritten + patches
On Mon, 2011-04-04 at 13:53 +0200, Pierre Saramito wrote: Hello ! From Adam: Already I can see a few issues: * I noticed that you removed -I/usr/include/lam from the CCS and CCD commands. I don't remember the exact reasons, but those were required for the LAM architectures. /usr/include/mpi should be a symlink to /usr/include/lam, but for some reason that didn't work. I think it's a worthy goal to try to remove that for the next upload, but would rather leave it in for this one. I've not tested on lam achitectures. So I'have a question: openmpi does not support yet multi-threads (see eg http://www.open-mpi.org/faq/?category=supported-systems#thread-support ) and we have deleted -DSCOTCH_PTHREAD in CFLAGS. Is lam thread-safe ? There is a FAQ here http://www.lam-mpi.org/faq/category7.php3#question5 but it's not clear for me... This is important for the short term, but a release goal for Wheezy is to deprecate LAM in favor of MPICH2 on the non-OpenMPI architectures. Are we ready to upload? Let's go ! Okay, building now, will upload when it's done. One other note: Muammar fixed blacs-mpi over the weekend, so as soon as that builds properly on alpha (the other arches are all built), scotch should build everywhere. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619935: Bugs #619935 #612621 : most debian/* files rewritten + patches
Hello Pierre, On Thu, 2011-03-31 at 16:12 +0200, Pierre Saramito wrote: Hi Adam and Johannes, From Adam: This is a very strange error in its irreproducibility... Please find a tarball containing a new version of debian files, together with git-status and git-diff files (some files are added, others are removed). This new version fix two major bugs: #619935 FTBFS on several arches due to lex issue #612621 SCOTCH_dgraphInit: linking with both libScotch and libPTScotch is not allowed For the second bug, I've run the two tests from Johannes and run more complex tests (the scotch library together with both pastix and rheolef, distributed environment). I'm glad to hear that you found and solved the source of the Scotch errors! Thanks for all of your work on this. Here is the changes (see debian/changelog) : * Separate compilations for static shared libs (closes: #612621) Note: removing -DSCOTCH_PTHREAD was not sufficient This makes a lot of sense. If they could use libtool, which does this automatically, our life would be easier... * Add flags to flex bison gcc -DSCOTCH_RENAME_PARSER (closes: #619935) * All patches/* has been simplified merged in one short file, for clarity I'm generally not a fan of merging patches like this. But in this case with lots of overlapping patches and all the changes you have made, I think it makes sense, so I'm okay to do it this way. I'm going to change the header a bit though, and maybe the patch file name. These patch has been successfully checked with pbuilder on two arch: i386 amd64 and on sid, wheezy squeeze dists. Also checked on ubuntu natty dist. Wow, thanks for being so thorough! Could you, please upload these files ? Thank you Pierre. I will look over them carefully and merge them into the git repository, then upload. Already I can see a few issues: * I noticed that you removed -I/usr/include/lam from the CCS and CCD commands. I don't remember the exact reasons, but those were required for the LAM architectures. /usr/include/mpi should be a symlink to /usr/include/lam, but for some reason that didn't work. I think it's a worthy goal to try to remove that for the next upload, but would rather leave it in for this one. * In libptscotch-5.1.install, int/lib/libpt*.so is ambiguous: it includes both the versioned shared libraries and the symlinks which belong in the -dev package. If those file names are ambiguous, then only the package order determines which files go into which package, and that is not good. Same for libscotch-5.1.install. * Ah, I see you removed all .so symlinks from the -dev packages, which is where they belong. So I'm going to ignore your .install file changes, which are otherwise cosmetic. I should be able to proceed later today. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619935: Bugs #619935 #612621 : most debian/* files rewritten + patches
On Fri, 2011-04-01 at 14:05 +0200, Johannes Ring wrote: Hi Adam and Pierre, On Fri, Apr 1, 2011 at 1:38 PM, Adam C Powell IV hazel...@debian.org wrote: * I noticed that you removed -I/usr/include/lam from the CCS and CCD commands. I don't remember the exact reasons, but those were required for the LAM architectures. /usr/include/mpi should be a symlink to /usr/include/lam, but for some reason that didn't work. I think it's a worthy goal to try to remove that for the next upload, but would rather leave it in for this one. I usually set CCS and CCD to point to mpicc (same as CCP) when I compile scotch. Would that work on the LAM architectures? Good point, that should work on all arches. I'll use that, and leave /usr/include/lam for now in CFLAGS as well, then we can take both includes out of CFLAGS in a later upload. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#620393: src:blacs-mpi: Uses incorrect MPI implementation on alpha
Package: src:blacs-mpi Version: 1.1-29 Severity: serious Justification: causes other packages to FTBFS Tags: patch Greetings, The blacs-mpi package gets the MPI implementation incorrect on alpha. Because it Build-Depends on libopenmpi-dev, which is not the default on alpha (LAM is), and because OpenMPI's mpi alternatives symlink is at a higher priority than that of LAM, line 9 of debian/rules sets BLACS_MPI to openmpi, messing everything else up. This causes other packages, such as mumps, to FTBFS, because they think there should be a libblacs-lam.so when there is none. This also prevents BLACS from building at all on architectures without OpenMPI, such as armel, hppa, mips[el] and s390. The attached patch should fix this problem. One note: the blacs-mpi FTBFS in bug 614528 (February 22) was probably caused by bug 608717/609830 (closed March 11), so removing libopenmpi-dev from Build-Depends should not cause that problem to happen again. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ --- blacs-mpi-1.1/debian/control~ 2011-04-01 12:23:39.0 -0400 +++ blacs-mpi-1.1/debian/control 2011-04-01 13:37:45.0 -0400 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Muammar El Khatib muam...@debian.org Standards-Version: 3.9.1 -Build-Depends: debhelper (= 7), mpi-default-dev, gfortran, libopenmpi-dev +Build-Depends: debhelper (= 7), mpi-default-dev, gfortran Homepage: http://www.netlib.org/blacs/ Package: libblacs-mpi1 signature.asc Description: This is a digitally signed message part
Bug#619935: Bugs #619935 #612621 : most debian/* files rewritten + patches
Hi again, On Fri, 2011-04-01 at 07:38 -0400, Adam C Powell IV wrote: Hello Pierre, On Thu, 2011-03-31 at 16:12 +0200, Pierre Saramito wrote: Hi Adam and Johannes, From Adam: This is a very strange error in its irreproducibility... Please find a tarball containing a new version of debian files, together with git-status and git-diff files (some files are added, others are removed). This new version fix two major bugs: #619935 FTBFS on several arches due to lex issue #612621 SCOTCH_dgraphInit: linking with both libScotch and libPTScotch is not allowed For the second bug, I've run the two tests from Johannes and run more complex tests (the scotch library together with both pastix and rheolef, distributed environment). I'm glad to hear that you found and solved the source of the Scotch errors! Thanks for all of your work on this. Here is the changes (see debian/changelog) : * Separate compilations for static shared libs (closes: #612621) Note: removing -DSCOTCH_PTHREAD was not sufficient This makes a lot of sense. If they could use libtool, which does this automatically, our life would be easier... * Add flags to flex bison gcc -DSCOTCH_RENAME_PARSER (closes: #619935) * All patches/* has been simplified merged in one short file, for clarity I'm generally not a fan of merging patches like this. But in this case with lots of overlapping patches and all the changes you have made, I think it makes sense, so I'm okay to do it this way. I'm going to change the header a bit though, and maybe the patch file name. These patch has been successfully checked with pbuilder on two arch: i386 amd64 and on sid, wheezy squeeze dists. Also checked on ubuntu natty dist. Wow, thanks for being so thorough! Could you, please upload these files ? Thank you Pierre. I will look over them carefully and merge them into the git repository, then upload. Already I can see a few issues: * I noticed that you removed -I/usr/include/lam from the CCS and CCD commands. I don't remember the exact reasons, but those were required for the LAM architectures. /usr/include/mpi should be a symlink to /usr/include/lam, but for some reason that didn't work. I think it's a worthy goal to try to remove that for the next upload, but would rather leave it in for this one. * In libptscotch-5.1.install, int/lib/libpt*.so is ambiguous: it includes both the versioned shared libraries and the symlinks which belong in the -dev package. If those file names are ambiguous, then only the package order determines which files go into which package, and that is not good. Same for libscotch-5.1.install. * Ah, I see you removed all .so symlinks from the -dev packages, which is where they belong. So I'm going to ignore your .install file changes, which are otherwise cosmetic. I should be able to proceed later today. I've integrated in everything and it's on alioth now. I've confirmed that it builds with binutils-gold. Can you please test it? Pierre, it differs from the changes you sent in mainly cosmetic ways, plus the -dev package has the .so symlinks, changing CCD and CCS to mpicc, and some other very small things. In the meantime, I've noticed the following FTBFS issues: ia64 and sparc: ln: creating symbolic link `libscotcherr.so': File exists I think this is fixed by Pierre's fix to the Makefile clean targets which remove old shared libraries kfreebsd-i386, mips and mipsel: mpicc -O3 -I. -fPIC -I/usr/include/mpi -I/usr/include/lam -Drestrict=__restrict -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME -DSCOTCH_COLLECTIVE -DSCOTCH_PTSCOTCH -c vmesh_store.c -o vmesh_store.o In file included from library_arch.c:75:0: scotch.h:170:73: error: expected declaration specifiers or '...' before 'MPI_Comm' It looks like this is a Didn't define SCOTCH_PTSCOTCH type of bug, which I think is fixed. Are we ready to upload? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#617729: libmedc-dev should Depend on libhdf5-mpi-dev
severity 617729 important thanks Thank you for your bug report. While this shortcoming makes libmedc-dev not usable without libhdf5-mpi-dev, at the same time, it does not prevent one from using it. As you pointed out, one can simply install libhdf5-mpi-dev and the package becomes fully usable. It is therefore not a grave bug. Nonetheless, I will fix it right away. Sorry I didn't notice it until now. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#620241: elmerfem: unbuildable on ia64 (libatlas3gf-base build-conflict)
severity 620241 important thanks Hello Julien, On Thu, 2011-03-31 at 14:51 +0200, Julien Cristau wrote: Package: elmerfem Version: 5.5.0.svn.5100.dfsg-1 Severity: serious Justification: fails to build from source elmerfem/ia64 dependency installability problem: elmerfem (= 5.5.0.svn.5100.dfsg-1) build-depends on one of: - libmumps-scotch-dev (= 4.9.2.dfsg-6) libatlas3gf-base (= 3.8.3-28) and source---elmerfem (= 5.5.0.svn.5100.dfsg-1) conflict libmumps-scotch-dev (= 4.9.2.dfsg-6) depends on one of: - libmumps-scotch-4.9.2 (= 4.9.2.dfsg-6) libmumps-scotch-4.9.2 (= 4.9.2.dfsg-6) depends on one of: - libatlas3gf-base (= 3.8.3-28) This is not an elmerfem problem, as just 2/14 buildds got it wrong and 11/14 got it right (Hurd is in Dep-Wait state). The resolution is easy: libmumps-scotch-4.9.2 depends on libblas3gf | libblas.so.3gf | libatlas3gf-base, so install libblas3gf. According to buildd.debian.org, every arch built blas 1.2-8 way back in October. And ftp.debian.org has hppa and ia64 packages for libblas3gf 1.2-8, so hppa and ia64 have no excuse. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#620241: elmerfem: unbuildable on ia64 (libatlas3gf-base build-conflict)
clone 620241 -1 reassign -1 src:mumps retitle -1 Should Build-Conflict with libatlas3gf-base block 620241 by -1 thanks On Thu, 2011-03-31 at 19:03 +0200, Julien Cristau wrote: severity 620241 serious kthxbye This bug may not belong to elmerfem but its severity is serious. Which is why it was Cc:ed to the atlas and mumps maintainers. When a fringe arch or two doesn't build a package properly, and it's clearly not due to a problem in that package, it's usually not RC (in my experience). But I'll leave it that way if you prefer. On Thu, Mar 31, 2011 at 12:43:11 -0400, Adam C Powell IV wrote: On Thu, 2011-03-31 at 14:51 +0200, Julien Cristau wrote: Package: elmerfem Version: 5.5.0.svn.5100.dfsg-1 Severity: serious Justification: fails to build from source elmerfem/ia64 dependency installability problem: elmerfem (= 5.5.0.svn.5100.dfsg-1) build-depends on one of: - libmumps-scotch-dev (= 4.9.2.dfsg-6) libatlas3gf-base (= 3.8.3-28) and source---elmerfem (= 5.5.0.svn.5100.dfsg-1) conflict libmumps-scotch-dev (= 4.9.2.dfsg-6) depends on one of: - libmumps-scotch-4.9.2 (= 4.9.2.dfsg-6) libmumps-scotch-4.9.2 (= 4.9.2.dfsg-6) depends on one of: - libatlas3gf-base (= 3.8.3-28) This is not an elmerfem problem, as just 2/14 buildds got it wrong and 11/14 got it right (Hurd is in Dep-Wait state). The resolution is easy: libmumps-scotch-4.9.2 depends on libblas3gf | libblas.so.3gf | libatlas3gf-base, so install libblas3gf. On ia64 libmumps-scotch-4.9.2 depends on libatlas3gf-base. No alternatives. I assume that dependency on libatlas3gf-base is picked up through shlibs. If that's incorrect then whatever package had wrong shlibs should be fixed. Looking at https://buildd.debian.org/fetch.cgi?pkg=mumpsarch=ia64ver=4.9.2.dfsg-6stamp=1290984683file=logas=raw both blas and atlas were installed (atlas was probably picked up from libscalapack-mpi or some other dependency), and atlas doesn't list alternatives in its shlibs file. The BLAS lib and the BLAS section of ATLAS are ABI-compatible, so BLAS has shlibs indicating libblas3gf | libblas.so.3gf | libatlas3gf-base. Building with BLAS leaves resulting packages free to choose which to link against. Building with ATLAS, which sometimes happens by accident, can lead packages to link with ATLAS only, which in turn can cause problems with other packages, like Elmer. So Elmer and a couple of other packages Build-Conflict with ATLAS in order to force the BLAS build, allowing users to choose their BLAS implementation at install time. According to buildd.debian.org, every arch built blas 1.2-8 way back in October. And ftp.debian.org has hppa and ia64 packages for libblas3gf 1.2-8, so hppa and ia64 have no excuse. I don't know what this is supposed to mean. Just that it's odd that two buildds (ia64 and hppa) got it wrong when 11 others got it right and, the packages are available on ia64 and hppa, so it's almost certainly not an Elmer bug. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619931: netgen: will FTBFS with OpenCASCADE 6.5.0
severity 619931 serious thanks OCC 6.5.0 is now in unstable, so this bug is now serious. -Adam On Mon, 2011-03-28 at 09:33 -0400, Adam C Powell IV wrote: Package: src:netgen Version: 4.9.13.dfsg-1 With OpenCASCADE 6.5.0, now in the NEW queue, netgen FTBFS: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../../libsrc/include -DOCCGEOMETRY -I/usr/include/opencascade -D_OCC64 -DHAVE_IOSTREAM -DHAVE_LIMITS -DHAVE_LIMITS_H -DHAVE_IOMANIP -g -O2 -g -O2 -c Partition_Loop2d.cxx -fPIC -DPIC -o .libs/Partition_Loop2d.o Partition_Loop2d.cxx:25:45: fatal error: BRepOffset_DataMapOfShapeReal.hxx: No such file or directory compilation terminated. make[4]: *** [Partition_Loop2d.lo] Error 1 make[4]: Leaving directory `/home/hazelsct/repositories/netgen/libsrc/occ' -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619935: src:scotch: FTBFS on several arches due to lex issue
Hi Pierre and Johannes, On Wed, 2011-03-30 at 14:47 +0200, Johannes Ring wrote: Hi Pierre, On Wed, Mar 30, 2011 at 2:24 PM, Pierre Saramito pierre.saram...@imag.fr wrote: Hi Adam and Johannes, From Adam: parser_ll.l:123:31: error: 'yylval' undeclared (first use in this function) From Johannes: I couldn't (for some unknown reason) reproduce this in a pbuilder I get the last debian/ files from git, then run git-buildpackage and finlay pbuilder, this on two arch (i686 and amd64). I run for each pbuilder on sid, wheezy, sqsueeze and also ubuntu natty, maverick, lucid. The result is the same for all these 12 cases: I couldn reproduce the problem. Also, I dont see any lex problem on debian logs: https://buildd.debian.org/status/package.php?p=scotch despite some logs are out of date. You can for instance see the error in this log: https://buildd.debian.org/fetch.cgi?pkg=scotcharch=i386ver=5.1.11.dfsg-4stamp=1301255277file=logas=raw The lex error can be found near the end, however, there are lots of other errors above this so I'm not sure where the problem lies. This is a very strange error in its irreproducibility... I've applied both patches and pushed to alioth. Angel, can you please verify for us that what's in alioth [1] will build with binutils-gold? It seems to work, but we would like to be sure. When that happens, I will rebuild and upload. [1] git://git.debian.org/git/debian-science/packages/scotch.git Thanks! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#619935: src:scotch: FTBFS on several arches due to lex issue
Package: src:scotch Version: 5.1.11.dfsg-4 Severity: serious Scotch FTBFS on i386, ia64, kfreebsd-i386, mips[el] and sparc: (flex parser_ll.l \ mv lex.yy.c parser_ll.c) || \ cp last_resort/parser_ll.c . mpicc -O3 -I. -fPIC -I/usr/include/mpi -I/usr/include/lam -Drestrict=__restrict -DCOMMON_FILE_COMPRESS_GZ -DCOMMON_PTHREAD -DCOMMON_RANDOM_FIXED_SEED -DSCOTCH_RENAME -DLONG -DSCOTCH_COLLECTIVE -DSCOTCH_PTSCOTCH -c parser_ll.c -o parser_ll.o parser_ll.l: In function '_SCOTCHstratParserLex': parser_ll.l:123:31: error: 'yylval' undeclared (first use in this function) parser_ll.l:123:31: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [parser_ll.o] Error 1 make[3]: Leaving directory `/build/buildd-scotch_5.1.11.dfsg-4-i386-uzmFPf/scotch-5.1.11.dfsg/src/libscotch' -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#614952: elmerfem: FTBFS (QVTKWidget.h was not found)
tags 614952 pending thanks Thanks for the report, the fix is in alioth and I will upload a new version soon. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#609044: elmer: Squashes geometry files
Package: elmer Version: 5.5.0.svn.4716.dfsg-5 Severity: grave Justification: causes data loss For some situations, ElmerGUI's Save Project operation replaces the geometry input files, and every other file with the same basename, with a zero-length file of the same name. This is due to a bug in ElmerGUI/Applications/src/mainwindow.cpp around line 1535, where even for identical geometry and project file paths, (g_path != p_path) returns true, and opening the output files destroys the originals. Upstream fixed this in SVN revisions 4887 and 4888. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#609044: elmer: Squashes geometry files
tags 609044 pending thanks Since upstream fixed this, it should have the pending tag, sorry I forgot it. Building now, should be uploaded by the end of the day. -Adam On Wed, 2011-01-05 at 13:13 -0500, Adam C Powell IV wrote: Package: elmer Version: 5.5.0.svn.4716.dfsg-5 Severity: grave Justification: causes data loss For some situations, ElmerGUI's Save Project operation replaces the geometry input files, and every other file with the same basename, with a zero-length file of the same name. This is due to a bug in ElmerGUI/Applications/src/mainwindow.cpp around line 1535, where even for identical geometry and project file paths, (g_path != p_path) returns true, and opening the output files destroys the originals. Upstream fixed this in SVN revisions 4887 and 4888. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#608655: scotch and gbase: error when trying to install together
Hello, Apologies for the oversight when renaming these binaries for the last upload. I think the scotch user base will expect the standard name of the gbase binary. So there are a couple of options: conflict with gbase, or use /etc/alternatives. Is there a way in popcon to see how many users install both of these? It seems like the database should support this. Hmm, the Homepage listed in control is dead, and a search for gbase gnome turns up very little, so it's hard for me to guess the overlap. If there's little to no overlap, then Conflicts is easier... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#605812: salome: FTBFS: sipAPISalomePyQt.h:7:1: error: unterminated #ifndef
On Fri, 2010-12-03 at 19:05 +0100, Cyril Brulebois wrote: Source: salome Version: 5.1.3-12 Severity: serious Justification: FTBFS Hi, your package no longer builds: | In file included from sipSalomePyQtQtxActionSet.cc:7: | sipAPISalomePyQt.h:7:1: error: unterminated #ifndef Thanks. This error almost always is a race condition in generated code: a thread tries to compile with the file before its generation is complete. This package has dealt with this before, let me see what I can do. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#604626: libmedc-dev: med_exit_if.h missing?
found 599052 2.3.6-4 tags 599052 pending tags 604626 pending thanks I goofed, this is still a problem for libmedc-dev. Sorry, rushed through the fix without thinking about it. Also fixed 604626 with a versioned conflict against this troublesome libmed-dev. The fixes are in alioth and I'm building now. -Adam On Mon, 2010-11-22 at 14:28 -0500, Adam C Powell IV wrote: Hello, I apologize, I am just now seeing this bug. I have just fixed it, included the fix in its alioth git repository, and uploaded a fixed version to debian unstable. Until it's in the archive, you can get it from: http://lyre.mit.edu/~powell/salome/ . -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#602217: salome-examples won't install
Hello again,
On Tue, 2010-11-02 at 15:34 -0400, Adam C Powell IV wrote:
On Wed, 2010-11-03 at 00:12 +0800, Matthieu Lagouge wrote:
Package: salome-examples
Version: 5.1.3-11
Severity: important
Tags: upstream
salome-examples fails the Python bytecode compilation during package
configuration on my system (amd64).
salome runs fine.
I don't know Python enough to figure out what the problem is exactly.
If there's anything I can try to help finding out the issue, let me know.
Here is the output from dpkg:
Paramétrage de salome-examples (5.1.3-11) ...
Compiling /usr/share/salome/examples/Superv/Python/GeomGraphGates_py.py ...
SyntaxError: ('invalid syntax',
('/usr/share/salome/examples/Superv/Python/GeomGraphGates_py.py', 154, 85,
PyMakeFuse_2.append( 'aSession =
myNamingService.Resolve('/Kernel/Session')
' )\n))
Hmm, files in /usr/share/salome/examples should probably not be
byte-compiled. It seems I'll need to either figure out how to hint that
they should be treated differently, or separate them from the python
code in the example modules (PYHELLO, PYCALCULATOR, etc.).
I've changed the approach somewhat. Having the large /usr/share/salome
directory of salome-examples in an arch any package bloats the archive a
lot, so I moved it to a new salome-examples-common package, which
eliminates this approach. The new version is on alioth, and building
now.
I'm going to upload with this in order to fix the RC bugs, then keep
trying to make NETGENPLUGIN work...
Thanks,
Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Bug#602660: petsc: FTBFS on armel
Hi Hector, On Mon, 2010-11-08 at 14:18 +, Hector Oron wrote: 2010/11/7 Adam C Powell IV hazel...@debian.org: Hi, unfortunately the build log for this configure process doesn't provide just about any needed info. Is there a way to get the configure.log file to determine what went wrong? Could you try to log into abel.debian.org (armel porterbox) and test a build there? I did so, but I am getting: [...] Using MPI implementation lam in directory /usr/lib/lam cp -fp /usr/share/automake-1.11/config.* config/configarch/ cp -fp /usr/share/automake-1.11/config.* config/BuildSystem/config/packages/ if [ ! -f TAGS.backup ]; then cp -a TAGS TAGS.backup; fi PETSC_DIR=/home/zumbi/petsc-3.1.dfsg PETSC_ARCH=linux-gnueabi-c-debug \ ./config/configure.py --with-debugging=1 \ --useThreads 0 --with-clanguage=C++ --with-c-support \ --with-fortran-interfaces=1 \ --with-mpi-dir=/usr/lib/lam \ --with-blas-lib=-lblas --with-lapack-lib=-llapack \ --with-blacs=1 --with-blacs-include=/usr/include \ --with-blacs-lib=[/usr/lib/libblacs-lam.so,/usr/lib/libblacsCinit-lam.so] \ --with-scalapack=1 --with-scalapack-include=/usr/include \ --with-scalapack-lib=/usr/lib/libscalapack-lam.so \ --with-mumps=1 --with-mumps-include=/usr/include \ --with-mumps-lib=[/usr/lib/libdmumps.so,/usr/lib/libzmumps.so,/usr/lib/libsmumps.so,/usr/lib/libcmumps.so,/usr/lib/libmumps_common.so,/usr/lib/libpord.so] \ --with-umfpack=1 --with-umfpack-include=/usr/include/suitesparse \ --with-umfpack-lib=[/usr/lib/libumfpack.so,/usr/lib/libamd.so] \ --with-spooles=1 --with-spooles-include=/usr/include/spooles \ --with-spooles-lib=/usr/lib/libspooles.so \ --with-hypre=1 --with-hypre-dir=/usr \ --with-scotch=1 --with-scotch-include=/usr/include/scotch \ --with-scotch-lib=/usr/lib/libscotch.so \ --with-hdf5=1 --with-hdf5-dir=/usr === Configuring PETSc to compile on your system === TESTING: configureMkdir from config.programs(config/BuildSystem/config/programs.py:21) Illegal instruction make: *** [build-arch] Error 132 dpkg-buildpackage: error: debian/rules build gave error exit status 2 How annoying... I'll see what I can do. Thanks again, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#602660: petsc: FTBFS on armel
severity 602660 important thanks Hi, unfortunately the build log for this configure process doesn't provide just about any needed info. Is there a way to get the configure.log file to determine what went wrong? Thanks, Adam On Sat, 2010-11-06 at 22:37 +, Hector Oron wrote: Package: petsc Version: 3.1.dfsg-8 Severity: serious Hello, petsc fails to build from source with following error: TESTING: configureLibrary from PETSc.packages.hdf5(/build/buildd-petsc_3.1.dfsg-8-armel-h4RNdQ/petsc-3.1.dfsg/config/PETSc/packages/hdf5.py:59) TESTING: check from config.libraries(/build/buildd-petsc_3.1.dfsg-8-armel-h4RNdQ/petsc-3.1.dfsg/config/BuildSystem/config/libraries.py:133) *** UNABLE to CONFIGURE with GIVEN OPTIONS(see configure.log for details): --- --with-hdf5-dir=/usr did not work *** make: *** [build-arch] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Full buildlog at: https://buildd.debian.org/fetch.cgi?pkg=petsc;ver=3.1.dfsg-8;arch=armel;stamp=1288964672 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#601712: salome: FTBFS due to missing graphviz
tags 601712 pending thanks This is now fixed in alioth. I'll upload in a week or when NETGEN meshing is working, whichever comes first. -Adam On Thu, 2010-10-28 at 16:49 -0400, Adam C Powell IV wrote: Package: src:salome Version: 5.1.3-11 Severity: serious Because graphviz is only Build-Depends-Indep and not Build-Depends, dot is missing, so YACS thinks libgraphviz-dev is missing, and doesn't set GRAPHVIZ_CPPFLAGS, and the build fails when trying to #include gvc.h . -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#601712: salome: FTBFS due to missing graphviz
Package: src:salome Version: 5.1.3-11 Severity: serious Because graphviz is only Build-Depends-Indep and not Build-Depends, dot is missing, so YACS thinks libgraphviz-dev is missing, and doesn't set GRAPHVIZ_CPPFLAGS, and the build fails when trying to #include gvc.h . -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598421: CVE-2010-3377 -- security problem in a few files
On Wed, 2010-10-13 at 17:40 +0200, Andre Espaze wrote: Hello Adam, There's a security bug in the Debian package for salome due to insecure handling of LD_LIBRARY_PATH in a couple of places, bug 598421. To fix it, I've patched my runSalome script (this does not affect upstream runSalome), and several upstream files, and pushed the fixes to the alioth repository. Can you please forward upstream the *-secure-library-path.patch files (*=gui, med, yacs)? Please mention that it fixes Common Vulnerabilities and Exposures issue ID CVE-2010-3377 , as mentioned in the patches. Ok, I plan to submit them with the report on the 5.1.4 version. In case it is more urgent, just let me know. Thanks. It's not really urgent for Debian because the package is only in unstable, and this bug is fixed in alioth. As for upstream, it's a locally-exploitable problem, i.e. a user can use it for privilege escalation, so it's somewhat more important than the other patches. Hopefully my current running build will work and I can upload 5.1.3-11 with this fix today, along with fixes for 15 other bugs (!)... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#595281: salome: FTBFS on Alpha, IA64 and Sparc at GEOM_GenSK.cc
retitle 595281 salome: FTBFS in GEOM_SRC_5.1.3/idl due to race condition tags 595281 pending thanks I just reproduced a version of this bug on amd64 when building with parallel=2 (same result as the Sparc issue below, even the same line number), so this is not arch-specific. I believe it is because the IDL compiler gets part-way through the file, and the C++ compiler starts its work before GEOM_GenSK.cc is complete. It wouldn't surprise me if the failures happen on block boundaries... I've put .NOTPARALLEL: in the Makefile.am of that directory and am not seeing any problems in three builds (where before it failed every time), so I'm pushing this to alioth and marking it pending. Yay! Aaron, do you have any advice on avoiding race conditions in generated code? I tried having the omniidl targets include touching a stamp file after finishing code generation, but couldn't get that to work. Once the build gets past GEOM, it seems fine until XDATA_SRC_5.1.3/src/XDATA2SALOME -- I'll try a .NOTPARALLEL: there and then attempt a new build of the whole thing. If that works, there's just one more new FTBFS bug (598690) to fix before upload. -Adam On Thu, 2010-09-02 at 13:22 -0400, Adam C Powell IV wrote: Package: src:salome Version: 5.1.3-10 Severity: serious Three architectures are failing to build on the same file in the GEOM module. Below are excerpts from the buildd logs. Alpha: libtool: compile: g++ -DPACKAGE_NAME=\Salome2 Project GEOM module\ -DPACKAGE_TARNAME=\SalomeGEOM\ -DPACKAGE_VERSION=\5.1.3\ -DPACKAGE_STRING=\Salome2 Project GEOM module 5.1.3\ -DPACKAGE_BUGREPORT=\webmaster.sal...@opencascade.com\ -DPACKAGE_URL=\\ -DPACKAGE=\SalomeGEOM\ -DVERSION=\5.1.3\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBDL=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES=/**/ -DYYTEXT_POINTER=1 -DWITH_NUMPY=/**/ -DHAVE_PTHREAD=1 -D__OSVERSION__=2 -DOMNIORB=/**/ -DCORBA_HAVE_POA=/**/ -DCORBA_ORB_INIT_HAVE_3_ARGS=/**/ -DCORBA_ORB_INIT_THIRD_ARG=/**/ -I. -I../../../GEOM_SRC_5.1.3/idl -I../idl -DOMNIORB_VERSION=4 -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -I/build/buildd-salome_5.1.3-10-alpha-J871wX/salome-5.1.3/debian/tmp/usr/include/salome -DHAVE_MPI2 -I/build/buildd-salome_5.1.3-10-alpha-J871wX/salome-5.1.3/debian/tmp/usr/include/salome -include SALOMEconfig.h -g -O2 -g -D_DEBUG_ -g -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -c GEOM_SupervSK.cc -fPIC -DPIC -o .libs/libSalomeIDLGEOM_la-GEOM_SupervSK.o GEOM_GenSK.cc: In function 'void _0RL_lcfn_095c7337dad1dbdb_f400(omniCallDescriptor*, omniServant*)': GEOM_GenSK.cc:2982: error: '_0RL_cd_095c7337dad1dbdb_630' was not declared in this scope GEOM_GenSK.cc:2982: error: expected ')' at end of input GEOM_GenSK.cc:2982: error: expected ',' or ';' at end of input GEOM_GenSK.cc:2982: warning: unused variable 'tcd' GEOM_GenSK.cc:2982: error: expected '}' at end of input GEOM_GenSK.cc: At global scope: GEOM_GenSK.cc:13: warning: '_0RL_library_version' defined but not used GEOM_GenSK.cc:2980: warning: 'void _0RL_lcfn_095c7337dad1dbdb_f400(omniCallDescriptor*, omniServant*)' defined but not used make[2]: *** [libSalomeIDLGEOM_la-GEOM_GenSK.lo] Error 1 make[2]: *** Waiting for unfinished jobs IA64: libtool: compile: g++ -DPACKAGE_NAME=\Salome2 Project GEOM module\ -DPACKAGE_TARNAME=\SalomeGEOM\ -DPACKAGE_VERSION=\5.1.3\ -DPACKAGE_STRING=\Salome2 Project GEOM module 5.1.3\ -DPACKAGE_BUGREPORT=\webmaster.sal...@opencascade.com\ -DPACKAGE_URL=\\ -DPACKAGE=\SalomeGEOM\ -DVERSION=\5.1.3\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBDL=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES=/**/ -DYYTEXT_POINTER=1 -DWITH_NUMPY=/**/ -DHAVE_PTHREAD=1 -D__OSVERSION__=2 -DOMNIORB=/**/ -DCORBA_HAVE_POA=/**/ -DCORBA_ORB_INIT_HAVE_3_ARGS=/**/ -DCORBA_ORB_INIT_THIRD_ARG=/**/ -I. -I../../../GEOM_SRC_5.1.3/idl -I../idl -DOMNIORB_VERSION=4 -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -I/build/buildd-salome_5.1.3-10-ia64-tatkt7/salome-5.1.3/debian/tmp/usr/include/salome -DHAVE_MPI2 -I/build/buildd-salome_5.1.3-10-ia64-tatkt7/salome-5.1.3/debian/tmp/usr/include/salome -include SALOMEconfig.h -D_OCC64 -g -O2 -g -D_DEBUG_ -g -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -c GEOM_GenSK.cc -fPIC -DPIC -o .libs/libSalomeIDLGEOM_la-GEOM_GenSK.o In file included from GEOM_GenSK.cc:3: GEOM_Gen.hh:2:1: error: unterminated #ifndef In file included from GEOM_GenSK.cc:4
Bug#595281: salome: FTBFS on Alpha, IA64 and Sparc at GEOM_GenSK.cc
On Mon, 2010-10-04 at 11:10 -0400, Aaron M. Ucko wrote: Adam C Powell IV hazel...@debian.org writes: Aaron, do you have any advice on avoiding race conditions in generated code? I tried having the omniidl targets include touching a stamp file after finishing code generation, but couldn't get that to work. The problem appears to be that they run the same command: .idlSK.cc: $(OMNIORB_IDL) $(IDLCXXFLAGS) $(OMNIORB_IDLCXXFLAGS) $ .idl.hh: $(OMNIORB_IDL) $(IDLCXXFLAGS) $(OMNIORB_IDLCXXFLAGS) $ As such, make inadvertantly clobbers one SK.cc file in the course of (re)generating the corresponding .hh file for the other source file. :-/ Ah, that makes a lot of sense, and explains why there were so often compilation errors in the SK.cc files. If my analysis is correct, you can work around the bug by having the .hh file claim to depend on the SK.cc file: %.hh: %SK.cc %SK.cc: %.idl $(OMNIORB_IDL) $(IDLCXXFLAGS) $(OMNIORB_IDLCXXFLAGS) $ Very strange, that fails with: make[2]: Entering directory `/home/hazelsct/repositories/salome/build-salome/GEOM_SRC_5.1.3/idl' Makefile:907: warning: overriding commands for target `mostlyclean-local' Makefile:880: warning: ignoring old commands for target `mostlyclean-local' /usr/bin/omniidl -bcxx -Wba -nf -I/usr/idl -I../idl/salome -I/home/hazelsct/repositories/salome/debian/salome/usr/idl/salome -Wba -nf -I/usr/idl ../../../GEOM_SRC_5.1.3/idl/GEOM_Gen.idl /usr/bin/omniidl -bcxx -Wba -nf -I/usr/idl -I../idl/salome -I/home/hazelsct/repositories/salome/debian/salome/usr/idl/salome -Wba -nf -I/usr/idl ../../../GEOM_SRC_5.1.3/idl/GEOM_Superv.idl make[2]: *** No rule to make target `GEOM_Gen.hh', needed by `all-am'. Stop. make[2]: *** Waiting for unfinished jobs Maybe because the SK.cc file timestamp is after the .hh? (The .idl - SK.cc rule could continue to use the traditional syntax, but I consider modern %-style pattern rules a better choice for two reasons: - The somewhat artificial SK.cc - .hh rule would otherwise need a dummy command. I wonder if it needs a dummy command anyway. Yup, sticking in a dummy command worked, without .NOTPARALLEL: . - They are clearer, particularly in the face of suffixes not starting with dots.) I agree completely. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598916: salome: FTBFS: make[4]: *** [install-data-local] Error 1
merge 598916 595620 thanks Known bug, it's a race condition in cleanup/installation, fixed in alioth git about four weeks ago. Upload is pending a fix for another FTBFS bug 595281/598772. -Adam On Sun, 2010-10-03 at 11:01 +0200, Philipp Kern wrote: Source: salome Version: 5.1.3-10 Severity: serious Whatever, the failure is buried somewhere in the build log. It fails to copy a lot. sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on murphy.debian.org ╔══╗ ║ salome 5.1.3-10 (i386) 02 Oct 2010 16:58 ║ ╚══╝ [...] warning: Tag `USE_WINDOWS_ENCODING' at line 11 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `DETAILS_AT_TOP' at line 23 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 229 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 230 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u make[4]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' make[3]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' Making install in gui rm -f *.lo make[3]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Nothing to be done for `install-exec-am'. if test -d KERNEL; then \ /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/local-install.sh -d /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ cp -rp KERNEL /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ fi Configuration file `doxyfile' updated. cp: cannot stat `KERNEL/classsalome__iapp_1_1SalomeOutsideGUI.html': No such file or directory -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598916: salome: FTBFS: make[4]: *** [install-data-local] Error 1
merge 598916 595260 D'oh! Got the bug number wrong. On Sun, 2010-10-03 at 19:46 -0400, Adam C Powell IV wrote: merge 598916 595620 thanks Known bug, it's a race condition in cleanup/installation, fixed in alioth git about four weeks ago. Upload is pending a fix for another FTBFS bug 595281/598772. -Adam On Sun, 2010-10-03 at 11:01 +0200, Philipp Kern wrote: Source: salome Version: 5.1.3-10 Severity: serious Whatever, the failure is buried somewhere in the build log. It fails to copy a lot. sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on murphy.debian.org ╔══╗ ║ salome 5.1.3-10 (i386) 02 Oct 2010 16:58 ║ ╚══╝ [...] warning: Tag `USE_WINDOWS_ENCODING' at line 11 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `DETAILS_AT_TOP' at line 23 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 229 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 230 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u make[4]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' make[3]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' Making install in gui rm -f *.lo make[3]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Nothing to be done for `install-exec-am'. if test -d KERNEL; then \ /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/local-install.sh -d /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ cp -rp KERNEL /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ fi Configuration file `doxyfile' updated. cp: cannot stat `KERNEL/classsalome__iapp_1_1SalomeOutsideGUI.html': No such file or directory -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598916: salome: FTBFS: make[4]: *** [install-data-local] Error 1
reassign 595260 src:salome merge 598916 59526 thanks One more try... On Sun, 2010-10-03 at 20:18 -0400, Adam C Powell IV wrote: merge 598916 595260 D'oh! Got the bug number wrong. On Sun, 2010-10-03 at 19:46 -0400, Adam C Powell IV wrote: merge 598916 595620 thanks Known bug, it's a race condition in cleanup/installation, fixed in alioth git about four weeks ago. Upload is pending a fix for another FTBFS bug 595281/598772. -Adam On Sun, 2010-10-03 at 11:01 +0200, Philipp Kern wrote: Source: salome Version: 5.1.3-10 Severity: serious Whatever, the failure is buried somewhere in the build log. It fails to copy a lot. sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on murphy.debian.org ╔══╗ ║ salome 5.1.3-10 (i386) 02 Oct 2010 16:58 ║ ╚══╝ [...] warning: Tag `USE_WINDOWS_ENCODING' at line 11 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `DETAILS_AT_TOP' at line 23 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 229 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 230 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u make[4]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' make[3]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' Making install in gui rm -f *.lo make[3]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Nothing to be done for `install-exec-am'. if test -d KERNEL; then \ /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/local-install.sh -d /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ cp -rp KERNEL /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ fi Configuration file `doxyfile' updated. cp: cannot stat `KERNEL/classsalome__iapp_1_1SalomeOutsideGUI.html': No such file or directory -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598916: salome: FTBFS: make[4]: *** [install-data-local] Error 1
merge 598916 595260 thanks Dammit I can't get this stupid thing right!! On Sun, 2010-10-03 at 20:29 -0400, Adam C Powell IV wrote: reassign 595260 src:salome merge 598916 59526 thanks One more try... On Sun, 2010-10-03 at 20:18 -0400, Adam C Powell IV wrote: merge 598916 595260 D'oh! Got the bug number wrong. On Sun, 2010-10-03 at 19:46 -0400, Adam C Powell IV wrote: merge 598916 595620 thanks Known bug, it's a race condition in cleanup/installation, fixed in alioth git about four weeks ago. Upload is pending a fix for another FTBFS bug 595281/598772. -Adam On Sun, 2010-10-03 at 11:01 +0200, Philipp Kern wrote: Source: salome Version: 5.1.3-10 Severity: serious Whatever, the failure is buried somewhere in the build log. It fails to copy a lot. sbuild (Debian sbuild) 0.60.0 (23 Feb 2010) on murphy.debian.org ╔══╗ ║ salome 5.1.3-10 (i386) 02 Oct 2010 16:58 ║ ╚══╝ [...] warning: Tag `USE_WINDOWS_ENCODING' at line 11 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `DETAILS_AT_TOP' at line 23 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_WIDTH' at line 229 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u warning: Tag `MAX_DOT_GRAPH_HEIGHT' at line 230 of file doxyfile has become obsolete. To avoid this warning please update your configuration file using doxygen -u make[4]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' make[3]: Leaving directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/tui' Making install in gui rm -f *.lo make[3]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Entering directory `/build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/doc/salome/gui' make[4]: Nothing to be done for `install-exec-am'. if test -d KERNEL; then \ /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/build-salome/KERNEL_SRC_5.1.3/local-install.sh -d /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ cp -rp KERNEL /build/buildd-salome_5.1.3-10-i386-qan9XA/salome-5.1.3/debian/salome-dev-doc/usr/share/doc/salome-doc/gui ; \ fi Configuration file `doxyfile' updated. cp: cannot stat `KERNEL/classsalome__iapp_1_1SalomeOutsideGUI.html': No such file or directory -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598421: salome: CVE-2010-3377: insecure library loading
tags 598421 pending
thanks
On Wed, 2010-09-29 at 23:24 -0500, Raphael Geissert wrote:
On 29 September 2010 22:01, Adam C Powell IV hazel...@debian.org wrote:
On Tue, 2010-09-28 at 21:07 +, Raphael Geissert wrote:
Would a secure change omit the former LD_LIBRARY_PATH? That is, would
it fix this in runSalome to say:
export LD_LIBRARY_PATH=${prefix}/lib:${libdir}:/usr/lib:/usr/local/lib
?
You could do that, or use the following:
export
LD_LIBRARY_PATH=${prefix}/lib:${libdir}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
(note the ${VAR:+foo} construct, which is what makes the shell only
expand to the latter part when VAR is set and non-empty. The colon
_before_ the plus sign is important.)
Thanks. I assume this works in both bash and dash, and have applied
this to the files you mentioned in the package git repository on alioth.
There's one more RC/FTBFS bug to fix, then I'll upload, hopefully by
tomorrow but maybe early next week.
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Bug#598421: CVE-2010-3377 -- security problem in a few files
Hello Andre, There's a security bug in the Debian package for salome due to insecure handling of LD_LIBRARY_PATH in a couple of places, bug 598421. To fix it, I've patched my runSalome script (this does not affect upstream runSalome), and several upstream files, and pushed the fixes to the alioth repository. Can you please forward upstream the *-secure-library-path.patch files (*=gui, med, yacs)? Please mention that it fixes Common Vulnerabilities and Exposures issue ID CVE-2010-3377 , as mentioned in the patches. Thanks, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#598421: salome: CVE-2010-3377: insecure library loading
Hello,
On Tue, 2010-09-28 at 21:07 +, Raphael Geissert wrote:
Package: salome
Version: 5.1.3-9
Severity: grave
Tags: security
User: t...@security.debian.org
Usertags: ldpath
Hello,
During a review of the Debian archive, I've found your package to
contain a script that can be abused by an attacker to execute arbitrary
code.
The vulnerability is introduced by an insecure change to
LD_LIBRARY_PATH, an environment variable used by ld.so(8) to look for
libraries on a directory other than the standard paths.
Thank you, I'm glad your review found this.
Would a secure change omit the former LD_LIBRARY_PATH? That is, would
it fix this in runSalome to say:
export LD_LIBRARY_PATH=${prefix}/lib:${libdir}:/usr/lib:/usr/local/lib
?
The prefix and libdir variables are set elsewhere in runSalome, so I
don't think one could override those... But if it could be a problem,
I'll have that script hard-code them instead.
Vulnerable code follows:
/usr/bin/runSalome line 28:
export LD_LIBRARY_PATH=${prefix}/lib:${libdir}:$LD_LIBRARY_PATH
/usr/bin/runTestMedCorba line 29:
export LD_LIBRARY_PATH=$MED_ROOT_DIR/lib/salome:${LD_LIBRARY_PATH}
/usr/bin/runTestMedCorba line 37:
export LD_LIBRARY_PATH=$MED_ROOT_DIR/lib/salome:${LD_LIBRARY_PATH}
Possibly vulnerable too:
/usr/lib/salome/bin/runLightSalome line 139:
export LD_LIBRARY_PATH=${MY_LD_LIBRARY_PATH}:${LD_LIBRARY_PATH}
/usr/lib/salome/bin/hxx2salome line 329:
echo -e setenv LD_LIBRARY_PATH
\${${CLASS_NAME}CPP_ROOT_DIR}${lib_dir#${CPP_ROOT_DIR}}:\${LD_LIBRARY_PATH}
${ENVIRON_FILE}
/usr/lib/salome/bin/hxx2salome line 351:
echo -e export
LD_LIBRARY_PATH=\${${CLASS_NAME}CPP_ROOT_DIR}${lib_dir#${CPP_ROOT_DIR}}:\${LD_LIBRARY_PATH}
\
${ENVIRON_FILE}
I see a couple of other bugs in those lines as well... Okay, a lot of
work to do, but starting with fixing the security issue, as soon as I
hear my fix idea above.
When there's an empty item on the colon-separated list of
LD_LIBRARY_PATH, ld.so treats it as '.' (i.e. CWD/$PWD.)
If the given script is executed from a directory where a potential,
local, attacker can write files to, there's a chance to exploit this
bug.
This vulnerability has been assigned the CVE id CVE-2010-3377. Please make
sure
you mention it when forwarding this report to upstream and when fixing
this bug (everywhere: upstream and here at Debian.)
[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3377
[1] http://security-tracker.debian.org/tracker/CVE-2010-3377
Thanks, I'll make sure upstream knows about this.
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Bug#597739: Salome: cannot load module salomeloader
severity 597739 normal thanks Thank you for your report. The program should be started with the command runSalome not salomeloader, so the package is usable. Also, 5.1.3-9 and newer versions should not have /usr/bin/salomeloader but /usr/lib/salome/bin/salomeloader. Please check the location of the script, it should not be where you found it. When I run /usr/lib/salome/bin/salomeloader I get the same error, so this is a bug. The salomeloader python module is distributed in /usr/share/pyshared/salome/salomeloader.py . I'll investigate further when I get some more time. -Adam On Wed, 2010-09-22 at 11:52 -0500, M. wrote: Package: salome Version: 5.1.3-10 Severity: grave Justification: renders package unusable When trying to start the program with the command salomeloader The following error is returned: :~$ salomeloader Traceback (most recent call last): File /usr/bin/salomeloader, line 20, in module import salomeloader ImportError: No module named salomeloader Renders package unusable. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35.4-ispm (SMP w/2 CPU cores; PREEMPT) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages salome depends on: ii libboost-signals1.42.0 1.42.0-4 managed signals and slots library ii libboost-system1.42.0 1.42.0-4 Operating system (e.g. diagnostics ii libboost-thread1.42.0 1.42.0-4 portable C++ multi-threading ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libcos4-1 4.1.3-1+b1 omniORB CORBA services stubs ii libcppunit-1.12-1 1.12.1-1 Unit Testing Library for C++ ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libgcc1 1:4.5.0-4GCC support library ii libgfortran34.5.0-4 Runtime library for GNU Fortran ap ii libgl1-mesa-glx [libgl1 7.7.1-4 A free implementation of the OpenG ii libglu1-mesa [libglu1] 7.7.1-4 The OpenGL utility library (GLU) ii libgvc5 2.26.3-5 rich set of graph drawing tools - ii libhdf5-openmpi-1.8.4 1.8.4-patch1-2 Hierarchical Data Format 5 (HDF5) ii libmed1 2.3.6-3 Library to exchange meshed data (F ii libmedimportcxx02.3.6-3 Library to import old version file ii libomniorb4-1 4.1.3-1+b1 omniORB core libraries ii libomnithread3c24.1.3-1+b1 C++ threading library ii libopencascade-foundati 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-modeling 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-ocaf-6.3 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-ocaf-lit 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-visualiz 6.3.0.dfsg.1-6 OpenCASCADE CAE platform shared li ii libopencascade-visualiz 6.3.0.dfsg.1-6 OpenCASCADE CAE platform library d ii libopenmpi1.3 1.4.2-4 high performance message passing l ii libpython2.62.6.6-5 Shared Python runtime library (ver ii libqscintilla2-52.4.3-1 The Qt4 port of the Scintilla sour ii libqt4-opengl 4:4.6.3-2Qt 4 OpenGL module ii libqt4-xml 4:4.6.3-2Qt 4 XML module ii libqtcore4 4:4.6.3-2Qt 4 core module ii libqtgui4 4:4.6.3-2Qt 4 GUI module ii libqwt5-qt4 5.2.0-1 Qt4 widgets library for technical ii libscotch-5.1 5.1.8a.dfsg-2programs and libraries for graph, ii libssl0.9.8 0.9.8o-2 SSL shared libraries ii libstdc++6 4.5.0-4 The GNU Standard C++ Library v3 ii libvtk5.4 5.4.2-7+b2 Visualization Toolkit - A high lev ii libx11-62:1.3.3-3X11 client-side library ii libxml2 2.7.7.dfsg-4 GNOME XML library ii libxt6 1:1.0.7-1X11 toolkit intrinsics library ii omniorb4-nameserver 4.1.3-1 Transitional package for the omniO ii python 2.6.6-1 interactive high-level object-orie ii python-central 0.6.16+nmu1 register and build utility for Pyt ii python-omniorb 3.3-1Python bindings for omniORB ii python-vtk 5.4.2-7+b2 Python bindings for VTK ii salome-common 5.1.3-10 Numerical simulation pre- and post ii zlib1g 1:1.2.3.5.dfsg-1 compression library - runtime salome recommends no packages. Versions of packages salome
Bug#596315: salome: python2.5-dev used as build-dependency, not python-dev or python2.6-dev
Hello Matthias, On Fri, 2010-09-10 at 09:58 +, Matthias Klose wrote: Package: salome Version: 5.1.3-9 Severity: serious User: debian-pyt...@lists.debian.org Usertag: python2.6 The package build-depends on python2.5-dev, which is not the default python version for squeeze. The package should be rebuilt with python2.6, either build-depending on python-dev (recommended) or python2.6-dev. In unstable: $ apt-get source salome Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'salome' packaging is maintained in the 'Git' version control system at: git://git.debian.org/git/debian-science/packages/salome.git Skipping already downloaded file 'salome_5.1.3.orig.tar.gz' Need to get 78.1kB of source archives. Get:1 http://debian.lcs.mit.edu/debian/ sid/main salome 5.1.3-10 (dsc) [2323B] Get:2 http://debian.lcs.mit.edu/debian/ sid/main salome 5.1.3-10 (diff) [75.8kB] Fetched 78.1kB in 0s (179kB/s) dpkg-source: info: extracting salome in salome-5.1.3 dpkg-source: info: unpacking salome_5.1.3.orig.tar.gz dpkg-source: info: unpacking salome_5.1.3-10.debian.tar.gz [skipping patches] $ grep 2.5 salome-5.1.3/debian/control Conflicts: libsalome-dev, libsalome5.1.3-0, python2.5-salome Your bug is one version old, unstable has -10 which doesn't involve python 2.5 except as a conflict with a previous salome version. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#595281: salome: FTBFS on Alpha, IA64 and Sparc at GEOM_GenSK.cc
Package: src:salome Version: 5.1.3-10 Severity: serious Three architectures are failing to build on the same file in the GEOM module. Below are excerpts from the buildd logs. Alpha: libtool: compile: g++ -DPACKAGE_NAME=\Salome2 Project GEOM module\ -DPACKAGE_TARNAME=\SalomeGEOM\ -DPACKAGE_VERSION=\5.1.3\ -DPACKAGE_STRING=\Salome2 Project GEOM module 5.1.3\ -DPACKAGE_BUGREPORT=\webmaster.sal...@opencascade.com\ -DPACKAGE_URL=\\ -DPACKAGE=\SalomeGEOM\ -DVERSION=\5.1.3\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBDL=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES=/**/ -DYYTEXT_POINTER=1 -DWITH_NUMPY=/**/ -DHAVE_PTHREAD=1 -D__OSVERSION__=2 -DOMNIORB=/**/ -DCORBA_HAVE_POA=/**/ -DCORBA_ORB_INIT_HAVE_3_ARGS=/**/ -DCORBA_ORB_INIT_THIRD_ARG=/**/ -I. -I../../../GEOM_SRC_5.1.3/idl -I../idl -DOMNIORB_VERSION=4 -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -I/build/buildd-salome_5.1.3-10-alpha-J871wX/salome-5.1.3/debian/tmp/usr/include/salome -DHAVE_MPI2 -I/build/buildd-salome_5.1.3-10-alpha-J871wX/salome-5.1.3/debian/tmp/usr/include/salome -include SALOMEconfig.h -g -O2 -g -D_DEBUG_ -g -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -c GEOM_SupervSK.cc -fPIC -DPIC -o .libs/libSalomeIDLGEOM_la-GEOM_SupervSK.o GEOM_GenSK.cc: In function 'void _0RL_lcfn_095c7337dad1dbdb_f400(omniCallDescriptor*, omniServant*)': GEOM_GenSK.cc:2982: error: '_0RL_cd_095c7337dad1dbdb_630' was not declared in this scope GEOM_GenSK.cc:2982: error: expected ')' at end of input GEOM_GenSK.cc:2982: error: expected ',' or ';' at end of input GEOM_GenSK.cc:2982: warning: unused variable 'tcd' GEOM_GenSK.cc:2982: error: expected '}' at end of input GEOM_GenSK.cc: At global scope: GEOM_GenSK.cc:13: warning: '_0RL_library_version' defined but not used GEOM_GenSK.cc:2980: warning: 'void _0RL_lcfn_095c7337dad1dbdb_f400(omniCallDescriptor*, omniServant*)' defined but not used make[2]: *** [libSalomeIDLGEOM_la-GEOM_GenSK.lo] Error 1 make[2]: *** Waiting for unfinished jobs IA64: libtool: compile: g++ -DPACKAGE_NAME=\Salome2 Project GEOM module\ -DPACKAGE_TARNAME=\SalomeGEOM\ -DPACKAGE_VERSION=\5.1.3\ -DPACKAGE_STRING=\Salome2 Project GEOM module 5.1.3\ -DPACKAGE_BUGREPORT=\webmaster.sal...@opencascade.com\ -DPACKAGE_URL=\\ -DPACKAGE=\SalomeGEOM\ -DVERSION=\5.1.3\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBDL=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES=/**/ -DYYTEXT_POINTER=1 -DWITH_NUMPY=/**/ -DHAVE_PTHREAD=1 -D__OSVERSION__=2 -DOMNIORB=/**/ -DCORBA_HAVE_POA=/**/ -DCORBA_ORB_INIT_HAVE_3_ARGS=/**/ -DCORBA_ORB_INIT_THIRD_ARG=/**/ -I. -I../../../GEOM_SRC_5.1.3/idl -I../idl -DOMNIORB_VERSION=4 -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include -I/usr/include/omniORB4 -I/usr/include/COS -I/build/buildd-salome_5.1.3-10-ia64-tatkt7/salome-5.1.3/debian/tmp/usr/include/salome -DHAVE_MPI2 -I/build/buildd-salome_5.1.3-10-ia64-tatkt7/salome-5.1.3/debian/tmp/usr/include/salome -include SALOMEconfig.h -D_OCC64 -g -O2 -g -D_DEBUG_ -g -Wparentheses -Wreturn-type -Wmissing-declarations -Wunused -pthread -c GEOM_GenSK.cc -fPIC -DPIC -o .libs/libSalomeIDLGEOM_la-GEOM_GenSK.o In file included from GEOM_GenSK.cc:3: GEOM_Gen.hh:2:1: error: unterminated #ifndef In file included from GEOM_GenSK.cc:4: /usr/include/omniORB4/IOP_S.h:57: error: expected constructor, destructor, or type conversion before 'class' In file included from GEOM_GenSK.cc:5: /usr/include/omniORB4/IOP_C.h:149: error: 'Rope' has not been declared /usr/include/omniORB4/IOP_C.h:158: error: expected ';' before '*' token Plus *lots *more errors presumably flowing from the unterminated #ifdef Sparc: libtool: compile: g++ -DPACKAGE_NAME=\Salome2 Project GEOM module\ -DPACKAGE_TARNAME=\SalomeGEOM\ -DPACKAGE_VERSION=\5.1.3\ -DPACKAGE_STRING=\Salome2 Project GEOM module 5.1.3\ -DPACKAGE_BUGREPORT=\webmaster.sal...@opencascade.com\ -DPACKAGE_URL=\\ -DPACKAGE=\SalomeGEOM\ -DVERSION=\5.1.3\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBDL=1 -DHAVE_LIBM=1 -DHAVE_NAMESPACES=/**/ -DYYTEXT_POINTER=1 -DWITH_NUMPY=/**/ -DHAVE_PTHREAD=1 -D__OSVERSION__=2 -DOMNIORB=/**/ -DCORBA_HAVE_POA=/**/ -DCORBA_ORB_INIT_HAVE_3_ARGS=/**/ -DCORBA_ORB_INIT_THIRD_ARG=/**/ -I. -I../../../GEOM_SRC_5.1.3/idl -I../idl -DOMNIORB_VERSION=4 -D__sparc__ -D__linux__ -DCOMP_CORBA_DOUBLE -DCOMP_CORBA_LONG -I/usr/include
Bug#595260: salome: FTBFS in parallel: cleanup/doc-installation race
tags 595260 pending thanks On Thu, 2010-09-02 at 11:20 -0400, Aaron M. Ucko wrote: Package: salome Version: 5.1.3-10 Severity: serious Justification: fails to build from source The automatic build of salome on i386, which appears to have been in parallel, ran into what looks like a race condition between cleaning subtrees after building their contents and building and installing documentation: Thanks Aaron, I noticed this. What's the best way around it, while preserving the performance of a parallel build? In the current version on alioth, build-indep-stamp is independent from build-arch-stamp, so I can't make one depend on the other to force -arch-stamp to complete before -indep-stamp starts. Is there a way to put a makefile barrier so all of the threads catch up before moving on? I'm not finding what I'm looking for in the make manual http://www.gnu.org/software/make/manual/html_node/Parallel.html . Ah, just hit on a solution: I'll have the documentation build in a separate directory. I'm still interested in the answer to the above though (makefile barriers). Just implemented and pushed this to alioth, hence pending above. Here are some relevant excerpts from the log (https://buildd.debian.org/fetch.cgi?pkg=salome;ver=5.1.3-10;arch=i386;stamp=128341 ), in order: [snip] I see failures on several other architectures as well, quite possibly due to the same issue (though I haven't actually checked); at any rate, could you please address it? Just checked: Sparc, IA64 and Alpha all attempted with -j 2 and failed; PPC and S390 used -j 1 and succeeded. Hmm, Sparc and IA64 fail in a different place, which doesn't appear to be related to the jobs issue. I'll file a separate bug. Thanks again, Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#595260: salome: FTBFS in parallel: cleanup/doc-installation race
On Thu, 2010-09-02 at 13:36 -0400, Aaron M. Ucko wrote: Adam C Powell IV hazel...@debian.org writes: Thanks Aaron, I noticed this. No problem; thanks for the quick response. What's the best way around it, while preserving the performance of a parallel build? Declaring .NOTPARALLEL: in debian/rules should cause make to run serially when working off of it but still pass -j to upstream's makefiles. Also, make supports order-only prerequisites (a relatively new feature, but available even in stable); if you declare build-indep-stamp: | build-arch-stamp it will take care to complete build-arch-stamp before starting on build-indep-stamp when building both but still allow building just build-indep-stamp. Thanks, these are really good to know! Ah, just hit on a solution: I'll have the documentation build in a separate directory. That sounds like it should work as well, thanks. Yeah I think I'll stick with this, it seems more elegant and in keeping with the new build style. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#593657: salome: cannot find libStdPlugin.so
clone 593657 -1 tags 593657 pending retitle -1 salome: Should not depend on libopencascade-visualization-dev severity -1 normal thanks Hi Denis, This bug has been fixed in alioth for a couple of weeks now, so I'm marking it pending. I'll fix the -visualization-dev issue next, and test the fix, then mark the new bug pending when I can get it to work. Thanks again! -Adam On Fri, 2010-08-20 at 09:06 -0400, Adam C Powell IV wrote: Hello Denis, On Fri, 2010-08-20 at 02:19 +0200, Denis Barbier wrote: Package: salome Version: 5.1.3-9 Severity: grave When switching to the MESH module, salome throws a fatal error, and console contains this message: could not open: StdPlugin ; reason: libStdPlugin.so: cannot open shared object file: No such file or directory Unable to load component Since salome cannot access the MESH module, it is IMO unusable, hence the severity of this bug. There are at least 2 ways to fix this problem: * Let salome depend on libopencascade-ocaf-dev. * Modify /usr/share/salome/resources/geom/Plugin to append -6.3.0 to library names I prefer the latter. Thanks, and nice job finding this root cause and solution! I'll fix it and test as soon as I get back to Salomé development next week. Unfortunately we need to wait for the package to get through the NEW queue before it makes sense to upload a new version. It's also worth asking: could a change like this let us drop the salome dependency on libopencascade-visualization-dev? As I recall, that dependency was added to avoid a similar error while loading a non-versioned plugin. -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#593657: salome: cannot find libStdPlugin.so
Hello Denis,
On Fri, 2010-08-20 at 16:32 +0200, Denis Barbier wrote:
On 2010/8/20 Adam C Powell IV wrote:
[...]
It's also worth asking: could a change like this let us drop the salome
dependency on libopencascade-visualization-dev? As I recall, that
dependency was added to avoid a similar error while loading a
non-versioned plugin.
[...]
Your log message for f995e2cb is not detailed enough, so it is hard to tell.
BTW I had a look at your recent commits, and was surprised to see that
you truncated my log message to keep only the first line on these
commits:
* Add AM_MAINTAINER_MODE into all configure.ac files
* Add --disable-dependency-tracking to configure flags
Do not ask me in 4 months why these changes are good for, I won't
remember why without detailed log messages ;)
And just curious, why don't you use gitk to cherry-pich commits? I
find this tool extremely useful.
Good points. I've been using gitg, which displays things nicely, but
doesn't make it straightforward to extract patches or move them between
repositories. I'll try gitk.
Also, I have been trying to keep my commit notes small, like changelog
entries. But you're right that it's better to have more detail in them,
so I'll copy your full entries from now on.
I'm afraid I saw this message from you *after* committing some changes
this morning...
Now back to your question, you set
export CSF_GraphicShr=${CASROOT}/lib/libTKOpenGl.so
in runSalome, which is shipped by libopencascade-visualization-dev. I
do not understand why, everything should work fine without setting
this variable, maybe you could simply remove this line from runSalome?
Ah, good idea, I'll try this. I think this variable was in upstream's
runSalome script, maybe from 3.2.6?
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
Bug#593657: salome: cannot find libStdPlugin.so
Hello Denis, On Fri, 2010-08-20 at 02:19 +0200, Denis Barbier wrote: Package: salome Version: 5.1.3-9 Severity: grave When switching to the MESH module, salome throws a fatal error, and console contains this message: could not open: StdPlugin ; reason: libStdPlugin.so: cannot open shared object file: No such file or directory Unable to load component Since salome cannot access the MESH module, it is IMO unusable, hence the severity of this bug. There are at least 2 ways to fix this problem: * Let salome depend on libopencascade-ocaf-dev. * Modify /usr/share/salome/resources/geom/Plugin to append -6.3.0 to library names I prefer the latter. Thanks, and nice job finding this root cause and solution! I'll fix it and test as soon as I get back to Salomé development next week. Unfortunately we need to wait for the package to get through the NEW queue before it makes sense to upload a new version. It's also worth asking: could a change like this let us drop the salome dependency on libopencascade-visualization-dev? As I recall, that dependency was added to avoid a similar error while loading a non-versioned plugin. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#590421: salome: FTBFS: mv: target `debian/tmp/usr/lib/python2.5/*-packages/salome/' is not a directory
Actually, this brings up an important question. I built it just fine last night with up-to-date unstable (i.e. python 2.6), and its python libraries etc. are in /usr/lib/python2.6/dist-packages . And it seems to start up and load the GEOM module okay with this arrangement. André do you know of any issues which would prevent it from running properly with 2.6? If not, we might just go ahead and use python 2.6; otherwise, I'll need to force it to completely use and depend on 2.5. I'm going to go ahead and try 100% 2.6 when I build tonight and will let you know if anything comes up. -Adam On Mon, 2010-08-02 at 12:51 -0400, Adam C Powell IV wrote: retitle 590421 salome: FTBFS: Update to Python 2.6 tags 590421 pending thanks The version in alioth builds working .debs with Python 2.6, so after a couple more changes to the package, I'll upload a working version. -Adam On Mon, 2010-07-26 at 09:03 +0200, Lucas Nussbaum wrote: Source: salome Version: 5.1.3-9 Severity: serious Tags: squeeze sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20100725 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[3]: Entering directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. make[3]: Leaving directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' make[2]: Leaving directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' make[1]: Leaving directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' mv debian/tmp/usr/idl debian/tmp/usr/share/ install -d debian/tmp/usr/share/aclocal mv debian/tmp/usr/salome_adm/unix/config_files/check_Kernel.m4 debian/tmp/usr/share/aclocal/salome.m4 for m4file in check_GUI.m4 check_GEOM.m4 check_Med.m4 check_RANDOMIZER.m4 check_SMESH.m4; do \ cat debian/tmp/usr/adm_local/unix/config_files/$m4file debian/tmp/usr/share/aclocal/salome.m4; \ done cp KERNEL_SRC_5.1.3/bin/killSalome debian/tmp/usr/bin/ chmod +x debian/tmp/usr/bin/killSalome mv debian/tmp/usr/lib/salome/bin/runSalome debian/tmp/usr/bin/ install -d debian/tmp/usr/share/applications cp -a debian/salome.desktop debian/tmp/usr/share/applications/ rm -f debian/tmp/usr/bin/appliskel/env.d/*.in \ debian/tmp/usr/bin/appliskel/env.d/*.obs mv debian/tmp/usr/lib/salome/lib/SalomePyQt.so debian/tmp/usr/lib/salome/lib/SalomePyQt.so.0 ln -s SalomePyQt.so.0 debian/tmp/usr/lib/salome/lib/SalomePyQt.so mv debian/tmp/usr/Tests debian/tmp/usr/share/salome/ rm -rf debian/tmp/usr/lib64 rm -rf debian/tmp/usr/doc rm -rf debian/tmp/usr/lib/salome/bin/appliskel rm -rf debian/tmp/usr/lib/salome/bin/HXX2SALOME_GENERIC_CLASS* rm -f debian/tmp/usr/lib/salome/bin/*.pyo debian/tmp/usr/lib/salome/bin/*.pyc rm -f debian/tmp/usr/lib/salome/bin/*.csh debian/tmp/usr/lib/salome/bin/*.ksh debian/tmp/usr/lib/salome/bin/*.bat for shscript in `ls debian/tmp/usr/lib/salome/bin/*.sh`; do \ shbase=`basename $shscript .sh`; \ mv debian/tmp/usr/lib/salome/bin/$shbase.sh debian/tmp/usr/lib/salome/bin/$shbase; \ done mv debian/tmp/usr/lib/salome/bin/*.xml debian/tmp/usr/lib/salome/bin/VERSION \ debian/tmp/usr/lib/salome/bin/*.tgz debian/tmp/usr/lib/salome/bin/*.awk \ debian/tmp/usr/share/salome/ install -d debian/salome/usr/lib/salome/bin mv debian/tmp/usr/lib/salome/bin/SALOME_ContainerPy.py debian/salome/usr/lib/salome/bin/SALOME_ContainerPy mv debian/tmp/usr/lib/salome/bin/*.py debian/tmp/usr/lib/python2.5/*-packages/salome/ mv: target `debian/tmp/usr/lib/python2.5/*-packages/salome/' is not a directory make: *** [install-stamp] Error 1 The full build log is available from: http://people.debian.org/~lucas/logs/2010/07/25/salome_5.1.3-9_lsid64.buildlog A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#590421: salome: FTBFS: mv: target `debian/tmp/usr/lib/python2.5/*-packages/salome/' is not a directory
retitle 590421 salome: FTBFS: Update to Python 2.6 tags 590421 pending thanks The version in alioth builds working .debs with Python 2.6, so after a couple more changes to the package, I'll upload a working version. -Adam On Mon, 2010-07-26 at 09:03 +0200, Lucas Nussbaum wrote: Source: salome Version: 5.1.3-9 Severity: serious Tags: squeeze sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20100725 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: make[3]: Entering directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. make[3]: Leaving directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' make[2]: Leaving directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' make[1]: Leaving directory `/build/user-salome_5.1.3-9-amd64-MMJfn6/salome-5.1.3/HXX2SALOME_SRC_5.1.3' mv debian/tmp/usr/idl debian/tmp/usr/share/ install -d debian/tmp/usr/share/aclocal mv debian/tmp/usr/salome_adm/unix/config_files/check_Kernel.m4 debian/tmp/usr/share/aclocal/salome.m4 for m4file in check_GUI.m4 check_GEOM.m4 check_Med.m4 check_RANDOMIZER.m4 check_SMESH.m4; do \ cat debian/tmp/usr/adm_local/unix/config_files/$m4file debian/tmp/usr/share/aclocal/salome.m4; \ done cp KERNEL_SRC_5.1.3/bin/killSalome debian/tmp/usr/bin/ chmod +x debian/tmp/usr/bin/killSalome mv debian/tmp/usr/lib/salome/bin/runSalome debian/tmp/usr/bin/ install -d debian/tmp/usr/share/applications cp -a debian/salome.desktop debian/tmp/usr/share/applications/ rm -f debian/tmp/usr/bin/appliskel/env.d/*.in \ debian/tmp/usr/bin/appliskel/env.d/*.obs mv debian/tmp/usr/lib/salome/lib/SalomePyQt.so debian/tmp/usr/lib/salome/lib/SalomePyQt.so.0 ln -s SalomePyQt.so.0 debian/tmp/usr/lib/salome/lib/SalomePyQt.so mv debian/tmp/usr/Tests debian/tmp/usr/share/salome/ rm -rf debian/tmp/usr/lib64 rm -rf debian/tmp/usr/doc rm -rf debian/tmp/usr/lib/salome/bin/appliskel rm -rf debian/tmp/usr/lib/salome/bin/HXX2SALOME_GENERIC_CLASS* rm -f debian/tmp/usr/lib/salome/bin/*.pyo debian/tmp/usr/lib/salome/bin/*.pyc rm -f debian/tmp/usr/lib/salome/bin/*.csh debian/tmp/usr/lib/salome/bin/*.ksh debian/tmp/usr/lib/salome/bin/*.bat for shscript in `ls debian/tmp/usr/lib/salome/bin/*.sh`; do \ shbase=`basename $shscript .sh`; \ mv debian/tmp/usr/lib/salome/bin/$shbase.sh debian/tmp/usr/lib/salome/bin/$shbase; \ done mv debian/tmp/usr/lib/salome/bin/*.xml debian/tmp/usr/lib/salome/bin/VERSION \ debian/tmp/usr/lib/salome/bin/*.tgz debian/tmp/usr/lib/salome/bin/*.awk \ debian/tmp/usr/share/salome/ install -d debian/salome/usr/lib/salome/bin mv debian/tmp/usr/lib/salome/bin/SALOME_ContainerPy.py debian/salome/usr/lib/salome/bin/SALOME_ContainerPy mv debian/tmp/usr/lib/salome/bin/*.py debian/tmp/usr/lib/python2.5/*-packages/salome/ mv: target `debian/tmp/usr/lib/python2.5/*-packages/salome/' is not a directory make: *** [install-stamp] Error 1 The full build log is available from: http://people.debian.org/~lucas/logs/2010/07/25/salome_5.1.3-9_lsid64.buildlog A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#589064: petsc: FTBFS: Unable to apply patches
Hello Sandro and Cyril, This is really bizarre, I've never seen anything like it. The patches apply, and upstream-p2 modifies TAGS. Then the clean target reverses the patches -- but upstream-p2 does *not* modify TAGS! It looks like it modifies everything else. Then the patches apply again, but TAGS is modified, so the patch fails. Ah, I think dh_clean is removing the TAGS files in .pc, so quilt forgets that they're part of the patches, and they don't get reverted. I think I know how to deal with this. Thanks, Adam On Wed, 2010-07-14 at 18:37 +0200, Cyril Brulebois wrote: Source: petsc Version: 3.1.dfsg-5 Severity: serious Justification: FTBFS Hi, your package FTBFS everywhere, since patches can't be applied: | 94 out of 95 hunks FAILED -- rejects in file TAGS | Patch upstream-p2.patch does not apply (enforce with -f) | dpkg-buildpackage: error: debian/rules build gave error exit status 2 Full build logs: https://buildd.debian.org/status/package.php?p=petsc Mraw, KiBi. -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#584551: libpetsc3.1 empty on non-amd64 architectures
On Tue, 2010-07-13 at 22:31 -0400, Adam C Powell IV wrote: On Tue, 2010-07-13 at 19:55 +0100, Adam D. Barratt wrote: On Fri, 2010-06-04 at 14:44 -0400, Adam C Powell IV wrote: On Fri, 2010-06-04 at 15:54 +0200, Johannes Ring wrote: Package: libpetsc3.1 Version: 3.1.dfsg-3 The package libpetsc3.1 is empty on all architectures except on amd64. $ dpkg -L libpetsc3.1 /. /usr /usr/lib /usr/share /usr/share/doc /usr/share/doc/libpetsc3.1 /usr/share/doc/libpetsc3.1/changelog.Debian.gz /usr/share/doc/libpetsc3.1/copyright Thanks Johannes. I think I know why this is, and will correct it in the next upload. This problem still manifests in 3.1.dfsg-4. Was the change you mentioned in the above message applied in that upload? I sent the RFH after -4 failed on the buildds (which I thought would fix the problem). Thanks. I'm sorry, that wasn't a very clear or helpful reply. I did try a couple of changes in -4, but they didn't help. After that I sent an RFH message to the debian-science list [1], and Johannes replied [2], but not to the bug. [1] http://lists.debian.org/debian-science/2010/07/msg6.html [2] http://lists.debian.org/debian-science/2010/07/msg00013.html -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#584551: RFH: petsc
On Mon, 2010-07-12 at 18:32 -0400, Adam C Powell IV wrote: On Mon, 2010-07-12 at 23:11 +0200, Johannes Ring wrote: Hi Adam, On Wed, Jul 7, 2010 at 5:51 PM, Adam C Powell IV hazel...@debian.org wrote: Hello, I'm having two problems with PETSc, and need some help. Second, I just uploaded a new version, and although the build process reports that it builds the libraries just fine, they are not installed during the install step -- though on my machine it all works fine. This seems odd to me, as install is just a matter of copying everything: cp -a linux-gnu-c-opt/lib debian/libpetsc3.1-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/ The linux-gnu-c-opt/lib directory is PETSC_LIB_DIR, but it must be empty, because the corresponding directory in the package is empty. Can someone else try to build it, and let me know what's in the linux-gnu-c-opt/lib directory at the end? I built PETSc in pbuilder and this is the contents in the linux-gnu-c-opt/lib folder: # ls -lh linux-gnu-c-opt/lib/ total 19M -rw-r--r-- 1 root root 13M Jul 12 20:33 libpetsc.a -rwxr-xr-x 1 root root 6.0M Jul 12 20:33 libpetsc.so Thanks very much Johannes. I'm consistently getting: % ls -lh linux-gnu-c-opt/lib/ total 19M -rw-r--r-- 1 hazelsct 1003 13M 2010-07-06 23:39 libpetsc.a lrwxrwxrwx 1 hazelsct 1003 15 2010-07-06 23:39 libpetsc.so - libpetsc.so.3.1* -rwxr-xr-x 1 hazelsct 1003 6.0M 2010-07-06 23:39 libpetsc.so.3.1* The install step should be putting all of these into debian/libpetsc-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/lib but for some reason the buildds are not getting the libpetsc.a or the .so symlink, let alone the name-versioned lib... Okay, you've given me some ideas, now back to the drawing board. D'oh, I'm an idiot! There's no patch target in PETSc's debian/rules. I'll try that, so the patches actually apply on the buildds. Yup, buildd logs show that the clean target removes all the patches, then it goes ahead and builds without re-applying them. That should also get rid of rpath in environment variables, closing another bug. Fixing that right now and uploading... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#584551: libpetsc3.1 empty on non-amd64 architectures
On Tue, 2010-07-13 at 19:55 +0100, Adam D. Barratt wrote: On Fri, 2010-06-04 at 14:44 -0400, Adam C Powell IV wrote: On Fri, 2010-06-04 at 15:54 +0200, Johannes Ring wrote: Package: libpetsc3.1 Version: 3.1.dfsg-3 The package libpetsc3.1 is empty on all architectures except on amd64. $ dpkg -L libpetsc3.1 /. /usr /usr/lib /usr/share /usr/share/doc /usr/share/doc/libpetsc3.1 /usr/share/doc/libpetsc3.1/changelog.Debian.gz /usr/share/doc/libpetsc3.1/copyright Thanks Johannes. I think I know why this is, and will correct it in the next upload. This problem still manifests in 3.1.dfsg-4. Was the change you mentioned in the above message applied in that upload? I sent the RFH after -4 failed on the buildds (which I thought would fix the problem). Thanks. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#585837: salome-dev and libsalome-dev: error when trying to install together
tags 585837 pending thanks On Mon, 2010-06-14 at 10:22 +0200, Ralf Treinen wrote: Package: libsalome-dev,salome-dev Version: libsalome-dev/5.1.3-8 Version: salome-dev/5.1.3-9 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2010-06-14 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: [snip] Errors were encountered while processing: /var/cache/apt/archives/salome-dev_5.1.3-9_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/include/salome/AbstractEdge.hxx [snip] This bug is assigned to both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. Thanks for pointing this out. I got some of the conflicts, but forgot this one. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
