Bug#1079618: grace: no longer depends on libxmhtml

[Nicholas Breen]

On Sun, Aug 25, 2024 at 01:49:03PM +, Graham Inggs wrote:
> This seems to be a problem in configuration.
> 
> Newer logs [1] have:
> 
> checking for XbaeCreateMatrix in -lXbae... yes
> --> Good. Seems you have compatible version of Xbae installed
> checking for XmHTML widget >= 1105... no
> 
> while older logs have:
> 
> checking for XbaeCreateMatrix in -lXbae... yes
> --> Good. Seems you have compatible version of Xbae installed
> checking for XmHTML widget >= 1105... yes

Hi Graham,

Thanks for catching that.  It was indeed a config bug - another instance
of GCC 14 requiring its "#include "s everywhere.  With that
added, configuration detects XmHTML properly[1], and I'll upload a new
version shortly.


Nicholas


[1] https://salsa.debian.org/debian/grace/-/jobs/6181916#L1992

Bug#1063752: custodian: Inappriate maintainer address

[Nicholas Breen]

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#1061727: [Debichem-devel] Bug#1061727: gromacs: please add support for loong64

[Nicholas Breen]

On Mon, Jan 29, 2024 at 07:51:04AM +, wuruilong wrote:
> Source: gromacs
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
> 
> Dear Maintainer,
> 
> The attached patch fixes the compilation error problem in the loong64 
> architecture, and the local compilation passes.

