Re: Help with catch2 transition needed

[Andreas Tille]

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

[Jerome BENOIT]

Hi, you may want to see #1054706.
Best wishes,
Jerome

On 07/11/2023 14:18, Andreas Tille wrote:

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




--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help with catch2 transition needed

[Sune Vuorela]

On 2023-11-07, Andreas Tille  wrote:
> 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'

in catch2 3.0 and later you now need to link catch2 and catch2 main in
your tests.

try link with Catch2WithMain in your test targets

Like this:
target_link_libraries(test PRIVATE Catch2::Catch2WithMain)

/Sune

Re: Help with catch2 transition needed

[Andreas Tille]

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

Re: Help with catch2 transition needed

[Petr Kubánek]

Hi Andreas,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.PetrDne 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

Help with catch2 transition needed

[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

Re: Help needed for libssl ABI change

[Gianfranco Costamagna]

For some reasons looks like you are using static libssl.a library.
I don't know if this is the issue, but with static library libssl.a and dynamic 
libcrypto, I don't know how much the linker will be happy to mix them together



quoting the upstream makefile
 ifneq ($(wildcard /usr/lib/x86_64-linux-gnu/libssl.a),)
   L+=/usr/lib/x86_64-linux-gnu/libssl.a
 else
   ifneq ($(wildcard /usr/local/opt/openssl/lib/libssl.a),)
  L+=/usr/local/opt/openssl/lib/libssl.a
   else
  L+=-lssl
   endif

(so for x86_64-linux-gnu only libssl.a is taken)

   ifneq ($(wildcard /opt/local/lib/libcrypto.a),)
  L+=/opt/local/lib/libcrypto.a
   else
  ifneq ($(wildcard /usr/local/opt/openssl/lib/libcrypto.a),)
 L+=/usr/local/opt/openssl/lib/libcrypto.a
  else
 L+=-lcrypto
  endif



You end up mixing static and dynamic ssl libraries.
If you remove the "x86_64-linux-gnu" from wildcard, the libssl.a wont' be found 
anymore, and you will end up with the very same behaviour and build failure of
i386 build, such as the one here:

PATH=/builds/med-team/libucsc/debian/output/source_dir/debian/tmp_blat/usr/bin:/usr/lib/ccache/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 make --directory=src/blat test
make[2]: Entering directory 
'/builds/med-team/libucsc/debian/output/source_dir/src/blat'
blat -verbose=0 hCrea.geno hCrea.mrna testRna.psl
make[2]: blat: No such file or directory
make[2]: *** [makefile:21: test] Error 127
make[2]: Leaving directory 
'/builds/med-team/libucsc/debian/output/source_dir/src/blat'
make[1]: *** [debian/rules:37: override_dh_auto_test] Error 2
make[1]: Leaving directory '/builds/med-team/libucsc/debian/output/source_dir'

G.


Il venerdì 15 settembre 2023 alle ore 12:56:32 CEST, Andreas Tille 
 ha scritto: 





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

Help needed for libssl ABI change

[Andreas Tille]

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

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Nilesh Patra]

On Fri, Aug 25, 2023 at 06:29:34PM +0200, Niels Thykier wrote:
> Nilesh Patra:
> > On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:
> > > [...]
> > 
> > I had figured out this already, but conffile.lex.c does not exist in the
> > project, it is generated as a part of the lexer output. In particular:
> > 
> 
> Ok, apologies it was not clear to me from your opening email, where you were
> stuck. I incorrectly assumed it was an an earlier stage than you are, so my
> input was not useful to you.
> 
> I checked the source of `conffile.l` and it need already has to runes to
> include config.h where I would have assumed you needed to 
> (https://salsa.debian.org/med-team/eegdev/-/blob/master/src/core/conffile.l#L24).
> 
> A bit of searching found the following flex upstream bug:
> 
>   * https://github.com/westes/flex/issues/564
> 
> Which seems related. Hopefully, it can help you.

So, it was a lexer issue after all :)
That did help, and I could fix the package. Thanks a lot!

Best,
Nilesh


signature.asc
Description: PGP signature

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Jeremy Sowden]

On 2023-08-25, at 18:29:34 +0200, Niels Thykier wrote:
> Nilesh Patra:
> > On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:
> > > [...]
> > 
> > I had figured out this already, but conffile.lex.c does not exist in the
> > project, it is generated as a part of the lexer output. In particular:
> > 
> 
> Ok, apologies it was not clear to me from your opening email, where you were
> stuck. I incorrectly assumed it was an an earlier stage than you are, so my
> input was not useful to you.
> 
> I checked the source of `conffile.l` and it need already has to runes to
> include config.h where I would have assumed you needed to 
> (https://salsa.debian.org/med-team/eegdev/-/blob/master/src/core/conffile.l#L24).
> 
> A bit of searching found the following flex upstream bug:
> 
>   * https://github.com/westes/flex/issues/564
> 
> Which seems related. Hopefully, it can help you.

Another possibility would be just not to use gnulib.  Debian is a GNU
system, so it shouldn't be needed.  If one removes the dh_autoreconf
override and just lets dh_autoreconf do its thing, the package builds
successfully.

J.


signature.asc
Description: PGP signature

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Nilesh Patra:

On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:

[...]


I had figured out this already, but conffile.lex.c does not exist in the
project, it is generated as a part of the lexer output. In particular:



Ok, apologies it was not clear to me from your opening email, where you 
were stuck. I incorrectly assumed it was an an earlier stage than you 
are, so my input was not useful to you.


I checked the source of `conffile.l` and it need already has to runes to 
include config.h where I would have assumed you needed to 
(https://salsa.debian.org/med-team/eegdev/-/blob/master/src/core/conffile.l#L24).


A bit of searching found the following flex upstream bug:

  * https://github.com/westes/flex/issues/564

Which seems related. Hopefully, it can help you.


Best regards,
Niels

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Nilesh Patra]

On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:
> Nilesh Patra:
> > 
> > 
> > On 25 August 2023 1:47:26 pm IST, Nilesh Patra  wrote:
> > > On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum  
> > > wrote:
> > > > Source: eegdev
> > > > Version: 0.2-6
> > > > Severity: serious
> > > > > In file included from conffile.lex.c:242:
> > > > > ../../lib/stdio.h:64:3: error: #error "Please include config.h first."
> > > > > 64 |  #error "Please include config.h first."
> > > > >|   ^
> > > 
> > > The lexed file conffile.lex.c seems to include some stuff before
> > > config.h is included which is causing it to choke.
> > > 
> > > I'm not acquainted with lexers and not sure what causes this. I'd
> > > appreciate any help.
> > 
> > Adding mentors list as well. If someone can help with this, that'd be great.
> I do not think the lexer has anything to do with this.
> 
> A quick look at the log suggests that the package is "rolling" its own
> "stdio.h" (note the "../../lib/stdio.h" in the error message).  Indeed, the
> full log has "mv stdio.h-t3 stdio.h" as well.
> 
> I believe that this is stdio.h is generated by the embedded gnulib copy and
> that is as far as I am willing to debug that rabbit hole. Based on the
> error, I assume gnulib's generated stdio.h requires the project specific
> "config.h" to be loaded first.
> 
> As for solving it, I would have a look at the "conffile.lex.c" file, see
> where it has its "#include" for stdio.h and then add an `include "config.h"`
> before that to see if it works (via a patch).

I had figured out this already, but conffile.lex.c does not exist in the
project, it is generated as a part of the lexer output. In particular:

$ ls conffile.lex.c
ls: cannot access 'conffile.lex.c': No such file or directory
$ flex conffile.l
$ ls conffile.lex.c
conffile.lex.c

And this indeed has config.h include after a few C-specific includes.
Since this is not a part of the source, there's nothing I can patch in
this file. conffile.l has the config.h include present before everything
else, and hence I'm not sure where this should be fixed.

Did I misunderstand your solution somehow? If not, can you recommend
something else?

Best,
Nilesh


signature.asc
Description: PGP signature

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Niels Thykier:

[...]

Hi,

[...]
I believe that this is stdio.h is generated by the embedded gnulib copy 
and that is as far as I am willing to debug that rabbit hole. Based on 
the error, I assume gnulib's generated stdio.h requires the project 
specific "config.h" to be loaded first.

[...]

Best regards,
Niels



Correction; the gnulib was probably not an "embedded copy". The file 
still seems to be generated via gnulib, so the rest of my argument would 
remain the same.

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Nilesh Patra:



On 25 August 2023 1:47:26 pm IST, Nilesh Patra  wrote:

On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum  wrote:

Source: eegdev
Version: 0.2-6
Severity: serious

In file included from conffile.lex.c:242:
../../lib/stdio.h:64:3: error: #error "Please include config.h first."
64 |  #error "Please include config.h first."
   |   ^


The lexed file conffile.lex.c seems to include some stuff before
config.h is included which is causing it to choke.

I'm not acquainted with lexers and not sure what causes this. I'd
appreciate any help.


Adding mentors list as well. If someone can help with this, that'd be great.

Best,
Nilesh



Hi,

I do not think the lexer has anything to do with this.

A quick look at the log suggests that the package is "rolling" its own 
"stdio.h" (note the "../../lib/stdio.h" in the error message).  Indeed, 
the full log has "mv stdio.h-t3 stdio.h" as well.


I believe that this is stdio.h is generated by the embedded gnulib copy 
and that is as far as I am willing to debug that rabbit hole. Based on 
the error, I assume gnulib's generated stdio.h requires the project 
specific "config.h" to be loaded first.


As for solving it, I would have a look at the "conffile.lex.c" file, see 
where it has its "#include" for stdio.h and then add an `include 
"config.h"` before that to see if it works (via a patch).


Hope that helps.

Best regards,
Niels

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Nilesh Patra]

On 25 August 2023 1:47:26 pm IST, Nilesh Patra  wrote:
>On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum  wrote:
>> Source: eegdev
>> Version: 0.2-6
>> Severity: serious
>> > In file included from conffile.lex.c:242:
>> > ../../lib/stdio.h:64:3: error: #error "Please include config.h first."
>> >64 |  #error "Please include config.h first."
>> >   |   ^
>
>The lexed file conffile.lex.c seems to include some stuff before
>config.h is included which is causing it to choke.
>
>I'm not acquainted with lexers and not sure what causes this. I'd
>appreciate any help.

Adding mentors list as well. If someone can help with this, that'd be great.

Best,
Nilesh

help needed about Salsa pipelines

[Patrice Duroux]

Hi,

Trying to maintain pingus package using Salsa, I faced two failures
with the Salsa pipelines.

The first is related to test-crossbuild-arm64 and the message is:

Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
builddeps:.:arm64 : Depends: scons:arm64 but it is not installable
E: Unable to correct problems, you have held broken packages.

