Bug#1063124: libccp4: NMU diff for 64-bit time_t transition

[Andrius Merkys]

Hi,

On Mon, 05 Feb 2024 07:52:37 + Steve Langasek  wrote:

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.


Should I upload libccp4 to unstable, or should I wait until someone 
performing the time_t64 transition does that?


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1068708: Building with EPICS fails because the compiler cannot find `compilerSpecific.h`.

[Andrius Merkys]

Hi Florian,

On 2024-04-10 16:40, Florian Forster wrote:
pkg-config references paths (/build/reproducible-path/…) that likely 
exist on the build system, but are not provided by the package:


```
# pkg-config epics-base --cflags | sed -e 's/  */\n/g'
-I/build/reproducible-path/epics-base-7.0.8+dfsg1/include
-I/build/reproducible-path/epics-base-7.0.8+dfsg1/include/os/Linux
-I/build/reproducible-path/epics-base-7.0.8+dfsg1/include/compiler/gcc
-D_GNU_SOURCE
-D_DEFAULT_SOURCE
-D_X86_64_
-DUNIX
-Dlinux
-ffile-prefix-map=/build/reproducible-path/epics-base-7.0.8+dfsg1=.
-D_FORTIFY_SOURCE=2
-ffile-prefix-map=/build/reproducible-path/epics-base-7.0.8+dfsg1=.
-fstack-protector-strong
-fstack-clash-protection
-fcf-protection
-D_FORTIFY_SOURCE=2
-mtune=generic
-m64
# dpkg -L epics-dev | grep /build; echo $?
1
```


You are right - this has been reported as bug #1059706 and marked as 
fixed since, although incorrect paths apparently were left in 
epics-base.pc. I have reopened #1059706 to deal with that.


Unrelated to this bug: my recommendation would be to keep the CPP flags 
(`-I`, `-D`) and remove the C flags (`-f`, `-m`).


It seems that EPICS straightforwardly puts its build flags to 
epics-base.pc. Many of these flags are specific to EPICS build and 
should not be used for reverse-dependencies.



What compiler do you use?


We test our project with GCC and clang.


OK, thanks.


Does this patch work for you?


Kind of. It fixes the compiler specific include described in the initial 
report, but fails to find an OS specific include:


```
In file included from /usr/include/epics/cadef.h:35,
                  from src/epics.c:26:
/usr/include/epics/epicsThread.h:468:10: fatal error: osdThread.h: No 
such file or directory

   468 | #include "osdThread.h"
       |          ^
```


Can you as well try to add /usr/include/compiler/gcc to your compiler's include 
path?


That path alone is not enough, but this works:

```
make CPPFLAGS="-I/usr/include/epics -I/usr/include/epics/compiler/gcc 
-I/usr/include/epics/os/Linux"

```


I guess that both /usr/include/epics/os/Linux/ and 
/usr/include/epics/compiler/gcc/ should be in the include path. Thus the 
following should work on GCC without patching EPICS code:


make CPPFLAGS="-I/usr/include/epics -I/usr/include/epics/compiler/gcc 
-I/usr/include/epics/os/Linux"


I wonder why clang cannot work with compilerSpecific.h. Most likely it 
contains GCC-specific instructions.


I think a viable solution for clang would be to create an empty file in 
/usr/include/epics/compiler/clang/compilerSpecific.h (no compiler 
specific settings for clang) and use include paths to indicate the used 
compiler, for clang:


make CPPFLAGS="-I/usr/include/epics -I/usr/include/epics/compiler/clang 
-I/usr/include/epics/os/Linux"


However, this should better be discussed with the upstream. They may 
want to automatically identify the compiler using __GNUC__ and similar 
checks.



Thanks for your time and effort maintaining this package, I appreciate it!


Thank you for the report!

Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1059706: epics-base.pc is still broken

[Andrius Merkys]

control: reopen -1
control: found -1 7.0.8+dfsg1-1

Hello,

As epics-base.pc still contains incorrect paths, I am reopening this bug.

Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1068708: Building with EPICS fails because the compiler cannot find `compilerSpecific.h`.

[Andrius Merkys]

Hi Florian,

On 2024-04-09 16:38, Florian Forster wrote:
Building with EPICS fails because the compiler cannot find 
`compilerSpecific.h`:


```
In file included from /usr/include/epics/epicsThread.h:62,
  from /usr/include/epics/cadef.h:35,
  from src/epics.c:26:
/usr/include/epics/compilerDependencies.h:21:10: fatal error: 
compilerSpecific.h: No such file or directory

   21 | #include "compilerSpecific.h"
  | ^~~~
compilation terminated.
make[1]: *** [Makefile:8195: src/epics_la-epics.lo] Error 1
```

The file exists at `/usr/include/epics/compiler/gcc/compilerSpecific.h`, 
which is not a directory searched by the compiler.


According to /usr/share/pkgconfig/epics-base.pc, 
/usr/include/compiler/gcc should be added to include path when compiling.


`"compilerSpecific.h"` isincluded unconditionally, and fails when not 
compiled with GCC. My recommendation is to guard the inclusion of the 
file with an appropriate check, for example:


```
// /usr/include/epics/compilerDependencies.h, line 21
#if __GNUC__
# include "compiler/gcc/compilerSpecific.h"
#endif
```


What compiler do you use? Does this patch work for you? If so, it is 
probably worth upstreaming it. Can you as well try to add

/usr/include/compiler/gcc to your compiler's include path?

Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1061357: python3-spglib: spglib python package not identified by dh_python3

[Andrius Merkys]

Hi,

On 2024-01-23 01:18, Drew Parsons wrote:

But I notice that python3-spglib doesn't provide the .dist-info
directory that most other python packages provide.  I guess dh-python
is using the dist-info mechanism to identify packages. Perhaps we
should file a bug against dh-python for it to run something like
"dpkg -S/usr/lib/python3/dist-packages/" if it doesn't find
a dist-info entry.

In the meantime, I figure spglib's lack of dist-info occurs because
it's a cmake build rather than a python setuptools build, in which
case the problem sits alongside Bug#1061263.


I have uploaded spglib 2.2.0-3 with sort of dual buildsystem where 
python package is built by pybuild. Thus now dist-info is present in the 
binary package. I did not close this bug as I have not attempted to 
rebuilt pymatgen yet. If you do and find the "Cannot find package that 
provides spglib" message gone, please close this bug.


Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1061357: spglib: buildsystem could be switched to scikit-build-core

[Andrius Merkys]

Hi,

On 2024-01-23 09:32, Andrius Merkys wrote:
I think both #1061263 and #1061357 could be solved by switching spglib's 
buildsystem to one based on scikit-build-core, as its pyproject.toml 
supports that.


I made an attempt to build spglib with scikit-build-core by specifying 
'--buildsystem pybuild' in debian/rules, adding the required build 
dependencies and patching pyproject.toml to run tests for Python. As 
expected, spglib is built for all supported Python versions. Shared 
libraries are built as well, but they are built for every supported 
Python version separately and are different (at least of same size). 
Fortran interface does not get built at all.


So the buildsystem could be switched, possibly resolving both #1061263 
and #1061357, but with the price of losing Fortran interface and strange 
issue with different shared libraries (maybe just an unreproducible build).


Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1061263: spglib: buildsystem could be switched to scikit-build-core

[Andrius Merkys]

Hi,

I think both #1061263 and #1061357 could be solved by switching spglib's 
buildsystem to one based on scikit-build-core, as its pyproject.toml 
supports that.


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1061263: python3-spglib: fails with python3.12 (extension not built)

[Andrius Merkys]

Hi Drew,

On 2024-01-21 19:32, Drew Parsons wrote:

Package: python3-spglib
Version: 2.2.0-2
Severity: normal

python3-spglib fails with python3.12, since the python extension is
built only for python3.11.


Yes, for the time being, spglib builds for default Python only.


spglib should be configured to build for all available python versions.
In other libraries (e.g. fenics-basix) this is done by building the C
library separately from the the python module.


Thanks for a pointer, I will give fenics-basix a look. I did not manage 
to figure out a way to build spglib for all available Python versions.



Not sure, should this be severity: serious?


I think no. Supporting default Python only is not RC-critical, AFAIR. 
However, having spglib support all Python versions would fix other 
issues, like #1056457.


Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Andrius Merkys]

Hi Yogeswaran,

On 2024-01-16 03:43, Yogeswaran Umasankar wrote:

I have removed the hard-coded version number from setup.py. I found that
the issue was due to changes in PEP440 version naming convention in
versioneer. For this package no need python3-versioneer, upstream has
its own versioneer.py. The work around is, once have everything in
master branch create a tag with just the version number (0.0.2-1)
instead of debian/version number (debian/0.0.2-1).


This would not work, either. Debian build machines build packages not 
from git repositories, but from source packages. Therefore they will not 
see git tags. Moreover, one should not deviate from Debian packaging 
principles to make a package build, thus Debian git tag names should not 
be tampered with.



I have forked python-mpiplus [0] for you to check the changes and to see
how it works before you decide to incorporate the changes. Feel free to
MR the fork and make any further changes needed.

[0] https://salsa.debian.org/yogu/python-mpiplus