Thank you for working on this!  I think the patch would best be applied
upstream, for the benefit of all distributions.  They prefer to take
gitlab merge requests.  Is that something you'd be willing to submit
(you're certainly in a better position to answer questions!), or would
you like me to do so?

https://manual.gromacs.org/current/dev-manual/contribute.html



-- 
Nicholas Breen
nbr...@debian.org

Bug#1017480: RM: gromacs/experimental -- NVIU; ROM; not flagged by autocruft

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal

Please remove gromacs/2022.1-1 from experimental.  There is a newer
version in unstable, but on fewer architectures, which is probably how
this missed the autocruft check.

Thanks.


--
Nicholas Breen
nbr...@debian.org

Bug#1011392: RM: gromacs [armel armhf i386 mipsel] -- ROM, ANAIS; upstream support dropped for 32-bit archs

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 1010501 1010502 1010503
Control: block 1011369 by -1


GROMACS upstream has dropped support for all 32-bit architectures in the
current version (not uncommon these days for number-crunching scientific
software).  Please remove all the binaries for those architectures at
your convenience: gromacs, libgromacs6, libgromacs-dev, libnblib-gmx0,
libnblib-gmx-dev.

The only rdeps are the three old votca-{csg,tools,xtp} packages, for
which separate RM bugs have already been filed.



-- 
Nicholas Breen
nbr...@debian.org

Bug#1011369: transition: gromacs

[Nicholas Breen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This is perhaps more of a "recommended best practice" request than a
transition request.

gromacs has an upcoming library transition, staged in experimental, and
its next upload to sid will close one RC bug [1].  However, its only
direct build-dependency in testing is votca-csg, which has a pending RM
request [2].  votca-csg *can* be binNMUed against gromacs 2022.1, but
that's not terribly useful when it's about to be replaced.

Additionally, gromacs upstream dropped support for 32-bit architectures
in the new release, so that will need an additional RM bug for old
binaries, not yet filed.

Should I proceed with an upload to sid when a slot is ready, or wait for
one or both of those removals to clear first?

Thanks.


-- 
Nicholas Breen
nbr...@debian.org


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009383
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010502

Ben file:

title = "gromacs";
is_affected = .depends ~ "libgromacs6" | .depends ~ "libgromacs7";
is_good = .depends ~ "libgromacs7";
is_bad = .depends ~ "libgromacs6";

Bug#1010501: RM: votca-tools -- ROM; superceded by votca

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal


The recent acceptance of src:votca into the archive (thank you!) covers
an upstream merger of its formerly separate components: votca-tools,
votca-csg, and votca-xtp.  Please remove those three when convenient.



--
Nicholas Breen
nbr...@debian.org

Bug#1009383: gromacs: FTBFS: AttributeError: module 'collections' has no attribute 'Iterable'

[Nicholas Breen]

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#1000714: muparser: Please update to latest upstream version 2.3.2

[Nicholas Breen]

Hello again,

One of my packages now has an upstream dependency on muparser >= 2.3, so
I'd definitely like to see the newer version in the archive.  Within the
next few days, I plan to upload a NMU containing only the previously
described changes, plus a one-line addition to install the new *.cmake
files - and will upload to DELAYED/14 as an additional safety.  Please
let me know at any time if I should cancel the upload.

The latest upstream version is now 2.3.3, but it requires no further
changes to the packaging.  Current diff attached.

Thanks again for your work on muparser.



-- 
Nicholas Breen
nbr...@debian.org
diff --git a/debian/changelog b/debian/changelog
index c48b85d..45589aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+muparser (2.3.3-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Drop patches - no longer needed with upstream move to cmake.
+  * Update debian/watch and Homepage in debian/control.
+
+ -- Nicholas Breen   Sat, 12 Mar 2022 14:13:16 -0800
+
 muparser (2.2.6.1+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index f4f7491..8febf57 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,12 @@ Uploaders: Gudjon I. Gudjonsson ,
Scott Howard 
 Section: libs
 Priority: optional
-Build-Depends: debhelper (>= 12~),
-   automake
+Build-Depends: cmake,
+   debhelper (>= 12~)
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/science-team/muparser
 Vcs-Git: https://salsa.debian.org/science-team/muparser.git
-Homepage: http://muparser.sourceforge.net
+Homepage: https://beltoforion.de/en/muparser/
 
 Package: libmuparser-dev
 Architecture: any
diff --git a/debian/copyright b/debian/copyright
index 21065bb..3f39d20 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,12 +2,9 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: muparser
 Upstream-Contact: Ingo Berg 
 Source: http://muparser.sourceforge.net
-Files-Excluded: */*.dll
-*/*.lib
-*/vs
 
 Files: *
-Copyright: 2004-2007 Ingo Berg 
+Copyright: 2004-2022 Ingo Berg 
 License: Expat
   Permission is hereby granted, free of charge, to any person obtaining a copy
   of this software and associated documentation files (the "Software"), to deal
diff --git a/debian/libmuparser-dev.install b/debian/libmuparser-dev.install
index 7df81cd..f304b9d 100644
--- a/debian/libmuparser-dev.install
+++ b/debian/libmuparser-dev.install
@@ -1,3 +1,4 @@
 usr/include/*
 usr/lib/*/lib*.so
 usr/lib/*/pkgconfig/*
+usr/lib/*/cmake/muparser
diff --git a/debian/patches/FTBFS_hurd.patch b/debian/patches/FTBFS_hurd.patch
deleted file mode 100644
index e603046..000
--- a/debian/patches/FTBFS_hurd.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-Description: Allow building on hurd
-Author: Scott Howard 
-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533817
-
-Index: muparser/build/autoconf/aclocal.m4
-===
 muparser.orig/build/autoconf/aclocal.m4	2013-01-26 23:30:49.773669077 -0500
-+++ muparser/build/autoconf/aclocal.m4	2013-01-26 23:30:53.421669002 -0500
-@@ -1258,7 +1258,7 @@
-   ;;
- 
-   powerpc-apple-macos* | \
--  *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | *-*-k*bsd*-gnu | \
-+  *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | *-*-k*bsd*-gnu | *-*-gnu* | \
-   *-*-mirbsd* | \
-   *-*-sunos4* | \
-   *-*-osf* | \
-@@ -1309,7 +1309,7 @@
- SONAME_FLAG=
- 
- case "${BAKEFILE_HOST}" in
--  *-*-linux* | *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | \
-+  *-*-linux* | *-*-gnu* | *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | \
-   *-*-k*bsd*-gnu | *-*-mirbsd* )
- if test "x$SUNCXX" = "xyes"; then
- SONAME_FLAG="-h "
diff --git a/debian/patches/fix-versionnum.patch b/debian/patches/fix-versionnum.patch
deleted file mode 100644
index 1810865..000
--- a/debian/patches/fix-versionnum.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From: Teemu Ikonen 
-  Andreas Tille 
-Date: Sun, 13 Jan 2019 18:59:59 +0100
-Subject: [PATCH] Fix version number to 2.2.6 in build system.
-

- Makefile.in | 4 ++--
- build/autoconf/configure.ac | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/Makefile.in b/Makefile.in
-index 157be77..305167c 100644
 a/Makefile.in
-+++ b/Makefile.in
-@@ -139,9 +139,9 @@ COND_WINDOWS_IMPLIB_1___muParser_dll___importlib = \
- @COND_USE_SOVERSION_0@__muParser_dll___targetsuf2 = .$(SO_SUFFIX)
- @COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@__muParser_dll___targetsuf3 \
- @COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@	= \
--@COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@	.$(SO_SUFFIX).2.2.4
-+@COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_

Bug#1000714: muparser: Please update to latest upstream version 2.3.2

[Nicholas Breen]

Source: muparser
Severity: minor
Tags: patch


If practical, please update muparser to the latest upstream version,
2.3.2.

I've attached a patch that seems to work, and also updates debian/watch
to *find* the new version.  Fortunately, a nice easy update, and one
that allows the previous patches to be dropped.  I did not look into the
dpkg-gensymbols problem that was reported earlier, though.

Thank you!


-- 
Nicholas Breen
nbr...@debian.org

diff --git a/debian/changelog b/debian/changelog
index c48b85d..33a989b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+muparser (2.3.2-1) UNRELEASED; urgency=medium
+
+  * New upstream release.
+  * Drop patches - no longer needed with upstream move to cmake.
+  * Update debian/watch and Homepage in debian/control.
+
+ -- Nicholas Breen   Sat, 27 Nov 2021 09:34:27 -0800
+
 muparser (2.2.6.1+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index f4f7491..8febf57 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,12 @@ Uploaders: Gudjon I. Gudjonsson ,
Scott Howard 
 Section: libs
 Priority: optional
-Build-Depends: debhelper (>= 12~),
-   automake
+Build-Depends: cmake,
+   debhelper (>= 12~)
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/science-team/muparser
 Vcs-Git: https://salsa.debian.org/science-team/muparser.git
-Homepage: http://muparser.sourceforge.net
+Homepage: https://beltoforion.de/en/muparser/
 
 Package: libmuparser-dev
 Architecture: any
diff --git a/debian/copyright b/debian/copyright
index 21065bb..11af306 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,12 +2,9 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: muparser
 Upstream-Contact: Ingo Berg 
 Source: http://muparser.sourceforge.net
-Files-Excluded: */*.dll
-*/*.lib
-*/vs
 
 Files: *
-Copyright: 2004-2007 Ingo Berg 
+Copyright: 2004-2020 Ingo Berg 
 License: Expat
   Permission is hereby granted, free of charge, to any person obtaining a copy
   of this software and associated documentation files (the "Software"), to deal
diff --git a/debian/rules b/debian/rules
index 20a3f85..43f6419 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,24 +11,6 @@ SAVE_FILES = configure
 %:
 	dh $@
 
-override_dh_update_autotools_config:
-	# Save upstream configs
-	for f in $(SAVE_FILES) ; do  \
-		if [ ! -f $$f-orig ] ; then mv $$f $$f-orig ; fi \
-	done
-	dh_update_autotools_config
-	bash build/autoconf/acregen.sh
-
-override_dh_auto_configure:
-	dh_auto_configure -- --disable-samples
-
-override_dh_clean:
-	dh_clean
-	# Restore upstream config
-	for f in $(SAVE_FILES) ; do\
-		if [ -f $$f-orig ] ; then mv $$f-orig $$f ; fi \
-done
-
 override_dh_makeshlibs:
 	#pkgkde-symbols helper is managing the symbols file.
 	#Sometimes we'll FTBFS on other arch's toolchains that export or miss
diff --git a/debian/watch b/debian/watch
index ac66e52..c869838 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
 
 opts="repacksuffix=+dfsg,dversionmangle=auto,repack,compression=xz" \
-  https://github.com/beltoforion/muparser/releases/latest .*/archive/v?@ANY_VERSION@@ARCHIVE_EXT@
+  https://github.com/beltoforion/muparser/releases/latest .*/archive/refs/tags/v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#855461: esniper: again fails to login

[Nicholas Breen]

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#980943: mipch: mpirun segfaults on s390x

[Nicholas Breen]

Package: mpich
Version: 3.4-5
Severity: important
User: debian-s...@lists.debian.org
Usertags: s390x
X-Debbugs-Cc: debian-s...@lists.debian.org
Affects: gromacs


Hi,

mpirun from mpich 3.4-5 (and possibly other versions, this is the only one I
tested) segfaults immediately on s390x:

  % mpirun -V
  host: zelenka
  zsh: segmentation fault  mpirun -V

It is reproducible after recompiling locally, in a sid chroot.  Very compact
backtrace of an unstripped/unoptimized version:

(gdb) run -V
Starting program: /home/nbreen/mpich-3.4/debian/tmp/usr/bin/mpiexec.hydra -V
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
host: zelenka

Program received signal SIGSEGV, Segmentation fault.
HYDU_create_proxy_list (exec_list=0x0, node_list=0x2aa0010d2f0, 
pg=0x2aa000863e8 )
at utils/alloc/alloc.c:429
429 while (pg->proxy_list->exec_list == NULL) {
(gdb) bt
#0  HYDU_create_proxy_list (exec_list=0x0, node_list=0x2aa0010d2f0, 
pg=0x2aa000863e8 )
at utils/alloc/alloc.c:429
#1  0x02aa8366 in main (argc=2, argv=0x3fffb38) at 
ui/mpich/mpiexec.c:262



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: s390x

Kernel: Linux 4.19.0-13-s390x (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages mpich depends on:
ii  hwloc-nox   2.4.0+dfsg-3
ii  libc6   2.31-9
ii  libmpich12  3.4-5

Versions of packages mpich recommends:
ii  libmpich-dev  3.4-5

Versions of packages mpich suggests:
pn  mpich-doc  

-- no debconf information

Bug#980634: [Debichem-devel] Bug#980634: gromacs: FTBFS: Errors while running CTest

[Nicholas Breen]

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#973639: [Debichem-devel] Bug#973639: closed by Debian FTP Masters (reply to Nicholas Breen ) (Bug#973639: fixed in gromacs 2021~beta2-1)

[Nicholas Breen]

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#960640: bash-completion: dh_bash-completion needs to record installed files for dh_missing

[Nicholas Breen]

Hello Gabriel,

As an example package demonstrating this bug, I encountered it when
preparing votca-csg 1.6.2-1.  Removing the workaround in debian/rules
(lines 29 and 30) causes a build failure with debhelper compat 13.

Thanks!


-- 
Nicholas Breen
nbr...@debian.org

Bug#965169: O: jigl -- Generates a static html photo gallery from one or more directories of images

[Nicholas Breen]

Package: wnpp
Severity: normal

I intend to orphan the jigl package.

The package description is:
 Perl script that generates a static html photo gallery from one or
 more directories of gif/jpg/png images. It supports themes and is very
 customizable. It includes the ability to display comments and EXIF
 info for each image in a simple clean layout.

I haven't used it for some years; it's not a difficult package, though
long-dead upstream, and with a late-'00s packaging style that could use
an overhaul.



-- 
Nicholas Breen
nbr...@debian.org

Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist

[Nicholas Breen]

On Mon, Jul 13, 2020 at 04:55:36PM -0700, Sean Whitton wrote:
> control: tag -1 + moreinfo
> 
> Hello Nicholas,
[...]
> Is there any reason to think the software no longer works?
> 
> Otherwise, perhaps it would be better if you were simply to orphan it.

Hi Sean,

It does still work (modulo #936008, which requires rewriting one script
-- though the package is basically just two scripts).  However, there's
nothing it does that other packages don't do equally well or better; it
could be orphaned and remain for another release or two, but I'm not
convinced it's helping anyone trying to decide between all the results
of "apt-cache search galler(y|ies)".



Nicholas

Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal

Please remove jigl from the archive.  It has not had any upstream
activity since 2006, and has the lowest popcon count of all remaining
similar tools:

https://qa.debian.org/popcon-graph.php?packages=jigl%2C+llgal%2C+fgallery%2C+lazygal%2C+igal2%2C+imageindex&show_installed=on&want_legend=on&from_date=2010-01-01&to_date=&hlght_date=&date_fmt=%25Y&beenhere=1


-- 
Nicholas Breen
nbr...@debian.org

Bug#959946: grace: fails to start: failed request: 12 (X_ConfigureWindow)

[Nicholas Breen]

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#955770: grace: fix of bug #727796 is a regression

[Nicholas Breen]

On Sat, Apr 04, 2020 at 09:18:04PM +0200, Lothar Brendel wrote:
> Package: grace
> Version: 1:5.1.25-7+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> xmgrace's UI got slightly inferior since version 1:5.1.25-6: The menu 
> accelerators have dissapreared, the font is less fitting.
> 
> Actually, I beg to differ regarding bug #727796 and its fix. The Xresources 
> hardcoded in xmgrace.c are *fallback* resources, employed via 
> XtAppSetFallbackResources(). They can be and *are* overriden by user 
> specified Xresources (I don't know why this didn't work in the bug reporter's 
> case). What's a bit annoying: *All* of them are dismissed as soon as a 
> resource file is given, even an empty one.
> 
> This can be verified nicely in version 1:5.1.23-3: Without an 
> /etc/X11/app-defaults/XMgrace, the UI has colors, a nice font, and menu 
> accelerators. With an empty /etc/X11/app-defaults/XMgrace, it is b/w, has a 
> monospaced font and no menu accelerators. Unfortunately, with the 
> /etc/X11/app-defaults/XMgrace shipped since version 1:5.1.23-6, it has 
> colors, but still the monospaced font and still no menu accelerators. This I 
> consider a regression.

Some of this may be DE-dependent; I get a monospaced font *with*
accelerators.  But I take your point.

> My suggestion: Don't cripple the fallback resources in the code and instead 
> of supplying a deficient /etc/X11/app-defaults/XMgrace, provide an example in 
> the docs. The example file could contain precisely the fallback values, then 
> the user could edit just the relevant bits.

This seems reasonable.  I feel like very, very few people are
customizing their Xresources file in the current day.  



-- 
Nicholas Breen
nbr...@debian.org

Bug#949669: [Debichem-devel] Bug#949669: votca-csg ftbfs with gromacs 2020-2

[Nicholas Breen]

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#943051: closed by Nicholas Breen (Re: [Debichem-devel] Bug#943051: gromacs: Python2 removal in sid/bullseye)

[Nicholas Breen]

On Tue, Oct 22, 2019 at 11:06:01PM -0400, Sandro Tosi wrote:
> Hello Nicholas,
> any specific reason to wait this long? it would be very helpful if
> there's a chance for you to speed up the upload to unstable, so that
> we can reduce the number of packages needing python2 in unstable soon,
> and better assess the situation we are in, and if we can actually
> remove py2 during bullseye development cycle. thanks for your
> understanding!

Hi Sandro,

Only that the fixes are in the beta branch for the next upstream
release, and it's scheduled for a stable release in January.  Also,
right now the experimental build fails on four release architectures
(and 11 port architectures!), so it's not quite ready for an upload to
unstable, if it can't later migrate to testing.

I haven't looked into the upstream code changes yet, but there was only
one specific part of the documentation build that relied on python2 in
the earlier versions - I'll see if I can backport that more quickly.


- Nicholas

Bug#934662: grace: Font mapping breaks with base35 *.t1 fonts

[Nicholas Breen]

On Tue, Aug 13, 2019 at 12:47:07AM -0500, Carlo Segre wrote:
> If the links ending in *.t1 in the /usr/share/grace/fonts/type1/ directory
> are renamed as *.pfb, then grace identifies all the fonts correctly and
> makes them all available with their proper name designations.  This
> indicates that the bug is in the source code for grace which should add a
> search for a fourth variant of the file name, i.e. with *.t1 as the
> extension.

Even worse: it's split between grace and t1lib code, with an awkward
interface between the two.

I'd *like* to solve it this way but only have a partial fix so far.
I'll poke at it further as time permits over the next few days, and
switch to your update-grace-fonts patch if it seems intractable. Thanks!


-- 
Nicholas Breen
nbr...@debian.org

Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)

[Nicholas Breen]

On Thu, Feb 14, 2019 at 05:08:54PM +0100, Santiago Vila wrote:
> After some tests, I believe the most probably reason for the failure I
> got was lack of disk space. Sorry for the false positive, I usually
> measure how much disk space is required and only try in a machine
> which has enough. Because this was a new upstream release, I was still
> using the disk estimation from the previous version.

The disk space requirements have indeed gone up enormously over time!
https://buildd.debian.org/status/logs.php?pkg=gromacs&arch=amd64

> I think there is still a problem here: Why is there not any "disk full"
> message anywhere? Why just "ld returned 1 exit status"? Should not
> also say the reason, like any other compiler usually does?
> 
> Perhaps this should be reassigned to whatever package contains the
> "mpicxx.openmpi" command?

It's from openmpi-bin, but it's just a wrapper around g++ that sets
appropriate flags, and should not be interfering with any output.  I
also can't reproduce that failure, by creating a link failure at that
specific point (setting it to link against a nonexistent library) -- the
ld error message appears as normal, passed through mpicxx.openmpi.
Might be something specific to 100% disk usage, I'll experiment further.




-- 
Nicholas Breen
nbr...@debian.org

Bug#921784: [Debichem-devel] Bug#921784: gromacs: FTBFS (ld returned 1 exit status)

[Nicholas Breen]

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#921202: ITP: votca-xtp -- Exciton transport simulation for VOTCA

[Nicholas Breen]

Package: wnpp
Severity: wishlist
Owner: Debichem Team 

* Package name: votca-xtp
  Version : 1.5.0
  Upstream Author : Christoph Junghans  and others
* URL : http://www.votca.org/
* License : Apache 2.0
  Programming Lang: C++
  Description : Exciton transport simulation for VOTCA

VOTCA is a software package which focuses on the analysis of molecular
dynamics data, the development of systematic coarse-graining techniques as
well as methods used for simulating microscopic charge transport in
disordered semiconductors.
 .
xtp is Votca's exciton transport simulation engine.


This extends the existing src:votca-tools and src:votca-csg, and will be
maintained by the Debichem team.

Bug#914379: nmu: mpich_3.3~rc1-2

[Nicholas Breen]

Subject: nmu: mpich_3.3~rc1-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hi,

The recent upload of mpich during the window where the buildds on some
architectures had a /usr-merged chroot, and the mpich build created
scripts (e.g.  /usr/bin/mpicc.mpich) with shebang lines pointing to
"/usr/bin/bash".  Naturally, this then fails to run on non-/usr-merged
systems.  Now that the buildds have that change reverted, a binNMU
should fix it up.

nmu mpich_3.3~rc1-2 . arm64 armel armhf i386 mips mips64el ppc64el s390x . 
unstable . -m 'Rebuild without usrmerge'

I'm not the mpich maintainer, but I noticed this when it broke the build
of my recent gromacs upload on those architectures - I think this is the
right syntax to additionally request a dep-wait on the rebuilt mpich?

dw gromacs . arm64 armel armhf i386 mips mips64el ppc64el s390x .  unstable . 
-m 'mpich (>= 3.3~rc1-2+b1)'

Thank you.



-- 
Nicholas Breen
nbr...@debian.org

Bug#910901: plasma-applet-redshift-control: Mouse wheel only reduces color temperature, in either direction

[Nicholas Breen]

Package: plasma-applet-redshift-control
Version: 1.0.18-2
Severity: normal
Tags: patch

Since redshift 1.12, the interface for one-shot changes was modified, causing
all mouse wheel operations to only lower the color temperature and gamma.  The
fix is simply to add the new "-P" command line option.

Other reports, with one-liner patches:
https://bugs.kde.org/show_bug.cgi?id=395641
https://bugs.archlinux.org/task/59084



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-applet-redshift-control depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-1
ii  redshift1.12-2

plasma-applet-redshift-control recommends no packages.

plasma-applet-redshift-control suggests no packages.

-- no debconf information

Bug#866440: NMU for mcomix RC bug

[Nicholas Breen]

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#887909: xmgrace GUI does not close properly (using kde plasma)

[Nicholas Breen]

On Tue, Feb 20, 2018 at 10:53:17AM +0100, John Lu. Mac wrote:
> The fact that the xmgrace window does not close, which I describe, is not
> due to hidden dialog boxes!
> (Also, the xmgrace process -- according to ps -- does terminate, when I try
> to close xmgrace via the GUI, just the GUI window refuses to close!)
> 
> Indeed, I can confirm that fully upgrading debian stretch to buster solves
> this issue!
> However, I can reproduce the issue on multiple desktop computers running
> pure Debian stretch (with KDE)!

After running up a fresh installation of stretch in a VM, with no setup steps
beyond selecting KDE during the installation and then installing grace, I still
cannot reproduce this issue.

Since the xmgrace process terminates, it seems the problem is likely with your
window manager somewhere instead - which could in turn be a video driver issue,
so disabling the compositor would be a logical thing to test.



-- 
Nicholas Breen
nbr...@debian.org

Bug#887909: xmgrace GUI does not close properly (using kde plasma)

[Nicholas Breen]

On Sun, Jan 21, 2018 at 05:36:37PM +0100, John Lu. Mac wrote:
> Package: grace
> Version: 1:5.1.25-3
> Severity: important
> 
> Dear Maintainer,
> 
> the xmgrace GUI does not close as expected (via -> File -> Exit) when
> xmgrace has been started with parameters.
> For example, when xmgrace has been started via "xmgrace file.xvg" the GUI
> will close correctly, but when it has been started with parameters (e.g.
> "xmgrace xyz.xvg -legend load") the window will not close.
> I'm using KDE plasma provided by Debian Stretch and the issue does not
> occur with Gnome desktop.

I cannot reproduce this behavior under KDE from either unstable or testing (and
I don't have a stable setup handy).

In the "-legend load" case, you will get a confirmation dialog on exit asking
if you wish to discard unsaved changes.  If that window is somehow hidden,
grace may seem to be frozen, but it's just waiting for user input.



-- 
Nicholas Breen
nbr...@debian.org

Bug#887340: [Debichem-devel] Bug#887340: gromacs: FTBFS on x32: tests 2 and 13 time out

[Nicholas Breen]

On Thu, Jan 18, 2018 at 05:21:48PM -0500, Aaron M. Ucko wrote:
> Mark Abraham  writes:
> 
> > GROMACS dev here - I expect that will let that test pass. It just needs
> > enough processes that can resolve MPI calls without deadlocking.
> 
> Confirmed, setting OMPI_MCA_rmaps_base_oversubscribe=1 fixes the "not
> enough slots" error in MdrunUtilityMpiUnitTests.  The GpuUtilsUnitTests
> regression remains, though.

It's possible that the latter is a gtest issue instead; that specific failing
test was previously the source of a FTBFS on Hurd, though for a different
reason.  I can't easily account for why it would only fail with OpenMPI but not
MPICH or the basic non-MPI build, though.

However, I think it's a low-importance test in this case - the build doesn't
use GPU support - so I may throw in another conditional to disable the test on
x32, with a note to revisit the issue the next time the gtest code is updated.

The thread safety warning is on all architectures, but if you still have a
build tree hanging around, could you please check that set of tests with this
command to be sure it's a non-issue?

  build/openmpi/bin/gpu_utils-test --gtest_death_test_style=threadsafe

Probably no difference, but it's fast.  Thanks much for the testing help.


- Nicholas

Bug#887340: [Debichem-devel] Bug#887340: gromacs: FTBFS on x32: tests 2 and 13 time out

[Nicholas Breen]

On Wed, Jan 17, 2018 at 11:22:27PM -0500, Aaron M. Ucko wrote:
> The only 3.0.x version available for x32 is 3.0.0-1, because newer
> versions build-depend on pmix, which in turn build-depends on pandoc,
> which is unavailable there.  (I think the Haskell stack generally is.)
> With that version installed in my laptop's x32 chroot and everything
> else left at the versions available in unstable, I get *different*
> errors per the attached log, excerpted below.  (Using unstable across
> the board yields the same errors as on the autobuilder.)

Technically an improvement!  The "not enough slots" error is a known OpenMPI
bug-or-feature, depending on who you ask.  As a workaround, could you please
add this near the top of debian/rules?

export OMPI_MCA_rmaps_base_oversubscribe=1

I'm not sure if this will let MdrunUtilityMpiUnitTests pass, but it should at
least get further and to a more informative error.  The "debian/rules
build-openmpi" target skips the very lengthy compilation of everything else.

A more powerful system shouldn't make any difference.

Bug#887340: [Debichem-devel] Bug#887340: gromacs: FTBFS on x32: tests 2 and 13 time out

[Nicholas Breen]

On Sun, Jan 14, 2018 at 10:09:23PM -0500, Aaron M. Ucko wrote:
> Source: gromacs
> Version: 2018-1
> Severity: important
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> User: debian-...@lists.debian.org
> Usertags: x32
> 
> Builds of gromacs 2018 for x32 (admittedly not a release architecture)
> have been failing with mysterious timeouts in tests 2 and 13, per
> the below excerpts from [1].

It's probably a bug in OpenMPI instead (since the exact same tests pass on x32
when using MPICH as the MPI implementation).  I don't have an x32 system
available for testing, but it would be very interesting to know if the tests
pass with the 3.0.x version of OpenMPI out of experimental.



-- 
Nicholas Breen
nbr...@debian.org

Bug#863872: grace: useless dependency on gconf2

[Nicholas Breen]

On Thu, Jun 01, 2017 at 05:52:03PM +0100, KatolaZ wrote:
> thanks for the kind and quick reply. The matter is that this
> dependency on gconf2 nowadays makes grace depend straight away on
> systemd. I know that systemd is the init of choice in Debian, but that
> is not the only possible init around, and indeed letting our beloved
> grace depend on the init system running on the machine is a bit too
> much :)

I don't believe that follows: gconf2 has a dependency on
"default-dbus-session-bus | dbus-session-bus", and the default option
(dbus-user-session) does indeed bring in systemd, but dbus-session-bus is also
provided by dbus-x11 that has no such dependency.  At the next step in the
dependency chain, dbus itself depends on libsystemd0, but that's just a stub
that's used to determine whether systemd is active, like its similar
dependencies libselinux1 and libapparmor1 - none of which mandate the use of
their corresponding systems.



-- 
Nicholas Breen
nbr...@debian.org

Bug#863872: grace: useless dependency on gconf2

[Nicholas Breen]

On Thu, Jun 01, 2017 at 11:00:35AM +0100, KatolaZ wrote:
> I noticed that grace depends now on gconf2 (stretch). By looking at
> the source package, it seems that this dep has been introduced by the
> addition of the thumbnailer in grace. However, forcing grace to depend
> on gconf2 does not make that much sense, since many people use grace
> in desktop environments which are not gnome based. And in many cases
> grace is still used only on the command-line (e.g. via ssh connections
> to clusters). Also, the provided thumbnailer feature, which triggers
> the dependency, is an addition to other software (namely, file
> managers) which might not be used at all by grace users.
> 
> My humble suggestion is to remove this dependency, since it triggers a
> whole chain of other deps which are not necessary at all for grace to
> work properly,

Certainly from well before stretch; the dependency was added in 2006.  However,
some of the reasoning[1] has changed since: nowadays it should be possible to
use trigger support in gconf2 and demote the Depends: to something lesser,
probably a Suggests:.

I'll give it a look but I wouldn't expect to upload anything before the stretch
release in a few weeks.  It's not possible to get such a change accepted into
stretch before then.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395079#42


-- 
Nicholas Breen
nbr...@debian.org

Bug#857713: ITP: librandom123 -- parallel random numbers library

[Nicholas Breen]

On Tue, Mar 14, 2017 at 09:20:37AM +0100, Andreas Tille wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andreas Tille 
> 
> * Package name: librandom123
[...]
> Remark: This library is used in a target of Debian Med (exabayes[1]) and
> thus I intend to maintain it inside the Debian Med team even if the
> scope is science in general.  In case somebody else intends to serve as
> an additional uploader and prefers Debian Science team I'd be fine to

Hi Andreas,

I'd find this useful and I'll offer to comaintain - it'll allow me to remove
the embedded code copy from gromacs.  I have no strong VCS location preference;
right now I don't have commit access to Med, but I'm sure that's not hard to
solve.



-- 
Nicholas Breen
nbr...@debian.org

Bug#854806: hddtemp daemon won't start on a systemd system

[Nicholas Breen]

Hi Jonathan,

I'm not the hddtemp maintainer, but: in your defaults file, RUN_SYSLOG needs to
be set to a non-zero value, as per the comment above that line.



-- 
Nicholas Breen
nbr...@debian.org

Bug#838591: [Debichem-devel] Processed: Re: Bug#838591: gcc-6: GROMACS compiled with gcc 6.2.0-4 fails the tests

[Nicholas Breen]

tags 838591 + moreinfo unreproducible
thanks

On Tue, Sep 27, 2016 at 07:24:06PM +, Debian Bug Tracking System wrote:
> Bug reassigned from package 'gcc-6' to 'gromacs'.

Hi Vedran,

I am not able to reproduce this failure with gromacs 2016-3 + gcc-6 6.2.0-4 in
a clean sid chroot.

If this is built against the Debian version of gromacs (it was unclear to me
from reading the bug report), additional information is necessary - exact
version, any nonstandard build options, the full configure/build log, and the
output of the failing tests. 

If it's not from a Debian source package and build environment, it's probably
best to take it to GROMACS upstream first.  However, if it's specific to a
build with OpenMPI, please check that you're either using the latest packages
or have downgraded all the way to a 1.x version - it's been undergoing a lot of
churn lately, and a number of packages depending on it have encountered various
test failures, often architecture-specific.


-- 
Nicholas Breen
nbr...@debian.org

Bug#834991: [Debichem-devel] Bug#834991: gromacs: please disable SIMD on armhf

[Nicholas Breen]

On Sun, Aug 21, 2016 at 01:19:18PM +0200, Graham Inggs wrote:
> Hi Maintainer
> 
> Gromacs FTBFS on the Ubuntu armhf buildds.  The Ubuntu armhf buildds
> have NEON extensions, while the ones in Debian do not.  Please
> consider including my patch below which simply disables SIMD on armhf,
> avoiding the detection of NEON.

Is NEON guaranteed on Ubuntu armhf installations in general?  If so, I might
want to think about an alternative (and admittedly messier) solution that would
let it autodetect NEON there, but solve the specific FTBFS reason, which is
that the configure step shouldn't be permitting NEON + double precision in the
same build.



- Nicholas

Bug#835113: RM: gromacs, votca-csg [armel] -- RoM; FTBFS; lack of C++11 atomics

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal

Hello,

Due to the well-known lack of C++11 atomics on armel[1][2], current versions of
src:gromacs do not build on that architecture.  Please remove its binaries from
armel, and that of its only reverse-dependency, src:votca-csg.  Both packages
are maintained by the Debichem team.

Binary packages are as follows:
 gromacs
 gromacs-dev
 gromacs-mpich
 gromacs-openmpi
 libgromacs1
 libgromacs-dev
 libvotca-csg3
 libvotca-csg-dev
 votca-csg

Thank you.


-- 
Nicholas Breen
nbr...@debian.org


[1] https://lists.debian.org/debian-arm/2016/07/msg00079.html
[2] https://lists.debian.org/debian-arm/2016/06/msg00038.html

Bug#834786: [Debichem-devel] Bug#834786: gromacs: FTBFS on hurd-i386 and m68k: test suite errors

[Nicholas Breen]

On Thu, Aug 18, 2016 at 11:35:07PM -0400, Aaron M. Ucko wrote:
> Source: gromacs
> Version: 2016-1
> Severity: important
> Justification: fails to build from source (but built successfully in the past)
> 
> Builds of gromacs for hurd-i386 and m68k each failed with (unrelated)
> test suite errors.  Could you please take a look?
> 
> hurd-i386:
> 
>   /«PKGBUILDDIR»/src/gromacs/hardware/tests/hardwaretopology.cpp:169: Failure
>   Expected: (n.memory) > (0), actual: 0 vs 0
>   [  FAILED  ] HardwareTopologyTest.NumaCacheSelfconsistency (0 ms)

I'm already logged into the hurd-i386 porterbox to work on this, in fact.  At
the moment I suspect it's simply a lack of Hurd feature support in hwloc, and
the test will need to be disabled; lstopo output looks fine.

> m68k:
> 
>   /<>/src/testutils/refdata.cpp:817: Failure In item:
>   /NormalDistribution/[0] Actual: -1.1957091691864972 Reference:
>   -1.1957091691864985 Difference: 1.33227e-15 (6 double-prec. ULPs, rel.
>   1.33e-15) Tolerance: abs. 8.88178e-16, 4 ULPs (rel. 8.88e-16) [  FAILED  ]
>   NormalDistributionTest.Output (10 ms)

This one's a little different.  It's directly caused by a packaging bug (one of
the sub-builds doesn't obey DEB_BUILD_OPTIONS=nocheck, which is set by default
on m68k), and I'll fix that, but I'd be happier if it *could* pass all the
tests



-- 
Nicholas Breen
nbr...@debian.org

Bug#821734: libvotca-csg3: fails to upgrade from 'jessie' - trying to overwrite /usr/share/man/man7/votca-csg.7.gz

[Nicholas Breen]

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

[Nicholas Breen]

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#831442: mpich: Broken /usr/lib/libmpich.so.12 symlink, depending on installation order

[Nicholas Breen]

Source: mpich
Version: 3.2-6
Severity: important

A symlink /usr/lib/libmpich.so.12 is created only depending on what order the
packages libmpich12 and libmpich-dev are installed in, apparently requiring
libmpich-dev to be unpacked before libmpich12 is configured.  In a clean
chroot:

  # dpkg --purge libmpich12 libmpich-dev
  # apt-get install libmpich12
  # apt-get install libmpich-dev
  # ls -l /usr/lib/libmpich.so.12
  ls: cannot access '/usr/lib/libmpich.so.12': No such file or directory

  # dpkg --purge libmpich12 libmpich-dev
  # apt-get install libmpich12 libmpich-dev
  # ls -l /usr/lib/libmpich.so.12
  lrwxrwxrwx 1 root root 9 Jul 16 05:12 /usr/lib/libmpich.so.12 -> libmpi.so

Because libmpi.so is part of the update-alternatives group with OpenMPI,
problems can result when they're both installed:

  # readlink -f /usr/lib/libmpich.so.12
  /usr/lib/x86_64-linux-gnu/libmpich.so.12.1.0
  # apt-get install libopenmpi-dev
  # readlink -f /usr/lib/libmpich.so.12
  /usr/lib/openmpi/lib/libmpi.so.12.0.3

This hits any package that builds against both MPI variants, causing failures
in dpkg-shlibdeps when it can't find MPICH symbols in /usr/lib/libmpich.so.12:
it's responsible for a FTBFS bug on yorick [1] and a whole bunch of build
failures on gromacs in experimental [2].  I don't know why it's suddenly a
problem now, but the buildds now seem to be installing the packages in the
order that triggers this problem more often than not.


-- 
Nicholas Breen
nbr...@debian.org


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831406
[2] 
https://buildd.debian.org/status/fetch.php?pkg=gromacs&arch=amd64&ver=2016%7Erc1-2&stamp=1468635513
(also on eight other architectures and counting)

Bug#815678: gromacs: FTBFS with doxygen 1.8.11

[Nicholas Breen]

Source: gromacs
Version: 5.1.1-2
Severity: important

Filing a bug for the record, since a fix may be slightly delayed by the ongoing
openmpi transition.

gromacs FTBFS in the build-manual target with doxygen 1.8.11; it's fine with
1.8.9.  Upstream targets 1.8.5 (!).  This applies to both gromacs 5.1.1 and the
as-yet-unpackaged 5.1.2.


-- 
Nicholas Breen
nbr...@debian.org

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Nicholas Breen]

On Tue, Dec 08, 2015 at 09:44:01PM +0100, Diego M. Rodriguez wrote:
> I am looking for a sponsor for my package "python-jellyfish"
> 
> * Package name: python-jellyfish
>   Version : 0.5.1-1
>   Upstream Author : James Turk 
> * URL : https://github.com/jamesturk/jellyfish
> * License : BSD-2-clause
>   Section : python

Hi Diego,

I believe the package also needs Build-Depends on libpython-all-dev and
libpython3-all-dev, or the C extensions fail (nonfatally) to compile in a clean
chroot environment.

Unfortunately, the tests also fail - it appears that pytest is not successfully
picking up any tests to run:

[...]
I: pybuild base:184: cd 
/tmp/buildd/python-jellyfish-0.5.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
pytest 
= test session starts ==
platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1
rootdir: /tmp/buildd/python-jellyfish-0.5.1, inifile: 
collected 0 items

= no tests ran in 0.00 seconds =
E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/tmp/buildd/python-jellyfish-0.5.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
pytest 
[...]



-- 
Nicholas Breen
nbr...@debian.org

Bug#775719: beets: Please package newer upstream 1.3.15

[Nicholas Breen]

Control: retitle 775719 beets: Please package newer upstream 1.3.15


beets upstream is now up to 1.3.15, seven releases past the current Debian
package.  A little local experimentation suggests that it should be fairly easy
to update the package, *except* that it does have a new unpackaged dependency,
jellyfish[1].  I personally don't have enough Python background to maintain
such a package, but I was able to trivially package it with python-stdeb.  I
think it would be low maintenance overhead for Python package maintainers.

Other than that, the new upstream version lets you drop both patches applied in
1.3.8+dfsg-2, and it does solve bugs #792060 (RC), #757516, and I think #785903
(not checked in detail).  There is a new test failure in test_nonexistent_file,
unfortunately.



-- 
Nicholas Breen
nbr...@debian.org


[1] https://pypi.python.org/pypi/jellyfish

Bug#797744: [Debichem-devel] Bug#797744: gromacs: shared library in a package that is not renamed with its SONAME

[Nicholas Breen]

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

[Nicholas Breen]

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#775749: fails to load comments

[Nicholas Breen]

On Sun, Feb 15, 2015 at 12:21:13PM +0200, Evgeny Stambulchik wrote:
> FYI, 5.1.25 was released tonight with a fix. Sorry about a slow response.

Thanks very much!

Lu - I'll upload a new Debian package shortly, but it won't make it into
testing or the next stable release, due to the freeze.  However, if that's what
you're running, the package should still install (manually) without any
problems.


- Nicholas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775749: fails to load comments

[Nicholas Breen]

On Mon, Jan 19, 2015 at 11:17:48PM +0800, Lu Wang wrote:
> Package: grace
> Version: 1:5.1.24-3
> Severity: normal
> 
> Dear Maintainer,
> 
> I plot a figure in xmgrace. Some of the lines have comments. Then I save
> the figure to a .agr file. When I open the saved file with xmgrace, I
> find that the comments become to the file name of the .agr file. They
> should be the comments I saved before.

If I'm not misunderstanding, this is an upstream change introduced in version
5.1.24:

] 2014-08-17 01:58  fnevgeny
]   * src/ssdata.c: Always overwrite set comments when reading data in.

