Bug#901477: mawk-1.3.3-17+b3 segfaults
Package: mawk Version: 1.3.3-17+b3 Run https://github.com/flang-compiler/flang/blob/master/runtime/libpgmath/tools/mth_z2yy.awk in mawk: $ mawk -v TARGET=X8664 -f mth_z2yy.awk Segmentation fault While gawk works: $ gawk -v TARGET=X8664 -f mth_z2yy.awk The most recent version of mawk from: https://github.com/ThomasDickey/mawk-snapshots/commit/f448f2385c499fabaa9a342bb1f3e207db67daf8 works. -- Christoph Junghans Web: http://www.compphys.de
Bug#851787: exodusii: integrate exodusii into trilinos?
The last exodusii release (v6.09) is from Oct. 2014 and SEACAS' exodus has a couple of bug fixes and extra features (e.g. exodiff executable) of top of that. Plus, tarballs have been taken down from sourceforge. -- Christoph Junghans Web: http://www.compphys.de
Bug#824511: Perl-5.22.2 does not inherit shell enviorment
Package: perl
Version: 5.22.2-1
The behavior when calling an exported shell function from whitin perl
has changed in version 5.22.2
$ bash
$ fct() { echo "Hello from within function";}
$ export -f fct
$ perl -e '$x=`bash -c "fct"`; print $x'
bash: fct: command not found
In contrast in version 5.20.2-3
$ bash
$ fct() { echo "Hello from within function";}
$ export -f fct
$ perl -e '$x=`bash -c "fct"`; print $x'
Hello from within function
On Fedora 23 (perl-5.22.1) and Gentoo (perl-5.22.2) everything works
as expected.
This was found using votca-csg-1.3, upstream bug:
https://github.com/votca/csg/issues/179
--
Christoph Junghans
Web: http://www.compphys.de
Bug#802357: [Debichem-devel] Bug#802357: votca-csg: FTBFS: fatal error: copyrite.h: No such file or directory
As I said on Bug#797744 to support gromacs 5.1 one needs the following patch: <http://pkgs.fedoraproject.org/cgit/votca-csg.git/tree/votca-csg-1.2.4-gmx51.patch> This patch got incorporated into Version 1.3_rc1, which is available on github: <https://github.com/votca/tools/releases/tag/v1.3_rc1> <https://github.com/votca/csg/releases/tag/v1.3_rc1> <https://github.com/votca/csg-tutorials/releases/tag/v1.3_rc1> and includes many more bug fixes. Christoph 2015-10-19 12:18 GMT-06:00 Chris West (Faux) <solo-debianb...@goeswhere.com>: > Source: votca-csg > Version: 1.2.4-1 > Severity: serious > Justification: fails to build from source > Tags: sid > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > The package fails to build: > > [ 8%] Building CXX object > src/libcsg/CMakeFiles/gmx_print_version.dir/modules/io/gmx_print_version.cc.o > cd /votca-csg-1.2.4/obj-x86_64-linux-gnu/src/libcsg && /usr/bin/c++ > -DGMX_SOFTWARE_INVSQRT -g -O2 -fPIE -fstack-protector-strong -Wformat > -Werror=format-security -D_FORTIFY_SOURCE=2 -I/votca-csg-1.2.4/include > -I/votca-csg-1.2.4/obj-x86_64-linux-gnu/src/libcsg-o > CMakeFiles/gmx_print_version.dir/modules/io/gmx_print_version.cc.o -c > /votca-csg-1.2.4/src/libcsg/modules/io/gmx_print_version.cc > /votca-csg-1.2.4/src/libcsg/modules/io/gmx_print_version.cc:28:30: fatal > error: copyrite.h: No such file or directory > compilation terminated. > src/libcsg/CMakeFiles/gmx_print_version.dir/build.make:65: recipe for target > 'src/libcsg/CMakeFiles/gmx_print_version.dir/modules/io/gmx_print_version.cc.o' > failed > make[3]: *** > [src/libcsg/CMakeFiles/gmx_print_version.dir/modules/io/gmx_print_version.cc.o] > Error 1 > make[3]: Leaving directory '/votca-csg-1.2.4/obj-x86_64-linux-gnu' > CMakeFiles/Makefile2:472: recipe for target > 'src/libcsg/CMakeFiles/gmx_print_version.dir/all' failed > make[2]: *** [src/libcsg/CMakeFiles/gmx_print_version.dir/all] Error 2 > > Full build log: > https://reproducible.debian.net/rb-pkg/unstable/amd64/votca-csg.html > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > > _______ > Debichem-devel mailing list > debichem-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel -- Christoph Junghans Web: http://www.compphys.de
Bug#797293: [Debichem-devel] Bug#797293: votca-csg: FTBFS: undefined reference to `votca::tools::RangeParser::Parse
2015-09-02 1:46 GMT-06:00 Simon McVittie <s...@debian.org>: > Control: reassign 797293 votca-tools > Control: found 797293 1.2.4-1 > Control: tag 797293 + sid stretch confirmed > Control: affects 797293 votca-csg > Control: retitle 797293 votca-tools: rename needed for libstdc++ ABI > transition > Control: user debian-...@lists.debian.org > Control: usertags 797293 + libstdc++-cxx11 > > On Sat, 29 Aug 2015 at 08:48:21 -0600, Christoph Junghans wrote: >> 2015-08-29 3:45 GMT-06:00 Dominic Hargreaves <d...@earth.li>: >> > CMakeFiles/csg_dump.dir/csg_dump.cc.o:(.data.rel.ro._ZTV10CsgDumpApp[_ZTV10CsgDu >> > mpApp]+0x28): undefined reference to >> > `votca::tools::Application::VersionString[a >> > bi:cxx11]()' >> >> This is simple. votca-tools, the prime dependency of votca-csg, was >> compiled with a compiler with a different cxx11 abi, you will need to >> re-compile votca-tools with same compiler. > > This implies that votca-tools needs an ABI transition. > > 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 votca-tools, Dominic's bug report indicates that a transition > is definitely required. The transition consists of renaming the affected > library packages, adding a v5 suffix (libgdcm2.4v5, etc.). The SONAME > should not be changed. I currently don't have a debian development system handy, but is there anything I can do from the upstream side? > > These follow-up transitions for libstdc++ are not going through exactly > the normal transition procedure, because many entangled transitions are > going on at the same time, and the usual ordered transition procedure > does not scale that far. When all the C++ libraries on which this library > depends have started their transitions in unstable if required, this > library should do the same, closing this bug; the release team will deal > with binNMUs as needed. > > In the case of votca-tools: > > * boost has already started its transition > * the other library build-deps appear to have C ABIs > > so I think this is ready to go. > > The package is likely to be NMU'd if there is no maintainer response. The > release team have declared a 2 day NMU delay[2] for packages involved > in the libstdc++ transition, in order to get unstable back to a usable > state in a finite time. > > Regards, > S > > [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition > [2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html -- Christoph Junghans Web: http://www.compphys.de
Bug#797744: [Debichem-devel] Bug#797744: Bug#797744: gromacs: shared library in a package that is not renamed with its SONAME
Hi Nicholas, if you bump gromacs to 5.1, please add the following patch <http://pkgs.fedoraproject.org/cgit/votca-csg.git/tree/votca-csg-1.2.4-gmx51.patch> to votca-csg-1.2.4 votca-csg-1.3 is on the way, but with the switch from google code to github things got delayed a little bit. Thanks, Christoph 2015-09-04 10:12 GMT-06:00 Nicholas Breen <nbr...@debian.org>: > 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 > > ___ > Debichem-devel mailing list > debichem-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel -- Christoph Junghans Web: http://www.compphys.de
Bug#797293: [Debichem-devel] Bug#797293: votca-csg: FTBFS: undefined reference to `votca::tools::RangeParser::Parse
2015-08-29 3:45 GMT-06:00 Dominic Hargreaves d...@earth.li: Source: votca-csg Version: 1.2.4-1 Severity: serious Justification: FTBFS This package FTBFS in a clean sid chroot: CMakeFiles/csg_dump.dir/csg_dump.cc.o:(.data.rel.ro._ZTV10CsgDumpApp[_ZTV10CsgDu mpApp]+0x28): undefined reference to `votca::tools::Application::VersionString[a bi:cxx11]()' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::ParseXML::Par seIgnore(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocator char const, std::mapstd::__cxx11::basic_stringchar, std::char_traitschar , std::allocatorchar , std::__cxx11::basic_stringchar, std::char_traitscha r, std::allocatorchar , std::lessstd::__cxx11::basic_stringchar, std::char _traitschar, std::allocatorchar , std::allocatorstd::pairstd::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar )' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::Property::get(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::ParseXML::Open(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::ToolsVersionStr[abi:cxx11]()' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::load_property_from_xml(votca::tools::Property, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar )' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::Application::CheckRequired(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::Table::Load(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar )' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::Property::Select(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' ../libcsg/libvotca_csg.so.2: undefined reference to `votca::tools::RangeParser::Parse(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar )' collect2: error: ld returned 1 exit status make[3]: *** [src/tools/csg_dump] Error 1 src/tools/CMakeFiles/csg_dump.dir/build.make:92: recipe for target 'src/tools/csg_dump' failed make[3]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' make[2]: *** [src/tools/CMakeFiles/csg_dump.dir/all] Error 2 CMakeFiles/Makefile2:654: recipe for target 'src/tools/CMakeFiles/csg_dump.dir/all' failed make[2]: Leaving directory '/«PKGBUILDDIR»/obj-x86_64-linux-gnu' make[1]: *** [all] Error 2 This is simple. votca-tools, the prime dependency of votca-csg, was compiled with a compiler with a different cxx11 abi, you will need to re-compile votca-tools with same compiler. Christoph Cheers, Dominic. ___ Debichem-devel mailing list debichem-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel -- Christoph Junghans Web: http://www.compphys.de
Bug#759974: [Debichem-devel] Bug#759974: Bug#759974: votca-csg: FTBFS: Could NOT find GROMACS (missing: GROMACS_LIBRARY GROMACS_INCLUDE_DIR)
2014-08-30 16:10 GMT-06:00 Nicholas Breen nbr...@debian.org: 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. Votca 1.2.3 doesn't support gromacs-5, but I am about to make a new release (1.2.4), which supports it. 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. Can you give me a 1 min intro, which commands I have to execute to do an NMU? I have access to the debichem svn and know what to upload for 1.2.4, but what's next after that? Christoph - Nicholas ___ Debichem-devel mailing list debichem-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel -- Christoph Junghans Web: http://www.compphys.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621874: [Debichem-devel] VOTCA available on my PPA
2013/12/22 Michael Banck mba...@debian.org: Hi, On Sun, Oct 27, 2013 at 02:55:04PM -0600, Christoph Junghans wrote: I finalize found the time to make the first steps to package VOTCA for Debian. The source/binary builds are available on https://launchpad.net/~ottxor/+archive/votca. Please have a look and help me to improve it, so that I can hand it over to debichem soon. I took a look at votca-tools now (as this is a Build-Depends for votca-csg and has to be uploaded first). I see the following issues: 1. The -dev package is named libvotca-tools2-dev, i.e. includes the soversion. This is discouraged (but unfortunately the library maintainer's guide advocated it at least last time I looked), unless a project is very widely used and switching all programs using it immediately is not feasable (like for GTK1-GTK2, oder Qt4-Qt5). I understand that Ubuntu ships it, but I would rather rename it to libvotca-tools-dev and either let Ubuntu deal with it, or add compatibility Replaces/Conflicts/Provides for it. Renaming is fine as it has only been released as PPA. So should we just rename the dev package or both? 2. votca-tools ships a convenience copy of boost. Either it needs to be stripped off the tarball (i.e. the tarball needs to be repackaged), or the boost license and copyright needs to be added to debian/copyright. VOTCA ships a pristine tarball already: https://votca.googlecode.com/files/votca-tools-1.2.3_pristine.tar.gz and on my PPA, I have used that one to create the debian package. Finally, I suggest adding an debian/upstream file with some metadata and the prime publications, I can do that. Once we have converged, I will add the debian folder to our admin repository. Christoph Michael -- Christoph Junghans Web: http://www.compphys.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621874: [Debichem-devel] VOTCA available on my PPA
2013/12/23 Michael Banck mba...@debian.org:
Hi,
On Mon, Dec 23, 2013 at 08:38:27AM -0700, Christoph Junghans wrote:
2013/12/22 Michael Banck mba...@debian.org:
Hi,
On Sun, Oct 27, 2013 at 02:55:04PM -0600, Christoph Junghans wrote:
I finalize found the time to make the first steps to package VOTCA for
Debian.
The source/binary builds are available on
https://launchpad.net/~ottxor/+archive/votca.
Please have a look and help me to improve it, so that I can hand it
over to debichem soon.
I took a look at votca-tools now (as this is a Build-Depends for
votca-csg and has to be uploaded first). I see the following issues:
1. The -dev package is named libvotca-tools2-dev, i.e. includes the
soversion. This is discouraged (but unfortunately the library
maintainer's guide advocated it at least last time I looked), unless a
project is very widely used and switching all programs using it
immediately is not feasable (like for GTK1-GTK2, oder Qt4-Qt5). I
understand that Ubuntu ships it, but I would rather rename it to
libvotca-tools-dev and either let Ubuntu deal with it, or add
compatibility Replaces/Conflicts/Provides for it.
Renaming is fine as it has only been released as PPA.
So should we just rename the dev package or both?
Only the -dev package, the runtime library is required to carry the
soversion in the package name.
Done.
Another thing to consider if the package has not shipped in Ubuntu
proper so far would be to maybe start over with the Debian changelog,
but I leave that up to you.
Whatever you debian guys like, I am happy to drop the current changelog.
2. votca-tools ships a convenience copy of boost. Either it needs to be
stripped off the tarball (i.e. the tarball needs to be repackaged), or
the boost license and copyright needs to be added to debian/copyright.
VOTCA ships a pristine tarball already:
https://votca.googlecode.com/files/votca-tools-1.2.3_pristine.tar.gz
and on my PPA, I have used that one to create the debian package.
Ah, ok. I think I saw that in passing a while back but by the time I
looked at the package I had forgotten about it.
Where would I note that in the debian files? The next release (1.3)
will not bundle boost anymore.
Finally, I suggest adding an debian/upstream file with some metadata and
the prime publications, I can do that.
Once we have converged, I will add the debian folder to our admin
repository.
That is usually discouraged (if you mean the code repository on Google
code), as it makes it more difficult to add Debian changes on top of a
release, if they are required by a new Debian policy, e.g. Also, it
makes it difficult to synchronize the Debian packaging with the regular
release.
The only exception are native packages, which are developped especially
for Debian, but even in that case, a lot of packages ship an upstream
source and the Debian diff.
Sorry, I misread, wrong direction of thought!
I added an upstream file with some fields in votca-{tools,csg}.
Cheers,
Christoph
So in practise, if an upstream tarball already contains a
debian/-directory, it is usually removed and replaced by the
debian.tar.gz from the source package.
Michael
--
Christoph Junghans
Web: http://www.compphys.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732400: [Debichem-devel] Bug#732400: gromacs: Illegal instruction in all programs on Intel Core 2 CPU
Graphics System -- no debconf information ___ Debichem-devel mailing list debichem-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel -- Christoph Junghans Web: http://www.compphys.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732400: [Debichem-devel] Bug#732400: gromacs: Illegal instruction in all programs on Intel Core 2 CPU
2013/12/17 Andras Szilagyi szi...@gmail.com: Unfortunately, mdrun crashes before it could create an md.log file. All programs, including mdrun, crash while reporting the command line arguments (all programs start with this). I noticed the crash always occurs before reporting the first command line argument (option) with a value that is not an integer or boolean. That is, when the type of the next command line argument to be printed is real, vector, or time. If this version is not supposed to run on pre-Sandy Bridge processors, maybe this should be indicated in the description. Gromacs can run on pre-Sandy Bridge processors, but you have to configure it with -DGMX_CPU_ACCELERATION=SSE2. Anyhow, this issue seems to be fixed in bug #725013 already. Andras On Tue, Dec 17, 2013 at 10:02 PM, Christoph Junghans jungh...@votca.org wrote: 2013/12/17 Andras Szilagyi szi...@gmail.com: Package: gromacs Version: 4.6.5-1 Severity: important All gromacs programs crash right at the start, reporting an illegal hardware instruction while printing the program options. My guess is that the deb package is compiled with some hardware acceleration, which is not available on your machine. To check, could you run: $ grep CPU acceleration md.log on some md.log file? If it says something like: CPU acceleration: AVX_256 we know why. E.g. g_angle -h results in the following output: :: :-) G R O M A C S (-: Groningen Machine for Chemical Simulation :-) VERSION 4.6.5 (-: (lots of text omitted) Option Filename Type Description -f traj.xtc InputTrajectory: xtc trr trj gro g96 pdb cpt -n angle.ndx InputIndex file -odangdist.xvg Output xvgr/xmgr file -ovangaver.xvg Output, Opt. xvgr/xmgr file -ofdihfrac.xvg Output, Opt. xvgr/xmgr file -ot dihtrans.xvg Output, Opt. xvgr/xmgr file -ohtrhisto.xvg Output, Opt. xvgr/xmgr file -ocdihcorr.xvg Output, Opt. xvgr/xmgr file -or traj.trr Output, Opt. Trajectory in portable xdr format Option Type Value Description -- -[no]h bool yes Print help info and quit -[no]version bool no Print version info and quit -niceint19 Set the nicelevel zsh: illegal hardware instruction g_angle -h ::: Debugging with gdb indicates that the error occurs in pa_val() in libgmx.so.8: ::: Program received signal SIGILL, Illegal instruction. 0x76801d8e in pa_val () from /usr/lib/libgmx.so.8 (gdb) bt #0 0x76801d8e in pa_val () from /usr/lib/libgmx.so.8 #1 0x76802020 in pargs_print_line () from /usr/lib/libgmx.so.8 #2 0x7680251a in print_pargs () from /usr/lib/libgmx.so.8 #3 0x767cc143 in ?? () from /usr/lib/libgmx.so.8 #4 0x767ce71f in write_man () from /usr/lib/libgmx.so.8 #5 0x767720b8 in parse_common_args () from /usr/lib/libgmx.so.8 #6 0x779ccd43 in gmx_g_angle () from /usr/lib/libgmxana.so.8 #7 0x77ffe7e9 in main () ::: This occurs on an Intel Core 2 Quad Q6600 CPU. /proc/cpuinfo gives this for each core: ::: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz stepping: 11 cpu MHz : 1600.000 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority bogomips: 4799.50 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: :: -- System Information: Debian Release: 6.0.8 APT prefers oldstable APT policy: (990, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gromacs depends on: ii atlas3-base [liblapack.s 3.6.0-20.6 Automatically Tuned Linear Algebra ii gromacs-data 4.6.5-1 GROMACS molecular dynamics sim, da ii lapack3 [liblapack.so.3] 3.0.2531a-6 library of linear algebra routines ii libatlas3-base [liblapac 3.8.4-9.1 Automatically Tuned Linear
Bug#732400: [Debichem-devel] Bug#732400: gromacs: Illegal instruction in all programs on Intel Core 2 CPU
2013/12/17 Andras Szilagyi szi...@gmail.com: I may not have been clear enough here. My bug report was intended for the debian binary package, not Gromacs itself. The binary package cannot be configured, it's already compiled, there is nothing you can configure about it. Also, I'm not asking for support, I'm filing a bug report. I can compile Gromacs from source, that is not the issue. Clear and I meant to configure Gromacs inside debian/rules with -DGMX_CPU_ACCELERATION=SSE2 so that the binary package only uses sse2 instructions. No, this bug is not fixed in #725013. I reported the bug for the latest debian binary package, 4.6.5-1. And the fix for #725013 ended in 4.6.5-1. I guess the package maintainer should decide which processors the binary package is intended to support. If only certain CPUs are supported then this should be indicated in the package name or title. Or if the purpose is to provide a generic version that will run on most processors then it should not depend on AVX. The maintainer already did that or at least the debian changelog claims so: * rules: Override autodetection of CPU extensions on amd64 and i386; force to SSE2 only, and provide new DEB_BUILD_OPTIONS=cpuopt flag to re-enable autodetection for local builds. (Closes: #725013) Also debian/rules contains: ifneq (,$(findstring cpuopt,$(DEB_BUILD_OPTIONS))) ifneq (,$(findstring $(DEB_HOST_ARCH),i386 amd64)) COMMON_CONFIG_PARAMS += -DGMX_CPU_ACCELERATION=SSE2 endif endif Andras On Tue, Dec 17, 2013 at 11:27 PM, Christoph Junghans jungh...@votca.org wrote: 2013/12/17 Andras Szilagyi szi...@gmail.com: Unfortunately, mdrun crashes before it could create an md.log file. All programs, including mdrun, crash while reporting the command line arguments (all programs start with this). I noticed the crash always occurs before reporting the first command line argument (option) with a value that is not an integer or boolean. That is, when the type of the next command line argument to be printed is real, vector, or time. If this version is not supposed to run on pre-Sandy Bridge processors, maybe this should be indicated in the description. Gromacs can run on pre-Sandy Bridge processors, but you have to configure it with -DGMX_CPU_ACCELERATION=SSE2. Anyhow, this issue seems to be fixed in bug #725013 already. Andras On Tue, Dec 17, 2013 at 10:02 PM, Christoph Junghans jungh...@votca.org wrote: 2013/12/17 Andras Szilagyi szi...@gmail.com: Package: gromacs Version: 4.6.5-1 Severity: important All gromacs programs crash right at the start, reporting an illegal hardware instruction while printing the program options. My guess is that the deb package is compiled with some hardware acceleration, which is not available on your machine. To check, could you run: $ grep CPU acceleration md.log on some md.log file? If it says something like: CPU acceleration: AVX_256 we know why. E.g. g_angle -h results in the following output: :: :-) G R O M A C S (-: Groningen Machine for Chemical Simulation :-) VERSION 4.6.5 (-: (lots of text omitted) Option Filename Type Description -f traj.xtc InputTrajectory: xtc trr trj gro g96 pdb cpt -n angle.ndx InputIndex file -odangdist.xvg Output xvgr/xmgr file -ovangaver.xvg Output, Opt. xvgr/xmgr file -ofdihfrac.xvg Output, Opt. xvgr/xmgr file -ot dihtrans.xvg Output, Opt. xvgr/xmgr file -ohtrhisto.xvg Output, Opt. xvgr/xmgr file -ocdihcorr.xvg Output, Opt. xvgr/xmgr file -or traj.trr Output, Opt. Trajectory in portable xdr format Option Type Value Description -- -[no]h bool yes Print help info and quit -[no]version bool no Print version info and quit -niceint19 Set the nicelevel zsh: illegal hardware instruction g_angle -h ::: Debugging with gdb indicates that the error occurs in pa_val() in libgmx.so.8: ::: Program received signal SIGILL, Illegal instruction. 0x76801d8e in pa_val () from /usr/lib/libgmx.so.8 (gdb) bt #0 0x76801d8e in pa_val () from /usr/lib/libgmx.so.8 #1 0x76802020 in pargs_print_line () from /usr/lib/libgmx.so.8 #2 0x7680251a in print_pargs () from /usr/lib/libgmx.so.8 #3 0x767cc143 in ?? () from /usr/lib/libgmx.so.8 #4 0x767ce71f in write_man () from /usr/lib/libgmx.so.8 #5 0x767720b8 in parse_common_args () from /usr/lib/libgmx.so.8 #6 0x779ccd43 in gmx_g_angle () from /usr/lib/libgmxana.so.8 #7 0x77ffe7e9 in main () ::: This occurs on an Intel Core 2 Quad Q6600 CPU. /proc/cpuinfo gives this for each core: ::: processor
Bug#621874: [Debichem-devel] VOTCA available on my PPA
2013/10/31 Nicholas Breen nbr...@debian.org: On Sun, Oct 27, 2013 at 02:55:04PM -0600, Christoph Junghans wrote: I finalize found the time to make the first steps to package VOTCA for Debian. The source/binary builds are available on https://launchpad.net/~ottxor/+archive/votca. Please have a look and help me to improve it, so that I can hand it over to debichem soon. Hi Christoph, Thanks for working on those. They look fairly sensible to me; the one change I'd strongly recommend is updating them to debhelper v9 compatibility, which should automatically handle both the multiarch paths and appending CPPFLAGS to CXXFLAGS. It might also be worth specifying what exactly the dh_python2 calls should operate on, since those throw a lot of errors during their run from trying (and failing) to operate on non-python files -- not a fatal error, it just makes that part of the build log hard to read. Don, done done. VOTCA uses the LIB variable to set the lib location, which is obliviously not what dh excepts, so I left this in rules. There's still a second typo in 11_csg_boltzmann_typo.patch: telp - help Done. Have you considered including the tutorials as additional documentation? I tried setting those up at first with the multiple-tarballs feature of the 3.0 source format [1], which does work although you'll need to write your own installation procedure in debian/rules for them. Done. Policy 3.9.5 was just released [2], so you can bump the Standards-Version lines in debian/control. I don't see any changes that would affect your packaging. Done. -- Nicholas Breen nbr...@debian.org [1] https://wiki.debian.org/Projects/DebSrc3.0#How_to_use_multiple_upstream_tarball_in_3.0_.28quilt.29_format.3F [2] https://lists.debian.org/debian-devel-announce/2013/10/msg6.html -- Christoph Junghans Web: http://www.compphys.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621874: VOTCA available on my PPA
I finalize found the time to make the first steps to package VOTCA for Debian. The source/binary builds are available on https://launchpad.net/~ottxor/+archive/votca. Please have a look and help me to improve it, so that I can hand it over to debichem soon. -- Christoph Junghans Web: http://www.compphys.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621874: Votca was 1.2 released
Announcement: http://groups.google.com/group/votca/browse_frm/thread/c814a046ebd31191 It now uses cmake as build system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590934: [xml/sgml-pkgs] Bug#590934: libxml2: Segmentation fault, when compiling with -static
How do you check if a weak symbol was resolved?
2010/8/2 Mike Hommey m...@glandium.org:
On Fri, Jul 30, 2010 at 11:53:17AM +0200, Christoph Junghans
jungh...@votca.org wrote:
Package: libxml2
Version: 2.6.32.dfsg-5+lenny1
I know static compiling is bad, but from time to time you need it.
Here is the simplest case I can imagine:
$ cat main.c
#include libxml/parser.h
int main(int argc, char **argv) {
xmlInitParser();
}
$ gcc -static main.c `xml2-config --libs --cflags` -pthread -lz -lm
$ ./a.out
Segmentation fault
This is a problem with weak symbols in threads.c
A patch can be found here:
https://bugzilla.gnome.org/show_bug.cgi?id=609926
but upstream refused to merge it.
Upstream is partially responsible for the problem. I'd say there are actually
2 different problems. The first one is that despite using weak symbols, the
initialization steps don't check if the symbols are resolved before using
them. That should IMHO be fixed in libxml2, instead of removing weak symbols.
The fix should be straightforward.
The other issue is that gcc and ld are doing weird stuff with those weak
pthread symbols, even when using -lpthread. I'll probably file a bug against
either or both.
Please also note that you should be using the --libs --static options when
linking statically libxml2, which gives the right flags, but due to the above,
that doesn't buy much.
Cheers,
Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590934: libxml2: Segmentation fault, when compiling with -static
Package: libxml2
Version: 2.6.32.dfsg-5+lenny1
I know static compiling is bad, but from time to time you need it.
Here is the simplest case I can imagine:
$ cat main.c
#include libxml/parser.h
int main(int argc, char **argv) {
xmlInitParser();
}
$ gcc -static main.c `xml2-config --libs --cflags` -pthread -lz -lm
$ ./a.out
Segmentation fault
This is a problem with weak symbols in threads.c
A patch can be found here:
https://bugzilla.gnome.org/show_bug.cgi?id=609926
but upstream refused to merge it.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