(cf. https://salsa.debian.org/Peutch-guest/pingus/-/jobs/4236854)

I do not understand because the scons package is arch:all, no?

The second is related to piuparts and the message is:

Reading package lists...
Building dependency tree...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
pingus : Depends: pingus-data (= 0.7.6-5+salsaci+20230522+2) but
0.7.6-5.1 is to be installed
W: Target Packages (main/binary-amd64/Packages) is configured multiple
times in /etc/apt/sources.list:1 and
/etc/apt/sources.list.d/debian.sources:1
W: Target Packages (main/binary-all/Packages) is configured multiple
times in /etc/apt/sources.list:1 and
/etc/apt/sources.list.d/debian.sources:1
E: Unable to correct problems, you have held broken packages.

(cf. https://salsa.debian.org/Peutch-guest/pingus/-/jobs/4236859)

Not clear to me why there is a version mismatch while installing the
pingus-data package?

Many thanks,
Patrice

Re: Help needed in setting up dev-environment

[Soren Stoutner]

I can second that.  Not that I have any personal experience with WSL, but I 
can tell you that dual boot is your friend.

Twenty-five years ago I got started on Linux in a dual boot environment.  
Slowly I started booting into Linux more and DOS/Windows less.  Now, very few 
of my machines even have a Windows installation.  It’s a good way to slowly 
migrate while enjoying a full Linux distro instead of a hobbled one.

On Friday, February 10, 2023 9:33:01 AM MST Danial Behzadi دانیال بهزادی 
wrote:
> For your own sake please don't!
> At least dual boot your machine with real Debian. WSL is too immature to be
> used as a development environment.
> در 10 فوریهٔ 2023 13:07:31 (UTC)، Ashutosh Pandey 
 نوشت:
> >Hello everyone,
> >
> >I am Ashutosh Pandey and I want to be a part of this year's GSoC program as
> >a mentee. I am doing my Bachelor's in Computer Science at ABESIT Ghaziabad,
> >India.
> >
> >I am interested in Dev-Ops and Full-Stack side of things and I have built
> >many projects where I have utilized my knowledge.
> >
> >Now coming to the help part
> >
> >I'm on a Windows machine and I have WSL enabled I'm using Ubuntu since
> >Debian has many packages I would like to contribute to Python and C code.
> >and I would prefer to work in my WSL ubuntu distro since it's closer to
> >Debian than Windows.
> >
> >   - Should I set up the development environment on Windows or on WSL?
> >   - In both cases(dev environment on Windows or WSL) is there any
> >   step-by-step guide for building Debian on Windows or on WSL?
> >
> >Thanks in advance and apologies if formatting isn't right.


-- 
Soren Stoutner
so...@stoutner.com

signature.asc
Description: This is a digitally signed message part.

Re: Help needed in setting up dev-environment

[Danial Behzadi دانیال بهزادی]

For your own sake please don't!
At least dual boot your machine with real Debian. WSL is too immature to be 
used as a development environment.

در 10 فوریهٔ 2023 13:07:31 (UTC)، Ashutosh Pandey 
 نوشت:
>Hello everyone,
>
>I am Ashutosh Pandey and I want to be a part of this year's GSoC program as
>a mentee. I am doing my Bachelor's in Computer Science at ABESIT Ghaziabad,
>India.
>
>I am interested in Dev-Ops and Full-Stack side of things and I have built
>many projects where I have utilized my knowledge.
>
>Now coming to the help part
>
>I'm on a Windows machine and I have WSL enabled I'm using Ubuntu since
>Debian has many packages I would like to contribute to Python and C code.
>and I would prefer to work in my WSL ubuntu distro since it's closer to
>Debian than Windows.
>
>   - Should I set up the development environment on Windows or on WSL?
>   - In both cases(dev environment on Windows or WSL) is there any
>   step-by-step guide for building Debian on Windows or on WSL?
>
>Thanks in advance and apologies if formatting isn't right.

Re: Help needed in setting up dev-environment

[Andrew M.A. Cater]

On Fri, Feb 10, 2023 at 06:37:31PM +0530, Ashutosh Pandey wrote:
> Hello everyone,
> 
> I am Ashutosh Pandey and I want to be a part of this year's GSoC program as
> a mentee. I am doing my Bachelor's in Computer Science at ABESIT Ghaziabad,
> India.
> 
> I am interested in Dev-Ops and Full-Stack side of things and I have built
> many projects where I have utilized my knowledge.
> 
> Now coming to the help part
> 
> I'm on a Windows machine and I have WSL enabled I'm using Ubuntu since
> Debian has many packages I would like to contribute to Python and C code.
> and I would prefer to work in my WSL ubuntu distro since it's closer to
> Debian than Windows.
> 
>- Should I set up the development environment on Windows or on WSL?
>- In both cases(dev environment on Windows or WSL) is there any
>step-by-step guide for building Debian on Windows or on WSL?
> 

There is a WSL2 Debian version: install that and use that instead of Ubuntu
(or a Windows dev environment).

This should be readily availabe from the Microsoft store. The latest stable
version of Debian is 11.6 at the moment: you should update the Debian you
download by using apt to do so.

Enjoy using Debian.

Andy Cater

> Thanks in advance and apologies if formatting isn't right.

Help needed in setting up dev-environment

[Ashutosh Pandey]

Hello everyone,

I am Ashutosh Pandey and I want to be a part of this year's GSoC program as
a mentee. I am doing my Bachelor's in Computer Science at ABESIT Ghaziabad,
India.

I am interested in Dev-Ops and Full-Stack side of things and I have built
many projects where I have utilized my knowledge.

Now coming to the help part

I'm on a Windows machine and I have WSL enabled I'm using Ubuntu since
Debian has many packages I would like to contribute to Python and C code.
and I would prefer to work in my WSL ubuntu distro since it's closer to
Debian than Windows.

   - Should I set up the development environment on Windows or on WSL?
   - In both cases(dev environment on Windows or WSL) is there any
   step-by-step guide for building Debian on Windows or on WSL?

Thanks in advance and apologies if formatting isn't right.

Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

[Andreas Tille]

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)

[Nilesh Patra]

On Thu, Oct 27, 2022 at 11:37:39AM +0200, Andreas Tille wrote:
> 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

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?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

[Andrius Merkys]

Hi Andreas,

On 2022-10-27 12:37, Andreas Tille wrote:

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.


Right, this does not seem correct... However, I am out of ideas about 
how to deal with this.


Best wishes,
Andrius

Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

[Andreas Tille]

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

Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

[Andrius Merkys]

Hi Andreas,

On 2022-10-27 11:31, Andreas Tille wrote:

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?


I have just pushed a fix. Please check if that works for you as well.

Best,
Andrius

Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

[Andreas Tille]

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

[Juri Grabowski]

Hello Andreas,

On 2022-09-29 14:54 4, Andreas Tille wrote:

I confirm this works.  However, uscan does not do the usual link to
orig.tar.gz.  Any idea why this is the case?

I have found this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896705

But did you have signing key from Rob Egan , because I
didn't found it on keyserver or in debian/upstream/signing-key.asc

Best Regards,
Juri Grabowski

Re: Help needed for watch file after bitbucket changed download page

[Andreas Tille]

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

Re: Help needed for watch file after bitbucket changed download page

[Juri Grabowski]

Hello,

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

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

Best Regards,
Juri Grabowski

Help needed for watch file after bitbucket changed download page

[Andreas Tille]

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

Re: Suggestion needed on test failures due to double arithmetics

[Andrey Rahmatullin]

On Thu, Nov 25, 2021 at 01:45:49PM +0100, Giulio Paci wrote:
> Moreover I am still wondering if the compiler behavior is correct in this
> case and why it is so unstable. 
It's correct when you don't care about the amount of precision, and it's
unstable for the reasons described in gcc(1) for the options you
mentioned, e.g. "This option prevents undesirable excess precision on
machines such as the 68000 where the floating registers (of the 68881)
keep more precision than a "double" is supposed to have.  Similarly for
the x86 architecture. For most programs, the excess precision does only
good, but a few programs rely on the precise definition of IEEE floating
point.", as in different circumstances the temporary values will have or
not have the x87 80-bit precision, leading to different calculation
results.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Il gio 25 nov 2021, 13:21 Andrey Rahmatullin  ha scritto:

> On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote:
> > The double values refer to timing information. The specific format,
> > known as CTM, stores information in seconds in decimals (e.g. "30.66"
> > seconds) from the beginning of the stream.
> > The failing tool reads this information into double variables
> Sounds like it just shouldn't read this data into a float type but use
> some fixed-point data type instead.
>

This is also my opinion (and already suggested upstream), although it would
make the code a little bit less readable.

Moreover I am still wondering if the compiler behavior is correct in this
case and why it is so unstable. Apart from this corner case (which in my
opinion should also work), I have not seen bad assumptions about double
arithmetics in the rest of the failing tool.

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Hi Paul,

On Thu, Nov 25, 2021 at 3:24 AM Paul Wise  wrote:
> Giulio Paci wrote:
>
> > 3) what is the most appropriate solution.
>
> As I understand it, floating point values should not be compared
> without some kind of accuracy/precision factor. Zero idea about the
> best reference for how to do it correctly, but here is a random one:
>
>
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

Thanks for this link.
It is a very great resource and summarizes very well what I already
know about double/float and much more.

Since the test case is dealing with timings, I think the most related
article is [1].
However even after reading that article it seems to me that in this
case it should be reasonable to expect stable behavior of those
operators.

I have uploaded simplified code that showcase the issue and some of
the instabilities [2]. The code seems to behave as if the last value
is different from the other 3, supposed equal values.
I am not even sure what I am seeing in the debugger, since most of the
values are optimized out (and I am not so skilled with debuggers).

[1] https://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/
[2] https://pastebin.com/embed_js/T3g560UV

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Andrey Rahmatullin]

On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote:
> The double values refer to timing information. The specific format,
> known as CTM, stores information in seconds in decimals (e.g. "30.66"
> seconds) from the beginning of the stream.
> The failing tool reads this information into double variables
Sounds like it just shouldn't read this data into a float type but use
some fixed-point data type instead.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

On Thu, Nov 25, 2021 at 8:54 AM Andrey Rahmatullin  wrote:
>
> On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote:
> > Dear mentors,
> >   while updating SCTK package I enabled the execution of the test suite
> > which was previously disabled. The tests are working fine on x86_64
> > architecture, but a couple of them are failing on i386.
> > After investigation [1] I found out that tests are failing because they
> > rely on the assumptions that, when a and b have the same double value:
> > 1) "a < b" is false;
> > 2) "a - b" is 0.0.
> What do they actually test, why do they use these assumptions?

SCTK is a toolkit to evaluate speech recognition (and other related
tasks) tools performance.
These tools usually read audio streams and produce simple text files
containing the transcriptions and time information (relative to the
stream) to synchronize the transcription to the stream. These files
are very similar to video subtitles files.
The SCTK compares two textual files (usually one is a manually created
file and the other is created by an automatic tool) to score how
different these outputs are.
The tests are checking that SCTK produces the same score reports when
provided with the same input files.

The double values refer to timing information. The specific format,
known as CTM, stores information in seconds in decimals (e.g. "30.66"
seconds) from the beginning of the stream.
The failing tool reads this information into double variables and, to
simplify, it compares "up to when the timings in one file is less than
the timings in the other files. If it exceeds or is the same, it
checks the difference".

In this kind of application you are not usually going beyond what you
can store uncompressed on a filesystem in PCM. So, even assuming audio
samples of 1 byte, int64 should be a reasonable type to store timings
(in samples, rather then seconds). But I understand that doing so
would complicate the logic of the tool, especially since it is very
unlikely that math approximation would be an issue. To be honest I did
not expect the corner case above would fail since it is comparing a
value against another value that should just be the same.

I have uploaded simplified code that showcase the issue and some of
the instabilities [1]. The code seems to behave as if the last value
is different from the other 3, supposed equal values.

[1] https://pastebin.com/embed_js/T3g560UV

Bests,
Giulio

Re: Suggestion needed on test failures due to double arithmetics

[Andrey Rahmatullin]

On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote:
> Dear mentors,
>   while updating SCTK package I enabled the execution of the test suite
> which was previously disabled. The tests are working fine on x86_64
> architecture, but a couple of them are failing on i386.
> After investigation [1] I found out that tests are failing because they
> rely on the assumptions that, when a and b have the same double value:
> 1) "a < b" is false;
> 2) "a - b" is 0.0.
What do they actually test, why do they use these assumptions?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestion needed on test failures due to double arithmetics

[Paul Wise]

Giulio Paci wrote:

> 3) what is the most appropriate solution.

As I understand it, floating point values should not be compared
without some kind of accuracy/precision factor. Zero idea about the
best reference for how to do it correctly, but here is a random one:

https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Suggestion needed on test failures due to double arithmetics

[Giulio Paci]

Dear mentors,
  while updating SCTK package I enabled the execution of the test suite
which was previously disabled. The tests are working fine on x86_64
architecture, but a couple of them are failing on i386.
After investigation [1] I found out that tests are failing because they
rely on the assumptions that, when a and b have the same double value:
1) "a < b" is false;
2) "a - b" is 0.0.
Unfortunately, these assumptions do not always hold on i386 as the behavior
of those operators seem to change according to compilation flags (e.g.,
optimization or debug flags) or the surrounding instructions (e.g., if a
function is invoked nearby or not).

I think the reason for this behavior is probably related to gcc
options -mfpmath
[2] and -ffloat-store [3]. Using -ffloat-store option indeed seems to fix
the issue.

However I am wondering:
1) if enabling -ffloat-store is an acceptable solution;
2) if this is a compiler bug (I always expect approximated results with
double arithmetics, but the above assumptions seem very basic to me,
considering that they cover the special case where a and b are equal);
3) what is the most appropriate solution.

Do you have any suggestion?

I just asked the same question upstream, but I would appreciate your
opinion as well.

Bests,
Giulio

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981030#39
[2]
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options
[3]
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options

Re: Advice needed for a strange request about getmail vs. getmail6

[Jeremy Stanley]

On 2021-10-18 22:17:27 +0100 (+0100), Sudip Mukherjee wrote:
[...]
> Why is the name a problem? getmail and getmail6 are different
> packages.
[...]

Because users are quite likely to assume that getmail6 is version 6
of the official getmail project, rather than a fork of getmail.

In a community I'm involved with, some developers decided to create
a bash script linter with output compatible to that of the pep8
utility for Python. They originally named the project bash8, but
they were soon strongly advised to rename it to something which
wouldn't mislead users into thinking it was version 8 of bash, and
so it's name was switched to bashate in order to avoid confusion.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Advice needed for a strange request about getmail vs. getmail6

[Sudip Mukherjee]

On Mon, Oct 18, 2021 at 9:25 PM Geert Stappers  wrote:
>
> On Tue, Oct 19, 2021 at 12:40:48AM +0500, Andrey Rahmatullin wrote:
> > On Mon, Oct 18, 2021 at 08:27:51PM +0100, Sudip Mukherjee wrote:
> > > Hi All,
> > >
> > > To give a brief history, Debian had "getmail" which was based on
> > > Python2 and was removed. Then there was a fork available named
> > > "getmail6" which was based on Python3. A transitional package linked
> > > them by #979060.
> > >
> > > Now, the upstream of "getmail" has raised a bug in Debian asking
> > > "getmail6" to be removed or renamed and he claims that users of
> > > getmail6 are imposing a support burden on him as users are thinking it
> > > to be getmail and mailing the getmail mailing list. #996569
> > >
> > > I went through the getmail mailing list archive and could find only
> > > one such mail. I am not sure what to reply to him, and need your
> > > suggestions about what to do now please.
> > Debian is a wrong place to do this.
> > And if not for the trademark violation claims I'd suggest ignoring this.
> > But the claims should be directed to the upstream first.

Thanks, I will forward the bug upstream.

But incidentally, I was searching the trademark database and it seems
"getmail" is a trademark registered by "Blue Cube Solutions Limited"
in UK.
https://trademarks.ipo.gov.uk/ipo-tmcase/page/Results/1/UK3129080

Not sure if "getmail" now should be using the name "getmail" as its a
registered trademark of another company. :)

>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996569 IS opened
> by the upstream author.
>
> In https://marc.info/?l=getmail=163440038426857=2
> is Charles Cazabon, upstream author, expressing that
> the poorly named fork of getmail should get a name without
> the string 'getmail'.
>
> In thread https://marc.info/?t=16341197233=1=2 you find
> also the author of the fork, Roland Puntaier.
>
>
> Back to the core of the bugreport, getmail vs getmail6.
>
> 
>   getmail6 was a good idea.
>   time did learn us it was too optimistic.
> 

Why is it too optimistic? imho, getmail6 is a good package which has
good upstream support. Roland had been very prompt in fixing any bug
report that I or anyone else has reported.

>
>
> 
>   the name getmail6
> 
>
>
> Solution would be a different name.

And, this is what I fail to understand. Why is the name a problem?
getmail and getmail6 are different packages. Its the transitional
package which let the users of getmail use getmail6 when they upgraded
to Bullseye.

>
> When no one comes with a different name,
> is removal of getmail6 from the Debian archive the next best thing.

And, this is also another point which I am failing to understand. How
does the removal of getmail6 help Bullseye?


-- 
Regards
Sudip

Re: Advice needed for a strange request about getmail vs. getmail6

[Geert Stappers]

On Tue, Oct 19, 2021 at 12:40:48AM +0500, Andrey Rahmatullin wrote:
> On Mon, Oct 18, 2021 at 08:27:51PM +0100, Sudip Mukherjee wrote:
> > Hi All,
> > 
> > To give a brief history, Debian had "getmail" which was based on
> > Python2 and was removed. Then there was a fork available named
> > "getmail6" which was based on Python3. A transitional package linked
> > them by #979060.
> > 
> > Now, the upstream of "getmail" has raised a bug in Debian asking
> > "getmail6" to be removed or renamed and he claims that users of
> > getmail6 are imposing a support burden on him as users are thinking it
> > to be getmail and mailing the getmail mailing list. #996569
> > 
> > I went through the getmail mailing list archive and could find only
> > one such mail. I am not sure what to reply to him, and need your
> > suggestions about what to do now please.
> Debian is a wrong place to do this.
> And if not for the trademark violation claims I'd suggest ignoring this.
> But the claims should be directed to the upstream first.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996569 IS opened
by the upstream author.

In https://marc.info/?l=getmail=163440038426857=2
is Charles Cazabon, upstream author, expressing that
the poorly named fork of getmail should get a name without
the string 'getmail'.

In thread https://marc.info/?t=16341197233=1=2 you find
also the author of the fork, Roland Puntaier.


Back to the core of the bugreport, getmail vs getmail6.


  getmail6 was a good idea.
  time did learn us it was too optimistic.




  the name getmail6



Solution would be a different name.

When no one comes with a different name,
is removal of getmail6 from the Debian archive the next best thing.


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Re: Advice needed for a strange request about getmail vs. getmail6

[Andrey Rahmatullin]

On Mon, Oct 18, 2021 at 08:27:51PM +0100, Sudip Mukherjee wrote:
> Hi All,
> 
> To give a brief history, Debian had "getmail" which was based on
> Python2 and was removed. Then there was a fork available named
> "getmail6" which was based on Python3. A transitional package linked
> them by #979060.
> 
> Now, the upstream of "getmail" has raised a bug in Debian asking
> "getmail6" to be removed or renamed and he claims that users of
> getmail6 are imposing a support burden on him as users are thinking it
> to be getmail and mailing the getmail mailing list. #996569
> 
> I went through the getmail mailing list archive and could find only
> one such mail. I am not sure what to reply to him, and need your
> suggestions about what to do now please.
Debian is a wrong place to do this. And if not for the trademark violation
claims I'd suggest ignoring this. But the claims should be directed to the
upstream first.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Advice needed for a strange request about getmail vs. getmail6