However, I can't find an bug report in the Grace forums[1] corresponding to
that change, so I don't know why it was made.  Evgeny, could you please help me
out with the background behind that change?  Thanks!


-- 
Nicholas Breen
nbr...@debian.org


[1] http://plasma-gate.weizmann.ac.il/Grace/phpbb/viewforum.php?f=5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774558: grace: dpkg trigger cycle via gsfonts

[Nicholas Breen]

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-dist-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)

[Nicholas Breen]

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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#758237: grace contains nonfree cephes library

[Nicholas Breen]

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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736667: xbae: [PATCH] Enable build on newer arches with dh-autoreconf and other build fixes & workarounds

[Nicholas Breen]

On Sat, Jan 25, 2014 at 04:49:18PM -0500, Daniel T Chen wrote:
> Package: xbae
> Version: 4.60.4-5
 
> Dear Maintainer,
> 
> In Ubuntu 14.04, the attached patch was applied to achieve the following:
> 
>   * Use dh-autoreconf, resolving FTBFS on newer arches.

Makes sense.  I'll upload that soonish.

> - Adjust d/rules for new location of macros.
[...]
> Some words about the gargantuan patch: the bulk is due to moving the macros
> into their own directory, as recommended by the autoconf manual.

This, however, I won't incorporate.  I don't see any benefit to moving the
macros, and it makes the 16k-line patch completely unreviewable by eye to find
the four lines that matter for the change.  If there's a technical improvement
that I'm missing, please let me know.

