Bug#793514: Fwd: Staden authoren ??? [Re: Bug#793514: FTBFS: conflicting types for append_int]

, Andrew On 07/08/15 15:26, Sascha Steinbiss wrote: Dear James and Andrew, I am writing to kindly bring the following Staden build issue to your attention. The Debian automated build system is currently unable to build the code from source due to multiple declarations of identically named

Bug#793514: Fwd: Staden authoren ??? [Re: Bug#793514: FTBFS: conflicting types for append_int]

Dear James and Andrew, I am writing to kindly bring the following Staden build issue to your attention. The Debian automated build system is currently unable to build the code from source due to multiple declarations of identically named functions with different parameter and return types. We

Bug#793514: Fwd: Staden authoren ??? [Re: Bug#793514: FTBFS: conflicting types for append_int]

releasing a compatible version of the Staden Package. The code is ready, it just needs releasing. I'll see what I can do. Thanks, Andrew On 07/08/15 16:35, Sascha Steinbiss wrote: Hi Andrew, many thanks for your quick reply and for your willingness to look into the issue. Best

Bug#798900: [Debian-med-packaging] Bug#798900: lintian: false positive: source-is-missing for non-minified JS files

: > On Sun, 2015-10-11 at 13:38 +0100, Sascha Steinbiss wrote: > >> It looks like JSHint is not a hard requirement but will just not be used if >> it’s >> not there: >> https://github.com/DataTables/DataTablesSrc/blob/master/build/make.sh#L58 >> Otherwise I wou

Bug#798900: [Debian-med-packaging] Bug#798900: lintian: false positive: source-is-missing for non-minified JS files

Hi all, >>> Looks like the JQuery DataTables libraries included are flagged as minified >>> without source on the basis that they have lines longer than 1024 >>> characters: >>> P: aegean source: source-contains-prebuilt-javascript-object >>> data/share/vendor/jquery.dataTables.js line length

Bug#798900: lintian: false positive: source-is-missing for non-minified JS files

Hi Paul, >> Looks like the JQuery DataTables libraries included are flagged as minified >> without source on the basis that they have lines longer than 1024 characters: >> P: aegean source: source-contains-prebuilt-javascript-object >> data/share/vendor/jquery.dataTables.js line length is 1397

Bug#798900: [Debian-med-packaging] Bug#798900: lintian: false positive: source-is-missing for non-minified JS files

Hi, >> For the time being, would it be enough to add the DataTablesSrc repo >> content (and a README) to aegean’s debian/missing-sources to comply >> with DFSG until a DataTables package gets into the archive? > > Better than nothing but I think it still violates ftpmaster policy > since it

Bug#808552: dh-dist-zilla: builds fail in recent pbuilder versions

Hi Axel, […] >> I have been able to fix the issue locally by setting >> BUILD_HOME="/tmp" in my .pbuilderrc, and afterwards everything >> builds fine for me. However, obviously that wouldn't help on build >> machines where I don't have control over that (autobuilders, ...). > > Exactly. > >> Is

Bug#827805: [Pkg-privacy-maintainers] Bug#827805: onioncircuits: FTBFS: E: Please add apropriate interpreter package to Build-Depends, see pybuild(1) for details at /usr/share/perl5/Debian/Debhelper/B

ACHE=/home/lamby/.cache/pip > HOME=/home/lamby > LOGNAME=lamby > SHLVL=1 > > PWD=/home/lamby/temp/cdt.20160621104415.5SuLtY7TVL.onioncircuits/onioncircuits-0.4 > OLDPWD=/home/lamby/temp/cdt.20160621104415.5SuLtY7TVL.onioncircuits > GPG_TTY=/dev/console > QUILT_PATCH

Bug#813465: [Debian-med-packaging] Bug#813465: bcftools: FTBFS: vcfmerge.c:424:6: error: conflicting types for 'bcf_hdr_merge'

This is most likely related to the htslib 1.3 upgrade. I expect that updating bcftools to the most recent upstream release (1.3) as well will help. On 02/02/2016 09:49, Chris Lamb wrote: > Source: bcftools > Version: 1.2-2 > Severity: serious > Justification: fails to build from source > User:

Bug#818725: picard-tools: FTBFS in unstable

Is this bug still an issue? Picard-tools has been recently updated to a newer upstream version which builds fine for me in a current sid pbuilder chroot. I'm asking because the autoremoval of picard-tools due to this bug would also drag Artemis with it... Cheers Sascha On Sat, 19 Mar 2016