Thanks for looking into python-mpiplus, but I have chosen a different 
approach to deal with this issue. I removed embedded versioneer.py in 
favor of python3-versioneer thus resolving the build issue. This is not 
optimal either, as versioneer-derived package version stays '0+unknown', 
but this does not seem to be uncommon in Debian [1].


[1] $ apt-file search 0+unknown.egg-info

Thank you for caring for python-mpiplus.

Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Andrius Merkys]

Hi Yogeswaran,

On 2024-01-14 18:46, Yogeswaran Umasankar wrote:

I created a patch for fixing AttributeError: module 'configparser' has
no attribute 'SafeConfigParser'. In the process I have updated it to the
latest upstream too. I’ve attached the debdiff for you to check out.


I noticed you have hard-coded the version number in setup.py. I would 
suggest against doing that as maintainer(s) will have to refresh this 
patch each time a new upstream release is imported. Manual tasks tend to 
be easily overlooked.


I think a better fix would be to use versioneer packaged in Debian 
package python3-versioneer, although I have not tried that.


Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1059706: epics-base.pc is broken in epics-dev package

[Andrius Merkys]

Control: tags -1 + confirmed

Hi,

On 2023-12-30 18:06, Matwey V. Kornilov wrote:

Package: epics-dev
Version: 7.0.7+dfsg1-5

Please note, that epics-base.pc file is installed into
/usr/share/pkg-config instead of /usr/share/pkgconfig and cannot be
found.


I have just fixed this in the packaging repository, but the upload will 
have to wait for the fix in pkgconfig content.



Also, content of epics-base.pc points to the nonexistent paths:

# standard variables
prefix=/build/reproducible-path/epics-base-7.0.7+dfsg1
exec_prefix=${prefix}
bindir=${prefix}/bin/linux-x86_64
libdir=${prefix}/lib/linux-x86_64


Right, these are incorrect, prefix should be set to /usr, bindir should 
be free of arch-specific suffix and libdir should include correct arch 
triplet. Not sure how to fix these properly, though. Maybe this could be 
done at initial configuration step, but I know the build system too 
little to say know. Will give a look a couple days later.


Thanks,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1059175: dials: FTBFS: Imported target "DXTBX::DXTBX" includes non-existent path

[Andrius Merkys]

Control: tags -1 + patch pending

Hi,

On 2023-12-21 00:42, Sebastian Ramacher wrote:

Source: dials
Version: 3.12.1+dfsg3-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=dials=amd64=3.12.1%2Bdfsg3-5%2Bb2=1702954054=0

-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found 
version "1.83.0") found components: thread python312
-- Configuring done (3.1s)
CMake Error in src/dials/algorithms/background/CMakeLists.txt:
   Imported target "DXTBX::DXTBX" includes non-existent path

 "/usr/lib/python3/dist-packages/dxtbx/src"


I have fixed this and pushed the fix to salsa. Salsa contains an 
unreleased new upstream version, therefore I refrain from upload. The 
same patch is applicable to 3.12.1+dfsg3 as well.


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1056241: dials autopkg tests fail with Python 3.12

[Andrius Merkys]

Hi,

On 2023-11-19 13:42, Matthias Klose wrote:

dials autopkg tests fail with Python 3.12:


[...]

548s E   FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/cctbx/python3.12'
548s === short test summary info 

548s ERROR  - FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/cc...
548s  Interrupted: 1 error during collection 

548s === 1 error in 0.19s 
===

548s autopkgtest [18:27:52]: test command1: ---]
548s command1 FAIL non-zero exit status 2


This is due to cctbx not having support for Python 3.12 yet.

Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1055896: cod-tools: FTBFS: source.c:33:5: error: ‘SPGCONST’ undeclared (first use in this function); did you mean ‘OP_CONST’?

[Andrius Merkys]

Control: owner -1 !

Hi,

On 2023-11-14 14:27, Gianfranco Costamagna wrote:

https://github.com/cod-developers/cod-tools/commit/2e9c0aaa367366883105fa9a7ba3d965495700f8

Just removing SPGCONST from the source.c file is enough, trivial patch 
attached:


Sadly I opened an upstream PR before upstream updated the branch, so the 
patch I uploaded in Ubuntu has my name as author


[patch removed for brevity]

I will soon update cod-tools to the newest upstream release where this 
bug is fixed.


Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1054433: node-puppeteer: website is build with Docusaurus not packaged for debian

[Andrius Merkys]

Hi,

On 2023-10-23 22:06, Bastien Roucariès wrote:

Source: fasttext


Source package names in Subject and Source do not match. Please retitle 
if this is not intentional.


Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: RFP: SAIL image decoding library

[Andrius Merkys]

Hi Dmitry,

On 2023-10-17 16:25, Dmitry Baryshev wrote:

 > Does it produce desired Debian packages?

I've just pushed a couple of fixes to the Debian rules. I'm able to 
build packages on LUbuntu 23.04. Maybe a couple of small fixes are still 
needed to build packages on Debian. So the recommended git sha to use is 
4705cb4cf96. It's a release candidate and ready to use in client 
applications.


In Debian the common practice is to separate the upstream repository 
(i.e., the package source) from packaging repository (i.e., where Debian 
packaging instructions are being developed). Common practice is to host 
the latter on salsa.debian.org, usually together with the package 
source. Thus I would suggest following this approach. I have put a short 
guide about how to do that [1].



 > Are these packages lintian-clean?

The only error Lintian showed is "unknown distribution", but this is 
because I run it on Ubunutu.


Right.

 > Do you know any software already in Debian which would benefit from 
having SAIL in Debian?


It's a library and I guess end users will benefit from it.


OK, makes sense.

Since this is an image decoding library, my personal opinion is that it 
would better fit the scope of Debian Multimedia Team instead of Debian 
Science Team.


[1] https://wiki.debian.org/AndriusMerkys/PackagingInSeconds

Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: RFP: SAIL image decoding library

[Andrius Merkys]

Hi Dmitry,

On 2023-10-17 13:29, Dmitry Baryshev wrote:
It would be great to have SAIL in Debian, at least in experimental. It's 
a C/C++ image decoding library similar to FreeImage. It's already 
available in Conan and VCPKG with thousands of installations.


Website: https://sail.software/ 
GitHub:https://github.com/HappySeaFox/sail 

RFP request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053729 


Build system: CMake
Debian rules: Yes, but need revisiting

Please pardon me if I'm writing to a wrong mailing list. Please CC any 
comments as I'm not in the list.


I saw the GitHub repository already has debian/ directory, this is a 
good start. Does it produce desired Debian packages? Are these packages 
lintian-clean? Do you know any software already in Debian which would 
benefit from having SAIL in Debian?


Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1052888: epics-base: FTBFS: make[2]: *** [configure/RULES_TOP:62: runtests] Error 1

[Andrius Merkys]

Control: tags -1 + unreproducible

On Tue, 26 Sep 2023 15:34:01 +0200 Lucas Nussbaum  wrote:

Source: epics-base
Version: 7.0.7+dfsg1-5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


I cannot reproduce the issue on amd64. From your log the relevant part 
seems to be the following:


epicsEventTrigger: pthread_mutex_lock failed: Invalid argument
epicsEventMustTriggerThread CAC-event (0x7f4370025b30) can't proceed, 
suspending.

Dumping a stack trace of thread 'CAC-event':
[0x7f4384e76943]: 
/<>/lib/linux-x86_64/libCom.so.3.22.0(epicsStackTrace+0x73)
[0x7f4384e679a9]: 
/<>/lib/linux-x86_64/libCom.so.3.22.0(cantProceed+0xc9)
[0x7f4384eec0b1]: 
/<>/lib/linux-x86_64/libdbCore.so.3.22.0(testdbCaWaitForEventCB+0x21)
[0x7f4384b4a2bc]: 
/<>/lib/linux-x86_64/libca.so.4.14.2(_ZN15oldSubscription7currentER10epicsGuardI10epicsMutexEjmPKv+0x6c)
[0x7f4384ef052a]: 
/<>/lib/linux-x86_64/libdbCore.so.3.22.0(_ZN9dbContext15callStateNotifyEP9dbChanneljmPK12db_field_logR14cacStateNotify+0x17a)
[0x7f4384ee4645]: 
/<>/lib/linux-x86_64/libdbCore.so.3.22.0(event_task+0x1e5)
[0x7f4384e70842]: 
/<>/lib/linux-x86_64/libCom.so.3.22.0(start_routine+0xd2)
[0x7f4384cd13ec]: 
/lib/x86_64-linux-gnu/libc.so.6(pthread_condattr_setpshared+0x4cc)

[0x7f4384d51a2c]: /lib/x86_64-linux-gnu/libc.so.6(__clone+0x11c)
Thread CAC-event (0x7f4370025b30) suspended
regressTest.t: Timed out './regressTest' after 500 seconds
regressTest.t ...

I think the test has timed out due to the high load of the building 
machine. If this persists, increasing the timeout value could be a solution.


Cheers,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1049872: armel and armhf excluded from asmjit architectures

[Andrius Merkys]

control: severity -1 normal

Hello,

In 0.0~git20230914.917f19d-1 I have excluded armel and armhf 
architectures from the list of architectures asmjit is built upon. Thus 
I think the severity should be normal now.


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1049872: FTBFS on multiple release architectures

[Andrius Merkys]

Hi Emanuele,