Thanks for the report.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#743359: grace: uses unsupported t1lib embedded library

[Nicholas Breen]

severity 743359 normal
retitle 743359 convert to freetype support
tags = upstream help
thanks

On Tue, Apr 01, 2014 at 08:19:08PM -0400, Michael Gilbert wrote:
> Since the unsupported embedded t1lib code is now used in grace, this
> package should no longer be in testing.  This can be fixed by
> converting to freetype.

As has already been explained[1][2], the t1lib code used in grace *is*
supported by the upstream grace maintainer.  That's not the same as supporting
all of t1lib, but grace doesn't even ship a complete copy of t1lib, just bits
and pieces it needs.

freetype support would be a Nice Thing, but using a convenience copy of t1lib
is neither RC[3] nor an outstanding security issue.


-- 
Nicholas Breen
nbr...@debian.org

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638760#79
[2] 
http://anonscm.debian.org/viewvc/collab-maint/deb-maint/grace/trunk/debian/README.source?view=markup
[3] Policy 4.13 is a "should", not a "must".


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#638760: Removal of grace, pygrace and expeyes

[Nicholas Breen]

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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#740442: RFS: par2cmdline/0.6.5-1 [ITA] -- PAR 2.0 compatible file verification and repair tool

[Nicholas Breen]

