Bug#1072576: coot: save its states in HOME.

[Andrius Merkys]

On 2024-06-05 10:13, Andrius Merkys wrote:
The REFMAC dictionary packaged in Debian as refmac-dictionary needs some 
adjustment to make usable by coot and make the messages above go away.


I have the fix for refmac-dictionary at hand, by the way. I will upload 
it soon.


Andrius

Bug#1072576: coot: save its states in HOME.

[Andrius Merkys]

Control: tags -1 + confirmed

Hi,

On 2024-06-04 17:31, Picca Frédéric-Emmanuel wrote:

While using coot I found that it save it's states in these files

DEBUG:: saving state to filename 0-coot.state.py
State file 0-coot.state.py written.
State file 0-coot-history.py written.
State file 0-coot-history.scm written.


I can confirm this happens.


Maybe this is just something linked to a DEBUG mode  It would be
great if this state could be saved in the xdg cache directory, or
maybe create a Release coot without all the Debuging.


I agree these files should better be placed in XDG cache or some other 
XDG-based directory. I have to make sure if these debug files are 
present only in Debian-provided coot, or are they supposed to appear 
always. I am not sure if it is a good idea to patch the debugging out 
unless it is intended, as turning it on would require rebuilding coot. 
Maybe the debug mode should be controlled by a command line option (off 
by default), but I would better have the upstream to implement it.



I do not know what is the best solution...

The coot command line is quite verbose...


I am wondering if these warnings are important ?


Most of them are probably not.


:~$ coot
INFO:: built with GTK 4.12.5
pdd /usr/share/coot
WARNING:: Coot REFMAC dictionary override COOT_REFMAC_LIB_DIR 
/usr/share/coot/lib failed to find the monomer library
WARNING:: COOT_PREFIX set, but no dictionary lib found
WARNING: Failed to read restraints dictionary.
debug:: in setup_python()pydirectory is /usr/lib/python3.11/site-packages
debug:: in setup_python() pkgpydirectory is 
/usr/lib/python3.11/site-packages/coot
WARNING:: The reference structures directory (COOT_REF_STRUCTS): 
/usr/share/coot/reference-structures was not found.
   Ca->Mainchain will not be possible.
WARNING:: Coot REFMAC dictionary override COOT_REFMAC_LIB_DIR 
/usr/share/coot/lib failed to find the monomer library
WARNING:: COOT_PREFIX set, but no dictionary lib found
WARNING: Failed to read restraints dictionary.


The REFMAC dictionary packaged in Debian as refmac-dictionary needs some 
adjustment to make usable by coot and make the messages above go away.


The remaining output seems to be purely informational. I stripped that 
off from this email.


Thanks,
Andrius

Bug#1072618: coot: layla fails to start unless LD_LIBRARY_PATH is specified

[Andrius Merkys]

Package: coot
Version: 1.1.08+dfsg-3
Severity: important
Forwarded: https://github.com/pemsley/coot/issues/120

layla executable fails to start unless LD_LIBRARY_PATH is given for it 
to locate the coot private libraries, e.g.:


$ LD_LIBRARY_PATH=/usr/lib/ layla

A thin wrapper is needed to set this up for layla.

Andrius

Bug#1072564: nmu: cctbx_2023.12+ds2+~3.17.0+ds1-4 clipper_ 2.1.20201109-2 libpdb-redo_3.0.5-2 ssm_1.4.0-2

[Andrius Merkys]

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

Hello,

I want to request binNMU on packages which are affected by libccp4 
soname change due to time_t64 transition:


  nmu cctbx_2023.12+ds2+~3.17.0+ds1-4 . ANY . unstable . -m "Rebuild 
with libccp4-dev >= 8.0.0-3"
  nmu clipper_ 2.1.20201109-2 . ANY . unstable . -m "Rebuild with 
libccp4-dev >= 8.0.0-3"
  nmu libpdb-redo_3.0.5-2 . ANY . unstable . -m "Rebuild with 
libccp4-dev >= 8.0.0-3"
  nmu ssm_1.4.0-2 . ANY . unstable . -m "Rebuild with libccp4-dev >= 
8.0.0-3"


Thanks,
Andrius

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Andrius Merkys]

Hi Christian,

On 2024-06-03 11:38, Christian Böck wrote:

when using headphones with my laptop (Thinkpad W550s) I get a repeating
cracking (~1sec intervalls) when nothing is playing.


I have a similar issue on a workstation with Ubuntu 22.04. What is your 
operating system version? I believe the issue started manifesting once I 
installed Jack. Do you have Jack on your machine?


Andrius

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

[Andrius Merkys]

On 2024-06-02 19:49, Louis-Philippe Véronneau wrote:> Sounds like a 
plan. I made the changed you proposed and also made sure
the tag will output the problematic BUILD_OPTION. That way, when/if 
someone wants to make it more generic, it'll be possible to pass other 
invalid BUILD_OPTION.


The tag outputted currently looks like:

foobar (source): debian-rules-invalid-build-option nodocs [debian/rules:2]


Great, thanks a lot. I reviewed the code and I think it is good to be 
merged as is. Tag name is appropriate and future-proof for other checks 
for DEB_BUILD_OPTIONS.


Thanks,
Andrius

Bug#1072383: lintian: flag packages bloated by auxiliary tests/docs/examples

[Andrius Merkys]

Hi Aaron,

On 2024-06-02 05:41, Aaron M. Ucko wrote:

A number of binary packages accompany their primary content by tests,
examples, and/or other documentation that appreciably increase their
size, in some cases by more than an order of magnitude, and as such
would be very reasonable to split out.  Could Lintian please flag such
packages so as to encourage such splitting?  I know Perl and would be
happy to draft a patch if that would be helpful.


I would really welcome such check in lintian. I am often bitten by such 
situations when trying to minimize the size of my VMs/containers. I 
think lintian hint encouraging maintainers to split off large auxiliary 
content would be nice and would happily review your patch.


Best,
Andrius

Bug#998820: lintian: overly generic python modules /usr/lib/python3/dist-packages/benchmarks/*.py

[Andrius Merkys]

On 2024-06-03 08:51, Andreas Beckmann wrote:

Followup-For: Bug #998820

Then we also have

/usr/lib/python3/dist-packages/build/lib/doc/conf.py
  ^^^
e.g. nxtomo 1.2.3-2

usr/lib/python3/dist-packages/build/lib/docs/conf.py
 
e.g. pipenv 2023.12.1+ds-1


Just thinking out loud: would it make sense to warn about all the files 
that are installed under /usr/lib/python3/dist-packages/, but outside 
the package directory? E.g. all files from python3-nxtomo in 
/usr/lib/python3/dist-packages/, but outside 
/usr/lib/python3/dist-packages/nxtomo/. I guess such approach may 
produce false-positives for plugin packages.


Another solution would be to simply warn about specific paths, such as:

