Any reason for broken pristine-tar information in webfs
Hi, I've created the webfs Git repository[1] intially via gbp import-dscs --debsnap --create-missing-branches --pristine-tar webfs which usially works. When building via gbp buildpackage --git-pbuilder-options="--source-only-changes" it turned out that the resulting upstream tarball differs from what I get via apt source webfs I tried to refresh the pristine-tar information via pristine-tar commit PATH_TO_ORIGINAL/webfs_1.21+ds1.orig.tar.gz but this fails as well. Any idea what might went wrong here? Kind regards Andreas. [1] https://salsa.debian.org/salvage-team/webfs -- https://fam-tille.de
Re: Help for wget2 update needed
Hi Jeremy, Am Mon, Sep 16, 2024 at 04:17:10PM +0100 schrieb Jeremy Sowden: > > wget2 seems to rely heavily on gnulib, so you'll need a build-dep on > that. It includes a bootstrap script which pulls in the code it > requires from gnulib and needs to be run before dh_autoreconf. > > Patch attached. That patch (as well as the hint from Santiago) helped definitely to some progress. However, I'm now blocked by config.status:3707: creating include/wget/wgetver.h config.status:3707: creating po/Makefile.in config.status:3693: error: cannot find input file: 'Makefile.in' as you can see in Salsa CI[1]. Any further hints? Kind regards Andreas. [1] https://salsa.debian.org/tille/wget2/-/jobs/6291380#L11850 -- https://fam-tille.de
Help for wget2 update needed
Hi, I intend to try the latest version of wget2. To build it I've created a fork but it does not build as you can see in Salsa CI[1]. I fiddled around with some patches for automake but obviously with no success. Any help would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/tille/wget2/-/jobs/6290074 -- https://fam-tille.de
Re: [Help] Re: input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
Hi Jeremy, Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden: > Try this patch. Works. Thanks a lot for the quick help Andreas. -- https://fam-tille.de
[Help] Re:input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
Control: tags -1 help Control: tags -1 confirmed Thanks Hi, since input-utils showed up as Bug of the Day[1] I worked down the list of bugs including upgrading to latest upstream. Unfortunately the FTBFS for several 32bit architectures (not only armhf) remains[2]. Since I have no experience with these architectures I'd kindly ask for help here. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://buildd.debian.org/status/package.php?p=input-utils -- https://fam-tille.de
How to delete from DELAYED queue
Hi, I made some mistake when uploading cal_4.1-1_source.changes to DELAYED=10 and tried to delete it from the queue. I was following `man dcut` from dput-ng and did: $ dcut rm --searchdirs -f cal_4.1-1_source.changes Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) Expanding package list for removals to: cal_4.1-1_source.changes, cal_4.1-1_amd64.buildinfo, cal_4.1-1.debian.tar.xz, cal_4.1.orig.tar.xz, cal_4.1-1.dsc Uploading andreas-1726085916.commands to ftp-master This led to the response: Log of processing your commands file /andreas-1726085916.commands: > rm --searchdirs cal_4.1-1.dsc cal_4.1-1.dsc did not match anything No files to delete > rm --searchdirs cal_4.1.orig.tar.xz cal_4.1.orig.tar.xz did not match anything No files to delete > rm --searchdirs cal_4.1-1.debian.tar.xz cal_4.1-1.debian.tar.xz did not match anything No files to delete > rm --searchdirs cal_4.1-1_amd64.buildinfo cal_4.1-1_amd64.buildinfo did not match anything No files to delete > rm --searchdirs cal_4.1-1_source.changes cal_4.1-1_source.changes did not match anything No files to delete Greetings, Your Debian queue daemon (running on host usper.debian.org) Any idea how I can successfully remove this package from the queue? Its really there[1]. Kind regards Andreas. [1] https://ftp-master.debian.org/deferred.html -- https://fam-tille.de
Bug#1067426: RFS: qucs-s/24.1.0 [ITP] -- Quite universal circuit simulator with SPICE
Hi, this is not what I mean. The Debian Electronics team will not do anything for you. I wanted to say you can join that team and have got chances to find sponsors there. BTW, if you **really** want to turn the ITP onto RFP its easy to retitle the bug. Asking someone for closing a bug for you which was opened by you makes no sense. You can even sent a mail to bugnumber-d...@bugs.debian.org to close it yourself. Hope these hints are helpful Andreas. Am Fri, Aug 23, 2024 at 04:51:20PM +0300 schrieb Vadim Kuznetsov: > Hello, > > Thanks for the reply! I decided to prepare RFP request instead. The ITP > request may be closed. > > Regards, > Vadim > > On 23.08.2024 09:03, Phil Wyett wrote: > > Morning Andreas, > > > > That is certainly an option for the submitter. Being part of a team may help > > them and the package now and in the future. > > > > Regards > > > > Phil > > > > On Fri, 2024-08-23 at 07:48 +0200, Andreas Tille wrote: > > > Hi, > > > > > > did you considered contacting Debian Electronics Team[1]? > > > > > > Kind regards > > > Andreas. > > > > > > [1] https://wiki.debian.org/Teams/pkg-electronics > > > > > > Am Fri, Aug 23, 2024 at 06:08:43AM +0100 schrieb Phil Wyett: > > > > Vadim, > > > > > > > > There has been numerous feedback entries but nothing since march. Is > > > > there > > > > still an appetite to package qucs-s in which ever form based on > > > > comments? > > > > > > > > Regards > > > > > > > > Phil > > > > > > > > -- > > > > > > > > "I play the game for the game’s own sake" > > > > > > > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > > > > > > > -- > > > > > > > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > > > > > > > Internet Relay Chat (IRC): kathenas > > > > > > > > Matrix: #kathenas:matrix.org > > > > > > > > Website: https://kathenas.org > > > > > > > > Instagram: https://instagram.com/kathenasorg/ > > > > > > > > Threads: https://www.threads.net/@kathenasorg > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- https://fam-tille.de
Re: Linker problem in safecat
Hi Antonio, Am Thu, Aug 22, 2024 at 08:48:55PM -0600 schrieb Antonio Russo: > I noticed the change of upstream to [1], but there's no import of any of > the work done in there. It looks like @aperezdc has already gone about > porting the package to meson, presumably solving this problem. Looking > through the rest of the minimal work done on the package since the 1.13 > import, there are a handful that make use of modern standard C libraries, > a few that add or remove documentation, and two commits that might be > controversial: 185e8bf and 6c14784. Thanks a lot for that hint. > The first removes the maildir.sh script and a no-op warn-auto.sh file > which seems to have only been used as part of its bespoke build system. > The second changes the behavior if DTLINE and RPLINE are defined, which > apparently has something to with qmail---I didn't bother to investigate. > Maybe these commits can be safely reverted if we want that "old" behavior? Seems it took even over one of our Debian patches which I was able to remove. > My point is that either the new upstream should be used, or we should > admit that Debian is now acting as upstream of the package. Maybe it's > worth it to just cherry pick the build system changes? It really seems > unlikely it's worth someone's time it to maintain an abandoned, single-purpose > build system designed in the late 20th century with ~1400 lines of code > for a ~1800 LOC project! We will *definitely* not become upstream. I pointed the watch file to the latest Git commit and filed an ITS bug. > (PS: Thank you so much for caring about these old packages. I'm sure > someone's workflow depends on these, and they may not realize how > precarious that is.) You are welcome and thanks a lot for your hint. I added the comment to the Bug of the Day matrix channel[2] that contacting debian-mentors@l.d.o helps over night. ;-) Kind regards Andreas. > [1] https://github.com/aperezdc/safecat [2] https://matrix.to/#/#debian-tiny-tasks:matrix.org -- https://fam-tille.de
Bug#1067426: RFS: qucs-s/24.1.0 [ITP] -- Quite universal circuit simulator with SPICE
Hi, did you considered contacting Debian Electronics Team[1]? Kind regards Andreas. [1] https://wiki.debian.org/Teams/pkg-electronics Am Fri, Aug 23, 2024 at 06:08:43AM +0100 schrieb Phil Wyett: > Vadim, > > There has been numerous feedback entries but nothing since march. Is there > still an appetite to package qucs-s in which ever form based on comments? > > Regards > > Phil > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > Internet Relay Chat (IRC): kathenas > > Matrix: #kathenas:matrix.org > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Threads: https://www.threads.net/@kathenasorg > > -- > > > > > > -- https://fam-tille.de
Linker problem in safecat
Hi, I intended to fix bugs #1066354 and #836007 of safecat as Bug of the Day[1]. While #1066354 gcc-14 error seemed to be a low hanging fruit it turns out I need help to solve some linker issue[2]: ./load safecat getln.a str.a stralloc.a strerr.a substdio.a \ alloc.o alloc_re.o byte_copy.o byte_cr.o envread.o error.o \ error_str.o fmt_uint64.o hostname.o sig.o stat_dir.o str_diffn.o \ str_len.o substdi.o substdio.o substdio_copy.o taia_fmtfrac.o \ taia_now.o taia_tai.o tempfile.o writefile.o /usr/bin/ld: errno: TLS definition in /lib/x86_64-linux-gnu/libc.so.6 section .tbss mismatches non-TLS reference in strerr.a(strerr_sys.o) /usr/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: error adding symbols: bad value collect2: error: ld returned 1 exit status make[1]: *** [Makefile:226: safecat] Error 1 Its connected to the obscure, manually written build system of upstream. Any idea how to convince the linker to behave nicely? You can find the full build log in Salsa CI of safecat[2]. Thanks a lot for any help Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/safecat/-/jobs/6164554 -- https://fam-tille.de
Bug#1075777: RFS: archivemount/1-1 -- mounts an archive or compressed file for access as a filesystem
Hi, Am Tue, Aug 20, 2024 at 11:19:16PM +0200 schrieb наб: > Well, libarchive-dev Depends: liblz4-dev, so that's, uh, impossible? > I'd certainly interrogate the pbuilder log about this > before adding the build-dep; smells weird to me. > > The build certainly works in a clean sid chroot > (i just built it in a clean sid chroot; > naturally apt build-dep pulled in libarchive-dev and liblz4-dev). Seems the pbuilder chroot on my laptop is somehow broken. Desktop builds fine thus I've uploaded your package as per Git repository. > > > If any particular cetera (or category of cetera) cross your mind, > > > I can find what their previous values were and list them as well. > > I do not want to by over-picky. But debhelper compat level and > > Standards-Version are mandatory for mentioning. > Thanks, good to know. > > Best, > > (Also, you left me out of CC: so I got this delayed, from the web.) Added you to CC again. Kind regards and thank you for working on this package Andreas. -- https://fam-tille.de
Bug#1075777: RFS: archivemount/1-1 -- mounts an archive or compressed file for access as a filesystem
Control: owner -1 ti...@debian.org Control: tags -1 pending Control: tags -1 - moreinfo Control: tags -1 confirmed Thanks Hi, I intend to sponsor the package which is maintained in Salsa[1]. There is just a minor issues with Build-Depends pending. Kind regards Andreas. [1] https://salsa.debian.org/nabijaczleweli/archivemount -- https://fam-tille.de
Bug#1075777: RFS: archivemount/1-1 -- mounts an archive or compressed file for access as a filesystem
Hi,
Am Tue, Aug 20, 2024 at 06:08:54PM +0200 schrieb наб:
> On Tue, Aug 20, 2024 at 10:44:24AM +0200, Andreas Tille wrote:
> > At first I need to say that my personal sponsoring style is that I
> > sponsor only from Git repositories on Salsa (for various reasons).
> https://salsa.debian.org/nabijaczleweli/archivemount
> it even passes the standard Salsa pipelines
> (except for reprotest:
>https://salsa.debian.org/nabijaczleweli/archivemount/-/jobs/6154192#L578)
That looks great.
> but it looks like that's because the reprotest driver is broken)
I admit I would tolerate failure in reprotest for sponsoring.
Unfortunately it does not build in my local pbuilder:
dh_auto_build
make -j8 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/build/archivemount-1'
g++ -g -O2 -ffile-prefix-map=/build/archivemount-1=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-I/usr/include/fuse3 -O3 -g -Wall -Wextra -fno-exceptions -fno-rtti
-Wno-missing-field-initializers -std=c++2b -Wdate-time -D_FORTIFY_SOURCE=2
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION='"1-1"' -DNDEBUG -Wl,-z,relro
-Wl,-z,now archivemount.cpp -larchive -lfuse3 -lpthread -o archivemount
awk '{ gsub(/ \^/, " \\(ha"); gsub(/ ~/, " \\(ti"); if($1 == ".Dd") $2 =
"August 20, 2024"; if($1 == ".Dt") print ".ds doc-volume-operating-system";
if($1 == ".Os") $2 = "archivemount-ng 1-1"; print}' < archivemount.1.in >
archivemount.1
/usr/bin/ld: /lib/x86_64-linux-gnu/liblz4.so.1: undefined reference to
`LZ4_XXH32'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblz4.so.1: undefined reference to
`LZ4_XXH32_digest'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblz4.so.1: undefined reference to
`LZ4_XXH32_update'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblz4.so.1: undefined reference to
`LZ4_XXH32_reset'
collect2: error: ld returned 1 exit status
make[1]: *** [: archivemount] Error 1
If I use the following patch:
$ git diff
diff --git a/debian/control b/debian/control
index b67d02d..45a6ec1 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Build-Depends: debhelper,
libfuse3-dev,
libarchive-dev,
pkgconf,
+ liblz4-dev
Package: archivemount
Architecture: any
the build works fine. No idea why Salsa CI installs liblz4-dev but
pbuilder does obviously not.
> >However, there where
> > *a lot* of package modernisations (which I applaude) that need to be
> > mentioned in d/changelog.
> tbh I considered the old packaging unsalvageable;
> except for a merged changelog, this is an entirely new debian/
> (copied from urlview; it's really quite a similar situation to urlview),
> so I don't really know what the changes... are? because I didn't make any
ACK, I fully understand what you mean. However, if you take over some
existing package you should list the changes you did. For doing so I'd
recommend routine-update (inside the package with the same name). It
modernises some existing package including calling Janitor tools and
maintains the changelog accordingly.
> >Starting with Vcs-fields, Standards-Version,
> > recent debhelper compat level, etc.
> Added all of those to d/changelog (by diff against 4b94b04^).
Fine.
> If any particular cetera (or category of cetera) cross your mind,
> I can find what their previous values were and list them as well.
I do not want to by over-picky. But debhelper compat level and
Standards-Version are mandatory for mentioning.
> I've uploaded this updated package to mentors.d.o.
I do not require you to upload to mentors. If you consider adapting
the Build-Depends I simply sponsor from Git.
Thanks a lot for your work
Andreas.
--
https://fam-tille.de
Bug#1075777: Reset confirmed since I consider more changes needed
Hi Phil, Am Tue, Aug 20, 2024 at 10:48:20AM +0100 schrieb Phil Wyett: > If you feel that you can and will take this package to sponsoring/upload. > Could you please take ownership and of the Request For Sponsorship (RFS) bug > and tag as "pending"[1]. I'd love to if the package is on Salsa as per my personal requirement. I wonder whether maintaining a package on Salsa should be more advertised on mentors.debian.net (I have not checked whether it possibly is, sorry.) > If not, ignore the above. That's fine. > [1] https://mentors.debian.net/sponsors/rfs-howto/ See the section prior to > "Uploading Packages". I hope to remember that hint. Thanks a lot for your work on mentors.d.n Andreas. > Regards > > Phil > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > Internet Relay Chat (IRC): kathenas > > Matrix: #kathenas:matrix.org > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Threads: https://www.threads.net/@kathenasorg > > -- > > > > > > -- https://fam-tille.de
Bug#1075777: Reset confirmed since I consider more changes needed
Control: tags -1 - confirmed
Bug#1075777: RFS: archivemount/1-1 -- mounts an archive or compressed file for access as a filesystem
Control: tag -1 moreinfo Thanks Hi, archivemount showed up in the Bug of the Day[1] today and I've checked the situation. At first I need to say that my personal sponsoring style is that I sponsor only from Git repositories on Salsa (for various reasons). Thus my first action on this package was importing it to Salsa[2]. If we find a new maintainer than this maintainer can decide where on Salsa the package should reside (perhaps in debian/ name space or some other team that might be a better fit). Thanks to Chrysostomos Nanakos for confirming that you can take over the package. This saves us from starting the Salvage Proces (I admit I was about to file an `ITS: archivemount` bug when I realised the RFA bug.) Regarding the changes to the packaging. I consider the changelog as *way* to short to be acceptable. Considering the upstream changelog simply closing a bunch of bugs is probably OKish. However, there where *a lot* of package modernisations (which I applaude) that need to be mentioned in d/changelog. Starting with Vcs-fields (which is good in principle, but please use some repository on Salsa), Standards-Version, recent debhelper compat level, etc. This is all *very* good - but it needs to be mentioned inside the changelog. Thus I have tagged the bug `moreinfo`. Kind regards and thanks a lot for bringing the package into shape again Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/archivemount [3] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [4] https://contributors.debian.org/contributor/cnanakos/ -- https://fam-tille.de
Bug#1074291: RFS: ghmm/0.9~rc3-7 [RC] [Team] -- General Hidden-Markov-Model library - tools
Hi Bo, thanks a lot for your fix. I've sponsored your commits. See you in Busan (if I'm not misleaded and if so please approach me) Andreas. Am Thu, Jun 27, 2024 at 02:26:45PM +0800 schrieb Bo YU: > Hi team, > > https://salsa.debian.org/med-team/ghmm/-/tree/master?ref_type=heads > > Please help me to review the upload for ghmm in your free time. We can > ignore the piuparts test failed due to old binary built with > python3.11 on Debian archives. > > TIA. > > > BR, > Bo > > > On Thu, Jun 27, 2024 at 3:42 AM Bastian Germann wrote: > > > > On Wed, 26 Jun 2024 13:12:46 +0800 Bo YU wrote: > > > ghmm (0.9~rc3-7) unstable; urgency=medium > > > . > > >* Team upload. > > >* Add fix_imp_func_issue.patch to fix ftbfs issue.(Closes: #1073355) > > > > For team uploads please push your changes to git to show that you are part > > of the team. > > I guess the Med Team has some different channel to ask for sponsorship. > > Please use that in the future. > > -- https://fam-tille.de
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&arch=ppc64el&ver=1.0.2-1&stamp=1644956229&raw=0 [2] https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=amd64&ver=1.0.2-1&stamp=1644952702&raw=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&arch=i386&ver=2.4.0%2Bdfsg-13&stamp=1613071965&raw=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&arch=ppc64el&ver=1.3.0%2Bdfsg-2&stamp=1602489351&raw=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&suite=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) || 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, &buf)) {
| ^~~
/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 > -fdebug-p
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 change
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) ==13
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(&prProgress, LogGetFP(&rLog, 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(&prProgress, LogGetFP(&rLog, 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*)
> /home/matthew/clustal-omega-1.2.
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(&prProgress, LogGetFP(&rLog, 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(&prProgress, LogGetFP(&rLog, 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&arch=mipsel&ver=1.2.4-5&stamp=1586883766&raw=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