Bug#818397: salmon: FTBFS: 'MEM_F_SELF_OVLP' was not declared in this scope

Hi, I have pushed a fix for this to git. I would be glad if someone could take a look. Thanks Sascha On Wed, 16 Mar 2016 13:36:46 -0700 Martin Michlmayr wrote: > Package: salmon > Version: 0.4.2+ds1-2 > Severity: serious > > This package fails to build in unstable: > > >

Bug#798789: netperf: fix for FTBFS

+ +++ netperf-2.6.0/debian/changelog 2016-04-05 10:02:33.0 + @@ -1,3 +1,10 @@ +netperf (2.6.0-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Adjust inline statements to fix FTBFS (Closes: #798789) + + -- Sascha Steinbiss <sas...@steinbiss.name> Tue, 05 Ap

Bug#803550: [Debian-med-packaging] Bug#803550: rsem: uninstallable on architectures without bowtie

Hi all, I re-introduced the build dependency on bowtie and also did some minor housekeeping. Committed the fix in git. Cheers Sascha > On 19 Mar 2016, at 14:34, Andreas Beckmann wrote: > > Package: rsem > Followup-For: Bug #803550 > > Hi, > > the > B-D: bowtie | bowtie2 >

Bug#832839: [Debian-med-packaging] Bug#832839: artemis: FTBFS: dpkg-gencontrol: error: error occurred while parsing Depends field:

Hi, > During a rebuild of all packages in sid, your package failed to build on > amd64. [...] >>dh_gencontrol >> dpkg-gencontrol: warning: can't parse dependency $ >> dpkg-gencontrol: error: error occurred while parsing Depends field: >> , >> default-jre | java5-runtime | java6-runtime |

Bug#832839: Bug#832839: artemis: FTBFS: dpkg-gencontrol: error: error occurred while parsing Depends field:

On 29/07/2016 12:49, Andreas Tille wrote: > On Fri, Jul 29, 2016 at 10:19:29AM +0100, Sascha Steinbiss wrote: >>>> dpkg-gencontrol: error: error occurred while parsing Depends field: >>>> , >>>> default-jre | java5-runtime | java6-runtime | java7-runtime |

Bug#853931: FTBFS: dh_install: debian/suricata-hyperscan.install returned exit code 127

Hi Arturo and James, >> I believe you need both debhelper and dh-exec from jessie-backports to >> make this work. > > Thanks James, it works!! :-) Thanks! I just tried the same and can confirm it works now. Cheers Sascha signature.asc Description: OpenPGP digital signature

Bug#852850: [Debian-med-packaging] Bug#852850: hilive: FTBFS (dh_auto_configure fails)

Hi Andreas, > ... > CMake Error at CMakeLists.txt:37 (find_package): > By not providing "FindSeqAn.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "SeqAn", but > CMake did not find one. > > Could not find a package configuration

Bug#852546: [Debian-med-packaging] Bug#852546: bowtie2 build-depends on non-free libmath-random-perl

Hi Adrian, [...] > bowtie2 (2.3.0-1) unstable; urgency=medium > ... > [ Andreas Tille ] > ... > * Remove code from test suite that is requiring non-free package > libmath-random-perl > ... > [ Sascha Steinbiss ] > * Even more new Build-Depends: libmath-ran

Bug#855932: sugar-physics-activity: FTBFS: unsatisfiable build-dependencies: python-sugar-0.88, python-sugar-toolkit-0.88

Hi, > During a rebuild of all packages in stretch (in a stretch chroot, not a > sid chroot), your package failed to build on amd64. […] > > The following packages have unmet dependencies: > > sbuild-build-depends-sugar-physics-activity-dummy : Depends: > > python-sugar-0.88 but it is not

Bug#750895: python3-tempita: doesn't work with python 3.3

Hi all, > 2. This issue is already fixed in the upstream in this commit: > > https://github.com/gjhiggins/tempita/commit/ce87d4c0f057880c5b0dc77e83e3eecad7f355a7 > (The previous commit of this, 75064399e7e72fd67e2a0c21c675d6289e7d1ec9, > suffers from the same error.) Here’s a small patch

Bug#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.

tags 852929 patch user debian-rele...@lists.debian.org usertags 852929 + bsp-2017-02-de-Berlin thanks Hi all, […] > touch latex_mtx > tex --ini '\input hugelatex.ini \dump' > This is TeX, Version 3.14159265 (TeX Live 2016/Debian) (INITEX) > (./hugelatex.ini >

Bug#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.

Hi Anton, >> Switching to ‘luatex' instead of ‘tex’ fixed the issue for me. Please >> see attached patch. However, I would be happy if someone could take a >> second look. I don’t usually write Cyrillic ;) > > Thanks. I am uploading the package now. :) Great, thanks! One more RC bug down.

Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)

Hi Santiago, thanks for reporting this. > I tried to build this package in stretch with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: […] > a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam > navig.graphics 0

Bug#835720: [Debian-med-packaging] Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi again, >> It would be great if somebody could fix the build to bring this forward >> since I personally do not have any interest in salmon (yet). > > I’ll look at it. There will be some patching necessary to bring the spdlog > API use in RepMap up to speed with the current spdlog version in

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi, > On Tue, Aug 30, 2016 at 12:16:26PM +0200, Andreas Tille wrote: >> I tried to upgrade salmon to latest upstream where this problem might >> have possibly solved. I'm currently struck by the fact that >> >>https://github.com/COMBINE-lab/RapMap >> >> is needed to build. > > I have

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi Andreas, > Back to the salmon issue: When using the just uploaded rapmap and > trying to prevent salmon's cmake from downloading it in a patch I'm now > facing the next configure issue which seems that BOOST_INCLUDEDIR and > BOOST_LIBRARYDIR are not found. Any clue how to get the latest

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi Andreas, > I'm now > facing the next configure issue which seems that BOOST_INCLUDEDIR and > BOOST_LIBRARYDIR are not found. Any clue how to get the latest state > of salmon Git build? It was a missing build-dependency on libboost-timer-dev. I also added the necessary build-deps on

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi Andreas, > thanks to Sascha's help I finalised rapmap, ITPed #836914 and uploaded. You’re welcome. I was going to finish it yesterday but I since I couldn’t find a explicit copyright statement I raised https://github.com/COMBINE-lab/RapMap/issues/31. It looks like I could also have just

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi Andreas, >> However, the build still fails with: >> >> In file included from >> /build/salmon-0.7.1+ds1/include/UtilityFunctions.hpp:5:0, >>from /build/salmon-0.7.1+ds1/include/SBModel.hpp:7, >>from /build/salmon-0.7.1+ds1/src/SBModel.cpp:1: >>

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

Hi Andreas, >> I’d rather get it to work for now and will try including the smallest >> necessary set of code needed to build salmon. It is definitely more than one >> file; currently I’m using trial and error to arrive at a minimal set. I have >> also opened

Bug#837276: python-mne: FTBFS: build-dependency not installable: mayavi2 (>= 4.4.3-1)

Hi, I am unable to reproduce this FTBFS in a current sid amd64 cowbuilder chroot. See attached build log. I can see that the latest mayavi2 NMU (4.4.3-2.2) failed to build for amd64, but I was sure able to get 4.4.3-2.1. I’m not sure I understand if this might be the reason for this failure

Bug#833965: tcsh: uses deprecated BSD union wait type

Hi, just a friendly ping whether this is still on anyone’s radar. I assume that #837026 [1] is a direct consequence of this issue? Cheers Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837026 On Thu, 1 Sep 2016 13:02:17 +0200 Thomas Lange wrote:

Bug#839309: [Debian-med-packaging] Bug#839309: orthanc-postgresql 2.0-3

Hi Sebastien, looks good to me, I'm on it. Cheers Sascha > On 3 Oct 2016, at 10:54, Sébastien Jodogne wrote: > > Hello, > > I have just updated the orthanc-postgresql package: > https://anonscm.debian.org/viewvc/debian-med?view=revision=22821 > > This new version of

Bug#839320: [Debian-med-packaging] Bug#839320: gubbins: FTBFS: Tests failures

Hi all, can anyone reproduce the failure as indicated in the bug submitter’s build log? My own cowbuilder build (unstable amd64) succeeds at ‘test_change_window_size' but fails at ‘test_robinson_foulds_convergence’ (the latter I have checked with upstream and they are happy to have this test

Bug#840826: princeprocessor: /usr/bin/pp64 is already used by polylib-utils

Hi Andreas, thanks for noticing this and letting me know. I will make sure to rename the single binary in this package to avoid the name clash. Cheers Sascha > On 15 Oct 2016, at 13:22, Andreas Beckmann wrote: > > Package: princeprocessor > Version: 0.21-2 > Severity:

Bug#840826: marked as pending

75e58607c5d13c027f55015c19a495e26d9f7712 Author: Sascha Steinbiss <sa...@debian.org> Date: Sat Oct 15 11:52:55 2016 + rename binary to avoid name clash diff --git a/debian/changelog b/debian/changelog index 9c5a6a5..021ff75 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +princepro

Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

Hi all, thanks John for the detailed explanation and the patches. >> So the real solution here is to revert your autoconf-archive to 6dc6cc5^ >> and use that unborked ax_with_curses.m4, which will in future be bundled >> with samtools. > > This should have been 0351b06^. I see. For now I have

Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

Hi. [...] >> Thanks. This has fixed the problem for me. Is this solution OK for everyone? > > Fine for me OK, I'll upload later. Cheers Sascha

Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

Hi all, I have pushed a fix (9aac9cb) to Git, solving the FTBFS. Before doing an upload I would be very happy if an Autotools-savvy person could take another closer look because admittedly I am not really sure about the cause of the problem. I also had to disable a test (test_usage) that

Bug#840974: [Debian-med-packaging] Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

Hi Chris, >> I would be very happy if an Autotools-savvy person could take another >> closer look because admittedly I am not really sure about the cause >> of the problem. > […] >> I also had to disable a test (test_usage) that otherwise also seems to >> (mysteriously?) fail > > These two

Bug#828254: bro: FTBFS with openssl 1.1.0

Hi Hilko and Kurt, some progress on this: I have modified Hilko's patch to use new API functions to access the OCSP response info, see attachment. This seems to have been the last issue, Bro builds fine with this patch for me with no additional API breaks. Unfortunately my additions require the

Bug#839320: Would you upload with disabled test?

Hi Andreas, > since there are no responses so far I wonder how to proceed with the > package. Yes, that's one of the bugs that has been on my list for a while as well... > I need to admit I get a different error when trying to build > the current state of gubbins packaging Git: > > gcc

Bug#839320: Would you upload with disabled test?

Hi Andreas and Adrian, >>> since there are no responses so far I wonder how to proceed with the >>> package. >> >> Yes, that's one of the bugs that has been on my list for a while as well... Regarding the original bug, I have confirmed again with upstream that it's fine to disable these tests,

Bug#846671: [Debian-med-packaging] Bug#846671: Artemis should adapt to new htsjdk API which has dropped SAMFileReader (Was: [samtools/htsjdk] SAMFileReader vanished in Version 2.7.0 (#767))]

Hi all, [...] > I do not find branch 6_0_17 and I do not even think that we need this > extra branch. I'd recommend to use master and as far as I understood > Olivier's comment your test should be sufficient. Sure. Sorry for the branch naming mixup, it was a little late ;) > I personally also