On Sat, Mar 01, 2014 at 03:08:20PM +0100, JCF Ploemen wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for "par2cmdline":
[snip]

>   * Update build-deps:
> + Add dh-autoreconf, automake1.11.

Does it require automake 1.11 specifically?  That version isn't due for removal
from the archive quite yet, but it will probably be in the next round [1], and
the current automake version is 1.14.  Might as well bring it all the way up to
date if it still builds easily.

(I haven't looked over the rest of the package.)


-- 
Nicholas Breen
nbr...@debian.org

[1] https://lists.debian.org/debian-devel/2013/09/msg00441.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738283: RFS: rotix/0.83-4.1 RC, NMU

[Nicholas Breen]

On Sat, Feb 08, 2014 at 11:09:07PM +0100, Andreas Moog wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for a NMU of the package "rotix"
> 
>  * Package name: rotix
>Version : 0.83-4.1
>Section : text

That package has subsequently been orphaned, #738336.  The next comment on that
bug asks whether it should be removed from the archive instead, as there are
other options.  Are you interested in either adopting it or encouraging its
removal?


-- 
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

[Nicholas Breen]

On Tue, Dec 17, 2013 at 05:57:10PM +0100, Andras Szilagyi wrote:
> 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. 
[snip]

This is my fault - although I did change the build setup to avoid this very
problem, I was also testing the build option that reenables all CPU extensions,
and it looks like I screwed up and uploaded the wrong set of binaries on amd64.
I apologize for the mistake, and will either get it binNMU'd or simply upload a
new (and more strictly verified!) version in the next day or two.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#730701: [Debichem-devel] Bug#730701: espresso: generation of vdW_kernel_table takes a long time without any progress

[Nicholas Breen]

On Thu, Nov 28, 2013 at 12:31:59PM +0100, Michael Banck wrote:
> This data file is shipped in quantum-espresso-data, so not generating it
> is not an option,

quantum-espresso-data is arch:all, so it seems like that *could* be an option -
no need to autobuild it on every architecture, and so far as I know all the
arch:all package builds still come from the package upload anyhow (no
autobuilds on any architecture).


- N


-- 
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

[Nicholas Breen]

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.

There's still a second typo in 11_csg_boltzmann_typo.patch: "telp" -> "help"

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.

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.

-- 
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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725226: nmu: gromacs_4.5.3-4

[Nicholas Breen]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertag: binnmu
Severity: normal

The last build of src:gromacs on amd64 picked up CPU-specific optimizations
that not all such CPUs support.  This seems to be build environment specific,
and a binNMU should fix it (no such problems on any previous autobuilt binary,
this is the first one in some time where amd64 was the maintainer build).  A
proper long-term fix is planned for the next upstream release.

nmu gromacs_4.6.3-4 . amd64 . -m "Recompile without AVX extensions"

Thanks very much.

--
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725013: [Support] [Debichem-devel] Bug#725013: gromacs-openmpi: grompp crashes with invalid opcode

[Nicholas Breen]

Thank you, I think that information will lead to a solution.  One last
question:

On Tue, Oct 01, 2013 at 11:00:26AM +0300, Vassilis Virvilis wrote:
> 7) Now I am installing in i5
>   It works in my i5. Looks like the problem is only in i7. I have
> tested in the two machines of the cluster. These are xeons that they
> have the problem. Here is an excerpt from /proc/cpuinfo

Could you please check if the i5 machines where it works include "avx" in the
flags line of /proc/cpuinfo?

I built 4.6.3-4 on a different machine than usual, and I think it accidentally
picked up a CPU optimization it should not have had.  AVX extensions were only
added on the Sandy Bridge and newer model Intel CPUs, and the Xeon you provided
the information for doesn't have it.  If that's the case, I will ask for the
package to be rebuilt on a different machine where that problem won't occur.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725013: [Debichem-devel] Bug#725013: gromacs-openmpi: grompp crashes with invalid opcode

[Nicholas Breen]

reassign 725013 gromacs
tags 725013 moreinfo
thanks


On Mon, Sep 30, 2013 at 04:39:48PM +0300, Vassilis Virvilis wrote:
> Trying to run grompp grompp_d
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> It crashes
> 
> dmesg output:
> [ 1699.966132] traps: grompp_d[9667] trap invalid opcode ip:7fb9311ac95d 
> sp:77700ee8 error:0 in libgmx_d.so.8[7fb9310d+4e9000]
> [ 1728.255893] traps: grompp[9684] trap invalid opcode ip:7f6807c2c65d 
> sp:7fff560ed648 error:0 in libgmx.so.8[7f6807b51000+51b000]

I can't reproduce this crash with my test data, and my system runs a similar
Intel CPU (i5-2x00 series).  Could you please attach a file that it crashes on
(or a pdb2gmx/genbox/etc. sequence that creates one) and the exact command line
that causes it to fail?


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#724866: virtual-package-depends-without-real-package-depends: libmpich-dev no longer virtual

[Nicholas Breen]

Package: lintian
Version: 2.5.19
Severity: minor
Tags: patch

libmpich-dev is a real package now, no longer a virtual package, causing false
positives on packages that have shifted their build-dep to it (from the former
libmpich2-dev).  Trivial patch attached.


-- 
Nicholas Breen
nbr...@debian.org
diff -Nru lintian-2.5.19/data/fields/virtual-packages lintian-2.5.19+patch/data/fields/virtual-packages
--- lintian-2.5.19/data/fields/virtual-packages	2013-09-23 09:56:58.0 -0700
+++ lintian-2.5.19+patch/data/fields/virtual-packages	2013-09-28 18:34:07.912271050 -0700
@@ -200,7 +200,6 @@
 liblapack.so.3
 liblapack.so.3gf
 libmp3splt0-plugin
-libmpich-dev
 libneon-dev
 libnora-ruby
 libode0-dev

Bug#724864: libmpich-dev: mpicc.mpich unconditionally sets RPATH

[Nicholas Breen]

Package: libmpich-dev
Version: 3.0.4-3
Severity: normal

mpicc.mpich sets RPATH in all binaries it compiles.

% mpicc.mpich test.c -o test
% objdump -p test | grep RPATH
  RPATH/usr/lib/x86_64-linux-gnu

This seems to be new behavior in v3; building mpich with the configuration
option "--disable-wrapper-rpath" in addition to the long-standing
"--disable-rpath" seems to solve it.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-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/dash

Versions of packages libmpich-dev depends on:
ii  g++ 4:4.8.1-3
ii  gfortran4:4.8.1-3
ii  libc6   2.17-93
ii  libcr-dev   0.8.5-2
ii  libcr0  0.8.5-2
ii  libmpich10  3.0.4-3

Versions of packages libmpich-dev recommends:
ii  mpich  3.0.4-3

libmpich-dev suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#721582: transition: xbae

[Nicholas Breen]

