Bug#1063752: custodian: Inappriate maintainer address
Might this have been a one-time glitch? The list receives mail from the ftpmaster role address routinely, before and after the bug report: https://alioth-lists.debian.net/pipermail/debichem-devel/2024-February/author.html#16139 If there are no other reported incidents, I'd suggest closing the bug. -- Nicholas Breen nbr...@debian.org
Bug#1009383: retitle 1011392
package ftp.debian.org retitle 1011392 RM: gromacs [armel armhf i386 mipsel] -- ROM, ANAIS; upstream support dropped for 32-bit archs; blocking transition to testing thanks
Bug#1009383: gromacs: FTBFS: AttributeError: module 'collections' has no attribute 'Iterable'
tags 1009383 + pending thanks Fix pending in git, which is (preferably) waiting on upload until votca finally clears NEW -- Nicholas Breen nbr...@debian.org
Bug#855461: esniper: again fails to login
found 855461 thanks esniper 2.35 once again cannot login to eBay, and upstream discussion suggests that only a major rewrite will solve the problem: https://sourceforge.net/p/esniper/bugs/797/ https://sourceforge.net/p/esniper/bugs/803/ (last entry in particular) It probably should not ship with bullseye in this state. -- Nicholas Breen nbr...@debian.org
Bug#980634: [Debichem-devel] Bug#980634: gromacs: FTBFS: Errors while running CTest
reassign 980634 src:mpich 3.4-4 affects 980634 src:gromacs close 980634 3.4-5 thanks On Wed, Jan 20, 2021 at 09:41:19PM +0100, Lucas Nussbaum wrote: > Source: gromacs > Version: 2020.4-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20210120 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > 1/30 Test #1: TestUtilsUnitTests ...***Exception: SegFault > > 0.10 sec > > [1611165257.171056] [ip-172-31-13-129:15115:0] rdmacm_cm.c:638 UCX > > ERROR rdma_create_event_channel failed: No such device > > [1611165257.171089] [ip-172-31-13-129:15115:0] ucp_worker.c:1432 UCX > > ERROR failed to open CM on component rdmacm with status Input/output error [...] > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects Reassigning to mpich and then closing, for the sake of bug tracking - building against 3.4-4 fails, but the 3.4-5 upload from earlier today resolves this bug (thanks Alistair!). It's possible that this is another iteration of #980033 on ucx, except that it affected MPICH instead of OpenMPI here. Not sure enough about that to merge the bugs. I can successfully build the OpenMPI portion of gromacs in sid right now. -- Nicholas Breen nbr...@debian.org
Bug#980634: [Debichem-devel] Bug#980634: gromacs: FTBFS: Errors while running CTest
This is *probably* a side effect of the ongoing, messy mpich/pmix/ucx transition in unstable, but that has so many moving parts that it'll take a bit to figure out which version of which package is responsible.
Bug#973639: [Debichem-devel] Bug#973639: closed by Debian FTP Masters (reply to Nicholas Breen ) (Bug#973639: fixed in gromacs 2021~beta2-1)
On Thu, Nov 12, 2020 at 05:24:34PM +0100, Andreas Beckmann wrote: > The SONAME of the file > /usr/lib/x86_64-linux-gnu/libgmxapi.so.0.2.0 > is libgmxapi.so.0, thus we still have a file conflict on the SONAME > symlink libgmxapi.so.0 in both libgromacs5 and libgromacs6. Agh, right you are. Thanks for catching that. > PPS: I still think that you would make your life easier with three > separate library packages: libgromacs6, libgmxapi0, libnblib0 I'd hoped to put that off until the gmxapi/nblib APIs stabilized - right now they're effectively coupled to a single version of the source package overall. But yes, definitely the correct long-term fix, possibly short-term as well. -- Nicholas Breen nbr...@debian.org
Bug#959946: grace: fails to start: failed request: 12 (X_ConfigureWindow)
On Thu, May 07, 2020 at 06:52:58PM +0800, Drew Parsons wrote: > On a clean installation, grace fails to launch: > > $ xmgrace > X Error of failed request: BadValue (integer parameter out of range for > operation) > Major opcode of failed request: 12 (X_ConfigureWindow) > Value in failed request: 0x0 > Serial number of failed request: 2821 > Current serial number in output stream: 2822 Hello Drew, I cannot reproduce this on any of three systems. If you have a residual /etc/X11/app-defaults/XMgrace, can you try removing it? Can you generate a log with xtrace? -- Nicholas Breen nbr...@debian.org
Bug#949774: marked as pending in votca-tools
Control: tag -1 pending Hello, Bug #949774 in votca-tools reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/votca-tools/commit/8f495a5f5591be80af04ed7c887cdc11b7a9ec8a Add Breaks/Replaces: libvotca-tools-dev (<< 1.6~rc1-1) to votca-tools for a file move. (Closes: #949774) (this message was generated automatically) -- Greetings https://bugs.debian.org/949774
Bug#949669: [Debichem-devel] Bug#949669: votca-csg ftbfs with gromacs 2020-2
tags 949669 + pending thanks On Thu, Jan 23, 2020 at 01:55:14PM +0100, Paul Gevers wrote: > Source: votca-csg > Version: 1.5.1-1 > Severity: serious > Justification: ftbfs > Tags: ftbfs sid bullseye > > Dear maintainer, > > gromacs started a transition and I scheduled binNMUs for votca-csg. > However, they failed. Please investigate. Known issue, I just needed to wait for votca-tools to clear NEW, which it did a few hours ago. (votca-csg needs it as an updated build-dep.) Will upload the fix shortly.
Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)
On Sat, Feb 09, 2019 at 12:15:22AM +, Santiago Vila wrote: > Package: src:gromacs > Version: 2019-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package in buster but it failed: [...] > /usr/bin/mpicxx.openmpi -msse2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -O3 > -DNDEBUG -funroll-all-loops -fexcess-precision=fast > -L/usr/lib/openmpi/lib -Wl,-z,relro -Wl,-z,now -Wl,--as-needed > CMakeFiles/mdlib-test.dir/calc_verletbuf.cpp.o > CMakeFiles/mdlib-test.dir/mdebin.cpp.o CMakeFiles/mdlib-test.dir/settle.cpp.o > CMakeFiles/mdlib-test.dir/shake.cpp.o > CMakeFiles/mdlib-test.dir/simulationsignal.cpp.o > CMakeFiles/mdlib-test.dir/updategroups.cpp.o > CMakeFiles/mdlib-test.dir/updategroupscog.cpp.o > CMakeFiles/mdlib-test.dir/__/__/__/testutils/unittest_main.cpp.o -o > ../../../../bin/mdlib-test ../../../../lib/libtestutils.a > ../../../../lib/libgromacs_mdrun_mpi_d.openmpi.a ../../../../lib/libgmock.a > -fopenmp /usr/lib/x86_64-linux-gnu/libz.so > /usr/lib/x86_64-linux-gnu/libhwloc.so -lrt > /usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libblas.so > /usr/lib/x86_64-linux-gnu/liblapack.so /usr/lib/x86_64-linux-gnu/libblas.so > /usr/lib/x86_64-linux-gnu/liblapack.so -lm > collect2: error: ld returned 1 exit status > make[4]: *** > [src/gromacs/mdlib/tests/CMakeFiles/mdlib-test.dir/build.make:190: > bin/mdlib-test] Error 1 [...] Hi Santiago, I can't reproduce this build failure in a clean buster or sid chroot. Both build successfully. > The build was made in my autobuilder with "dpkg-buildpackage -A" > and it also fails here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gromacs.html > > where you can get a full build log if you need it. This is actually a different error. Is this running under pbuilder or a derivative? The test case that this build log failed on requires a semi-functional network setup - it doesn't need (or attempt to use) outside access, but it does at least need gethostbyname() to return a reachable address for the system's hostname, with localhost being fine. This does *not* work with the default pbuilder configuration, only with USENETWORK=yes. sbuild on the buildds works, as does a build outside a constrained environment. pbuilder also breaks further down the chain for a few tests that don't allow running as root, unless BUILDUSERID is also configured to a non-zero value. It does make testing more difficult! If those constraints can't be met and pbuilder is essential, it should be built with 'nocheck'. Since it's no problem for either the buildds or users in their own shell, I haven't considered those issues as serious bugs. -- Nicholas Breen nbr...@debian.org
Bug#866440: NMU for mcomix RC bug
Hi Krzysztof and Emfox,
#866440 has been an RC bug on mcomix for some months, and it is no longer
installable in unstable; I've uploaded a NMU to DELAYED/5 with the attached
patch. Please let me know if you'd like me to cancel that upload.
--
Nicholas Breen
nbr...@debian.org
diff -Nru mcomix-1.2.1/debian/changelog mcomix-1.2.1/debian/changelog
--- mcomix-1.2.1/debian/changelog 2016-02-20 23:35:20.0 -0800
+++ mcomix-1.2.1/debian/changelog 2018-05-29 21:35:28.0 -0700
@@ -1,3 +1,10 @@
+mcomix (1.2.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Replace Depends: python-imaging with python-pil. (Closes: #866440)
+
+ -- Nicholas Breen Tue, 29 May 2018 21:35:28 -0700
+
mcomix (1.2.1-1) unstable; urgency=low
* New upstream release (Closes: #813730, #810743)
diff -Nru mcomix-1.2.1/debian/control mcomix-1.2.1/debian/control
--- mcomix-1.2.1/debian/control 2016-02-20 23:29:23.0 -0800
+++ mcomix-1.2.1/debian/control 2018-05-29 21:35:28.0 -0700
@@ -10,7 +10,7 @@
Package: mcomix
Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-imaging
+Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-pil
Suggests: unrar
Description: GTK+ image viewer for comic books
MComix is an user-friendly, customizable image viewer. It is specifically
Bug#821734: libvotca-csg3: fails to upgrade from 'jessie' - trying to overwrite /usr/share/man/man7/votca-csg.7.gz
Unless someone else is already on it, I'll take care of this within the week, and that'll handle the necessary rebuild for the libgromacs1 -> libgromacs2 SONAME bump at the same time. -- Nicholas Breen nbr...@debian.org
Bug#831406: yorick FTBFS - linked to mpich
block 831406 by 831442 thanks The same bug is hitting one of my packages, seems to be an issue with mpich. Filed as https://bugs.debian.org/831442 . -- Nicholas Breen nbr...@debian.org
Bug#797744: [Debichem-devel] Bug#797744: gromacs: shared library in a package that is not renamed with its SONAME
On Wed, Sep 02, 2015 at 09:15:58AM +0100, Simon McVittie wrote: > Source: gromacs > Version: 5.0.6-1 > Severity: serious > Justification: Policy 8.1 > > The gromacs binary package contains a public shared library > (libgromacs.so.0), and votca-csg depends on it. > > Policy §8.1 says: > > > The run-time shared library must be placed in a package whose name > > changes whenever the SONAME of the shared library changes. Yeah, that's a leftover from before votca entered the archive, and gromacs fell under the "Shared libraries that are internal to a particular package" wording, making it exempt from section 8. I'll see if I can split it for 5.1, but it'll be at least three weeks until I can get to working on that. On the plus side, maybe the C++ transitions will have settled down a little by then. -- Nicholas Breen nbr...@debian.org
Bug#797743: [Debichem-devel] Bug#797743: gromacs: ABI transition needed for libstdc++ v5
On Wed, Sep 02, 2015 at 09:09:25AM +0100, Simon McVittie wrote: > Source: gromacs > Version: 5.0.6-1 > Severity: serious > Justification: breaks ABI without a package rename > Tags: sid stretch > User: debian-...@lists.debian.org > Usertags: libstdc++-cxx11 > > Background[1]: libstdc++6 introduces a new ABI to conform to the > C++11 standard, but keeps the old ABI to not break existing binaries. > Packages which are built with g++-5 from experimental (not the one > from testing/unstable) are using the new ABI. Libraries built from > this source package export some of the new __cxx11 or B5cxx11 symbols, > dropping other symbols. If these symbols are part of the API of > the library, then this rebuild with g++-5 will trigger a transition > for the library. > > In the case of gromacs, std::string appears in installed headers, > so it seems very likely that a transition is needed. Isn't this just #791061 again? To the best of my knowledge, nothing external uses those. -- Nicholas Breen nbr...@debian.org
Bug#774558: grace: dpkg trigger cycle via gsfonts
On Sun, Jan 04, 2015 at 01:09:52PM +0100, Niels Thykier wrote: Package: grace Version: 1:5.1.24-2 Severity: serious [...] This simulates an upgrade scenario, where gsfonts might be temporarily ^^^ deconfigured while gsfonts remains configured. If this happens, dpkg ^^^ ?? * Use no-await triggers. *CAVEAT*: not always applicable. Known suitable use cases includes cache handling, where the cache is allowed to be out of date tempoarily. That's fine for this application. I'll upload shortly. -- Nicholas Breen nbr...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759974: [Debichem-devel] Bug#759974: votca-csg: FTBFS: Could NOT find GROMACS (missing: GROMACS_LIBRARY GROMACS_INCLUDE_DIR)
On Sat, Aug 30, 2014 at 02:57:22PM -0700, Lucas Nussbaum wrote: Source: votca-csg Version: 1.2.3-1 [snip] -- checking for module 'libgmx' -- package 'libgmx' not found -- Could NOT find GROMACS (missing: GROMACS_LIBRARY GROMACS_INCLUDE_DIR) CMake Error at src/libcsg/CMakeLists.txt:25 (message): gromacs not found, make sure you have installed at least the gromacs-4.0.7 and it's dev package. If the gromacs module was not found above, make sure you have sourced GMXRC or set PKG_CONFIG_PATH yourself. If you have a double precision version of gromacs enable to build against it with -DGMX_DOUBLE=ON. If you have gromacs-5.0 installed enable to build against it with -DWITH_GMX_DEVEL=ON. Gromacs support can be disable it with -DWITH_GMX=OFF. This one looks like it's indirectly my fault - I just uploaded gromacs 5.0 to unstable a few days ago, and didn't realize it changed a build parameter in votca-csg. libgmx and libmd are replaced by the merged libgromacs. Christoph, do you want to upload a new package? I can also make the suggested CMake change and upload it myself if you'd prefer. - Nicholas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758237: grace contains nonfree cephes library
On Fri, Aug 15, 2014 at 01:08:56PM -0400, Legimet wrote: There was a discussion back in 2004 about the author being willing to relicense it under a BSD license [2], but nothing happened after that. It seems that there actually was further progress, resulting in an explicit GPL-2 license: http://anonscm.debian.org/cgit/collab-maint/labplot.git/tree/debian/copyright However, this was not also filed as a grace bug at the time, so this is not documented in the grace packaging - which I agree is a bug that must be fixed. Looks like debian/copyright is overdue for an overhaul in general. -- Nicholas Breen nbr...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. If getting t1lib in all its forms out of the archive is the goal, then yes, grace would have to be removed. Rewriting it is not practical and there doesn't seem to be anyone with the time + desire + skillset to adopt t1lib. However, there's also no real replacement for grace itself available. -- Nicholas Breen nbr...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680825: FTBFS fixed with cmake 2.8.9-rc3
tags 680825 wheezy stop There is no longer a FTBFS when using cmake 2.8.9~rc3-1, uploaded today. This bug can be closed as soon as cmake transitions to testing. - N -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On Wed, Jul 11, 2012 at 03:44:22PM -0400, Brad King wrote: This should fix it: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8720aa04 Ideally we should add a test for this case but I have no time now. We'll include the fix in the next 2.8.9 rc. Thank you very much for tracking down the bug. Modestas, do you think it's worth applying that patch to the cmake package and requesting a freeze exception from the RMs? I'm not sure if it affects any other packages in the archive, but I cannot find any other outright failures in this batch of FTBFS bugs that date from after the 2.8.9-rc1 upload, so it might well be just this one case. Otherwise I'll hash out a workaround for gromacs to keep it from getting removed as RC-buggy. - Nicholas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680825: [Debichem-devel] Bug#680825: gromacs: FTBFS: mv: cannot stat `/«PKGBUILDDIR»/debian/gromacs-mpich/usr/lib/*.so': No such file or directory
On Tue, Jul 10, 2012 at 02:11:46PM +0200, Evgeni Golov wrote: Hi, the attached patch solves the issue. Not tagging patch or intend to NMU however, as I think it should be further investigated why it fails (it does not build the libs anymore when building mdrun target only). Thanks. I *suspect* it's something new in cmake 2.8.9-rc1, since gromacs built perfectly well a month ago under cmake 2.8.8, and the MPI implementations haven't changed in that time (and _both_ of them fail to build now), though I won't be able to work on it for a day or two yet. - Nicholas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595859: [Debichem-devel] Bug#595859: gnome-chemistry-utils: FTBFS in squeeze: moz-plugin.c:24:19: error: npapi.h: No such file or directory
reassign 595859 xulrunner-dev found 595859 1.9.1.11-2 tag 595859 + squeeze merge 595859 595881 thanks On Tue, Sep 07, 2010 at 12:53:54AM +0200, Lucas Nussbaum wrote: [snip] moz-plugin.c:24:19: error: npapi.h: No such file or directory moz-plugin.c:28:22: error: npupp.h: No such file or directory Looks like the xulrunner-dev mismatch in squeeze, which in turn causes many other packages to FTBFS until it's brought back into sync. Reassigning there and merging with the existing bug report. -- Nicholas Breen nbr...@ofb.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583956: grace: fails to start after gsfonts upgrade
reassign 583956 gsfonts forcemerge 583964 583956 thanks On Mon, May 31, 2010 at 10:53:30PM +0200, Francesco Poli (t1000) wrote: After the following upgrade: [UPGRADE] gsfonts 1:8.11+urwcyr1.0.7~pre44-4 - 1:8.11+urwcyr1.0.7~pre44-4.1 xmgrace stopped working: ...which is not a bug in grace. gsfonts maintainers, please consider reversing #582113 for now. defoma support in gsfonts is still needed while defoma-using applications depend on it. -- Nicholas Breen nbr...@ofb.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: [Debichem-devel] Bug#531419: gromacs: FTBFS: error: couldn't find library libmd_mpi_d_openmpi.so.5
(Adding Cc: #531522, the bug I cloned to openmpi.) On Tue, Jun 02, 2009 at 11:38:20PM +0200, Manuel Prinz wrote: ACK. But from what I see and experienced, I get the feeling that it's related to eglibc. Anyway, here is my backtrace (amd64): Doesn't seem like it was necessarily the eglibc switch, though. Downgrading to openmpi 1.3-2 on an otherwise up-to-date sid box doesn't show the bug. fakeroot 1.12.2, libc6 2.9-13. - Nicholas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: [Debichem-devel] Bug#531419: gromacs: FTBFS: error: couldn't find library libmd_mpi_d_openmpi.so.5
On Mon, Jun 01, 2009 at 12:57:49PM +0200, Kurt Roeckx wrote: Source: gromacs Version: 4.0.5-2 Severity: serious Hi, There was an error while trying to autobuild your package: [...] Looks like another victim of #531184, the MPI update-alternatives bug you filed on Saturday; should clear itself up once that's resolved. Thanks for the report. (There's a _different_ FTBFS bug on powerpc, but in theory that'll be fixed by the next gromacs upload...) -- Nicholas Breen nbr...@ofb.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531419: [Debichem-devel] Bug#531419: gromacs: FTBFS: error: couldn't find library libmd_mpi_d_openmpi.so.5
clone 531419 -1
reassign -1 libopenmpi-dev
retitle -1 libopenmpi-dev: mpicc segfaults under fakeroot
block 531419 by -1
thanks
Okay, it looks like the root cause is something that's appeared recently in
openmpi - it fails under 1.3.2-2, but works under 1.3-2. Manuel, I'm cloning
the bug for tracking purposes, but I'm certainly not sure that it's actually an
OpenMPI bug at heart. Have you seen anything else like this?
% echo int main(void) { return 0; } test.c
% mpicc.openmpi test.c ; echo $?
0
% fakeroot mpicc.openmpi test.c ; echo $?
Segmentation fault
139
No failures with the other MPI implementations, nor with OpenMPI 1.3. I can
put it under gdb but am missing some debugging libraries in the middle:
% fakeroot gdb mpicc.openmpi
[...]
(gdb) run test.c
Starting program: /usr/bin/mpicc.openmpi conftest.c
[Thread debugging using libthread_db enabled]
[New Thread 0xb7dc46c0 (LWP 6958)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dc46c0 (LWP 6958)]
__libc_calloc (n=1, elem_size=20) at malloc.c:3932
3932malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0 __libc_calloc (n=1, elem_size=20) at malloc.c:3932
#1 0xb7f83086 in _dlerror_run (operate=0xb7f82d90 dlsym_doit,
args=0xbfd3002c) at dlerror.c:142
#2 0xb7f82d43 in __dlsym (handle=0x, name=0xb800f16a open) at
dlsym.c:71
#3 0xb800db73 in load_library_symbols () from
/usr/lib/libfakeroot/libfakeroot-sysv.so
#4 0xb800e687 in tmp___xstat () from /usr/lib/libfakeroot/libfakeroot-sysv.so
#5 0xb800daa3 in __xstat () from /usr/lib/libfakeroot/libfakeroot-sysv.so
#6 0xb7fbcefc in ?? () from /usr/lib/libopen-pal.so.0
#7 0x0003 in ?? ()
#8 0xb7fc948e in ?? () from /usr/lib/libopen-pal.so.0
#9 0xbfd300e4 in ?? ()
#10 0x1b2e in ?? ()
#11 0xbfd300e4 in ?? ()
#12 0x0003 in ?? ()
#13 0x0003 in ?? ()
#14 0xbfd30164 in ?? ()
#15 0xb7f20ff4 in ?? () from /lib/i686/cmov/libc.so.6
#16 0x0001 in ?? ()
#17 0xb7dc8d0c in ?? () from /lib/i686/cmov/libc.so.6
#18 0xbfd30148 in ?? ()
#19 0xb7ee4429 in *__GI__dl_addr (address=0xb7e34e70, info=0xbfd30184,
mapp=0xbfd30194,
symbolp=0xb7f2260c) at dl-addr.c:146
#20 0xb7e35096 in ptmalloc_init () at arena.c:571
#21 0xb7e386bc in malloc_hook_ini (sz=12, caller=0xb7f939ab) at hooks.c:37
#22 0xb7e38535 in *__GI___libc_malloc (bytes=12) at malloc.c:3546
#23 0xb7f939ab in opal_class_initialize () from /usr/lib/libopen-pal.so.0
#24 0xb7fb3227 in opal_output_init () from /usr/lib/libopen-pal.so.0
#25 0xb7f96205 in opal_init_util () from /usr/lib/libopen-pal.so.0
#26 0x08049b62 in main (argc=2, argv=0xbfd30404) at
../../../../../opal/tools/wrappers/opal_wrapper.c:480
I confess that the peculiar interactions of compilers, fakeroot, and (e)glibc
put me well out of my depth.
--
Nicholas Breen
nbr...@ofb.net
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517707: [Debichem-devel] Bug#517707: FTBFS mopac7_1.14-2(mipsel/unstable)
On Sat, Apr 11, 2009 at 07:26:53PM +0200, Daniel Leidert wrote: In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519006#19 Matthias suggested to give the binutils from experimental a try. Michael, do you have the time to do this on a mips/mipsel buildd? It FTBFSes in the same way on my mips box (SGI O2) in a chroot of current sid + binutils 2.19.51.20090315-1 from experimental. - Nicholas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456860: gromacs: FTBFS: checking size of int... configure: error: cannot compute sizeof (int)
block 456860 by 456721 thanks On Tue, Dec 18, 2007 at 09:51:19AM +0100, Lucas Nussbaum wrote: Package: gromacs During a rebuild of all packages in sid, your package failed to build on i386. This is collateral damage from #456721, and should be corrected by a re-rebuild once that's been closed. I'll keep this bug open until then. -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456860: gromacs: FTBFS: checking size of int... configure: error: cannot compute sizeof (int)
On Wed, Dec 19, 2007 at 12:47:55AM +0100, Manuel Prinz wrote: I just finished to develop a patch for our broken OpenMPI package. It looks quite good in first tests. I'll do more tomorrow and will include GROMACS. So I hope we'll have a fixed openmpi package in a few days. I'll keep you informed about the progress! Is it somewhere publically available? I'd be happy to test it as well, it'll be interesting to see if it also works with GROMACS 3.3.3-beta packages. - Nicholas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451991: gromacs-openmpi: Binaries missing
we already talked about that bug. It affects the current version in unstable on amd64 and is reprocudible in a lenny and sid chroot. More peculiarly, it's affected the i386 build[1], which I was able to build successfully in a clean sid chroot with no special considerations. Additionally, the package I built has no lam4c2 dependence. I strongly suspect these are two manifestations of the same bug. - Nicholas [1] http://packages.debian.org/sid/gromacs-openmpi/i386/filelist -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451991: Bug#451993: gromacs-openmpi: Package depends on lam4c2
severity 451193 serious clone 451993 -1 reassign -1 libopenmpi-dev retitle -1 libopenmpi-dev: /usr/lib/libmpi.so conflicts with other packages' alternatives merge 451991 451993 retitle 451993 gromacs-openmpi: build fails silently if libopenmpi-dev installed before lam4-dev/libmpich1.0-dev block 451991 by -1 thanks On Mon, Nov 19, 2007 at 06:36:35PM +0100, Manuel Prinz wrote: gromacs-openmpi depends on lam4c2 which seems to be wrong. I think it's related to #451991 but I'm not sure, so I file it as a seperate bug. (I'm not sure about the severity either.) As best I can tell, the problem here is that libopenmpi-dev ships /usr/lib/libmpi.so as a file (symlink) in the package itself, while both LAM (lam4c2, lam4-dev) and MPICH (libmpich1.0ldbl, libmpich1.0-dev) do not have it in the file list, but *do* reference it as part of their update-alternatives(1) configuration. As a result, depending on what order the packages are installed in, you can end up with a symlink pointing to a LAM or MPICH library, while dpkg still registers the filename as belonging to OpenMPI. This in turn causes link errors during compilation and improper dependencies from dpkg-shlibdeps. As a demonstration, starting from a clean slate: # aptitude purge libmpich1.0ldbl libmpich1.0-dev lam4c2 lam4-dev libopenmpi1 libopenmpi-dev # aptitude install libopenmpi1 libopenmpi-dev # aptitude install lam4c2 lam4-dev libmpich1.0ldbl libmpich1.0-dev # ls -l /usr/lib/libmpi.so* lrwxrwxrwx 1 root root 27 2007-11-19 18:54 /usr/lib/libmpi.so - /etc/alternatives/libmpi.so lrwxrwxrwx 1 root root 15 2007-11-19 18:54 /usr/lib/libmpi.so.0 - libmpi.so.0.0.0 -rw-r--r-- 1 root root 513660 2007-10-06 06:06 /usr/lib/libmpi.so.0.0.0 Here, libmpi.so.0.0.0 is from libopenmpi1. The libmpi.so link is where the problem arises: # readlink -f /usr/lib/libmpi.so /usr/lib/liblam.so.4.0 # dpkg -S /usr/lib/libmpi.so /usr/lib/liblam.so.4.0 libopenmpi-dev: /usr/lib/libmpi.so lam4c2: /usr/lib/liblam.so.4.0 I've set the bug severity at serious because this is a filename overlap between packages (Policy 10.1), which dpkg does not catch because LAM/MPICH create the conflicting filename in their postinst scripts. If OpenMPI is installed *after* the other two, builds work as expected, but this can't be enforced on the buildds. Both lam4-dev and libopenmpi-dev ship their equivalents to libmpi.so under different original filenames and directories (/usr/lib/liblam.so and /usr/lib/mpich/lib/shared/libmpich.so, respectively), underneath an update-alternatives group using /usr/include/mpi as the master node. In turn, binaries generally link against the original library path/filename instead of /usr/lib/libmpi.so. OpenMPI does not do so - its dependencies link against /usr/lib/libmpi.so directly, and it doesn't share the same update-alternatives master node. % mpicc.lam -showme gcc -I/usr/lib/lam/include -pthread -L/usr/lib/lam/lib -llammpio -llamf77mpi -lmpi -llam -lutil -ldl ^^ no equivalent with mpicc.openmpi -showme I think the solution is relocating OpenMPI's libmpi.so in a similar manner to the other MPI packages, joining the same update-alternatives scheme, and then recompiling its reverse dependencies. Does that sound correct, or even reasonably possible? -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451193: Oops!
severity 451193 wishlist thanks Sorry about that, I typo'ed the bug number I was aiming for (451993). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446726: file conflicts between packages
On Mon, Oct 15, 2007 at 03:17:52PM +0200, Manuel Prinz wrote: As a GROMACS user, I'd prefer to keep the name genbox since it's one of the tools in the GROMACS suite that is used quite often and a lot of my scripts would need an update to work on a name change. I think there are more people in the same situation. I agree with Manuel on this point; also, since GROMACS runs are often set up on one machine and then uploaded to a number-crunching cluster somewhere else (which is quite possibly running a different OS entirely), script breakage due to changing the command name is even more likely. #403879 wasn't a problem since that command is nearly unused, but it's the rare GROMACS run that *doesn't* need genbox. However, radiance also ships a large number of files in /usr/bin, which I assume are scriptable too? Is renaming the command likely to cause equivalent problems for your users? -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446726: file conflicts between packages
On Mon, Oct 15, 2007 at 09:03:41PM +0200, Bernd Zeimetz wrote: As Your package is the older package, and genbox is probably not one of the very often used tools, I'll rename it in Debian. It sounds like that will be the least disruptive overall. Thanks very much. I'll be making a new upload of gromacs soon and will add a versioned Conflicts: radiance (= 3R8+20070924.dfsg-1), to ensure we don't accidentally end up with the clashing versions in testing. -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435645: Bug seen with 2.1.5-4
On Tue, Aug 14, 2007 at 01:51:07PM +0200, Frank Lichtenheld wrote: This is definetly no eject error message. It comes from pumount. You will either need to list /cdrom in /etc/fstab (since pumount should fall back to umount then, if it doesn't, please reassign this bug there) or you need to mount your cdrom under /media/something, or you need to deinstall pmount. Indeed, I can confirm that it is pmount -- ejecting a CD works perfectly for a user _not_ in the plugdev group. Thanks for the pointer; reassigning the bug appropriately. Vincent: The bug appears to have appeared between 0.9.16-1 (works as expected) and 0.9.16-2 (fails, as does -3). /cdrom is listed in fstab: /dev/cdrom /cdrom iso9660 ro,user,noauto0 0 -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435645: Bug seen with 2.1.5-4
found 435645 2.1.5-4 thanks I also see this behavior on my system with eject 2.1.5-4. % eject -v eject: using default device `cdrom' eject: device name is `cdrom' eject: expanded name is `/dev/cdrom' eject: `/dev/cdrom' is a link to `/dev/scd0' eject: `/dev/scd0' is mounted at `/cdrom' eject: unmounting device `/dev/scd0' from `/cdrom' Error: mount point /cdrom is not below /media/ eject: unmount of `/cdrom' failed The problem appears to be that I have a /media directory, which does not contain the CD mount point. If I rename /media, eject works as expected. I'm not sure where the bug itself actually lies -- since I don't use the optical drive daily, I can't say for sure when it stopped working for me. Perhaps realpath() has changed behavior recently? I don't see anything relevant in the libc6 changelog more recent than #239427 (April 2007 upload, and it's definitely worked since then!), though I could easily have overlooked something in the last few weeks' uploads. -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403380: Bug#403879: ffscan filename conflict
How would you like to handle this bug? I'm slightly reluctant to rename the binary in gromacs for fear of breaking user scripts, but also recognize that forutil has been using the name for many more years. It's unclear to me which package change would be less disruptive. Well, unless it looks like forutil should be removed, I think it has the older rights. However, I can understand you about breaking scripts. How about the following: You rename the binary inside of gromacs, and until release of etch, you use an symlink inside your package (plus a conflict on gromacs), so that no existing script is broken now, but people are encouraged to use the new name? (This would be a policy violation as well, but I would be willing to etch-ignore this one, because there is a good reason, and it doesn't really break stuff.) I'd prefer not to have them conflict, since FORTRAN use is still common in gromacs's field -- co-installability would be a benefit. Best to bite the bullet and rename one, I think. Since I haven't heard from Taketoshi, I'll rename the binary in gromacs and document the change appropriately. I'd hate to see either of our packages miss the etch release by delaying too long. -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403380: ffscan filename conflict
How would you like to handle this bug? I'm slightly reluctant to rename the binary in gromacs for fear of breaking user scripts, but also recognize that forutil has been using the name for many more years. It's unclear to me which package change would be less disruptive. Neither package is significantly more popular than the other, judging by the popcon results: #rank nameinst vote old recent no-files 13093 gromacs 47122312 0 14586 forutil 33 622 5 0 -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360374: gromacs: package overlap with mono-mcs
On Sat, Apr 01, 2006 at 07:54:01PM +0200, Laurent Bonnaud wrote: Unpacking gromacs (from .../gromacs_3.3-1_i386.deb) ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/usr/bin/disco', which is also in package mono-mcs Unpacking gromacs-doc (from .../gromacs-doc_3.3-1_all.deb) ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/usr/share/man/man1/disco.1.gz', which is also in package mono-mcs Thanks for catching that. I'd checked some of the more common sounding filenames for package conflicts, but clearly I missed one. mono-mcs is certainly much more popular, so I'll rename the binary in this package. -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
