Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files
Package: wnpp Severity: wishlist Owner: Andrius Merkys * Package name: cod-tools Version : 2.0 Upstream Author : Saulius Gražulis , Andrius Merkys , Antanas Vaitkus * URL : http://wiki.crystallography.net/cod-tools * License : GPL 2.0 Programming Lang: C, Perl, Python, Shell Description : tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files The package contains Crystallographic Information Format (CIF) v1.1 and v2.0 parser (parser of CIF v1.1 is compared to other parsers in Merkys et al. 2016, doi:10.1107/S1600576715022396) and scripts for manipulating CIF files. Package includes CIF parser bindings for C, Perl and Python. Tools from the package are used in the development and maintenance of the Crystallography Open Database (http://www.crystallography.net/cod/, usage described in Gražulis et al. 2009, doi:10.1107/S0021889809016690 and Gražulis et al. 2015, doi:10.1107/S1600576714025904). The tools follow the same filter-like usage pattern as Netpbm. As I am an upstream author, I plan to maintain the package myself. As this is my first submission, I will need a sponsor.
Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files
Dear Steffen, thank you for a swift response! I will prepare the package and upload it to the Debian Mentors ASAP and will let you know. Many thanks, Andrius On 07/06/17 17:19, Steffen Möller wrote: > Hi Andrius, > > I happily help with sponsoring. You may also consider to team up with > Debian Science at some point. > > Best, > > Steffen -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania Lecturer at Vilnius University Faculty of Mathematics and Informatics, Naugarduko g. 24 LT-03225 Vilnius, Lithuania
Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files
Dear Steffen, I have uploaded my packages to Debian Mentors (https://mentors.debian.net/package/cod-tools). I have managed to get rid of all lintian errors and warnings and will hopefully cure "no-upstream-changelog" pedantic notice in a short while. Could you please review my submission? For convenience, I have mirrored all debian/* files to GitHub: https://github.com/cod-developers/cod-deb-packaging. You have also suggested me teaming up with Debian Science. I have been subscribed to their mailing list for a while, however, I do not fully understand your suggestion. Should I apply for their help for packaging cod-tools? Many thanks, Andrius On 07/06/17 17:19, Steffen Möller wrote: > Hi Andrius, > > I happily help with sponsoring. You may also consider to team up with > Debian Science at some point. > > Best, > > Steffen -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania Lecturer at Vilnius University Faculty of Mathematics and Informatics, Naugarduko g. 24 LT-03225 Vilnius, Lithuania
Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files
Dear Andreas, thank you for your message. I would gladly maintain my package in either Debian Science or DebiChem team. Best wishes, Andrius On 10/06/17 07:58, Andreas Tille wrote: > Hi Andrius, > > thanks for this interesting ITP. This package seems to fit nicely into > the scope of Debian Science or DebiChem. I'd like to suggest you should > maintain the package in either of this team. > > Kind regards > >Andreas. > > On Wed, Jun 07, 2017 at 04:33:49PM +0300, Andrius Merkys wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Andrius Merkys >> >> * Package name: cod-tools >> Version : 2.0 >> Upstream Author : Saulius Gražulis , Andrius Merkys >> , Antanas Vaitkus >> * URL : http://wiki.crystallography.net/cod-tools >> * License : GPL 2.0 >> Programming Lang: C, Perl, Python, Shell >> Description : tools for manipulation of Crystallographic Information >> Format v1.1 and v2.0 files >> >> The package contains Crystallographic Information Format (CIF) v1.1 and >> v2.0 parser (parser of CIF v1.1 is compared to other parsers in Merkys et >> al. 2016, doi:10.1107/S1600576715022396) and scripts for manipulating CIF >> files. Package includes CIF parser bindings for C, Perl and Python. Tools >> from the package are used in the development and maintenance of the >> Crystallography Open Database (http://www.crystallography.net/cod/, usage >> described in Gražulis et al. 2009, doi:10.1107/S0021889809016690 and >> Gražulis et al. 2015, doi:10.1107/S1600576714025904). The tools follow >> the same filter-like usage pattern as Netpbm. >> >> As I am an upstream author, I plan to maintain the package myself. As >> this is my first submission, I will need a sponsor. >> >> -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania Lecturer at Vilnius University Faculty of Mathematics and Informatics, Naugarduko g. 24 LT-03225 Vilnius, Lithuania
Bug#864713: RFS: cod-tools/2.0-5 [ITP] -- tools for manipulation of Crystallographic Information Format files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cod-tools" * Package name: cod-tools Version : 2.0-5 Upstream Author : Saulius Gražulis , Andrius Merkys , Antanas Vaitkus * URL : http://wiki.crystallography.net/cod-tools * License : GPL 2.0 Section : misc It builds those binary packages: cod-tools - tools for manipulating CIF format files codcif - error-correcting CIF parser libcexceptions0 - C exception handling library libcod-cif-parser-bison-perl - error-correcting CIF parser - Perl bindings libcod-cif-parser-yapp-perl - error-correcting CIF parser - YAPP implementation libcod-precision-perl - COD precision handling module for Perl language libcod-usermessage-perl - COD message formatting module for Perl language libgetoptions0 - Command line argument processing library for C python-pycodcif - error-correcting CIF parser - Python bindings To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cod-tools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cod-tools/cod-tools_2.0-5.dsc More information about cod-tools can be obtained from http://wiki.crystallography.net/cod-tools. Regards, Andrius Merkys
Bug#1062398: sympa: lacks dependency on perl-doc
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#1058454: [Debichem-devel] Bug#1058454: Do we really need to support 32bit in abinit and prody (maybe others)
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#1062666: transition: openmm
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#1064953: [Debichem-devel] Bug#1064953: rdkit: Please provide cmake files
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#1075834: [Debichem-devel] Bug#1075834: Bug#1075834: python3-ase: new upstream release available
Hi, On 7/8/24 21:11, Graham Inggs wrote: On Sat, 6 Jul 2024 at 02:45, Drew Parsons wrote: debian/watch is broken. gitlab access to the tarballs is confusing, and I wasn't able to find a simple fix for debian/watch Apparently, this changed in gitlab in March, 2024 [1]. version=4 opts="searchmode=plain" \ https://gitlab.com/ase/ase/tags?sort=updated_desc -/archive/v?\d[\d.]+/ase-@ANY_VERSION@@ARCHIVE_EXT@ Seems to do the right thing for me. I have fixed the debian/watch according to Graham's suggestion. Best, Andrius
Bug#1074897: cura-engine: ftbfs with GCC-14
Control: retitle -1 rapidjson: causes FTBFS with GCC-14
Control: block 1075335 by -1
Control: block 1075439 by -1
Hello,
When building other packages with rapidjson-dev with GCC-14, the
following failure occurs:
/usr/include/rapidjson/document.h: In member function
‘rapidjson::GenericStringRef&
rapidjson::GenericStringRef::operator=(const
rapidjson::GenericStringRef&)’:
/usr/include/rapidjson/document.h:319:82: error: assignment of read-only
member ‘rapidjson::GenericStringRef::length’
319 | GenericStringRef& operator=(const GenericStringRef& rhs) {
s = rhs.s; length = rhs.length; }
|
~~~^~~~
This is the underlying reason at least for #1075335 and #1075439.
Andrius
Bug#1076519: [Debichem-devel] Bug#1076519: libinchi1: new version 1.07 of InChI (now MIT license scheme)
Control: reassign -1 src:inchi 1.03+dfsg-4 Dear Norwid, On 7/17/24 19:58, Norwid Behrnd via Debichem-devel wrote: I hereby request the update of the InChI package as provided by DebiChem. At present, download and installation of libinchi1/libinchi-bin from the repositories of Debian 13/trixie provides the software equivalent to version 1.03/June 15, 2010. While Andrius Merkys thankfully packaged this version in 2019, there already was the request to provide the community a package corresponding to a more recent version of InChI. However, starting with version 1.04 (September 2011), InChI trust adopted a license scheme which did not comply Debian's policies (see, for example [1]). Today Wednesday, 2024-07-17, the InChI trust released a new version 1.07 of the software. In addition to revised and extended functionality, the open source project hosted on GitHub[2] now adopts the MIT license scheme. Thanks for noticing about the release of InChI v1.07.0. However, the new version contains licensing inconsistencies of which I have informed the upstream some five months ago [3]. In strict sense these inconsistencies block the update of InChI in Debian. I am aware that the overall intention of InChI developers is to have InChI MIT licensed, but looking solely at the source tarball the license is not clear. [1] https://sourceforge.net/p/inchi/mailman/message/37365947/ [2] https://github.com/IUPAC-InChI/InChI [3] https://github.com/IUPAC-InChI/InChI/issues/8 Best, Andrius
Bug#1077055: [Debichem-devel] Bug#1077055: postgresql-16-rdkit: inchi support not included in rdkit build
Hi David, On 7/25/24 18:51, David Lounsbrough via Debichem-devel wrote: I wanted to ask if there's a reason that `inchi` support is not enabled for this package. You can read more about the attempts to enable InChI support in rdkit in [1]. In short, inchi package in Debian seems incompatible with rdkit (too old, seemingly), and the newer versions have licensing issues. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964773 Andrius
Bug#1056065: transition: spdlog
On Thu, 16 Nov 2023 18:01:01 +0200 Andrius Merkys wrote: * kodi (seems to be affected by spdlog API change) Sorry, kodi builds fine, it should not be here, my mistake. Best, Andrius
Bug#1056065: transition: spdlog
On 2023-11-17 08:42, Sebastian Ramacher wrote: I suspect that's due to the use of libspdlogX-fmtY. I've added a manual tracker and added the fmt postfix. Right, this might be the reason. Thanks! Andrius
Bug#1055696: 1055696: more info
Hi, I have reassigned this issue to python3-rdkit as Python 3.12 specific issue seems to be confined to python3-rdkit: $ python3.12 -c 'import rdkit' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/rdkit/__init__.py", line 6, in from . import rdBase ImportError: cannot import name 'rdBase' from partially initialized module 'rdkit' (most likely due to a circular import) (/usr/lib/python3/dist-packages/rdkit/__init__.py) Andrius
Bug#1056065: transition: spdlog
Hi Sebastian, On 2023-11-18 14:36, Sebastian Ramacher wrote: spdlog's autopkgtest fail, though: https://ci.debian.net/data/autopkgtest/testing/amd64/s/spdlog/39983394/log.gz Could you please take a look? Apparently spdlog needs catch2 >= 3.0.0. I have just added the versioned depends and uploaded. Best, Andrius
Bug#1056343: ITP: nanovg -- antialiased vector graphics rendering library for OpenGL
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: nanovg Version : 0.0~git20230826.f93799c Upstream Author : Mikko Mononen * URL : https://github.com/memononen/nanovg * License : Zlib Programming Lang: C Description : antialiased vector graphics rendering library for OpenGL NanoVG is small antialiased vector graphics rendering library for OpenGL. It has lean API modeled after HTML5 canvas API. It is aimed to be a practical toolset for building scalable user interfaces and visualizations. NanoVG is embedded in a few Debian packages. Remark: This package is to be maintained with Debian Multimedia Maintainers at https://salsa.debian.org/multimedia-team/nanovg
Bug#1056241: dials autopkg tests fail with Python 3.12
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
Bug#1017811: node-wikibase-cli: FTBFS without Internet access
Hello, I have commented out a pair of test cases which attempted network access in the upload of node-wikibase-cli 15.15.4-5. Could you please check whether FTBFS continues? On Wed, 14 Dec 2022 12:16:39 +0100 Sven Mueller wrote: Interestingly, in our build environment which has some extremely limited network access, the package build fails before tests are even run: Linking /usr/bin/wb-set-label to /usr/share/nodejs/wikibase-cli/bin/wb-set-label Linking /usr/bin/wb-sparql to /usr/share/nodejs/wikibase-cli/bin/wb-sparql Linking /usr/bin/wb-summary to /usr/share/nodejs/wikibase-cli/bin/wb-summary Linking /usr/bin/wb-update-claim to /usr/share/nodejs/wikibase-cli/bin/wb-update-claim Linking /usr/bin/wb-update-qualifier to /usr/share/nodejs/wikibase-cli/bin/wb-update-qualifier Linking /usr/bin/wd to /usr/share/nodejs/wikibase-cli/bin/wd dh_installdocs -i dh_installchangelogs -i dh_installexamples -i debian/rules override_dh_installman make[1]: Entering directory '/<>' help2man wb --name 'command-line interface to Wikibase' --no-info > debian/wb.1 help2man: can't get `--help' info from wb Try `--no-discard-stderr' if option outputs to stderr make[1]: *** [debian/rules:10: override_dh_installman] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary-indep] Error 2 dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit status 2 I do not quite get this, AFAIK tests are run before dh_installman. Thus in your case tests pass, but override_dh_installman fails, right? Thanks, Andrius
Bug#992180: [Debichem-devel] Bug#992180: MR with fix available Re: openmm FTBFS on amd64/arm64/ppc64el
Hi Michael, On 2023-11-23 19:25, Michael R. Crusoe wrote: Hello, I opened the merge request below to add SIMDe to this package; I tested on the riscv64 porterbox where the build succeeded, included tests. Likewise on my personal amd64 laptop. https://salsa.debian.org/debichem-team/openmm/-/merge_requests/1 Thanks a lot for helping porting openmm to more architectures! I have merged your PR and uploaded openmm. It won't fix the FTBFS on armel / armhf; that's due to them being detected as arm64 and inappropriate NEON intrinsics being used Thanks for spotting this, I will give it a look, although I understand very little about vectorization. Best wishes, Andrius
Bug#992180: [Debichem-devel] Bug#992180: Bug#992180: MR with fix available Re: openmm FTBFS on amd64/arm64/ppc64el
Hi Michael,
On 2023-11-24 09:30, Andrius Merkys wrote:
On 2023-11-23 19:25, Michael R. Crusoe wrote:
It won't fix the FTBFS on armel / armhf; that's due to them being
detected as arm64 and inappropriate NEON intrinsics being used
Thanks for spotting this, I will give it a look, although I understand
very little about vectorization.
I successfully patched the build on armel by leaving NEON vectorization
for arm64 only:
--- a/libraries/vecmath/src/vecmath.cpp
+++ b/libraries/vecmath/src/vecmath.cpp
@@ -1,4 +1,4 @@
-#if defined(__ARM__) || defined(__ARM64__)
+#if defined(__ARM64__)
#include "neon_mathfun.h"
#else
#if !defined(__PNACL__)
--- a/openmmapi/include/openmm/internal/vectorize.h
+++ b/openmmapi/include/openmm/internal/vectorize.h
@@ -32,7 +32,7 @@
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*
*
--
*/
-#if defined(__ARM__) || defined(__ARM64__)
+#if defined(__ARM64__)
#include "vectorize_neon.h"
#elif defined(__PPC__)
#include "vectorize_ppc.h"
Build on armel succeeded, however, some tests segfault:
The following tests FAILED:
10 - TestReferenceCustomCentroidBondForce (SEGFAULT)
11 - TestReferenceCustomCompoundBondForce (SEGFAULT)
12 - TestReferenceCustomExternalForce (SEGFAULT)
13 - TestReferenceCustomGBForce (SEGFAULT)
15 - TestReferenceCustomIntegrator (SEGFAULT)
16 - TestReferenceCustomManyParticleForce (SEGFAULT)
17 - TestReferenceCustomNonbondedForce (Subprocess aborted)
18 - TestReferenceCustomTorsionForce (SEGFAULT)
69 - TestReferenceRpmd (Timeout)
110 - TestParser (SEGFAULT)
I gave TestParser a look with gdb:
(gdb) run
Starting program:
/home/merkys/openmm-8.0.0+dfsg/obj-arm-linux-gnueabi/TestParser
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
Lepton::CompiledExpression::generateTwoArgCall
(this=this@entry=0xbefff004, c=..., dest=..., arg1=..., arg2=...,
function=) at
./libraries/lepton/src/CompiledExpression.cpp:511
511 invoke->setArg(0, arg1);
(gdb) print arg1
$1 = (asmjit::_abi_1_9::arm::Vec &) @0x4186f8:
{ = { =
{ = { =
{_signature = {_bits = 0},
_baseId = 0, _data = {0, 0}}, }, fields>}, }, }
My wild guess is that asmjit is incompatible with armel/armhf as in
standalone asmjit (see #1049872). Building openmm without asmjit support
seems possible, I will try that.
Best,
Andrius
Bug#1057025: node-ip-address: please remove me from uploaders
Source: node-ip-address Severity: wishlist Hello, Back in a day I packaged/sponsored a bunch of node packages needed by node-shiny-server. I ended up never using shiny-server and/or node-shiny-server, but with the responsibility for its dependencies. Thus I would like to be removed from the uploaders of this package. Best, Andrius OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057024: node-client-sessions: please remove me from uploaders
Source: node-client-sessions Severity: wishlist Hello, Back in a day I packaged/sponsored a bunch of node packages needed by node-shiny-server. I ended up never using shiny-server and/or node-shiny-server, but with the responsibility for its dependencies. Thus I would like to be removed from the uploaders of this package. Best, Andrius OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057026: node-morgan: please remove me from uploaders
Source: node-morgan Severity: wishlist Hello, Back in a day I packaged/sponsored a bunch of node packages needed by node-shiny-server. I ended up never using shiny-server and/or node-shiny-server, but with the responsibility for its dependencies. Thus I would like to be removed from the uploaders of this package. Best, Andrius OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057027: node-pause: please remove me from uploaders
Source: node-pause Severity: wishlist Hello, Back in a day I packaged/sponsored a bunch of node packages needed by node-shiny-server. I ended up never using shiny-server and/or node-shiny-server, but with the responsibility for its dependencies. Thus I would like to be removed from the uploaders of this package. Best, Andrius OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057028: node-stable: please remove me from uploaders
Source: node-stable Severity: wishlist Hello, Back in a day I packaged/sponsored a bunch of node packages needed by node-shiny-server. I ended up never using shiny-server and/or node-shiny-server, but with the responsibility for its dependencies. Thus I would like to be removed from the uploaders of this package. Best, Andrius OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072115: ERROR:: Failure to read or parse /usr/share/coot/ui/coot-gtk4.ui
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
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#1072148: epics-base: please add support for loong64
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#1072148: epics-base: please add support for loong64
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
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#1072195: valgrind: add support for loong64
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#998820: lintian: overly generic python modules /usr/lib/python3/dist-packages/benchmarks/*.py
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#1072383: lintian: flag packages bloated by auxiliary tests/docs/examples
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#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
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#1072515: general: Repeating cracking sound in headphones when nothing is playing.
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#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
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#1072618: coot: layla fails to start unless LD_LIBRARY_PATH is specified
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#1072576: coot: save its states in HOME.
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#1072576: coot: save its states in HOME.
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#1057556: elpa: FTBFS: not enough slots available
Control: owner -1 ! On Fri, 31 May 2024 14:46:28 +0200 Santiago Vila wrote:> Instead of patch-2.txt and patch-3.txt, the following more simple patch would also fix the issue (I've tested it on single-cpu systems and also on m6a.large instances from AWS, which have 1 core and two threads). (Suggested by Drew Parsons in Bug#1071722, which is similar to this one). This an un-intrusive patch allowing elpa to be built even on single-vcore machines. I will apply it. (IMO the patch called patch-1.txt which I posted before should still be applied because it removes unnecessary complexity). Indeed. Thanks for caring for elpa. Andrius
Bug#1072576: coot: save its states in HOME.
Hi, On 2024-06-11 07:50, Paul Emsley wrote: OK, so 1.1.09 should now read and save the state and config files in an XDG Base Directory compliant manner. Thanks. I will update the Debian package ASAP. I have cleaned up some of the terminal output (it is verbose because doing so helps me diagnose other people start-up problems). I will see if I can put yet more output behind a "--debug" command line flag. Sounds good. Best, Andrius
Bug#1072576: coot: save its states in HOME.
On 2024-06-11 07:54, Paul Emsley wrote: I have been a bit sloppy with my file names and you should not be. Let's call the "refmac-dictionary" the "ccp4-monomer-library" OK, I will rename it to 'ccp4-monomer-library'. This is where it lives: https://github.com/MonomerLibrary/monomers Looking at coot's build-it-3-3, it seems that it downloads the monomer library from [1] from year 2016 while GitHub contains more recent releases. Will coot be able to use the newer monomer library? [1] http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/dependencies Andrius
Bug#1053729: RFP: SAIL image decoding library
Hi Sudip, On 2023-12-13 12:28, Sudip Mukherjee wrote: Hi Andrius, On Wed, Oct 18, 2023 at 08:38:52AM +0300, Andrius Merkys wrote: 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. 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. Just wanted to check if you are planning to package this. Its still a RFP so I guess not, but still want to confirm. If you are not packaging this then I can take it up. No, I am not planning to work on packaging SAIL anytime soon, so please go ahead. Thanks, Andrius
Bug#1058690: liblatex-tounicode-perl: trying to overwrite .../ltx2unitxt.1.gz, which is also in package texlive-bibtex-extra 2023.20231207-1
Control: tags -1 + patch Hello, On 2023-12-14 16:07, Vincent Lefevre wrote: Package: liblatex-tounicode-perl Version: 0.54-1 Severity: serious As a consequence of the upgrade of texlive-bibtex-extra to 2023.20231207-3: [...] Selecting previously unselected package liblatex-tounicode-perl. (Reading database ... 711147 files and directories currently installed.) Preparing to unpack .../00-liblatex-tounicode-perl_0.54-1_all.deb ... Unpacking liblatex-tounicode-perl (0.54-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-seikpl/00-liblatex-tounicode-perl_0.54-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/ltx2unitxt.1.gz', which is also in package texlive-bibtex-extra 2023.20231207-1 [...] It seems that the fix in bug 1058462 is incorrect or incomplete. I agree that this bug is due to the incomplete fix for #1058462. The offending files were removed from texlive-bibtex-extra, but Breaks+Replaces were not added to liblatex-tounicode-perl. Thus to complete the fix one should add the following to liblatex-tounicode-perl: Breaks: texlive-bibtex-extra (<< 2023.20231207-2) Replaces: texlive-bibtex-extra (<< 2023.20231207-2) Thanks, Andrius
Bug#1058722: scikit-build-core: please remove me from uploaders
Source: scikit-build-core Severity: wishlist Hello, Back in a day I thought scikit-build-core was a new build dependency of a package I maintained, thus I packaged it. Later it turned out that it was not necessary. Thus now I have no interest in scikit-build-core and would prefer to be removed from the uploaders. I know Emmanuel Arias is interested in scikit-build-core as well. Thus I know I am leaving this package in good hands :) Best, Andrius OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058723: python-parsley: run autopkgtest for all supported Python versions
Source: python-parsley Version: 1.3-3 Severity: wishlist Tags: help Hello, python-parsley builds for all supported Python versions. It seems only appropriate to run autopkgtest on all supported Python versions as well. However, currently it is run only on the default version: $ cat debian/tests/control Test-Command: python3 -m pytest Depends: python3-pytest, @, I would like to switch to 'Testsuite: autopkgtest-pkg-pybuild' and drop debian/tests/control altogether, but autopkgtest-pkg-pybuild does not work. I feel this might be due to unusual layout of test files, but I know too little about autopkgtest-pkg-pybuild to sort it out. Therefore I would like to get somebody's help. Thanks, Andrius
Bug#1058865: ITP: python-pubchempy -- pubchem python rest api chemistry cheminformatics
Hi Yogeswaran, On 2023-12-17 09:57, Yogeswaran Umasankar wrote: * Package name: python-pubchempy Version : 1.0.4 Upstream Contact: Matt Swain * URL :https://github.com/mcs07/PubChemPy * License : Expat Programming Lang: Python Description : pubchem python rest api chemistry cheminformatics I find this package interesting as well. You may turn to me whenever you need a sponsor for it. Best wishes, Andrius
Bug#1058868: [Debichem-devel] Bug#1058868: gemmi: Please build shared library
Control: tags -1 + moreinfo Hi Yadd, On 2023-12-17 11:31, Yadd wrote: Source: gemmi Version: 0.6.3+ds-1 Severity: important Tags: patch X-Debbugs-Cc: y...@debian.org Hi, 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 appreciate the idea and your patch, thanks for giving gemmi a look. However, I am hesitant to package gemmi shared library for Debian for now. The previous two releases had breaking API changes each. If upstream handles this properly and bumps the soversion, then this is fine, although having to undergo a transition twice a year is still quite some work. However, if the upstream does not maintain ABI stability inside the same soversion, then I would say the shared library is not yet ready for Debian. You have marked this bug as severity:important. Does this mean you need gemmi's shared library for some package? I never had the need to manually trigger the ldconfig before. The issue might be the lack of 'Section: libs' in binary package description. Thanks, Andrius
Bug#1058868: [Debichem-devel] Bug#1058868: gemmi: Please build shared library
Control: owner -1 ! Control: tags -1 - moreinfo Hi, On 2023-12-18 09:47, Yadd wrote: yas I'm going to package ovito which depends on it. If shared library isn't provided, cmake automatically uses libgemmi_cpp.a which then embed gemmi into ovito 🙁 I see. OK, let me apply your patch and build the shared library for gemmi, and let's see what happens. Best wishes, Andrius
Bug#1058868: [Debichem-devel] Bug#1058868: gemmi: Please build shared library
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
Bug#1010653: closed by Debian FTP Masters (reply to Komolehin Israel Timilehin ) (Bug#1010653: fixed in busco 5.5.0-2)
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#1010653: needs-internet restriction (Was: Bug#1010653: closed ...) (Bug#1010653: fixed in busco 5.5.0-2)
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#1056457: [Debichem-devel] Bug#1056457: python-ase's autopkg tests fail with Python 3.12
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#1059175: dials: FTBFS: Imported target "DXTBX::DXTBX" includes non-existent path
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&arch=amd64&ver=3.12.1%2Bdfsg3-5%2Bb2&stamp=1702954054&raw=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#1059706: epics-base.pc is broken in epics-dev package
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#1057644: multiple python versions in a single .deb package
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#1067212: ITP: libgraph-grammar-perl -- Grammar for graphs
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#1066296: RE: Bug#1066296: xli: FTBFS: dither.c:77:36: error: implicit declaration of function ‘strlen’ [-Werror=implicit-function-declaration]
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#943315: ITP: vst3sdk -- professional audio plugin development kit
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#1003512: closed by Debian FTP Masters (reply to Patrick Winnertz ) (Bug#1003512: fixed in cherrytree 1.1.0+dfsg-1)
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#1066450: opensearch: FTBFS with lucene9/9.10.0+dfsg
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#1068294: RFH: liboqs -- library for quantum-safe cryptographic algorithms
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#1068381: closed by Debian FTP Masters (reply to Andrius Merkys ) (Bug#1068381: fixed in openapi-specification 3.1.0-2)
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#1036769: lintian: Check for certificates .pem/.crt/.pkcs12 with expiry set
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#1035833: cpptraj: autopkgtest failure everywhere except on amd64
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#1071089: RM: cpptraj [arm64 armel armhf i386 mips64el ppc64el riscv64 s390x] -- ROM; FTBFS on non-amd64 archs
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#1071176: ITP: python-htmltools -- Tools for creating, manipulating, and writing HTML
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#1071207: ITP: r-cran-calculus -- High Dimensional Numerical and Symbolic Calculus
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#1035833: cpptraj: autopkgtest failure everywhere except on amd64
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#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS
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#1071573: ITP: libnet-ssl-expiredate-perl -- obtain expiration date of certificate
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#1071655: pytorch: FTBFS on ppc64el
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: Status of libnet-ssl-expiredate-perl
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#1059706: epics-base.pc is still broken
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
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#1069873: rdkit: FTBFS convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).
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#1039087: removing embeded version of yajl
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#1064311: rdkit: NMU diff for 64-bit time_t transition
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#1063124: libccp4: NMU diff for 64-bit time_t transition
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
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#1069873: rdkit: FTBFS convert: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb).
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#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates
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#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates
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#1064311: rdkit: NMU diff for 64-bit time_t transition
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#956194: streamlit status
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#1068925: 1068925: macromoleculebuilder should be limited to 64bit
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#1070275: RM: macromoleculebuilder [armhf] -- ROM; unsupported on 32bit archs
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#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"
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#1068626: libdwarf-dev: please provide CMake files
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#1068692: RFP: python-pycddl -- Deserialize CBOR and/or do CDDL schema validation
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#1068708: Building with EPICS fails because the compiler cannot find `compilerSpecific.h`.
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#1059706: epics-base.pc is still broken
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`.
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#1068925: [Debichem-devel] Bug#1068925: macromoleculebuilder: FTBFS on armhf (error: inconsistent deduction for auto return type: 'long int' and then 'long long int')
control: forwarded -1 https://simtk.org/tracker/?func=detail&group_id=359&atid=827&aid=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&arch=armhf&ver=4.0.0%2Bdfsg-3.1&stamp=1710492689&raw=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#1069098: emboss: all executables segfault on s390x
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#1069098: emboss: all executables segfault on s390x
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#1069142: emboss: build time testsuite is failing silently
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#1069142: emboss: build time testsuite is failing silently
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