On Thu, Sep 05, 2013 at 11:42:55PM +0200, Julien Cristau wrote:
> On Sun, Sep  1, 2013 at 20:16:20 -0700, Nicholas Breen wrote:
> > I'd like to launch a very small transition for an ABI bump in src:xbae,
> > which does have a renamed package (libxbae4 -> libxbae4m).  This is a
> > sub-dependency of the openmotif transition, #708462.  It should affect
> > only three leaf packages:
> > 
> > * paw and geant321 will need binNMUs
[...]

> That sounds fine.  Please ping this bug when xbae is built everywhere
> and the binNMUs have to be scheduled.

xbae is now built and installed on all architectures.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#721582: transition: xbae

[Nicholas Breen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to launch a very small transition for an ABI bump in src:xbae,
which does have a renamed package (libxbae4 -> libxbae4m).  This is a
sub-dependency of the openmotif transition, #708462.  It should affect
only three leaf packages:

* paw and geant321 will need binNMUs
* grace will recieve a sourceful upload at the same time as xbae (#717644)

All those packages have already been tested with the rebuilt xbae from
experimental, and no problems were seen.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717640: [paw] please transition from lesstif2 to motif

[Nicholas Breen]

As a supplemental note - as the xbae maintainer, I don't mind holding off
temporarily on uploading the Motif-built version to unstable.  If I did it now,
it would render paw and its reverse dependencies uninstallable.  paw and grace
are the only two packages that Build-Depend on libxbae-dev, and I also maintain
grace.

Please let me know when you're ready to upload to unstable, and I'll upload
xbae accordingly.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717763: beets: needs to Depend on python-musicbrainzngs (>= 0.4)

[Nicholas Breen]

Package: beets
Version: 1.2.1-1
Severity: minor

Noticed when setting up the new beets release on a wheezy (stable) system:

% beet stats
Traceback (most recent call last):
  File "/usr/bin/beet", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2711, in 

parse_requirements(__requires__), Environment()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: musicbrainzngs>=0.4

stable still has python-musicbrainzngs 0.2-1, and this problem is easily solved
by installing 0.4-1 from unstable instead.  (In fact, all the dependencies that
beets has at the moment can be satisfied on stable by selectively picking them
out of unstable, no recompilation necessary - very handy!)  Simply adding an
"(>= 0.4)" constraint to the existing Depends: on python-musicbrainzngs should
clear that up for any other prospective backporters.

Thanks very much.

-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#366193: Motif transition

[Nicholas Breen]

tags 366193 -wontfix +pending
severity 366193 normal
user openmo...@packages.debian.org
usertags lesstif2motif
thanks

Now that Openmotif is under a free license, this request is back on the agenda.
Transition bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708462


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714753: [Debichem-devel] Bug#714753: [gromacs] build-depends on lesstif2-dev but does not build with lesstif2

[Nicholas Breen]

On Tue, Jul 02, 2013 at 04:09:39PM +0200, Graham Inggs wrote:
> Gromacs has a build dependency on lesstif2-dev, but does not seem to
> actually build with lesstif2 (Motif).
> None of the binary packages built from gromacs depend on lesstif2
> and running 'ldd * | grep libXm' in the binary package's usr/bin
> directory shows no matches.
> 
> I was unable to find anything in the changelogs that indicated this
> was intentional, so either the configure options could to be fixed
> to build with Motif, or fixed to build without the lesstif2-dev
> dependency.

Leftover from an old viewing program, that I hadn't noticed had been removed
upstream.  I'll fix that in the next upload; there's an upcoming upstream
release already overdue that I'd like to wait for a little longer (days, not
months).


-- 
Nicholas Breen
nbr...@debian.org


-- 
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: ITP -> RFP

[Nicholas Breen]

Control: retitle -1 RFP: votca -- Versatile Object-oriented Toolkit for 
Coarse-graining Applications
Control: owner -1 !


I'm not personally doing much MD work these days, and so I haven't had as much
time or interest to package votca; by now it's well past time to admit I won't
be getting to it.  I would certainly be happy to assist and co-maintain the
package with a more directly motivated user, and could sponsor uploads for a
non-DD.  Maintaining it as part of the debichem team would assist in that
regard.


-- 
Nicholas Breen
nbr...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690858: grace: source-hardening.diff breaks SVG output formatting

[Nicholas Breen]

On Thu, Oct 18, 2012 at 05:19:37PM +0100, Alex Valavanis wrote:
> Package: Grace
> Version: 1:5.1.22-13
> 
> Hi Nicholas,
> 
> The recent source-hardening.diff patch appears to break SVG output
> formatting.  Please see the original bug report in Ubuntu [1].

Hello Alex,

I'm on vacation this week and don't have convenient access to my usual dev
system.  I'll give it a look when I get back.

Thanks,

- Nicholas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#580828: ghemical: Segmentation fault on running MOPAC energy calculation

[Nicholas Breen]

On Fri, Oct 05, 2012 at 12:55:04AM +0200, Michael Banck wrote:
> On Sat, May 15, 2010 at 09:27:34PM -0400, Bill Gunn wrote:
> > It crashes with any molecular geometry I have tried either imported or
> > drawn in ghemical.  I attach two example files I have tested.
> 
> I can reproduce this, albeit only on amd64 not on i386 (Debian stable
> both).  Can somebody reproduce this on 64bit on Debian testing or
> unstable?
> 
> 1. start ghemical
> 2. switch to Draw
> 3. Draw one carbon
> 4. Compute->Setup, switch to all QM
> 5. Compute->Energy 

Following those steps, I cannot reproduce the crash on my amd64/sid system:

Changed the Setup for calculations (setup = allqm, engine = eng1_qm_mopac : 
MOPAC7 / MNDO).
Calculating Energy (setup = allqm, engine = eng1_qm_mopac : MOPAC7 / MNDO).
Energy = -11447.07446209 kJ/mol

(program continues normally, no errors)

Package information appended below.

- Nicholas


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-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/dash

Versions of packages ghemical depends on:
ii  libatk1.0-02.4.0-2
ii  libblas3 [libblas3gf]  1.2.20110419-5
ii  libblas3gf 1.2.20110419-5
ii  libc6  2.13-35
ii  libcairo2  1.12.2-2
ii  libfontconfig1 2.9.0-7
ii  libfreetype6   2.4.9-1
ii  libgcc11:4.7.2-2
ii  libgdk-pixbuf2.0-0 2.26.1-1
ii  libgfortran3   4.7.2-2
ii  libghemical5   3.0.0-2
ii  libgl1-mesa-glx [libgl1]   8.0.4-2
ii  libglade2-01:2.6.4-1
ii  libglib2.0-0   2.33.12+really2.32.4-1
ii  libglu1-mesa [libglu1] 8.0.4-2
ii  libgtk2.0-02.24.10-2
ii  libgtkglext1   1.2.0-3
ii  libice62:1.0.8-2
ii  liblapack3 [liblapack3gf]  3.4.1-6
ii  liblapack3gf   3.4.1-6
ii  libmopac7-1gf  1.15-5
ii  liboglappth2   1.0.0-2
ii  libopenbabel4  2.3.1+dfsg-4
ii  libopenmpi1.3  1.4.5-1
ii  libpango1.0-0  1.30.0-1
ii  libquadmath0   4.7.2-2
ii  libsc7 2.3.1-14
ii  libsm6 2:1.2.1-2
ii  libstdc++6 4.7.2-2
ii  libx11-6   2:1.5.0-1
ii  libxml22.8.0+dfsg1-5
ii  libxmu62:1.1.1-1
ii  libxt6 1:1.1.3-1
ii  mpqc   2.3.1-14


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#689532: grace: please consider packaging new upstream version 5.1.23

[Nicholas Breen]

On Wed, Oct 03, 2012 at 07:12:49PM +0200, Francesco Poli (wintermute) wrote:
> Hello,
> it seems that a new upstream version has recently been released:
> ftp://plasma-gate.weizmann.ac.il/pub/grace/src/grace5/grace-5.1.23.tar.gz
> 
> Please consider packaging it, at least for experimental (if you do not
> want to upload to unstable during a freeze...).

I'll put it in the to-do queue.  As it appears that the bugs it fixes are
generally incorporation of patches already applied in the current package, it
doesn't look like an urgent upgrade.

- Nicholas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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

[Nicholas Breen]

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-dist-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

[Nicholas Breen]

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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#678705: RFS: e2defrag/0.80 ITP: #678598

[Nicholas Breen]

On Sun, Jun 24, 2012 at 02:31:23PM -0400, Phillip Susi wrote:
> On 06/24/2012 12:00 PM, Roger Leigh wrote:
> > This was always a tool which needed to be used with great caution,
> > and was removed for good reason.  Is this safe to use with all
> > ext2, ext3 and ext4 filesystems?
> 
> Obviously there may be bugs, and a crash in mid defrag likely will leave you 
> with a hopelessly corrupted fs, but yes, it is working with all modern ext4 
> features.  I'm kicking around an idea to log enough information to allow for 
> recovery after a crash, but this would significantly slow down the process.

There is already an ext4-specific (depends on creation with -O extent) e4defrag
tool in e2fsprogs since 1.42~WIP-2011-07-02-1.  Is there a reason you would use
one tool over the other?





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673352: lintian: false positive for icon-size-and-directory-name-mismatch on symlinks

[Nicholas Breen]

Package: lintian
Version: 2.5.7
Severity: normal

The test added in 2.5.7 for icons with the wrong size for their directory
(#628189) relies on file-info, which then generates an error and a false
positive on symbolic links.  For example, with the grace package:

% lintian grace_5.1.22-13_amd64.changes
[...]
Use of uninitialized value $2 in concatenation (.) or string at 
/usr/share/lintian/checks/files line 924.
W: grace: icon-size-and-directory-name-mismatch 
usr/share/icons/hicolor/32x32/mimetypes/application-x-grace.png 32x32x
[...]

% file /usr/share/icons/hicolor/32x32/mimetypes/application-x-grace.png 
   
/usr/share/icons/hicolor/32x32/mimetypes/application-x-grace.png: symbolic link 
to `../apps/grace.png'
% file `readlink -f 
/usr/share/icons/hicolor/32x32/mimetypes/application-x-grace.png`
/usr/share/icons/hicolor/32x32/apps/grace.png: PNG image data, 32 x 32, 
8-bit/color RGBA, non-interlaced


-- 
Nicholas Breen
nbr...@debian.org


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-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/dash

Versions of packages lintian depends on:
ii  binutils   2.22-6
ii  bzip2  1.0.6-1
ii  diffstat   1.55-2
ii  file   5.11-1
ii  gettext0.18.1.1-8
ii  hardening-includes 2.1
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26+b1
ii  libc-bin   2.13-32
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.3
ii  libemail-valid-perl0.190-1
ii  libipc-run-perl0.91-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  locales2.13-32
ii  man-db 2.6.1-2
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-10
ii  unzip  6.0-6

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 
ii  dpkg-dev   1.16.3
ii  libhtml-parser-perl3.69-2
ii  libtext-template-perl  
ii  man-db 2.6.1-2
ii  xz-utils   5.1.1alpha+20110809-3

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#670613: Grace should recommend xfont packages

[Nicholas Breen]

On Fri, Apr 27, 2012 at 12:24:23PM +0100, Alex Valavanis wrote:
> Hi Nicholas,
> 
> I guess this is an Ubuntu-specific issue then...
> 
> As of xorg_1:7.6+7ubuntu1, the xfonts-100dpi and xfonts-75dpi packages
> were dropped from "Depends" to "Suggests",[1] and therefore they do
> not appear in a standard Ubuntu installation.

*sigh*.

Well, since that Recommends is essentially a no-op on Debian systems still, it
won't hurt to add it.  I'll apply that to the next upload.

- Nicholas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673319: RM: checkmp3 -- ROM; dead upstream, outdated, better alternatives in archive

[Nicholas Breen]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the checkmp3 package.  It has not seen a new release since 2000,
and therefore has problems with "newer" features that are standard today (VBR
files, id3v2 tags, etc.); even if used only with older files, there are
incomplete and likely buggy checks in the code.  Better options in the archive
include mp3check and mp3diags.


-- 
Nicholas Breen
nbr...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#670613: Grace should recommend xfont packages

[Nicholas Breen]

On Fri, Apr 27, 2012 at 11:32:46AM +0100, Alex Valavanis wrote:
> Grace should recommend the xfonts-100dpi or xfonts-75dpi packages.

I am not convinced this is a useful fix.  The xorg metapackage already Depends
on these packages, and a desktop system without them *and* without a remote
font server is pretty much broken by the user deliberately.  (There are also
-transcoded variants to consider.)  Although nearly any X package requires
fonts to operate properly, almost none have such fonts-related Recommends[*], as
those should be handled either by xorg or the corresponding metapackage for the
user's WM of choice.

- N

[*] apt-cache rdepends --no-suggests xfonts-100dpi : 12 unique results, of
which only 5 are applications; 3 more results that are Suggests:, of
which none are applications



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#571449: Build-dependency on old MPI implementations - intention to NMU

[Nicholas Breen]

This bug has been open without activity for a little over two years now, and is
one of the blockers on the mpi-defaults transition (#573187); I'll upload a NMU
to DELAYED-5 in the next day or two, using the patch in my previous mail,
unless there are any objections.


-- 
Nicholas Breen
nbr...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#662358: grace: Please Build-Depends on libpng-dev, change from libpng12-dev

[Nicholas Breen]

On Mon, Mar 05, 2012 at 03:07:46PM +0900, Nobuhiro Iwamatsu wrote:
> 2012/3/5 Nicholas Breen :
> > On Mon, Mar 05, 2012 at 01:00:43PM +0900, Nobuhiro Iwamatsu wrote:
> >> Libpng maintainers plan transition of libpng[0].
> >> Version 1.2 is used for libpng of current debian, but will shifts
> >> to version 1.5 in this transition.
> >> Your package still does it depending on libpng12-dev.
> >> We cannot shift in transition mentioned above.
> >> Please change Build-Depends of the package from libpng12-dev to libpng-dev.
> >
> > Currently grace Build-Depends on libpng12-dev | libpng-dev.  Is this not
> > adequate for the transition?
> >
> 
> Maybe OK. libpng12-dev provides libpng-dev.
> I am glad to delete libpng12-dev when you set only libpng-dev.

Okay.  grace is currently involved in the netcdf transition [1], so I would
prefer not to upload a new version until that transition is complete if that
will not delay libpng's transition.  (If they cannot be separated, I will
upload grace sooner.)  There should be no problems if libpng12-dev is removed
before then.

- Nicholas

[1] http://release.debian.org/transitions/html/netcdf7.html



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#662358: grace: Please Build-Depends on libpng-dev, change from libpng12-dev

[Nicholas Breen]

On Mon, Mar 05, 2012 at 01:00:43PM +0900, Nobuhiro Iwamatsu wrote:
> Source: grace
> Version: 1.8.4-5

(The current version of grace is 1:1.5.22-12.)

> Libpng maintainers plan transition of libpng[0].
> Version 1.2 is used for libpng of current debian, but will shifts 
> to version 1.5 in this transition.
> Your package still does it depending on libpng12-dev.
> We cannot shift in transition mentioned above. 
> Please change Build-Depends of the package from libpng12-dev to libpng-dev.

Currently grace Build-Depends on libpng12-dev | libpng-dev.  Is this not
adequate for the transition?

Thanks.

-- 
Nicholas Breen
nbr...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#656175: keepass2: Fails to launch under mono 2.10

[Nicholas Breen]

Package: keepass2
Version: 2.18+dfsg-1
Severity: important

% keepass2
Unhandled Exception: System.TypeLoadException: Could not load type 
'KeePass.Program' from assembly 'KeePass, Version=2.1.8.27472, Culture=neutral, 
PublicKeyToken=0738eb9f132ed756'.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load 
type 'KeePass.Program' from assembly 'KeePass, Version=2.1.8.27472, 
Culture=neutral, PublicKeyToken=0738eb9f132ed756'.
%

Working with mono 2.6.7-5, and if manually launched with "mono --runtime=v2.0
/usr/lib/keepass2/KeePass.exe", but not by default after the 2.10.5 upload to
unstable today or with the "--runtime=v4.0" option.  Other reports suggest it
may be a bug in mono itself, e.g.
.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-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/dash

Versions of packages keepass2 depends on:
ii  libmono-corlib2.0-cil2.10.5-2
ii  libmono-system2.0-cil2.10.5-2
ii  libmono-winforms2.0-cil  2.10.5-2
ii  mono-runtime 2.10.5-2

keepass2 recommends no packages.

Versions of packages keepass2 suggests:
pn  keepass2-doc  2.18+dfsg-1
pn  xdotool   

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#644397: [Debichem-devel] Bug#644397: Bug#644397: gromacs: pdb2gmx, version 4.5.5, fails with 'Illegal instruction' on i686, 3.0.0.1-686-pae (testing)

[Nicholas Breen]

Using the binaries with debugging symbols that you built, could you please
collect a backtrace using "gdb" when the program crashes?  It may help to
install the "libc6-dbg" package for additional symbols within libc, which will
probably be *somewhere* in the stack.

http://wiki.debian.org/HowToGetABacktrace#Running_gdb

With luck this will be enough information to localize the problem to a single
function.

- N



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#644397: [Debichem-devel] Bug#644397: Bug#644397: gromacs: pdb2gmx, version 4.5.5, fails with 'Illegal instruction' on i686, 3.0.0.1-686-pae (testing)

[Nicholas Breen]

On Sat, Oct 08, 2011 at 08:26:37PM +0200, groenedraeck wrote:
> $ apt-get source --build gromacs > log.20111007 2>&1

When building that package, it's also possible to both turn on debugging (i.e.
turn off binary stripping at the end) and disable compiler optimization.  The
latter might help avoid the bug, and the former should help identify what
exactly is causing the failure.  A command such as:

 $ DEB_BUILD_OPTIONS=noopt,debug apt-get source --build (etc.)

will enable both options.  I would be curious to learn if that changes the bug
behavior in any way.  Unfortunately I have no access to Duron hardware and
cannot test these myself.



> When finished, the log was inspected for apparent errors. The log
> file frequently contained a MPI implementation error:
> > -- Using manually set binary suffix: "_mpi.mpich"
> > -- Using manually set library suffix: "_mpi.mpich"
> > CMake Warning at CMakeLists.txt:192 (MESSAGE):
> >
> >
> > There are known problems with some MPI implementations:
> >OpenMPI version < 1.4.1
> >MVAPICH2 version <= 1.4.1

These are harmless, it issues those warnings regardless of the OpenMPI version
on the system (your installation is probably using 1.4.3), and pdb2gmx doesn't
use MPI anyhow.

Best,


-- 
Nicholas Breen
nbr...@ofb.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#646418: gpivtools: Please update Depends: on MPI Python packages

[Nicholas Breen]

Source: gpivtools
Severity: normal
Tags: patch

The last update to python-scientific replaced the lampython and mpichpython
packages with openmpipython and mpich2python, which will be the two actively
maintained MPI implementations going forward.  The attached patch updates the
Depends: field in debian/control accordingly, and adds "mpipython" to the
beginning of the list, which is a virtual package that openmpipython and
mpich2python both Provide -- this should help keep gpivtools-mpi from
accidentally becoming uninstallable (as it unfortunately is now!) if those
Python packages change again in the future.

Thanks,

-- 
Nicholas Breen
nbr...@ofb.net

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-2-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/dash
diff -Nru gpivtools-0.6.0.orig/debian/control gpivtools-0.6.0/debian/control
--- gpivtools-0.6.0.orig/debian/control	2011-10-23 19:06:34.0 -0700
+++ gpivtools-0.6.0/debian/control	2011-10-23 19:13:06.648618383 -0700
@@ -47,8 +47,8 @@
 
 Package: gpivtools-mpi
 Architecture: any
-Depends: ${shlibs:Depends}, libgpiv-mpi3, mpi-default-bin, lampython | mpichpython, 
- python-scientific
+Depends: ${shlibs:Depends}, libgpiv-mpi3, mpi-default-bin, 
+ mpipython | openmpipython | mpich2python, python-scientific
 Replaces: gpivtools
 Conflicts: gpivtools
 Recommends: plotmtv, imagemagick

Bug#646417: debian-science: Please update MPI implementations in distributedcomputing task

[Nicholas Breen]

Source: debian-science
Version: 0.13
Severity: normal
Tags: patch

The last update to python-scientific replaced the lampython and mpichpython
packages with openmpipython and mpich2python, which will be the two actively
maintained MPI implementations going forward.  The attached patch updates the
distributedcomputing task to reflect these new binary packages.

Thanks,

-- 
Nicholas Breen
nbr...@ofb.net


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-2-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/dash
diff -Nru debian-science-0.13.orig/debian-science-tasks.desc debian-science-0.13/debian-science-tasks.desc
--- debian-science-0.13.orig/debian-science-tasks.desc	2011-05-04 02:35:42.0 -0700
+++ debian-science-0.13/debian-science-tasks.desc	2011-10-23 19:08:29.495073960 -0700
@@ -162,10 +162,10 @@
  gridengine-qmon
  globus-core
  openmpi-bin
+ openmpipython
  mpich2
- mpichpython
+ mpich2python
  python-mpi
- lampython
 
 Task: science-electronics
 Section: debian-science
diff -Nru debian-science-0.13.orig/tasks/distributedcomputing debian-science-0.13/tasks/distributedcomputing
--- debian-science-0.13.orig/tasks/distributedcomputing	2011-04-29 07:13:30.0 -0700
+++ debian-science-0.13/tasks/distributedcomputing	2011-10-23 19:11:09.287747195 -0700
@@ -19,7 +19,7 @@
 
 Depends: openmpi-bin, mpich2
 
-Depends: mpichpython, python-mpi, lampython
+Depends: openmpipython, mpich2python, python-mpi
 
 Suggests: hpcc
 

Bug#626336: blacs-mpi: Please add support for MPICH2 (libmpich2-dev) builds

[Nicholas Breen]

Patch to add support for mpich2 attached.  I'd be happy to NMU it if you'd
prefer.

Thanks,

-- 
Nicholas Breen
nbr...@ofb.net


blacs-mpi.626336.patch.gz
Description: Binary data

Bug#638760: grace: please remove t1lib dependency

[Nicholas Breen]

On Sun, Aug 21, 2011 at 12:16:03PM -0400, Michael Gilbert wrote:
> t1lib is slated to be removed (in favor of freetype) before wheezy ships
> [0],[1]. This package is currently one of its reverse dependencies.
> Please convert the package to use freetype.

Patches or documentation are of course welcome.  That alone doesn't leave me
much to go on


-- 
Nicholas Breen
nbr...@ofb.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#636970: grace: FTBFS with libpng 1.5

[Nicholas Breen]

On Sun, Aug 07, 2011 at 11:29:04PM +0900, Nobuhiro Iwamatsu wrote:
> I uploaded libpng 1.5.2 to experimental.
> libpng maintainers plan to transition from libpng 1.2 to 1.5.
> I am checking build it the package depend to libpng.
> 
> I noticed your package FTBFS by libpng 1.5.
> I created the patch that revise this problem.
> Could you check and apply this patch?

I'm traveling right now, but can test and upload a new version in about a week,
and also forward the patch upstream.  Will that fit the transition schedule?


-- 
Nicholas Breen
nbr...@ofb.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#631353: developers-reference: Section 5.6.2: delayed queue goes to 15-day, not 8

[Nicholas Breen]

Package: developers-reference
Version: 3.4.4
Severity: minor

A small error in sec. 5.6.2, Delayed uploads: the text refers to upload
directories DELAYED/[012345678]-day, but the delayed queue actually goes as
high as DELAYED/15-day.

<ftp://ftp-master.debian.org/pub/UploadQueue/README>, which is indirectly
linked by way of the deferred queue overview, does describe the full range.

-- 
Nicholas Breen
nbr...@ofb.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#626429: updating mpi-defaults (decommissioning lam)

[Nicholas Breen]

Subject: libmpich2-dev: please add links for /usr/lib/mpich2/{include,lib}
Package: libmpich2-dev
Severity: normal
Tags: patch
User: debian-scie...@lists.debian.org
Usertags: old-mpi-eol

On Wed, May 11, 2011 at 07:37:44AM +0200, Lucas Nussbaum wrote:
> On 10/05/11 at 20:16 -0700, Nicholas Breen wrote:
> > Both of these expect /usr/lib/mpich2/{include,lib} to exist.  The other 
> > three
> > MPI implementations all have such directories, either as the actual 
> > location of
> > the corresponding files or symlinks to them.  MPICH2 maintainers: would you
> > consider adding these directories as well?
> 
> Yes. Could you file a bug and/or provide a patch?

Sure thing, attached.

- Nicholas

diff -Nru mpich2-1.4~rc2_orig/debian/libmpich2-dev.dirs mpich2-1.4~rc2/debian/libmpich2-dev.dirs
--- mpich2-1.4~rc2_orig/debian/libmpich2-dev.dirs	1969-12-31 16:00:00.0 -0800
+++ mpich2-1.4~rc2/debian/libmpich2-dev.dirs	2011-05-11 14:05:37.550301799 -0700
@@ -0,0 +1 @@
+usr/lib/mpich2/lib
diff -Nru mpich2-1.4~rc2_orig/debian/libmpich2-dev.links mpich2-1.4~rc2/debian/libmpich2-dev.links
--- mpich2-1.4~rc2_orig/debian/libmpich2-dev.links	2011-03-30 01:10:12.0 -0700
+++ mpich2-1.4~rc2/debian/libmpich2-dev.links	2011-05-11 14:05:37.550301799 -0700
@@ -1 +1,2 @@
 usr/share/man/man1/mpicxx.1.gz /usr/share/man/man1/mpic++.1.gz
+usr/include/mpich2 usr/lib/mpich2/include
diff -Nru mpich2-1.4~rc2_orig/debian/rules mpich2-1.4~rc2/debian/rules
--- mpich2-1.4~rc2_orig/debian/rules	2011-05-06 14:34:59.0 -0700
+++ mpich2-1.4~rc2/debian/rules	2011-05-11 15:25:43.833771018 -0700
@@ -61,6 +61,9 @@
 	rm -f debian/libmpich2-dev/usr/bin/mpic++ debian/libmpich2-dev/usr/share/man/man1/mpic++.1
 	dh_link -plibmpich2-dev /usr/bin/mpicxx.mpich2 /usr/bin/mpic++.mpich2
 	dh_link -plibmpich2-dev /usr/share/man/man1/mpicxx.mpich2.1 /usr/share/man/man1/mpic++.mpich2.1
+	for i in debian/libmpich2-dev/usr/lib/*.so ; do \
+	  dh_link -plibmpich2-dev usr/lib/`basename $$i` usr/lib/mpich2/lib/`basename $$i` ;\
+	done
 
 binary-install/mpich2::
 	mv debian/mpich2/usr/bin/mpiexec debian/mpich2/usr/bin/mpiexec.mpich2

Bug#626336: blacs-mpi: Please add support for MPICH2 (libmpich2-dev) builds

[Nicholas Breen]

Package: blacs-mpi
Severity: normal
User: debian-scie...@lists.debian.org
Usertags: old-mpi-eol


Hello,

blacs-mpi (as well as scalapack) does not currently support building against
MPICH2, from the libmpich2-dev package.  Eventually mpi-default-dev will switch
over to MPICH2 on the architectures where OpenMPI isn't available, while
LAM/MPI and MPICH1 will be removed from the archive.

It looks like this support can be easily retrofitted into both packages, though
I couldn't quite tell what was going on in the rules files -- is all that
manual library assembly necessary?  Is there a missing function in mpicc that
should be added?

If you do need the explicit list of libraries, "mpicc.mpich2 -show" currently
gives this list:   -lmpich -lopa -lmpl -lrt -lcr -lpthread 

Thank you,

-- 
Nicholas Breen
nbr...@ofb.net



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#571446: Patch to switch from mpich1 to mpi-default-dev

[Nicholas Breen]

The attached patch switches the Build-Depends from libmpich1.0-dev to
mpi-default-dev.  The additional "CC=mpicc" entries ensure correct linking --
the original fftw makefiles assume that "-lmpi" is all the linking they need
for MPI, but the newer implementations need additional libraries that mpicc
enumerates properly.


-- 
Nicholas Breen
nbr...@ofb.net
diff -Nru fftw-2.1.3_orig/debian/control fftw-2.1.3/debian/control
--- fftw-2.1.3_orig/debian/control	2011-05-10 19:17:57.0 -0700
+++ fftw-2.1.3/debian/control	2011-05-10 19:18:54.312346690 -0700
@@ -2,7 +2,7 @@
 Section: oldlibs
 Priority: extra
 Maintainer: Paul Brossier 
-Build-Depends: debhelper (>= 4.0.0), autotools-dev, autoconf, automake, dpatch, libtool, libmpich1.0-dev, gfortran
+Build-Depends: debhelper (>= 4.0.0), autotools-dev, autoconf, automake, dpatch, libtool, mpi-defaults-dev, gfortran
 Build-Conflicts: autoconf2.13, automake1.4  
 Standards-Version: 3.7.3
 
@@ -10,7 +10,7 @@
 Architecture: any
 Section: oldlibs
 Depends: ${shlibs:Depends}
-Suggests: fftw-dev, mpich-bin
+Suggests: fftw-dev, mpi-defaults-bin
 Provides: fftw2-double
 Conflicts: fftw2-double
 Description: library for computing Fast Fourier Transforms
@@ -36,7 +36,7 @@
 Architecture: any
 Section: oldlibs
 Depends: ${shlibs:Depends}
-Suggests: sfftw-dev, mpich-bin
+Suggests: sfftw-dev, mpi-defaults-bin
 Provides: fftw2-single
 Conflicts: fftw2-single, fftw2 (<= 2.1.3-10)
 Description: library for computing Fast Fourier Transforms
diff -Nru fftw-2.1.3_orig/debian/rules fftw-2.1.3/debian/rules
--- fftw-2.1.3_orig/debian/rules	2011-05-10 19:17:57.0 -0700
+++ fftw-2.1.3/debian/rules	2011-05-10 19:30:42.516078892 -0700
@@ -14,7 +14,7 @@
 	CFLAGS += -O2
 endif
 
-CONFFLAGS := --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --enable-shared --enable-mpi --enable-threads 
+CONFFLAGS := --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --enable-shared --enable-mpi --enable-threads
 
 ifeq ($(ARCHITECTURE), i386)
   ARCHCONFFLAGS := --enable-i386-hacks
@@ -30,7 +30,7 @@
 build-arch-stamp: autoreconf-stamp 
 	dh_testdir
 	# single precision
-	F77=gfortran CFLAGS="$(CFLAGS)" ./configure $(CONFFLAGS) --enable-float --enable-type-prefix $(ARCHCONFFLAGS)
+	F77=gfortran CFLAGS="$(CFLAGS)" CC=mpicc ./configure $(CONFFLAGS) --enable-float --enable-type-prefix $(ARCHCONFFLAGS)
 	$(MAKE)
 	#$(MAKE) -C tests check
 	./tests/fftw_test  -t -e -v -p 1024 -x 1
@@ -38,7 +38,7 @@
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp-single
 	$(MAKE) clean
 	# double precision
-	F77=gfortran CFLAGS="$(CFLAGS)" ./configure $(CONFFLAGS) $(ARCHCONFFLAGS)
+	F77=gfortran CFLAGS="$(CFLAGS)" CC=mpicc ./configure $(CONFFLAGS) $(ARCHCONFFLAGS)
 	$(MAKE)
 	#$(MAKE) -C tests check
 	./tests/fftw_test  -t -e -v -p 1024 -x 1