/usr/lib/python3/dist-packages/build/*
/usr/lib/python3/dist-packages/docs/*
/usr/lib/python3/dist-packages/__init__.py
...

Does it make sense to name lintian tag 
'python-package-installs-overly-generic-path'?


Best,
Andrius

Bug#1072195: valgrind: add support for loong64

[Andrius Merkys]

Package: valgrind
Version: 1:3.20.0-2.1
Severity: wishlist
Control: block 1072148 by -1
X-Debbugs-CC: wuruil...@loongson.cn

Hello,

In #1072148 a patch to support loong64 has been proposed in epics-base. 
The proposed patch modifies valgrind header (valgrind/valgrind.h) 
embedded in epics-base source. I would like to un-embed this header in 
the upcoming upload. Therefore to be able to add support for loong64 in 
epics-base, valgrind should support it first.


Andrius

Bug#1072148: epics-base: please add support for loong64

[Andrius Merkys]

On 2024-05-30 05:17, wuruilong wrote:

I checked valgrind debian package is not supported loongarch architecture.


Thanks for checking. I would like to remove the embedded 
valgrind/valgrind.h and use the header from valgrind package. Thus I 
would suggest implementing loongarch support in valgrind before epics-base.


Andrius

Bug#1072148: epics-base: please add support for loong64

[Andrius Merkys]

On 2024-05-29 11:32, wuruilong wrote:
Modify the valgrind header file because valgrind's code has gone too 
long without loongarch support.


Does the valgrind Debian package support loong64? If so, the embedded 
valgrind/valgrind.h can be replaced with the header from Debian package.


Andrius

Bug#1072148: epics-base: please add support for loong64

[Andrius Merkys]

Control: forwarded -1 https://github.com/epics-base/epics-base/pull/329

Hi,

On 2024-05-29 10:31, wuruilong wrote:

Compile error on loongarch, reference upstream code to provide patch.
Link to upstream code:https://github.com/epics-base/epics-base/pull/329


Why does this patch modify the embedded valgrind source?

Thanks,
Andrius

Bug#1039087: removing embeded version of yajl

[Andrius Merkys]

Hi,

On 2024-05-28 18:35, PICCA Frederic-Emmanuel wrote:

Here the diff between the epics version (debian patch unapplyed) and the 
current 2.1.0 version of yajl (debian patch unapplyed).


It seems EPICS authors have forked yajl and implemented JSON5 support 
there. As a result, the code diverged quite much. I see no easy way to 
resolve this now, alas.


Andrius

Bug#1072115: ERROR:: Failure to read or parse /usr/share/coot/ui/coot-gtk4.ui

[Andrius Merkys]

Control: severity -1 serious
Control: owner -1 !

Hi,

On 2024-05-28 23:07, Picca Frédéric-Emmanuel wrote:

while trying to start coot, I get this error message.

$ coot
INFO:: built with GTK 4.12.5
pdd /usr/share/coot
WARNING:: Coot REFMAC dictionary override COOT_REFMAC_LIB_DIR 
/usr/share/coot/lib failed to find the monomer library
WARNING:: COOT_PREFIX set, but no dictionary lib found
WARNING: Failed to read restraints dictionary.
ERROR:: Failure to read or parse /usr/share/coot/ui/coot-gtk4.ui
No function named `on_active_map_ok_button_clicked`.


Thanks for spotting this. Interestingly, I had to problem with version 
1.1.07.705.gb7e2c16a2+dfsg-1, thus this is be a regression. I will 
investigate.



It would be great if you could add an autopkgtest with timetout in order to 
check if the coot GUI could start


Good idea - thanks for proposing a suggestion for such autopkgtest.

Best,
Andrius

Bug#1039087: removing embeded version of yajl

[Andrius Merkys]

Hi,

On 2024-05-28 17:49, PICCA Frederic-Emmanuel wrote:

following a different path...,

I added this in the rules file

-export POSIX_CFLAGS+=$(CFLAGS)
+export POSIX_CFLAGS+=$(CFLAGS) $(shell pkgconf --cflags yajl)
export POSIX_CFLAGS+=$(CPPFLAGS)
export POSIX_CPPFLAGS+=$(CPPFLAGS)
-export POSIX_LDFLAGS+=$(LDFLAGS)
+export POSIX_LDFLAGS+=$(LDFLAGS) $(shell pkgconf --libs yajl)


This is much better than my previous method, thanks!


but it ends up like this

/usr/bin/gcc  -D_GNU_SOURCE -D_DEFAULT_SOURCE  -D_X86_64_ -DUNIX  -Dlinux -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-I/usr/include/yajl  -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -I/usr/include/yajl  -Wdate-time -D_FORTIFY_SOURCE=2 
-O3 -g   -Wall -Werror-implicit-function-declaration  -mtune=generic -m64  -I. -I../O.Common 
-I. -I. -I.. -I../../../../include/compiler/gcc -I../../../../include/os/Linux -I../../../../include
 -c ../yajl_test.c
../yajl_test.c: In function ‘main’:
../yajl_test.c:209:23: error: ‘yajl_allow_json5’ undeclared (first use in this 
function)
   209 | yajl_config(hand, yajl_allow_json5, 0);
   |   ^~~~
../yajl_test.c:209:23: note: each undeclared identifier is reported only once 
for each function it appears in

the embeded version seems to provide at least this extra symbols.


It is worth checking whether these extra symbols are added locally, or 
is this unmodified upstream source of yajl, but just a different version.



what about integrating this symbol in the yajl library ?


This is a solution, yes. But I would like to explore other options first.

Thanks a lot,
Andrius

Bug#1069873: rdkit: FTBFS convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).

[Andrius Merkys]

Control: severity -1 important

On Fri, 26 Apr 2024 09:25:06 +0300 Andrius Merkys  wrote:
Since I need to upload rdkit to experimental to deal with time_t64 
transition, I am going to disable latexpdf documentation building for 
the time being and deal with this issue later.


I have disabled latexpdf documentation building in 202309.3-4~exp1. 
Therefore rdkit no longer FTBFS. Leaving this issue open as a reminder 
to investigate the bug and re-enable latexpdf documentation.


Andrius

Bug#1071573: Status of libnet-ssl-expiredate-perl

[Andrius Merkys]

Hi Mason,

On 2024-05-27 13:11, Mason James wrote:

sorry for my late reply and no objections from me!


Now worries, I finished the package and uploaded today.

Best,
Andrius

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

[Andrius Merkys]

Hi,

On Sat, 4 May 2024 22:53:36 +0900 Kentaro HAYASHI  wrote:

I've attached PoC patches which are
based on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059706#33

Before:

  $ pkg-config --cflags epics-base
-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 


After:

  $ pkg-config --cflags epics-base
-I/usr/include/epics -I/usr/include/epics/os/Linux
-I/usr/include/epics/compiler/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE
-D_X86_64_ -DUNIX -Dlinux
-ffile-prefix-map=/debian/epics-base-7.0.8+dfsg1=. -D_FORTIFY_SOURCE=2
-ffile-prefix-map=/debian/epics-base-7.0.8+dfsg1=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection
-D_FORTIFY_SOURCE=2 -mtune=generic -m64 


I hope it will help.


This looks good indeed. I will give your patch another look and apply 
it. While you are at the epics-base.pc, can you check why all buildflags 
get stored in it?


Best,
Andrius

Bug#1071573: Status of libnet-ssl-expiredate-perl

[Andrius Merkys]

Control: owner -1 !

Hello,

It is quite important to me to get libnet-ssl-expiredate-perl done ASAP. 
Thus if you do not have any objections, I am going to finalize it.


Andrius

Bug#1071655: pytorch: FTBFS on ppc64el

[Andrius Merkys]

Source: pytorch
Version: 2.1.2+dfsg-4
Severity: serious
Tags: ftbfs

Hello,

pytorch FTBFS on ppc64el:

FAILED: 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o
/usr/bin/c++ -DAT_PER_OPERATOR_HEADERS -DCAFFE2_BUILD_MAIN_LIB 
-DFMT_HEADER_ONLY=1 -DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 
-DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 
-DONNX_ML=1 -DONNX_NAMESPACE=onnx -DTORCH_ENABLE_LLVM -DUSE_C10D_GLOO 
-DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC -DUSE_RPC -DUSE_TENSORPIPE 
-D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS 
-I/home/merkys/pytorch-2.1.2+dfsg/build/aten/src 
-I/home/merkys/pytorch-2.1.2+dfsg/aten/src 
-I/home/merkys/pytorch-2.1.2+dfsg/build 
-I/home/merkys/pytorch-2.1.2+dfsg 
-I/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/benchmark/include 
-I/usr/lib/llvm-16/include -I/home/merkys/pytorch-2.1.2+dfsg/debian/foxi 
-I/home/merkys/pytorch-2.1.2+dfsg/build/debian/foxi 
-I/home/merkys/pytorch-2.1.2+dfsg/torch/csrc/api 
-I/home/merkys/pytorch-2.1.2+dfsg/torch/csrc/api/include 
-I/home/merkys/pytorch-2.1.2+dfsg/caffe2/aten/src/TH 
-I/home/merkys/pytorch-2.1.2+dfsg/build/caffe2/aten/src/TH 
-I/home/merkys/pytorch-2.1.2+dfsg/build/caffe2/aten/src 
-I/home/merkys/pytorch-2.1.2+dfsg/build/caffe2/../aten/src 
-I/home/merkys/pytorch-2.1.2+dfsg/torch/csrc 
-I/home/merkys/pytorch-2.1.2+dfsg/third_party/miniz-2.1.0 
-I/home/merkys/pytorch-2.1.2+dfsg/debian/kineto/libkineto/include 
-I/home/merkys/pytorch-2.1.2+dfsg/debian/kineto/libkineto/src 
-I/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/.. 
-I/home/merkys/pytorch-2.1.2+dfsg/c10/.. 
-I/home/merkys/pytorch-2.1.2+dfsg/third_party/flatbuffers/include 
-isystem /home/merkys/pytorch-2.1.2+dfsg/build/third_party/gloo -isystem 
/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/gloo -isystem 
/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/googletest/googlemock/include 
-isystem 
/home/merkys/pytorch-2.1.2+dfsg/cmake/../third_party/googletest/googletest/include 
-isystem /usr/include/opencv4 -isystem /usr/include/eigen3 -isystem 
/home/merkys/pytorch-2.1.2+dfsg/caffe2 -Wdate-time -D_FORTIFY_SOURCE=2 
-g -O2 -ffile-prefix-map=/home/merkys/pytorch-2.1.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -gsplit-dwarf 
-Wno-dangling-reference  -I/usr -D_GLIBCXX_USE_CXX11_ABI=1 
-fvisibility-inlines-hidden -DUSE_KINETO -DLIBKINETO_NOCUPTI 
-DLIBKINETO_NOROCTRACER -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC 
-Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor 
-Werror=range-loop-construct -Werror=bool-operation -Wnarrowing 
-Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds 
-Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function 
-Wno-unused-result -Wno-strict-overflow -Wno-strict-aliasing 
-Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic 
-Wno-error=old-style-cast -Wno-invalid-partial-specialization 
-Wno-unused-private-field -Wno-aligned-allocation-unavailable 
-Wno-missing-braces -fdiagnostics-color=always -faligned-new 
-Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno 
-fno-trapping-math -Werror=format -Werror=cast-function-type 
-Wno-stringop-overflow -O2 -g -DNDEBUG -std=gnu++17 -fPIC 
-DCAFFE2_USE_GLOO -DTH_HAVE_THREAD -Wall -Wextra -Wno-unused-parameter 
-Wno-unused-function -Wno-unused-result -Wno-missing-field-initializers 
-Wno-unknown-pragmas -Wno-type-limits -Wno-array-bounds 
-Wno-strict-overflow -Wno-strict-aliasing -Wno-missing-braces 
-Wno-maybe-uninitialized -fvisibility=hidden -O2 -fopenmp -MD -MT 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o -MF 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o.d 
-o caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/Col2Im.cpp.o 
-c /home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/Col2Im.cpp
In file included from 
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vsx/vec256_common_vsx.h:8,
 from 
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vec256.h:19,
 from 
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec.h:6,
 from 
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/cpu/utils.h:4,
 from 
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/im2col.h:7,
 from 
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/native/Col2Im.cpp:6:
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vsx/vec256_double_vsx.h: 
In member function ‘at::vec::CPU_CAPABILITY::Vectorized 
at::vec::CPU_CAPABILITY::Vectorized::acos() const’:
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen/cpu/vec/vec256/vsx/vec256_double_vsx.h:220:14: 
error: ‘Sleef_acosd2_u10’ was not declared in this scope; did you mean 
‘Sleef_acoshf_u10’?

  220 |  return {Sleef_acosd2_u10(_vec0), Sleef_acosd2_u10(_vec1)};
  |  ^~~~
  |  Sleef_acoshf_u10
/home/merkys/pytorch-2.1.2+dfsg/aten/src/ATen

Bug#1071573: ITP: libnet-ssl-expiredate-perl -- obtain expiration date of certificate

[Andrius Merkys]

Package: wnpp
Owner: Mason James 
Severity: wishlist
Control: block 1036769 by -1
X-Debbugs-CC: m...@kohaaloha.com

* Package name: libnet-ssl-expiredate-perl
  Version : 1.24
  Upstream Author : Hirose Masaaki
* URL : https://metacpan.org/release/Net-SSL-ExpireDate
* License : Artistic
  Programming Lang: Perl
  Description : obtain expiration date of certificate

Net::SSL::ExpireDate get certificate from network (SSL) or local
file and obtain its expiration date.

This ITP is to document the fact that Net::SSL::ExpireDate is being 
packaged (by Mason James). I am interested in this package as means to 
implement #1036769 in lintian (certificate expiry check).


Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libnet-ssl-expiredate-perl

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

[Andrius Merkys]

On 2024-05-19 15:48, Julian Gilbey wrote:

But here I'd suggest doing the
opposite: checking for valid build options (and note: this is a check
for DEB_BUILD_OPTIONS, not for DEB_BUILD_PROFILES).  There is a very
short list of standard build options: those listed in
dpkg-buildpackage(1) (parallel=n, nocheck, noopt, nostrip, terse,
hardening=..., reproducible=..., abi=..., future=..., qa=...,
optimize=..., sanitize=...) and
https://wiki.debian.org/BuildProfileSpec: nodoc


+1

Andrius

Bug#1035833: cpptraj: autopkgtest failure everywhere except on amd64

[Andrius Merkys]

Control: severity -1 important
Control: retitle -1 cpptraj: FTBFS on \!amd64

On Wed, 10 May 2023 02:29:08 +0530 Kiran S Kunjumon  
wrote:

You package cpptraj has an autopkgtest, great.
However, it fails everywhere except on amd64. Can you please investigate the 
situation and fix it?


I have extended the build time tests to catch segfaulting executables. 
Therefore all architectures for which autopkgtests failed now FTBFS.


Now binaries of all non-amd64 architectures are excluded. Thus cpptraj 
should be allowed to migrate to testing, at least for amd64.


Andrius

Bug#1071207: ITP: r-cran-calculus -- High Dimensional Numerical and Symbolic Calculus

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: r-cran-calculus
  Version : 1.0.1
  Upstream Author : Emanuele Guidotti 
* URL : https://cran.r-project.org/package=calculus
* License : GPL-3
  Programming Lang: GNU R
  Description : High Dimensional Numerical and Symbolic Calculus

Efficient C++ optimized functions for numerical and symbolic calculus as 
described in Guidotti (2022). It includes basic arithmetic, tensor 
calculus, Einstein summing convention, fast computation of the 
Levi-Civita symbol and generalized Kronecker delta, Taylor series 
expansion, multivariate Hermite polynomials, high-order derivatives, 
ordinary differential equations, differential operators (Gradient, 
Jacobian, Hessian, Divergence, Curl, Laplacian) and numerical 
integration in arbitrary orthogonal coordinate systems: cartesian, 
polar, spherical, cylindrical, parabolic or user defined by custom scale 
factors.


I found this package useful at my $DAYJOB.

Remark: This package is to be maintained with Debian R Packages 
Maintainers at

   https://salsa.debian.org/r-pkg-team/r-cran-calculus

Bug#1071176: ITP: python-htmltools -- Tools for creating, manipulating, and writing HTML

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-htmltools
  Version : 0.5.1
  Upstream Author : Posit Software, PBC
* URL : https://github.com/rstudio/py-htmltools
* License : Expat
  Programming Lang: Python
  Description : Tools for creating, manipulating, and writing HTML 
(Python 3)


Tools for creating, manipulating, and writing HTML from Python.

This package is needed to package py-shiny.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-htmltools

Bug#1071089: RM: cpptraj [arm64 armel armhf i386 mips64el ppc64el riscv64 s390x] -- ROM; FTBFS on non-amd64 archs

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove cpptraj binaries for the following architectures:

arm64 armel armhf i386 mips64el ppc64el riscv64 s390x

It FTBFS on non-amd64 architectures as noticed in #1035833.

Andrius

Bug#1035833: cpptraj: autopkgtest failure everywhere except on amd64

[Andrius Merkys]

On Wed, 10 May 2023 02:29:08 +0530 Kiran S Kunjumon  
wrote:

=== FAILURES
===
TEST: /tmp/autopkgtest-lxc.kz5vbtvg/downtmp/build.qgE/src/test/Test_SPAM

   CPPTRAJ: SPAM Test
../MasterTest.sh: line 495:  3218 Killed  $cpptraj_cmd >> 
$CPPTRAJ_OUTPUT
Error:  cpptraj exited with status 137

   CPPTRAJ: SPAM Pure Solvent Test

   1 out of 2 executions exited with an error.
   2 out of 5 comparisons failed.


Interestingly, the same segmentation faults happen during build, 
although they do not terminate the build process.


Thanks,
Andrius

Bug#1036769: lintian: Check for certificates .pem/.crt/.pkcs12 with expiry set

[Andrius Merkys]

Control: owner -1 !

Hi,

On Thu, 25 May 2023 17:27:48 +0200 Florian Lohoff  wrote:

i am in the middle of a stretch rebuild for mipsel (Upgrade path from
jessie as stretch dropped 75% of supported systems with mips32)

A big issue are certificates, mostly for build tests which have an
expire date set. This causes the package to fail just because we are a
couple years behind schedule.
I am interested in taking this. I have been bitten by expired 
certificates in tests previously, albeit not from standalone files, but 
embedded in test runners. Checking of expiry of standalone certificates 
should be pretty simple, whereas finding embedded certificates might 
require a bit more magic.


I plan to employ a Perl module Net::SSL::ExpireDate to check the expiry 
date. It should be easy to use it in lintian code. Of course, first of 
all, Net::SSL::ExpireDate needs to be packaged (on salsa, no ITP yet).


Andrius

Bug#1070275: RM: macromoleculebuilder [armhf] -- ROM; unsupported on 32bit archs

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove macromoleculebuilder binaries for armhf. The upstream has 
confirmed the package is no longer supported on 32bit architectures.


Andrius

Bug#1068925: 1068925: macromoleculebuilder should be limited to 64bit

[Andrius Merkys]

Control: owner -1 !

Hello,

Upstream has confirmed that macromoleculebuilder should be limited to 
64bit. I am going to limit the architectures and file for RM on armhf soon.


Andrius

Bug#956194: streamlit status

[Andrius Merkys]

Hello,

Is anybody still interested in streamlit? Some time ago I packaged its 
dependency node-xxhashjs and ended up maintaining it. I do not use 
node-xxhashjs myself and would like to pass its maintenance to people 
interested in streamlit.


Andrius

Bug#1064311: rdkit: NMU diff for 64-bit time_t transition

[Andrius Merkys]

Hi,

On Wed, 24 Apr 2024 23:57:17 +0200 Chris Hofstaedtler  
wrote:> An upload with t64 binaries is required as soon as possible. Given

the packages have to go to binary-NEW, you must upload with
binaries, and then probably follow up with a source-only upload once
they are ACCEPTed.


t64 binaries for rdkit got accepted to experimental. Should I upload it 
to unstable, or should I wait for someone else to do that?


Best,
Andrius

Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates

[Andrius Merkys]

Control: severity -1 important
Control: tags -1 - ftbfs

Hi,

On 2024-04-25 19:12, Santiago Vila wrote:

I noticed that chemicaltagger currently FTBFS and I believe it is because
of this problem, so to avoid duplicate reports, I'm raising this one to 
serious.


A build log for chemicaltagger is available here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html


I have just fixed the FTBFS bug in chemicaltagger/1.6.2-4, it was a 
separate issue, unrelated to antlr4-maven-plugin.


Best,
Andrius

Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates

[Andrius Merkys]

Hi,

On 2024-04-25 19:12, Santiago Vila wrote:

I noticed that chemicaltagger currently FTBFS and I believe it is because
of this problem, so to avoid duplicate reports, I'm raising this one to 
serious.


A build log for chemicaltagger is available here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html


I think this FTBFS is caused by change in some other dependency as 
antlr4-maven-plugin did not change since last successful build of 
chemicaltagger.


By raising the severity of this bug, I'm assuming that this will be 
eventually fixed
in antlr4-maven-plugin and chemicaltagger will not need to be changed to 
build again,
but I really have no idea if such thing will happen. If it does not, we 
would need

a different FTBFS bug for chemicaltagger so that it's fixed there.


chemicaltagger could in principle be adapted to detect the version of 
antlr4-maven-plugin and build against that, but I would like to 
understand why antlr4-maven-plugin exports only the strictly versioned 
maven coordinates. This seems quite unusual for Java packages, but as 
said, there might be a reason for this.


Best,
Andrius

Bug#1069873: rdkit: FTBFS convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).

[Andrius Merkys]

Source: rdkit
Version: 202309.3-3
Severity: serious
Tags: ftbfs sid

Hello,

rdkit FTBFS with the following error in latexpdf documentation build:

Extension error:
convert exited with error:
[stderr]
b'convert: Unable to read font 
(/usr/share/fonts/type1/gsfonts/n019003l.pfb).\n'

[stdout]
b''
make[2]: *** [Makefile:118: latexpdf] Error 2
make[2]: Leaving directory 
'/builds/debichem-team/rdkit/debian/output/source_dir/Docs/Book'

make[1]: *** [debian/rules:95: override_dh_auto_build] Error 2
make[1]: Leaving directory 
'/builds/debichem-team/rdkit/debian/output/source_dir'

make: *** [debian/rules:40: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


Since I need to upload rdkit to experimental to deal with time_t64 
transition, I am going to disable latexpdf documentation building for 
the time being and deal with this issue later.


Andrius

Bug#1064311: rdkit: NMU diff for 64-bit time_t transition

[Andrius Merkys]

Hi Chris,

On 2024-04-25 00:57, Chris Hofstaedtler wrote:

t64 is already in unstable and making its way to testing. So you are
a bit late with getting rdkit fixed for t64.

An upload with t64 binaries is required as soon as possible. Given
the packages have to go to binary-NEW, you must upload with
binaries, and then probably follow up with a source-only upload once
they are ACCEPTed.


Thanks for the information. I will upload rdkit ASAP.

Best,
Andrius

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

Bug#1064311: rdkit: NMU diff for 64-bit time_t transition

[Andrius Merkys]

Hi,

On Mon, 19 Feb 2024 21:35:16 + Steve Langasek  
wrote:> Since turning on 64-bit time_t is being handled centrally 
through a change

to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for rdkit
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.


It is most likely my fault this has not been resolved yet - by uploading 
202309.3-3 I trashed 202309.3-2.1~exp1. Am I right that I should 
reupload rdkit with t64 binaries to experimental now?


Andrius

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Andrius Merkys]

Hi Nilesh,

On 2024-04-10 19:53, Nilesh Patra wrote:

On Mon, Apr 08, 2024 at 08:59:26AM +0300, Andrius Merkys wrote:

On 2024-04-07 15:28, Nilesh Patra wrote:

Assistance required with maintaining the singularity-container package.


I am not offering help with singularity-container, but do you by any chance
know why apptainer is not packaged for Debian? I cannot find a wnpp bug.


I am lazy to find references right now, but you should be able to find it in
debian-hpc and debian-devel archives. If I don't miss anything this was the
sequence of events:

1) While updating singularity-container, Andreas created a repo for apptainer on
salsa.
2) The goal at that time was to get a mobility compute (either apptainer or
singularity) up and running
3) singularity and apptainer codebases are in sync so as per my understanding
there's no real point in having *both* - here's a brief discussion about it[1]


Thanks a lot for the summary. I found packaging repository for apptainer 
on salsa and wrote the debian-hpc team to ask about its status [4]. I 
was not aware about the close relation between apptainer and singularity.



My opinion: It does not make a lot of sense to package apptainer as well.
Although the latter is "community" maintained, the codebases for
sylabs/singularity and apptainer are in close sync at most times which also
means they keep inheriting CVEs from each other too.

As a result one may not be able to maintain apptainer well in stable release
either unless they have:
a) Good/Great go programming skills
b) ability to deal with CVEs and backports

I'd like to just link to a similar discussion thread about the same rather than
repeating the points[2] and here's what upstream says[3].


I agree with you, if their codebases are in sync, it does not make sense 
to have them both.



[1]: https://lists.debian.org/debian-hpc/2022/08/msg00021.html
[2]: https://lists.debian.org/debian-devel/2023/01/msg00078.html
[3]: https://lists.debian.org/debian-devel/2023/01/msg00080.html


[4] https://lists.debian.org/debian-hpc/2024/04/msg00012.html

Best wishes,
Andrius

Bug#1068942: unblock 1068942 by 1069098

[Andrius Merkys]

control: unblock 1068942 by 1069098

Hello,

emboss no longer builds on s390x and its binaries have been RMed from 
s390x, unblocking emboss migration to testing. This in principle should 
resolve the current bug.


Andrius

Bug#1069226: tomogui: FTBFS: RuntimeError: Sphinx is required to build or test the documentation

[Andrius Merkys]

Source: tomogui
Version: 0.3.1-2
Severity: serious
Tags: ftbfs

Hello,

tomogui FTBFS in sid on amd64:

running build_doc
Traceback (most recent call last):
  File "/home/merkys/tomogui-0.3.1/setup.py", line 804, in 
setup_package()
  File "/home/merkys/tomogui-0.3.1/setup.py", line 801, in setup_package
setup(**setup_kwargs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
107, in setup

return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 185, in setup

return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", 
line 201, in run_commands

dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 969, in run_commands

self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, 
in run_command

super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", 
line 988, in run_command

cmd_obj.run()
  File "/home/merkys/tomogui-0.3.1/setup.py", line 175, in run
raise RuntimeError(
RuntimeError: Sphinx is required to build or test the documentation.
Please install Sphinx (http://www.sphinx-doc.org).

Bug#1069225: freesas: FTBFS: fatal error: numpy/arrayobject.h: No such file or directory

[Andrius Merkys]

Source: freesas
Version: 0.9.0-6
Severity: serious
Tags: ftbfs

Hello,

freesas FTBFS in sid on amd64:

INFO:root:x86_64-linux-gnu-gcc -Wsign-compare -fwrapv -O2 -Wall 
-Werror=implicit-function-declaration -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/merkys/freesas-0.9.0=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -g -DNDEBUG 
"-DPyMODINIT_FUNC=__attribute__((visibility(\"default\"))) PyObject* " 
-I/usr/include/python3.11 -c freesas/_distance.c -o 
build/temp.linux-x86_64-cpython-311/freesas/_distance.o -fopenmp 
-fvisibility=hidden
freesas/_distance.c:1212:10: fatal error: numpy/arrayobject.h: No such 
file or directory

 1212 | #include "numpy/arrayobject.h"
  |  ^
compilation terminated.

Bug#1069224: nabu: FTBFS: AssertionError: OpenclUnsharpMask: max error is too high with method

[Andrius Merkys]

Source: nabu
Version: 2023.1.1-3
Severity: serious
Tags: ftbfs

Hello,

nabu FTBFS in sid on amd64:

 
FAILURES 
=
__ 
TestUnsharp.testOpenclUnsharp 
__


self = 

@pytest.mark.skipif(not (__has_pyopencl__), reason="Need pyopencl 
for this test")

def testOpenclUnsharp(self):
cl_queue = CommandQueue(self.cl_ctx)
d_image = parray.to_device(cl_queue, self.data)
d_out = parray.zeros_like(d_image)
for method in OpenclUnsharpMask.avail_methods:
d_image = parray.to_device(cl_queue, self.data)
d_out = parray.zeros_like(d_image)

opencl_unsharp = OpenclUnsharpMask(self.data.shape, 
self.sigma, self.coeff, method=method, ctx=self.cl_ctx)

opencl_unsharp.unsharp(d_image, output=d_out)
res = d_out.get()
>   self.check_result(res, method, 
error_msg_prefix="OpenclUnsharpMask")


nabu/misc/tests/test_unsharp.py:61:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


self = 
result = array([[ 82.38305 ,  82.57701 ,  82.776085, ..., 116.8 , 
116.8 ,

116.8 ],
   [ 82.23501 ,  82.112217],
   [177.92279 , 177.92285 , 177.92336 , ...,  36.  ,  57.  ,
 57.  ]], dtype=float32)
method = 'log', data = None, error_msg_prefix = 'OpenclUnsharpMask'

def check_result(self, result, method, data=None, 
error_msg_prefix=None):

reference = self.get_reference_result(method, data=data)
mae = np.max(np.abs(result - reference))
err_msg = str(
"%s: max error is too high with method=%s: %.2e > %.2e" % 
(error_msg_prefix or "", method, mae, self.tol)

)
>   assert mae < self.tol, err_msg
E   AssertionError: OpenclUnsharpMask: max error is too high with 
method=log: 2.33e+02 > 1.00e-04

E   assert 232.60403 < 0.0001
E+  where 0.0001 = object at 0x7f62be9990a0>.tol


nabu/misc/tests/test_unsharp.py:47: AssertionError

Bug#1069170: RM: emboss [s390x] -- ROM; FTBFS

[Andrius Merkys]

control: tags -1 - moreinfo

On Wed, 17 Apr 2024 14:03:10 +0300 Andrius Merkys  
wrote:> Please remove emboss binaries for s390x because of #1069098. I 
have not
yet filed RM requests for all the reverse dependencies, therefore I tag 
this with moreinfo, to be removed once I am done.


RM bugs for arch:any reverse dependencies filed and marked as blocking 
the current bug. Therefore I remove moreinfo tag.


Andrius

Bug#1069174: RM: embassy-domsearch [s390x] -- ROM; Build-Depends missing on s390x

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal
Control: block 1069170 by -1

Hello,

Please remove embassy-domsearch binaries for s390x, as emboss-lib is no 
longer built there due to #1069098.


Andrius

Bug#1069173: RM: embassy-domalign [s390x] -- ROM; Build-Depends missing on s390x

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal
Control: block 1069170 by -1

Hello,

Please remove embassy-domalign binaries for s390x, as emboss-lib is no 
longer built there due to #1069098.


Andrius

Bug#1069172: RM: embassy-domainatrix [s390x] -- ROM; Build-Depends missing on s390x

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal
Control: block 1069170 by -1

Hello,

Please remove embassy-domainatrix binaries for s390x, as emboss-lib is 
no longer built there due to #1069098.


Andrius

Bug#1069170: RM: emboss [s390x] -- ROM; FTBFS

[Andrius Merkys]

Package: ftp.debian.org
Severity: normal
Tags: moreinfo

Hello,

Please remove emboss binaries for s390x because of #1069098. I have not 
yet filed RM requests for all the reverse dependencies, therefore I tag 
this with moreinfo, to be removed once I am done.


Andrius

Bug#1069142: emboss: build time testsuite is failing silently

[Andrius Merkys]

Hi Charles,

On Wed, 17 Apr 2024 09:30:03 +0300 Andrius Merkys  wrote:
While looking into why #1069098 has not been detected earlier, I noticed 
that emboss build time testsuite is silently failing since at least 
6.4.0-3. This needs fixing in order to avoid problems similar to #1069098.


I noticed (via 'git blame debian/rules') it was you who has added the 
build time tests for emboss. However, they seem to be broken since at 
least 6.4.0-3: tests seem to require 'embassy' directory which is not in 
the source tarball:


   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
rm -f test-stamp
[ -d debian/testbackup ] || cp -a test debian/testbackup
sed -i "/SET emboss_tempdata/cSET emboss_tempdata /<>/test" 
test/.embossrc
sed -i "/SET emboss_qadata/cSET emboss_qadata /<>/test" 
test/.embossrc

echo "SET emboss_acdroot /<>/emboss/acd" >> test/.embossrc
echo "SET emboss_data /<>/emboss/data" >> test/.embossrc
echo "SET emboss_docroot /<>/doc" >> test/.embossrc
cd test/qa && LS_COLORS='' EMBOSSRC=/<>/test 
PATH=/<>/emboss:$PATH EMBOSS_ROOT=../../../ ./qatest.csh

Failed to find embassy directory at ../../scripts/qatest.pl line 1045.

Perhaps you have any idea how to address this?

If these tests are too difficult to get running, I would like to replace 
them with something that could at least check for segmentation faults.


Best wishes,
Andrius

Bug#1069142: emboss: build time testsuite is failing silently

[Andrius Merkys]

Source: emboss
Version: 6.4.0-3
Severity: important
Owner: Andrius Merkys 

Hello,

While looking into why #1069098 has not been detected earlier, I noticed 
that emboss build time testsuite is silently failing since at least 
6.4.0-3. This needs fixing in order to avoid problems similar to #1069098.


Andrius

Bug#1069098: emboss: all executables segfault on s390x

[Andrius Merkys]

Hi Andreas,

On 2024-04-17 08:32, Andreas Tille wrote:

I'd recommend following the procedure you supposed in
https://lists.debian.org/debian-med/2024/04/msg00034.html

Someone needs to file removal requests for s390x for the
rdepends from emboss, thought.


Thanks, this is what I am going to do next.

Best wishes,
Andrius

Bug#1069098: emboss: all executables segfault on s390x

[Andrius Merkys]

Package: emboss
Version: 6.6.0+dfsg-9
Severity: important
Tags: bullseye bookworm trixie sid
X-Debbugs-CC: debian-...@lists.debian.org

Hello,

All emboss executables segfault on s390x since bullseye. Segfault is 
evident when calling any of emboss executables without CLI arguments or 
only with '--help'. Checking with GDB on sid for 'gdb seqret' says:


(gdb) run
Starting program: /usr/bin/seqret
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
cvt_s (code=, ap=0x3ff99c0, put=0x3fff77b79b8 
, cl=0x3ff9e70, flags=0x3ff99c8, width=-2147483648, 
precision=-2147483648) at ajfmt.c:352

352if(str)

GDB localises the issue for seqret in a string formatting function.

Andrius

Bug#1068925: [Debichem-devel] Bug#1068925: macromoleculebuilder: FTBFS on armhf (error: inconsistent deduction for auto return type: 'long int' and then 'long long int')

[Andrius Merkys]

control: forwarded -1 
https://simtk.org/tracker/?func=detail_id=359=827=3289


Hi,

On 2024-04-13 16:52, Kentaro HAYASHI via Debichem-devel wrote:

Dear Maintainer,

  macromoleculebuilder fails to build on armhf.

FYI:

https://buildd.debian.org/status/fetch.php?pkg=macromoleculebuilder=armhf=4.0.0%2Bdfsg-3.1=1710492689=0

Currently, limited architecture succeeds to build (amd64,
arm64, and loong64)


Judging from the fact that MMB used to build on armhf before the time_64 
transition, I assume that time value is being assigned to 32bit variable 
somewhere. I have forwarded the bug upstream.


Andrius

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

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

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

Bug#1068692: RFP: python-pycddl -- Deserialize CBOR and/or do CDDL schema validation

[Andrius Merkys]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-rust-maintain...@lists.alioth.debian.org

* Package name: python-pycddl
  Version : 0.6.1
  Upstream Author : Systema Development LLC
* URL : https://gitlab.com/tahoe-lafs/pycddl
* License : Expat
  Programming Lang: Python
  Description : Deserialize CBOR and/or do CDDL schema validation

CDDL is a schema language for the CBOR serialization format. pycddl 
allows one to validate CBOR documents match a particular CDDL schema, 
based on the Rust cddl library. Optionally, it can decode CBOR documents.


python-pycddl is a new dependency of tahoe-lafs. It has parts written in 
Rust. I have no knowledge of Rust packaging thus it would be great if 
someone could help. Thus I am CCing Rust team via X-Debbugs-CC.


Andrius

Bug#1068626: libdwarf-dev: please provide CMake files

[Andrius Merkys]

Package: libdwarf-dev
Version: 20210528-1

Hello,

dwarfutils seem to contain CMake files needed to find libdwarf using 
CMake's find_library(). However, these files do not seem to be installed 
into the libdwarf-dev binary package. It might be because the package is 
currently built using configure, and CMake files would be built when 
building with CMake buildsystem.


I am working on packaging coot [1] which uses find_library() to locate 
libdwarf. Could you please check if it is possible to include CMake 
files in libdwarf-dev?


[1] https://bugs.debian.org/897673

Andrius

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Andrius Merkys]

Hi Nilesh,

On 2024-04-07 15:28, Nilesh Patra wrote:

Assistance required with maintaining the singularity-container package.


I am not offering help with singularity-container, but do you by any 
chance know why apptainer is not packaged for Debian? I cannot find a 
wnpp bug.


Thanks for caring about singularity-container.

Andrius

Bug#1068381: closed by Debian FTP Masters (reply to Andrius Merkys ) (Bug#1068381: fixed in openapi-specification 3.1.0-2)

[Andrius Merkys]

On 2024-04-04 15:41, Julian Gilbey wrote:

Wow, that was fast - thank you!


You are welcome - hope that helps!

Best wishes,
Andrius

Bug#1068294: RFH: liboqs -- library for quantum-safe cryptographic algorithms

[Andrius Merkys]

Package: wnpp
Severity: normal

In the light of recent calls to increase the quality and the bus factor 
of security-related packages, I request assistance with maintaining the 
liboqs package. I do not have enough time nor expertise to properly 
maintain liboqs alone.


The package is sid-only per upstream request (#1000303) and should stay 
this way until the upstream gives a green light.


I fail to keep up with upstream releases mostly due to the work needed 
to update debian/copyright. The upstream does a great job in applying 
REUSE standards on liboqs source, but as the package is in active 
development there usually are many changes to its source files.


The package description is:

liboqs is an open source C library for quantum-safe cryptographic 
algorithms. It provides a collection of open source implementations of 
quantum-safe key encapsulation mechanism (KEM) and digital signature 
algorithms; a common API for these algorithms; a test harness and 
benchmarking routines.


liboqs is part of the Open Quantum Safe (OQS) project, which aims to 
develop and integrate into applications quantum-safe cryptography to 
facilitate deployment and testing in real world contexts. In particular, 
OQS provides prototype integrations of liboqs into TLS and SSH, through 
OpenSSL and OpenSSH.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066450: opensearch: FTBFS with lucene9/9.10.0+dfsg

[Andrius Merkys]

control: retitle -1 opensearch: FTBFS with lucene9/9.10.0+dfsg

I have recently updated lucene9. Current FTBFS is caused by missing 
lucene9 classes. Thus it seems that lucene9 API has changed breaking 
backwards compatibility.


Andrius

Bug#1003512: closed by Debian FTP Masters (reply to Patrick Winnertz ) (Bug#1003512: fixed in cherrytree 1.1.0+dfsg-1)

[Andrius Merkys]

Hi Patrick,

On 2024-03-28 17:09, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the wnpp package:

#1003512: RFA: cherrytree -- hierarchical note taking application

It has been closed by Debian FTP Masters  (reply to 
Patrick Winnertz ).


Thanks for taking care of cherrytree!

Best wishes,
Andrius

Bug#943315: ITP: vst3sdk -- professional audio plugin development kit

[Andrius Merkys]

Hello,

I had some luck in packaging vst3sdk. I pushed my packaging attempts 
(just the debian/ directory) to my personal repository on salsa [1]. The 
package builds and installs VST3 plugins, debian/copyright is as well 
almost finished.


I had some difficulties in constructing the multiple upstream tarball 
(MUT). uscan does not seem to be able to handle debian/watch correctly, 
thus I first have to change upstream version to 0 in debian/changelog, 
run 'uscan --download', revert the upstream version in debian/changelog 
and run it again. From downloaded tarballs the MUT is built by 
debian/get-orig-source. I plan to import the constructed MUT into the 
same git repository [1] to simplify its usage, but I will probably 
exclude doc/ subdirectory due to multiple source-is-missing problems.


[1] https://salsa.debian.org/merkys/vst3sdk

Andrius

Bug#1066296: RE: Bug#1066296: xli: FTBFS: dither.c:77:36: error: implicit declaration of function ‘strlen’ [-Werror=implicit-function-declaration]

[Andrius Merkys]

Hi Nilson,

On Wed, 13 Mar 2024 17:34:15 + Nilson Silva 
 wrote:

Relevant part (hopefully):
> cc -c -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O 
-DSYSPATHFILE=\"/usr/lib/X11/Xli\"   -Wdate-time -D_FORTIFY_SOURCE=2 fill.c
> dither.c: In function ‘dither’:
> dither.c:77:36: error: implicit declaration of function ‘strlen’ 
[-Werror=implicit-function-declaration]
>77 | image->title = (char *)lmalloc(strlen(cimage->title) + 12);
>   |^~
> dither.c:28:1: note: include ‘’ or provide a declaration of ‘strlen’
>27 | #include "xli.h"
>   +++ |+#include 
>28 |


Do you need a hand in fixing this? This issue threatens a bunch of my 
packages with autoremoval.


Best wishes,
Andrius

Bug#1067212: ITP: libgraph-grammar-perl -- Grammar for graphs

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libgraph-grammar-perl
  Version : 0.1.0
  Upstream Author : Andrius Merkys 
* URL : https://metacpan.org/release/Graph-Grammar
* License : BSD-3-Clause
  Programming Lang: Perl
  Description : Grammar for graphs

Graph::Grammar is a Perl implementation of a graph rewriting method 
(a.k.a. graph grammar). Much of the API draws inspiration from 
Parse::Yapp, but instead of acting on text streams Graph::Grammar is 
oriented at graphs, as implemented in Perl's Graph module. 
Graph::Grammar implements a single method parse_graph() which accepts an 
instance of Graph and an array of rules. Every rule is evaluated for 
each vertex in a graph and, if a match is found, an action associated 
with the rule is executed.


Graph::Grammar is a new dependency of chemonomatopist.

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libgraph-grammar-perl

Bug#964773: 964773: inchi to become free software again

[Andrius Merkys]

Hello,

An update: the upcoming inchi release is going to be licensed under 
Expat [1]. Thus an opportunity may appear to build rdkit with inchi support.


[1] https://github.com/IUPAC-InChI/InChI/issues/8

Andrius

Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates

[Andrius Merkys]

Package: antlr4-maven-plugin
Version: 4.9.2-2
Control: affects -1 src:chemicaltagger

Hello,

antlr4-maven-plugin provides maven coordinates carrying package version 
only:


/usr/share/maven-repo/org/antlr/antlr4-maven-plugin/4.9.2/antlr4-maven-plugin-4.9.2.jar
/usr/share/maven-repo/org/antlr/antlr4-maven-plugin/4.9.2/antlr4-maven-plugin-4.9.2.pom

This is difficult to depend on, as each version bump affects the path. 
Thus it would be nice to have debian-versioned coordinates as well:


/usr/share/maven-repo/org/antlr/antlr4-maven-plugin/debian/antlr4-maven-plugin-debian.jar
/usr/share/maven-repo/org/antlr/antlr4-maven-plugin/debian/antlr4-maven-plugin-debian.pom

Or is there a reason why debian-versioned coordinates are not provided?

Andrius

Bug#1064953: [Debichem-devel] Bug#1064953: rdkit: Please provide cmake files

[Andrius Merkys]

Hi Gürkan,

On 2024-02-28 10:17, Gürkan Myczko wrote:

thanks for the rdkit packaging would it be possible to also ship
rdkit-config.cmake
rdkit-config-version.cmake
rdkit-targets.cmake
rdkit-targets-none.cmake
in /usr/lib/cmake/rdkit/ (needed for coot packaging)?


I can give it a look.

I tried to package coot some years ago (#897673), but gave up, mostly 
because of its many dependencies and lots of files with missing 
copyright information. I hope the situation is better now. Is rdkit now 
a hard dependency of coot?


Best,
Andrius

Bug#1061765: Help needed to fix python-coverage-test-runner

[Andrius Merkys]

Hi Andreas,

On 2024-02-23 09:15, Andreas Tille wrote:

I've attempted to fix python-coverage-test-runner in Git since this
package is finally responsible for the failure of vmdb2:

  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22,
in 
 import imp
ModuleNotFoundError: No module named 'imp'


I had a similar problem. I worked it around by depending on 
python3-zombie-imp, the original code did not require any modifications.


Best,
Andrius

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[Andrius Merkys]

Hi,

On 2024-02-14 00:21, Peter Hyman wrote:

Description : tmpwatch is a utility searches for files not accessed in a
specific time and deletes them


I fail to parse the short description as a sentence. Maybe:

s/utility searches/utility which searches/

Best,
Andrius

Bug#1041027: rapidjson FTBFS with googletest 1.13.0

[Andrius Merkys]

On Thu, 8 Feb 2024 10:22:10 +0200 Andrius Merkys  wrote:
I attach a patch which fixes the issue by setting -std=c++14 (as needed 
by googletest) and commenting out a code line in 
include/rapidjson/document.h which is gone in the newest upstream commit 
[1].


[1] 
https://github.com/Tencent/rapidjson/commit/a98e2bd633a2736cc41f96ec85ef0c50e44d


A more elegant solution would be to configure rapidjson with 
-DRAPIDJSON_BUILD_CXX11=OFF and set -std=c++14 via 
DEB_CXXFLAGS_MAINT_APPEND in debian/rules, this would avoid patching 
CMakeLists.txt.


Andrius

Bug#1041027: rapidjson FTBFS with googletest 1.13.0

[Andrius Merkys]

control: tags -1 + patch

On Fri, 14 Jul 2023 11:03:55 +0300 Adrian Bunk  wrote:

Source: rapidjson
Version: 1.1.0+dfsg2-7.1
Severity: serious
Tags: ftbfs trixie sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rapidjson.html

...
In file included from /usr/src/gtest/include/gtest/gtest-message.h:57,
 from /usr/src/gtest/include/gtest/gtest-assertion-result.h:46,
 from /usr/src/gtest/include/gtest/gtest.h:64,
 from 
/build/1st/rapidjson-1.1.0+dfsg2/test/unittest/unittest.h:47,
 from 
/build/1st/rapidjson-1.1.0+dfsg2/test/unittest/namespacetest.cpp:15:
/usr/src/gtest/include/gtest/internal/gtest-port.h:270:2: error: #error C++ 
versions less than C++14 are not supported.
  270 | #error C++ versions less than C++14 are not supported.
  |  ^
...


I attach a patch which fixes the issue by setting -std=c++14 (as needed 
by googletest) and commenting out a code line in 
include/rapidjson/document.h which is gone in the newest upstream commit 
[1].


[1] 
https://github.com/Tencent/rapidjson/commit/a98e2bd633a2736cc41f96ec85ef0c50e44d


Andrius--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -63,7 +63,7 @@
 if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.7.0")
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
 else()
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")
 endif()
 endif()
 if (RAPIDJSON_BUILD_ASAN)
--- a/include/rapidjson/document.h
+++ b/include/rapidjson/document.h
@@ -316,7 +316,7 @@
 
 GenericStringRef(const GenericStringRef& rhs) : s(rhs.s), length(rhs.length) {}
 
-GenericStringRef& operator=(const GenericStringRef& rhs) { s = rhs.s; length = rhs.length; }
+// GenericStringRef& operator=(const GenericStringRef& rhs) { s = rhs.s; length = rhs.length; }
 
 //! implicit conversion to plain CharType pointer
 operator const Ch *() const { return s; }

Bug#1061814: [Debichem-devel] Bug#1061814: Bug#1061814: add patch

[Andrius Merkys]

On 2024-02-07 10:59, Matthias Klose wrote:

the package in experimental still has the dependency on python3-distutils.


Right, I have just removed it in salsa.d.o.

Best,
Andrius

Bug#1061814: [Debichem-devel] Bug#1061814: add patch

[Andrius Merkys]

Hi,

On 2024-02-07 07:29, Matthias Klose wrote:

this is fixed upstream, and in experimental.

however you also have to drop the dependency on python3-distutils.

patch at
http://launchpadlibrarian.net/713215440/openmm_8.0.0+dfsg-6build1_8.0.0+dfsg-6ubuntu1.diff.gz


Thanks for a patch. I have already filed a transition bug for openmm [1] 
(experimental -> unstable). Thus since this issue is already fixed in 
experimental I do not think it is worth fixing in unstable.


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

Best,
Andrius

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

Bug#1062666: transition: openmm

[Andrius Merkys]

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

Hello,

I would like to request a transition slot for openmm
(experimental -> unstable) due to soname bump. Current ben tracker [1]
is OK.

All reverse dependencies rebuild fine, except for cpptraj which is not 
in testing.


Thanks,
Andrius

[1] https://release.debian.org/transitions/html/auto-openmm.html

Bug#1058454: [Debichem-devel] Bug#1058454: Do we really need to support 32bit in abinit and prody (maybe others)

[Andrius Merkys]

Hi Andreas,

On 2024-01-31 13:08, Andreas Tille wrote:

in connection with the time_t transition in Debian Med we are
discussing[1] whether we really need 32 bit support for some of our
tools or whether we should realistically drop this support to
concentrate on problems which are more relevant for our users.

I wonder whether we could also consider abinit and prody candidates for
droping 32 bit support and by doing so closing these two RC bugs.


prody fails a single test case which could be fixed by increasing test 
tolerance. Therefore I do not think it is worth RM'ing. It is just that 
I cannot get down to it due to being busy with other Python migration 
bugs in packages I care more about.



[1] https://lists.debian.org/debian-med/2024/01/msg00021.html


Best,
Andrius

Bug#1062398: sympa: lacks dependency on perl-doc

[Andrius Merkys]

Package: sympa
Version: 6.2.70~dfsg-2

Dear Maintainers,

Please consider adding dependency on perl-doc for sympa. When called 
'sympa help' or just 'sympa', instead of readable manual 'sympa' shows 
plain Perl code with a warning that perl-doc is needed to show it in 
more human-readable form. After having perl-doc installed these calls 
result in nice manpage-style output.


Andrius

Bug#1061814: [Debichem-devel] Bug#1061814: openmm fails its autopkg tests with Python 3.12

[Andrius Merkys]

Hi,

On 2024-01-29 21:59, Matthias Klose wrote:

Package: src:openmm
Version: 8.0.0+dfsg-6
Severity: important
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

With python3-defaults from experimental, the package fails its autopkg 
tests:


[...]

openmm was built for default Python only (3.11 at the time of building), 
thus the autopkgtest failure was expected. I have just uploaded openmm 
8.1.0+dfsg-2 to experimental after enabling the build for all supported 
Python versions. I expect this version to have this issue addressed.


Andrius

Bug#1042858: promod3: unable to install on arm64

[Andrius Merkys]

Hi,

On Tue, 1 Aug 2023 23:23:39 +0200 Sebastian Ramacher 
 wrote:

$ apt-get install promod3
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 promod3 : Depends: python3-ost but it is not installable
   Depends: python3-promod3 but it is not installable
E: Unable to correct problems, you have held broken packages.


promod3 is arch:all, but it depends on arch:any packages which build on 
amd64 only. Is it necessary to limit the architecture list for promod3? 
I am reluctant to do so as there will be the need to manually update the 
list every time a new architecture becomes supported by its arch:any 
dependencies.


Andrius

Bug#1061479: mk-origtargz: support lz compression

[Andrius Merkys]

Package: devscripts
Version: 2.23.7
Severity: wishlist

Dear Maintainers,

I am maintaining ocrad package which recently has switched to shipping 
its tarballs compressed with lz (ocrad-0.29.tar.lz). 'tar.lz' files are 
identified by 'file' as 'application/x-lzip' and seamlessly extracted by 
'tar'. However, 'tar_regex' in 
/usr/share/perl5/Devscripts/MkOrigtargz/Config.pm does not allow 
'tar.lz', albeit it includes 'tlz'. If renamed to 'tlz', the archive is 
again refused to be processed as '%mime2comp' in 
/usr/share/perl5/Devscripts/Compression.pm does not contain 
'application/x-lzip'. I tried adding 'application/x-lzip' to 
'%mime2comp', but then ran into "uscan: error: tar is not a supported 
compression" error and gave up.


Could you please give a look at implementing support for lz compression 
in mk-origtargz?


Best wishes,
Andrius

Bug#1061263: 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

Bug#1054409: redmine-plugin-redhopper: redmine stops working after installing this plugin

[Andrius Merkys]

Control: tags -1 + confirmed

Hi,

On Tue, 24 Oct 2023 09:57:08 +0300 Andrius Merkys  wrote:
Thank you for reporting this, it seems to be a rather serious issue. I 
will give it a closer look once I get to setting up a VM with bookworm.


I have successfully reproduced the issue on fresh install of Debian 
bookworm. The cause seems to be the missing Gemfile for 
redmine-plugin-redhopper (binary package does not contain it, although 
it should). You may patch it yourself by downloading the following file 
and adjusting gem versions in it:


$ cd /usr/share/redmine/plugins/redhopper
$ wget 
https://sources.debian.org/data/main/r/redmine-plugin-redhopper/2.0.0-2/Gemfile


In the file you would have to modify minimum versions for the following 
gems (correct versions added in the cited lines):


gem 'acts_as_list', '>= 0.9.15'
gem 'haml', '>= 5.1.1'

As well as comment out these lines:

group :test do
  gem 'rails-controller-testing', '~> 1.0.4'
end

This is all I can suggest for now, but this fixed the installation for 
me. I will try to patch the package for bookworm distribution as well.


Best wishes,
Andrius

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

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

Bug#1056457: python-ase's autopkg tests fail with Python 3.12

[Andrius Merkys]

Hi Graham,

On Mon, 8 Jan 2024 08:46:45 +0200 Graham Inggs  wrote:

However, since spglib stopped building its extension for all supported
Python versions (see #1057858) testing python-ase against Python 3.12
now fails with:

531s INTERNALERROR> Traceback (most recent call last):
531s INTERNALERROR>   File
"/usr/lib/python3/dist-packages/spglib/spglib.py", line 41, in

531s INTERNALERROR> from spglib import _spglib as spg
531s INTERNALERROR> ImportError: cannot import name '_spglib' from
partially initialized module 'spglib' (most likely due to a circular
import) (/usr/lib/python3/dist-packages/spglib/__init__.py)

Therefore, I let python-ase only test against the default Python
version [1], and lower the severity of this bug, until either Python
3.12 is the default, or spglib builds its extension for all supported
Python versions again.


Maybe an alternative solution would be to only disable spglib-related 
test cases for Python 3.12. It seems that spglib is not an essential 
dependency for python-ase, thus the remaining test cases could still be 
ran to ensure package's integrity on Python 3.12.



[1] 
https://salsa.debian.org/debichem-team/python-ase/-/commit/b33055fd68da81e1806e7a0f0dd65dc5b53fc3b2

Best wishes,
Andrius

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

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

Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andrius Merkys]

Hi,

On 2024-01-15 17:34, Christoph Berg wrote:

Re: Andrius Merkys

The patch proposed in #1042610 does not fix test failure. Interestingly, the
failure seems to be nondeterministic: after patching #1042610 some builds
succeed. However, I did not manage to find the root cause.


The difference between a working and a failing run is this diff:

 dh_auto_test -O--buildsystem=pybuild
-I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest test
+I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest tests

I.e. pybuild invokes either
"python3.12 -m pytest test" (good)
or "python3.12 -m pytest tests" (bad)


Great catch! I tried diff'ing working and failing buildlogs as well, but 
probably was not that attentive to spot this.



I tried to drill down where this decision is made but couldn't spot
it.


This might be a bug in dh-python.


As a workaround, we can move the "tests" directory aside. Then it will
reliably run the "test" target. (Not pretty, but I want to get the
package unstuck.)


Yes, this makes sense.

Best,
Andrius

Bug#1059998: Update liboqs to mitigate KyberSlash - potential to leak secrets

[Andrius Merkys]

Hi,

On 2024-01-04 16:18, Kartik Kulkarni wrote:
The latest release 
[0.9.1](https://github.com/open-quantum-safe/liboqs/releases/tag/0.9.1 
) has 
merged the fixes

for a potential division timing attack found in kyber reference design.
- https://github.com/open-quantum-safe/liboqs/pull/1631 

- https://github.com/open-quantum-safe/liboqs/pull/1637 



More information about this attack can be found at 
https://kyberslash.cr.yp.to/faq.html 


Thanks for the information. I am aware of the new release. Reviewing and 
updating the copyright details in liboqs Debian package is the major 
blocker for me, as the package contains files from many different 
sources. I would happily share the maintenance burden, though.


Best wishes,
Andrius

Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andrius Merkys]

Hi,

On Tue, 12 Dec 2023 19:35:09 +0100 s3v  wrote:

please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042610
for a proposed patch.


The patch proposed in #1042610 does not fix test failure. Interestingly, 
the failure seems to be nondeterministic: after patching #1042610 some 
builds succeed. However, I did not manage to find the root cause.


Andrius

Bug#1042610: #1042610: patch works

[Andrius Merkys]

Control: tags -1 + patch

Hello,

I can confirm that the provided patch (+B-D on python3-doc) fixes the 
bug. However, #1054974 is not fixed, thus behave still FTBFS.


Andrius

Bug#1057644: multiple python versions in a single .deb package

[Andrius Merkys]

Hi,

On 2024-01-01 06:21, Mo Zhou wrote:
I tried this and it turns to be a little bit complicated to support. The 
code change can be found in the git history, which was reverted by me. 
The problem is that the file libtorch_python.so.* is specific to one 
python version, and cannot be shared between py3.11 and py3.12. One of 
them will break if we do setup.py for both versions.


Thanks a lot for giving this a shot. This means that all reverse 
dependencies of pytorch will have to support default Python only.


Best wishes,
Andrius

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

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

Bug#1056457: [Debichem-devel] Bug#1056457: python-ase's autopkg tests fail with Python 3.12

[Andrius Merkys]

Control: tags -1 + patch

Hi,

On 2023-12-20 20:23, s3v wrote:

After applying [1][2][3] from upstream and adding "-p no:warnings":

   addopts = -p no:cacheprovider -p no:warnings
  
in ase/test/pytest.ini (DeprecationWarnings from various packages make

tests fail), I was able to build your package in a sid chroot environment.

Kind Regards

[1] https://gitlab.com/ase/ase/-/commit/9c019c1782115343014691596514eb6d351e8e17
[2] https://gitlab.com/ase/ase/-/commit/f0932b3385fea739bc737e5aec1fc92960b0550c
[3] https://gitlab.com/ase/ase/-/merge_requests/3022


This is great news, thanks for caring for python-ase. It would be nice 
to have an upstream release with all Python 3.12 compatibility fixes, 
but in the meantime patches are OK.


Is there a way to ignore DeprecationWarnings, but leave them in to the 
output? They are quite helpful to see, but not worth failing the build 
at the time being.


Best,
Andrius

Bug#1010653: needs-internet restriction (Was: Bug#1010653: closed ...) (Bug#1010653: fixed in busco 5.5.0-2)

[Andrius Merkys]

Hi Andreas,

On 2023-12-20 12:37, Andreas Tille wrote:

Hi Andrius,

Am Wed, Dec 20, 2023 at 08:27:31AM +0200 schrieb Andrius Merkys:

On 2023-12-19 18:51, Debian Bug Tracking System wrote:

 [ Komolehin Israel Timilehin ]
 * Added autopkgtest to check hmmer and prodigal integration (Closes: 
#1010653)


Thanks for working on this. I see that the added autopkgtest uses network to
download the dataset. It is done properly, with 'needs-internet'
restriction, which is good. However, does Debian CI enable internet access
for such autopkgtests?


Isn't it exactly what needs-internet restriction was invented for?

May be I'm to naive here but I used it exactly for those cases and
it worked.


Right. I have never used needs-internet before, so just asking.

Best wishes,
Andrius

Bug#1010653: closed by Debian FTP Masters (reply to Komolehin Israel Timilehin ) (Bug#1010653: fixed in busco 5.5.0-2)

[Andrius Merkys]

Hi,

On 2023-12-19 18:51, Debian Bug Tracking System wrote:

[ Komolehin Israel Timilehin ]
* Added autopkgtest to check hmmer and prodigal integration (Closes: 
#1010653)


Thanks for working on this. I see that the added autopkgtest uses 
network to download the dataset. It is done properly, with 
'needs-internet' restriction, which is good. However, does Debian CI 
enable internet access for such autopkgtests?


Best,
Andrius

Bug#1058868: [Debichem-devel] Bug#1058868: gemmi: Please build shared library

[Andrius Merkys]

Hi,

On 2023-12-17 11:31, Yadd wrote:

currently src:gemmi builds gemmi and gemmi-dev. This doesn't permit to
build any software using gemmi-dev without static linking.

The proposed patch adds package libgemmi1 which contains the shared
library.


I looked into the shared library provided by gemmi v0.6.4 (newer 
upstream release than in your patch). This version of gemmi builds the 
shared library by default. However, the produced shared library does not 
carry a soversion, thus according to Debian principles it is not 
suitable to be packaged as public shared library, alas. Thus static 
linking is the only option for now.


Best wishes,
Andrius