[Sudip Mukherjee]

Hi All,

To give a brief history, Debian had "getmail" which was based on
Python2 and was removed. Then there was a fork available named
"getmail6" which was based on Python3. A transitional package linked
them by #979060.

Now, the upstream of "getmail" has raised a bug in Debian asking
"getmail6" to be removed or renamed and he claims that users of
getmail6 are imposing a support burden on him as users are thinking it
to be getmail and mailing the getmail mailing list. #996569

I went through the getmail mailing list archive and could find only
one such mail. I am not sure what to reply to him, and need your
suggestions about what to do now please.


-- 
Regards
Sudip

Re: Help needed to sign and upload dune packages (part of debian-science) to experimental

[Patrick Jaap]

Hi Adam! Thanks for reporting the problem!

I think I forgot to add the dependency "libdune-grid-doc" in the 
2.8.0~rc1 package which contains the missing msh file. It was only a 
build-dependency and therefore I did not encounter the problem on my end 
where I built the package.


In the meantime DUNE 2.8 was released and we will upload updated 2.8.0 
packages of all DUNE modules this week.


Best,
Patrick


Am 07.09.21 um 13:34 schrieb Adam Borowski:

On Tue, Sep 07, 2021 at 10:43:45AM +0200, Lisa Julia Nebel wrote:

Hello debian science team and debian mentors,

thanks for all the help so far with uploading the dune-packages to the
debian archive!!!

We are currently looking into the problems regarding alberta, and apart from
that, then there are only two unreviewed packages left:

  * https://mentors.debian.net/package/dune-functions/
  * https://mentors.debian.net/package/dune-pdelab/

They still fail for me:
  7/23 Test  #7: globalvaluedlfetest ...***Failed0.40 sec
Reading 2d Gmsh grid...
Dune reported error: Dune::IOError 
[read:/usr/include/dune/grid/io/file/gmshreader.hh:372]: Could not open 
/usr/share/doc/dune-grid/grids/gmsh/curved2d.msh

   Start  8: gridviewfunctionspacebasistest
  8/23 Test  #8: gridviewfunctionspacebasistest ***Failed0.92 sec
+++  Testing on structured 1d grids  
   Testing B-spline basis with open knot vectors
order: 0
order: 1
order: 2
   Testing B-spline basis with non-open knot vectors
order: 0
order: 1
order: 2
+++  Testing on structured 2d grids  
   Testing B-spline basis with open knot vectors
order: 0
order: 1
order: 2
   Testing B-spline basis with non-open knot vectors
order: 0
order: 1
order: 2
+++  Testing on structured 3d grids  
   Testing B-spline basis with open knot vectors
order: 0
order: 1
order: 2
   Testing B-spline basis with non-open knot vectors
order: 0
order: 1
order: 2
+++  Testing on hybrid 2d grid  
Reading 2d Gmsh grid...
Dune reported error: Dune::IOError 
[read:/usr/include/dune/grid/io/file/gmshreader.hh:372]: Could not open 
/usr/share/doc/dune-grid/grids/gmsh/hybrid-testgrid-2d.msh

and dune-pdelab B-Depends on dune-functions.


Meow!

Re: Help needed to sign and upload dune packages (part of debian-science) to experimental

[Adam Borowski]

On Tue, Sep 07, 2021 at 10:43:45AM +0200, Lisa Julia Nebel wrote:
> Hello debian science team and debian mentors,
> 
> thanks for all the help so far with uploading the dune-packages to the
> debian archive!!!
> 
> We are currently looking into the problems regarding alberta, and apart from
> that, then there are only two unreviewed packages left:
> 
>  * https://mentors.debian.net/package/dune-functions/
>  * https://mentors.debian.net/package/dune-pdelab/

They still fail for me:
 7/23 Test  #7: globalvaluedlfetest ...***Failed0.40 sec
Reading 2d Gmsh grid...
Dune reported error: Dune::IOError 
[read:/usr/include/dune/grid/io/file/gmshreader.hh:372]: Could not open 
/usr/share/doc/dune-grid/grids/gmsh/curved2d.msh

  Start  8: gridviewfunctionspacebasistest
 8/23 Test  #8: gridviewfunctionspacebasistest ***Failed0.92 sec
   +++  Testing on structured 1d grids  
  Testing B-spline basis with open knot vectors
   order: 0
   order: 1
   order: 2
  Testing B-spline basis with non-open knot vectors
   order: 0
   order: 1
   order: 2
   +++  Testing on structured 2d grids  
  Testing B-spline basis with open knot vectors
   order: 0
   order: 1
   order: 2
  Testing B-spline basis with non-open knot vectors
   order: 0
   order: 1
   order: 2
   +++  Testing on structured 3d grids  
  Testing B-spline basis with open knot vectors
   order: 0
   order: 1
   order: 2
  Testing B-spline basis with non-open knot vectors
   order: 0
   order: 1
   order: 2
   +++  Testing on hybrid 2d grid  
Reading 2d Gmsh grid...
Dune reported error: Dune::IOError 
[read:/usr/include/dune/grid/io/file/gmshreader.hh:372]: Could not open 
/usr/share/doc/dune-grid/grids/gmsh/hybrid-testgrid-2d.msh

and dune-pdelab B-Depends on dune-functions.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ How to exploit the Bible for weight loss:
⢿⡄⠘⠷⠚⠋⠀ Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
⠈⠳⣄

Re: Help needed to sign and upload dune packages (part of debian-science) to experimental

[Lisa Julia Nebel]

Hello debian science team and debian mentors,

thanks for all the help so far with uploading the dune-packages to the 
debian archive!!!


We are currently looking into the problems regarding alberta, and apart 
from that, then there are only two unreviewed packages left:


 * https://mentors.debian.net/package/dune-functions/
 * https://mentors.debian.net/package/dune-pdelab/

In case someone of you can find the time to review these - that would be 
great!


Thanks a lot and kind regards,
Lisa and Patrick

On 19.08.21 09:39, Sudip Mukherjee wrote:

Hi Lisa,

Also, adding Debian Science list in Cc.

On Tue, Aug 17, 2021 at 3:42 PM Lisa Julia Nebel
 wrote:

Dear debian mentors,

