Redefinition of _Int (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
H again,
Am Sun, Apr 14, 2024 at 07:17:41AM +0200 schrieb Andreas Tille:
> Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
> >
> > The one after this looks like a GTK problem, and that's the point at
> > which I bow out.
I was able to fix some more missing declaration issues (which luckily did
not were connected to GTK) but I'm now stumbling upon:
...
In file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: note: in expansion of macro '_Int'
36 | typedef enum { _Int, _Text, _Float, _DateType, _Key, _Tag } AceType;
|^~~~
...
which is caused by whooks/systags.h[2]
...
#define _Int 24
#define _Unsigned 25
#define _Long 26 /* not supported */
#define _Long_Unsigned 27 /* not supported */
#define _Float 28
...
Is there any trick I could use here instead of replacing these
definitions by something else like _Int_acedb or so globally to get this
build by modern compilers?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/acedb/-/jobs/5586407#L1893
[2]
https://salsa.debian.org/med-team/acedb/-/blob/master/whooks/systags.h?ref_type=heads#L57-61
--
https://fam-tille.de
Re: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
Hi Jeremy, Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden: > > The one after this looks like a GTK problem, and that's the point at > which I bow out. Thanks a lot for your help so far. Your patches are pushed to Git. Kind regards Andreas. -- https://fam-tille.de
cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
Control: tags -1 help thanks Hi, while I was able to fix the origininal cause of the failure I'm now blocked by some issue that cython seems to miss adding some #include but I have no idea how to accomplish this. The Salsa CI build log[1] says: ... y.tab.c: In function 'yyparse': y.tab.c:1409:16: error: implicit declaration of function 'yylex' [-Werror=implicit-function-declaration] y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you mean 'YYerror'? [-Werror=implicit-function-declaration] In file included from aqlparse.y:335: aqlparse.l: In function 'yylex': ... Any help would be welcome Andreas. [1] https://salsa.debian.org/med-team/acedb/-/jobs/5580840 -- https://fam-tille.de
Re: Help with catch2 transition needed
Am Tue, Nov 07, 2023 at 01:55:49PM - schrieb Sune Vuorela: > target_link_libraries(test PRIVATE Catch2::Catch2WithMain) Thanks a lot. This was exactly the hint I needed. Kind regards Andreas. -- http://fam-tille.de
Re: Help with catch2 transition needed
Hi Petr, Am Tue, Nov 07, 2023 at 02:41:00PM +0100 schrieb Petr Kubánek: > catch2 is a bit complicated story. Look on GitHub, unfortunately catch2 v2.x > changed headers, just for catch2 v3.x to change it back. Best is to use catch2 > v3.x, but that comes with a static library you need to link ASIK. As you can see in the build log on Salsa[2] catch2 3.4.0-1 is used - just the version that is in unstable. Do you want to tell me that I need to add some extra library in the linker command line (via test/CMakeLists.txt) and if yes which library is this? Kind regards Andreas. > Dne 7. 11. 2023 14:18 napsal uživatel Andreas Tille : > > > Hi, > > as per bug #1054707 libodsstream failed to build from source due to > > /<>/test/test_ods.cpp:3:10: fatal error: catch2/catch.hpp: No > such file or directory > 3 | #include >| ^~ > compilation terminated. > > I noticed that catch2 does not contain the header file catch.hpp any > more. There is now some catch_all.hpp. So I replaced this header file > in a patch[1] but obviously this problem can't be solved by pure wild > guessing since this has lead to > >/usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/ > Scrt1.o: in function `_start': > (.text+0x17): undefined reference to `main' > > and my manually added main() function (also in patch[2]) did not > enhanced the situation much since its now running into linker errors[2]. > > Any hint how to fix this catch2 issue properly would be welcome > Andreas. > > > [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/ > debian/patches/new_catch2_usage.patch > [2] https://salsa.debian.org/debichem-team/libodsstream/-/jobs/4898134 > > > -- > http://fam-tille.de > > > -- http://fam-tille.de
Help with catch2 transition needed
Hi, as per bug #1054707 libodsstream failed to build from source due to /<>/test/test_ods.cpp:3:10: fatal error: catch2/catch.hpp: No such file or directory 3 | #include | ^~ compilation terminated. I noticed that catch2 does not contain the header file catch.hpp any more. There is now some catch_all.hpp. So I replaced this header file in a patch[1] but obviously this problem can't be solved by pure wild guessing since this has lead to /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x17): undefined reference to `main' and my manually added main() function (also in patch[2]) did not enhanced the situation much since its now running into linker errors[2]. Any hint how to fix this catch2 issue properly would be welcome Andreas. [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/patches/new_catch2_usage.patch [2] https://salsa.debian.org/debichem-team/libodsstream/-/jobs/4898134 -- http://fam-tille.de
Re: pbuilder root seems to lack support for usrmerge when doing autopkgtest
Hi Gregor, Am Tue, Sep 19, 2023 at 04:53:52PM +0200 schrieb gregor herrmann: > That's from apt: > > apt (2.7.4) unstable; urgency=medium > … > * Only accept installs of usrmerge on unmerged-usr systems. > As of bookworm, merged-usr is mandatory, and people got caught > in the crosshairs of the dpkg fsys-unmessusr debacle and inadvertently > reverted back to an unmerged configuration and continue to remain > on an unsupported system unknowingly. OK. > Looks like your chroot is not /usr-merged; no idea why installing the usrmerge > package didn't and doesn't change it. > > > Do you have any hints? If not, what further information should I > > provide? (logs etc?) > > Just for comparison my (unstable) chroot looks /usr-merged: > > % ll /var/cache/pbuilder/base.cow > lrwxrwxrwx 2 root root7 Sep 18 2022 bin -> usr/bin > … I confirm that /var/cache/pbuilder/base.cow/bin was no symlink but just the old /bin dir. > Maybe try to login in: > cowbuilder --login --save-after-login [--basepath /some/where] > and reconfigure usrmerge, or something? I did so and usrmerge was installed but somehow it seems it was not doing its job. I simply created a new chroot via sudo cowbuilder --create and it works now. So may be this thread is simply some warning that usrmerge might fail. Kind regards Andreas. -- http://fam-tille.de
pbuilder root seems to lack support for usrmerge when doing autopkgtest
Hi, I configured pbuilder (Uploaders in CC) to run autopkgtest after a successful build. This worked nicely until yesterday (at least - may be a couple of days before but I did not noticed). Since yesterday I get: E: /bin resolved to a different inode than /usr/bin E: Unmerged usr is no longer supported, install usrmerge to continue. autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs The test itself runs in Salsa CI - so the package itself is not broken. I'm actually using cowbuilder - but I naively assume this is not relevant. I tried to fix this with diff --git a/pbuilderrc b/pbuilderrc index d796fd8..9176073 100644 --- a/pbuilderrc +++ b/pbuilderrc @@ -11,6 +11,6 @@ OTHERMIRROR="deb [trusted=yes] file:///var/cache/pbuilder/extra/release ./" BINDMOUNTS="/dev/shm /var/cache/pbuilder/extra/release" HOOKDIR=/var/cache/pbuilder/hooks # this is necessary for running ''apt-ftparchive'' in the hook below -EXTRAPACKAGES="apt-utils" +EXTRAPACKAGES="apt-utils usrmerge" in /etc but with no change. According to the log the package usrmerge is really installed in the pbuilder chroot. Do you have any hints? If not, what further information should I provide? (logs etc?) Kind regards Andreas. -- http://fam-tille.de
Help needed for libssl ABI change
Hi, I'm trying to build libucsc which fails to build[1]. I suspect this is due to an ABI change in libssl 1.1 to 3.x. Any help how to fix this would be really apreciated. Kind regards Andreas. [1] https://salsa.debian.org/med-team/libucsc/-/pipelines/579427 -- http://fam-tille.de
Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets
Hi Bo, Am Fri, Jul 21, 2023 at 12:29:24AM +0800 schrieb Bo YU: > > [1]: https://med-team.pages.debian.net/policy/ > > > > If you agree to it, please feel free to proceed, git easily > > I have read the policy and accepted it. :-) > > Sounds good, let us know once you pushed your modification. > > I have updated it here: > https://salsa.debian.org/med-team/spades > > The only thing this is uncertain about is whether the distribution > should be UNRELEASE or unstable UNRELEASED (mind the 'D' at end - probably a typo in your mail since the commit was correct. Just mentioning it for other readers.) > in changelog. In Debian python team, it was `UNRELEASE` if team upload > from non-DD/DM. So l use it there. > Could you have a look?:) This is correct and Etienne just did what was needed. ;-) Thanks a lot for your contribution Andreas. -- http://fam-tille.de
Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets
Hi, Am Thu, Jul 20, 2023 at 12:57:11PM +0800 schrieb Bo YU: > ... > Oh, thanks you told me the background so today I learned many here. > > I think it is okay i push the update to the salsa repo directly as > your suggestion. Thank you for your contribution and welcome in the team Andreas. -- http://fam-tille.de
How to create multi-source tarball with different submodules for scipy
Hi, I tried to create a multi-source tarball for scipy in its experimental branch[1]. Upstream includes a set of git submodules in its build process. I intended to merge all these submodules in a single scipy_1.10.0.orig-submodules.tar.gz. This tarball is created with a script[2] which makes sure that the exact directory structure as it is used by upstream is conserved. This directory layout is needed in the build process. Unfortunately `dpkg-source -x` extracts the content of the submodules tarball into a subdirectory submodules/. Is there any trick to unpack this tarball right into the root? Otherwise I need to do some symlinks workaround in d/rules to provide all files where these are needed. Kind regards Andreas. [1] https://salsa.debian.org/python-team/packages/scipy/-/tree/experimental [2] https://salsa.debian.org/python-team/packages/scipy/-/blob/experimental/debian/get-submodules -- http://fam-tille.de
Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)
Am Thu, Oct 27, 2022 at 03:25:29PM +0530 schrieb Nilesh Patra: > I pushed something via which I get: > > | uscan info: Launch mk-origtargz with options: > | --package libomp-jonathonl --version 0.0+git20211216.5228495 > --compression default --directory .. --copyright-file debian/copyright > ../libomp-jonathonl-0.0+git20211216.5228495.tar.xz > | Successfully symlinked ../libomp-jonathonl-0.0+git20211216.5228495.tar.xz > to ../libomp-jonathonl_0.0+git20211216.5228495.orig.tar.xz. > > > Maybe this shall do. Can you check? Thanks a lot, works Andreas. -- http://fam-tille.de
Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)
Hi Andrius, Am Thu, Oct 27, 2022 at 12:00:59PM +0300 schrieb Andrius Merkys: > I have just pushed a fix. Please check if that works for you as well. Hmmm, this results in uscan info: Newest version of libomp-jonathonl on remote site is 0.0+git20181221.506f3e5, local version is 0.0+git20181221.506f3e5 while I would expect uscan info: Newest version of libomp-jonathonl on remote site is 0.0+git20211216.5228495, local version is 0.0+git20181221.506f3e5 since commit 5228495 is from 2021-12-16. Kind regards Andreas. -- http://fam-tille.de
Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)
Hi again, Am Thu, Oct 27, 2022 at 08:23:43AM +0200 schrieb Andreas Tille: > > According to requirements.txt [1], minimac4 depends on omp [2], so it seems > > this message warns about omp not being found on the system. Unfortunately its not just omp but the latest commit from the development branch. Thus I tried gitmode[1] according to the docs: $ cat debian/watch version=4 opts="mode=git,gitmode=full,pgpmode=none,pretty=0.0+git%cd.%h" \ https://github.com/jonathonl/omp refs/heads/develop but I do not get any helpful result: $ uscan --verbose uscan info: uscan (version 2.22.2) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="libomp-jonathonl" version="0.0+git20181221.506f3e5-1" (as seen in debian/changelog) uscan info: package="libomp-jonathonl" version="0.0+git20181221.506f3e5" (no epoch/revision) uscan info: ./debian/changelog sets package="libomp-jonathonl" version="0.0+git20181221.506f3e5" uscan info: Process watch file at: debian/watch package = libomp-jonathonl version = 0.0+git20181221.506f3e5 pkg_dir = . uscan info: opts: mode=git,gitmode=full,pgpmode=none,pretty=0.0+git%cd.%h uscan info: line: https://github.com/jonathonl/omp refs/heads/develop uscan info: Parsing mode=git uscan info: Parsing gitmode=full uscan info: Parsing pgpmode=none uscan info: Parsing pretty=0.0+git%cd.%h uscan info: line: https://github.com/jonathonl/omp refs/heads/develop uscan warn: Tag pattern missing version delimiters () in debian/watch, skipping: https://github.com/jonathonl/omp refs/heads/develop uscan info: Scan finished Any idea what might went wrong? Kind regards Andreas. [1] https://salsa.debian.org/med-team/libomp-jonathonl/-/blob/master/debian/watch -- http://fam-tille.de
Re: Help needed for watch file after bitbucket changed download page
Hi Juri, Am Thu, Sep 29, 2022 at 12:38:03PM +0200 schrieb Juri Grabowski: > maybe it can be helpfull for you. So you can get commit hash of your tag > with bitbucket api: > curl -s -L > https://api.bitbucket.org/2.0/repositories/berkeleylab/metabat/refs/tags/v2.15 > |jq -C -r .target.hash I confirm this returns the commit hash - but I have no idea how you want to use this information inside d/watch. > Other way is to use more generic git mode: > > cat <<'EOF'>debian/watch > version=4 > > opts="mode=git,pgpmode=gittag,dversionmangle=auto" \ > https://bitbucket.org/berkeleylab/metabat.git refs/tags/v([\d\.\d]+) > EOF I confirm this works. However, uscan does not do the usual link to orig.tar.gz. Any idea why this is the case? Kind regards Andreas. -- http://fam-tille.de
Help needed for watch file after bitbucket changed download page
Hi, the watch file for metabat[1] used to work nicely until some point in time when bitbucket replaced `v@ANY_VERSION@` by the commit ID which is not sensibly sorting any more. Is there any trick how I can get bitbucket pages working again? Kind regards Andreas. [1] https://salsa.debian.org/med-team/metabat/-/blob/master/debian/watch -- http://fam-tille.de
adduser claims existing diretory in postinst when running piuparts for shiny-server
Hi, the Debian Science team has packaged node-shiny-server[1]. It creates a system user in its postinst script. I've added some debug output to this script[2] since I wanted to debug a piuparts issue which you can see here in salsa CI[3]. This log shows two ways to verify that the home directory of the user does not exist, but adduser fails with Stopped: Couldn't create home directory `/home/shiny': File exists. anyway. Any idea what's going on here and how to fix this? Kind regards Andreas. [1] https://salsa.debian.org/science-team/shiny-server [2] https://salsa.debian.org/science-team/shiny-server [3] https://salsa.debian.org/science-team/node-shiny-server/-/jobs/2785645#L5900 -- http://fam-tille.de
Re: How to use local font in dh_auto_test
Am Fri, Apr 01, 2022 at 10:42:44PM +0200 schrieb Dominik George:
> > I tried to copy that font file to ${HOME}/.fonts and fc-list is even
> > listing the font in question[1]:
> >
> > /tmp/.fonts/yudit.ttf: Yudit Unicode:style=LR
> >
> > but finally the test fails
>
> have you tried updating the fontconfig cache (using fc-cache -f)?
Yep, right before fc-list:
https://salsa.debian.org/debian-phototools-team/feh/-/blob/master/debian/rules
Kind regards
Andreas.
--
http://fam-tille.de
How to use local font in dh_auto_test
Hi,
I intend to add build time tests (and if this will work autopkgtest)
to feh. It turns out that it can not find its own font file shipped
with the source since it is not installed at build time test status.
I tried to copy that font file to ${HOME}/.fonts and fc-list is even
listing the font in question[1]:
/tmp/.fonts/yudit.ttf: Yudit Unicode:style=LR
but finally the test fails with
feh WARNING: couldn't load font yudit/11, attempting to fall back to fixed.
feh WARNING: failed to even load fixed! Attempting to find any font.
feh ERROR: Error loading fonts
Any idea how to get this working?
Kind regards
Andreas.
[1] https://salsa.debian.org/debian-phototools-team/feh/-/jobs/2629411#L1292
--
http://fam-tille.de
Re: Automake issues on pngnq
Am Mon, Mar 07, 2022 at 11:08:11PM +0100 schrieb Filip Hroch: > > PKG_CHECK_MODULES macro defines set of [lib]png_* variables, > specially [lib]png_CFLAGS and [lib]png_LIBS, which can be used > in Makefile[.am] by this way: > > pngnq_CFLAGS = ... $(png_CFLAGS) .. > pngnq_LDADD = ... $(png_LIBS) .. > > (I'm unsure if ones are png_* or libpng_*, please > consult `config.log'). Its $(PNG_LIBS) and the build works that way. Thanks for your helpful hint Andreas. -- http://fam-tille.de
Re: Automake issues on pngnq
Am Tue, Mar 08, 2022 at 01:07:05AM +0500 schrieb Andrey Rahmatullin: > On Mon, Mar 07, 2022 at 08:59:38PM +0100, Andreas Tille wrote: > > For whatever reason automake puts LDFLAGS before "-o pngcomp" > This is correct. > > > instead of after and the last options are obtained from the LIBS variable. > This is correct. > > > I have no idea how to tweak this sequence. > You don't need to tweak the sequence. You need to put libs into LIBS. I was checking this as well - seems here is something broken: # checks for libraries AC_SEARCH_LIBS([zlibVersion],[z]) AC_SEARCH_LIBS([sqrt],[m]) PKG_CHECK_MODULES([PNG], [libpng >= 1.2.0]) Any idea how to make sure the correct -lpng expression is added here? Kind regards Andreas. -- http://fam-tille.de
Automake issues on pngnq
Hi, I tried to adopt pngnq from QA and pushed it to Salsa[1]. Unfortunately the new upstream version has some automake issues. Strangely enough one issue in configure script occures only in salsa-ci[2] but not in my local pbuilder. There I get another issue in a later stage of the build process: gcc `libpng-config --I_opts` -Wall --pedantic -std=gnu99 -g -O2 -ffile-prefix-map=/build/pngnq-1.1=. -fstack-protector-strong -Wformat -Werror=format-security `libpng-config --ldflags` -lz -lm -Wl,-z,relro -Wl,-z,now -o pngcomp pngcomp.o rwpng.o colorspace.o -lm -lz /usr/bin/ld: rwpng.o: in function `rwpng_error_handler': ./src/rwpng.c:563: undefined reference to `png_get_error_ptr' /usr/bin/ld: rwpng.o: in function `rwpng_version_info': ./src/rwpng.c:48: undefined reference to `png_get_header_ver' /usr/bin/ld: rwpng.o: in function `rwpng_read_image': ./src/rwpng.c:82: undefined reference to `png_sig_cmp' /usr/bin/ld: ./src/rwpng.c:88: undefined reference to `png_create_read_struct' ... The latter can be fixed by appending `libpng-config --ldflags` in the end of the command line. For whatever reason automake puts LDFLAGS before "-o pngcomp" instead of after and the last options are obtained from the LIBS variable. I have no idea how to tweak this sequence. Kind regards Andreas. [1] https://salsa.debian.org/debian-phototools-team/pngnq/ [2] https://salsa.debian.org/debian-phototools-team/pngnq/-/jobs/2538883 -- http://fam-tille.de
Re: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x
Hi, Am Wed, Feb 16, 2022 at 12:09:23PM +0100 schrieb John Paul Adrian Glaubitz: > > So, I have skimmed over the build logs and one of the main issues is the use > of > -march flags to enforce a certain baseline [1]: > > powerpc64le-linux-gnu-gcc: error: unrecognized command-line option > ‘-march=native’; did you mean ‘-mcpu=native’? > > This is a policy violation and must be fixed in any case. Blacklisting > architectures > is not enough in this case as forcing the baseline of the buildds can lead to > code > that won't run on the user's machines. I confirm this is a problem and the critical string can also be found in the amd64 build log[2]: ... running build_clib customize UnixCCompiler customize UnixCCompiler using build_clib CCompilerOpt.cc_test_flags[1013] : testing flags (-march=native) C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC creating /tmp/tmpk22ehoi2/usr creating /tmp/tmpk22ehoi2/usr/lib creating /tmp/tmpk22ehoi2/usr/lib/python3 creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils/checks compile options: '-c' extra options: '-march=native' CCompilerOpt.cc_test_flags[1013] : testing flags (-O3) C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC ... I admit I'm not sure at what point / what tool might inject this string and I'm also not sure whether the option -march=native is really used in the amd64 case. Kind regards Andreas. > > [1] > > https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=ppc64el=1.0.2-1=1644956229=0 [2] https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=amd64=1.0.2-1=1644952702=0 -- http://fam-tille.de
Re: How to turn off Salsa CI for a package?
Am Thu, Jan 27, 2022 at 10:29:26PM + schrieb Rebecca N. Palmer: > I've tried these attempts at "do nothing" in debian/salsa-ci.yml. Neither of > them does that: the default CI still runs. > > https://salsa.debian.org/science-team/pandas/-/commits/debian See https://www.wgdd.org/2019/11/salsa-skip-ci/ Hope this helps Andreas. -- http://fam-tille.de
[Help] Re: Bug#998479: aevol: FTBFS: configure.ac:301: error: AM_INIT_AUTOMAKE expanded multiple times
Control: tags -1 help Hi, I tried to fix the issue via a patch[1] that should ensure AM_INIT_AUTOMAKE is called only once. Unfortunately that patch resulted in: dh_autoreconf configure.ac:303: error: AM_INIT_AUTOMAKE expanded multiple times /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from... configure.ac:301: the top level /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from... configure.ac:303: the top level autom4te: error: /usr/bin/m4 failed with exit status: 1 aclocal: error: /usr/bin/autom4te failed with exit status: 1 autoreconf: error: aclocal failed with exit status: 1 dh_autoreconf: error: autoreconf -f -i returned exit code 1 Any idea why autoreconf is working inside if and else branch and how to fix this issue properly? Kind regards Andreas. [1] https://salsa.debian.org/med-team/aevol/-/blob/master/debian/patches/automake.patch -- http://fam-tille.de
Re: URL is OK in browser but returns 404 with uscan
Hi Dominik, Am Sat, Oct 09, 2021 at 10:11:23PM +0200 schrieb Dominik George: > Digging a bit, there is actually an example for this in the uscan man > page (grep for AWS). > > Find attached a patch for your package ☺. Thanks a lot for the really quick and welcome help Andreas. -- http://fam-tille.de
URL is OK in browser but returns 404 with uscan
Hi, when I try to visit https://alkesgroup.broadinstitute.org/BOLT-LMM/downloads/ with any browser I get a list of files. However, the watch file of bolt-lmm[1] pointing to that web page returns: $ uscan --verbose --report uscan info: uscan (version 2.21.3) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="bolt-lmm" version="2.3.5+dfsg-2" (as seen in debian/changelog) uscan info: package="bolt-lmm" version="2.3.5+dfsg" (no epoch/revision) uscan info: ./debian/changelog sets package="bolt-lmm" version="2.3.5+dfsg" uscan info: Process watch file at: debian/watch package = bolt-lmm version = 2.3.5+dfsg pkg_dir = . uscan info: opts: repacksuffix=+dfsg,dversionmangle=s/\+dfsg//g,repack,compression=xz uscan info: line: https://alkesgroup.broadinstitute.org/BOLT-LMM/downloads/ .*/BOLT-LMM_v(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz)) uscan info: Parsing repacksuffix=+dfsg uscan info: Parsing dversionmangle=s/\+dfsg//g uscan info: Parsing repack uscan info: Parsing compression=xz uscan info: line: https://alkesgroup.broadinstitute.org/BOLT-LMM/downloads/ .*/BOLT-LMM_v(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz)) uscan info: Last orig.tar.* tarball version (from debian/changelog): 2.3.5+dfsg uscan info: Last orig.tar.* tarball version (dversionmangled): 2.3.5 uscan info: Requesting URL: https://alkesgroup.broadinstitute.org/BOLT-LMM/downloads/ uscan warn: In watchfile debian/watch, reading webpage https://alkesgroup.broadinstitute.org/BOLT-LMM/downloads/ failed: 404 Not Found uscan info: Scan finished Any idea how to help uscan reading that web page? Kind regards Andreas. [1] https://salsa.debian.org/med-team/bolt-lmm/-/blob/master/debian/watch -- http://fam-tille.de
Re: r-cran-ncdf4: ftbfs with autoconf 2.70
Control: tags -1 help
Hi,
I need to admit that from my naive perspective this is a bug in
autoconf. In the log that is provided in the bug report[1] you can see
this here:
dh_autoreconf -O--buildsystem=R
configure.ac:44: warning: AC_OUTPUT should be used without arguments.
configure.ac:44: You should run autoupdate.
configure.ac:44: warning: AC_OUTPUT should be used without arguments.
configure.ac:44: You should run autoupdate.
debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cd tools && ./regenerate
rm: cannot remove '../Makefile': No such file or directory
rm: cannot remove '../src/Makevars': No such file or directory
configure.ac:44: warning: AC_OUTPUT should be used without arguments.
configure.ac:44: You should run autoupdate.
configure.ac:44: warning: AC_OUTPUT should be used without arguments.
configure.ac:44: You should run autoupdate.
This results later in:
** using staged installation
configure.ac: starting
./configure: line 1764: syntax error near unexpected token `;;'
./configure: line 1764: ` as_dir=./ ;;'
ERROR: configuration failed for package ‘ncdf4’
I checked the resulting configure file and the part in question looks like:
echo "configure.ac: starting"
as_dir=./ ;;
*/) ;;
*) as_dir=$as_dir/ ;;
esac
for ac_exec_ext in '' $ac_executable_extensions; do
if as_fn_executable_p "$as_dir$ac_word$ac_exec_ext"; then
ac_cv_prog_HAS_NC_CONFIG="yes"
printf "%s\n" "$as_me:${as_lineno-$LINENO}: found
$as_dir$ac_word$ac_exec_ext" >&5
break 2
fi
done
It looks like a case statement intended but not injected by autoconf. I
have no idea how this can be influenced by some configure.ac statement.
Kind regards
Andreas.
[1] https://bugs.debian.org/978891
--
http://fam-tille.de
Re: Failed build for seqan2 on i386
On Fri, Feb 12, 2021 at 04:30:48PM +0500, Andrey Rahmatullin wrote: > On Fri, Feb 12, 2021 at 11:21:38AM +0100, Hilmar Preuße wrote: > > > But other 32bit architectures like armel and armhf are passing[2]. So I > > > fail to see why exactly i386 is failing. Is this possibly an effect of > > > bug #917851? > > > > > Maybe the memory of the whole builder is exhausted. > > Then it would get an OOM, not a *virtual* memory error. Seems the best idea is to ask ftpmaster to remove seqan2 i386 since chances that this software is used here is extremely low anyway. Kind regards Andreas. -- http://fam-tille.de
Re: Failed build for seqan2 on i386
Hi Hilmar, On Fri, Feb 12, 2021 at 11:21:38AM +0100, Hilmar Preuße wrote: > > But other 32bit architectures like armel and armhf are passing[2]. So I > > fail to see why exactly i386 is failing. Is this possibly an effect of > > bug #917851? > > > Maybe the memory of the whole builder is exhausted. In this case it may help > to limit the amount of parallel running processes. On i386 we have "make > -j4" on armel just "make -j1" . Do you suggest I should enforce this in d/rules or is it possible to ask autobuild maintainers to trigger a rebuild with this setting? Kind regards Andreas. -- http://fam-tille.de
Re: Failed build for seqan2 on i386
Hi, On Fri, Feb 12, 2021 at 02:39:25PM +0500, Andrey Rahmatullin wrote: > > I wonder whether this could be simply solved by adjusting the hardware / > > emulation parameters of the according autobuilder. > > > > Am I missing something? > You can't adjust anything to get more than 4GB virtual memory on 32-bit > architectures. > You can try adjusting compilation/linking parameters to make the > compiler/linker use less memory though (not sure if the suggestions are > documented anywhere). But other 32bit architectures like armel and armhf are passing[2]. So I fail to see why exactly i386 is failing. Is this possibly an effect of bug #917851? Kind regards Andreas. [2] https://buildd.debian.org/status/package.php?p=seqan2 -- http://fam-tille.de
Failed build for seqan2 on i386
Hi, in the build log[1] I found virtual memory exhausted: Operation not permitted I wonder whether this could be simply solved by adjusting the hardware / emulation parameters of the according autobuilder. Am I missing something? Kind regards Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=seqan2=i386=2.4.0%2Bdfsg-13=1613071965=0 -- http://fam-tille.de
Re: No pushable pushable ssh URLs for Salsa & gbp
On Thu, Jan 28, 2021 at 10:54:43PM +0100, Ansgar wrote: > > Just checking: git behaves properly as expected and ends up with > > salsa:team/package.git > > as URL. > > You followed the instructions for "You can also use a shortcut for all > Salsa repositories:" from the Wiki page you linked. That shortcut is > "salsa:" > > If you want to rewrite https://salsa.debian.org, you should follow the > instructions before that. I did both which resulted in: $ cat .gitconfig [url "g...@salsa.debian.org:"] pushInsteadOf = https://salsa.debian.org/ insteadOf = salsa: and works for git ... but not for gbp. It works perfectly on my other computers but not on this one so I think some additional gbp config is needed. (I had no time to seek for this yet.) Kind regards Andreas. -- http://fam-tille.de
Re: No pushable pushable ssh URLs for Salsa & gbp
On Thu, Jan 28, 2021 at 09:53:48PM +0100, Geert Stappers wrote: > > > >gbp clone salsa:team/package > > Odd git clone URL, might be due magic from gbp. Just checking: git behaves properly as expected and ends up with salsa:team/package.git as URL. > Hard to tell. Things to be aware of > * account on new computer might not be known to Salsa > (Give a copy of (new) ssh pub key to Salsa) I'm using the same ssh key. > * `gbp` doing magic things > (based upon seeing the odd git clone URL above) Seems to be the reason - I seek tomorrow for more ideas if nobody else can give a hint. Thanks a lot Andreas. -- http://fam-tille.de
No pushable pushable ssh URLs for Salsa
Hi, I had no problems to clone from salsa for since the beginning. It works on several computers I have. On a newly installed Laptop I copied all my configurations from a computer that works perfectly in the sense that gbp clone salsa:team/package creates a .git/config containing [remote "origin"] url = g...@salsa.debian.org:team/package.git as it should be to be able to push. Great. However, on that new laptop I get [remote "origin"] url = https://salsa.debian.org/team/package.git I closely followed the salsa documentation[1] and did git config --global url."g...@salsa.debian.org:".insteadOf salsa: (which created the entry in ~/.gitconfig [url "g...@salsa.debian.org:"] pushInsteadOf = https://salsa.debian.org/ insteadOf = salsa: So all seems as expected - but the URL is not replaced and I need to manually change the URL in cloned repositories. The laptop in question is running an up to date testing. Any idea what I might missing? Kind regards Andreas. [1] https://wiki.debian.org/Salsa/Doc#Canonical_URLs -- http://fam-tille.de
Re: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 11:47:53PM +, Jeremy Sowden wrote: > If you haven't got this sorted yet, try the attached patch. It also > corrects the SONAME of shasta.so. It does mean there's an RPATH in the > executable, however. > ... Thanks a lot Andreas. -- http://fam-tille.de
Re: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote: > On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote: > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead > > to: > > > > dpkg-shlibdeps: error: cannot find library > > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed > > by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: > > '0201003e'; RPATH: '') > Why are you linking an executable to a Python binary module? That's a good question. Its actually not me who did this. I think that's done here: https://salsa.debian.org/med-team/shasta/-/blob/master/debian/rules#L27 but I admit I have no idea why Shayan did so. I wonder what might be the proper way to do this to share the library between Python modules and the executable. Kind regards Andreas. -- http://fam-tille.de
dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
Hi, I tried no override_dh_shlibdeps in shasta debian/rules, which has lead to: dpkg-shlibdeps: error: cannot find library /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: error: cannot continue due to the error above Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to use -l. dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/shasta.substvars debian/shasta/usr/bin/shasta returned exit code 2 dh_shlibdeps: error: Aborting due to earlier error and in the pbuilder chroot I also tried the there commands I added to the comment in https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6 with no success - dpkg-shlibdeps simply did not found the shared library which exists at the said place. I wonder what might be wrong here and how to fix this. Kind regards Andreas. On Fri, Dec 18, 2020 at 06:03:30PM +0530, Nilesh Patra wrote: > Hi Andreas, > > On Fri, 18 Dec 2020 at 15:53, Andreas Tille wrote: > > > Control: tags -1 help > > > > Hi, > > > > I tried to fix the issue by making dh_shlibdeps work. In > > > > > > https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6 > > > > I documented what I tried but all failed and I think the key to this bug > > is just making it work. > > > > Any idea? > > > > I've no clue. The "-l" flag doesn't seem to work somehow. May I suggest > forwarding it to the list? I'm positive that Aaron (ucko) will definitely > know a good workaround for this bit. > Also another request: Could you please as well attach the failing logs in > future RFHs? This saves atleast one build for the others. Consider my best > of intentions. > > Regards -- http://fam-tille.de
Re: pftools: CMAKE_INSTALL_PREFIX resolves *sometimes* to /usr instead of $(CURDIR)/debian/$package/usr
Hi Juhani,
On Thu, Dec 17, 2020 at 06:04:26PM +0200, Juhani Numminen wrote:
>
> They do not take DESTDIR into account. They should, because the built-in
> cmake function install() does.
>
> Note that
> - ${CMAKE_INSTALL_PREFIX} is /usr
> - ${DESTDIR}${CMAKE_INSTALL_PREFIX} is /build/pftools-3.2.6/debian/pftools/usr
I tried to implement this in
https://salsa.debian.org/med-team/pftools/-/commit/4aac978b4166030668477d9b5d95b91a9658370e
but unfortunately this does not work.
Did I misunderstood your hint?
Kind regards
Andreas.
--
http://fam-tille.de
pftools: CMAKE_INSTALL_PREFIX resolves *sometimes* to /usr instead of $(CURDIR)/debian/$package/usr
Hi, I'm working on pftools in git[1]. The package builds and the build time tests are passing. However, in the install step the variable CMAKE_INSTALL_PREFIX in [2] simply seems to resolve to /usr, since I get ... -- Installing: /build/pftools-3.2.6/debian/pftools/usr/share/examples/all.prf -- Installing: /build/pftools-3.2.6/debian/pftools/usr/share/examples/score.lis find: '/usr/share/examples/': No such file or directory find: '/usr/share/examples/': No such file or directory find: '/usr/share/examples/': No such file or directory CMake Error at tests/cmake_install.cmake:62 (FILE): FILE RENAME failed to rename /usr/share/examples/test_V2.sh.cmake to /usr/share/examples/test_V2.sh because: No such file or directory Call Stack (most recent call first): cmake_install.cmake:58 (include) make[2]: *** [Makefile:162: install] Error 1 make[2]: Leaving directory '/build/pftools-3.2.6/obj-x86_64-linux-gnu' At other places the variable seems to resolve properly, thought. Any idea what might be wrong at this specific line(s) (the next two lines in this CMakeLists.txt are the same)? Kind regards Andreas. [1] https://salsa.debian.org/med-team/pftools [2] https://salsa.debian.org/med-team/pftools/-/blob/master/tests/CMakeLists.txt#L49 -- http://fam-tille.de
Re: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)
Hi Mathieu, On Thu, Dec 10, 2020 at 11:10:17AM +0100, Mathieu Malaterre wrote: > "make -j160" > > that would be my guess :) This sounds pretty likely, thought. Thanks for the hint. > remove parallel from the dh option, and try again (fixes symptoms) To cure the real issue rather than the symptoms: Is there any way to make sure flex will be called first before the build starts? My knowledge in automake is pretty limited and I have no idea how to express this. Kind regards and thanks for the hint in any case Andreas. -- http://fam-tille.de
Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)
Control: tags -1 help Hi, I tried to investigate the situation below and my guess is that lex has somehow problems to create the missing header files. I've found the files in upstreams .gitignore file so these need to be created but this does not seem to work on ppc64el (any more - since the package has build successfully before). Any hint to tackle this is welcome Andreas. On Wed, Dec 09, 2020 at 09:37:42AM +0100, Lucas Nussbaum wrote: > Source: libpll > Version: 0.3.2-3 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. > > I'm marking this bug as severity:serious since your package currently has > ppc64el binary packages in unstable (so this is a regression). > > Relevant part (hopefully): > > /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. > > -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE > > -std=c99 -O3 -fPIC -g -c -o libpll_la-lex_utree.lo `test -f 'lex_utree.c' > > || echo './'`lex_utree.c > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c fasta.c -fPIC -DPIC -o .libs/libpll_la-fasta.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c pll.c -fPIC -DPIC -o .libs/libpll_la-pll.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c likelihood.c -fPIC -DPIC -o .libs/libpll_la-likelihood.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c maps.c -fPIC -DPIC -o .libs/libpll_la-maps.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c output.c -fPIC -DPIC -o .libs/libpll_la-output.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c utree.c -fPIC -DPIC -o .libs/libpll_la-utree.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c utree_moves.c -fPIC -DPIC -o .libs/libpll_la-utree_moves.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c models.c -fPIC -DPIC -o .libs/libpll_la-models.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c parsimony.c -fPIC -DPIC -o .libs/libpll_la-parsimony.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c core_partials.c -fPIC -DPIC -o .libs/libpll_la-core_partials.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c derivatives.c -fPIC -DPIC -o .libs/libpll_la-derivatives.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c utree_svg.c -fPIC -DPIC -o .libs/libpll_la-utree_svg.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c gamma.c -fPIC -DPIC -o .libs/libpll_la-gamma.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c rtree.c -fPIC -DPIC -o .libs/libpll_la-rtree.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c list.c -fPIC -DPIC -o .libs/libpll_la-list.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c partials.c -fPIC -DPIC -o .libs/libpll_la-partials.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c compress.c -fPIC -DPIC -o .libs/libpll_la-compress.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC > > -g -c core_pmatrix.c -fPIC -DPIC -o .libs/libpll_la-core_pmatrix.o > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time >
[help] Error in hdmf possibly caused by hdf5 issue?
Control: tags -1 help
Hi,
the build log says:
...
> ==
> FAIL: test_link_h5py_dataset_h5dataio_input
> (tests.unit.test_io_hdf5_h5tools.H5IOTest)
> --
> Traceback (most recent call last):
> File
> "/<>/.pybuild/cpython3_3.9_hdmf/build/tests/unit/test_io_hdf5_h5tools.py",
> line 688, in test_link_h5py_dataset_h5dataio_input
> self.assertTrue(isinstance(self.f.get('test_softlink', getlink=True),
> SoftLink))
> AssertionError: False is not true
>
> ==
> FAIL: test_link_h5py_dataset_input (tests.unit.test_io_hdf5_h5tools.H5IOTest)
> --
> Traceback (most recent call last):
> File
> "/<>/.pybuild/cpython3_3.9_hdmf/build/tests/unit/test_io_hdf5_h5tools.py",
> line 671, in test_link_h5py_dataset_input
> self.assertTrue(isinstance(self.f.get('test_softlink', getlink=True),
> SoftLink))
> AssertionError: False is not true
>
> --
> Ran 748 tests in 3.146s
>
> FAILED (failures=2, skipped=3, expected failures=1)
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
> /<>/.pybuild/cpython3_3.9_hdmf/build; python3.9 -m unittest
> discover -v
> dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.8" returned
> exit code 13
...
I wonder whether there is a known issue with hdf5 which might cause this
test suite error which otherwise looks pretty clean (also in other hdf5
tests).
Kind regards
Andreas.
--
http://fam-tille.de
dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}
Control: tags -1 pending
Hi,
upstream of fis-gtm package[1] confirmed that the build needs some root
permissions. Thus I've set
Rules-Requires-Root: yes
When trying to build with pbuilder I get:
dh_testroot
dh_testroot: error: Package needs targeted root but builder has not provided a
gain-root command via ${DEB_GAIN_ROOT_CMD}
make: *** [debian/rules:21: binary] Error 25
How can this be fixed?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/fis-gtm
--
http://fam-tille.de
Fortran issue solved but symbols issues (Was: Bug#957665: Fortran issue in paw (Was: paw: ftbfs with GCC-10))
Hi Andrius On Thu, Oct 15, 2020 at 03:34:15PM +0300, Andrius Merkys wrote: > > FFLAGS += -fallow-argument-mismatch Thanks a lot for the helpful hint which enabled me to do one step forward[1]. Unfortunately there are further errors: ... /usr/bin/ld: paw/cdf/shared/mlpdef.o:/build/paw-2.14.04.dfsg.2/build/pawlib/paw/cdf/mlpdef.c:155: multiple definition of `klnkaddr'; paw/cdf/shared/pawcdf.o:/build/paw-2.14.04.dfsg.2/build/pawlib/paw/cdf/pawcdf.c:155: first defined here /usr/bin/ld: warning: alignment 4 of symbol `pawch3_' in paw/ntuple/shared/c_decl.o is smaller than 16 in paw/code/shared/pawint3.o /usr/bin/ld: warning: size of symbol `hcfile_' changed from 12800 in paw/code/shared/hgetid.o to 4000 in paw/ntuple/shared/c_decl.o /usr/bin/ld: warning: size of symbol `pawc_' changed from 40004 in comis/code/shared/csdefn.o to 4 in paw/ntuple/shared/c_decl.o /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:31: multiple definition of `learn_'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:31: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:40: multiple definition of `pat_'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:40: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:19: multiple definition of `net_'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:19: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:49: multiple definition of `divers_'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:49: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:92: multiple definition of `Hessian'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:92: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:91: multiple definition of `ExamplesIndex'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:91: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:90: multiple definition of `JacobianMatrix'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:90: first defined here /usr/bin/ld: paw/mlpfit/shared/mlp_inter.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:89: multiple definition of `Gamma'; paw/mlpfit/shared/mlp_gen.o:/build/paw-2.14.04.dfsg.2/src/pawlib/paw/mlpfit/mlp_gen.h:89: first defined here ... Any further hints are welcome Andreas. [1] https://salsa.debian.org/science-team/paw/-/commit/5b7695142d3580516168086feb3e97c2b1fac575 -- http://fam-tille.de
Fortran issue in paw (Was: paw: ftbfs with GCC-10)
Control: tags -1 help Hi, when trying to build paw with gcc / fortran 10 there are some FORTRAN errors: ... Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/INTEGER(4)). /<>/src/pawlib/comis/code/cs1200.F:138:24: 76 | CALL CCOPYA(KOD(IPCP),KOD(IPCP+I),L) |2 .. 138 | CALL CCOPYA(CX,KOD(IPCP-1),KLCMLX) |1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/INTEGER(4)). /<>/src/pawlib/comis/code/cs1200.F:154:24: 76 | CALL CCOPYA(KOD(IPCP),KOD(IPCP+I),L) |2 .. 154 | CALL CCOPYA(CX,KOD(IPCP-2),KLCMLX) |1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/INTEGER(4)). /<>/src/pawlib/comis/code/cs1200.F:183:22: ... Any hint how this can be solved? Kind regards Andreas. -- http://fam-tille.de
Re: Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Hi Étienne,
On Mon, Oct 12, 2020 at 10:22:39PM +0200, Étienne Mollier wrote:
> > 162 | __cpuid (__ext, __eax, __ebx, __ecx, __edx);
> > | ^~~
> > third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
> > 103 | __asm__ ("cpuid\n\t" \
> > | ^~~
> > third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
> > 185 | __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
> > | ^~~
> > In file included from ebwt_build.cpp:8:
> > ...
> >
> > Any idea how to deal with this?
>
> I believe that cpuid.h is an architecture specific header, but
> the upstream source code ships with a custom third_party/cpuid.h
> which probably mainly targets amd64, hence issues on non amd64.
>
> I ran an arm64 build a few minutes ago, after having excluded
> third_party/. This way, the source code gently failed back to
> the system provided cpuid.h which should be always be
> appropriate. My build went through on arm64, as well as the
> test suite.
H, may be I should remove third_party/cpuid.h in general?
Given its copyright informazion is
Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
that seems to be a pretty old copy of this file.
> > [1]
> > https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch
>
> As a side note, I believe that the $(filter ...) statement added
> in the patch to be able to list architectures reverted the
> logic, so replaced the ifeq (...) statement to an ifneq (...).
>
> Most changes are available on my machine. I would have
> suggested to push them, but my build targeting mips64el failed
> and it seems that its because `uname -m` returns mips64 on that
> architecture. I'm not 100% sure of the name for the other
> architectures, maybe listing CPUs handling popcnt might be
> simpler ?
>
> Anyway in hope any of these ideas helps...
Would you mind sending a `git diff` to make sure I fully
understood what you mean?
Kind regards
Andreas.
--
http://fam-tille.de
Re: Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Control: reopen -a
Control: tags -1 help
On Mon, Oct 12, 2020 at 02:50:41PM +0500, Andrey Rahmatullin wrote:
> > while I've fixed the issue for arm64 the new version of bowtie seems to
> > have some new assembly code where mips64el, ppc64el and others are
> > stumbling upon [1]:
> The reason it works on arm64 is
>
> ifeq (aarch64,$(shell uname -m))
> POPCNT_CAPABILITY=0
> endif
>
> in Makefile. It's clearly not supposed to run on anything else non-Intel
> but you can try patching this to also disable popcnt on other non-Intel.
My patch [1] worked for ppc64el and s390x. However for arm64 (and others)
a new build error occures:
...
In file included from ebwt_build.cpp:8:
ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t,
TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*)
[with T = S2bDnaString]’:
ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
497 | list_[cur_++] = el;
| ^
ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
497 | list_[cur_++] = el;
| ^
ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
497 | list_[cur_++] = el;
| ^
In file included from processor_support.h:17,
from ebwt.h:41,
from ebwt_build.cpp:10:
third_party/cpuid.h: In constructor ‘Ebwt::Ebwt(TStr, bool, int32_t, int32_t,
int32_t, int32_t, int32_t, int, const string&, bool, bool, TIndexOffU,
TIndexOffU, TIndexOffU, int, EList&, EList&,
EList&, TIndexOffU, const RefReadInParams&, uint32_t, int32_t,
int32_t, bool, bool, bool, bool) [with TStr = S2bDnaString]’:
third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
103 | __asm__ ("cpuid\n\t" \
| ^~~
third_party/cpuid.h:162:3: note: in expansion of macro ‘__cpuid’
162 | __cpuid (__ext, __eax, __ebx, __ecx, __edx);
| ^~~
third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
103 | __asm__ ("cpuid\n\t" \
| ^~~
third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
185 | __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
| ^~~
In file included from ebwt_build.cpp:8:
...
Any idea how to deal with this?
Kind regards
Andreas.
[1]
https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch
--
http://fam-tille.de
Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)
Control: tags -1 help Hi, while I've fixed the issue for arm64 the new version of bowtie seems to have some new assembly code where mips64el, ppc64el and others are stumbling upon [1]: ...In file included from ebwt_build.cpp:8: ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t, TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*) [with T = S2bDnaString]’: ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h: In function ‘void mkeyQSortSuf2(const T&, size_t, TIndexOffU*, size_t, TIndexOffU*, int, size_t, size_t, size_t, size_t, EList*) [with T = SString]’: ds.h:497:3: warning: ‘tmp2’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp3’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ ds.h:497:3: warning: ‘tmp4’ may be used uninitialized in this function [-Wmaybe-uninitialized] 497 | list_[cur_++] = el; | ^ /tmp/ccRHXYbX.s: Assembler messages: /tmp/ccRHXYbX.s:27483: Error: unrecognized opcode: `popcntq' /tmp/ccRHXYbX.s:27951: Error: unrecognized opcode: `popcntq' /tmp/ccRHXYbX.s:28493: Error: unrecognized opcode: `popcntq' /tmp/ccRHXYbX.s:143323: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:143324: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:143325: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:143326: Error: unrecognized opcode: `mov' /tmp/ccRHXYbX.s:143327: Error: operand out of range (0x0020 is not between 0x and 0x001f) /tmp/ccRHXYbX.s:143327: Error: missing operand /tmp/ccRHXYbX.s:143328: Error: unrecognized opcode: `push' /tmp/ccRHXYbX.s:143329: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:143330: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:143331: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:143332: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:143391: Error: unrecognized opcode: `cpuid' /tmp/ccRHXYbX.s:143407: Error: unrecognized opcode: `cpuid' /tmp/ccRHXYbX.s:176663: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:176664: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:176665: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:17: Error: unrecognized opcode: `mov' /tmp/ccRHXYbX.s:176667: Error: operand out of range (0x0020 is not between 0x and 0x001f) /tmp/ccRHXYbX.s:176667: Error: missing operand /tmp/ccRHXYbX.s:176668: Error: unrecognized opcode: `push' /tmp/ccRHXYbX.s:176669: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:176670: Error: unrecognized opcode: `pushfd' /tmp/ccRHXYbX.s:176671: Error: unrecognized opcode: `pop' /tmp/ccRHXYbX.s:176672: Error: unrecognized opcode: `popfd' /tmp/ccRHXYbX.s:176730: Error: unrecognized opcode: `cpuid' /tmp/ccRHXYbX.s:176746: Error: unrecognized opcode: `cpuid' make[2]: *** [Makefile:255: bowtie-build-s] Error 1 Any help would be welcome Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=bowtie=ppc64el=1.3.0%2Bdfsg-2=1602489351=0 -- http://fam-tille.de
gfortran-10 issue in raster3d
Hi, I tried to update the raster3d package in Debian[1] but it fails to build with: gfortran -g -w -O2 -Wno-tabs -ffixed-line-length-132 -c -o render.o render.f render.f:1078:13: 1078 | IERR = LOCAL(1, NAX, NAY, OTMODE, QUALITY) | 1 Error: More actual than formal arguments in procedure call at (1) render.f:1079:22: 1077 | IERR = LOCAL(5, IBKGND(1), IBKGND(2), IBKGND(3)) | 2 1078 | IERR = LOCAL(1, NAX, NAY, OTMODE, QUALITY) 1079 | IERR = LOCAL(4, TITLE) | 1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (CHARACTER(132)/INTEGER(4)). render.f:4402:22: 1077 | IERR = LOCAL(5, IBKGND(1), IBKGND(2), IBKGND(3)) | 2 .. 4402 | IERR = LOCAL(2, OUTBUF(K+1,1), OUTBUF(K+1,2), OUTBUF(K+1,3), | 1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(2)/INTEGER(4)). render.f:4430:13: 4430 | IERR = LOCAL(3) | 1 Error: Missing actual argument for argument '_formal_4' at (1) make[2]: *** [: render.o] Error 1 Any help would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/raster3d -- http://fam-tille.de
schroot behaves different than pbuilder (Was: Bug#963392: [Help] Re: r-cran-rstanarm: FTBFS: error: (converted from warning) TBB library not found.)
Hi, the short version of this question is how can it be that pbuilder seems to "eat" some '-L' in front of a linker option in r-cran-rstan[1] to make the build fail in pbuilder (see below) while Shayan confirmed schroot is able to build the package nicely? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-rstan On Thu, Sep 24, 2020 at 01:17:18PM +0100, Shayan Doust wrote: > Hello Andreas, > > That is very strange. It seems like a localised issue with chroot? It's > strange > because I can build this with sbuild (which relies on chroot?). I have > attached > the full log of my build regarding r-cran-rstan for information on the build > in > my case. > > I don't use chroots but I do rely on $ pbuilder login in some cases, so I'm > not > sure why you can't build this in your chroot. > > Kind regards, > Shayan Doust > > On 24/09/2020 10:19, Andreas Tille wrote: > > On Wed, Sep 23, 2020 at 07:34:50PM +0100, Shayan Doust wrote: > >> This [commit] now rectifies the build issue for r-cran-prophet. > >> > >> I can build r-cran-prophet successfully after re-building r-cran-rstan > >> with the > >> new patch. > > > > Strange, when I try to build r-cran-rstan with your patch I get: > > > > g++ -std=gnu++14 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include" > > -I"../inst/include/boost_not_in_BH" -I"." -DBOOST_DISABLE_ASSERTS > > -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -DBOOST_NO_AUTO_PTR -D_REENTRANT > > -DSTAN_THREADS -I'/usr/lib/R/site-library/Rcpp/include' > > -I'/usr/lib/R/site-library/RcppEigen/include' > > -I'/usr/lib/R/site-library/BH/include' > > -I'/usr/lib/R/site-library/StanHeaders/include' > > -I'/usr/lib/R/site-library/RcppParallel/include'-fpic -g -O2 > > -fdebug-prefix-map=/build/r-base-OT058M/r-base-4.0.2=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > > -D_FORTIFY_SOURCE=2 -g -c stan/lang/grammars/whitespace_grammar_inst.cpp > > -o stan/lang/grammars/whitespace_grammar_inst.o > > g++ -std=gnu++14 -shared -L/usr/lib/R/lib -Wl,-z,relro -o rstan.so Module.o > > chains.o init.o misc.o pointer-tools.o sparse_extractors.o stan_fit_base.o > > stan_fit_rccp.o stanc.o stan/lang/ast_def.o > > stan/lang/grammars/bare_type_grammar_inst.o > > stan/lang/grammars/block_var_decls_grammar_inst.o > > stan/lang/grammars/expression07_grammar_inst.o > > stan/lang/grammars/expression_grammar_inst.o > > stan/lang/grammars/functions_grammar_inst.o > > stan/lang/grammars/indexes_grammar_inst.o > > stan/lang/grammars/local_var_decls_grammar_inst.o > > stan/lang/grammars/program_grammar_inst.o > > stan/lang/grammars/semantic_actions_def.o > > stan/lang/grammars/statement_2_grammar_inst.o > > stan/lang/grammars/statement_grammar_inst.o > > stan/lang/grammars/term_grammar_inst.o > > stan/lang/grammars/whitespace_grammar_inst.o /usr/lib/x86_64-linux-gnu > > -ltbb -ltbbmalloc -L/usr/lib/R/lib -lR > > /usr/bin/ld: cannot find /usr/lib/x86_64-linux-gnu: file format not > > recognized > > collect2: error: ld returned 1 exit status > > make[1]: *** [/usr/share/R/share/make/shlib.mk:6: rstan.so] Error 1 > > > > It looks as if some variable is not resloved properly resolved in the chroot > > I substituted > > > >s/inst.o /usr/lib/x86_64-linux-gnu -ltbb/inst.o > > -L/usr/lib/x86_64-linux-gnu -ltbb/ > > > > (in the very end) and it worked. I guess the patch in R/plugin.R is > > responsible > > for this since this is where I can find the string -ltbb. > > > > Any idea how to fix this? > > > > Kind regards > > > >Andreas. > > -- http://fam-tille.de
Re: Potential gcc-10 issue "error: conflicting types for ‘uintptr_t’" (Was: Bug#966523: r-bioc-rsubread FTBFS on 32bit: error: conflicting types for ‘uintptr_t’)
Hi Paul, On Wed, Sep 23, 2020 at 07:57:09AM +, Paul Wise wrote: > It looks like r-base-core is duplicating standard C types and defining > them incorrectly. If you edit /usr/share/R/include/Rinterface.h to > remove uintptr_t, does the build succeed? It turned out that this problem has gone. Thus I'm closing this bug hereby. Kind regards Andreas. -- http://fam-tille.de
Potential gcc-10 issue "error: conflicting types for ‘uintptr_t’" (Was: Bug#966523: r-bioc-rsubread FTBFS on 32bit: error: conflicting types for ‘uintptr_t’)
Control: tags -1 help Control: tags -1 upstream Control: forwarded -1 Wei Shi , Yang Liao , Gordon K Smyth Hi, unfortunately upstream has not yet responded to this mail. My guess is that this is a general gcc-10 issue. Any hint how to solve this? Kind regards Andreas. On Tue, Sep 08, 2020 at 05:00:10PM +0200, Andreas Tille wrote: > Hi, > > I'm hereby forwarding a problem that was detected on the Debian packaged > version of Rsubread. Any idea how to fix this? > > Kind regards > >Andreas. > > On Thu, Jul 30, 2020 at 08:50:31AM +0300, Adrian Bunk wrote: > > Source: r-bioc-rsubread > > Version: 2.2.5-1 > > Severity: serious > > Tags: ftbfs > > > > https://buildd.debian.org/status/package.php?p=r-bioc-rsubread=sid > > > > ... > > In file included from /usr/lib/gcc/i686-linux-gnu/10/include/stdint.h:9, > > from HelperFunctions.h:139, > > from R_wrapper.c:35: > > /usr/include/stdint.h:96:23: error: conflicting types for ‘uintptr_t’ > >96 | typedef unsigned int uintptr_t; > > | ^ > > In file included from R_wrapper.c:30: > > /usr/share/R/include/Rinterface.h:110:24: note: previous declaration of > > ‘uintptr_t’ was here > > 110 | typedef unsigned long uintptr_t; > > |^ > > make[1]: *** [/usr/lib/R/etc/Makeconf:167: R_wrapper.o] Error 1 > -- http://fam-tille.de
[Solved] Re: Linker issues for libssw on armel, mips64el and mipsel
Hi Peter, On Thu, Aug 13, 2020 at 05:06:49PM +0800, Peter Ji wrote: > in line 33 of the ./src/Makefile，Modified like this may be better： > 33:$(PROG): main.c kseq.h $(LIB) $(STATICLIB) Thanks a lot. That was very helpful Andreas. -- http://fam-tille.de
Issues with parallel build (Was: Linker issues for libssw on armel, mips64el and mipsel)
Hi, On Wed, Aug 12, 2020 at 09:01:07AM +0100, Steve McIntyre wrote: > On Wed, Aug 12, 2020 at 09:33:31AM +0200, Andreas Tille wrote: > >... > >c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > >-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > >-Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 > >-DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -I"/include" -I"/include/linux" > >-I/usr/lib/jvm/default-java/include/ > >-I/usr/lib/jvm/default-java/include/linux -fPIC -shared -rdynamic -o > >libsswjni.so sswjni.c ssw.c -Wl,-z,relro -Wl,-z,now > >cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > >-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > >-Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 > >-DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -o ssw-align main.c kseq.h -L. -lssw > >-lm -lz -Wl,-z,relro -Wl,-z,now > >/usr/bin/ld: cannot find -lssw > >... > > > >(same on some non-released architectures). > > > >Any idea how to fix this? > > Comparing the buildd logs for arm64 and armel, there are obvious > differences - on armel the build doesn't even attempt to make the > library libssw.a. Check the Makefiles etc. to see if it has hard-coded > architecture support? I failed to find some architecture specific issues (as long as ifneq ($(filter nojava,$(DEB_BUILD_PROFILES)),) is not filtering for certain architectures implicitly.) I think the issue is connected to parallel builds. After comparing build logs which look pretty similar between amd64 and armel I suspected that there is some issue with parallel builds and forced --no-parallel with the result that the build now even fails for amd64: dh_auto_build --no-parallel --sourcedirectory src -- default java cd src && make -j1 "INSTALL=install --strip-program=true" default java make[2]: Entering directory '/build/libssw-1.1/src' g++ -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/libssw-1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -fPIC -shared -rdynamic -Wl,-soname,libssw.so.0 -o libssw.so.0 ssw.c ssw.h ssw_cpp.h ssw_cpp.cpp -Wl,-z,relro -Wl,-z,now cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/libssw-1.1=. -fstack-protector-strong -Wformat -Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -o ssw-align main.c kseq.h -L. -lssw -lm -lz -Wl,-z,relro -Wl,-z,now /usr/bin/ld: cannot find -lssw Michael Crusoe confirmed that The package builds for me on armel as of https://salsa.debian.org/med-team/libssw/-/commit/a19c146931e078e0e56abc85684f5a3583165e63 so perhaps the issue was introduced later? I admit I re-applied former patches to create a static lib which was kicked by the SIMDE patches but it seems I messed up the Makefile. Any second pair of eyeballs finding what I might have made wrong in Git[1] between the commit above and HEAD when re-adding the static lib that was droped at some point in time? Kind regards Andreas. [1] https://salsa.debian.org/med-team/libssw -- http://fam-tille.de
Re: [Help] f2j: ftbfs with GCC-10
On Wed, Aug 12, 2020 at 10:53:24AM +0100, Sudip Mukherjee wrote: > Try the attached patch. Thanks, this works Andreas. -- http://fam-tille.de
Linker issues for libssw on armel, mips64el and mipsel
Hi, while the package libssw builds nicely on most architectures on armel, mips64el and mipsel there is a linking issue[1]: ... c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -I"/include" -I"/include/linux" -I/usr/lib/jvm/default-java/include/ -I/usr/lib/jvm/default-java/include/linux -fPIC -shared -rdynamic -o libsswjni.so sswjni.c ssw.c -Wl,-z,relro -Wl,-z,now cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -o ssw-align main.c kseq.h -L. -lssw -lm -lz -Wl,-z,relro -Wl,-z,now /usr/bin/ld: cannot find -lssw ... (same on some non-released architectures). Any idea how to fix this? Kind regards Andreas. [1] https://buildd.debian.org/status/package.php?p=libssw -- http://fam-tille.de
[Help] f2j: ftbfs with GCC-10
Control: tags -1 help Hi, I think I've fixed part of the problem in Git[1]. Unfortunately there is a remainig "multiple definition" issue where I have no idea how to fix it: ex.o f2jmain.o symtab.o codegen.o vcg_emitter.o dlist.o typecheck.o optimize.o globals.o f2jmem.o -L/build/f2j-0.8.1+dfsg/libbytecode -lbytecode -Wl,-z,relro -Wl,-z,now /usr/bin/ld: optimize.o:./src/optimize.c:49: multiple definition of `unit_name'; codegen.o:./src/codegen.c:28: first defined here collect2: error: ld returned 1 exit status make[2]: *** [Makefile:20: f2java] Error 1 Any hint would be welcome Andreas. [1] https://salsa.debian.org/java-team/f2j/-/commit/fa634211dbef57ba6fda8121c3a565bafa73beed (please review) -- http://fam-tille.de
[Help] pvm: ftbfs with GCC-10
Hi,
while I do not intend to maintain pvm personally some Debian Med package
depend from it. Thus I like to see bug #957717 fixed but I need help.
I commited some general packaging changes so you can find the last
packaging state in Git[1]. When building this I get the following
output:
cc -DSYSVSIGNAL -DNOWAIT3 -DRSHCOMMAND=\"/usr/bin/rsh\" -DNEEDENDIAN
-DFDSETNOTSTRUCT -DHASERRORVARS -DHASSTDLIB -DCTIMEISTIMET -DSYSERRISCONST
-DNOTMPNAM -DSYSVSTR -DUSESTRERROR -g -O2
-fdebug-prefix-map=/build/pvm-3.4.6=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-DRSHCOMMAND="/usr/lib/pvm3/bin/rsh" -DPVMDPATH="pvmd"
-DPVMDFILE="/usr/bin/pvmd" -DPVM_DEFAULT_ROOT="/usr/lib/pvm3" -DOVERLOADHOST
-Wl,-z,relro -Wl,-z,now -fPIC -DCLUMP_ALLOC -DSTATISTICS -DTIMESTAMPLOG
-DSANITY -I/build/pvm-3.4.6/include -DARCHCLASS=\"LINUX64\" -DIMA_LINUX64 -c
/build/pvm-3.4.6/src/ddpro.c
: warning: "RSHCOMMAND" redefined
: note: this is the location of the previous definition
/build/pvm-3.4.6/src/ddpro.c: In function 'hostfailentry':
/build/pvm-3.4.6/src/ddpro.c:556:3: warning: implicit declaration of function
'pvmlogprintf' [-Wimplicit-function-declaration]
556 | pvmlogprintf("hostfailentry() host %s\n", hp->hd_name);
| ^~~~
/build/pvm-3.4.6/src/ddpro.c:561:3: warning: implicit declaration of function
'pvmlogerror'; did you mean 'pvm_perror'? [-Wimplicit-function-declaration]
561 | pvmlogerror("hostfailentry() lost master host, we're screwwwed\n");
| ^~~
| pvm_perror
/build/pvm-3.4.6/src/ddpro.c:575:3: warning: implicit declaration of function
'pkint'; did you mean 'printf'? [-Wimplicit-function-declaration]
575 | pkint(mp, hosts->ht_serial);
| ^
| printf
/build/pvm-3.4.6/src/ddpro.c:582:5: warning: implicit declaration of function
'sendmessage'; did you mean 'sendmsg'? [-Wimplicit-function-declaration]
582 | sendmessage(mp);
| ^~~
| sendmsg
/build/pvm-3.4.6/src/ddpro.c:656:7: warning: implicit declaration of function
'assign_tasks' [-Wimplicit-function-declaration]
656 | assign_tasks(wp);
| ^~~~
/build/pvm-3.4.6/src/ddpro.c:682:6: warning: implicit declaration of function
'free_waitc_add' [-Wimplicit-function-declaration]
682 | free_waitc_add((struct waitc_add *)wp->wa_spec);
| ^~
/build/pvm-3.4.6/src/ddpro.c:695:5: warning: implicit declaration of function
'mb_tidy' [-Wimplicit-function-declaration]
695 | mb_tidy(wp->wa_on);
| ^~~
/build/pvm-3.4.6/src/ddpro.c:703:5: warning: implicit declaration of function
'mb_tidy_reset' [-Wimplicit-function-declaration]
703 | mb_tidy_reset(wp->wa_on);
| ^
/build/pvm-3.4.6/src/ddpro.c: At top level:
/build/pvm-3.4.6/src/ddpro.c:821:1: warning: return type defaults to 'int'
[-Wimplicit-int]
821 | free_waitc_add(wxp)
| ^~
/build/pvm-3.4.6/src/ddpro.c: In function 'addhosts':
/build/pvm-3.4.6/src/ddpro.c:882:6: warning: implicit declaration of function
'upkint' [-Wimplicit-function-declaration]
882 | if (upkint(mp, ) || count < 1 || count > maxhostid) {
| ^~
/build/pvm-3.4.6/src/ddpro.c:903:7: warning: implicit declaration of function
'upkstralloc' [-Wimplicit-function-declaration]
903 | if (upkstralloc(mp, )) {
| ^~~
/build/pvm-3.4.6/src/ddpro.c:907:7: warning: implicit declaration of function
'parsehost' [-Wimplicit-function-declaration]
907 | if (parsehost(buf, hp)) {
| ^
/build/pvm-3.4.6/src/ddpro.c:917:5: warning: implicit declaration of function
'applydefaults' [-Wimplicit-function-declaration]
917 | applydefaults(hp, hp2);
| ^
: error: 'pvmd' undeclared (first use in this function)
/build/pvm-3.4.6/src/ddpro.c:1031:14: note: in expansion of macro 'PVMDPATH'
1031 | pvmdpath = PVMDPATH;
| ^~~~
: note: each undeclared identifier is reported only once for each
function it appears in
/build/pvm-3.4.6/src/ddpro.c:1031:14: note: in expansion of macro 'PVMDPATH'
1031 | pvmdpath = PVMDPATH;
| ^~~~
/build/pvm-3.4.6/src/ddpro.c:1039:3: warning: implicit declaration of function
'pkstr' [-Wimplicit-function-declaration]
1039 | pkstr(mp2, hp->hd_sopts ? hp->hd_sopts : "");
| ^
/build/pvm-3.4.6/src/ddpro.c:1133:5: warning: implicit declaration of function
'pvmlogperror'; did you mean 'pvm_perror'? [-Wimplicit-function-declaration]
1133 | pvmlogperror("addhosts() fork");
| ^~~~
| pvm_perror
/build/pvm-3.4.6/src/ddpro.c:1142:4: warning: implicit declaration of function
'beprime' [-Wimplicit-function-declaration]
1142 |beprime();
|^~~
/build/pvm-3.4.6/src/ddpro.c:1144:4: warning: implicit declaration of function
'hoster' [-Wimplicit-function-declaration]
1144 |hoster(mp2);
|^~
Re: Bug#957487: libzstd: ftbfs with GCC-10
Control: tags -1 help Hi, this issue is now RC and has not changed in current version 1.4.5. Any hint what to do? Kind regards Andreas. On Fri, Apr 17, 2020 at 11:05:08AM +, Matthias Klose wrote: > Package: src:libzstd > Version: 1.4.4+dfsg-3 > Severity: normal > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-10 > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc10-20200225/libzstd_1.4.4+dfsg-3_unstable_gcc10.log > The last lines of the build log are at the end of this report. > > To build with GCC 10, either set CC=gcc-10 CXX=g++-10 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-10/porting_to.html > > [...] > ==> compiling dynamic library 1.4.4 > cc -Wdate-time -D_FORTIFY_SOURCE=2 -I. -I./common -DXXH_NAMESPACE=ZSTD_ > -I./legacy -DZSTD_LEGACY_SUPPORT=5 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -DZSTD_LEGACY_MULTITHREADED_API common/debug.c > common/entropy_common.c common/error_private.c common/fse_decompress.c > common/pool.c common/threading.c common/xxhash.c common/zstd_common.c > compress/fse_compress.c compress/hist.c compress/huf_compress.c > compress/zstd_compress.c compress/zstd_compress_literals.c > compress/zstd_compress_sequences.c compress/zstd_double_fast.c > compress/zstd_fast.c compress/zstd_lazy.c compress/zstd_ldm.c > compress/zstd_opt.c compress/zstdmt_compress.c decompress/huf_decompress.c > decompress/zstd_ddict.c decompress/zstd_decompress.c > decompress/zstd_decompress_block.c deprecated/zbuff_common.c > deprecated/zbuff_compress.c deprecated/zbuff_decompress.c dictBuilder/cover.c > dictBuilder/divsufsort.c dictBuilder/fastcover.c dictBuilder/zdict.c > legacy/zstd_v05.c legacy/zstd_v06.c legacy/zstd_v07.c -Wl,-z,relro -Wl,-z,now > -shared -fPIC -fvisibility=hidden -Wl,-soname=libzstd.so.1 -o libzstd.so.1.4.4 > ==> compiling static library > ar rcs libzstd.a common/debug.o common/entropy_common.o > common/error_private.o common/fse_decompress.o common/pool.o > common/threading.o common/xxhash.o common/zstd_common.o > compress/fse_compress.o compress/hist.o compress/huf_compress.o > compress/zstd_compress.o compress/zstd_compress_literals.o > compress/zstd_compress_sequences.o compress/zstd_double_fast.o > compress/zstd_fast.o compress/zstd_lazy.o compress/zstd_ldm.o > compress/zstd_opt.o compress/zstdmt_compress.o decompress/huf_decompress.o > decompress/zstd_ddict.o decompress/zstd_decompress.o > decompress/zstd_decompress_block.o deprecated/zbuff_common.o > deprecated/zbuff_compress.o deprecated/zbuff_decompress.o dictBuilder/cover.o > dictBuilder/divsufsort.o dictBuilder/fastcover.o dictBuilder/zdict.o > legacy/zstd_v05.o legacy/zstd_v06.o legacy/zstd_v07.o > make[3]: Leaving directory '/<>/programs' > cp programs/zstd . > creating versioned links > ln -sf libzstd.so.1.4.4 libzstd.so.1 > ln -sf libzstd.so.1.4.4 libzstd.so > make[3]: Leaving directory '/<>/lib' > make[2]: Leaving directory '/<>' > dh_auto_build --sourcedirectory=contrib/pzstd/ -- pzstd > cd contrib/pzstd && make -j4 "INSTALL=install --strip-program=true" > pzstd > make[2]: Entering directory '/<>/contrib/pzstd' > g++ -MMD -MP -MF main.Td -Wdate-time -D_FORTIFY_SOURCE=2 -I../../lib > -I../../lib/common -I../../programs -I. -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -std=c++11 -c main.cpp -o main.o > g++ -MMD -MP -MF Options.Td -Wdate-time -D_FORTIFY_SOURCE=2 -I../../lib > -I../../lib/common -I../../programs -I. -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -std=c++11 -c Options.cpp -o Options.o > g++ -MMD -MP -MF Pzstd.Td -Wdate-time -D_FORTIFY_SOURCE=2 -I../../lib > -I../../lib/common -I../../programs -I. -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -std=c++11 -c Pzstd.cpp -o Pzstd.o > g++ -MMD -MP -MF SkippableFrame.Td -Wdate-time -D_FORTIFY_SOURCE=2 > -I../../lib -I../../lib/common -I../../programs -I. -g -O2 >
Help with C++ issue in sina needed
Hi,
the Debian Med team is working on Sina[1]
...
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I./include -DBOOST_TEST_DYN_LINK
-DBOOST_TEST_MAIN -pthread -I/usr/include -Wdate-time -D_FORTIFY_SOURCE=2
-DNDEBUG -g -O2 -fdebug-prefix-map=/build/sina-1.6.1=. -fstack-protector-strong
-Wformat -Werror=format-security -g -O2 -fdebug-prefix-map=/build/sina-1.6.1=.
-fstack-protector-strong -Wformat -Werror=format-security -W -c src/cseq.cpp
-fPIC -DPIC -o src/.libs/cseq.o
In file included from src/sina.cpp:62:
/usr/include/tbb/task_scheduler_init.h:21:154: note: #pragma message: TBB
Warning: tbb/task_scheduler_init.h is deprecated. For details, please see
Deprecated Features appendix in the TBB reference manual.
21 | #pragma message("TBB Warning: tbb/task_scheduler_init.h is deprecated.
For details, please see Deprecated Features appendix in the TBB reference
manual.")
|
^
src/sina.cpp: In function ‘int real_main(int, char**)’:
src/sina.cpp:404:29: warning: ‘template class
tbb::flow::interface11::source_node’ is deprecated: TBB Warning:
tbb::flow::source_node is deprecated, use tbb::flow::input_node.
[-Wdeprecated-declarations]
404 | using source_node = tf::source_node;
xd
| ^~~
re
In file included from src/sina.cpp:64:
de
/usr/include/tbb/flow_graph.h:1181:1: note: declared here
on
1181 | source_node : public graph_node, public sender< Output > {
to
| ^~~
on
src/align.cpp: In function ‘void sina::do_align(sina::cseq&, const cseq&,
MASTER&, transition&, std::ostream&)’:
src/align.cpp:481:55: error: ‘tbb_allocator’ is not a member of ‘tbb’
481 | using mesh_t = mesh>;
| ^
src/align.cpp:481:55: error: ‘tbb_allocator’ is not a member of ‘tbb’
src/align.cpp:481:69: error: template argument 4 is invalid
481 | using mesh_t = mesh>;
|
^
src/align.cpp:482:59: error: ‘mesh_t’ has not been declared
482 | logger->debug("Allocating {}MB for alignment matrix",
mesh_t::guessMem(m, c)/1024/1024);
...
Any hint how to fix this?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/sina
--
http://fam-tille.de
Re: Automake help to find boost_regexp needed
Hi, On Mon, Jun 22, 2020 at 04:06:56PM +0800, 铜豌豆 Linux wrote: > In my computer, I use dpkg-buildpackage, A, probably on your computer is pkg-config installed. Added to Build-Depends - works. Thanks for the inspiring information. > ./dgrep.cc:11: multiple definition of `dgrep_main(int, char**)'; > dgrep.o:./dgrep.cc:11: first defined here That's caused by my patch which was done to "provoke" and error when boost is not found. Thank you for your help Andreas. -- http://fam-tille.de
Automake help to find boost_regexp needed
Hi, in the Debian Med Covid-19 sprint I'm trying to package ufasta[1]. Unfortunately the configure step leads to checking for libboost_regex... no I wonder what I'm doing wrong here. Kind regards Andreas. [1] https://salsa.debian.org/med-team/ufasta -- http://fam-tille.de
How to properly deal with git lfs
Hi, in the covid-19 sprint of the Debian Med project we intend to package flappie[1]. When using the normal uscan download of the tarball some files that are kept in upstream git as lfs these files are corrupted (just links to the lfs location and non-functional inside the tarball). So I naively removed these files since I assumed it would be easy to download those data later but the header files here[2] are symlinks to the mdl files (which I removed) and thus the build does not work. I have two questions about dealing with this: 1. How to sensibly get a functional tarball of the latest release? Obviously its not the normal uscan. With Git mode I have no idea how to point to the latest tag and moreover I do not know how to ensure that git-lfs is installed. 2. How to properly deal with lfs support on salsa? I remember I once had trouble with this and would like to get hints to a simple guideline. Alternatively I would decide to simply keep the debian/ dir on Salsa (may be that's sensible in general for large archives anyway) - but this makes question 1. even more relevant Kind regards Andreas. [1] https://salsa.debian.org/med-team/flappie [2] https://github.com/nanoporetech/flappie/tree/master/src/models -- http://fam-tille.de
Re: cmake help needed for metabat
Hi Alexis,
thanks a lot for your extremely helpful explanation.
On Thu, May 28, 2020 at 10:04:02PM +0200, Alexis Murzeau wrote:
>
> There is a Debian patch that replace cmake/htslib.cmake with a
> pkg_check_modules call, which doesn't create targets, so that why it fails.
> There is the same issue with zlib, and a missing header
> "metabat_version.h" created by cmake/git-watcher.cmake.
>
>
> About HTSlib issue
> --
>
> With pkgconfig, you instead get just variables (no target), including
> these interesting ones:
> - HTSlib_LIBRARIES
> - HTSlib_INCLUDE_DIRS
>
> (The HTSlib comes from the first argument of pkg_check_modules)
>
> In cmake version 3.6 and later, an argument to pkg_check_modules can
> create a target to be used with target_link_libraries that will take
> care of the libraries and include dirs.
> This is the IMPORTED_TARGET option, it will create a target named
> PkgConfig::.
>
> So you can have:
> ```
> pkg_check_modules(HTSlib REQUIRED IMPORTED_TARGET htslib)
> ```
>
> and then use it:
> ```
> target_link_libraries(target [...] PkgConfig::HTSlib)
> ```
>
> But metabat seems to require only cmake 3.5, so it might not be allowed
> for upstream to do that.
>
> Instead you can just do the same as done for Boost and add:
> ```
> include_directories(${HTSlib_INCLUDE_DIRS})
> ```
> and
> ```
> target_link_libraries(target [...] ${HTSlib_INCLUDE_DIRS})
> ```
Makes sense.
> About zlib issue
>
>
> FindPackage(ZLIB) don't create any "zlib" target, but a "ZLIB::ZLIB"
> target instead, which can be used with target_link_libraries.
>
> So you can just replace the add_dependencies(target zlib) with a new
> item there:
> ```
> target_link_libraries(target [...] ZLIB::ZLIB)
> ```
>
> About the metabat_version.h header issue
>
>
> cmake/git-watcher.cmake generate metabat_version.h from
> metabat_version.h.in.
> So as with the patch, git-watcher.cmake is not used anymore, you still
> need to handle that.
>
> Either put fake stuff like this:
> ```
> set(PRE_CONFIGURE_FILE "metabat_version.h.in")
> set(POST_CONFIGURE_FILE "metabat_version.h")
> # include(cmake/git-watcher.cmake)
>
> # Add this:
> set(GIT_RETRIEVED_STATE "")
> set(GIT_HEAD_SHA1 "nosha")
> set(GIT_IS_DIRTY 0)
> set(BUILD_TIMESTAMP 0)
> configure_file("${PRE_CONFIGURE_FILE}" "${POST_CONFIGURE_FILE}" @ONLY)
> include_directories("${CMAKE_CURRENT_BINARY_DIR}")
> ```
>
> Or you change directly the code that use these defines to use different
> data (like Debian version instead).
Makes sense. I was not up to this issue - just was dealing with errors
step by step but I guess this would have been my next question. ;-)
Thanks a lot for the proactive answer.
> Conclusion
> --
>
> I'm attaching a patch with what I've said here.
> The build still doesn't work because of tests failure.
> The tests require data files like "contigs_depth.txt" but can't find them.
OK, I need to deal with this.
> In test/CMakeLists.txt, there is a reference to them as
> "${CMAKE_BINARY_DIR}/contigs_depth.txt", but it should be
> "${CMAKE_CURRENT_SOURCE_DIR}/contigs_depth.txt", unless the text files
> should be copied while building, but that doesn't seem the case.
I'll check upstream Git or file an issue about this.
Unfortunately your patch did not applied cleanly - no idea why. I have
added it manually and reread your explanation which I think are
implemented correctly. Unfortunately in my pbuilder I get the same
cmake failure as before and since I think I've now understand the issue
I'm even more in vain since its not working anyway for me but you
confirmed that it should work. Could you be so kind to have another
look on the latest state in Git?
Thanks again
Andreas.
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
> diff --git a/debian/patches/use_debian_packaged_libs.patch
> b/debian/patches/use_debian_packaged_libs.patch
> index 05c4a0e..b532dc9 100644
> --- a/debian/patches/use_debian_packaged_libs.patch
> +++ b/debian/patches/use_debian_packaged_libs.patch
> @@ -1,7 +1,15 @@
> -Author: Andreas Tille
> +From: Andreas Tille
> +Date: Thu, 28 May 2020 21:21:02 +0200
> +Subject: Use Debian packaged libraries
> +
> Last-Update: Thu, 28 May 2020 17:21:42 +0200
> -Description: Use Debian packaged libraries
> +---
> + CMakeLists.txt | 15 ---
> + src/CMakeLists.txt | 8
> + 2 files changed, 16 insertions(+), 7 deletions(-)
>
> +di
cmake help needed for metabat
Hi, I'm trying to package metabat[1] in the COVID-19 effort of the Debian Med team. I went forward with tweaking cmake but I'm now struck with: Installing None MetaBAT into /usr -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11"). -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2"). -- Checking for module 'htslib' -- Found htslib, version 1.10.2-3 -- Found Boost: /usr/include (found suitable version "1.67.0", minimum required is "1.55.0") found components: program_options filesystem system graph serialization iostreams regex. ... -- Configuring done CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "htslib" of target "contigOverlaps" does not exist. CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "zlib" of target "contigOverlaps" does not exist. CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "htslib" of target "jgi_summarize_bam_contig_depths" does not exist. CMake Error at src/CMakeLists.txt:51 (add_dependencies): The dependency target "zlib" of target "jgi_summarize_bam_contig_depths" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "htslib" of target "metabat2" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "zlib" of target "metabat2" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "htslib" of target "metabat1" does not exist. CMake Error at src/CMakeLists.txt:39 (add_dependencies): The dependency target "zlib" of target "metabat1" does not exist. ... This is strange since in the beginning zlib and htslib were found due to the means I did. Any hint would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/metabat -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Adrian, On Mon, May 11, 2020 at 10:04:24AM +0300, Adrian Bunk wrote: > A bug buried somewhere in the Debian bts would not change anything. Probably that's correct. > What would have to happen would be a Debian MIPS porter debugging > this problem and then submitting a minimal testcase to gcc upstream. I'd be really happy about this. > Assuming this will be confirmed to be a mipsel-specific gcc bug, > this looks likely but it is still possible that there actually > is a bug in clustalo that works by chance on other architectures. > Unlikely, but not impossible. The debugging sessions on clustalo and suggested patches uncovered code parts that are not looking nice - so I have no idea about the likelihood of this. For me it seems a possibility that should be kept in mind and which is why I tried my best to support the debugging sessions. > In a more positive note, I assume people would have already noticed if > OpenMP on mipsel in stable and unstable would be completely broken. Probably. Kind regards Andreas. -- http://fam-tille.de
How to build static and shared library with meson (Was: Bug#959409: pbcopper breaks pbbam)
Hi, On Sun, May 10, 2020 at 08:10:48PM +0300, Adrian Bunk wrote: > Control: reassign -1 libpbcopper1.3.0 1.4.0+dfsg-1 > Control: affects -1 src:pbbam > ... > $ objdump -p /usr/lib/x86_64-linux-gnu/libpbcopper.so.1.6.0 | grep SONAME > SONAME libpbcopper.so.1.6.0 > > With this SONAME, which looks correct if ABI changes with each 1.x.y > release, the general package naming is correct. When checking this package I'd like to fix this by using d-shlibs to make sure that kind of mistake will not happen in future. Since d-shlibs is requiring a static library for the -dev package I'd like to change the build system to provide both shared and static lib. Unfortunately I'm not familiar with meson build system. Is there any easy example to build both libs? Kind regards Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
On Sun, May 10, 2020 at 03:51:28PM -0400, Jeffrey Walton wrote: > > I've now uploaded now with this patch closing the bug - but as I tried to > > express I'd sleep a bit better if this issue would be recorded somewhere > > else than in a closed bug. > > Maybe GCC? I believe the component is libgomp. > > If you have a good idea of the problematic source file, then add the > preprocessoed source with the report. Also see > https://gcc.gnu.org/bugs/. > > If you don't have an idea, then maybe someone like Andrew or Ian can > provide some suggestions. I admit I don't have any idea, sorry. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Adrian, thanks a lot for your investigation. On Sun, May 10, 2020 at 11:19:27AM +0300, Adrian Bunk wrote: > What does fix the problem is disabling OpenMP. > I suspect OpenMP is somehow broken in gcc >= 8 on mipsel. I wonder how we could keep this finding to other packages. I bet it would not the only issue but it has shown up due to intense testing. > Below is a workaround patch (lower performance of clustalo on mipsel > shouldn't be a major problem). Its definitely no problem - I doubt that the package is used at all on mipsel. Its simply of theoretical interest and might uncover hidden issues (finally some suggestions to enhance the code were found not only for mipsel). > --- clustalo-1.2.4/debian/rules 2020-04-14 12:19:44.0 +0300 > +++ clustalo-1.2.4/debian/rules 2020-04-14 12:19:44.0 +0300 > @@ -9,6 +9,11 @@ > %: > dh $@ > > +ifneq (,$(filter $(DEB_HOST_ARCH), mipsel)) > +override_dh_auto_configure: > + dh_auto_configure -- --without-openmp > +endif > + > override_dh_auto_build-indep: > # nothing to do here I've now uploaded now with this patch closing the bug - but as I tried to express I'd sleep a bit better if this issue would be recorded somewhere else than in a closed bug. Thanks again for your research Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Thu, Apr 30, 2020 at 05:53:29PM -0700, Matthew Fernandez wrote: > > Is the priority goal here to simply ship a non-crashing clustalo mipsel > binary that BioPython can depend on? If so, maybe we can just disable > compiler optimisation (-O0) and this may avoid provoking the bus error. Of > course this doesn’t fix the underlying problem(s), but it looks as if > debugging this to its root cause is going to result in the Debian package > carrying a lot of invasive dquilt patches on top of upstream. OTOH I don’t > know the performance requirements of BioPython and maybe an unoptimised > clustalo is unacceptable to it. I need to admit the priority goal is to be really sure that the clustalo code has no hidden issues which might crash on architectures that are used in practical applications. I would have no problems to simply exclude clustalo for mipsel architecture completely - if I could be sure that it works properly. So the major reason for this debugging session is to make sure that clustalo runs properly *on all other* architectures while loosing mipsel would be no real loss for practival usage of clustalo and its rdepends. To follow your hints I cared for -O0 optimisation flags (which is possible via configure options which uncovers some syntax errors in comments :-( which I fixed as well) and tried to rebuild on the mipsel host provided by Debian. Unfortunately the bus error remains. Due to the advise here that valgrind works properly only for -O0 I'm reposting the valgrind output here: (sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind -s src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==13209== Memcheck, a memory error detector ==13209== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==13209== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==13209== Command: src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==13209== ==13209== Conditional jump or move depends on uninitialised value(s) ==13209==at 0x4007828: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57) ==13209==by 0x4007828: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217) ==13209==by 0x4008080: open_verify.constprop.0 (dl-load.c:1688) ==13209==by 0x4009D7C: _dl_map_object (dl-load.c:2181) ==13209==by 0x40011F8: map_doit (rtld.c:607) ==13209==by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196) ==13209==by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215) ==13209==by 0x4001138: do_preload (rtld.c:778) ==13209==by 0x4002560: handle_preload_list (rtld.c:879) ==13209==by 0x4005B08: dl_main (rtld.c:1684) ==13209==by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253) ==13209==by 0x400199C: _dl_start_final (rtld.c:447) ==13209==by 0x4001D44: _dl_start (rtld.c:539) ==13209== ==13209== Invalid read of size 1 ==13209==at 0x486F558: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==13209==by 0x486F5F0: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==13209== Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd ==13209==at 0x484B89C: malloc (in /usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so) ==13209==by 0x134D1C: CkMalloc (util.c:83) ==13209== ==13209== Invalid read of size 4 ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346) ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835) ==13209==by 0x11A6C4: Align (clustal-omega.c:1221) ==13209==by 0x1171C8: MyMain (mymain.c:1192) ==13209==by 0x113CCC: main (main.cpp:469) ==13209== Address 0x8060 is not stack'd, malloc'd or (recently) free'd ==13209== ==13209== ==13209== Process terminating with default action of signal 10 (SIGBUS) ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346) ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835) ==13209==by 0x11A6C4: Align (clustal-omega.c:1221) ==13209==by 0x1171C8: MyMain (mymain.c:1192) ==13209==by 0x113CCC: main (main.cpp:469) ==13209== ==13209== HEAP SUMMARY: ==13209== in use at exit: 8,039 bytes in 34 blocks ==13209== total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated ==13209== ==13209== LEAK SUMMARY: ==13209==definitely lost: 128 bytes in 2 blocks ==13209==indirectly lost: 0 bytes in 0 blocks ==13209== possibly lost: 0 bytes in 0 blocks ==13209==still reachable: 7,911 bytes in 32 blocks ==13209== suppressed: 0 bytes in 0 blocks ==13209== Rerun with --leak-check=full to see details of leaked memory ==13209== ==13209== Use --track-origins=yes to see where uninitialised values come from ==13209== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) ==13209== ==13209== 1 errors in context 1 of 3: ==13209== Invalid read of size 4 ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Jeffrey,
thanks a lot for this analysis. Any chance that somebody could
turn this into a patch I could try?
Kind regards
Andreas.
On Thu, Apr 30, 2020 at 03:40:12PM -0400, Jeffrey Walton wrote:
> On Fri, Apr 17, 2020 at 7:21 AM Andreas Tille wrote:
> > ...
> > So it seems the bus error occures somehow here:
> >
> >
> > https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346
>
> NewProgress is at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.c#L53.
> It uses a progress_t at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/progress.h#L25.
>
> typedef struct {
> /* where to write to */
> FILE *prFile;
> /* prefix printed before each step */
> char *pcPrefix;
> bool bPrintCR;
> char pcLastLogMsg[1024];
> Stopwatch_t *prStopwatch;
> } progress_t;
>
> And stopwatch_t at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.h:
>
> struct stopwatch_s {
> time_t t0; /* Wall clock time, ANSI time() */
> #ifdef SRE_STRICT_ANSI
> clock_t cpu0; /* CPU time, ANSI clock()*/
> #else
> struct tms cpu0; /* CPU/system time, POSIX times()*/
> #endif
>
> double elapsed; /* elapsed time, seconds */
> double user; /* CPU time, seconds */
> double sys; /* system time, seconds */
> };
>
> There are your doubles that are likely the problem.
>
> And what do we have here at
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/squid/stopwatch.c#L276
> ...
>
> void
> StopwatchPVMPack(Stopwatch_t *w)
> {
> pvm_pkdouble(&(w->elapsed), 1, 1);
> pvm_pkdouble(&(w->user),1, 1);
> pvm_pkdouble(&(w->sys), 1, 1);
> }
> void
> StopwatchPVMUnpack(Stopwatch_t *w)
> {
> pvm_upkdouble(&(w->elapsed), 1, 1);
> pvm_upkdouble(&(w->user),1, 1);
> pvm_upkdouble(&(w->sys), 1, 1);
> }
>
> I can't track the trail any further. The source code is missing for
> pvm_pkdouble and pvm_upkdouble. I would be very suspect of
> pvm_pkdouble and pvm_upkdouble.
>
> Jeff
>
--
http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
On Thu, Apr 30, 2020 at 07:17:50AM -0700, Matthew Fernandez wrote: > > Valgrind, in its default mode, checks for a variety of memory issues > (use-after-free, write out-of bounds, …). You don’t need any special > configure/build options, but you probably want to enable debug symbols > (`export CFLAGS=-g; export CXXFLAGS=-g`). Then you can prefix the test you’re > running with Valgrind: `valgrind ./src/clustalo -i > debian/tests/biopython_testdata/f002 …`. Running on mipsel: (sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==15149== Memcheck, a memory error detector ==15149== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==15149== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==15149== Command: src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force ==15149== ==15149== Conditional jump or move depends on uninitialised value(s) ==15149==at 0x4007828: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57) ==15149==by 0x4007828: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217) ==15149==by 0x4008080: open_verify.constprop.0 (dl-load.c:1688) ==15149==by 0x4009D7C: _dl_map_object (dl-load.c:2181) ==15149==by 0x40011F8: map_doit (rtld.c:607) ==15149==by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196) ==15149==by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215) ==15149==by 0x4001138: do_preload (rtld.c:778) ==15149==by 0x4002560: handle_preload_list (rtld.c:879) ==15149==by 0x4005B08: dl_main (rtld.c:1684) ==15149==by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253) ==15149==by 0x400199C: _dl_start_final (rtld.c:447) ==15149==by 0x4001D44: _dl_start (rtld.c:539) ==15149== ==15149== Invalid read of size 1 ==15149==at 0x486F558: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==15149==by 0x486F5F0: ??? (in /usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8) ==15149== Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd ==15149==at 0x484B89C: malloc (in /usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so) ==15149==by 0x126674: CkMalloc (util.c:83) ==15149==by 0x126864: CkStrdup (util.c:213) ==15149==by 0x1108F4: ConvertOldCmdline(int*, char***, int, char**) (main.cpp:358) ==15149==by 0x10FCDC: main (main.cpp:467) ==15149== ==15149== Invalid read of size 4 ==15149==at 0x1221B8: PairDistances (pair_dist.c:346) ==15149==by 0x114774: AlignmentOrder (clustal-omega.c:835) ==15149==by 0x115024: Align (clustal-omega.c:1221) ==15149==by 0x112EB4: MyMain (mymain.c:1192) ==15149==by 0x10FCF0: main (main.cpp:469) ==15149== Address 0x83b0 is not stack'd, malloc'd or (recently) free'd ==15149== ==15149== ==15149== Process terminating with default action of signal 10 (SIGBUS) ==15149==at 0x1221B8: PairDistances (pair_dist.c:346) ==15149==by 0x114774: AlignmentOrder (clustal-omega.c:835) ==15149==by 0x115024: Align (clustal-omega.c:1221) ==15149==by 0x112EB4: MyMain (mymain.c:1192) ==15149==by 0x10FCF0: main (main.cpp:469) ==15149== ==15149== HEAP SUMMARY: ==15149== in use at exit: 8,039 bytes in 34 blocks ==15149== total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated ==15149== ==15149== LEAK SUMMARY: ==15149==definitely lost: 128 bytes in 2 blocks ==15149==indirectly lost: 0 bytes in 0 blocks ==15149== possibly lost: 0 bytes in 0 blocks ==15149==still reachable: 7,911 bytes in 32 blocks ==15149== suppressed: 0 bytes in 0 blocks ==15149== Rerun with --leak-check=full to see details of leaked memory ==15149== ==15149== Use --track-origins=yes to see where uninitialised values come from ==15149== For lists of detected and suppressed errors, rerun with: -s ==15149== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) Bus error Is this different from your tests on amd64? > > On the other hand: Is valgrind possibly able to uncover issues also > > on any other architecture? > > You mean if we were to use Valgrind to debug this on e.g. x86? In my own > experiments on amd64, both ASan and Valgrind found multiple issues in both > Clustal Omega and its dependency, argtable2. However I don’t believe any of > the remaining ones I was seeing after the last patches I sent you could be > causing the mipsel bus error; they were all memory leaks. Thanks again for your great support and the time you've spent. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Wed, Apr 29, 2020 at 05:51:26PM -0700, Matthew Fernandez wrote: > > Any more help from debian-mipsel is really appreciated. > > Hm yes, “--disable-libsanitizer” is rather ominous. I guess the mipsel GCC > package has been built without ASan support. Surprising that it fails so > messily (the front end seems to think -fsanitize=address is an accepted > command line option), but libasan does indeed seem not available on mipsel > [0]. OK, so it seems this method to track down the issue on mips does not work. > The other option I suggested was Valgrind, but if you can’t run apt-file you > probably can’t install Valgrind either. Well, I guess apt-get is permitted for sudo but not apt-file. So I can probably install valgrind inside the chroot environment. I've never worked with valgrind. What am I supposed to do? On the other hand: Is valgrind possibly able to uncover issues also on any other architecture? > If anyone spectating has ideas, please chime in. Definitely. We obviously could need some help. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Wed, Apr 29, 2020 at 07:14:30AM -0700, Matthew Fernandez wrote: > > To add another data point to this discussion, one other (fruitless) thing I > tried previously was cross-compiling Clustal Omega. From an amd64 host, it’s > possible to target mipsel using the GCC cross-compilers in the standard > Debian repositories. You can then run the resulting binary using Qemu’s user > mode. Using this technique, the f002 test runs to completion with no bus > error. This is not really surprising as AFAIK unaligned accesses that would > trigger a bus error on mipsel hardware would be silently allowed in this > configuration (Qemu doesn’t faithfully emulate this hardware behaviour and > amd64 allows unaligned access). > > Unfortunately the repositories’ cross-compilers have been built without ASan > enabled and you can’t attach to an emulated mipsel process with a native > Valgrind. So debugging memory safety issues is not straightforward. To go > further with this approach, you would have to build a mipsel-targeting > cross-compiler with ASan enabled or cross-compile Valgrind to mipsel. For a > true masochist, it may be possible to attach to the process with GDB or rr > and reverse-step from the location Andreas has quoted, but I wouldn’t trust > the debugger not to crash in this configuration. Even then the issue may not > be reproducible because it may be dependent on transformations/optimizations > only performed by the particular version of the native mipsel compiler called > during packaging. Thanks a lot for your effort. > For those on this thread who have access to mipsel hardware or can shell in > to one of the mipsel build machines, I would suggest running an > ASan-instrumented test there (`export CFLAGS="-g -fsanitize=address"; export > CXXFLAGS="-g -fsanitize=address"`) and see what we learn. I tried on real hardware. Unfortunately I'm running into configure:3720: $? = 0 configure:3709: gcc -v >&5 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/mipsel-linux-gnu/9/lto-wrapper Target: mipsel-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-10' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=mipsel-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --disable-werror --enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all --with-arch-64=mips64r2 --enable-checking=release --build=mipsel-linux-gnu --host=mipsel-linux-gnu --target=mipsel-linux-gnu Thread model: posix gcc version 9.3.0 (Debian 9.3.0-10) configure:3720: $? = 0 configure:3709: gcc -V >&5 gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated. configure:3720: $? = 1 configure:3709: gcc -qversion >&5 gcc: error: unrecognized command line option '-qversion'; did you mean '--version'? gcc: fatal error: no input files compilation terminated. configure:3720: $? = 1 configure:3740: checking whether the C compiler works configure:3762: gcc -g -O2 -fdebug-prefix-map=/home/tille/clustalo=. -fstack-protector-strong -Wformat -Werror=format-security -fsanitize=address -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now conftest.c >&5 /usr/bin/ld: cannot find libasan_preinit.o: No such file or directory /usr/bin/ld: cannot find -lasan collect2: error: ld returned 1 exit status configure:3766: $? = 1 configure:3804: result: no configure: failed program was: I have no idea why libasan_preinit.o and libasan.a are not installed. The package libgcc-9-dev is installed for sure and on amd64 both files are included here. It seems the sudo command on eller does not permit me executing `apt-file update` in a chroot so I have no idea where these files are on mipsel (if they exist at all). Any more help from debian-mipsel is really appreciated. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi, On Wed, Apr 29, 2020 at 10:30:35AM +0800, 黄佳文 wrote: > I am a developer from Loongson company (R & D CPU/mip64el), I've been > looking at this recently. Very nice to see mips developers to care for biological software. :-) > I did two experiments, and I found that when I used Python 3,7 to compile > python-biopython, Build successfully. > In the same environment, I just upgrade Python 3.7 to Python 3.8, and then > compile python-biopytho, Build fails, but not bus error. > I found through online query that some symbol tables were added and deleted > in upgrading Python 3.7 to 3.8. The following are symbol tables: Sorry to insist here - I do not think that it is a Python version problem at all. The issue can be reproduced in clustalo only which is pure C code. May be you have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956324#59 and the following discussion. Despite Matthew has found some issues inside the C code it did not helped to prevent: Starting program: /home/tille/clustalo/src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1". Program received signal SIGBUS, Bus error. 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, pairdist_type=, bPercID=, istart=0, iend=3, jstart=0, jend=3, fdist_in=0x0, fdist_out=0x0) at pair_dist.c:346 346 NewProgress(, LogGetFP(, LOG_INFO), That's the issue we need to care about here. Kind regards and thanks a lot for the attempt to help Andreas.
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, many thanks again for your investigation. On Sat, Apr 18, 2020 at 01:15:49PM -0700, Matthew Fernandez wrote: > > Upstream is in the row of this investigation. Its quite interesting > > that the issue could also observed on amd64. So probably this is a real > > issue which is just exposed on mipsel. I think just bumping the array > > boundaries is cheap. If there will be no response from upstream (or > > somebody else who is comfortable with the algorithm which I'm not) I'll > > check again on mipsel and in case it will work I'll upload. > > Fair enough. While we’re discussing this, here’s another patch for a memory > leak that fixes a typoed ifdef and a missing free(): > > diff --git a/src/squid/clustal.c b/src/squid/clustal.c > index 650004a..bb1fec8 100644 > --- a/src/squid/clustal.c > +++ b/src/squid/clustal.c > @@ -207,7 +207,7 @@ WriteClustal(FILE *fp, MSA *msa) >intnamelen; /* maximum name length used */ >intpos; /* position counter */ > #ifdef CLUSTALO > - char *buf; /* buffer for writing seq*/ > + char *buf = NULL; /* buffer for writing seq > */ >intcpl = msa->alenalen+10 : (iWrap > 0 ? iWrap : > 60); /* char per line (< 64) */ > #else >char buf[80]; /* buffer for writing seq*/ > @@ -410,8 +410,9 @@ WriteClustal(FILE *fp, MSA *msa) > #endif > } > > -#ifdef CLUSTAL > +#ifdef CLUSTALO >free(piResCnt); piResCnt = NULL; > + free(buf); buf = NULL; > #endif > >return; I tried the suggested patches again step by step on mipsel but the bus error issue remains. :-( Kind regards Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew,
thanks a lot for your detailed investigation.
On Fri, Apr 17, 2020 at 04:28:23PM -0700, Matthew Fernandez wrote:
> > Program received signal SIGBUS, Bus error.
> > 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30,
> > pairdist_type=, bPercID=, istart=0, iend=3,
> > jstart=0, jend=3, fdist_in=0x0,
> >fdist_out=0x0) at pair_dist.c:346
> > 346 NewProgress(, LogGetFP(, LOG_INFO),
>
> OK, let me try a little harder :)
>
> $ # enable debugging symbols and Address Sanitizer
> $ CFLAGS="-g -fsanitize=address" CXXFLAGS="-g -fsanitize=address"
> ./configure
> …
> $ make clean && make
> …
> $ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> =
> ==30264==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on
> address 0x7ffcfcbf5784 at pc 0x5620f0aa478c bp 0x7ffcfcbf56c0 sp
> 0x7ffcfcbf56b8
> WRITE of size 4 at 0x7ffcfcbf5784 thread T0
> #0 0x5620f0aa478b in PairDistances
> /home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336
> #1 0x5620f0a91d9f in AlignmentOrder
> /home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:835
> #2 0x5620f0a95c04 in Align
> /home/matthew/clustal-omega-1.2.4/src/clustal-omega.c:1221
> #3 0x5620f0a90d76 in MyMain
> /home/matthew/clustal-omega-1.2.4/src/mymain.c:1192
> #4 0x5620f0a88ca2 in main
> /home/matthew/clustal-omega-1.2.4/src/main.cpp:469
> #5 0x7f3773d9009a in __libc_start_main ../csu/libc-start.c:308
> #6 0x5620f0a89ad9 in _start
> (/home/matthew/clustal-omega-1.2.4/src/clustalo+0x2dad9)
>
> Address 0x7ffcfcbf5784 is located in stack of thread T0
> SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow
> /home/matthew/clustal-omega-1.2.4/src/clustal/pair_dist.c:336 in PairDistances
> Shadow bytes around the buggy address:
> 0x10001f976aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001f976ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001f976ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001f976ad0: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca
> 0x10001f976ae0: 04 cb cb cb cb cb cb cb 00 00 00 00 ca ca ca ca
> =>0x10001f976af0:[04]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00
> 0x10001f976b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001f976b10: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2
> 0x10001f976b20: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
> 0x10001f976b30: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
> 0x10001f976b40: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user:f7
> Container overflow: fc
> Array cookie:ac
> Intra object redzone:bb
> ASan internal: fe
> Left alloca redzone: ca
> Right alloca redzone:cb
> ==30264==ABORTING
>
> Looking at line 336 of pair_dist.c, it looks like the bound on the containing
> loop is wrong. So let’s try adjusting that:
>
> $ vim src/clustal/pair_dist.c
> $ git diff src/clustal/pair_dist.c
> diff --git a/src/clustal/pair_dist.c b/src/clustal/pair_dist.c
> index e6dbdc3..bb79e61 100644
> --- a/src/clustal/pair_dist.c
> +++ b/src/clustal/pair_dist.c
> @@ -321,7 +321,7 @@ PairDistances(symmatrix_t **distmat, mseq_t *mseq,
> int pairdist_type, bool bPerc
>
> /* FIXME: can get rid of iChunkStart, iChunkEnd now that we're
> using the arrays */
> iChunkStart = iend;
> -for(iChunk = 0; iChunk <= iNumberOfThreads; iChunk++)
> +for(iChunk = 0; iChunk < iNumberOfThreads; iChunk++)
> {
> iChunkEnd = iChunkStart;
> if (iChunk == iNumberOfThreads - 1){
> $ make
> …
> $ ./src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out
> temp_test.dnd -o temp_test.aln --outfmt clustal --force
> =
> ==30601==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x561188847864 at pc 0x5611886da6e7 bp 0x7fffe6d77ef0 sp 0x7fffe6d77ee8
> READ of size 4 at 0x561188847864 thread T0
> #0 0x5611886da6e6 in FullAlignment::Build(HMM&, Hit&, char*)
>
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Fri, Apr 17, 2020 at 08:18:29AM -0700, Matthew Fernandez wrote: > > Thanks for the patch which I applied to packaging Git. I assume you > > want to express that while these fixes are definitely good coding > > practice the bus error problem is not fixed by it, right? > > Thanks, Andreas. It may fix the bus error, but I don’t have a MIPS machine > to test on. Some of those logging calls had the potential to leave you with > a misaligned stack pointer. IIUC unaligned loads on MIPS could cause such a > bus error. I tried with hope ... but failed: (sid_mipsel-dchroot)tille@eller:~/clustalo$ gdb --args src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force GNU gdb (Debian 9.1-3) 9.1 ... Reading symbols from src/clustalo... (gdb) run Starting program: /home/tille/clustalo/src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1". Program received signal SIGBUS, Bus error. 0x5556a1b8 in PairDistances (distmat=0x7fff278c, mseq=0x55692a30, pairdist_type=, bPercID=, istart=0, iend=3, jstart=0, jend=3, fdist_in=0x0, fdist_out=0x0) at pair_dist.c:346 346 NewProgress(, LogGetFP(, LOG_INFO), Thank you for the fixes anyway Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Hi Matthew, On Fri, Apr 17, 2020 at 07:40:54AM -0700, Matthew Fernandez wrote: > > As a jumping off point, the attached patch fixes some issues with logging > calls in the upstream 1.2.4 source release. Thanks for the patch which I applied to packaging Git. I assume you want to express that while these fixes are definitely good coding practice the bus error problem is not fixed by it, right? Kind regards and thank a lot in any case Andreas. -- http://fam-tille.de
Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)
Control: tags -1 help Hi, as it can be seen on the recent build log of clustalo on mips[1] the build fails with # Run additional test from python-biopython package to verify that # this will work as well src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force make[1]: *** [debian/rules:25: override_dh_auto_test-arch] Bus error I injected that extra test since this very test failed inside the python-biopython package. To track it down I logged in to eller.debian.org tried to build the package and was able to reproduce the error. Thus I fired up gdb in this session and got: (sid_mipsel-dchroot)tille@eller:~/clustalo-1.2.4$ gdb --args src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force GNU gdb (Debian 9.1-3) 9.1 ... Reading symbols from src/clustalo... (gdb) run Starting program: /home/tille/clustalo-1.2.4/src/clustalo -i debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/mipsel-linux-gnu/libthread_db.so.1". Program received signal SIGBUS, Bus error. 0x5556a188 in PairDistances (distmat=0x7fff278c, mseq=0x55692a38, pairdist_type=, bPercID=, istart=0, iend=3, jstart=0, jend=3, fdist_in=0x0, fdist_out=0x0) at pair_dist.c:346 346 NewProgress(, LogGetFP(, LOG_INFO), (gdb) So it seems the bus error occures somehow here: https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346 I have no idea how to continue from here. I'm hoping that someone with some more detailed knowledge might have a clue how to fix this issue on mipsel. Otherwise I personally do not see any better solution than to remove clustalo from mipsel architecture. Kind regards Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=clustalo=mipsel=1.2.4-5=1586883766=0 -- http://fam-tille.de
Re: Help to enable test suite precondition for covid-19 relevant R package
Hi, thanks a lot for these helpful hints. On Mon, Apr 06, 2020 at 08:51:57PM +0100, jnq...@gmail.com wrote: > > without looking at any of the packages, at all, you say you're > unfamiliar with Rust, so perhaps the following hints will be helpful: > 1. you can use the Rustc compiler (rustc) directly unless you actually > need to make use of a Cargo project file (Cargo.toml). I was simply following what upstream code was specifying as requriement (which probably makes perfectly sense when not using a Debian chroot that has no remote access). > 2. `cargo` has an `--offline` option to run without network access. > Cargo is built around the concept of "crates" (libraries) being > available on crates.io, which projects can depend upon by specifying > dependencies in Cargo.toml (though it is also possible to have > dependencies hosted elsewhere), and which cargo can automatically > download, compile and link when building your project. Cargo can thus > have a need to retrieve an updated index of available crates (just like > apt update), requiring internet access, as well as needing internet > access to fetch depended upon crates that you have not already got > cached. You can however as I just mentioned run it in offline mode > whereby it tries to proceed with cached dependencies only. I'll keep a record of these helpful hints in Git of that package. It turned out that I can use r-cran-av as an alternative which for the intended purpose works out of the box. So I'll delay this for the future if there might be some need, thought. Thanks again Andreas. -- http://fam-tille.de
Re: [covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)
On Mon, Apr 06, 2020 at 08:53:12PM +0100, Jeremy Sowden wrote: > > Thanks a lot for your help anyway > > Patch attached. Thank you so much again, Andreas. -- http://fam-tille.de
Help to enable test suite precondition for covid-19 relevant R package
Hi, the cran package r-cran-gganimate requires r-cran-gifski to run its test suite. I've prepared the latter in Git[1]. To build the package a rust compiler is needed which I provided via Build-Depends: cargo. Unfortunately there will be some Rust modules needed which the build process tries to download: ... gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-pthread -fvisibility=hidden -fpic -g -O2 -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. -fstack-protector-strong -Wformat -W /usr/bin/cargo build --release --manifest-path=myrustlib/Cargo.toml Updating crates.io index warning: spurious network error (2 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12) warning: spurious network error (1 tries remaining): failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12) error: failed to fetch `https://github.com/rust-lang/crates.io-index` Caused by: failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12) make[1]: *** [Makevars:12: myrustlib/target/release/libmyrustlib.a] Error 101 ... Since I have no idea about rust: How can I find out what extra module is needed and do we possibly have a package of it I could use as Build-Depends? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-gifski -- http://fam-tille.de
[covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)
Hi Jeremy, On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote: > On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote: > >dh_autoreconf -O--buildsystem=R > > autoheader: warning: missing template: HAVE_OPENMP > > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description]) > > autoreconf: /usr/bin/autoheader failed with exit status: 1 > > dh_autoreconf: error: autoreconf -f -i returned exit code 1 > > make: *** [debian/rules:4: binary] Error 25 > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > > status 2 > > Similar to some of the problems with mpqc yesterday. Patch attached. Thanks a lot for your patch (commited to Git[1]) which solved the autoconf issue. Unfortunately there is another issue now: ecking for stdint.h... yes checking for unistd.h... yes checking dispatch/dispatch.h usability... no checking dispatch/dispatch.h presence... no checking for dispatch/dispatch.h... no checking whether OpenMP will work in a package... yes configure: creating ./config.status config.status: creating src/Makevars config.status: creating src/config.h ** libs make[1]: Entering directory '/build/r-bioc-rgadem-2.34.1/src' gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g -O2 -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c Gadem_Analysis.c -o Gadem_Analysis.o Gadem_Analysis.c: In function 'GADEM_Analysis': Gadem_Analysis.c:618:7: warning: implicit declaration of function 'DO_APPLY' [-Wimplicit-function-declaration] 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii, | ^~~~ Gadem_Analysis.c:618:16: error: invalid use of void expression 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii, |^~~ 619 | startPWMfound, minminSites, maxpFactor[ii], | ~~~ 620 | numSeq, numSeqEM, seq, rseq, seqLen, Iseq, | ~~ 621 | bfreq0, posWeight, weightType, | ~~ 622 | pvalueCutoff, emSeqLen, | ~~~ 623 | pwm[ii], pwmLen[ii], epwm[ii], opwm[ii], | 624 | pwmConsensus[ii], scoreCutoff+ii, sdyad[ii], ii), | make[1]: *** [/usr/lib/R/etc/Makeconf:168: Gadem_Analysis.o] Error 1 Thanks a lot for your help anyway Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-rgadem -- http://fam-tille.de
[covid-19] Help with r-bioc-rgadem needed
Hi, since I did not got any response from r-pkg team yet I guess nobody has a clue about this autoconf issue. So I'd like to forward this question here to finalise a package which is relevant for our COVID-19 Biohackathon. I injected r-bioc-rgadem[1] but the build ends in: dh_autoreconf -O--buildsystem=R autoheader: warning: missing template: HAVE_OPENMP autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description]) autoreconf: /usr/bin/autoheader failed with exit status: 1 dh_autoreconf: error: autoreconf -f -i returned exit code 1 make: *** [debian/rules:4: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Any hint would be welcome Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-rgadem -- http://fam-tille.de
Re: Autoconf issue in mpqc
On Sun, Apr 05, 2020 at 12:34:55PM +0100, Jeremy Sowden wrote: > > > I've attached the part or the build log that seems to be autoconf > > > relevant. I admit I'm a bit astonished since I can only see > > > warnings but no error ... > > > > Here's a patch that fixes the autoheader warnings. > > Whoops. That version doesn't seem to apply. The patch I've attached to > this message I have actually tested properly. > > > autoreconf is still failing. > > That's not quite right: "autoreconf" fails, but "autoreconf -f -i" > (which is what dh_autoreconf does) succeeds. Now dh_auto_configure > fails. I confirm it fails with ... checking if semctl requires semun... no checking if fortran compiler works... no configure: error: in `/build/mpqc-2.3.1': configure: error: fortran compiler does not work I've updated Git with your patch - thanks a lot so far. Kind regards Andreas. -- http://fam-tille.de
Re: Autoconf issue in mpqc
Hi Jeremy, On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote: > > Any help would be appreciated. > > > > [1] https://salsa.debian.org/debichem-team/mpqc > > Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch > attached). Thanks a lot for the promising patch I have commited to Git[1]. Unfortunately the build does not yet succeed in a pbuilder chroot. I've attached the part or the build log that seems to be autoconf relevant. I admit I'm a bit astonished since I can only see warnings but no error ... Kind regards Andreas. -- http://fam-tille.de dh_autoreconf -O--no-parallel aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' configure.in:766: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from... configure.in:766: the top level configure.in:776: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from... configure.in:776: the top level configure.in:1259: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... configure.in:1259: the top level configure.in:766: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from... configure.in:766: the top level configure.in:776: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2601: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2617: AC_COMPILE_IFELSE is expanded from... configure.in:776: the top level configure.in:1259: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... configure.in:1259: the top level configure.in:1761: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from... lib/autoconf/libtool.m4:664: AC_LIBTOOL_COMPILER_OPTION is expanded from... lib/autoconf/libtool.m4:4901: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... lib/autoconf/libtool.m4:2737: _LT_AC_LANG_C_CONFIG is expanded from... lib/autoconf/libtool.m4:2736: AC_LIBTOOL_LANG_C_CONFIG is expanded from... lib/autoconf/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... lib/autoconf/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... lib/autoconf/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... configure.in:1761: the top level configure.in:1761: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:2042: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2063: AC_CACHE_CHECK is expanded from... lib/autoconf/libtool.m4:709: AC_LIBTOOL_LINKER_OPTION is expanded from... lib/autoconf/libtool.m4:4901: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... lib/autoconf/libtool.m4:2737: _LT_AC_LANG_C_CONFIG is expanded from... lib/autoconf/libtool.m4:2736: AC_LIBTOOL_LANG_C_CONFIG is expanded from... lib/autoconf/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... lib/autoconf/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from... lib/autoconf/libtool.m4:25: AC_PROG_LIBTOOL is expanded from... configure.in:1761: the top level configure.in:1761: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from... lib/autoconf/libtool.m4:332: _LT_AC_SYS_LIBPATH_AIX is expanded from... lib/autoconf/libtool.m4:5428: AC_LIBTOOL_PROG_LD_SHLIBS is expanded from... lib/autoconf/libtool.m4:2737: _LT_AC_LANG_C_CONFIG is expanded from... lib/autoconf/libtool.m4:2736: AC_LIBTOOL_LANG_C_CONFIG is expanded from... lib/autoconf/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from... lib/autoconf/libtool.m4:60:
Re: [RFC] python-cobra, python3-sbml5
On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote: > > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > > > provide) package. When I dug into looking at libsbml, I noticed that the > > > relevant file (libsbml.py) which throws error > > > is generated with swig-3.0 by the upstream [3] > > > > I admit I'm absolutely naive about swig - but if libsbml.py is really > > autogenerated what about re-generating it with swig-4? > > I think there's a miscommunication here. The file in the archive(on doing > $apt source python3-sbml5) is generated with swig-4 already, while it's > generated with swig-3 upstream. > Hence the issue. Ahhh, so it is regenerated in the Debian package build process but it conflicts with other parts of the upstream code? Did I now understood correctly? I wonder if we should exclude this kind of autogenerated code inside the source tarball since we are repackaging the source anyway to exclude some files for policy reasons. I'm doing so in other source tarballs for instance with cython files to be absolutely sure that this code is regenerated. This would probably not solve the build issue but might be a good idea in general. What do you think? Kind regards Andreas. > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 > > > > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 > > > > > > [3]: > > > https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple -- http://fam-tille.de
Re: [RFC] python-cobra, python3-sbml5
Hi Nilesh, On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote: > > >From the logs, in the last message[2] it looks like an import-error for > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > provide) package. When I dug into looking at libsbml, I noticed that the > relevant file (libsbml.py) which throws error > is generated with swig-3.0 by the upstream [3] I admit I'm absolutely naive about swig - but if libsbml.py is really autogenerated what about re-generating it with swig-4? Kind regards Andreas. > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 > > [3]: > https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple > > Thanks and regards > Nilesh -- http://fam-tille.de
Autoconf issue in mpqc
Control: tags -1 help Hi, while Nilesh has fixed the MPI-3.0 issue of mpqc in Git[1] the package does not build any more due to an autoconf issue: ... configure.in:1802: error: possibly undefined macro: AC_CHECK_CCA If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:1833: error: possibly undefined macro: AC_DEFINE_DIR autoreconf: /usr/bin/autoconf failed with exit status: 1 ... The macro AC_CHECK_CCA is defined in lib/autoconf/cca.m4 but it seems it is not found any more by recent autotools. Any help would be appreciated. Kind regards Andreas. [1] https://salsa.debian.org/debichem-team/mpqc -- http://fam-tille.de
Re: Bug#922589: FTBFS against opencv 4.0.1 (exp
Hi Alex,
On Sat, Mar 28, 2020 at 11:30:04AM +, Alex Dewar wrote:
> I've stuck in a PR to the upstream OpenCFU repository, which should fix
> this issue: https://github.com/qgeissmann/OpenCFU/pull/26
>
> Let me know if this works (or not) for you.
Thanks a lot for your port in OpenCFU to latest OpenCV. Its probably
very valuable. I've applied the patch in Salsa[1].
Unfortunately I'm still struck with the configure step:
...
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for OPENCV... no
configure: error: OpenCV not found. Have you installed the library (devel
version)
tail -v -n \+0 config.log
...
Regarding the hint of Samuel Thibault: Yes there is
# cat ./usr/lib/x86_64-linux-gnu/pkgconfig/opencv4.pc
# Package Information for pkg-config
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib/x86_64-linux-gnu
includedir_old=${prefix}/include/opencv4/opencv
includedir_new=${prefix}/include/opencv4
Name: OpenCV
Description: Open Source Computer Vision Library
Version: 4.2.0
Libs: -L${exec_prefix}/lib/x86_64-linux-gnu -lopencv_stitching -lopencv_aruco
-lopencv_bgsegm -lopencv_bioinspired -lopencv_ccalib -lopencv_dnn_objdetect
-lopencv_dnn_superres -lopencv_dpm -lopencv_highgui -lopencv_face
-lopencv_freetype -lopencv_fuzzy -lopencv_hdf -lopencv_hfs -lopencv_img_hash
-lopencv_line_descriptor -lopencv_quality -lopencv_reg -lopencv_rgbd
-lopencv_saliency -lopencv_shape -lopencv_stereo -lopencv_structured_light
-lopencv_phase_unwrapping -lopencv_superres -lopencv_optflow
-lopencv_surface_matching -lopencv_tracking -lopencv_datasets -lopencv_text
-lopencv_dnn -lopencv_plot -lopencv_ml -lopencv_videostab -lopencv_videoio
-lopencv_viz -lopencv_ximgproc -lopencv_video -lopencv_xobjdetect
-lopencv_objdetect -lopencv_calib3d -lopencv_imgcodecs -lopencv_features2d
-lopencv_flann -lopencv_xphoto -lopencv_photo -lopencv_imgproc -lopencv_core
Libs.private: -ldl -lm -lpthread -lrt
Cflags: -I${includedir_old} -I${includedir_new}
in my pbuilder chroot - but this somehow does not help :-(
Kind regards
Andreas.
[1]
https://salsa.debian.org/med-team/opencfu/-/commit/1cfb33ca7dd7e659cd597694d458d56dc18c661c
--
http://fam-tille.de
Re: Cmake error in diamond-aligner: pthreads - not found
On Fri, Mar 27, 2020 at 10:05:05AM -0500, Ryan Pavlik wrote: > > Looks like two of the patches were actually applied upstream and can be > dropped: > > - multi_arch > https://github.com/bbuchfink/diamond/commit/2248fefb362e931ce1cee4d9292efe8d1499f225 > - fix_i386_and_s390x > https://github.com/bbuchfink/diamond/commit/aea535c07e09fd41c5ab48ae72b6901d01d8decb > > I've done this via gbp pq here: > https://salsa.debian.org/med-team/diamond-aligner/-/merge_requests/2 Thanks a lot for watching me! This was pretty helpful. Kind regards Andreas. -- http://fam-tille.de
Cmake error in diamond-aligner: pthreads - not found
Hi folks, I have problems to upgrade diamond-aligner[1] to its latest upstream version and upstream can't reproduce the issue. Sorry, currently I'm swamped with COVID-19 issues so I'd like to ask here simply for a patch which is probably not that hard. In pbuilder I get: ... -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE.. CMake Error at CMakeLists.txt:69 (else): else An ELSE command was found outside of a proper IF ENDIF structure. Or its arguments did not match the opening IF command. CMake Error at CMakeLists.txt:166 (endif): endif An ENDIF command was found outside of a proper IF ENDIF structure. Or its arguments did not match the opening IF command. CMake Error at CMakeLists.txt:271 (add_executable): add_executable cannot create target "diamond" because another target with the same name already exists. The existing target is an executable created in source directory "/build/diamond-aligner-0.9.31". See documentation for policy CMP0002 for more details. -- Configuring incomplete, errors occurred! See also "/build/diamond-aligner-0.9.31/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log". See also "/build/diamond-aligner-0.9.31/obj-x86_64-linux-gnu/CMakeFiles/CMakeError.log". ... Any patch would be really welcome. Thanks a lot Andreas. [1] https://salsa.debian.org/med-team/diamond-aligner -- http://fam-tille.de
Re: cannot allocate memory in static TLS block
Hi Faidon, On Tue, Mar 17, 2020 at 01:29:59PM +0200, Faidon Liambotis wrote: > Hi Andreas, > > Thanks for reaching out. It sounds like this is already reported as > #951704 (Cc'ed now). OK. > I'll need to give this a closer look, but I hope I > can have an update within the next couple of weeks. Does this work? Well, drmaa is certainly not the most important package inside Debian so I see no reason to push you. But it would be great to have all those Python3 issues from the table sooner or later since it generated noise for the most active Python 2->3 migrators. Just take the time you need. See you Andreas. -- http://fam-tille.de
Re: cannot allocate memory in static TLS block
Hi Faidon, could you imagine to build jemalloc with --disable-initial-exec-tls as Sergio suggests below to fix the issue in drmaa (and possibly other packages)? Should I open a separate bug report against jemalloc to request this? Kind regards Andreas. On Sat, Mar 14, 2020 at 05:18:49PM -0400, Sergio Durigan Junior wrote: > > $ python3 > > Python 3.7.6 (default, Jan 19 2020, 22:34:52) > > [GCC 9.2.1 20200117] on linux > > Type "help", "copyright", "credits" or "license" for more information. > import drmaa > > Traceback (most recent call last): > > File "", line 1, in > > File > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py", > > line 65, in > > from .session import JobInfo, JobTemplate, Session > > File > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py", > > line 39, in > > from drmaa.helpers import (adapt_rusage, Attribute, > > attribute_names_iterator, > > File > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py", > > line 36, in > > from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t, > > File > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py", > > line 58, in > > _lib = CDLL(libpath, mode=RTLD_GLOBAL) > > File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__ > > self._handle = _dlopen(self._name, mode) > > OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory > > in static TLS block > > This is an issue with jemalloc's handling of the TLS model when being > dlopened.. See: > > https://github.com/jemalloc/jemalloc/issues/1237 > > The recommended way to build a libjemalloc that is suitable for being > dlopened is to use '--disable-initial-exec-tls' when building it. Take > a look at the INSTALL.md file, and look for this option: > > https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md > > There is a way to workaround this bug by doing an LD_PRELOAD of > libjemalloc when invoking python, but this will only mask the problem > and we can't expect users to do/know this. > > The way I see it, you can try to convince jemalloc's maintainer to > enable that flag. > > BTW, the reason 'find_library' can't find drmaa's library is because the > .so is being installed in a non-standard directory. I don't know why > the package was made like this, though. > > Thanks, > > -- > Sergio > GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 > Please send encrypted e-mail if possible > http://sergiodj.net/ -- http://fam-tille.de
cannot allocate memory in static TLS block (Was: Bug#953832: drmaa: autopkgtest failure: RuntimeError: Could not find drmaa library)
Control: tags -1 help
Control: retitle -1 cannot allocate memory in static TLS block
Hi Paul,
On Fri, Mar 13, 2020 at 11:09:31PM +0100, Paul Gevers wrote:
>
> raise RuntimeError(('Could not find drmaa library. Please specify
> its ' +
> RuntimeError: Could not find drmaa library. Please specify its full
> path using the environment variable DRMAA_LIBRARY_PATH
I've fixed this in Git. Unfortunately I get a new issue when importing
drmaa
$ python3
Python 3.7.6 (default, Jan 19 2020, 22:34:52)
[GCC 9.2.1 20200117] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import drmaa
Traceback (most recent call last):
File "", line 1, in
File
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py",
line 65, in
from .session import JobInfo, JobTemplate, Session
File
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py",
line 39, in
from drmaa.helpers import (adapt_rusage, Attribute,
attribute_names_iterator,
File
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py",
line 36, in
from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
File
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py",
line 58, in
_lib = CDLL(libpath, mode=RTLD_GLOBAL)
File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory in
static TLS block
Any help would be welcome
Andreas.
--
http://fam-tille.de
Re: Help to package nest-simulator to enable upgrading pynn
Hi Steffen, thanks for registering on Salsa. You might like to read the Debian Med team policy[1] On Fri, Mar 13, 2020 at 09:34:12AM +0100, Steffen Graber wrote: > Without really knowing anything about debian packages, is > > override_dh_auto_test: > /usr/bin/ctest / > --force-new-ctest-process / > --build-exe-dir $(CURDIR)/bin / > -j$((`nproc`)) > > an option? Sounds promising but did not helped (see my last commit). I was wondering whether there is some way to patch such PATH in but I can not found any place where this might be possible. I wonder if you are running the test in a local build and have some /usr/bin/nest installed - which you might have as developer - which executable gets really tested. May be you call the install target first and the test finds the new executable. However, in Debian the sequence is configure build test install Thanks a lot for your contribution anyway Andreas. [1] https://med-team.pages.debian.net/policy/ > Am 12.03.20 um 19:50 schrieb Andreas Tille: > > Control: tags -1 help > > > > [debian-mentors readers please start reading at this mark @debian-mentors] > > > > Hi Steffen, > > > > I'm working on upgrading the Debian package of pynn. While I assume the > > latest upstream version of pynn will fix all Python3 migration issues it > > also has the new dependency on nest-simulator. Thus I commited > > preliminary packaging for this to the Debian development Git[1]. Thanks > > for your great initial work for Debian packaging inside the upstream > > tarball. I left you as Uploader in d/control and I hope you would like > > to maintain the Debian packaging inside the Debian Med team who is > > traditionally very welcoming to newcomers. If you agree please register > > at salsa.debian.org and ask for membership in the Debian Med team (or > > ping me by mentioning your salsa user name). If you agree the easiest > > way for maintenance would be if you drop the debian/ dir from the > > upstream source and we maintain it here directly with the goal of > > uploadin it to official Debian (and from there propagating to all Debian > > derivatives). > > > > > > @debian-mentors > > > > To update pynn to a Python3 aware version we need the new package > > nest-simulator. I've prepared the packaging[1] based on some work by > > upstream (thanks for this Steffen). Unfortunately I'm stumbling upon > > ctest: > > > > PATH=/build/nest-simulator-2.20.0/bin:/usr/sbin:/usr/bin:/sbin:/bin > > dh_auto_test > > cd build && make -j4 test ARGS\+=-j4 > > make[2]: Entering directory '/build/nest-simulator-2.20.0/build' > > Running tests... > > /usr/bin/ctest --force-new-ctest-process -j4 > > Test project /build/nest-simulator-2.20.0/build > > Start 1: selftests/test_pass.sli > > Could not find executable /usr/bin/nest > > Looked in the following places: > > /usr/bin/nest > > /usr/bin/nest > > /usr/bin/Release/nest > > /usr/bin/Release/nest > > /usr/bin/Debug/nest > > /usr/bin/Debug/nest > > /usr/bin/MinSizeRel/nest > > > > > > I wonder how I can tell ctest that the executable that is needed can be > > found in /build/nest-simulator-2.20.0/bin. Seems my means in d/rules > > > > PATH=$(CURDIR)/bin:$(PATH) dh_auto_test > > > > is not sufficient. > > > > Any better idea? > > > > Kind regards > > > > Andreas. > > > > [1] https://salsa.debian.org/med-team/nest-simulator > > > > -- > Steffen Graber > > SimLab Neuroscience > Division HPC in Neuroscience > Jülich Supercomputing Centre > Institute for Advanced Simulation > Forschungszentrum Jülich GmbH > E-mail: s.gra...@fz-juelich.de <mailto:s.gra...@fz-juelich.de> > Phone: +49 2461 61 85457 > http://www.fz-juelich.de/ias/jsc > > Institute of Neuroscience and Medicine (INM-6) > Computational and Systems Neuroscience & > Institute for Advanced Simulation (IAS-6) > Theoretical Neuroscience & > JARA Institute Brain Structure-Function Relationships (INM-10) > Forschungszentrum Jülich GmbH > http://www.csn.fz-juelich.de > -- http://fam-tille.de
Help to package nest-simulator to enable upgrading pynn
Control: tags -1 help [debian-mentors readers please start reading at this mark @debian-mentors] Hi Steffen, I'm working on upgrading the Debian package of pynn. While I assume the latest upstream version of pynn will fix all Python3 migration issues it also has the new dependency on nest-simulator. Thus I commited preliminary packaging for this to the Debian development Git[1]. Thanks for your great initial work for Debian packaging inside the upstream tarball. I left you as Uploader in d/control and I hope you would like to maintain the Debian packaging inside the Debian Med team who is traditionally very welcoming to newcomers. If you agree please register at salsa.debian.org and ask for membership in the Debian Med team (or ping me by mentioning your salsa user name). If you agree the easiest way for maintenance would be if you drop the debian/ dir from the upstream source and we maintain it here directly with the goal of uploadin it to official Debian (and from there propagating to all Debian derivatives). @debian-mentors To update pynn to a Python3 aware version we need the new package nest-simulator. I've prepared the packaging[1] based on some work by upstream (thanks for this Steffen). Unfortunately I'm stumbling upon ctest: PATH=/build/nest-simulator-2.20.0/bin:/usr/sbin:/usr/bin:/sbin:/bin dh_auto_test cd build && make -j4 test ARGS\+=-j4 make[2]: Entering directory '/build/nest-simulator-2.20.0/build' Running tests... /usr/bin/ctest --force-new-ctest-process -j4 Test project /build/nest-simulator-2.20.0/build Start 1: selftests/test_pass.sli Could not find executable /usr/bin/nest Looked in the following places: /usr/bin/nest /usr/bin/nest /usr/bin/Release/nest /usr/bin/Release/nest /usr/bin/Debug/nest /usr/bin/Debug/nest /usr/bin/MinSizeRel/nest I wonder how I can tell ctest that the executable that is needed can be found in /build/nest-simulator-2.20.0/bin. Seems my means in d/rules PATH=$(CURDIR)/bin:$(PATH) dh_auto_test is not sufficient. Any better idea? Kind regards Andreas. [1] https://salsa.debian.org/med-team/nest-simulator -- http://fam-tille.de