Bug#846671: [Debian-med-packaging] Bug#846671: Artemis should adapt to new htsjdk API which has dropped SAMFileReader (Was: [samtools/htsjdk] SAMFileReader vanished in Version 2.7.0 (#767))]

Hi Andreas and Andrew, to address this problem I have taken a shot at patching Debian’s Artemis to use the new htsjdk API, avoiding SAMFileReader and using the SamReaderFactory instead. This fixed the FTBFS for me. I tested BAM file reading by opening MAL1.embl.gz from the test/data directory

Bug#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

forwarded 859111 https://github.com/sanger-pathogens/ariba/issues/170 tags 859111 upstream thanks Hi all, > On Thu, Mar 30, 2017 at 06:20:16PM +0300, Adrian Bunk wrote: >> Control: retitle -1 ariba FTBFS with bowtie2 2.3.1-1 > [...] >> This is actually not related to the ariba version but to the

Bug#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

Hi all, >> Control: retitle -1 ariba FTBFS with bowtie2 2.3.1-1 > [...] >> This is actually not related to the ariba version but to the bowtie2 version, >> ariba 2.6.1+ds-1 in stretch builds with the stretch bowtie2 2.3.0-2 but >> FTBFS with the sid bowtie2 2.3.1-1 > > Do we already know

