On 4 Oct 2022, at 15:31, Nilesh Patra wrote:
> The thing that was causing failures on !amd64 was that there were amd64
> specific symbols in debian/libhtscodecs2.symbols that were not matching on
> those archs due to avx2/avx512 specific ABI being exported there.
So something specific to the De
On 1 Oct 2022, at 07:21, Nilesh Patra wrote:
> I have fixed a bunch of things with htscodecs and htslib, both
> of which were not building on !amd64. Hopefully it is
> fine now.
If htscodecs or htslib is failing to build on !amd64 due to a problem outside
your Debian-specific build scripts, you
Andreas Tille wrote:
> Interestingly the missing symbols are mentioned in some warnings higher up in
> the changelog!
As per the build log, those warnings were:
Selecting previously unselected package libhtscodecs2:amd64.
Preparing to unpack .../44-libhtscodecs2_1.2.2-1_amd64.deb ...
Unpacking l
Steffen Möller wrote:
> htscodecs is now distributed next to samtools
[...]
>
> I needed this update to compile 1.12 of htslib. which again is required
> to compile bcftools 1.12.
If you are making htslib depend on your libhtscodecs package then you need to
configure htslib to use it via --with-
Andreas Tille wrote:
> Sounds good. I think we should prefer this once the new version is available.
FYI bedtools 2.30.0 was released over the weekend.
John
Andreas Tille wrote:
> I do not fully understand why the htsutil binary should not stay in the
> bedtools package
If I were a Debian user who had installed the bedtools package, I would be
confused by that package creating a /usr/lib/bedtools directory -- because
bedtools does not have plugins o
Étienne Mollier wrote:
> Technically speaking, the existing bedtools-test package moving
> to Arch: any will need one instance per architecture, so growing
> the size of the archive.
That is true, and the test data is unfortunately quite large. One could put the
htsutil executable (and perhaps th
Étienne Mollier wrote:
> I noticed current bedtools 2.29.2+dfsg-5 fails to migrate to
> testing, so I pushed a fix[1].
The problem being that the bedtools-test package's symlink to the htsutil
executable located in the bedtools package is not adequately copied when the
test files are copied to /
On 4 Dec 2020, at 16:08, Samuel Thibault wrote:
> In catch.hpp it is used for the MacOS case, to access the mib, which is
> completely normal. But I don't see why ./source/uchime_src/myutils.cpp
> and ./source/mothur.h would need to include it, they are not using the
> sysctl function.
The myutil
> I intended to upgrade the packaging for pftools[1] in Git but was running into
> ...
> /src/C/../../src/C/include/profile.h:70: multiple definition of
> `VectorPosition';
> pfsearchV3-pfsearch.o:./src/C/../../src/C/include/profile.h:70: first defined
> here
The code has mistakenly applied the
> I updated bcftools in Git but when trying to build I get
> vcfmerge.c:3213:36: error: 'BCF_SR_ALLOW_NO_IDX' undeclared (first use in
> this function)
It is almost always the case that samtools 1.N and bcftools 1.N both require
htslib 1.N.
In this case, bcftools 1.11 uses htslib-1.11 facilitie
Étienne Mollier wrote:
> I had a look at the autopkgtest failure affecting biobambam2,
> and since these segmentation faults were showing up only in my
> autopkgtest environment, and not when using the package directly
> on my system, it felt like a missing dependency. So I trapped
> system calls
es the "static" from cram_to_bam and adds its declaration
to a header file.
if you think that's helpful and upstream has no problems with this
I'm fine with that patch. I've kept John Marshall who once helped
to have a clean htslib - comments are welcome.
As you have a
On 13 Dec 2017, at 10:47, Mattia Rizzolo wrote:
> These three symbols are from fuctions that are clearly aimed at debug.
> The functions do dumb fprintf() of some data structures to stderr,
> clearly something that nobody would ever use in a production system.
> The fuctions themselves are still t
14 matches
Mail list logo