On 2023-09-11 12:07, Emanuele Rocca wrote:

On 2023-09-09 08:38, Andrius Merkys wrote:

This is news to me. Could you please point out where in Debian Policy I can
read more about such requirement? I thought I saw packages dropping support
for one or another release architecture without being removed from testing.

Seehttps://release.debian.org/testing/rc_policy.txt  section 4
(Autobuilding).


Thanks for the pointer. According to the cited RC policy this is indeed 
an RC bug. I will see what I can do about it.


Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1049872: FTBFS on multiple release architectures

[Andrius Merkys]

Hi Emanuele,

On 2023-09-05 16:58, Emanuele Rocca wrote:

On 2023-08-28 07:42, Andrius Merkys wrote:

On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca  wrote:

asmjit does not build correctly on the following architectures:
armel, armhf, mips64el, mipsel, s390x.


Does this constitute an RC bug? If not, severity should be lowered.


It does, on armel and armhf the package did build successfully in the
past. See:

https://buildd.debian.org/status/logs.php?pkg=asmjit=armhf
https://buildd.debian.org/status/logs.php?pkg=asmjit=armel


This is news to me. Could you please point out where in Debian Policy I 
can read more about such requirement? I thought I saw packages dropping 
support for one or another release architecture without being removed 
from testing.



Bug retitled given that meanwhile the issue has been fixed on mips64el,
mipsel, and s390x.


This is correct, thanks.

Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1049872: FTBFS on multiple release architectures

[Andrius Merkys]

Hi,

On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca  wrote:

asmjit does not build correctly on the following architectures:
armel, armhf, mips64el, mipsel, s390x.


Does this constitute an RC bug? If not, severity should be lowered.

Thanks,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1039917: [Debichem-devel] Bug#1039917: gemmi breaks finalcif autopkgtest: causes autopkgtest timeout

[Andrius Merkys]

Hi,

On 2023-06-29 17:06, Paul Gevers wrote:
With a recent upload of gemmi the autopkgtest of finalcif fails in 
testing when that autopkgtest is run with the binary packages of gemmi 
from unstable. It passes when run with only packages from testing. In 
tabular form:


    pass    fail
gemmi  from testing    0.6.2+ds-2
finalcif   from testing    113+dfsg-2
all others from testing    from testing

I copied some of the output at the bottom of this report. After the 
fifth test, there's no output until autopkgtest aborts after 2:47 hours. 
Normally the test takes 2 to 3 minutes.


Currently this regression is blocking the migration of gemmi to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


I have just updated finalcif to its new upstream release. This should 
restore finalcif's compatibility with gemmi. Should finalcif's 
autopkgtests pass, I will close this bug.



[1] https://qa.debian.org/excuses.php?package=gemmi


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1039087: epic-base: embed yajl

[Andrius Merkys]

Hi,

On Sun, 25 Jun 2023 15:02:18 + =?utf-8?q?Bastien_Roucari=C3=A8s?= 
 wrote:

Your package embed a copy of yajl.


I agree with un-embedding.


Could you:
- compile against the packaged yajl package


I spent some time trying, but did not find an unintrusive way to do so. 
Adding OP_SYS_INCLUDES passes the compilation:


override_dh_auto_build:
make LINKER_USE_RPATH=NO OP_SYS_INCLUDES=-I/usr/include/yajl

But I could not make the linker use the yajl library, arriving at the 
following failure:


/usr/bin/g++ -o yajl_test 
-L/home/merkys/epics-base-7.0.3.1/lib/linux-x86_64   -rdynamic 
-m64 yajl_test.o-lCom