Bug#860876: [Debian-med-packaging] Bug#860876: reapr: FTBFS: Error in system call: R CMD BATCH 00.Sample/gc_vs_cov.R 00.Sample/gc_vs_cov.Rout

reassign 860876 r-cran-kernsmooth thanks Hi Chris, thanks for your bug report. I can reproduce the problem; it looks like an R component within REAPR’s build time tests has started to fail, causing the whole build to break. […] > [REAPR preprocess] Error in system call: > R CMD BATCH

Bug#868614: [Debian-med-packaging] Bug#868614: cwltool FTBFS with python-typing 3.6.1-1

Hi Michael, [...] > Installed /build/1st/cwltool-1.0.20170114120503 > Processing dependencies for cwltool==1.0.20170114120503 > Searching for typing<3.6,>=3.5.2 > Reading https://pypi.python.org/simple/typing/ > Download error on https://pypi.python.org/simple/typing/: [Errno -3] > Temporary

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

Hi Michael, > I have a fix checked in as part of the 2.1-1 release, but it is blocked > on me uploading a python3 version of sphinx-guzzle Ah I see -- thanks, won't pursue this anymore then :) Cheers Sascha > Pe 4 iul. 2017 23:12, "Sascha Steinbiss" <sa...@debian.org >

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

Hi all, >> I've applied this patch to get the build working now that Python 3.6 is a >> supported version in Ubuntu. I admit I don't entirely understand why it is >> necessary! Maybe you do? :) >> > Now that python3.6 is supported in Debian, khmer FTBFS: > >

