Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd

Hi Samuel, I forwarded the bug to the GCC tracker and they said that your interpretation of the docs is correct. I doubt whether they are willing to change the behaviour, but we'll see. Best, Fabian

Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd

forwarded 945133 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419

Bug#944299: ITP: phylonium -- Fast and Accurate Estimation of Evolutionary Distances

Best Fabian https://salsa.debian.org/med-team/phylonium On 07.11.19 13:34, Fabian Kloetzl wrote: Package: wnpp Severity: wishlist Owner: Fabian Klötzl * Package name: phylonium Version : 1.1 Upstream Author : Fabian Klötzl * URL : https://github.com/evolbioinf

Bug#936088: [Debian-med-packaging] Bug#936088: marked as done (libmurmurhash autopkg tests fail)

I saw that there was something wrong with the CI of libmurmurhash but didn't have the time to look into it, yet. Thanks to Matthias for the patch and to Andreas for releasing a new version so quickly. Best, Fabian

Bug#922010: RFS: libmurmurhash 1.3

On 11.02.19 22:24, Andreas Tille wrote: I had a look on the build logs[1] and at least mips and s390x keep on failing (some archs are not yet build). Sorry for keeping you busy with this That's fine, because it is entirely my fault; Wouldn't have happened if I had merged your automake

Bug#922010: RFS: libmurmurhash 1.3

Hi Andreas, On 11.02.19 15:41, Andreas Tille wrote: Furthermore, I added some man page links. I also wanted to remove some private functions from the .symbols file. However, that resulted in a lintian error. Could you be more verbose about what you did and what lintian error was issued?

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

Hi Andreas, On 07.02.19 14:58, Andreas Tille wrote: There are also build issues of libmurmurhash on some architectures[2] Any idea what to do next? [2] https://buildd.debian.org/status/package.php?p=libmurmurhash=sid I hope to have fixed the build issues upstream. Have pushed a new—and

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

Hi, On 07.02.19 16:00, Andreas Tille wrote: > I've obviously missed that part of your mail. It is fixed now and I'll > re-upload. No worries. The alternative would have been to create a separate set of unit tests for the 32bit architectures. > > Meanwhile I've fixed the symbols file in Git.

Bug#919778: Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

On 07.02.19 14:58, Andreas Tille wrote: Unfortunately the -DARCH32 flag (which is set according to the build log[1]) does not help on i386 architecture: ./mash info -d test/reads.msh > test/reads.json diff test/genomes.json test/ref/genomes.json 7c7 < "hashType" : "MurmurHash3_x86_32",

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

Hi Andreas, On 07.02.19 08:10, Andreas Tille wrote: Unfortunately it does not pass its build time tests any more now that I rebuild it for uploading. I had a look and could trace the failure to two issues. 1) The test should run sequentially; can be fixed via a simple override. 2) The

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