we (patrick.j...@tu-dresden.de and lisa_julia.ne...@tu-dresden.de) have 
successfully tested a new release of the dune-packages 
(https://salsa.debian.org/science-team?utf8=%E2%9C%93=dune) on our local 
machines.

The current maintainer Ansgar Burchardt 
(https://tracker.debian.org/pkg/dune-common) is unfortunately too busy to sign 
and upload the packages to experimental.

Is there someone else among you who sign the packages and can upload them to 
experimental? Can you then let us know which files exactly you need to the 
upload? Then, we will send these to you or provide a download.

The usual process will be to upload your package at
https://mentors.debian.net/, raise a RFS bug and then request the
Science Team to sponsor the package and do a team upload.




OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help needed to sign and upload dune packages (part of debian-science) to experimental

[Lisa Julia Nebel]

Dear Sudip,

thanks a lot for your answer :) we will proceed then as described at 
https://mentors.debian.net/.


Best regards
Lisa

On 19.08.21 09:39, Sudip Mukherjee wrote:

Hi Lisa,

Also, adding Debian Science list in Cc.

On Tue, Aug 17, 2021 at 3:42 PM Lisa Julia Nebel
 wrote:

Dear debian mentors,

we (patrick.j...@tu-dresden.de and lisa_julia.ne...@tu-dresden.de) have 
successfully tested a new release of the dune-packages 
(https://salsa.debian.org/science-team?utf8=%E2%9C%93=dune) on our local 
machines.

The current maintainer Ansgar Burchardt 
(https://tracker.debian.org/pkg/dune-common) is unfortunately too busy to sign 
and upload the packages to experimental.

Is there someone else among you who sign the packages and can upload them to 
experimental? Can you then let us know which files exactly you need to the 
upload? Then, we will send these to you or provide a download.

The usual process will be to upload your package at
https://mentors.debian.net/, raise a RFS bug and then request the
Science Team to sponsor the package and do a team upload.

Re: Help needed to sign and upload dune packages (part of debian-science) to experimental

[Sudip Mukherjee]

Hi Lisa,

Also, adding Debian Science list in Cc.

On Tue, Aug 17, 2021 at 3:42 PM Lisa Julia Nebel
 wrote:
>
> Dear debian mentors,
>
> we (patrick.j...@tu-dresden.de and lisa_julia.ne...@tu-dresden.de) have 
> successfully tested a new release of the dune-packages 
> (https://salsa.debian.org/science-team?utf8=%E2%9C%93=dune) on our 
> local machines.
>
> The current maintainer Ansgar Burchardt 
> (https://tracker.debian.org/pkg/dune-common) is unfortunately too busy to 
> sign and upload the packages to experimental.
>
> Is there someone else among you who sign the packages and can upload them to 
> experimental? Can you then let us know which files exactly you need to the 
> upload? Then, we will send these to you or provide a download.

The usual process will be to upload your package at
https://mentors.debian.net/, raise a RFS bug and then request the
Science Team to sponsor the package and do a team upload.


-- 
Regards
Sudip

Help needed to sign and upload dune packages (part of debian-science) to experimental

[Lisa Julia Nebel]

Dear debian mentors,

we (patrick.j...@tu-dresden.de and lisa_julia.ne...@tu-dresden.de 
) have successfully tested a new 
release of the dune-packages 
(https://salsa.debian.org/science-team?utf8=%E2%9C%93=dune 
) on 
our local machines.


The current maintainer Ansgar Burchardt 
(https://tracker.debian.org/pkg/dune-common) is unfortunately too busy 
to sign and upload the packages to experimental.


Is there someone else among you who sign the packages and can upload 
them to experimental? Can you then let us know which files exactly you 
need to the upload? Then, we will send these to you or provide a download.


Thanks a lot and best wishes

Patrick Jaap and Lisa Julia Nebel

Help with C++ issue in sina needed

[Andreas Tille]

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

[Eduardo M KALINOWSKI]

On 21/06/2020 18:43, Andreas Tille wrote:
> 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.

Well, is libboost-regex-dev (or an specific version) installed?


-- 
"I don't care who does the electing as long as I get to do the nominating."
-- Boss Tweed

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Automake help to find boost_regexp needed

[Andreas Tille]

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

Re: Automake help to find boost_regexp needed

[铜豌豆 Linux]

Hi,

    In my computer, I use dpkg-buildpackage,

[...]
checking for libboost_regex... yes
[...]

But I meet the other errors:

g++ -std=c++0x -g -O3 -std=c++0x -g -O2
-fdebug-prefix-map=/home/atzlinux/devel/offical/ufasta=.
-fstack-protector-strong -Wformat -Werror=format-security -I/usr/include
-lboost_regex -Wl,-z,relro -o ufasta ufasta.o common.o one.o sizes.o
head.o tail.o rc.o n50.o extract.o format.o sort.o dgrep.o dsort.o
split.o rsort.o hgrep.o dgrep.o 
/usr/bin/ld: dgrep.o: in function
`boost::exception_detail::error_info_injector::error_info_injector(boost::exception_detail::error_info_injector
const&)':
./dgrep.cc:11: multiple definition of `dgrep_main(int, char**)';
dgrep.o:./dgrep.cc:11: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:639：ufasta] 错误 1
make[2]: 离开目录“/home/atzlinux/devel/offical/ufasta”
make[1]: *** [Makefile:542：all] 错误 2
make[1]: 离开目录“/home/atzlinux/devel/offical/ufasta”
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:21：build] 错误 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

I use Debian 10.4 stable.

dpkg -l|grep libboost

ii  libboost-regex-dev:amd64  
1.67.0.1 amd64    regular
expression library for C++ (default version)
ii  libboost-regex1.67-dev:amd64  
1.67.0-13+deb10u1    amd64    regular
expression library for C++
ii  libboost-regex1.67.0:amd64
1.67.0-13+deb10u1    amd64    regular
expression library for C++
ii  libboost1.67-dev:amd64
1.67.0-13+deb10u1    amd64    Boost C++
Libraries development files

The attachment is my buildlog.

在 2020/6/22 上午5:43, Andreas Tille 写道:
> 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
>
-- 
肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux
《铜豌豆 Linux》 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB



ufasta_0.0.3+git20190131.85d60d1-1_amd64.buildlog
Description: Binary data


signature.asc
Description: Binary data


signature.asc
Description: OpenPGP digital signature

Automake help to find boost_regexp needed

[Andreas Tille]

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

Re: cmake help needed for metabat

[Alexis Murzeau]

hi,

Le 29/05/2020 à 10:10, Andreas Tille a écrit :
> 
>> 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?

I've looked at your commit on git, and the issue is that you need to
remove both "add_dependencies" completely in src/CMakeLists.txt.
zlib and htslib targets doesn't exist anymore as they were created by
scripts in cmake/ folder.

> 
> Thanks again
> 
>   Andreas.
> 


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Re: cmake help needed for metabat

[Andreas Tille]

Hi Alexis,

thanks a lot for your extremely helpful explanation.

On Thu, May 28, 2020 at 10:04:02PM +0200, Alexis Murzeau wrote:
> 
> There is a Debian patch that replace cmake/htslib.cmake with a
> pkg_check_modules call, which doesn't create targets, so that why it fails.
> There is the same issue with zlib, and a missing header
> "metabat_version.h" created by cmake/git-watcher.cmake.
> 
> 
> About HTSlib issue
> --
> 
> With pkgconfig, you instead get just variables (no target), including
> these interesting ones:
>  - HTSlib_LIBRARIES
>  - HTSlib_INCLUDE_DIRS
> 
> (The HTSlib comes from the first argument of pkg_check_modules)
> 
> In cmake version 3.6 and later, an argument to pkg_check_modules can
> create a target to be used with target_link_libraries that will take
> care of the libraries and include dirs.
> This is the IMPORTED_TARGET option, it will create a target named
> PkgConfig::.
> 
> So you can have:
> ```
> pkg_check_modules(HTSlib REQUIRED IMPORTED_TARGET htslib)
> ```
> 
> and then use it:
> ```
> target_link_libraries(target [...] PkgConfig::HTSlib)
> ```
> 
> But metabat seems to require only cmake 3.5, so it might not be allowed
> for upstream to do that.
> 
> Instead you can just do the same as done for Boost and add:
> ```
> include_directories(${HTSlib_INCLUDE_DIRS})
> ```
> and
> ```
> target_link_libraries(target [...] ${HTSlib_INCLUDE_DIRS})
> ```

Makes sense.
 
> About zlib issue
> 
> 
> FindPackage(ZLIB) don't create any "zlib" target, but a "ZLIB::ZLIB"
> target instead, which can be used with target_link_libraries.
> 
> So you can just replace the add_dependencies(target zlib) with a new
> item there:
> ```
> target_link_libraries(target [...] ZLIB::ZLIB)
> ```
> 
> About the metabat_version.h header issue
> 
> 
> cmake/git-watcher.cmake generate metabat_version.h from
> metabat_version.h.in.
> So as with the patch, git-watcher.cmake is not used anymore, you still
> need to handle that.
> 
> Either put fake stuff like this:
> ```
> set(PRE_CONFIGURE_FILE "metabat_version.h.in")
> set(POST_CONFIGURE_FILE "metabat_version.h")
> # include(cmake/git-watcher.cmake)
> 
> # Add this:
> set(GIT_RETRIEVED_STATE "")
> set(GIT_HEAD_SHA1 "nosha")
> set(GIT_IS_DIRTY 0)
> set(BUILD_TIMESTAMP 0)
> configure_file("${PRE_CONFIGURE_FILE}" "${POST_CONFIGURE_FILE}" @ONLY)
> include_directories("${CMAKE_CURRENT_BINARY_DIR}")
> ```
> 
> Or you change directly the code that use these defines to use different
> data (like Debian version instead).

Makes sense.  I was not up to this issue - just was dealing with errors
step by step but I guess this would have been my next question. ;-)
Thanks a lot for the proactive answer.
 
> Conclusion
> --
> 
> I'm attaching a patch with what I've said here.
> The build still doesn't work because of tests failure.
> The tests require data files like "contigs_depth.txt" but can't find them.

OK, I need to deal with this.

> In test/CMakeLists.txt, there is a reference to them as
> "${CMAKE_BINARY_DIR}/contigs_depth.txt", but it should be
> "${CMAKE_CURRENT_SOURCE_DIR}/contigs_depth.txt", unless the text files
> should be copied while building, but that doesn't seem the case.

I'll check upstream Git or file an issue about this.

Unfortunately your patch did not applied cleanly - no idea why.  I have
added it manually and reread your explanation which I think are
implemented correctly.  Unfortunately in my pbuilder I get the same
cmake failure as before and since I think I've now understand the issue
I'm even more in vain since its not working anyway for me but you
confirmed that it should work.  Could you be so kind to have another
look on the latest state in Git?

Thanks again

  Andreas.

> -- 
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

> diff --git a/debian/patches/use_debian_packaged_libs.patch 
> b/debian/patches/use_debian_packaged_libs.patch
> index 05c4a0e..b532dc9 100644
> --- a/debian/patches/use_debian_packaged_libs.patch
> +++ b/debian/patches/use_debian_packaged_libs.patch
> @@ -1,7 +1,15 @@
> -Author: Andreas Tille 
> +From: Andreas Tille 
> +Date: Thu, 28 May 2020 21:21:02 +0200
> +Subject: Use Debian packaged libraries
> +
>  Last-Update: Thu, 28 May 2020 17:21:42 +0200
> -Description: Use Debian packaged libraries
> +---
> + CMakeLists.txt | 15 ---
> + src/CMakeLists.txt |  8 
> + 2 files changed, 16 insertions(+), 7 deletions(-)
> 
> +diff --git a/CMakeLists.txt b/CMakeLists.txt
> +index 638c27c..6166143 100644
>  --- a/CMakeLists.txt
>  +++ b/CMakeLists.txt
>  @@ -8,8 +8,10 @@ endif()
> @@ -17,32 +25,52 @@ Description: Use Debian packaged libraries
> 
>   set(CMAKE_CXX_STANDARD 11)
>   set(CMAKE_CXX_STANDARD_REQUIRED ON)
> -@@ -23,7 +25,7 @@ add_definitions(-D_XOPEN_SOURCE=700)
> +@@ -23,7 +25,14 @@ add_definitions(-D_XOPEN_SOURCE=700)
> 
>   set(PRE_CONFIGURE_FILE "metabat_version.h.in")
>   

Re: cmake help needed for metabat

[Alexis Murzeau]

Hi,

Le 28/05/2020 à 20:33, Andreas Tille a écrit :
> 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:
> 
> [...]
> 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
> 

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})
```

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).


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.
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.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F
diff --git a/debian/patches/use_debian_packaged_libs.patch 
b/debian/patches/use_debian_packaged_libs.patch
index 05c4a0e..b532dc9 100644
--- a/debian/patches/use_debian_packaged_libs.patch
+++ b/debian/patches/use_debian_packaged_libs.patch
@@ -1,7 +1,15 @@
-Author: Andreas Tille 
+From: Andreas Tille 
+Date: Thu, 28 May 2020 21:21:02 +0200
+Subject: Use Debian packaged libraries
+
 Last-Update: Thu, 28 May 2020 17:21:42 +0200
-Description: Use Debian packaged libraries
+---
+ CMakeLists.txt | 15 ---
+ src/CMakeLists.txt |  8 
+ 2 files changed, 16 insertions(+), 7 deletions(-)

+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 638c27c..6166143 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -8,8 +8,10 @@ endif()
@@ -17,32 +25,52 @@ Description: Use Debian packaged libraries

  set(CMAKE_CXX_STANDARD 11)
  set(CMAKE_CXX_STANDARD_REQUIRED ON)
-@@ -23,7 +25,7 @@ add_definitions(-D_XOPEN_SOURCE=700)
+@@ -23,7 +25,14 @@ add_definitions(-D_XOPEN_SOURCE=700)

  set(PRE_CONFIGURE_FILE "metabat_version.h.in")
  set(POST_CONFIGURE_FILE "metabat_version.h")
 -include(cmake/git-watcher.cmake)
 +# include(cmake/git-watcher.cmake)
++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}")
++

  if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
# using Clang
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index d47843e..b8dc3b9 100644
 --- a/src/CMakeLists.txt
 +++ b/src/CMakeLists.txt
-@@ -36,7 +36,7 

cmake help needed for metabat

[Andreas Tille]

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: [covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)

[Andreas Tille]

On Mon, Apr 06, 2020 at 08:53:12PM +0100, Jeremy Sowden wrote:
> > Thanks a lot for your help anyway
> 
> Patch attached.

Thank you so much again, Andreas.

-- 
http://fam-tille.de

Re: [covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)

[Jeremy Sowden]

On 2020-04-06, at 20:32:12 +0200, Andreas Tille wrote:
> Hi Jeremy,
>
> On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote:
> > On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote:
> > >dh_autoreconf -O--buildsystem=R
> > > autoheader: warning: missing template: HAVE_OPENMP
> > > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description])
> > > autoreconf: /usr/bin/autoheader failed with exit status: 1
> > > dh_autoreconf: error: autoreconf -f -i returned exit code 1
> > > make: *** [debian/rules:4: binary] Error 25
> > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> > > status 2
> >
> > Similar to some of the problems with mpqc yesterday.  Patch attached.
>
> Thanks a lot for your patch (commited to Git[1]) which solved the
> autoconf issue.  Unfortunately there is another issue now:
>
>
> ecking for stdint.h... yes
> checking for unistd.h... yes
> checking dispatch/dispatch.h usability... no
> checking dispatch/dispatch.h presence... no
> checking for dispatch/dispatch.h... no
> checking whether OpenMP will work in a package... yes
> configure: creating ./config.status
> config.status: creating src/Makevars
> config.status: creating src/config.h
> ** libs
> make[1]: Entering directory '/build/r-bioc-rgadem-2.34.1/src'
> gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic  -g -O2 
> -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -g  -c Gadem_Analysis.c -o Gadem_Analysis.o
> Gadem_Analysis.c: In function 'GADEM_Analysis':
> Gadem_Analysis.c:618:7: warning: implicit declaration of function 'DO_APPLY' 
> [-Wimplicit-function-declaration]
>   618 |   DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
>   |   ^~~~
> Gadem_Analysis.c:618:16: error: invalid use of void expression
>   618 |   DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
>   |^~~
>   619 |  startPWMfound, minminSites, 
> maxpFactor[ii],
>   |  
> ~~~
>   620 |  numSeq, numSeqEM, seq, rseq, 
> seqLen, Iseq,
>   |  
> ~~
>   621 |  bfreq0, posWeight, weightType,
>   |  ~~
>   622 |  pvalueCutoff, emSeqLen,
>   |  ~~~
>   623 |  pwm[ii], pwmLen[ii], epwm[ii], 
> opwm[ii],
>   |  
> 
>   624 |  pwmConsensus[ii], 
> scoreCutoff+ii, sdyad[ii], ii),
>   |  
> 
> make[1]: *** [/usr/lib/R/etc/Makeconf:168: Gadem_Analysis.o] Error 1
>
>
> Thanks a lot for your help anyway

Patch attached.

J.
From d3b5c1358bcf8463719c0175d759f74819e74f8e Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Mon, 6 Apr 2020 20:41:54 +0100
Subject: [PATCH] The definition of DO_APPLY in src/config.h.in is clobbered by
 autoheader, so add it in Gadem_Analysis.c where it is used.

---
 src/Gadem_Analysis.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/src/Gadem_Analysis.c b/src/Gadem_Analysis.c
index a604afeb0479..0e868b56918a 100755
--- a/src/Gadem_Analysis.c
+++ b/src/Gadem_Analysis.c
@@ -25,6 +25,32 @@
 
 #include "config.h"
 
+#ifdef HAVE_DISPATCH_DISPATCH_H
+  #include 
+  #define DO_APPLY(task, n_times, counter_name) \
+R_CheckUserInterrupt(); \
+dispatch_apply(n_times, \
+   dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),   \
+   ^(size_t counter_name) { task; });
+  
+#else // not HAVE_DISPATCH_DISPATCH_H
+  #ifdef HAVE_OPENMP
+#include 
+#define DO_APPLY(task, n_times, counter_name) \
+  R_CheckUserInterrupt(); \
+  _Pragma("omp parallel for") \
+  for (int counter_name = 0; counter_name < n_times; ++counter_name) { \
+task; \
+  }
+  #else // not HAVE_OPENMP
+#define DO_APPLY(task, n_times, counter_name) \
+  for (int counter_name = 0; counter_name < n_times; ++counter_name) { \
+R_CheckUserInterrupt(); \
+task; \
+  }
+  #endif // HAVE_OPENMP
+#endif // HAVE_DISPATCH_DISPATCH_H
+
 /*---
 // v1.3.1: last modifications 5/14/2011
 // added user-input background model
-- 
2.25.1



signature.asc
Description: PGP signature

[covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)

[Andreas Tille]

Hi Jeremy,

On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote:
> On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote:
> >dh_autoreconf -O--buildsystem=R
> > autoheader: warning: missing template: HAVE_OPENMP
> > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description])
> > autoreconf: /usr/bin/autoheader failed with exit status: 1
> > dh_autoreconf: error: autoreconf -f -i returned exit code 1
> > make: *** [debian/rules:4: binary] Error 25
> > dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> > status 2
> 
> Similar to some of the problems with mpqc yesterday.  Patch attached.

Thanks a lot for your patch (commited to Git[1]) which solved the
autoconf issue.  Unfortunately there is another issue now:


ecking for stdint.h... yes
checking for unistd.h... yes
checking dispatch/dispatch.h usability... no
checking dispatch/dispatch.h presence... no
checking for dispatch/dispatch.h... no
checking whether OpenMP will work in a package... yes
configure: creating ./config.status
config.status: creating src/Makevars
config.status: creating src/config.h
** libs
make[1]: Entering directory '/build/r-bioc-rgadem-2.34.1/src'
gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c 
Gadem_Analysis.c -o Gadem_Analysis.o
Gadem_Analysis.c: In function 'GADEM_Analysis':
Gadem_Analysis.c:618:7: warning: implicit declaration of function 'DO_APPLY' 
[-Wimplicit-function-declaration]
  618 |   DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
  |   ^~~~
Gadem_Analysis.c:618:16: error: invalid use of void expression
  618 |   DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
  |^~~
  619 |  startPWMfound, minminSites, 
maxpFactor[ii],
  |  
~~~
  620 |  numSeq, numSeqEM, seq, rseq, 
seqLen, Iseq,
  |  
~~
  621 |  bfreq0, posWeight, weightType,
  |  ~~
  622 |  pvalueCutoff, emSeqLen,
  |  ~~~
  623 |  pwm[ii], pwmLen[ii], epwm[ii], 
opwm[ii],
  |  

  624 |  pwmConsensus[ii], scoreCutoff+ii, 
sdyad[ii], ii),
  |  

make[1]: *** [/usr/lib/R/etc/Makeconf:168: Gadem_Analysis.o] Error 1


Thanks a lot for your help anyway

  Andreas.

[1] https://salsa.debian.org/r-pkg-team/r-bioc-rgadem

-- 
http://fam-tille.de

Re: [covid-19] Help with r-bioc-rgadem needed

[Jeremy Sowden]

On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote:
> since I did not got any response from r-pkg team yet I guess nobody
> has a clue about this autoconf issue.  So I'd like to forward this
> question here to finalise a package which is relevant for our COVID-19
> Biohackathon.
>
> I injected r-bioc-rgadem[1] but the build ends in:
>
>dh_autoreconf -O--buildsystem=R
> autoheader: warning: missing template: HAVE_OPENMP
> autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description])
> autoreconf: /usr/bin/autoheader failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> make: *** [debian/rules:4: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
>
>
> Any hint would be welcome

Similar to some of the problems with mpqc yesterday.  Patch attached.

J.
diff --git a/configure.ac b/configure.ac
index 0b7e8d793a31..aef047400685 100755
--- a/configure.ac
+++ b/configure.ac
@@ -39,6 +39,7 @@ Use --disable-parallel (or ARG=no) to keep the code sequential even if GCD or Op
 # As recommended by Simon Urbanek on R-Devel
 AC_DEFUN([AC_CHECK_PKG_OPENMP], 
   [dnl
+AH_TEMPLATE([HAVE_OPENMP],[])
 AC_MSG_CHECKING([whether OpenMP will work in a package])
 ac_pkg_openmp=no
 AS_IF(


signature.asc
Description: PGP signature

[covid-19] Help with r-bioc-rgadem needed

[Andreas Tille]

Hi,

since I did not got any response from r-pkg team yet I guess nobody has
a clue about this autoconf issue.  So I'd like to forward this question
here to finalise a package which is relevant for our COVID-19
Biohackathon.

I injected r-bioc-rgadem[1] but the build ends in:

   dh_autoreconf -O--buildsystem=R
autoheader: warning: missing template: HAVE_OPENMP
autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description])
autoreconf: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Any hint would be welcome

   Andreas.


[1] https://salsa.debian.org/r-pkg-team/r-bioc-rgadem

-- 
http://fam-tille.de

Re: C++ help needed for pbdagcon

[Matthew Fernandez]

> On Jan 22, 2020, at 11:56, Andreas Tille  wrote:
> 
> Control: tags -1 help
> 
> I have fixed Python2->Python3 migration as well as the FTBFS with
> pbseqlib 5.3.3+dfsg-1 issue in Git[1].  Unfortunately there is another
> build issue in the C++ code which I have no idea how to fix:
> 
> 
> ...
> g++ -g -O2 -fdebug-prefix-map=/build/pbdagcon-0.3+git20180411.c14c422+ds=. 
> -fstack-protector-strong -Wformat -Werror=format-security -O3 -std=c++14 
> -Wall -Wuninitialized -pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP 
> -I/build/pbdagcon-0.3+git20180411.c14c422+ds/DAZZ_DB 
> -I/build/pbdagcon-0.3+git20180411.c14c422+ds/DALIGNER 
> -I/usr/include/pbseq/alignment -I/usr/include/pbseq/pbdata 
> -I/usr/include/pbseq/hdf -I/usr/include/pbseq -isystem.//third-party   -c -o 
> DazAlnProvider.o DazAlnProvider.cpp
> In file included from DazAlnProvider.cpp:10:
> DazAlnProvider.hpp:97:19: error: expected ')' before '&' token
>   97 | Target(DAZZ_DB& db, int tspace, int small);
>  |   ~   ^
>  |   )
> DazAlnProvider.hpp:122:5: error: 'DAZZ_DB' does not name a type
>  122 | DAZZ_DB db_;
>  | ^~~
> DazAlnProvider.hpp:161:5: error: 'DAZZ_DB' does not name a type
>  161 | DAZZ_DB db_;
>  | ^~~
> DazAlnProvider.cpp: In constructor 'DazAlnProvider::DazAlnProvider(const 
> ProgramOpts&)':
> DazAlnProvider.cpp:34:33: error: 'db_' was not declared in this scope
>   34 | int status = Open_DB(path, _);
>  | ^~~
> DazAlnProvider.cpp: In destructor 'virtual DazAlnProvider::~DazAlnProvider()':
> DazAlnProvider.cpp:74:15: error: 'db_' was not declared in this scope
>   74 | Close_DB(_);
>  |   ^~~
> DazAlnProvider.cpp: In member function 'virtual bool 
> DazAlnProvider::nextTarget(std::string&, std::vector&)':
> DazAlnProvider.cpp:125:25: error: 'db_' was not declared in this scope
>  125 | seq = Load_Subread(_, trg_->id, 0, trg_->length, targSeqBuf_, 
> 0);
>  | ^~~
> DazAlnProvider.cpp: At global scope:
> DazAlnProvider.cpp:225:15: error: expected constructor, destructor, or type 
> conversion before '(' token
>  225 | Target::Target(DAZZ_DB& db, int tspace, int small) :
>  |   ^
> DazAlnProvider.cpp: In member function 'void Target::firstRecord(Record&, 
> bool)':
> DazAlnProvider.cpp:246:14: error: 'db_' was not declared in this scope
>  246 | length = db_.reads[id].rlen;
>  |  ^~~

Just taking some educated guesses here, but the way this variable is used 
indicates to me that the code expects it to be a HITS_DB, declared in 
DAZZ_DB/DB.h. The DAZZ_DB subdirectory looks like a copy of upstream project 
https://github.com/thegenemyers/DAZZ_DB 
. The latest revision of this calls 
this type DAZZ_DB, not HITS_DB. So maybe the solution is to pull in the latest 
revision of this?

C++ help needed for pbdagcon

[Andreas Tille]

Control: tags -1 help

I have fixed Python2->Python3 migration as well as the FTBFS with
pbseqlib 5.3.3+dfsg-1 issue in Git[1].  Unfortunately there is another
build issue in the C++ code which I have no idea how to fix:


...
g++ -g -O2 -fdebug-prefix-map=/build/pbdagcon-0.3+git20180411.c14c422+ds=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 -std=c++14 -Wall 
-Wuninitialized -pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MP 
-I/build/pbdagcon-0.3+git20180411.c14c422+ds/DAZZ_DB 
-I/build/pbdagcon-0.3+git20180411.c14c422+ds/DALIGNER 
-I/usr/include/pbseq/alignment -I/usr/include/pbseq/pbdata 
-I/usr/include/pbseq/hdf -I/usr/include/pbseq -isystem.//third-party   -c -o 
DazAlnProvider.o DazAlnProvider.cpp
In file included from DazAlnProvider.cpp:10:
DazAlnProvider.hpp:97:19: error: expected ')' before '&' token
   97 | Target(DAZZ_DB& db, int tspace, int small);
  |   ~   ^
  |   )
DazAlnProvider.hpp:122:5: error: 'DAZZ_DB' does not name a type
  122 | DAZZ_DB db_;
  | ^~~
DazAlnProvider.hpp:161:5: error: 'DAZZ_DB' does not name a type
  161 | DAZZ_DB db_;
  | ^~~
DazAlnProvider.cpp: In constructor 'DazAlnProvider::DazAlnProvider(const 
ProgramOpts&)':
DazAlnProvider.cpp:34:33: error: 'db_' was not declared in this scope
   34 | int status = Open_DB(path, _);
  | ^~~
DazAlnProvider.cpp: In destructor 'virtual DazAlnProvider::~DazAlnProvider()':
DazAlnProvider.cpp:74:15: error: 'db_' was not declared in this scope
   74 | Close_DB(_);
  |   ^~~
DazAlnProvider.cpp: In member function 'virtual bool 
DazAlnProvider::nextTarget(std::string&, std::vector&)':
DazAlnProvider.cpp:125:25: error: 'db_' was not declared in this scope
  125 | seq = Load_Subread(_, trg_->id, 0, trg_->length, targSeqBuf_, 0);
  | ^~~
DazAlnProvider.cpp: At global scope:
DazAlnProvider.cpp:225:15: error: expected constructor, destructor, or type 
conversion before '(' token
  225 | Target::Target(DAZZ_DB& db, int tspace, int small) :
  |   ^
DazAlnProvider.cpp: In member function 'void Target::firstRecord(Record&, 
bool)':
DazAlnProvider.cpp:246:14: error: 'db_' was not declared in this scope
  246 | length = db_.reads[id].rlen;
  |  ^~~


Any help would be welcome

   Andreas.

[1] https://salsa.debian.org/med-team/pbdagcon

-- 
http://fam-tille.de

Re: Help for linking library needed (Was: Bug#948926: blasr ftbfs with libpbbam1.0.6)

[Andrey Rahmatullin]

On Wed, Jan 15, 2020 at 05:50:03PM +0100, Andreas Tille wrote:
> Control: tags -1 help
> 
> On Tue, Jan 14, 2020 at 09:48:10PM +0100, Paul Gevers wrote:
> > Did not find CMake 'cmake'
> > Found CMake: NO
> > Run-time dependency pbbam found: NO
> > 
> > meson.build:54:0: ERROR: Could not generate cargs for pbbam:
> > Package pbcopper was not found in the pkg-config search path.
> > Perhaps you should add the directory containing `pbcopper.pc'
> > to the PKG_CONFIG_PATH environment variable
> > Package 'pbcopper', required by 'pbbam', not found
> 
> I've fixed this specific issue (and others) in Git[1] but I'm running
> into trouble I have no idea to fix.
> 
> 
> ...
> [22/25] c++  -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq 
> -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial 
> -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time - 
> D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 
> -std=c++14 -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl. a -pthread 
> -lblasr /usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata 
> -lpbihdf -Wl,--end-group '-Wl,-rpath,$ORIGIN/' 
> -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/
> FAILED: toAfg
> c++  -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq 
> -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial 
> -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time -D_FORTIFY_SOURCE=2 - 
> g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. -fstack-protector-strong 
> -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 -std=c++14 
> -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl.a -pthread -lblasr / 
> usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata -lpbihdf 
> -Wl,--end-group '-Wl,-rpath,$ORIGIN/' 
> -Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/
> /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol 
> '_ZN6PacBio3BAM9BamRecordD1Ev'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu//libpbbam.so.0.23.0: error adding 
> symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
It tells you to add libpbbam to the link command.

> In the pbuilder chroot I tried to simplify the linker call and
> reduced it to
> 
> root@sputnik:/build/blasr-5.3.3+dfsg/build# c++  -o toAfg 
> 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq 
> -L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial 
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -DHAVE_HDF5_1_10_1 -std=c++14 
> -lhdf5_cpp -lhdf5 ./libblasr_impl.a -pthread -lz -lpbdata -lpbihdf -lpbihdf 
> -lblasr
> /usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol 
> '_ZN6PacBio3BAM9BamRecordD1Ev'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0: error adding 
> symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
Indeed libpbbam is still missing here.

> I've checked that the symbol which is not found exists in the linked
> libraries:
It's not linked.
Also, using grep for this is very wrong, you need to use nm -D and check
it's defined there (it is though).


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help for linking library needed (Was: Bug#948926: blasr ftbfs with libpbbam1.0.6)

[Andreas Tille]

Control: tags -1 help

On Tue, Jan 14, 2020 at 09:48:10PM +0100, Paul Gevers wrote:
> Did not find CMake 'cmake'
> Found CMake: NO
> Run-time dependency pbbam found: NO
> 
> meson.build:54:0: ERROR: Could not generate cargs for pbbam:
> Package pbcopper was not found in the pkg-config search path.
> Perhaps you should add the directory containing `pbcopper.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'pbcopper', required by 'pbbam', not found

I've fixed this specific issue (and others) in Git[1] but I'm running
into trouble I have no idea to fix.


...
[22/25] c++  -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq 
-L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial 
-Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time - 
D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 
-std=c++14 -Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl. a -pthread 
-lblasr /usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata 
-lpbihdf -Wl,--end-group '-Wl,-rpath,$ORIGIN/' 
-Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/
FAILED: toAfg
c++  -o toAfg 'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq 
-L/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu/hdf5/serial 
-Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wdate-time -D_FORTIFY_SOURCE=2 - g 
-O2 -fdebug-prefix-map=/build/blasr-5.3.3+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -DHAVE_HDF5_1_10_1 -std=c++14 
-Wl,--start-group -lhdf5_cpp -lhdf5 libblasr_impl.a -pthread -lblasr / 
usr/lib/x86_64-linux-gnu/libz.so -lpbdata -lpbihdf -lblasr -lpbdata -lpbihdf 
-Wl,--end-group '-Wl,-rpath,$ORIGIN/' 
-Wl,-rpath-link,/build/blasr-5.3.3+dfsg/build/
/usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol 
'_ZN6PacBio3BAM9BamRecordD1Ev'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu//libpbbam.so.0.23.0: error adding 
symbols: DSO missing from command line
collect2: error: ld returned 1 exit status


In the pbuilder chroot I tried to simplify the linker call and
reduced it to

root@sputnik:/build/blasr-5.3.3+dfsg/build# c++  -o toAfg 
'toAfg@exe/utils_ToAfg.cpp.o' -I/usr/include/pbseq -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-DHAVE_HDF5_1_10_1 -std=c++14 -lhdf5_cpp -lhdf5 ./libblasr_impl.a -pthread -lz 
-lpbdata -lpbihdf -lpbihdf -lblasr
/usr/bin/ld: toAfg@exe/utils_ToAfg.cpp.o: undefined reference to symbol 
'_ZN6PacBio3BAM9BamRecordD1Ev'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0: error adding 
symbols: DSO missing from command line
collect2: error: ld returned 1 exit status


I've checked that the symbol which is not found exists in the linked
libraries:

root@sputnik:/build/blasr-5.3.3+dfsg/build# grep _ZN6PacBio3BAM9BamRecordD1Ev 
/usr/lib/x86_64-linux-gnu/*libpb*
Binary file /usr/lib/x86_64-linux-gnu/libpbbam.so matches
Binary file /usr/lib/x86_64-linux-gnu/libpbbam.so.0.23.0 matches
Binary file /usr/lib/x86_64-linux-gnu/libpbbam.so.1.0.6 matches
Binary file /usr/lib/x86_64-linux-gnu/libpbdata.a matches
Binary file /usr/lib/x86_64-linux-gnu/libpbdata.so matches


I wonder whether the issue might be connected to the fact that there is
only a shared lib but no libpbbam.a (the build system of libpbbam-dev
would need to be tweaked - but I'd assume a shared lib should be
sufficient for linking, right?)


Any hint to fix the build would be welcome.

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/blasr

-- 
http://fam-tille.de

Bug#948099: RFS Not Needed

[Tobias Frost]

Hallo Michael,

I have to chime in as I probably encouraged Phil for this RFS.

On Fri, 3 Jan 2020 22:26:35 -0600 Michael Lustfield <
mich...@lustfield.net> wrote:
> Thanks for your interest contributing to Debian.
> 
> Unfortunately, the packages you built are not DFSG-free and have
additional
> problems that would prevent them from being included in Debian. Check
out the
> lintian warnings, ideally with "lintian -EviIL +pedantic *.changes".

> typically does a good job predicting whether or not a package will
find a
> sponsor and/or pass NEW.

This is actually the reason why we have the sponsoring process to help
people understanding the processes and requirements of contributiong to
Debian. We do not expect, especially on new contributors that they know
everything from the first upload already. Frankly, imho, your language
is not well suited to encourage new contributors 

Looking at the packages, the lintian situation is not that bad, I have
seen worse even in the archives.

imho the correct procedure would have been to mark this bug "wontfix"
or "moreinfo" as per https://wiki.debian.org/Mentors/BTS. Closing it
seems a bit rough.

> Fortunately, these packages are already present in Debian and are
being
> actively maintained. If you would like to contribute, you should
reach out to
> the current maintainer to discuss collaborative maintenance.

The maintainer chimed in in #947270#30 saying that he would appreciate
help because of ETIME.

Depending on
> their time, they may be willing to review/sponsor your updates to the
> package.
> 
> https://tracker.debian.org/pkg/filezilla
> https://tracker.debian.org/pkg/libfilezilla
> https://tracker.debian.org/pkg/gnome-maps
(I did not find a RFS for the last one)

> 
> FWIW-
> I noticed that this is not the first time you've submitted this sort
of bug.
> 
> You should be aware that working *with* the current maintainer is the
ideal way
> to begin contributing to a maintained packages. An NMU (non-
maintainer upload)
> is one of those last resort options, typically reserved for
unreachable
> maintainers or urgent issues.

You saw that Phil was doing an Team Upload? Both packages are in the
debian namepsace on salsa, thus a team upload is completly in order.
[1]
(Of course it is always good to talk to each other.) 


[1] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

> When you don't work with the package maintainer and instead just try
to build
> updates and have others upload, it circumvents said maintainer. Ths
is why
> this particular type of behavior is often seen as an attempt at a
"hostile
> takeover" of the package.

Neither of the both packages has a change in maintainer ship recorded,
so there is no package hijacking. It is a team upload as documented in
the changelog.

Of course a question to ask in the RFS is, espescially if there are
bigger changes, are if the sponsoree have checked with the recorded
maintainer and in best case to establish a link between them. At least
this is what I would have done while marking the bug "moreinfo" 

> I'm sure that wasn't you're intention and suspect you're attempting
to follow
> a process for packages that are not yet in Debian. In most cases, if
you didn't
> file an ITP, you won't be filing an RFS.
>

-- 
tobi

Bug#932817: Pricing needed

[Jerry Wilson]

Good day,  Can you please provide me with quote for the below.
 7 HP 651A Magenta Original LaserJet Toner Cartridge, CE343A Original
Microsoft Surface Book 2 MFR #: HN6-1 x 9 
 Thank you
 Jerry Wilson
Director of Purchasing
Contemporary Plan
2741 W 21st St,
Erie, PA 16506
814 208 9313
www.contemporaryplan.com 

Re: Re: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)

[Alf Gaida]

Andreas, you didn't do anything wrong, reason:


On 16.09.19 19:38, Andrey Rahmatullin wrote:

> On Mon, Sep 16, 2019 at 05:38:47PM +0200, Andreas Tille wrote:
>> Determining dependency 'gtest_main' with pkg-config executable 
>> '/usr/bin/pkg-config'
>> PKG_CONFIG_PATH:
>> Called `/usr/bin/pkg-config --modversion gtest_main` -> 1
> There is no pkgconfig file for gtest_main in the archive.

googletest: /usr/src/googletest/googletest/cmake/gtest.pc.in

googletest: /usr/src/googletest/googletest/cmake/gtest_main.pc.in


Dunno if this is only wrong packaged or if there is a deeper sense
behind ...


Cheers Alf



second mail i bothered wrar with:


On 16.09.19 19:38, Andrey Rahmatullin wrote:

> There is no pkgconfig file for gtest_main in the archive.

And there is a reason for it:


short test:

mkdir googletest

cd googletest

apt source googletest

cd goog

nano debian/rules

override_dh_missing:

    dh_missing --fail-missing


Result:


make[1]: Verzeichnis
„/home/agaida/fucked/googletest/googletest-1.9.0.20190831“ wird verlassen
   dh_installdocs -O--buildsystem=cmake
   dh_installchangelogs -O--buildsystem=cmake
   dh_installman -O--buildsystem=cmake
   dh_installinit -O--buildsystem=cmake
   dh_perl -O--buildsystem=cmake
   dh_link -O--buildsystem=cmake
   dh_strip_nondeterminism -O--buildsystem=cmake
   dh_compress -O--buildsystem=cmake
   dh_fixperms -O--buildsystem=cmake
   debian/rules override_dh_missing
make[1]: Verzeichnis
„/home/agaida/fucked/googletest/googletest-1.9.0.20190831“ wird betreten
dh_missing --fail-missing
dh_missing: usr/lib/x86_64-linux-gnu/pkgconfig/gmock.pc exists in
debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/pkgconfig/gtest_main.pc exists in
debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/pkgconfig/gmock_main.pc exists in
debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/pkgconfig/gtest.pc exists in
debian/tmp but is not installed to anywhere
dh_missing:
usr/lib/x86_64-linux-gnu/cmake/GTest/GTestConfigVersion.cmake exists in
debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/cmake/GTest/GTestConfig.cmake
exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/cmake/GTest/GTestTargets-none.cmake
exists in debian/tmp but is not installed to anywhere
dh_missing: usr/lib/x86_64-linux-gnu/cmake/GTest/GTestTargets.cmake
exists in debian/tmp but is not installed to anywhere
dh_missing: missing files, aborting
    The following debhelper tools have reported what they installed
(with files per package)
 * dh_install: google-mock (0), googletest (3), googletest-tools
(2), libgmock-dev (3), libgtest-dev (3)
 * dh_installdocs: google-mock (0), googletest (1),
googletest-tools (0), libgmock-dev (0), libgtest-dev (0)
 * dh_installman: google-mock (0), googletest (0),
googletest-tools (1), libgmock-dev (0), libgtest-dev (0)
    If the missing files are installed by another tool, please file
a bug against it.
    When filing the report, if the tool is not part of debhelper
itself, please reference the
    "Logging helpers and dh_missing" section from the "PROGRAMMING"
guide for debhelper (10.6.3+).
  (in the debhelper package:
/usr/share/doc/debhelper/PROGRAMMING.gz)
    Be sure to test with dpkg-buildpackage -A/-B as the results may
vary when only a subset is built
    For a short-term work-around: Add the files to debian/not-installed
make[1]: *** [debian/rules:49: override_dh_missing] Fehler 255
make[1]: Verzeichnis
„/home/agaida/fucked/googletest/googletest-1.9.0.20190831“ wird verlassen
make: *** [debian/rules:23: binary] Fehler 2
dpkg-buildpackage: Fehler: Unterprozess fakeroot debian/rules binary
lieferte Exitstatus 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -ICVS -



And no, i don't want to write a grave bug now - but i'm a bit speachless
about the ignorance ...


Cheers Alf

Re: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)

[Andrey Rahmatullin]

On Mon, Sep 16, 2019 at 05:38:47PM +0200, Andreas Tille wrote:
> Determining dependency 'gtest_main' with pkg-config executable 
> '/usr/bin/pkg-config'
> PKG_CONFIG_PATH:
> Called `/usr/bin/pkg-config --modversion gtest_main` -> 1
There is no pkgconfig file for gtest_main in the archive.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)

[Andreas Tille]

Control: tags -1 pending

Hi,

I wanted to upgrade to the latest upstream version in Git[1] where
upstream has changed the build system.  Its a bit irritating to use
meson on top of cmake (at least I have never seen this before) and I
think I have added all needed Build-Depends (locally - not commited
yet):


diff --git a/debian/control b/debian/control
index b4d7424..c5a11fd 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,10 @@ Section: libs
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
dh-exec,
+   meson,
+   pkg-config,
+   cmake,
+   googletest,
zlib1g-dev,
libhdf5-dev,
libboost-dev,


Despite I have added googletest it seems not be found:


Library rt found: YES
Configuring LibBlasrConfig.h using configuration
Program tools/check-formatting found: YES 
(/build/pbseqlib-5.3.3+dfsg/tools/check-formatting)
Pkg-config binary for MachineChoice.HOST is cached.
Determining dependency 'gtest_main' with pkg-config executable 
'/usr/bin/pkg-config'
PKG_CONFIG_PATH:
Called `/usr/bin/pkg-config --modversion gtest_main` -> 1

CMake binary for MachineChoice.HOST is not cached
CMake binary missing from cross or native file, or env var undefined.
Trying a default CMake fallback at cmake
Trying CMake binary cmake for machine MachineChoice.HOST at ['/usr/bin/cmake']
Found CMake: /usr/bin/cmake (3.13.4)
Extracting basic cmake information
Try CMake generator: auto
Called `/usr/bin/cmake --trace-expand .` in 
/build/pbseqlib-5.3.3+dfsg/obj-x86_64-linux-gnu/meson-private/cmake_gtest_main 
-> 0
  -- Module search paths:['/', '/opt', '/usr', '/usr/local']
  -- CMake root: /usr/share/cmake-3.13
  -- CMake architectures:['x86_64-linux-gnu']
  -- CMake lib search paths: ['lib', 'lib32', 'lib64', 'libx32', 'share', 
'lib/x86_64-linux-gnu']
Run-time dependency gtest_main found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency gtest_main

unittest/meson.build:14:0: ERROR: Automatic wrap-based subproject downloading 
is disabled



I also tried adding libgtest-dev in addition but this does not change
the situation.

Any hint, what to do?

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/pbseqlib

-- 
http://fam-tille.de

Bug#932817: Quote needed

[Sanford Rockowitz]

It looks like you got our name from some IBM list.  I'm afraid we can't 
help you.  We're software developers and that is our connection to IBM.


Regards,
Sanford Rockowitz

On 09/09/2019 03:26 PM, Jerry Edwards wrote:


Good day,

Can you please assist me with quote for the below product.

Lenovo Yoga C930 14" Intel® Core™ i7-8550U (1.80GHz, up to 4.0GHz, Win 
10,16GB DDR4 2400MHz,1TB SSD,UHD Graphics 620.


Thank you for your assistance.

Jerry Edwards
JC Window Fashions
6400 Fleet Street
Commerce, CA 90040
f...@jcwindowfashions.com 
Ph 909 359 2526

Bug#932817: Quote needed

[Jerry Edwards]

Good day,
 Can you please assist me with quote for the below product.
 Lenovo Yoga C930 14" Intel� Core!22 i7-8550U (1.80GHz, up to 4.0GHz, Win 
10,16GB DDR4 2400MHz,1TB SSD,UHD Graphics 620.
 Thank you for your assistance.
 Jerry Edwards
JC Window Fashions
6400 Fleet Street
Commerce, CA 90040
f...@jcwindowfashions.com
Ph 909 359 2526

Re: cannot find library libgmsh.so.4.4 needed by ...

[Nico Schlömer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ah, I get it now! Because `${DEB_HOST_MULTIARCH}` is used in the
.install-files, they have to be treated with a special tool, dh-exec, that
takes the variables from debian/rules.
Thanks everyone!
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.9.1 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJdMY3tAAoJEJFPgzQ3IEx1btMP/1OV09y42MP+Hj95dwjI
0LZ/FQtCy6HaDi8a8lI91Q9YLPSD6lsladen9YrYb8d5STuZ8uThafIFcNSq
J2kTCXoh2m1FCXcVa2U5en5YxEXz7Nq4ANs+xabW+yGkNDt70pUd0ibBHmjE
hdpGd4XkrUzjPGhFcnDL0AB1CU1KHftRu3e+yIzHGZe3a9j/z8NJj6d475Ff
bQYhAOfY54xqAvYRNpdrDKILz3INBatpKnw5D7Wvy4hPwqMb0y25k/oFSoLB
SwYR1gJUGFYdjnUvEdH4O0IZgVSVVYNaltGm0VY9Exiy4M2uNnSaF3Ym30oW
5u81SJsSBiC1HgrBdl/0RvelJC7ztFbDtmRgozmdFSqQSDXooKDDXTyUQjd7
Zwj7H8BoORoV0pXVlEZpiJ1Af12QPogHUVcK0n24lSgkq295u02A9jdDL1mk
rryhjoj+LLrwn3aHlGtH998S6+ur6evIfZS7+pzlvf+EyYSFcouMSnLAPqEH
vzku/Zep2MTekEtt/0Kk8jvfO2Hlnbkt4m6Dhh5ax798hT5Q16jF1yXXR1WJ
aRQ3BSaS3mqfvBFURKM13WfR6MAiav0WuOq+/xu38FHZMftD4RV19pH20aQ5
cnOrqLjITou62yc4l3ijvawmKxMTYfD8ydYkGRhgDZ2CMt1RlYPexLuHlnCl
/JRm
=dN1d
-END PGP SIGNATURE-


0x914F833437204C75.asc
Description: application/pgp-keys

Re: cannot find library libgmsh.so.4.4 needed by ...

[Andrey Rahmatullin]

On Fri, Jul 19, 2019 at 03:53:55AM -0400, Nico Schlömer wrote:
> >> debian/rules has
> >> ```
> >> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
> >> ```
> >> so I thought (on respective machines), {DEB_HOST_MULTIARCH} equals
> >> x86_64-linux-gnu. Not the case?
> > No substitutions is done on debhelper config files, unless you use
> > dh-exec, and you disabled that.
> 
> Just for clarity: debian/rules is a "debhelper config file"?
No.

> How did I disable dh-exec? I is that because I unset the executable bit on
> the .install file?
Yes.

> (This looked like a mistake really
You've seen the shebangs in the files, so you could guess they should be
executable.

> and I haven't found documentation on that either.)
It's in debhelper(7), "Executable debhelper config files", and as the
files have dh-exec in the shebang, in dh-exec(1).

> I had always thought of debian/rules like a Makefile, and thought that when
> I put
> ```
> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
> ```
> there, all ${DEB_HOST_MULTIARCH} get replaced by the rhs expression.
But only in the makefile itself, not random text files read by various
programs executed by that makefile.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: cannot find library libgmsh.so.4.4 needed by ...

[Nico Schlömer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>> debian/rules has
>> ```
>> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
>> ```
>> so I thought (on respective machines), {DEB_HOST_MULTIARCH} equals
>> x86_64-linux-gnu. Not the case?
> No substitutions is done on debhelper config files, unless you use
> dh-exec, and you disabled that.

Just for clarity: debian/rules is a "debhelper config file"?
How did I disable dh-exec? I is that because I unset the executable bit on
the .install file? (This looked like a mistake really, and I haven't found
documentation on that either.)

I had always thought of debian/rules like a Makefile, and thought that when
I put
```
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
```
there, all ${DEB_HOST_MULTIARCH} get replaced by the rhs expression.

Cheers,
Nico
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.9.1 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJdMXcQAAoJEJFPgzQ3IEx1goMP/jJb2DobgNRf/aCmJk7W
sEDKx7CGvtjxyq6bOJwbg1kceK9FEMgHO/eOz1eHdZlVLHhL2eKSZQsqU0ka
YlE2RtNN5v40G/3wM+/nNK5M7AOviL9BWsawzDXtfT94NMoxajLKthTflS6S
vdDsfAZpcZJjQFUk2s3jzqmEfHvAOxC1YcJKVG1lqrxRJ9qVGg/8tpGNSMfg
zcYcO6/pxhYoEbUhrcb80Cagg4EufTS1l2iFafDNi01d4RwCzaUHmmL6yz6I
uMxXu4DhEYOC9HAbSRGuYs2j2cH+llm16zzF4d0NOxyge3aEHk5mFsorQjv2
LeZv1NUpQs3T/rkYfx9dFFYV8wS6EixaeHeoMDXDeNnxERTEQJ09wXEVEPhX
qsANJ1G4jh8cTc/CXcuiF1IJZlJc7Gp5R8SlvA7f5siOs9uqC6OPAQ1cYODb
HHT/EvtEIO2HwBFTBftPK2+zFK7Jmxk2f2epBQI+WshouoJQN2Ba7xG70qqZ
mTyKExfjf9ldn2sWfCb8fU4NjDCn1RDmfoFv+fmqAXBjL5NDiopGdS7T62CK
gtXRo7IBGoLBOnoRi7y+QGFwzR8zLKfriUOTJw+yT78i5Zr1jDGTzpQNfN+z
K0PMOrguyZLbcjWTe/r0y/Wnz9UwbHuvZTRWGfvQSXtsh+Iq6L1SBgaJry0J
ufqp
=AayP
-END PGP SIGNATURE-


0x914F833437204C75.asc
Description: application/pgp-keys

Re: cannot find library libgmsh.so.4.4 needed by ...

[Andrey Rahmatullin]

On Mon, Jul 15, 2019 at 05:12:37PM +0200, Nico Schlömer wrote:
> > As a result, the library gets installed to usr/lib/${DEB_HOST_MULTIARCH} 
> > rather than usr/lib/x86_64-linux-gnu
> 
> debian/rules has
> ```
> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
> ```
> so I thought (on respective machines), {DEB_HOST_MULTIARCH} equals
> x86_64-linux-gnu. Not the case?
No substitutions is done on debhelper config files, unless you use
dh-exec, and you disabled that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: cannot find library libgmsh.so.4.4 needed by ...

[Nico Schlömer]

> As a result, the library gets installed to usr/lib/${DEB_HOST_MULTIARCH} 
> rather than usr/lib/x86_64-linux-gnu

debian/rules has
```
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
```
so I thought (on respective machines), {DEB_HOST_MULTIARCH} equals
x86_64-linux-gnu. Not the case?

On Mon, Jul 15, 2019 at 3:22 PM Sven Joachim  wrote:
>
> On 2019-07-15 14:44 +0200, Nico Schlömer wrote:
>
> > Hi everyone,
> >
> > when upgrading gmsh to 4.4.0, I'm getting the build error
> > ```
> > [...]
> > dpkg-shlibdeps: error: cannot find library libgmsh.so.4.4 needed by
> > debian/gmsh/usr/bin/gmsh (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.
> > ```
> > see [1]. I'm not exactly sure why libgmsh.so.4.4 cannot be found; the
> > library is linked with
> > ```
> > -Wl,-soname,libgmsh.so.4.4 -o libgmsh.so.4.4.0
> > ```
> > Any hints?
>
> Probably that is a consequence of your commit a44d5ad253b8[1] which
> removed the executable bit from debian/*.install.  As a result, the
> library gets installed to usr/lib/${DEB_HOST_MULTIARCH} rather than
> usr/lib/x86_64-linux-gnu, and dpkg-shlibdeps will not look in such a
> strange place.
>
> Cheers,
>Sven
>
>
> 1. 
> https://salsa.debian.org/science-team/gmsh/commit/a44d5ad253b874869f643a02c7d3ca4f4b6c05c0

Re: cannot find library libgmsh.so.4.4 needed by ...

[Sven Joachim]

On 2019-07-15 14:44 +0200, Nico Schlömer wrote:

> Hi everyone,
>
> when upgrading gmsh to 4.4.0, I'm getting the build error
> ```
> [...]
> dpkg-shlibdeps: error: cannot find library libgmsh.so.4.4 needed by
> debian/gmsh/usr/bin/gmsh (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.
> ```
> see [1]. I'm not exactly sure why libgmsh.so.4.4 cannot be found; the
> library is linked with
> ```
> -Wl,-soname,libgmsh.so.4.4 -o libgmsh.so.4.4.0
> ```
> Any hints?

Probably that is a consequence of your commit a44d5ad253b8[1] which
removed the executable bit from debian/*.install.  As a result, the
library gets installed to usr/lib/${DEB_HOST_MULTIARCH} rather than
usr/lib/x86_64-linux-gnu, and dpkg-shlibdeps will not look in such a
strange place.

Cheers,
   Sven


1. 
https://salsa.debian.org/science-team/gmsh/commit/a44d5ad253b874869f643a02c7d3ca4f4b6c05c0

cannot find library libgmsh.so.4.4 needed by ...

[Nico Schlömer]

Hi everyone,

when upgrading gmsh to 4.4.0, I'm getting the build error
```
[...]
dpkg-shlibdeps: error: cannot find library libgmsh.so.4.4 needed by
debian/gmsh/usr/bin/gmsh (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.
```
see [1]. I'm not exactly sure why libgmsh.so.4.4 cannot be found; the
library is linked with
```
-Wl,-soname,libgmsh.so.4.4 -o libgmsh.so.4.4.0
```
Any hints?

Cheers,
Nico

[1] https://salsa.debian.org/science-team/gmsh/-/jobs/58

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Yavor Doganov]

On Wed, 09 Jan 2019 22:42:43 +0200,
Andreas Tille wrote:
> The values of the structure are set in line 350[3] and are OK there.

What looks suspicious to me is that an unsigned long long value is
assigned to struct members of type size_t.  In the previous upstream
release that worked, the return value of ffparse_ulong was used which
was unsigned long.

I doubt this is the culprit but may be something worth looking at.

> I admit I fail to see why the code works under stretch with gcc 6.3
> but fails with gcc 8.2.

If the code works with an old compiler but fails with a modern one, in
99.99% of the cases it's a bug in the code.  These bugs are revealed
due to new and more aggressive optimization techniques/algorithms that
assume undefined behavior.  IOW, the code was/is buggy by definition
but you got away with it somehow.  The remaining 0.01% is due to
compiler bugs but I bet that's not the case here.

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi Sune,

On Thu, Jan 10, 2019 at 06:27:47PM +, Sune Vuorela wrote:
> ...
> I looked briefly at the code, but I didn't feel like actually trying to
> understand what's going on.

Thanks a lot for this detailed analysis.  I'll forward it to bug #907624
and the upstream issue[1].  I admit I also will not try to understand
the code since I not even have an idea what the program is supposed to
do.

I think we have now provided sufficient input for upstream to track down
the issue.

Thanks again

   Andreas.

[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7

-- 
http://fam-tille.de

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Sune Vuorela]

On 2019-01-09, Andrey Rahmatullin  wrote:
> As usual: reading the code, debugging, printfs. Address sanitizer and/or
> valgrind may or may not help too.

I just tried throwing some tools at it.

Apparantly you need a three step thing to get to it.

address-sanitizer. First issue. The command to create the test data to
get the error.

$ ./ffindex_build -s ./test.data ./test.ffindex test/data test/data2

=
==824==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7f3393888ed0 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f33937994f1 in ffindex_index_parse 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:325
#2 0x56072c890783 in main 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_build.c:243
#3 0x7f33935f9b16 in __libc_start_main ../csu/libc-start.c:310

SUMMARY: AddressSanitizer: 304 byte(s) leaked in 1 allocation(s).


Oh well. rebuild without address sanitizer and run the first two steps.
Then rebuild with address sanitizer for the last step.

$ ./ffindex_modify -u ./test.ffindex b
AddressSanitizer:DEADLYSIGNAL
=
==1453==ERROR: AddressSanitizer: SEGV on unknown address 0x000ca3ff8001 (pc 
0x7f459600a9f7 bp 0x7ffd6674b8d0 sp 0x7ffd6674b8a0 T0)
==1453==The signal is caused by a READ memory access.
#0 0x7f459600a9f6 in action 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554
#1 0x7f45960076ed in trecursemisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:26
#2 0x7f459600775d in trecursemisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:31
#3 0x7f4596007827 in twalkmisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:44
#4 0x7f459600aac3 in ffindex_tree_write 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:563
#5 0x7f4596009f60 in ffindex_write 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:443
#6 0x55c8564c3fa8 in main 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_modify.c:182
#7 0x7f4595e69b16 in __libc_start_main ../csu/libc-start.c:310
#8 0x55c8564c3259 in _start 
(/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/build/src/ffindex_modify+0x2259)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554 
in action
==1453==ABORTING

I'm not sure that gives more new info.

Lets try valgrind.

$ valgrind ./ffindex_modify -u ./test.ffindex b
==32176== Memcheck, a memory error detector
==32176== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32176== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==32176== Command: ./ffindex_modify -u ./test.ffindex b
==32176== 
==32176== Invalid read of size 8
==32176==at 0x4846525: trecursemisc (twalkmisc.h:25)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  Address 0x4a536e1 is 17 bytes inside a block of size 24 alloc'd
==32176==at 0x483577F: malloc (vg_replace_malloc.c:299)
==32176==by 0x4986160: tsearch (tsearch.c:338)
==32176==by 0x4847C02: ffindex_index_as_tree (ffindex.c:533)
==32176==by 0x1094D7: main (ffindex_modify.c:122)
==32176== 
==32176== Invalid read of size 8
==32176==at 0x4847C6D: action (ffindex.c:554)
==32176==by 0x4846543: trecursemisc (twalkmisc.h:26)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  Address 0x4a53d is not stack'd, malloc'd or (recently) free'd
==32176== 
==32176== 
==32176== Process terminating with default action of signal 11 (SIGSEGV)
==32176==  Access not within mapped region at address 0x4A53D
==32176==at 0x4847C6D: action (ffindex.c:554)
==32176==by 0x4846543: trecursemisc (twalkmisc.h:26)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  If you believe this happened as a result of a stack
==32176==  overflow in your program's main thread (unlikely but
==32176==  possible), you can try to increase the 

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 10:49:48PM +0100, Andreas Tille wrote:
> > > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > > that the elements of a structure are not accessible:
> > > 
> > >(gdb) print entry->offset
> > >Cannot access memory at address 0x7
> > It's because entry is 0x7.
> 
> When I was running the code with some more debugging info activated[1]
> I had pretty valid looking adresses 0x555666 
And still SEGV?

> > > The values of the structure are set in line 350[3] and are OK there.
> > The problem is not about the structure fields but about the structure
> > pointer itself though.
> > ...
> > You need to find out why one of the tree nodes has an invalid address.
> 
> Can you propose any means to find this out?
As usual: reading the code, debugging, printfs. Address sanitizer and/or
valgrind may or may not help too.

> I have no idea about specific compiler differences.
I don't think pondering compiler differences can be helpful here, it's
most likely bad code that is working file with some compilers but is still
bad code.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi,

On Thu, Jan 10, 2019 at 02:14:14AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > that the elements of a structure are not accessible:
> > 
> >(gdb) print entry->offset
> >Cannot access memory at address 0x7
> It's because entry is 0x7.

When I was running the code with some more debugging info activated[1]
I had pretty valid looking adresses 0x555666 (or something in that line
just remembering by heart - can activate the patch if needed).  I have
no idea why the address is this without that extra debug code.
 
> > The values of the structure are set in line 350[3] and are OK there.
> The problem is not about the structure fields but about the structure
> pointer itself though.
> ...
> You need to find out why one of the tree nodes has an invalid address.

Can you propose any means to find this out?  I have no idea about
specific compiler differences.  BTW, I also tried to set -O0 but this
did not avoided the SIGSEGV.

Thanks for your hint anyway

  Andreas.

[1] 
https://salsa.debian.org/med-team/ffindex/blob/master/debian/patches/debug_segfault

-- 
http://fam-tille.de

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Ole Streicher]

Hi Andreas,

one thing I usually do in such cases is to rebuild the package adding
"-fsanitize=address -O0" flags (optimization just to understand better
what happens in the source). This switches the address sanitizer on
<https://github.com/google/sanitizers/wiki/AddressSanitizer>. This can
test if a local variable is accidently overwritten (by an off-by-one
error or similar). Often it finds many more bugs which one can turn
upstream into bonus points...

Otherwise I see no other chance than to go through the debugger and see
where the strange address was set. 0x7 however sounds that somewhere a
small integer was assigned to the pointer, so I would try the sanitizing
stuff first.

Cheers

Ole

Andreas Tille  writes:
> Hi,
>
> as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
> and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
> I've reported upstream[1] the results of my gdb session where I was able
> to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> that the elements of a structure are not accessible:
>
>(gdb) print entry->offset
>Cannot access memory at address 0x7
>
> (full gdb log under [1] or in the bug log).
>
> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like 
>
>if ( !entry->offset ) {
>
> in line 554 will trigger the SIGSEGV.  The values of the structure are
> set in line 350[3] and are OK there.  The funktion that contains the
> failing line is action() [4] and called via a pointer to this function
> in line 563[5] (I admit I have no real idea why this pointer to a
> function should be needed.  Its the only function that is used in this
> place and IMHO only adds an extra layer of complexity.)
>
> The structure is declared in the header file[6].
>
> I admit I fail to see why the code works under stretch with gcc 6.3
> but fails with gcc 8.2.
>
> Any idea?
>
> Kind regards
>
>Andreas.
>
>
> [1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
> [2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
> [3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
> [4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
> [5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
> [6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andrey Rahmatullin]

On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> that the elements of a structure are not accessible:
> 
>(gdb) print entry->offset
>Cannot access memory at address 0x7
It's because entry is 0x7.

> In fact I tried in some more detailed debugging that any attempt to
> access one of the structure elements even for instance only injecting
> something like 
> 
>if ( !entry->offset ) {
Of course this won't work, entry is 0x7.

> The values of the structure are set in line 350[3] and are OK there.
The problem is not about the structure fields but about the structure
pointer itself though.

> The funktion that contains the failing line is action() [4] and called
> via a pointer to this function in line 563[5] (I admit I have no real
> idea why this pointer to a function should be needed.  Its the only
> function that is used in this place and IMHO only adds an extra layer of
> complexity.)
No? line 563 calls twalkmisc() which walks the tree and calls action() for
each node. 

You need to find out why one of the tree nodes has an invalid address.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Andreas Tille]

Hi,

as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
I've reported upstream[1] the results of my gdb session where I was able
to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
that the elements of a structure are not accessible:

   (gdb) print entry->offset
   Cannot access memory at address 0x7

(full gdb log under [1] or in the bug log).

In fact I tried in some more detailed debugging that any attempt to
access one of the structure elements even for instance only injecting
something like 

   if ( !entry->offset ) {

in line 554 will trigger the SIGSEGV.  The values of the structure are
set in line 350[3] and are OK there.  The funktion that contains the
failing line is action() [4] and called via a pointer to this function
in line 563[5] (I admit I have no real idea why this pointer to a
function should be needed.  Its the only function that is used in this
place and IMHO only adds an extra layer of complexity.)

The structure is declared in the header file[6].

I admit I fail to see why the code works under stretch with gcc 6.3
but fails with gcc 8.2.

Any idea?

Kind regards

   Andreas.


[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
[2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
[3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
[4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
[5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
[6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

-- 
http://fam-tille.de

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Andreas Tille]

On Tue, Dec 04, 2018 at 12:04:36AM +0500, Andrey Rahmatullin wrote:
> On Mon, Dec 03, 2018 at 07:19:52PM +0100, Andreas Tille wrote:
> > I try to build the latest libsbml[1] in Git but I was running
> > into:
> Why do you think it's a problem? It's not.

Since cmake decided to mention it in build/CMakeFiles/CMakeError.log
and gave an explicit hint to read this file.

> Again, please learn how to read the program output including the build
> system output. Your build fails with the following error:
> 
> CMake Error at src/bindings/r/CMakeLists.txt:339 (get_target_property):
>   The LOCATION property may not be read from target "binding_r_lib".  Use the
>   target name directly with add_custom_command, or use the generator
>   expression $, as appropriate.

... while this was not mentioned in CMakeError.log.

Thanks for the helpful hint anyway

   Andreas.

-- 
http://fam-tille.de

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Nicolas Mora]

Hello,

Le 2018-12-03 14:25, Andreas Tille a écrit :

>
> find /usr/include -name ieeefp.h
> /usr/include/newlib/ieeefp.h
> /usr/include/newlib/machine/ieeefp.h

Use #include  or pass -Inewlib to the compiler (I 
don't

know whether that's a good idea).


How to pass -Inewlib option to the

   check_include_files (ieeefp.h HAVE_IEEEFP_H)

That's not a good idea to change the source code to silence an compiler 
error message.


As Andrey mentionned, you have the same error in the current sid 
package.
Probably a change in its dependencies broke the package, I'd start there 
to try to fix your problem.


I took a quick look at the package source on salsa and there are some 
references to matlab in the debian/rules file and the debian/cmake_opts 
file.


I don't see matlab in the debian packages, so maybe the answer is 
related to that. Maybe there was some matlab binary package before


spoiler alert: I manually patched the file debian/cmake_opts to remove 
all references to matlab ("$ sed '/MATLAB/d' debian/cmake_opts").
The dh_auto_configure step was succesful, and the build process started, 
although it doesn't mean that's the answer to your problem!

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Andreas Tille]

Hi Ferenc,

thanks a lot for your helpful hints which solved at least half of
my problem.

On Mon, Dec 03, 2018 at 07:46:30PM +0100, Ferenc Wágner wrote:
> Andreas Tille  writes:
> 
> > I explicitly added "Build-Depends: libnewlib-dev" und thus there is
> >
> > find /usr/include -name ieeefp.h
> > /usr/include/newlib/ieeefp.h
> > /usr/include/newlib/machine/ieeefp.h
> 
> Use #include  or pass -Inewlib to the compiler (I don't
> know whether that's a good idea).

How to pass -Inewlib option to the

   check_include_files (ieeefp.h HAVE_IEEEFP_H)

specifically in a way that it persists for resulting commands to finally
build the code?
 
> > I have no idea what check.h is seeked in src/CMakeLists.txt which has
> 
> Have you got the 'check' package installed?

I've added it to Build-Depends and that error vanished now.

Kind regards

   Andreas. 

-- 
http://fam-tille.de

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Andrey Rahmatullin]

On Tue, Dec 04, 2018 at 12:04:36AM +0500, Andrey Rahmatullin wrote:
> > I try to build the latest libsbml[1] in Git but I was running
> > into:
> Why do you think it's a problem? It's not.
It's even the same in the last successfully built package version in sid.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Ferenc Wágner]

Andreas Tille  writes:

> I explicitly added "Build-Depends: libnewlib-dev" und thus there is
>
> find /usr/include -name ieeefp.h
> /usr/include/newlib/ieeefp.h
> /usr/include/newlib/machine/ieeefp.h

Use #include  or pass -Inewlib to the compiler (I don't
know whether that's a good idea).

> I have no idea what check.h is seeked in src/CMakeLists.txt which has

Have you got the 'check' package installed?
-- 
Regards,
Feri

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Andrey Rahmatullin]

On Mon, Dec 03, 2018 at 07:19:52PM +0100, Andreas Tille wrote:
> I try to build the latest libsbml[1] in Git but I was running
> into:
Why do you think it's a problem? It's not.
Again, please learn how to read the program output including the build
system output. Your build fails with the following error:

CMake Error at src/bindings/r/CMakeLists.txt:339 (get_target_property):
  The LOCATION property may not be read from target "binding_r_lib".  Use the
  target name directly with add_custom_command, or use the generator
  expression $, as appropriate.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Cmake help needed: Fails to find check.h and ieeefp.h

[Birger Schacht]

hi,

On 12/3/18 7:19 PM, Andreas Tille wrote:
> Hi,
> 
> I try to build the latest libsbml[1] in Git but I was running
> into:
> 
> cat /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeError.log
> Determining if files check.h exist failed with the following output:
> Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp
> 
> Run Build Command:"/usr/bin/make" "cmTC_71faf/fast"
> make[2]: Entering directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> /usr/bin/make -f CMakeFiles/cmTC_71faf.dir/build.make 
> CMakeFiles/cmTC_71faf.dir/build
> make[3]: Entering directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> Building C object CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o
> /usr/bin/cc   -g -O2 -fdebug-prefix-map=/build/libsbml-5.17.0+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-strict-aliasing -fPIC-o CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o   
> -c 
> /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_CHECK_H.c
> /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_CHECK_H.c:2:10:
>  fatal error: check.h: No such file or directory
>  #include 
>   ^
> compilation terminated.
> make[3]: *** [CMakeFiles/cmTC_71faf.dir/build.make:66: 
> CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o] Error 1
> make[3]: Leaving directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> make[2]: *** [Makefile:121: cmTC_71faf/fast] Error 2
> make[2]: Leaving directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'

apt-file search /check.h gives me:
[...]
check: /usr/include/check.h
[...]

so maybe a build dependency on the package check helps?

> 
> Source:
> /* */
> #include 
> 
> 
> int main(void){return 0;}
> 
> Determining if files ieeefp.h exist failed with the following output:
> Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp
> 
> Run Build Command:"/usr/bin/make" "cmTC_8b304/fast"
> make[2]: Entering directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> /usr/bin/make -f CMakeFiles/cmTC_8b304.dir/build.make 
> CMakeFiles/cmTC_8b304.dir/build
> make[3]: Entering directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> Building C object CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o
> /usr/bin/cc   -g -O2 -fdebug-prefix-map=/build/libsbml-5.17.0+dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-strict-aliasing -fPIC-o CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o  
>  -c 
> /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_IEEEFP_H.c
> /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_IEEEFP_H.c:2:10:
>  fatal error: ieeefp.h: No such file or directory
>  #include 
>   ^~
> compilation terminated.
> make[3]: *** [CMakeFiles/cmTC_8b304.dir/build.make:66: 
> CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o] Error 1
> make[3]: Leaving directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> make[2]: *** [Makefile:121: cmTC_8b304/fast] Error 2
> make[2]: Leaving directory 
> '/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
> 
> Source:
> /* */
> #include 
> 
> 
> int main(void){return 0;}
> 
> 
> 
> I explicitly added "Build-Depends: libnewlib-dev" und thus there is
> 
> find /usr/include -name ieeefp.h
> /usr/include/newlib/ieeefp.h
> /usr/include/newlib/machine/ieeefp.h

if thats the ieeefp.h you need, maybe the include statement should say
#include 

cheers,
Birger

> 
> 
> I have no idea what check.h is seeked in src/CMakeLists.txt which has
> 
> # create libsbml-config-common.h
> #
> include(CheckIncludeFiles)
> check_include_files (check.h HAVE_CHECK_H)
> check_include_files (expat.h HAVE_EXPAT_H)
> check_include_files (errno.h HAVE_ERRNO_H)
> check_include_files (ieeefp.h HAVE_IEEEFP_H)
> 
> 
> but I know that the configure step worked in end of May when I did my
> last attempt to build that code.  Unfortunately there seems to be some
> issue with codesearch.d.n (I get "The results may be incomplete, not all
> Debian Code Search servers are okay right now." and no results) so I
> hope somebody can give a hint how to pass the configure step
> successfully.
> 
> Kind regards
> 
>Andreas.
> 
> 
> [1] https://salsa.debian.org/med-team/libsbml
> 

Cmake help needed: Fails to find check.h and ieeefp.h

[Andreas Tille]

Hi,

I try to build the latest libsbml[1] in Git but I was running
into:

cat /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeError.log
Determining if files check.h exist failed with the following output:
Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_71faf/fast"
make[2]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_71faf.dir/build.make 
CMakeFiles/cmTC_71faf.dir/build
make[3]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o
/usr/bin/cc   -g -O2 -fdebug-prefix-map=/build/libsbml-5.17.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-fPIC-o CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o   -c 
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_CHECK_H.c
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_CHECK_H.c:2:10:
 fatal error: check.h: No such file or directory
 #include 
  ^
compilation terminated.
make[3]: *** [CMakeFiles/cmTC_71faf.dir/build.make:66: 
CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o] Error 1
make[3]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_71faf/fast] Error 2
make[2]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'

Source:
/* */
#include 


int main(void){return 0;}

Determining if files ieeefp.h exist failed with the following output:
Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_8b304/fast"
make[2]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_8b304.dir/build.make 
CMakeFiles/cmTC_8b304.dir/build
make[3]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o
/usr/bin/cc   -g -O2 -fdebug-prefix-map=/build/libsbml-5.17.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-fPIC-o CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o   -c 
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_IEEEFP_H.c
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_IEEEFP_H.c:2:10:
 fatal error: ieeefp.h: No such file or directory
 #include 
  ^~
compilation terminated.
make[3]: *** [CMakeFiles/cmTC_8b304.dir/build.make:66: 
CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o] Error 1
make[3]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_8b304/fast] Error 2
make[2]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'

Source:
/* */
#include 


int main(void){return 0;}



I explicitly added "Build-Depends: libnewlib-dev" und thus there is

find /usr/include -name ieeefp.h
/usr/include/newlib/ieeefp.h
/usr/include/newlib/machine/ieeefp.h


I have no idea what check.h is seeked in src/CMakeLists.txt which has

# create libsbml-config-common.h
#
include(CheckIncludeFiles)
check_include_files (check.h HAVE_CHECK_H)
check_include_files (expat.h HAVE_EXPAT_H)
check_include_files (errno.h HAVE_ERRNO_H)
check_include_files (ieeefp.h HAVE_IEEEFP_H)


but I know that the configure step worked in end of May when I did my
last attempt to build that code.  Unfortunately there seems to be some
issue with codesearch.d.n (I get "The results may be incomplete, not all
Debian Code Search servers are okay right now." and no results) so I
hope somebody can give a hint how to pass the configure step
successfully.

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/libsbml

-- 
http://fam-tille.de

Re: How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed

[Sergio Durigan Junior]

On Monday, September 10 2018, Andreas Tille wrote:

> Hi Andrey,
>
> On Mon, Sep 10, 2018 at 07:40:45PM +0500, Andrey Rahmatullin wrote:
>> > is correct behaviour and return code is 0.  
>> You are not running this in a minimal chroot.
>> 
>> # pkg-config --cflags pbbam
>> Package zlib was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `zlib.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'zlib', required by 'htslib', not found
>> 
>> I've submitted #908501 against libhts-dev.
>
> Good catch.  Meanwhile I've added zlib1g-dev directly to Build-Depends
> of this package and it turned out that also libhdf5-dev is needed
> (including an according patch for meson.build.  Unfortunately there are
> remaining issues related to hdf5 lib:
>
> ...
> c++ -Iblasr@sha -I. -I.. -I../ -I/usr/include/hdf5/serial 
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++11 -g -O2 
> -fdebug-prefix-map=/build/libblasr-5.3.1=. -fstack-protecto
> In file included from ../hdf/HDFAtom.cpp:1:
> ../hdf/HDFAtom.hpp: In member function ‘int 
> HDFAtom::Initialize(H5::H5File&, const string&, const string&)’:
> ../hdf/HDFAtom.hpp:64:44: error: no matching function for call to 
> ‘HDFGroup::Initialize(H5::H5File&, const string&)’
>  group.Initialize(hdfFile, groupName);
> ^
> In file included from ../hdf/HDFData.hpp:10,
>  from ../hdf/HDFAtom.hpp:12,
>  from ../hdf/HDFAtom.cpp:1:
> ../hdf/HDFGroup.hpp:28:9: note: candidate: ‘int 
> HDFGroup::Initialize(H5::Group&, std::__cxx11::string)’
>  int Initialize(H5::Group& fg, std::string groupName);
>  ^~
> ../hdf/HDFGroup.hpp:28:9: note:   no known conversion for argument 1 from 
> ‘H5::H5File’ to ‘H5::Group&’
> ../hdf/HDFGroup.hpp:30:9: note: candidate: ‘int 
> HDFGroup::Initialize(HDFGroup&, std::__cxx11::string)’
>  int Initialize(HDFGroup& parentGroup, std::string groupName);
>  ^~
> ../hdf/HDFGroup.hpp:30:9: note:   no known conversion for argument 1 from 
> ‘H5::H5File’ to ‘HDFGroup&’
> ...
>
> Any idea how to fix this?

This can't work.  From the source code:

  class HDFGroup : public HDFAttributable
  {
  public:
  ...

  int Initialize(H5::Group& fg, std::string groupName);

  int Initialize(HDFGroup& parentGroup, std::string groupName);

  ...
  };

But:

  template 
  class HDFAtom : public HDFData
  {
  public:

  ...
  int Initialize(H5::H5File , const std::string ,
 const std::string )
  {
  HDFGroup group;
  group.Initialize(hdfFile, groupName);
  attribute = group.group.openAttribute(attributeName.c_str());
  isInitialized = true;
  return 1;
  }
  ...


The HDFAtom::Initialize above is calling "group.Initialize" passing an
"H5::H5File&" as the first parameter, but there's no
"H5Group::Initialize (H5::H5File&...)" method declared.  This is a bug.

The code is too cryptic for me understand what the correct solution is
in this case.  There are a few possibilities (creating a HDFFile first,
iterating over the available groups, etc.), but I'm not sure.

I'd report this upstream.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed

[Andreas Tille]

Hi Andrey,

On Mon, Sep 10, 2018 at 07:40:45PM +0500, Andrey Rahmatullin wrote:
> > is correct behaviour and return code is 0.  
> You are not running this in a minimal chroot.
> 
> # pkg-config --cflags pbbam
> Package zlib was not found in the pkg-config search path.
> Perhaps you should add the directory containing `zlib.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'zlib', required by 'htslib', not found
> 
> I've submitted #908501 against libhts-dev.

Good catch.  Meanwhile I've added zlib1g-dev directly to Build-Depends
of this package and it turned out that also libhdf5-dev is needed
(including an according patch for meson.build.  Unfortunately there are
remaining issues related to hdf5 lib:

...
c++ -Iblasr@sha -I. -I.. -I../ -I/usr/include/hdf5/serial 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++11 -g -O2 
-fdebug-prefix-map=/build/libblasr-5.3.1=. -fstack-protecto
In file included from ../hdf/HDFAtom.cpp:1:
../hdf/HDFAtom.hpp: In member function ‘int HDFAtom::Initialize(H5::H5File&, 
const string&, const string&)’:
../hdf/HDFAtom.hpp:64:44: error: no matching function for call to 
‘HDFGroup::Initialize(H5::H5File&, const string&)’
 group.Initialize(hdfFile, groupName);
^
In file included from ../hdf/HDFData.hpp:10,
 from ../hdf/HDFAtom.hpp:12,
 from ../hdf/HDFAtom.cpp:1:
../hdf/HDFGroup.hpp:28:9: note: candidate: ‘int 
HDFGroup::Initialize(H5::Group&, std::__cxx11::string)’
 int Initialize(H5::Group& fg, std::string groupName);
 ^~
../hdf/HDFGroup.hpp:28:9: note:   no known conversion for argument 1 from 
‘H5::H5File’ to ‘H5::Group&’
../hdf/HDFGroup.hpp:30:9: note: candidate: ‘int HDFGroup::Initialize(HDFGroup&, 
std::__cxx11::string)’
 int Initialize(HDFGroup& parentGroup, std::string groupName);
 ^~
../hdf/HDFGroup.hpp:30:9: note:   no known conversion for argument 1 from 
‘H5::H5File’ to ‘HDFGroup&’
...

Any idea how to fix this?

Kind regards

Andreas.



-- 
http://fam-tille.de

Re: How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed

[Andrey Rahmatullin]

On Mon, Sep 10, 2018 at 04:14:23PM +0200, Andreas Tille wrote:
> returns nothing which makes sense.  This is for instance the case for
> /usr/lib/*/pkgconfig/pbbam.pc of libpbbam-dev and I think that
> 
> $ pkg-config --cflags pbbam
> 
> $ echo $?
> 0
> 
> is correct behaviour and return code is 0.  
You are not running this in a minimal chroot.

# pkg-config --cflags pbbam
Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'htslib', not found

I've submitted #908501 against libhts-dev.

-- 
WBR, wRAR


signature.asc
Description: PGP signature