Bug#859111: [Debian-med-packaging] Bug#859111: Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

tags 859111 pending thanks > bowtie2 2.3.1 introduced different default values for one of the > parameters [1], it might be likely that it's connected to that. I > have contacted upstream Upstream have added support for Bowtie2 2.3.1 [1] and I can confirm that the tests -- and hence the build --

Bug#860692: gopacket: FTBFS on i386: XXX

tags 860692 patch thanks Hi all, [...] > # Copy test files to build dir > cp pcap/*.pcap obj-i386-linux-gnu/src/github.com/google/gopacket/pcap/ > cp: target 'obj-i386-linux-gnu/src/github.com/google/gopacket/pcap/' is not a directory > debian/rules:19: recipe for target

Bug#860684: [pkg-go] Bug#860684: golang-github-streadway-amqp: FTBFS on i386: dh_auto_test: go test -v -p 1 github.com/streadway/amqp returned exit code 1

Hi all, [...] >> === RUN TestGoFuzzCrashers >> --- FAIL: TestGoFuzzCrashers (0.00s) >> panic: runtime error: makeslice: len out of range [recovered] >> panic: runtime error: makeslice: len out of range >> >> goroutine 3445 [running]: >> panic(0x8249520, 0x18a0e0a8) >>

Bug#863414: coyim FTBFS: xmpp: failed to verify TLS certificate: x509: certificate signed by unknown authority

Hi Chris, [...] > I've uploaded coyim 0.3.7-2.1 to DELAYED/5: Many thanks for taking care of this! I was unfortunately not able to respond to the bug in time due to traveling :/ Cheers Sascha signature.asc Description: OpenPGP digital signature

Bug#865039: [Debian-med-packaging] Bug#865039: libhat-trie FTBFS on 32bit: check_ahtable fails

forwarded 865039 https://github.com/dcjones/hat-trie/issues/31 tags 865039 upstream thanks > On 18 Jun 2017, at 21:56, Adrian Bunk wrote: > > Source: libhat-trie > Version: 0.1.1-1 > Severity: serious > > https://buildd.debian.org/status/package.php?p=libhat-trie > > ... >

Bug#881496: [Pkg-privacy-maintainers] Bug#881496: onioncircuits: current python3/testing breaks onioncircuits

Hi Mykola, thanks for letting us know about the issue. > --8<---cut here---start->8--- > $ onioncircuits > Traceback (most recent call last): > File "/usr/bin/onioncircuits", line 31, in > import stem.connection > File

Bug#881496: [Pkg-privacy-maintainers] Bug#881496: onioncircuits: python3/testing and apparmor/testing breaks onioncircuits

Hi all, ah, this sheds some light on the situation. However: > audit[3722]: AVC apparmor="DENIED" operation="file_mmap" > profile="/usr/bin/onioncircuits" > name="/usr/lib/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so" > pid=3722 comm="onioncircuits" requested_mask="m"

Bug#887727: [debhelper-devel] Bug#887727: debhelper, dh-dist-zilla: dh-dist-zilla based package builds no more run dh_auto_install (and maybe other dh_auto_*)

Hi Niels and Axel, > Niels Thykier wrote: >> Could you please verify that the attached patch fixes the problem for you? > > systray-mdstat and roary both build fine again with this patch applied > on top of debhelper's git HEAD. Confirmed, and new roary upload done [x]. Thanks to you both for

Bug#889615: python-tifffile: broken autopkgtest, broken package

Hi Andreas, >> $ ./debian/tests/python-import >> 2017.09.14 >> Traceback (most recent call last): >> File "./debian/tests/python-import", line 16, in >> for page in tif: >> TypeError: 'TiffFile' object is not iterable >> $ >> >> This part looks like it might be a bug in the test rather

Bug#889615: python-tifffile: broken autopkgtest, broken package

Hi again, [...] >> I wonder whether you have an idea how this can be fixed. > > Unfortunately I'm a bit swamped with work and (more so) RL stuff at the > moment... maybe this has time until the sprint later this week? Actually this was rather easy to address. I pushed some code that should fix

Bug#905169: golang-github-graph-gophers-graphql-go: Incomplete debian/copyright?

Hi Chris, > I just ACCEPTed golang-github-graph-gophers-graphql-go from NEW but > noticed it was missing attribution in debian/copyright for at least > internal/validation/testdata. > > This is in no way exhaustive so please check over the entire package > carefully and address these on your

Bug#893697:

affects 893697 iva thanks Hi, this is also a problem in iva [1]. Patch attached — any comments? I don’t have too much experience with NMUs, would that be OK here? What delay would you recommend? Cheers Sascha networkx.patch Description: Binary data signature.asc Description: Message

Bug#893697:

Hi Sandro, thanks for your reply. >> this is also a problem in iva [1]. Patch attached — any comments? I don’t >> have too much experience with NMUs, would that be OK here? What delay would >> you recommend? > > please hold your NMU, i'll prepare the new upstream release instead Sure, thanks

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

Hi, FYI I have already opened an issue upstream for something that might be related: https://github.com/marbl/Mash/issues/104 I suspect that some of these failures are connected to the update of Cap'n Proto to 0.7.0, the issues only started after the dependency was upgraded in in unstable.

Bug#919778: [Debian-med-packaging] Bug#919778: mash FTBFS on armhf when built on arm64 hardware

tags 919778 help forwarded 919778 https://github.com/marbl/Mash/issues/108 thanks Hi, thanks for reporting this issue! I have forwarded this upstream but I'm afraid I won't be able to do much about it in the near future. With the upcoming freeze in mind, and given the fact that upstream doesn't

Bug#918850: libmypaint: FTBFS with Sphinx 1.8: No module named 'sphinx.ext.pngmath'

loses: #918850 + * Make build reproducible. Thanks to Chris Lamb for the patch. +Closes: #895401 + * Reference correct homepage. Thanks to Chris Lamb for the patch. + Closes: #895402 + + -- Sascha Steinbiss Sat, 09 Feb 2019 12:22:40 +0100 + libmypaint (1.3.0-2) unstable; urgency=medium

Bug#921778: deap: FTBFS (Could not import extension sphinx.ext.pngmath)

AUTOPKGTEST_TMP instead of ADTTMP - -- Ondřej Nový Tue, 13 Feb 2018 10:18:20 +0100 + [ Sascha Steinbiss ] + * Use imgmath Sphinx extension instead of deprecated pngmath. +Closes: #921778 + + -- Sascha Steinbiss Sat, 09 Feb 2019 19:28:44 +0100 deap (1.0.2.post2-5) unstable; urgency

Bug#915175: oath-toolkit FTBFS with glibc 2.28

oath-toolkit-2.6.1/debian/changelog 2019-02-09 16:39:41.0 +0100 @@ -1,3 +1,11 @@ +oath-toolkit (2.6.1-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * Use _IO_EOF_SEEN as GNU libc indicator. +Closes: #915175 + + -- Sascha Steinbiss Sat, 09 Feb 2019 16:39:41 +0100 + oath-to

Bug#884721: rsyncrypto: Segmentation fault with --delete

@@ -1,3 +1,13 @@ +rsyncrypto (1.14-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add explicit build dependency on automake-1.15. +Closes: #912051 + * Fix segfault with --delete. Thanks to Chris Boot for the patch. +Closes: #884721 + + -- Sascha Steinbiss Sat, 09 Feb

Bug#921759: sdaps: FTBFS (Error running "pdflatex" to compile the LaTeX file)

. + + -- Sascha Steinbiss Sun, 10 Feb 2019 15:51:38 +0100 + sdaps (1.2.1-1) unstable; urgency=medium * Initial release (Closes: #887393) diff -Nru sdaps-1.2.1/debian/patches/disable-bookmark.patch sdaps-1.2.1/debian/patches/disable-bookmark.patch --- sdaps-1.2.1/debian/patches/disable

Bug#917797: snapd: FTBFS: too many arguments in call to activation.Listeners

tags 917797 + unreproducible user debian-rele...@lists.debian.org usertag 917797 + bsp-2019-02-de-berlin thanks Hi, a warm hello from the BSP in Berlin. > I found problems with am armel-on-arm64 build, but I can reproduce the > same problem on a straight amd64 build too. I've tried to look

Bug#897865: Code compiles just fine with current commit in Salsa

tags 897865 + unreproducible user debian-rele...@lists.debian.org usertag 897865 + bsp-2019-02-de-berlin thanks Hi, a warm hello from the BSP in Berlin (and from across the table fro you, Hilko ;). > The current commit in Salsa -- 00b7e79dd144ebfc5d187c331353b50239b032db, > marked "snapd

Bug#920223: gnome-keysign: fails to build because of test failures

Hi Jeremy, > gnome-keysign fails to build from source in a clean unstable chroot as > seen on Ubuntu and with Debian Reproducible Builds. The build tests > are failing. Thanks for reporting this. Just for the record, I do indeed build all my packages in clean unstable chroots via

Bug#935917: suricata-update: cannot use suricata-update command

Dear Aaron, Thanks for bringing this to my attention. > I just installed the suricata-update package from the Debian buster repo. > Before that, I used the github version which worked fine. I see. > > The "suricata-update" command of the Debian package tries to execute a file >

Bug#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

> On 19. Sep 2019, at 11:29, Aurelien Jarno wrote: > > Package: augustus > Version: 3.3.3+dfsg-1 > Severity: serious > > On 2019-09-18 23:34, Debian FTP Masters wrote: >> augustus_3.3.3+dfsg-1_mips64el.deb: Built-Using refers to non-existing >> source package libbam-dev (= 0.1.19-4) >> >>

Bug#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

Hi Aurelien, thanks for the quick reply! >> 7.8 of the policy requires that I have an ‘=‘ version relation on the >> package listed in ‘Built-Using' — I am not even sure how I would determine >> that for the source package since it’s not even used in the build? > > Quoting the corresponding

Bug#937811: python-hkdf: Python2 removal in sid/bullseye

It looks like all reverse deps are currently exclusively using the Python3 version: [vagrant@debian:~/gnome-keysign] $ apt-rdepends -r python3-hkdf Reading package lists... Done Building dependency tree Reading state information... Done python3-hkdf Reverse Depends: magic-wormhole

Bug#937811: python-hkdf: Python2 removal in sid/bullseye

> It looks like all reverse deps are currently exclusively using the Python3 > version: Or maybe not, looks like not all rdeps are displayed. Looks like things like python-omemo and friends still depend on this. So no removal upload for me then. S.

Bug#950211: python-virustotal-api fails autopkg test

Hi Matthias, > the autodep8 test fails, because the package is wrongly named. The package > name > should be python-virustotal-apis? I wanted to be in line with the name of the package on PyPi [1] as that how I would look for this package if I wanted to use it. 'virustotal-api' is also the

Bug#950211: python-virustotal-api fails autopkg test

Hi Matthias, >>> Or you remove the autodep8 test from debian/control. >> Indeed that is what I changed in 1.1.11-2 which should be in both sid >> and bullseye by now -- I changed the autopkgtest definition and added >> custom test scripts reflecting the situation. >> >> All tests are green so

Bug#951765: suricata: FTBFS on armel: atomic builtins clashing with Rust objects

Source: suricata Severity: serious Tags: ftbfs help Justification: fails to build from source (but built successfully in the past) Suricata fails to build on armel at link time [1] due to duplicate objects between what is built by the Rust compiler and what is built by gcc: /usr/bin/ld:

Bug#937269: peframe: Python2 removal in sid/bullseye

Just an update: Python 3 compatibility is indeed introduced in the latest upstream version, however, that version also adds some new dependencies that would need to be packaged and pass NEW. For example, python-virustotal-api, which has been in NEW for quite some time. I have also looked at

Bug#952316: [pkg-go] Bug#952316: gopacket: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 github.com/google/gopacket github.com/google/gopacket/afpacket github.co

Hi. > During a rebuild of all packages in sid, your package failed to build > on amd64. This is easily fixed by updating to the latest upstream version (1.1.17). @Hilko: OK with you? I have already prepared the update as need this for stenographer to migrate. Gopacket as a dependency has been

Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

Hi all, > you once wrote that test. Do you have any idea how to fix it? Since this is just a warning, it might be sufficient to simply add Restrictions: allow-stderr That would make sure that printing a warning to stderr does not cause the test to fail. I will test this later and fix it if

Bug#970340: [Debian-med-packaging] Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

Hi all, >> you once wrote that test. Do you have any idea how to fix it? > > Since this is just a warning, it might be sufficient to simply add > > Restrictions: allow-stderr > > That would make sure that printing a warning to stderr does not cause > the test to fail. I will test this later

Bug#937269: peframe: Python2 removal in sid/bullseye

Hi Moritz, >> Just an update: Python 3 compatibility is indeed introduced in the latest >> upstream version, however, that version also adds some new dependencies that >> would need to be packaged and pass NEW. For example, python-virustotal-api, >> which has been in NEW for quite some time. I

Bug#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

Hi, has anyone taken any action here already? Some of my packages are affected by this as well. Cheers Sascha

Bug#971154: fever: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/DCSO/fever/cmd/fever github.com/DCSO/fever/cmd/fever/cmds github.com/DCSO/fever/db github.

reassign 971154 golang-go thanks Hi Lucas, Thanks for reporting this. […] >> ok github.com/DCSO/fever/input 15.229s >> # github.com/DCSO/fever/processing [github.com/DCSO/fever/processing.test] >> compile: loop To me, this looks like a possible Go regression, though. The above seems to

Bug#963332: ariba: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8 returned exit code 13

Hi Andreas, thanks for your email! [Test failures] [...] >>> -- >>> Ran 356 tests in 57.387s >>> >>> FAILED (SKIP=2, errors=6) >>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd >>>

Bug#971296: rekall: Switch to python3-pycryptodome

Hi everyone, [...] > I just discovered that rekall is no longer maintained at the upstream > level so I'm wondering if we should not just remove the package. > > Hilko, Sascha, what do you think? I would be fine with removing it as at least I don't have much interest in it any more anyway. It

Bug#971296: rekall: Switch to python3-pycryptodome

Hi all, [..]> I just discovered that rekall is no longer maintained at the upstream > level so I'm wondering if we should not just remove the package. > > Hilko, Sascha, what do you think? Just bringing this up again... I would be in favour of removing it completely. Would be happy to file a RM

Bug#937269: peframe: Python2 removal in sid/bullseye

Hi, Please feel free to remove it for now, unless someone wants to take over. Ack. Given that noone stepped up for about a year now, I'll go ahead and file a removal request. Fine with me! Cheers Sascha

Bug#987378: yara breaks golang-github-hillu-go-yara autopkgtest + ftbfs

Hi, I think this is done now. With YARA 4.1.2 and golang-github-hillu-go-yara 4.1.0 now in unstable, the build works again as the build-time tests complete fine. @Hilko any other comments? Cheers Sascha

Bug#1001527: FTBFS with fmtlib 8

Hi, > I have uploaded fmtlib/8 to experimental, and plan to start this transition. > > You package FTBFS with fmtlib/8, it has been fixed in version 2021.08.26. > Please package the new version or backport the relevant commits. Unfortunately never versions than the one currently in testing

Bug#1001981: [Pkg-privacy-maintainers] Bug#1001981: onioncircuits: Doesn't start: Permission denied: '/usr/local/lib/python3.9/dist-packages/usb-0.0.83.dev0.dist-info'

Hi Richard, thanks for your report. Let's see what I can do. > clicking then launcher results in no visible action. This is just in bullseye? Unfortunately I can't reproduce this, onioncircuits opens fine for me. > Starting from shell > results in this: > > rz@rz-debian:~$ onioncircuits >

Bug#1001981: [Pkg-privacy-maintainers] Bug#1001981: Bug#1001981: onioncircuits: Doesn't start: Permission denied: '/usr/local/lib/python3.9/dist-packages/usb-0.0.83.dev0.dist-info'

severity 1001981 normal thanks FTR: The original reporter confirmed that removing the Python modules in /usr/local got onioncircuits to start again. So lowering severity as this is likely not a packaging bug breaking onioncircuits for everyone. S. On 23.12.21 12:58, Sascha Steinbiss wrote: >

Bug#999806: pygattlib: Misbuild with multiple supported python versions

Hi Nobuhiro, [...] > Python3.10 has been introduced in Ubuntu, and as part of the rebuild > of packages against 3.10 I noticed that pygattlib misbuilds, linking > both the python3.9 and python3.10 extensions against the same version > of libboost_python instead of linking each against the

Bug#999620: pktanon: autopkgtest regression on armhf

Hi Paul, sorry for the delay in replying, I was quite busy and now I have some free time over the holidays to follow up. >> I am puzzled. The recent upload only changed the watchfile and updated >> Standards-Version, compat level etc -- packaging things. Nothing touched >> the code or build

  1   2   >