Hi Andreas, So I improved the upstream libmurmurhash, adapted the package and filed an ITP (#921353). I even managed to locally build mash against the new package. So hereby I kindly ask you to fix the last lintian issue about NMU which I don't fully understand and then maybe sponsor an

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

As promised, I pushed my packaging attempt. However, I didn't manage to create a repository under med-team, thus it is under my account [1]. Best Fabian 1: https://salsa.debian.org/kloetzl-guest/libmurmurhash

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

Hi Andreas, I started a new project `libmurmurhash` which should fix the problem of code duplication [1]. However, I could not yet check whether my code produces the correct result on big endian systems without crashing. On x64 it works fine and I also produced a working package locally. I could

Bug#918566: Lost of code copies of MurmurHash3 (Was: Bug#918566: mash FTBFS on big endian: test failures)

Hi, There are 162 packages in Debian containing the string MurmurHash. Some of them use an implementation called PMurHash which fixes the endianess issue. On 07.01.19 16:42, Andreas Tille wrote: > It seems to be time to package MurmurHash3 separately, isn't it? Yeah, I think it makes sense to

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

forwarded 918566 https://github.com/marbl/Mash/issues/106 thanks

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

mash internally uses MurmurHash 3 which is sensitive to the endianess. There is a note in the source [1], but no preventive measures are taken. I will forward this upstream and might even have a go at this myself. (In theory this should not be a big issue expect for slightly

Bug#912235: Bug#912235: figtree FTBFS with OpenJDK 11

forwarded 912235 https://github.com/rambaut/figtree/issues/128 I agree, using Java 8 is the easy solution, not the nice one. Even with the hot-of-the-press version 1.4.4 the problem exists, so I opened an issue upstream [1]. I will continue looking into this even if Java is not my strength.

Bug#912235: [Debian-med-packaging] Bug#912235: figtree FTBFS with OpenJDK 11

Thank you for reporting. I added a fix to the repo. Will get resolved with the next upload. Best Fabian

Bug#908459: theseus FTBFS with gcc 8

On 11.09.2018 15:58, Adrian Bunk wrote: Control: reopen -1 Some builds were still running into #897876 due to the buildd chroots only regenerated twice per week (which is not something you should be worried about), but the armhf/i386 and ppc64el FTBFS look more like actual problems that need

Bug#908459: theseus FTBFS with gcc 8

Hi Andreas, On 10.09.18 13:59, Andreas Tille wrote: > /usr/bin/gcc -O3 -ffast-math -fstrict-aliasing -funroll-loops > -fomit-frame-pointer -Wall -Werror -pedantic -std=c99 -Wno-unused-result > -Wformat-truncation=0 -pthread -c logistic_dist.c > logistic_dist.c: In function 'evallogisticML': >

Bug#908459: [Debian-med-packaging] Bug#908459: theseus FTBFS with gcc 8

Thanks for reporting. There were plenty of string related errors. Fixed in git repo.

Bug#908039: figtree: Crashes with NoClassDefFoundError

On 05.09.2018 16:13, Andreas Tille wrote: I commited the same change that helped for cgview. Not tested yet but setting tag pending to prevent others from spending time with this most probably solved problem. Tested and it works. Thank you very much. So apparently supplying a classpath

Bug#908039: figtree: Crashes with NoClassDefFoundError

On 05.09.2018 14:46, Andreas Tille wrote: Probably same as #907559. Yeah, that looks related. Would you mind adding batik-constants.jar to CLASSPATH and try again? As far as I understand java, I already tried that. One can give additional paths to the java executable via the -cp

Bug#887632: [Debian-med-packaging] Bug#887632: progressivemauve FTBFS with glibc 2.26

Hi all, This bug is easily fixed by forcing mauve to use the native getopt. A half-hearted fix is pushed. However, I have trouble removing the unnecessary files from the orig tarball, because the pristine-tar branch contains only a .delta and a .id file? Any help would be appreciated. Best

Bug#859202: warning: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

Tags: patch Hi, Since version 3.6.2, there is a proper check for the availability of readdir_r. So we could leave things as they are and wait for libc to remove readdir_r at which point the warnings will also vanish. Or we could force dcmtk to no longer use readdir_r by disabling the check. I

Bug#780816: December: tophat

Hi Andreas, On 04.12.2017 17:33, Andreas Tille wrote: > On Mon, Dec 04, 2017 at 02:09:48PM +0100, Fabian Klötzl wrote: >> I just pushed some changes to build tophat with our version of libbam. >> Not sure if the previously mentioned issue in [1] is fixed; can't test, > > Tha

Bug#780816: [Debian-med-packaging] Bug#780816: December: tophat

On 04.12.2017 17:33, Andreas Tille wrote: > Thanks to the test suite we now know that the issue is not solved yet: > > $ sh run-unit-test > > [2017-12-04 17:28:54] Beginning TopHat run (v2.1.1) > --- > [2017-12-04 17:28:54] Checking for Bowtie >

Bug#780816: December: tophat

Hi all, I just pushed some changes to build tophat with our version of libbam. Not sure if the previously mentioned issue in [1] is fixed; can't test, because my cowbuild just broke. :( Best, Fabian [1]: https://lists.debian.org/debian-med/2014/10/msg4.html

Bug#752860: bug 752860 is forwarded to https://github.com/Teuniz/EDFbrowser/issues/38

forwarded 752860 https://github.com/Teuniz/EDFbrowser/issues/38 thanks

Bug#866646: Any idea how to fix freebayes? [Was: Bug#866646: freebayes FTBFS with libhts-dev 1.4.1-2]

Hi Andreas, On 02.09.2017 14:54, Andreas Tille wrote: > The htslib issue remains the same but I have no idea how to fix it. The problem is that Allele.h defines a friend function called `json` residing in global namespace. However, hts.h already defined a value of an enum with the same name,

Bug#807486: ITP: INDELible -- A powerful and flexible simulator of biological evolution

Package: wnpp Severity: wishlist Owner: "Debian Med Team" * Package name: INDELible Version : 1.03 Upstream Author : William Fletcher * URL : http://abacus.gene.ucl.ac.uk/software/indelible/ * License : GPL Programming Lang: C++

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

Package: wnpp Severity: wishlist Owner: "Fabian Klötzl" <kloe...@evolbio.mpg.de> * Package name: andi Version : 0.9.4 Upstream Author : Fabian Klötzl <kloe...@evolbio.mpg.de> * URL : https://github.com/EvolBioInf/andi * License : GPL

Bug#800932: ITP: andi -- Efficient Estimation of Evolutionary Distances

On 05.10.2015 10:55, Andreas Tille wrote: > I guess for non-German speakers andy might be a random 4 letter > combination and nobody will confuse it with the tyical nickname of > a German Andreas. :-) Great, I'll stick with "andi" then and continue packaging. Thanks for the quick advice Fabian

Bug#794729: [u...@debian.org: Bug#794729: libdivsufsort-dev: missing dependency on libdivsufsort3]

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 06.08.2015 08:32, Andreas Tille wrote: Hi Fabian, I hope you read the mailing list debian-med-packag...@lists.alioth.debian.org or at least have subscribed this package in the Debian Package Tracker. If not please do either of one to