/usr/bin/ld: yajl_test.o: in function `main':
yajl_test.c:(.text.startup+0x62): undefined reference to `yajl_alloc'
/usr/bin/ld: yajl_test.c:(.text.startup+0xde): undefined reference to 
`yajl_parse'
/usr/bin/ld: yajl_test.c:(.text.startup+0x119): undefined reference to 
`yajl_complete_parse'
/usr/bin/ld: yajl_test.c:(.text.startup+0x129): undefined reference to 
`yajl_free'
/usr/bin/ld: yajl_test.c:(.text.startup+0x212): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x26b): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x31b): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x343): undefined reference to 
`yajl_config'
/usr/bin/ld: yajl_test.c:(.text.startup+0x374): undefined reference to 
`yajl_get_error'
/usr/bin/ld: yajl_test.c:(.text.startup+0x39d): undefined reference to 
`yajl_free_error'
/usr/bin/ld: yajl_test.c:(.text.startup+0x3fd): undefined reference to 
`yajl_free'

collect2: error: ld returned 1 exit status


- remove by repacking the embded code copy in order to avoid accidental
compilation of the embed code copy

This should be doable when the build succeeds.

Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1016958: epics-base: FTBFS without network access

[Andrius Merkys]

Hello,

On 2023-02-28 12:57, Santiago Vila wrote:

Hello. Merely trying network access is already considered RC,
so this should really be serious.

(I would be willing to test a fix if somebody proposes one).


This particular test seems to attempt to communicate to a locally 
running server daemon. It assumes a certain executable is installed in 
$PATH, thus will always fail in build time tests. I think it is OK to 
skip the test entirely and maybe make it an autopkgtest.


On a related note, is trying network access to localhost RC?

Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: parallel-hashmap_1.3.8+ds-1_amd64.changes REJECTED

[Andrius Merkys]

Hi,

On 2023-02-24 21:00, Thorsten Alteholz wrote:

please also mention Daniel James and the Boost license in your debian/copyright.


Thanks for the hint! I have fixed this and reuploaded.

Best wishes,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1027215: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andrius Merkys]

Hello,

On 2023-01-14 13:12, Rebecca N. Palmer wrote:
theano has been mostly abandoned upstream since 2018.  (The Aesara fork 
is not abandoned, but includes interface changes including the import 
name, so would break reverse dependencies not specifically altered for it.)


Its reverse dependencies are keras, deepnano and invesalius.

It is currently broken, probably by numpy 1.24 (#1027215), and the 
immediately obvious fixes weren't enough 
(https://salsa.debian.org/science-team/theano/-/pipelines).


Is this worth spending more effort on fixing, or should we just remove it?


keras is needed to train evaluation models for qmean [1] which I intend 
[2] to package eventually. qmean is a quite popular protein model 
evaluation tool, personally I use it a lot and I believe it would be 
useful to have it in Debian.


That said, it is OK to omit keras in bookworm if need be, but I would 
like to see it back for trixie.


[1] 
https://git.scicore.unibas.ch/search?search=keras_source=navbar_id=69_id=25_code=true_ref=master

[2] https://bugs.debian.org/976981

Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1026011: scilab: replace liblucene4.10-java with liblucene8-java

[Andrius Merkys]

Source: scilab
Version: 6.1.1+dfsg2-4

Hello,

scilab build-depends on liblucene4.10-java while it declares 
compatibility with lucene up to 8.4.0 (see scilab/CHANGES.md). Debian 
has lucene 8.8.1 packaged as liblucene8-java, which is later than 8.4.0 
but is worth trying (I did not try due to #1012099).


Additional rationale of moving to liblucene8-java is reducing the number 
of dependencies of key packages: scilab is key package, liblucene8-java 
is a dependency of h2database). By the way, liblucene4.10-java is 
affected by #1022325 of severity:serious.


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1024526: simbody: FTBFS on ppc64el, mips64el

[Andrius Merkys]

Control: severity -1 important

The upstream says this is a bug in optimization, but they do not have 
access to these architectures. For now I have RMed the binaries of 
ppc64el and mips64el, thus the package should be allowed to migrate to 
testing without them for the time being.


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: python-pymbar_3.1.0-1_amd64.changes REJECTED

[Andrius Merkys]

Hi Thorsten,

On 2022-10-04 21:00, Thorsten Alteholz wrote:

please also mention at least:

  The Regents of the University of California
  Stanford University and Columbia University
  University of Virginia
  University of Colorado Boulder, Memorial Sloan Kettering Cancer Center

in your debian/copyright.


Thanks for the hint, I have fixed and reuploaded the package.

Best,
Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1016958: FTBFS: epics-base

[Andrius Merkys]

control: retitle -1 epics-base: FTBFS without network access
control: severity -1 important

On Wed, 10 Aug 2022 16:51:20 +0200 Sven Mueller  wrote:

We ran into a build failure of epics-base in Debian testing during
rebuilds, but it seems the same error also occurs in the reproducible
builds process, see
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epics-base.html


FTBFS on amd64 seems to be due to the absence of network access:

#   Failed test 'Got same BaseVersion from pvget'
#   at netget.t line 135.
#   '2023-11-01T17:56:51.313 Failed to introspect 
interfaces or no network interfaces available.

# test-1398452:BaseVersion 2023-11-01 17:56:50.828  7.0.3.1
# '
# doesn't match '(?^x:^ test-1398452:BaseVersion \s .* 7\.0\.3\.1 
\s* $)'

# Looks like you failed 1 test of 3.

The test could be patched to ignore the "Failed to introspect interfaces 
or no network interfaces available" part as the remaining message seems 
to be in line with the expected result.


Andrius

--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1012498: finalcif: FTBFS with python3-gemmi 0.5.5+ds

[Andrius Merkys]

Source: finalcif
Version: 104+dfsg-1
Severity: serious
Tags: ftbfs

finalcif FTBFS with python3-gemmi 0.5.5+ds:

self = 

@property
def is_centrosymm(self) -> bool:
"""
Whether a structuere is centro symmetric or not.
"""
if not self.symmops or self.symmops == ['']:
# Do not crash without symmops
return False
ops = gemmi.GroupOps([gemmi.Op(o) for o in self.symmops])
>   return ops.is_centric()
E   AttributeError: 'gemmi.GroupOps' object has no attribute
'is_centric'

finalcif/cif/cif_file_io.py:567: AttributeError

It worked fine with python3-gemmi 0.5.4+ds, thus the cause is API change
in python3-gemmi.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1011928: patch available

[Andrius Merkys]

Control: tags -1 + patch

Hello,

I can confirm the FTBFS with libtbb-dev/2021.5.0-9 in experimental.
However, trilinos can be compiled without TBB by removing the following
from configure step in debian/rules:

-DTPL_ENABLE_TBB:BOOL=ON

With this removed trilinos built fine in experimental.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1012128: opencascade: FTBFS with onetbb/2021.5.0-8 in experimental

[Andrius Merkys]

Source: opencascade
Version: 7.5.1+dfsg1-2
Severity: normal
Tags: ftbfs

Hello,

tbb/onetbb transition (#1007222) is currently in the planning. During
test rebuild of libtbb-dev reverse dependencies with onetbb/2021.5.0-8
in experimental, current source failed to build with the following:

[  0%] Building CXX object
src/TKernel/CMakeFiles/TKernel.dir/__/OSD/OSD_Parallel_TBB.cxx.o
cd /<>/obj-x86_64-linux-gnu/src/TKernel && /usr/bin/c++
-DHAVE_FREEIMAGE -DHAVE_RAPIDJSON -DHAVE_TBB -DOCC_CONVERT_SIGNALS
-DTKernel_EXPORTS -I/usr/include/tcl -I/usr/include/freetype2
-I/<>/obj-x86_64-linux-gnu/include/opencascade -std=c++0x
-Wdate-time -D_FORTIFY_SOURCE=2
 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-fexceptions -fPIC -Wall -Wextra -O2 -g -DNDEBUG -fPIC -MD -MT
src/TKernel/CMakeFiles/TKernel.dir/__/OSD/OSD_Parallel_TBB.cxx.o -MF
CMakeFiles/TKernel.dir/__/OSD/OSD_Parallel_TBB.cxx.o.d -o
CMakeFiles/TKernel.dir/__/OSD/OSD_Parallel_TBB.cxx.o -c
/<>/src/OSD/OSD_Parallel_TBB.cxx
/<>/src/OSD/OSD_Parallel_TBB.cxx:28:10: fatal error:
tbb/task_scheduler_init.h: No such file or directory
   28 | #include 
  |  ^~~
compilation terminated.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1012126: deal.ii: FTBFS with onetbb/2021.5.0-9 in experimental

[Andrius Merkys]

Source: deal.ii
Version: 9.3.2-1
Severity: normal
Tags: ftbfs

Hello,

tbb/onetbb transition (#1007222) is currently in the planning. During
test rebuild of libtbb-dev reverse dependencies with onetbb/2021.5.0-9
in experimental, current source failed to build with the following:

-- Include /<>/cmake/configure/configure_1_tbb.cmake
-- Found TBB_LIBRARY
-- TBB_DEBUG_LIBRARY not found! The call was:
-- FIND_LIBRARY(TBB_DEBUG_LIBRARY NAMES tbb_debug HINTS
PATH_SUFFIXES lib lib64 lib)
-- TBB_INCLUDE_DIR not found! The call was:
-- FIND_PATH(TBB_INCLUDE_DIR tbb/tbb_stddef.h HINTS PATH_SUFFIXES
include include/tbb tbb)
--   TBB_LIBRARIES: /usr/lib/x86_64-linux-gnu/libtbb.so
--   TBB_INCLUDE_DIRS: *** Required variable "TBB_INCLUDE_DIR" set to
NOTFOUND ***
--   TBB_USER_INCLUDE_DIRS: *** Required variable "TBB_INCLUDE_DIR" set
to NOTFOUND ***
-- Could NOT find TBB
-- The externally provided TBB library is older than version 4.2.0,
which cannot be used with deal.II.
-- DEAL_II_WITH_TBB has unmet external dependencies.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1011750: gazebo: FTBFS with onetbb/2021.5.0-9 in experimental

[Andrius Merkys]

Source: gazebo
Version: 11.10.1+dfsg-2
Severity: normal
Tags: ftbfs

Hello,

tbb/onetbb transition (#1007222) is currently in the planning. During
test rebuild of libtbb-dev reverse dependencies with onetbb/2021.5.0-9
in experimental, current source failed to build with the following:

[ 42%] Building CXX object
gazebo/transport/CMakeFiles/gazebo_transport.dir/Connection.cc.o
cd
/home/merkys/gazebo-11.10.1+dfsg/obj-x86_64-linux-gnu/gazebo/transport
&& /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK
-DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK
-DBOOST_IOSTREAMS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK
-DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_TEST_DYN_LINK
-DBOOST_THREAD_DYN_LINK -DBUILDING_DLL -DBUILDING_DLL_GZ_TRANSPORT
-DHAVE_OPENGL -DIGN_PROFILER_ENABLE=0 -DLIBBULLET_VERSION=3.05
-DLIBBULLET_VERSION_GT_282 -Dgazebo_transport_EXPORTS
-I/home/merkys/gazebo-11.10.1+dfsg
-I/home/merkys/gazebo-11.10.1+dfsg/obj-x86_64-linux-gnu
-I/usr/include/libusb-1.0 -I/usr/include/ignition/transport8 -isystem
/usr/include/ignition/msgs5 -isystem /usr/include/ignition/math6
-isystem /usr/include/ignition/common3 -isystem
/usr/include/ignition/fuel_tools4 -isystem
/usr/include/OGRE/RTShaderSystem -isystem /usr/include/OGRE -isystem
/usr/include/OGRE/Terrain -isystem /usr/include/OGRE/Paging -isystem
/usr/include/OGRE/Overlay -isystem /usr/include/sdformat-9.7 -isystem
/usr/include/uuid -isystem /usr/include/sdformat-9.7/sdf/.. -g -O2
-ffile-prefix-map=/home/merkys/gazebo-11.10.1+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2   -Wall -Wextra -Wno-long-long -Wno-unused-value
-Wfloat-equal -Wshadow -Wswitch-default -Wmissing-include-dirs -pedantic
-fvisibility=hidden -fvisibility-inlines-hidden  -fPIC   -fPIC
-I/usr/include/uuid -MD -MT
gazebo/transport/CMakeFiles/gazebo_transport.dir/Connection.cc.o -MF
CMakeFiles/gazebo_transport.dir/Connection.cc.o.d -o
CMakeFiles/gazebo_transport.dir/Connection.cc.o -c
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.cc
In file included from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/ConnectionManager.hh:31,
 from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.cc:60:
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.hh:62:5:
error: expected class-name before '{' token
   62 | {
  | ^
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.hh:77:20:
error: 'task' in namespace 'tbb' does not name a type
   77 |   public: tbb::task *execute()
  |^~~~
In file included from /usr/include/tbb/task.h:17,
 from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.hh:20,
 from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/ConnectionManager.hh:31,
 from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.cc:60:
/usr/include/oneapi/tbb/task.h:26:11: note: 'tbb::v1::task' declared here
   26 | namespace task {
  |   ^~~~
In file included from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/ConnectionManager.hh:31,
 from
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.cc:60:
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.hh: In
member function 'void gazebo::transport::Connection::OnReadData(const
boost::system::error_code&, boost::tuples::tuple)':
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.hh:317:61:
error: 'allocate_root' is not a member of 'tbb::v1::task'
  317 |   ConnectionReadTask *task =
new(tbb::task::allocate_root())
  |
^
/home/merkys/gazebo-11.10.1+dfsg/gazebo/transport/Connection.hh:319:30:
error: 'enqueue' is not a member of 'tbb::v1::task'
  319 |   tbb::task::enqueue(*task);
  |  ^~~

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1011112: onetbb: FTBFS on mips64el/mipsel: libtbbmalloc is not built

[Andrius Merkys]

Source: onetbb
Version: 2021.5.0-8
Severity: important
Tags: ftbfs

Hello,

onetbb seemingly does not provide libtbbmalloc for mips* architectures.
>From CMakeLists.txt:

if (NOT "${CMAKE_SYSTEM_PROCESSOR}" MATCHES "mips")
if (TBBMALLOC_BUILD)
add_subdirectory(src/tbbmalloc)
add_subdirectory(src/tbbmalloc_proxy)
endif()
# skip for brevity
endif()

Thus either libtbbmalloc* binary packages should not be built for mips*
architectures, or a way to provide them should be found.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[Andrius Merkys]

Hi,

On 2022-05-13 01:32, M. Zhou wrote:
> Yes. If you have time to handle it please go ahead.
> I'm suffering from a recent paper submission deadline,
> so I'm only able to build and upload some small packages
> that can be built on my weak laptop.
> The paper deadline is May 19. After that I should be
> able to handle this with a proper build machile.

Thanks. I will see if I can get do this sooner. I have successfully
built both packages on my machine.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[Andrius Merkys]

Hello,

Can we proceed with splitting out libtbbmalloc2 if there are no
blockers? tbb/onetbb transition is blocking quite some packages, it
would be nice to deal with all of them until the freeze.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1009191: cctbx: please re-enable building on riscv64

[Andrius Merkys]

Hi,

On 2022-04-30 13:29, Neil Williams wrote:
>> Neil, is there a particular reason riscv64 support was disabled in
>> 2021.12+ds1-3? 
> I didn't see it as particularly likely that any real-world usage of
> cctbx was manageable on any current RISCV64 hardware. 

Thanks for explanation. I usually disable only the explicitly
unsupported architectures, or the ones that fail and would otherwise
block migration.

>> cctbx seems to build fine on riscv64 now. Can it be
>> re-enabled?
> Probably, yes. I won't have time to do an upload soon though. 
> 
> If someone else has time to do it as a team upload, go ahead. 

I will enable riscv64 and team upload.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1009191: cctbx: please re-enable building on riscv64

[Andrius Merkys]

Hello,

On 2022-04-08 17:57, Graham Inggs wrote:
> Building on riscv64 was silently disabled in 2021.12+ds1-3.
> 2021.12+ds1-2 built successfully in the past [1], and 2021.12+ds1-4
> continues to build in Ubuntu.
> 
> Please re-enable building on riscv64 as we would like to promote
> riscv64 to a release architecture.

Neil, is there a particular reason riscv64 support was disabled in
2021.12+ds1-3? cctbx seems to build fine on riscv64 now. Can it be
re-enabled?

> [1] https://buildd.debian.org/status/logs.php?pkg=cctbx=riscv64

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[Andrius Merkys]

Hi Andreas,

On 2022-04-23 14:21, Andreas Metzler wrote:
>> After that, build fails at dh_shlibdeps step:
>>dh_shlibdeps
>> dpkg-shlibdeps: error: cannot find library libtbbmalloc.so.2 needed by
>> debian/libtbbmalloc2/usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc_proxy.so.2
>> (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
> You need to 
> chmod +x debian/libtbbmalloc2.install
> after applying the patch to activate dh_exec.

This worked, thanks! I can confirm libtbb2 and libtbb12 are
co-installable now, thus I can work on packaging pufferfish (#944785),
which transitively depends on both of these libs packages.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[Andrius Merkys]

Hello,

For me tbb 2020.3-1 fails to build in sid chroot with tbb.diff applied.
First of all, build runs into missing symbols. I managed to get past
this by removing them:

--- a/debian/libtbbmalloc2.symbols.amd64
+++ b/debian/libtbbmalloc2.symbols.amd64
@@ -2,8 +2,6 @@ libtbbmalloc.so.2 libtbbmalloc2 #MINVER#
  MallocInitializeITT@Base 2017~U7
  _Z9parseFileILi100ELi1EEvPKcRAT0__K13parseFileItem@Base 2018~U6
  _Z9parseFileILi100ELi2EEvPKcRAT0__K13parseFileItem@Base 2018~U6
- (optional)_ZN11MallocMutex11scoped_lockD1Ev@Base 2020.3
- (optional)_ZN11MallocMutex11scoped_lockD2Ev@Base 2020.3
  _ZN3rml10pool_msizeEPNS_10MemoryPoolEPv@Base 2019~U4
  _ZN3rml10pool_resetEPNS_10MemoryPoolE@Base 2017~U7
  _ZN3rml11pool_createElPKNS_13MemPoolPolicyE@Base 2017~U7

After that, build fails at dh_shlibdeps step:

   dh_shlibdeps
dpkg-shlibdeps: error: cannot find library libtbbmalloc.so.2 needed by
debian/libtbbmalloc2/usr/lib/${DEB_HOST_MULTIARCH}/libtbbmalloc_proxy.so.2
(ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
dpkg-shlibdeps: error: cannot continue due to the error above
Note: libraries are not searched in other binary packages that do not
have any shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to use -l.
dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/libtbbmalloc2.substvars
debian/libtbbmalloc2/usr/lib/\${DEB_HOST_MULTIARCH}/libtbbmalloc.so.2
debian/libtbbmalloc2/usr/lib/\${DEB_HOST_MULTIARCH}/libtbbmalloc_proxy.so.2
returned exit code 2
dh_shlibdeps: error: Aborting due to earlier error
make: *** [debian/rules:49: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2

onetbb 2021.5.0-7 builds fine with onetbb.diff in sid chroot.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Install fenics from ppa on Ubuntu 20.04

[Andrius Merkys]

Hi,

On 2021-11-26 16:39, Sebastian Dransfeld wrote:
> I only saw the errors, and assumed it wouldn't work. So I "fixed" it without 
> testing fenics, and just wanted to notify:)

Thanks for the report. I have submitted a bug report on the package
dropping these errors:

https://bugs.debian.org/1000950

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1000950: python3-mshr: error processing line 3 of /usr/lib/python3/dist-packages/mshr.pth

[Andrius Merkys]

Package: python3-mshr
Version: 2019.2.0~git20200924.c27eb18+dfsg1-7

Hello,

When installing python3-mshr in clean sid chroot, the following message
is displayed multiple times:

"""
Error processing line 3 of /usr/lib/python3/dist-packages/mshr.pth:

  Traceback (most recent call last):
File "/usr/lib/python3.9/site.py", line 175, in addpackage
  exec(line)
File "", line 1, in 
  FileNotFoundError: [Errno 2] No such file or directory:
'/usr/lib/petsc/include/petscconf.h'

Remainder of file ignored
"""

Despite the message, python3-mshr seems to install successfully.
Nevertheless the message gives an impression of installation failure [1].

[1]
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2021-November/095683.html

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1000633: 1000633: nice to have

[Andrius Merkys]

Control: severity -1 wishlist

Hello,

Actually, simbody does not block macromoleculebuilder v3.5. Nevertheless
it would be nice to have the newest simbody.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1000633: simbody: please package v3.7

[Andrius Merkys]

Source: simbody

Hello,

I saw that salsa contains packaging for simbody v3.7, but it does not
seem to be uploaded. Are there any blockers for that? I need simbody
v3.7 to update macromoleculebuilder.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Install fenics from ppa on Ubuntu 20.04

[Andrius Merkys]

Hi Sebastian,

On 2021-11-23 16:00, Sebastian Dransfeld wrote:
> Installed fenics with «apt get fenics», and it fails because it cannot
> find /usr/lib/petsc/include/petscconf.h. This file is provided by
> libpetsc-real-dev, but it is provided by alternatives. So it isn’t
> available until this package has been completely set up. So the install
> succeeds if this package is installed first. Can it be forced in the
> «fenics» package that this dependency is completely installed first?

Thanks for the report. I attempted reproducing your problem on Debian
sid with fenics package version 1:2019.2.0.5 (Ubuntu 20.04 has
1:2019.1.0.3). Not sure what you have received from PPA, though.

On clean Debian sid chroot the package installed successfully despite
many errors like the following:

  Error processing line 3 of /usr/lib/python3/dist-packages/mshr.pth:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site.py", line 175, in addpackage
exec(line)
  File "", line 1, in 
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/lib/petsc/include/petscconf.h'

  Remainder of file ignored

(this looks bad, and mentions the same file as you had trouble with).

Nevertheless, importing Python modules for fenics [1] worked for me.
What led you to failures? (I am not using fenics myself)

[1]
https://sources.debian.org/src/fenics/1:2019.2.0.5/debian/tests/test-fenics/

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#973513: 973513: confirmed

[Andrius Merkys]

Version: 3.6.0-1
Control: tags -1 + confirmed

Hello,

I can confirm that at least python3-gi and libgtk-3-dev are required to
run gpu-mon. Since libgtk-3-dev brings a lot of other dependencies, it
may need some narrowing down.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#995133: python3-gpumodules: Error parsing amdfeaturemask

[Andrius Merkys]

Control: fixed 995133 3.6.0
Control: tags 995133 + fixed-upstream pending

Hi,

On 2021-09-27 00:04, Gregor Riepl wrote:
> gpu-pac currently fails on my system because of a hex string parsing issue in
> python3-gpumodules:
> 
> Traceback (most recent call last):
>   File "/usr/bin/gpu-pac", line 1323, in 
> main()
>   File "/usr/bin/gpu-pac", line 1274, in main
> gpu_list.set_gpu_list()
>   File "/usr/lib/python3/dist-packages/GPUmodules/GPUmodule.py", line 1666, in
> set_gpu_list
> self.amd_featuremask = env.GUT_CONST.read_amdfeaturemask()
>   File "/usr/lib/python3/dist-packages/GPUmodules/env.py", line 205, in
> read_amdfeaturemask
> self.amdfeaturemask = int(fm_file.readline())
> ValueError: invalid literal for int() with base 10: '0xbfff\n'
> 
> This issue is fixed in gpu-utils 3.6.0. Please push an upgrade.

I have pushed 3.6.0 some time ago, it is in NEW queue now.

Thanks,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#984346: 984346: fixed in new upstream release

[Andrius Merkys]

control: fixed 984346 1.0.4-1
control: tags 984346 + fixed-upstream

Hello,

I tried to reproduce the bug with new upstream release, 1.0.4, and it
seems that it is gone now.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#989954: cif-api FTCBFS: uses the build architecture pkg-config

[Andrius Merkys]

Hi Helmut,

On 2021-06-16 17:49, Helmut Grohne wrote:
> cif-api fails to cross build from source, because the upstream configure
> script uses the build architecture pkg-config. The simple solution is to
> replace the relevant AC_PATH_PROG with AC_PATH_TOOL. A better solution
> would likely be using PKG_CHECK_MODULES. Please consider applying the
> attached patch for the simple solution.

Thanks a lot for the fix. As this is not release-critical, I will apply
the patch after the bullseye freeze is over.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#989399: nauty FTCBFS -- multiple reasons

[Andrius Merkys]

Hi Nilesh,

On 2021-06-03 13:05, Nilesh Patra wrote:
> On Thu, 3 Jun 2021 at 13:10, Andrius Merkys  <mailto:mer...@debian.org>> wrote:
> On 2021-06-02 19:29, Nilesh Patra wrote:
> > Nauty fails to cross build due to two reasons:
> >
> > 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross
> build
> >    Simply replacing it by AC_LINK_IFELSE does the trick. Please
> find the
> >    patch for this below, and consider applying
> 
> I have no experience with this, alas.
> 
> This patch that I suggested is actually wrong, as you might see in
> Helmut's message.
> But more importantly, we ended up discovering that this is a *Release
> critical*  bug instead.
> Please consider fixing it ASAP if you have some free cycles.

I am aware of Helmut's response and the severity of the problem.
However, I have no experience with fixing i386 baseline violation. I may
give a look, but I am not sure anything will come out of that.

> Indeed, help2man should not call the compiled executables. Nevertheless
> it may still be used to produce manpages from static text, see [2] for
> example.
> 
> This looks nice, there is also ronn and node-marked-man which can do
> similar stuff via README.

I was not aware of ronn and node-marked-man - thanks, I will give them a
look.

> But doing so isn't always possible because several times we have
> multiple binaries and we need separate manual page for each binary.
> In such a case, we need to maintain a maintainer manpage

True indeed.

> [2]
> 
> https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11
> 
> <https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11>

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#989399: nauty FTCBFS -- multiple reasons

[Andrius Merkys]

Hi Nilesh,

On 2021-06-02 19:29, Nilesh Patra wrote:
> Nauty fails to cross build due to two reasons:
> 
> 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
>Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
>patch for this below, and consider applying

I have no experience with this, alas.

> 2. It uses help2man during build, and the same has also been
>autotoolised - this isn't allowed during build. It looks like there's 
> particularly
>no good way to fix it, and probably compiling twice once for build
>arch, and once for host is un-needed extra work.
>I'd suggest removing the help2man invocations from autotools, not
>generate this during build, but simply maintain maintainer manpage,
>using for example createmanpages script[1]
>Talking to upstream and asking them to vendor their own manpages from
>next release can also be a nice option.
> 
>If it is too much hassle for you, I'm willing to do so myself and
>even maintain the package
> 
> [1]: 
> https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

Indeed, help2man should not call the compiled executables. Nevertheless
it may still be used to produce manpages from static text, see [2] for
example. createmanpages is a viable option too.

[2]
https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#987580: libnauty2-dev: suggest include gentreeg.c source (like geng.c)

[Andrius Merkys]

Control: tags -1 + confirmed
Control: owner -1 !

On 2021-04-26 04:24, Kevin Ryde wrote:
> It'd be good if the libnauty2-dev included the gentreeg.c source in
> /usr/share/nauty, together with geng.c.  gentreeg.c has a GENTREEG_MAIN
> option so can be compiled to make trees within a user program.
> 
> (I'd proposed the three geng.c, gentourng.c, gentreeg.c sources in my
> bug 860782.  I didn't notice sooner the latter omitted as I had my own
> symlink for interim use :)

This could indeed be done. As we are in freeze right now, I will add
gentreeg.c as soon as the freeze is over.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#986785: binoculars gui does not work

[Andrius Merkys]

Hi,

On 2021-04-12 10:42, Picca Frédéric-Emmanuel wrote:
> $ binoculars-gui 
> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> /usr/bin/binoculars-gui:1276: DeprecationWarning: In future, it will be an 
> error for 'np.bool_' scalars to be interpreted as an index
>   box.setChecked(state)
> /usr/lib/python3/dist-packages/binoculars/util.py:536: 
> H5pyDeprecationWarning: dataset.value has been deprecated. Use dataset[()] 
> instead.
>   setattr(configobj, section, dict((key, config[section][key].value) for key 
> in config[section]))
> /usr/lib/python3/dist-packages/binoculars/util.py:475: 
> H5pyDeprecationWarning: dataset.value has been deprecated. Use dataset[()] 
> instead.
>   setattr(meta, section, dict((key, group[key].value) for key in group))
> /usr/bin/binoculars-gui:834: MatplotlibDeprecationWarning: Adding an axes 
> using the same arguments as a previous axes currently reuses the earlier 
> instance.  In a future version, a new instance will always be created and 
> returned.  Meanwhile, this warning can be suppressed, and the future behavior 
> ensured, by passing a unique label to each axes instance.
>   self.ax = self.figure.add_subplot(plotrows, plotcolumns, i+1)
> Traceback (most recent call last):
>   File "/usr/bin/binoculars-gui", line 725, in update_key
> self.plot()
>   File "/usr/bin/binoculars-gui", line 843, in plot
> im = binoculars.plot.plot(space, self.figure, self.ax, log=log, 
> loglog=loglog, label=basename, norm=norm[i])
>   File "/usr/lib/python3/dist-packages/binoculars/plot.py", line 157, in plot
> fig._draggablecbar = DraggableColorbar(cbarwidget, im)  # we need to 
> store this instance somewhere
>   File "/usr/lib/python3/dist-packages/binoculars/plot.py", line 16, in 
> __init__
> self.index = self.cycle.index(cbar.get_cmap().name)
> AttributeError: 'Colorbar' object has no attribute 'get_cmap'
> Aborted

This seems to be caused by matplotlib API change. From [1]:

colorbar.ColorbarBase.get_cmap (use ScalarMappable.get_cmap instead)

However, apart from that, I have no clue how to adapt to this change.

[1]
https://github.com/matplotlib/matplotlib/blob/a8831d57207db5e9bf681e30810ce0ea146f4a31/doc/api/prev_api_changes/api_changes_3.3.0/removals.rst

Hope this helps,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

Hi Andreas,

On 2021-03-25 09:39, Andreas Beckmann wrote:
> On 24/03/2021 22.59, Andrius Merkys wrote:
>> However, I am not sure how to proceed next. In principle I could tinker
>> with maintscripts, but I am not sure how to instruct piuparts to pick my
>> .deb instead of what is already present in bullseye.
> 
> There is '--distupgrade-to-testdebs-from /path/to/Packages-and-.debs'

I managed to figure out a working set of command line options myself,
but thanks :)

> I see you applied the fix I suggested ;-) Sorry, didn't find time yet to
> look at this and try something.

No problem - I got an opportunity to learn something new.

> dpkg stating that both relative and absolute values work as $old_target
> is correct in most cases. Simplified, the check is
> 
> if [ $(readlink $pathname) = $old_target ] || [ $(readlink -f $pathname)
> = $old_target ]; then ... fi
> which did not work in your case because readlink returned the absolute
> path in both cases, but $old_target was relative and thus never matched.
> (But I vaguely remember a case where the relative link gave better
> results as well, so absolute is not the perfect solution.)

This sounds complicated. It would be nice to have the logic documented
somewhere, for example dpkg-maintscript-helper(1), also explaining the
use case for relative link.

> BTW: every time you add more information to a bug it will reset the
> AUTORM timer.

I came to this conclusion purely from a bunch of observations, but thank
you for confirming this!

Many thanks,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

On 2021-03-17 00:51, Andreas Beckmann wrote:
> The following should catch both cases:
> 
> symlink_to_dir /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~

I have applied the fix suggested by Andreas, and managed to get piuparts
checks passing locally. Uploaded the fixed package.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

Hello,

On 2021-03-24 15:58, Torrance, Douglas wrote:
> Has there been any progress on this bug?  I'm not sure how to reproduce
> it, but I'd be happy to help in any way that I can.  nauty and its
> reverse dependencies have been marked for auto-removal on Apr. 29
> because of it.

I managed to reproduce the bug by running piuparts locally:

$ sudo piuparts --scriptsdir /etc/piuparts/scripts-multi-distro-upgrade
-d jessie -d stretch -d buster -d bullseye --apt libnauty-dev=None
--no-eatmydata --mirror http://ftp.de.debian.org/debian --keyring
keyring-with-jessie-key.gpg

However, I am not sure how to proceed next. In principle I could tinker
with maintscripts, but I am not sure how to instruct piuparts to pick my
.deb instead of what is already present in bullseye.

I will come back to this later.

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

On 2021-03-17 00:51, Andreas Beckmann wrote:
> On 16/03/2021 16.05, Andrius Merkys wrote:
>> symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-1~
> 
> That looks correct.

Thanks for confirming.

>>  From this I gather that upgrades of nauty <= 2.7r1+ds-1 to this new
>> version should trigger the replacement of a symlink with real directory
>> before placing the files inside. Or am I wrong?
> 
> In buster we have
>   /usr/share/doc/nauty -> libnauty2
> but in jessie we had
>   /usr/share/doc/nauty -> /usr/share/doc/libnauty2
> 
> and that is not caught by the maintscript entry.

OK, I see, so the problem is due to jessie -> buster upgrade.

> The following should catch both cases:
> 
> symlink_to_dir /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~

dpkg-maintscript-helper(1) says:

dpkg-maintscript-helper symlink_to_dir \
pathname old-target prior-version package -- "$@"

pathname is the absolute name of the old symlink (the path will be a
directory at the end of the installation) and old-target is the target
name of the former symlink at pathname. It can either be absolute or
relative to the directory containing pathname.

>From this I gather that absolute and relative paths are equivalent, but
I may read it wrong. Maybe both have to be added?:

symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-2~symlink_to_dir
/usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~

> I'll try to test that ...

Many thanks!

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

Hello,

On 2021-03-16 12:39, Andreas Beckmann wrote:
> 1m40.0s ERROR: FAIL: silently overwrites files via directory symlinks:
>   /usr/share/doc/nauty/changelog.Debian.gz (nauty) != 
> /usr/share/doc/libnauty2/changelog.Debian.gz (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>   /usr/share/doc/nauty/changelog.gz (nauty) != 
> /usr/share/doc/libnauty2/changelog.gz (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>   /usr/share/doc/nauty/changes24-27.txt.gz (nauty) != 
> /usr/share/doc/libnauty2/changes24-27.txt.gz (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2
>   /usr/share/doc/nauty/copyright (nauty) != 
> /usr/share/doc/libnauty2/copyright (libnauty2:amd64)
> /usr/share/doc/nauty -> /usr/share/doc/libnauty2

I am trying to debug the issue, however, unsuccessfully. From the
attached log I gather that the break happens upon upgrading from buster
(2.6r10+ds-1) to bullseye (2.7r1+ds-1):

1m38.6s DUMP:
  PIUPARTS_DISTRIBUTION_PREV=buster
  PIUPARTS_DISTRIBUTION=bullseye

Affected binary packages are nauty and libnauty. The former has recently
(in 2.7r1+ds-1) switched from shipping a directory symlink to a real
directory, and this is accommodated in debian/nauty.maintscript:

symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-1~

>From this I gather that upgrades of nauty <= 2.7r1+ds-1 to this new
version should trigger the replacement of a symlink with real directory
before placing the files inside. Or am I wrong?

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Andrius Merkys]

Hi Sébastien,

On 2020-12-28 15:14, Sébastien Hinderer wrote:
> Actually,
> 
> xlsx2csv foo.xlsx
> 
> does write the CSV output on stdout.

Glad the upstream answered your question.

> I think this bug report can now be closed.

How about reading from stdin? Can you confirm that /dev/stdin does the
trick? If so, this bug report could indeed be closed.

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#978503: etsf-io: uscan fails due to gone download page

[Andrius Merkys]

Source: etsf-io
Version: 1.0.4-5
Severity: normal

Old download page of etsf-io is now gone [1], as etsf-io seems to have
switched to GitHub [2]. However, the releases are not tagged there, thus
fetching tarballs with meaningful version numbers is impossible for the
time being. I have opened an issue requesting to tag releases [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978414
[2] https://github.com/ElectronicStructureLibrary/libetsf_io
[3] https://github.com/ElectronicStructureLibrary/libetsf_io/issues/1

Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Andrius Merkys]

reopen 977293
forwarded https://github.com/dilshod/xlsx2csv/issues/213
thanks

Dear Sébastien,

On 2020-12-27 18:16, Sébastien Hinderer wrote:
> Andrius Merkys (2020/12/14 08:16 +0200):
>> Have you tried using /dev/stdin and /dev/stdout on the command line?
>> This usually does the trick for commands not accepting '-'.
> I tried finally and it does not work. It produces the following error:
>
> Traceback (most recent call last):
>   File "/usr/bin/xlsx2csv", line 1129, in 
> xlsx2csv.convert(outfile, sheetid)
>   File "/usr/bin/xlsx2csv", line 216, in convert
> self._convert(sheetid, outfile)
>   File "/usr/bin/xlsx2csv", line 266, in _convert
> outfile = open(outfile, 'w+', encoding=self.options['outputencoding'], 
> newline="")
> io.UnsupportedOperation: File or stream is not seekable.

It seems that xlsx2csv requires seekable files/streams. Then /dev/stdout
cannot be used, alas. Talking to upstream is the right course of action.

> Bug reported upstream at https://github.com/dilshod/xlsx2csv/issues/213
>
> I did try to add the Forwarded: pseudo-header, I hope it worked.

Thanks for reporting this upstream! Forwarded: pseudo-header works only
for new bug reports, for existing ones you have to use the control
server [1]. I have reopened the bug and added forward address on the top
three lines of this e-mail.

[1] https://www.debian.org/Bugs/server-control

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#977293: Read .xlsx from stdin, write .csv to stdout

[Andrius Merkys]

Hello,

On 2020-12-13 19:00, Sebastien Hinderer wrote:
> Dear upstream authors,

Debian is not the upstream of this package. Bug reports filed in Debian
BTS are not automatically forwarded to upstream either. To contact the
upstream, I suggest opening an issue on their GitHub issue tracker [1].

> Would it please be possible to extend is so that "-" ban be specified
> both as the name of the input file (meaning to read the .xlsx file
> from standard input) and as the name of the output file, meaning that
> the CSV file is written to stdout?
> 
> That way the program could be used in a pipe, which would be very
> convenient. Of course that requires to make sure that all the
> other messages the program could possibly produce are written to stderr.

Have you tried using /dev/stdin and /dev/stdout on the command line?
This usually does the trick for commands not accepting '-'.

[1] https://github.com/dilshod/xlsx2csv/issues

Best,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#957665: Fortran issue in paw (Was: paw: ftbfs with GCC-10)

[Andrius Merkys]

Hi Andreas,

On 2020-10-15 15:26, Andreas Tille wrote:
> when trying to build paw with gcc / fortran 10 there are some FORTRAN
> errors:
> 
> 
> ...
> Error: Type mismatch between actual argument at (1) and actual argument at 
> (2) (COMPLEX(4)/INTEGER(4)).
> /<>/src/pawlib/comis/code/cs1200.F:138:24:
> 
>76 | CALL CCOPYA(KOD(IPCP),KOD(IPCP+I),L)
>   |2
> ..
>   138 | CALL CCOPYA(CX,KOD(IPCP-1),KLCMLX)
>   |1

I had the same problem with libccp4. Upstream has recommended turning
off argument mismatch checks via FFLAGS, which I did in debian/rules [1]:

FFLAGS += -fallow-argument-mismatch

Of course this just silences the error, which should probably be fixed,
especially if argument mismatch is not intentional.

[1]
https://salsa.debian.org/science-team/libccp4/-/commit/985597f71ee539e7e3242d43a60b271865e7672e

Hope this helps,
Andrius

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: RFS: benchmark_1.5.0-1

[Andrius Merkys]

Hi Michael,

Have you pushed the tags (git push --tags)? 'gbp buildpackage' complains
about non-existant upstream/1.5.0.

Andrius

On 2019-09-20 12:42, Michael Crusoe wrote:
> I've updated benchmark to version 1.5.0-1 to support my pending SeqAn3
> package:
>
> benchmark (1.5.0-1) UNRELEASED; urgency=medium
>
>   * Team upload.
>   * New upstream version
>   * debhelper-compat 12
>   * Standards-Version: 4.4.0
>   * Set upstream metadata fields: Name.
>   * Apply patch from upstream so we can specify the location of Debian's
>     googletest source
>   * cmake files are now in /usr/lib/*/cmake/benchmark
>   * Ship pkgconfig in /usr/lib/*/pkgconfig/
>   * libbenchmark-tools is Multi-Arch: foreign
>
>  -- Michael R. Crusoe  <mailto:michael.cru...@gmail.com>>  Thu, 19 Sep 2019 12:25:32 +0200
>
> so I need a Debian Developer to either
>
> gbp clone g...@salsa.debian.org:science-team/benchmark.git
> cd benchmark
> git diff debian/1.4.1-3 -- debian/
> dch --release
> gbp buildpackage -S -d
> dput -f ../benchmark_1.5.0-1_source.changes
> git tag debian/1.5.0-1
> gbp push
>
> or give me uploading permissions:
>
> dcut dm --uid 724D609337113C710550D7473C26763F6C67E6E2 --allow benchmark
>
> Thanks!
>
> -- 
> Michael R. Crusoe
>
-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#927140: getdp compiled without support for gmsh

[Andrius Merkys]

Hello,

it seems that getdp wants to be linked with private gmsh API, which is not
installed by Debian packages yet [1].

[1] https://packages.debian.org/sid/alpha/libgmsh-dev/filelist

Best,
Andrius

On Mon, 15 Apr 2019, 16:33 boffi,  wrote:

> Package: getdp
> Version: 3.0.4+dfsg1-1
> Severity: important
>
> Dear Maintainer,
>
> I was trying to familiarize with dpget, running the tutorials available
> on https://gitlab.onelab.info/doc/tutorials but when I followed the
> instructions contained, e.g., in the MagneticForces subdirectory
>
>  >  To compute the solution in a terminal:
>  >  First generate the (3D) mesh and then run getdp with the chosen
> resolution
>  >  gmsh magnets.geo -3
>  >  getdp magnets.pro -solve MagSta_a
>
> I had the following response
>
>  >  $ getdp magnets.pro -solve MagSta_a
>  >  Info: Running 'getdp magnets.pro -solve MagSta_a' [GetDP
> 3.0.4-git, 1 node, max. 1 thread]
>  >  Info: Started (Mon Apr 15 15:09:54 2019, Wall = 0.759439s, CPU =
> 0.088765s, Mem = 25.0664Mb)
>  >  Info: Increasing process stack size (8192 kB < 16 MB)
>  >  Info: Loading problem definition 'magnets.pro'
>  >  Info: Loading problem definition 'magnets_common.pro'
>  >  Info: Selected Resolution 'MagSta_a'
>  >  Info: Loading Geometric data 'magnets.msh'
>  >  Error   : You need to compile GetDP with Gmsh support to open
> 'magnets.msh'
>  >  $
>
> If I am correct assuming that in most cases one want to use getdp using
> gmsh as its pre- and post-processor, the problem I'm reporting constitutes
> a real breakage for most users.
>
> Regards, gb
>
> P.S.: maybe getdp should, at least, recommend the gmsh package.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages getdp depends on:
> ii  libarpack2   3.7.0-1
> ii  libatlas3-base [liblapack.so.3]  3.10.3-8
> ii  libc62.28-8
> ii  libgcc1  1:8.3.0-6
> ii  libgfortran5 8.3.0-6
> ii  libgsl23 2.5+dfsg-6
> ii  liblapack3 [liblapack.so.3]  3.8.0-2
> ii  libopenmpi3  3.1.3-10
> ii  libpetsc-real3.103.10.5+dfsg1-1
> ii  libpython2.7 2.7.16-2
> ii  libslepc-real3.103.10.2+dfsg1-1
> ii  libstdc++6   8.3.0-6
>
> getdp recommends no packages.
>
> getdp suggests no packages.
>
> -- no debconf information
>
> --
> debian-science-maintainers mailing list
> debian-science-maintainers@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#913455: spglib breaks cod-tools autopkgtest

[Andrius Merkys]

Control: found -1 spglib/1.11.1-1
Control: owner !

Dear Paul,

thanks for reporting the bug. I confirm I can reproduce it with spglib/1.11.1, 
a bugfixed upstream release which I have just uploaded to Debian. I will look 
into the discrepancies in the autopkgtest ASAP.

Best wishes,
Andrius

On 2018-11-11 09:09, Paul Gevers wrote:
> Source: spglib, cod-tools
> Control: found -1 spglib/1.11.0-1
> Control: found -1 cod-tools/2.2+dfsg-3
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
>
> Dear maintainers,
>
> With a recent upload of spglib the autopkgtest of cod-tools fails in
> testing when that autopkgtest is run with the binary packages of spglib
> from unstable. It passes when run with only packages from testing. In
> tabular form:
>passfail
> spglib from testing1.11.0-1
> cod-tools  from testing2.2+dfsg-3
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is contributing to the delay of the migration
> of spglib to testing [1]. Due to the nature of this issue, I filed this
> bug report against both packages. Can you please investigate the
> situation and reassign the bug to the right package? If needed, please
> change the bug's severity.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=spglib
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cod-tools/1296192/log.gz
>
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_001.inp:
> FAILED:
> 50,53c50,53
> < V1 V 0.5 0.8222 0.25 0.0 Uiso 1.00
> < H2 H 0.5 0.5149 0.25 0.0 Uiso 0.50
> < O9 O 0 0.7111 0.25 0.0 Uiso 1.00
> < O10 O 0 0.9262 0.25 0.0 Uiso 1.00
> ---
>> V1 V 0.5 0.1778 0.25 0.0 Uiso 1.00
>> H2 H 0.5 0.4851 0.25 0.0 Uiso 0.50
>> O9 O 1 0.2889 0.25 0.0 Uiso 1.00
>> O10 O 1 0.0738 0.25 0.0 Uiso 1.00
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_002.inp:
> OK
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_003.inp:
> Test skipped by request - test only compatible with spglib v1.9.9
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_004.inp:
> Test skipped by request - test only compatible with spglib v1.9.9
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_005.inp:
> FAILED:
> 32,33c32,33
> < _cell_angle_alpha89.831346
> < _cell_angle_beta 89.831346
> ---
>> _cell_angle_alpha90.168654
>> _cell_angle_beta 90.168654
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_006.inp:
> OK
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_007.inp:
> Test skipped by request - test only compatible with spglib v1.9.9
> /tmp/autopkgtest-lxc.9ex462xd/downtmp/autopkgtest_tmp/tests/cases/cif_find_symmetry_008.inp:
> FAILED:
> 2c2
> < _cell_length_a   4.01206506674
> ---
>> _cell_length_a   4.01206456672
> 5,7c5,7
> < _cell_angle_alpha90.01
> < _cell_angle_beta 89.95
> < _cell_angle_gamma120.07695
> ---
>> _cell_angle_alpha89.99
>> _cell_angle_beta 89.999996
>> _cell_angle_gamma119.95327
> 24,25c24,25
> < Ac 0. 0.6667 0.6667
> < Ac 0.6667 0. 0.
> ---
>> Ac 0.6667 0. 0.
>> Ac 0. 0.6667 0.6667
>
-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania



signature.asc
Description: OpenPGP digital signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#903689: cod-tools: missing build-depends

[Andrius Merkys]

Control: tags 903666 + pending
Control: tags 903689 + pending

Hi Chris,

On 07/13/2018 11:01 AM, Chris Lamb wrote:
> Actually, I think you are missing a lot more (DBI.pm, etc.). Sorry
> for the additional noise. :)

thanks for the report. I have fixed this and another [1] dependency-related 
bug. I will upload it soon.

Best wishes,
Andrius

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

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#902745: clipper: please make the build reproducible

[Andrius Merkys]

Control: tags -1 + confirmed fixed

On 06/30/2018 11:06 AM, Chris Lamb wrote:

> Whilst working on the Reproducible Builds effort [0], we noticed
> that clipper could not be built reproducibly.
>
> This is because it ships a non-reproducible Makefile that hardcodes
> build paths (so it's not very useful for end-users anyway...)

Hi,

thanks for the patch! I have incorporated it, the fixed package is ready to be 
uploaded (I don't have privileges myself).

Best wishes,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#901997: python-pycodcif has unsatisfiable dependencies

[Andrius Merkys]

Control: tags 901997 + fixed pending

Hi,

On 06/21/2018 11:18 AM, Matthias Klose wrote:
> Package: python-pycodcif
> Version: 2.1+dfsg-1
> Severity: serious
> Tags: sid buster patch
>
> python-pycodcif has unsatisfiable dependencies.
>
> patch at
> http://launchpadlibrarian.net/375388523/cod-tools_2.1+dfsg-1_2.1+dfsg-1ubuntu1.diff.gz
>
this is already fixed and waiting for sponsor to be uploaded.

Many thanks!
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#901060: lammps: generate irreducible q-points with spglib

[Andrius Merkys]

Package: lammps
Severity: wishlist

lammps has an optional feature to generate irreducible q-points set via spglib, 
which is now packaged in Debian. I attach a patch to enable this feature. 
lammps must build-depend on libsymspg-dev in order to use it.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Description: link against libsymspg-dev to provide the functionality to
 produce irreducible q-points with spglib.
Author: Andrius Merkys 
--- a/tools/phonon/Makefile
+++ b/tools/phonon/Makefile
@@ -16,9 +16,9 @@
 # spglib 1.8.2, used to get the irreducible q-points
 # if UFLAG is not set, spglib won't be used.
 
-# UFLAG  = -DUseSPG
-# SPGINC = -I/opt/libs/spglib/1.8.2/include
-# SPGLIB = -L/opt/libs/spglib/1.8.2/lib -lsymspg
+UFLAG  = -DUseSPG
+SPGINC =
+SPGLIB = -lsymspg
 
 # if spglib other than version 1.8.2 is used, please 
 # modify file phonon.cpp, instruction can be found by searching 1.8.2
-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#901047: debian-science: s/spglib/libsymspg-dev/

[Andrius Merkys]

Package: src:debian-science
Version: 1.7

Please replace spglib with libsymspg-dev, since this is the libdevel package 
from spglib source.

Thanks,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: spglib_1.10.3-1_amd64.changes REJECTED

[Andrius Merkys]

Hi Thorsten,

thanks for the review. I have fixed the debian/copyright and asked the package 
to be uploaded once more.

Best,
Andrius


On 05/15/2018 05:10 PM, Thorsten Alteholz wrote:
> Hi Andrius,
>
> according to the file header some files are licensed under GPL. 
> Please mention them in your debian/copyright.
>
> Thanks!
>  Thorsten
>
>
>
> ===
>
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
>

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania


-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers