Bug#1063191: libcifpp-data: Incorrect URL in update-libcifpp-data script
Hi Andreas, The URL's were updated in upstream some time ago. The debian version of libcifpp (and all dependent tools) are a bit out of date. The problem I have is that development of libcifpp is a bit too fast. Whenever I break the ABI I have to ask for someone to upload a newer version. And last time this apparently did not went well and so the update stalled. I don't remember who I asked to update, but since that didn't happen I forgot about it. Anyway, so I had an upload ready for version 5.2 and libcifpp is now at version 6.1. I will thus have to prepare yet another update and then upload all depending packages. I'll see what I can do. regards, -maarten Op 13-02-2024 om 08:28 schreef Andreas Tille: Hi Maarten, since last September there is a new upstream version in Git which was not uploaded. I see less instances of ftp.wwpdb.org in this code but there are some remainings. It would be great if you could upload your preparation after checking that the bug below is fixed. Kind regards Andreas. Am Mon, Feb 05, 2024 at 11:27:36AM -0500 schrieb Rick Bernard: Package: libcifpp-data Version: 5.0.7.1-3 Severity: important Tags: patch Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing libcifpp-data via "apt install". The incorrect URL causes apt to hang for a long period of time before returrning to a prompt. As a result, the file supposed to be loaced in /var/cache/libcifpp/components.cif fails to download. The Stable version of this package was showing timeout errors when attempting to connect to https://ftp.wwpdb.org. The correct URL that is published by wwpdb.org is https://files.wwpdb.org for downloading via HTTP. This will happen durring install via apt when you are prompted Package configuration about setting up weekly downloads of these data files from wwpdb.org. * What exactly did you do (or not do) that was effective (or ineffective)? Editing the file /etc/cron.weekly/update-libcifpp-data and changing the URL for the components.cif download from https://ftp.wwpdb.org to https://files.wwpdb.org leaving all subpaths the same resolves the issue. This also helps with the stable version of this package and fixes dpkg and apt when running "dpkg --configure -a" * What was the outcome of this action? Resolves the package install and fixes apt/dpkg package management system. * What outcome did you expect instead? The expected outcome is that "apt install" will successfully install the package and be able to run the download scripts successfully. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-17-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcifpp-data depends on: ii debconf [debconf-2.0] 1.5.82 libcifpp-data recommends no packages. libcifpp-data suggests no packages. -- debconf information: * libcifpp/update: true --- update-libcifpp-data.orig 2024-02-05 11:13:15.964579981 -0500 +++ update-libcifpp-data2024-02-05 11:24:35.219320601 -0500 @@ -60,7 +60,7 @@ # Update the dictionaries -update_dictionary "/var/cache/libcifpp/components.cif" "https://ftp.wwpdb.org/pub/pdb/data/monomers/components.cif.gz; +update_dictionary "/var/cache/libcifpp/components.cif" "https://files.wwpdb.org/pub/pdb/data/monomers/components.cif.gz; update_dictionary "/var/cache/libcifpp/mmcif_pdbx.dic" "https://mmcif.wwpdb.org/dictionaries/ascii/mmcif_pdbx_v50.dic.gz; update_dictionary "/var/cache/libcifpp/mmcif_ma.dic" "https://github.com/ihmwg/ModelCIF/raw/master/dist/mmcif_ma.dic; ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#1050949: Acknowledgement (routine-update had my rules for lunch)
I'm sorry, I messed up. This report should not have been sent. I used a wrong version of routine-update. -maarten Op 31-08-2023 om 19:33 schreef Debian Bug Tracking System: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1050949: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050949. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Med Packaging Team If you wish to submit further information on this problem, please send it to 1050...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#1050949: routine-update had my rules for lunch
Package: routine-update Severity: important Dear Maintainer, For my debian package I used the wiki page on SphinxDocumentation as inspiration and added the following lines to my rules file: override_dh_auto_build: export http_proxy=127.0.0.1:9 override_dh_auto_build: export https_proxy=127.0.0.1:9 override_dh_auto_build: dh_auto_build The reason to do this is that I wanted to have the http_proxy set while still running the regular build (using cmake). My cmake setup builds the documentation and this avoids sphinx to try to fetch resources from the internet. However, running routine-update on this package removed the last two lines and the effect was that nothing was built anymore. Of course, the rules file is suboptimal, but simply removing the last two lines makes it worse. regards, -maarten -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025778: libnewuoa breaks libpdb-redo autopkgtest: pdb-redo-example (Failed)
ailure" to re-run the failed cases verbosely. autopkgtest [15:19:23]: test run-unit-test -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#1024893: libcifpp: Requesting transition slot
Source: libcifpp Severity: normal Dear Maintainer, libcifpp and libpdb-redo are both in experimental. I've prepared the packages depending on them and am now requesting a time slot to take the following transition steps. regards, -maarten hekkelman
Bug#1024622: ITP: libmcfp -- A header-only C++ argv and configuration parsing library
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libmcfp Version : 1.2.2 Upstream Author : Maarten L. Hekkelman * URL : http://github.com/mhekkel/libmcfp * License : BSD-2-Clause Programming Lang: C++ Description : A header-only C++ argv and configuration parsing library There are already a few configuration parser around, but most of them introduce runtime dependencies. This header-only library avoids that and add a simple to use and complete C++ API for accessing configuration passed through command line arguments or configuration files. The argv parsing is following the POSIX standard. All of the programs I've submitted to Debian before have switched from using boost::program_options to libcfp. Adding this library to Debian would ease packaging updates to these tools a lot. (Alternative is to include a copy of this lib to each and every tools separately). This library is intended to be maintained by the med-team. This ITP replaces the one from bug nr #1024144 which had a name conflict on other platforms.
Bug#1024144: ITP: libcfp -- A header-only C++ argv and configuration parsing library
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" X-Debbugs-Cc: debian-de...@lists.debian.org, maar...@hekkelman.com * Package name: libcfp Version : 1.2.0 Upstream Author : Maarten L. Hekkelman * URL : https://github.com/mhekkel/libcfp.git * License : BSD-2-Clause Programming Lang: C++ Description : A header-only C++ argv and configuration parsing library There are already a few configuration parser around, but most of them introduce runtime dependencies. This header-only library avoids that and add a simple to use and complete C++ API for accessing configuration passed through command line arguments or configuration files. The argv parsing is following the POSIX standard. All of the programs I've submitted to Debian before have switched from using boost::program_options to libcfp. Adding this library to Debian would ease packaging updates to these tools a lot. (Alternative is to include a copy of this lib to each and every tools separately).
Bug#989051: [Debian-med-packaging] Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI
Hi Étienne, Thank you very much for your reply. Luckily I found out the same route (using qemu) myself and fixed the problem All architectures are now green in tracker: https://buildd.debian.org/status/package.php?p=mrc regards, -maarten Op 12-09-2021 om 15:59 schreef Étienne Mollier: Hi Maarten, Maarten L. Hekkelman, on 2021-09-02: I found the underlying problem, apparently the ABI field of the ELF header should contain a flag indicating it is a Linux executable. In order to set this flag properly, I need to find out various things and perhaps it is easiest to try to figure out these myself. Is it possible to get access to a HPPA machine running Debian? I am a Debian maintainer, if that makes any difference. Without easy access to a PA-RISC machine, you can resort to Qemu. The Debian hppa port can be emulated using one of the emulators provided in the package qemu-system-misc. If you combine it with the package qemu-user-static (and also have Debian ports keyring at hand), then you can directly debootstrap a chroot able to run PA-RISC binaries: $ uname -m x86_64 $ sudo debootstrap \ --arch=hppa \ --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \ --include=debian-ports-archive-keyring \ sid sid-hppa-chroot http://ftp.ports.debian.org/debian-ports I: Target architecture can be executed [...] I: Base system installed successfully. $ sudo chroot sid-hppa-chroot uname -m parisc Otherwise, could you provide me the output of `cpp -dM /dev/null` and perhaps also how to detect PA-RISC/Debian in a cmake file. That last question is perhaps a bit too much to ask for, but any hint is appreciated. Feel free to checkout cpp_hppa.h in attachment; I obtained it with the aforementioned method. In hope this helps, Have a nice day, :) -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI
Dear Dave, Thanks for reporting, and apologies for not responding earlier. I found the underlying problem, apparently the ABI field of the ELF header should contain a flag indicating it is a Linux executable. In order to set this flag properly, I need to find out various things and perhaps it is easiest to try to figure out these myself. Is it possible to get access to a HPPA machine running Debian? I am a Debian maintainer, if that makes any difference. Otherwise, could you provide me the output of `cpp -dM /dev/null` and perhaps also how to detect PA-RISC/Debian in a cmake file. That last question is perhaps a bit too much to ask for, but any hint is appreciated. regards, -maarten Op 24-05-2021 om 20:09 schreef John David Anglin: Source: mrc Version: 1.2.3-2 Severity: normal Dear Maintainer, The build fails with the following error: make[1]: Entering directory '/<>' mrc.cpp dummy.cpp g++ -std=c++17 -o mrc-bootstrap obj/mrc.o obj/dummy.o -L/usr/lib/hppa-linux-gnu -lboost_program_options ./mrc-bootstrap -o obj/mrc_rsrc.o mrsrc.h g++ -std=c++17 -o mrc obj/mrc.o obj/mrc_rsrc.o -L/usr/lib/hppa-linux-gnu -lboost_program_options /usr/bin/ld: unknown architecture of input file `obj/mrc_rsrc.o' is incompatible with hppa1.1 output collect2: error: ld returned 1 exit status make[1]: *** [GNUmakefile:87: mrc] Error 1 As far as I can tell, this occurs because obj/mrc_rsrc.o is created with the wrong OS/ABI: dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc_rsrc.o obj/mrc_rsrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (SYSV), not stripped SYSV should be GNU/Linux: dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc.o obj/mrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (GNU/Linux), with debug_info, not stripped Not sure why this happens. Regards, Dave Anglin -- System Information: Debian Release: 11.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 5.10.39+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#987436: libcifpp: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Hi Adriano, Thanks very much -maarten Op 23-04-2021 om 21:41 schreef Adriano Rafael Gomes: Package: libcifpp Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#979314: libccp4: The endianness check in ccp4_sysdep.h is incorrect assuming powerpc is always big endian
Source: libccp4 Version: 6.5.1-4 Severity: grave Tags: patch upstream Justification: renders package unusable X-Debbugs-Cc: maar...@hekkelman.com -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.4.0-58-generic (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect The file ccp4_sysdep.h checks for the endianness in an incorrect way, the check assumes powerpc is always big endian. By moving the catch-all test up the test is more robust. regards, -maarten --- a/ccp4/ccp4_sysdep.h +++ b/ccp4/ccp4_sysdep.h @@ -177,6 +177,26 @@ #define DFNTF_CONVEXNATIVE 5/**< Convex native floats */ #define DFNTF_LEIEEE4 /**< little-endian IEEE format */ +/* From time to time new architectures are added here, often because Linux + * packagers want to build it on all platforms supported by their distro. + * Here we try to catch machines not listed explicitely above, under + * assumption that endianness is the same for floating point numbers + * as for integers. Which is safe assumption on modern standard computers + * (not embedded systems), according to + * http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness + */ +#if defined(__BYTE_ORDER) +# if __BYTE_ORDER == __LITTLE_ENDIAN +# define NATIVEIT DFNTI_IBO +# define NATIVEFT DFNTF_LEIEEE +# elif __BYTE_ORDER == __BIG_ENDIAN +# define NATIVEIT DFNTI_MBO +# define NATIVEFT DFNTF_BEIEEE +# endif +#endif + +#if !defined(NATIVEIT) && !defined(NATIVEFT) + #if defined (VAX) || defined (vax) /* gcc seems to use vax */ # define NATIVEFT DFNTF_VAX # define NATIVEIT DFNTI_IBO @@ -222,22 +242,6 @@ # endif #endif -/* From time to time new architectures are added here, often because Linux - * packagers want to build it on all platforms supported by their distro. - * Here we try to catch machines not listed explicitely above, under - * assumption that endianness is the same for floating point numbers - * as for integers. Which is safe assumption on modern standard computers - * (not embedded systems), according to - * http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness - */ -#if !defined(NATIVEIT) && !defined(NATIVEFT) && defined(__BYTE_ORDER) -# if __BYTE_ORDER == __LITTLE_ENDIAN -# define NATIVEIT DFNTI_IBO -# define NATIVEFT DFNTF_LEIEEE -# elif __BYTE_ORDER == __BIG_ENDIAN -# define NATIVEIT DFNTI_MBO -# define NATIVEFT DFNTF_BEIEEE -# endif #endif #ifndef NATIVEFT
Bug#976849: ITP: density-fitness -- Calculates per-residue electron density scores real-space R, real-space correlation coefficient, EDIAm, and OPIA
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: density-fitness Version : 1.0.0 Upstream Author : Maarten L. Hekkelman * URL : https://github.com/PDB-REDO/density-fitness * License : BSD-2-Clause Programming Lang: C++ Description : Calculates per-residue electron density scores real-space R, real-space correlation coefficient, EDIAm, and OPIA The program density-fitness calculates electron density metrics, for main- (includes Cβ atom) and side-chain atoms of individual residues. For this calculation, the program uses the structure model in either PDB or mmCIF format and the electron density from the 2mFo-DFc and mFo-DFc maps. If these maps are not readily available, the MTZ file and model can be used to calculate maps clipper. Density-fitness support both X-ray and electron diffraction data. This program is essentially a reimplementation of _edstats_, a program available from the CCP4 suite. However, the output now contains only the RSR, SRSR and RSCC fields as in _edstats_ with the addition of EDIAm and OPIA and no longer requires pre-calculated map coefficients. The software uses libpdb-redo, libcifpp and libzeep.
Bug#976727: ITP: libpdb-redo -- Library containing shared code for the various programs in project PDB-REDO
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: libpdb-redo Version : 1.0.0 Upstream Author : Maarten L. Hekkelman * URL : https://github.com/PDB-REDO/libpdb-redo * License : BSD-2-Clause Programming Lang: C++ Description : Library containing shared code for the various programs in project PDB-REDO For the PDB-REDO project, a lot of programs have been created over time. Many of these application share common routines and these are combined in this particular library. The PDB-REDO tools that are of general interest will follow as separate Debian packages. About PDB-REDO: PDB-REDO is a procedure to optimise crystallographic structure models, providing algorithms that make a fully automated decision making system for refinement, rebuilding and validation. It combines popular crystallographic software from CCP4, e.g. REFMAC and COOT, with with our specially developed rebuilding tools Centrifuge, Pepflip & SideAide and structure analysis tools like WHAT IF and PDB-care. PDB-REDO optimises refinement settings (e.g. geometric and B-factor restraint weights, B-factor model, TLS groups, NCS and homology restraints), refines with REFMAC, partially rebuilds the structure (rejects waters, refines side chains, checks peptide planes), refines some more, and then validates the results. With PDB-REDO you can obtain updated and optimised versions of existing entries of the PDB from our DataBank, or you can optimise your own structure model using our Server. If you want to know more or install PDB-REDO on your own computers, please check below.
Bug#976627: libcifpp: [INTL:de] initial German debconf translation
Thank Helge, I've placed the file where it is supposed to be, will be included at the next check-in. regards, -maarten Op 06-12-2020 om 05:49 schreef Helge Kreutzmann: Package: libcifpp Version: 1.0.0-3 Severity: wishlist Tags: patch l10n Please find the initial German debconf translation for libcifpp attached. Please place this file in debian/po/ as de.po for your next upload. If you update your template, please use 'msgfmt --statistics ' to check the po-files for fuzzy or untranslated strings. If there are such strings, please contact me so I can update the German translation. Greetings Helge
Bug#976272: ITP: libnewuoa-cpp -- C++ implementation of the NEWUOA algorithm
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: libnewuoa-cpp Version : 0.1.0 Upstream Author : Roman Siromakha * URL : https://github.com/elsid/newuoa-cpp * License : MIT Programming Lang: C++ Description : C++ implementation of the NEWUOA algorithm This library contains the C++ implementation of the NEWUOA derivative free optmization algorithm originally published by Michael J. D. Powell.
Bug#975691: ITP: tortoize -- Application to calculate ramachandran z-scores.
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: tortoize Version : 2.0.0 Upstream Author : Maarten L. Hekkelman * URL : http://github.com/PDB-REDO/tortoize * License : BSD-2-Clause Programming Lang: C++ Description : Application to calculate ramachandran z-scores. Tortoize validates protein structure models by checking the Ramachandran plot and side-chain rotamer distributions. Quality Z-scores are given at the residue level and at the model level (ramachandran-z and torsions-z). Higher scores are better. To compare models or to describe the reliability of the model Z-scores jackknife- based standard deviations are also reported (ramachandran-jackknife-sd and torsion-jackknife-sd). This application depends on libcifpp and libzeep.
Bug#975526: ITP: cif-tools -- Suite of tools to manipulate, validate and query mmCIF files
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: cif-tools Version : 1.0.0 Upstream Author : Maarten L. Hekkelman * URL : http://github.com/PDB-REDO/cif-tools * License : BSD-2-Clause Programming Lang: C++ Description : Suite of tools to manipulate, validate and query mmCIF files This package contains a suite of tools for the manipulation of mmCIF files. The structure of macro molecules is nowadays recorded in mmCIF files. Until recently however the ancient PDB file format was used by many programs but that format has since long been deprecated. This package provides two tools, pdb2cif and cif2pdb, that can convert files from one format into the other, provided that data fits of course. Other tools are cif-validate, cif-grep, cif-diff, cif-merge and mmCQL. The latter can be used to manipulate an mmCIF file as if it were a SQL like database using SELECT, UPDATE, INSERT and DELETE commands. This package depends on libcifpp.
Bug#975446: libzeep: FTBFS against boost_1.74
Hi Anton, Previous versions of libboost-tools-dev used to install a file called boost-build.jam in /usr/share/boost-build. Version 1.74 however no longer does this. Is this a permanent change? In the previous setup one could simply use bjam to build but with version 1.74 this no longer works. So before I change my build scripts, I'd like to know if the omission of /usr/share/boost-build/boost-build.jam is an error or was intended to be dropped. regards, -maarten Op 22-11-2020 om 21:43 schreef Anton Gladky: Hi Marteen, there are really some misunderstandings with version numbers. Anyway, I have just tried to build 5.0.2-3 and it still fails to build: mkdir -p obj cd doc; /usr/bin/bjam /bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX --mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -I/usr/include -Wall -Wno-multichar -I include -O3 -DNDEBUG -MT obj/connection.lo -MD -MP -MF obj/connection.d -c -o obj/connection.lo lib-http/src/connection.cpp /bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX --mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -I/usr/include -Wall -Wno-multichar -I include -O3 -DNDEBUG -MT obj/controller.lo -MD -MP -MF obj/controller.d -c -o obj/controller.lo lib-http/src/controller.cpp /bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX --mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -I/usr/include -Wall -Wno-multichar -I include -O3 -DNDEBUG -MT obj/controller-rsrc.lo -MD -MP -MF obj/controller-rsrc.d -c -o obj/controller-rsrc.lo lib-http/src/controller-rsrc.cpp Unable to load B2: could not find 'boost-build.jam' --- Attempted search from '/root/mod2/libzeep-5.0.2/doc' up to the root at '/usr/bin/b2' Please consult the documentation at 'https://boostorg.github.io/build/'. Could you please have a look? Thanks Anton Am So., 22. Nov. 2020 um 21:22 Uhr schrieb Maarten L. Hekkelman : Hi, The bug report is for libzeep version 5, but the logs show that an attempt was made to compile version 3. I'm quite sure that building libzeep version 5 with boost 1.74 will succeed, since I've been using it myself for several weeks now. regards, -maarten Op 22-11-2020 om 13:28 schreef Anton Gladky: Package: libzeep Version: 5.0.2-3 Severity: important Tags: ftbfs User: team+bo...@tracker.debian.org Usertags: boost174 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, it was discovered that your package failed to build against boost_1.74. Logs can be found here [1]. Most relevant part is probably this: dpkg-source: info: using options from libzeep-3.0.5/debian/source/options: --extend-diff-ignore=(^|/)(.vscode/.*|msvc|\.gitignore|\.travis\.yml|tests|zeep-test.*|webapp-test.cpp|doc/bin)$ fakeroot debian/rules clean dh clean dh_auto_clean make -j4 clean make[1]: Entering directory '/<>' rm -rf obj/* libzeep.a libzeep.so* zeep-test libzeep-3.0.5 libzeep-3.0.5.tgz cd doc; bjam clean Unable to load B2: could not find 'boost-build.jam' - --- Attempted search from '/<>/doc' up to the root at '/usr/bin/b2' Please consult the documentation at 'https://boostorg.github.io/build/'. make[1]: *** [makefile:122: clean] Error 1 make[1]: Leaving directory '/<>' dh_auto_clean: error: make -j4 clean returned exit code 2 make: *** [debian/rules:8: clean] Error 25 It is planned to push boost_1.74 as the default version in Debian/Bullseye. [1] http://qa-logs.debian.net/2020/10/27-boost/boost/libzeep_3.0.5-2_unstable_boost.log Best regards Anton - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+6WXURHGdsYWRrQGRl Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXFQ/6AobGTBmLGOayKBafvfY7JKMuOvQUt/CN 3x0Q1q9JKT3PrAiDupOILvGpU7kLVwXm+Xj7Y6jmOFmQXAIiejQINB5S3SMm3OW/ GJb2MkcbeAr/1gKnoRiXWGauFjBXT+RfHwKCB0qCRxaCcgd6wqN/sur9LiK1o9Jb yAxYOhsAuqU3zrmGbJ6H9WGzRsOAFjhWRDu9vvq9+XWwhCZ1msETk8J+ube6dI3G uYpkUgEUxf6dSLYAFki2vKtSX6TonmFwJ9Zn3uMer1OlTwOPGFfeKFP+Hvgd+Fx5 lwbGAh6RkoxM+9a+q+MSnIyhVoqMSYKWGbazen1SbJiQSR2tf8INYpryjd9wTYbK aFlazYitywFTlq4I9cu+vDuHzLP6/rV480+v
Bug#975446: libzeep: FTBFS against boost_1.74
Hi, The bug report is for libzeep version 5, but the logs show that an attempt was made to compile version 3. I'm quite sure that building libzeep version 5 with boost 1.74 will succeed, since I've been using it myself for several weeks now. regards, -maarten Op 22-11-2020 om 13:28 schreef Anton Gladky: Package: libzeep Version: 5.0.2-3 Severity: important Tags: ftbfs User: team+bo...@tracker.debian.org Usertags: boost174 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, it was discovered that your package failed to build against boost_1.74. Logs can be found here [1]. Most relevant part is probably this: dpkg-source: info: using options from libzeep-3.0.5/debian/source/options: --extend-diff-ignore=(^|/)(.vscode/.*|msvc|\.gitignore|\.travis\.yml|tests|zeep-test.*|webapp-test.cpp|doc/bin)$ fakeroot debian/rules clean dh clean dh_auto_clean make -j4 clean make[1]: Entering directory '/<>' rm -rf obj/* libzeep.a libzeep.so* zeep-test libzeep-3.0.5 libzeep-3.0.5.tgz cd doc; bjam clean Unable to load B2: could not find 'boost-build.jam' - --- Attempted search from '/<>/doc' up to the root at '/usr/bin/b2' Please consult the documentation at 'https://boostorg.github.io/build/'. make[1]: *** [makefile:122: clean] Error 1 make[1]: Leaving directory '/<>' dh_auto_clean: error: make -j4 clean returned exit code 2 make: *** [debian/rules:8: clean] Error 25 It is planned to push boost_1.74 as the default version in Debian/Bullseye. [1] http://qa-logs.debian.net/2020/10/27-boost/boost/libzeep_3.0.5-2_unstable_boost.log Best regards Anton - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+6WXURHGdsYWRrQGRl Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXFQ/6AobGTBmLGOayKBafvfY7JKMuOvQUt/CN 3x0Q1q9JKT3PrAiDupOILvGpU7kLVwXm+Xj7Y6jmOFmQXAIiejQINB5S3SMm3OW/ GJb2MkcbeAr/1gKnoRiXWGauFjBXT+RfHwKCB0qCRxaCcgd6wqN/sur9LiK1o9Jb yAxYOhsAuqU3zrmGbJ6H9WGzRsOAFjhWRDu9vvq9+XWwhCZ1msETk8J+ube6dI3G uYpkUgEUxf6dSLYAFki2vKtSX6TonmFwJ9Zn3uMer1OlTwOPGFfeKFP+Hvgd+Fx5 lwbGAh6RkoxM+9a+q+MSnIyhVoqMSYKWGbazen1SbJiQSR2tf8INYpryjd9wTYbK aFlazYitywFTlq4I9cu+vDuHzLP6/rV480+v6ZRKgNLO8ciNu3i/vB/a8G23cdAu Bite4zw/29R5ekDUIvZcLLUSTVYfArKd1gMeRbVQFx9Y/AcFBC1/eZwqeiQFKmZv c1PwFhB9bl54jDqS/mb7c85uhzt2LEbEeLrzo69TaUxjo1/1vQCvZa2FMn5uZgBF aQwH4QSlL8Qh1zd3DW6DpQUzC4hg9TWFH/xIulFfuS46i2vD6UUDZYO/lBsw9Bod a5Sgqn6aeKSZs2StgSOf8HFF067rSOYbC3oaDO9/7xBmNe8FHjYLV27mFr6+Sotu OObqY7WdDP4= =ljID -END PGP SIGNATURE----- -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#974973: ITP: libcifpp -- A library for creating and manipulating mmCIF and PDB files containing macro molecular structure information
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: libcifpp Version : 1.0.0 Upstream Author : Maarten L. Hekkelman * URL : http://github.com/PDB-REDO/libcifpp * License : BSD-2-Clause Programming Lang: C++ Description : A library for creating and manipulating mmCIF and PDB files containing macro molecular structure information The structure of macro molecules is nowadays recorded in mmCIF files. Until recently however the ancient PDB file format was used by many programs but that format has since long been deprecated. This library contains code to read and write mmCIF files. It also contains validating code to check the integrity and validity of mmCIF files. As a bonus, this library is capable of importing and exporting PDB files which is not trivial. The code greatly benefits from the CCP4 distribution being available, but does not require it to work. The current DSSP in Debian needs to be replaced with a new version soon, this new version of DSSP will require libcifpp. The Debian Med team will take care of maintenance.
Bug#974895: ftp.debian.org: MRS should be updated to support the new libzeep library
Package: ftp.debian.org Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) MRS is an information retrieval system, used to index terabytes of text based databanks on a single machine. Mostly used in the medical and biological world. The version of MRS in currently in Debian is based on libzeep version 3. Libzeep was in fact a spin off project from MRS. I stopped development of MRS in 2012 when I switched to a new employer but I took libzeep with me. Since then, libzeep has evolved and changed a lot and now compatibility with MRS is broken. I've submitted the new version of libzeep into debian (it is currently in unstable) but now MRS no longer builds and so I request to remove it from Debian until it is updated. regards, -maarten
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
Hi Juhani, Bug #974074 is in fact a bug in MRS. However, the bug report does contain a useful observation, the usage of the various override_dh_auto_configure rules in libzeep is incorrect and no shared library is created. Now the question is, is a shared library really required? If so I will have to go back to the drawing board and redesign the makefiles in the upstream project to create proper shared libraries, including a version numbering scheme. regards, -maarten Op 11-11-2020 om 09:13 schreef Juhani Numminen: On Tue, 10 Nov 2020 23:03:57 +0100 Sebastian Ramacher wrote: Hi Marten On 2020-11-10 07:42:45 +0100, Maarten L. Hekkelman wrote: ... Sorry, long story. To make it short. - Keep mrc, no problem there - Upgrade libzeep to version 5 Thanks for the detailed explanation. The first two steps are almost done The current versions of mrc and libzeep should be able to migrate soon as their RC bugs have been fixed. ... Right, but one RC bug is not fixed yet: libzeep packages are missing the shared library altogether; the .so files are not there. For that we have bug #974074, and see gregor's message for suggested fix. It seems he is confident in the first diff of that mail, while the latter diff is more speculative. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974074#19 Regards, Juhani -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http://www.hekkelman.com/ +31 24 348 0192
Bug#973526: FTBFS due to SIGABRT while running HTTP server tests, bug #973526
Op 10-11-2020 om 16:21 schreef Andrey Rahmatullin: Running 7 test cases... started daemon at port 5923 terminate called after throwing an instance of 'boost::wrapexcept' what(): resolve: Host not found (authoritative) Looks like it tries to resolve something, and that usually implies Internet access, as otherwise you could just connect to localhost? Accessing the Internet is forbidden during building. The test case tried to resolve "127.0.0.1" as host. I've changed that to "localhost" since adding a flag for boost to only interpret the value as numeric is not easy to add to the code. I've seen hosts where localhost is mapped to some other IP address in the range 127.0.0.0/255 Could this be the case on the particular build machine where the test failed? Anyway, I assume that using localhost will be sufficient to fix this problem. We'll see that shorly. regards, -maarten
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
Hi Andreas, To avoid confusion, we're talking about three tools here: libzeep, mrc and mrs. mrc is a simple resource compiler, is now compatible and bug free, builds on all architectures and should be kept. I believe it is very useful, using it I can create downloadable, portable applications that need additional static data without the need for installer scripts. libzeep version 5 is the latest incarnation of a library I've been working on for 12 years now. It has evolved into a toolbox to build web applications in C++ inspired by the popular Java Spring framework and Thymeleaf template processor. It also contains a full XML and a JSON library. Using this library I could e.g. convert a pipeline to process genomics data into an interactive web application, the python scripts took up to 4 hours for each run, now you can do the same analysis in less than 5 seconds. I have a couple of applications based on libzeep that I would like to add to Debian, most of them tools used in crystallography and genomics research. But also a content management system. And then we have MRS. This is a retrieval system, a web application capable of indexing and then searching terabytes of text based databanks on a single machine. Mostly used in the medical and biological world. It is used e.g. on mini computers that are sent into Africa where internet access is limited, that way large databanks like EMBL are still available. But I stopped development in 2012 when I switched jobs. I continued development of libzeep on which MRS is based but someone else took over development of MRS. A year ago I did a consultancy job fixing MRS which basically came down to reverting most of the attempted 'improvements' after I left. Currently I'm working at the Netherlands Cancer Institute, here I write both software used in crystallography as well as a genomics analysis tool. Many of the crystallographic tools are moving into open source right now. We would have liked to include those in the CCP4 distribution, but unfortunately my code is way too new (C++17) to work in that environment. Next to that we would like to include our tools in Debian (DSSP already is, but that application needs an update), but if that won't work, I will set up a private repository to distribute our binaries. I know libzeep is not very popular, that's because I never bothered much to find an audience. But I can't live without it myself, a lot of my tools are based on it one way or another. Libzeep is also quite mature and has been used in many tools in a production environment for many years now. Sorry, long story. To make it short. - Keep mrc, no problem there - Upgrade libzeep to version 5 - Kick out mrs until it is upgraded to use libzeep 5 regards, -maarten Op 09-11-2020 om 20:49 schreef Andreas Tille: Hi Maarten, On Mon, Nov 09, 2020 at 07:22:30PM +0100, Maarten L. Hekkelman wrote: I'm sorry, but mrs as it is currently in Debian is not compatible with libzeep version 5. It needs a major rewrite. Libzeep is a spin off project of mrs and has evolved a lot since then. So either libzeep should be kept at version 3 or mrs should be removed. If mrs and libzeep are kept, I will not be able to release my other tools based on libzeep in Debian. You are the Uploader and the only competent person to decide. If I understood the issue correctly it came up right after mrc was added to the Build-Depends. Wouldn't it be an option to just de-couple both again. Upgrading mrs is of course the best option, but I won't have time to do that soon. So please draw a sensible decision. Libzeep was according to popcon[1] never installed by more than 10 users - currently the vote (active users) is at zero. Feel free to decided what *you* personally love to see in Debian (but decreasing a version number is usually not nice). Kind regards Andreas. [1] https://qa.debian.org/popcon.php?package=libzeep regards, -maarten Op 09-11-2020 om 16:19 schreef Niko Tyni: On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote: Source: mrs Version: 6.0.5+dfsg-8 Severity: serious Tags: ftbfs sid Justification: fails to build from source (but built successfully in the past) | Checking for libzeep...libzeep is not installed, either install the package libzeep-dev | or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep | and run configure again. | make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2 Looks to me like libzeep-dev is broken because the build doesn't pass --enable-shared to ./configure. Probably the override_dh_auto_configure-arch and override_dh_auto_configure-indep targets in src:libzeep debian/rules are not effective because of the earlier override_dh_auto_configure target. But I didn't actually test any of this. Hope this helps, -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http://www.hekkelman.com/ -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http
Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"
I'm sorry, but mrs as it is currently in Debian is not compatible with libzeep version 5. It needs a major rewrite. Libzeep is a spin off project of mrs and has evolved a lot since then. So either libzeep should be kept at version 3 or mrs should be removed. If mrs and libzeep are kept, I will not be able to release my other tools based on libzeep in Debian. Upgrading mrs is of course the best option, but I won't have time to do that soon. regards, -maarten Op 09-11-2020 om 16:19 schreef Niko Tyni: On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote: Source: mrs Version: 6.0.5+dfsg-8 Severity: serious Tags: ftbfs sid Justification: fails to build from source (but built successfully in the past) | Checking for libzeep...libzeep is not installed, either install the package libzeep-dev | or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep | and run configure again. | make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2 Looks to me like libzeep-dev is broken because the build doesn't pass --enable-shared to ./configure. Probably the override_dh_auto_configure-arch and override_dh_auto_configure-indep targets in src:libzeep debian/rules are not effective because of the earlier override_dh_auto_configure target. But I didn't actually test any of this. Hope this helps, -- Maarten L. Hekkelman Cataloniëstraat 3 6663NJ Lent http://www.hekkelman.com/
Bug#970087: ITP: mrc -- resource compiler to store data in ELF object files
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: mrc Version : 1.2.2 Upstream Author : Maarten L. Hekkelman * URL : http://github.com/mhekkel/mrc * License : BSD-2-Clause-FreeBSD Programming Lang: C++ Description : resource compiler to store data in ELF object files Many applications come with supplementary data. This data is usually stored on disk as regular files. The disadvantage of this procedure is that an application cannot simply be copied to another location or computer and expected to function properly. Resources are a way to overcome this problem by including all data inside the executable file. The mrc resource compiler can create object files containing both the data and an index. This data can then be accessed from within an application using C++ classes. A header file to include in your C++ application is provided. As a resource in mrc of course. I'm the author of libzeep, a C++ based web application framework and in combination with mrc I can create web based application with a C++ backend, all combined in a single executable that's easily distributable. Libzeep is already sponsored by the Med team.
Bug#712679: ITP: mrs -- Complete Information Retrieval System for Biomedical databanks
Package: wnpp Severity: wishlist Owner: Maarten L. Hekkelman m.hekkel...@cmbi.ru.nl * Package name: mrs Version : 6.0.1 Upstream Author : Maarten L. Hekkelman * URL : http://mrs.cmbi.ru.nl/ * License : Boost Programming Lang: C++, Perl, JavaScript Description : Complete Information Retrieval System for Biomedical databanks MRS which stands for Maartens Retrieval System is a complete information retrieval system. It comes with all the code necessary to keep a set of biological or medial text databanks up-to-date and indexed, allows for fast full text searches and can even provide Blast compatible protein searches. Data can be accessed using the builtin web application or via webservices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671481: ITP: libzeep -- A C++ library providing a validating XML parser, XML DOM tree implement
Package: wnpp Severity: wishlist Owner: Maarten L. Hekkelman maar...@cmbi.ru.nl * Package name: libzeep Version : 2.9.0 Upstream Author : Maarten L. Hekkelman m.hekkel...@cmbi.ru.nl * URL : http://www.cmbi.ru.nl/libzeep * License : Boost-1.0 Programming Lang: C++ Description : A C++ library providing a validating XML parser, XML DOM tree implementation, XPath 1.0 support and code to create SOAP/REST servers as well as a full web application framework. libzeep was originally designed to create SOAP servers in C++ easily. The current incarnation provides a full validating XML parser creating a DOM tree that can be iterated using STL container like methods. The tree can be searched using XPath 1.0 queries. . There's also code to create SOAP and REST servers based allowing to export C++ methods as web services. And there's a full web application framework to create dynamic web sites in C++ and XHTML. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609541: ITP: libzeep -- XML Library for SOAP servers written in C++
Package: wnpp Severity: wishlist Owner: Maarten L. Hekkelman m.hekkel...@cmbi.ru.nl * Package name: libzeep Version : 2.0.1 Upstream Author : Maarten L. Hekkelman m.hekkel...@cmbi.ru.nl * URL : http://www.cmbi.ru.nl/libzeep/ * License : Boost Programming Lang: C++ Description : XML Library for SOAP servers written in C++ libzeep is an XML library that can be used to create a full SOAP server in C++. Code is generated by the compiler based on the signature of the methods that are exported as SOAP service. Makes heavy use of boost libraries. This library also contains a full validating XML parser and an XPath implementation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
