Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)

2024-04-04 Thread Sascha Steinbiss
Hi Andreas, after routine-update dh_missing failed due to compat level 13 which defaults to fail if some files are not installed. Yep, encountered that in other places as well when updating a few (old!) things. This made me aware that upstream in principle installs a test suite we could use

Bug#1060955: [Pkg-privacy-maintainers] Bug#1060955: (none)

2024-02-29 Thread Sascha Steinbiss
Hi all, Upgrading txtorcon to the latest version (23.11.0) should fix this problem, it does not happen there for me. I have imported the new upstream version and updated the packaging [1] after adjusting the watchfile, which indeed fixes this FTBFS. Would it be OK to push to git and

Bug#1063602: seqan-needle: FTBFS on amd64: test/api/insert_delete_test (Failed)

2024-02-18 Thread Sascha Steinbiss
Hi, https://buildd.debian.org/status/fetch.php?pkg=seqan-needle=amd64=1.0.2%2Bds-2=1707394988=0 2: [ RUN ] insert.ibfmin 2: unknown file: Failure 2: C++ exception with description "std::bad_alloc" thrown in the test body. 2: 2: [ FAILED ] insert.ibfmin (0 ms) [...] 2: [ FAILED ] 1

Bug#1032553: magic-wormhole: FTBFS in testing: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

2023-04-08 Thread Sascha Steinbiss
Hi Martin, [...] This is mentioned in https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely a "timing issue". Not sure if it's fixed upstream. > Could it make sense to also patch the tests to include the delay that is mentioned in the GitHub issue comments? I've tried

Bug#1032553: magic-wormhole: FTBFS in testing: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

2023-04-05 Thread Sascha Steinbiss
Hi all, [...] This is mentioned in https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely a "timing issue". Not sure if it's fixed upstream. > Could it make sense to also patch the tests to include the delay that is mentioned in the GitHub issue comments? Cheers Sascha

Bug#1012382: pktanon: autopkgtest fails on s390x with: wrong pcap file version: should be 2.4

2022-12-04 Thread Sascha Steinbiss
forwarded 1012382 https://github.com/KIT-Telematics/pktanon/issues/8 tags 1012382 upstream thanks Hi, Your package has an autopkgtest, great. However, it fails on s390x. I have attached the relevant piece of the log [1]. I'd like to note that s390x is big-endian. Maybe the check for the

Bug#1013938: balboa: regression + flaky autopkgtest: regularly times out on amd64, i386 and s390x

2022-06-27 Thread Sascha Steinbiss
Hi Paul, thanks for letting me know! I noticed that there were several runs that took 2:47 (our timeout time), while successful runs more in the order of minutes. This started to happen recently. This is likely related to #1012629 [1] (also see #1012804 [2]), a hang issue that was in fact

Bug#1013588: Accepted golang-github-satta-ifplugo 0.0~git20200508.ca679be-4 (source) into unstable

2022-06-24 Thread Sascha Steinbiss
Hi Shengjing! Even better :) I will undo my change then as well as soon as a new version hits the archive. Thanks Sascha On 24.06.22 16:18, Shengjing Zhu wrote: Hi, golang-github-satta-ifplugo (0.0~git20200508.ca679be-4) unstable; urgency=medium . * Adjust import path for

Bug#1010771: suricata: recieve erros after adding rule list

2022-05-10 Thread Sascha Steinbiss
severity 1010771 normal thanks Hi Tim, I just noticed you also included your suricata.yaml configuration file in your bug report. I think I found the cause of your problem. Let's take a look at a problematic rule: 9/5/2022 -- 14:20:21 - -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error

Bug#1010771: suricata: recieve erros after adding rule list

2022-05-09 Thread Sascha Steinbiss
Hi, [...] 9/5/2022 -- 14:20:21 - -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Complete IP space negated. Rule address range is NIL. Probably have a !any or an address range that supplies a NULL address range This seems to indicate that in the rule below, the expression

Bug#999620: pktanon: autopkgtest regression on armhf

2022-04-18 Thread Sascha Steinbiss
Hi, Do you think we should wait for this to be fixed? As I said before I (just from my practical point of view) would be in favor of just removing the problematic architectures. I have no opinion on this. But if you want the package to be releasable, you will need to change it so that it is

Bug#999620: pktanon: autopkgtest regression on armhf

2022-04-14 Thread Sascha Steinbiss
Hi Steve, Many thanks for reproducing this and for offering a the detailed explanation. I would be happy to forward your findings to upstream (however, my previous issues/PRs on upstream's GitHub have gone unanswered). For the time being, I must admit I unfortunately do not have the time to

Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

2022-03-19 Thread Sascha Steinbiss
Hi Nilesh, […] > Would it be possible to add a hint to ignore arm64 autopkgtest suite? BTW I think this is possible already in the autopkgtest definition [1] by adding an Architecture: section and leaving out arm64 in the list of archs you list in there — if that is what you mean. Cheers

Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

2022-02-20 Thread Sascha Steinbiss
Hi Andreas, thanks for your quick reply! On 19.02.22 22:17, Andreas Beckmann wrote: > On 19/02/2022 20.13, Sascha Steinbiss wrote: >>     79 | #error The version of CUB in your include path is not compatible >> with this release of Thrust. CUB is now included in the CUDA Too

Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

2022-02-19 Thread Sascha Steinbiss
Hi all, greetings from the Debian Med Sprint 2021! [...] > /usr/bin/nvcc -M -D__CUDACC__ > /build/relion-cuda-3.1.0/src/acc/cuda/cuda_projector_plan.cu -o >

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

2022-01-02 Thread Sascha Steinbiss
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#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'

2022-01-02 Thread Sascha Steinbiss
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#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'

2021-12-23 Thread Sascha Steinbiss
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#999620: pktanon: autopkgtest regression on armhf

2021-12-20 Thread Sascha Steinbiss
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

Bug#1001527: FTBFS with fmtlib 8

2021-12-20 Thread Sascha Steinbiss
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#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]

2021-11-22 Thread Sascha Steinbiss
Hi Roberto, thanks for the quick response! > I cannot attend to this at the moment, so I give you my blessing to > proceed with the NMU. Thanks, will do that and upload soon. Cheers Sascha

Bug#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]

2021-11-22 Thread Sascha Steinbiss
. + * Incorporate patch from upstream to fix build on newer GCC versions. +(Closes: #997248) + + -- Sascha Steinbiss Mon, 22 Nov 2021 13:01:43 +0100 + mysql++ (3.2.5-2) unstable; urgency=medium * Update to Standards-Version 4.5.0 (no changes) diff -Nru mysql++-3.2.5/debian/patches

Bug#999620: pktanon: autopkgtest regression on armhf

2021-11-14 Thread Sascha Steinbiss
Hi Paul, > With a recent upload of pktanon the autopkgtest of pktanon fails in > testing on armhf when that autopkgtest is run with the binary packages > of pktanon from unstable. [...] > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the

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

2021-09-02 Thread Sascha Steinbiss
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#937269: peframe: Python2 removal in sid/bullseye

2021-09-01 Thread Sascha Steinbiss
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#971296: rekall: Switch to python3-pycryptodome

2021-01-13 Thread Sascha Steinbiss
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#971296: rekall: Switch to python3-pycryptodome

2020-11-30 Thread Sascha Steinbiss
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#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

2020-10-13 Thread Sascha Steinbiss
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.

2020-09-27 Thread Sascha Steinbiss
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#970340: [Debian-med-packaging] Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

2020-09-15 Thread Sascha Steinbiss
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#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

2020-09-15 Thread Sascha Steinbiss
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#937269: peframe: Python2 removal in sid/bullseye

2020-09-13 Thread Sascha Steinbiss
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#963332: ariba: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8 returned exit code 13

2020-06-22 Thread Sascha Steinbiss
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#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

2020-04-29 Thread Sascha Steinbiss
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#951765: suricata: FTBFS on armel: atomic builtins clashing with Rust objects

2020-02-21 Thread Sascha Steinbiss
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#950211: python-virustotal-api fails autopkg test

2020-01-30 Thread Sascha Steinbiss
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#950211: python-virustotal-api fails autopkg test

2020-01-30 Thread Sascha Steinbiss
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#937269: peframe: Python2 removal in sid/bullseye

2019-12-26 Thread Sascha Steinbiss
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#937811: python-hkdf: Python2 removal in sid/bullseye

2019-12-11 Thread Sascha Steinbiss
> 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#937811: python-hkdf: Python2 removal in sid/bullseye

2019-12-10 Thread Sascha Steinbiss
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#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

2019-09-20 Thread Sascha Steinbiss
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#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

2019-09-19 Thread Sascha Steinbiss
> 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#935917: suricata-update: cannot use suricata-update command

2019-08-27 Thread Sascha Steinbiss
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#921759: sdaps: FTBFS (Error running "pdflatex" to compile the LaTeX file)

2019-02-10 Thread Sascha Steinbiss
. + + -- 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#921778: deap: FTBFS (Could not import extension sphinx.ext.pngmath)

2019-02-09 Thread Sascha Steinbiss
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

2019-02-09 Thread Sascha Steinbiss
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

2019-02-09 Thread Sascha Steinbiss
@@ -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#918850: libmypaint: FTBFS with Sphinx 1.8: No module named 'sphinx.ext.pngmath'

2019-02-09 Thread Sascha Steinbiss
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#897865: Code compiles just fine with current commit in Salsa

2019-02-09 Thread Sascha Steinbiss
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#917797: snapd: FTBFS: too many arguments in call to activation.Listeners

2019-02-09 Thread Sascha Steinbiss
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#919778: [Debian-med-packaging] Bug#919778: mash FTBFS on armhf when built on arm64 hardware

2019-01-27 Thread Sascha Steinbiss
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#920223: gnome-keysign: fails to build because of test failures

2019-01-24 Thread Sascha Steinbiss
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#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

2019-01-07 Thread Sascha Steinbiss
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#905169: golang-github-graph-gophers-graphql-go: Incomplete debian/copyright?

2018-08-01 Thread Sascha Steinbiss
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:

2018-04-14 Thread Sascha Steinbiss
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#893697:

2018-04-14 Thread Sascha Steinbiss
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#889615: python-tifffile: broken autopkgtest, broken package

2018-02-05 Thread Sascha Steinbiss
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#889615: python-tifffile: broken autopkgtest, broken package

2018-02-05 Thread Sascha Steinbiss
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#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_*)

2018-01-21 Thread Sascha Steinbiss
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#881496: [Pkg-privacy-maintainers] Bug#881496: onioncircuits: python3/testing and apparmor/testing breaks onioncircuits

2017-11-20 Thread Sascha Steinbiss
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#881496: [Pkg-privacy-maintainers] Bug#881496: onioncircuits: current python3/testing breaks onioncircuits

2017-11-18 Thread Sascha Steinbiss
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#868614: [Debian-med-packaging] Bug#868614: cwltool FTBFS with python-typing 3.6.1-1

2017-08-10 Thread Sascha Steinbiss
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

2017-07-04 Thread Sascha Steinbiss
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

2017-07-04 Thread Sascha Steinbiss
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#865039: [Debian-med-packaging] Bug#865039: libhat-trie FTBFS on 32bit: check_ahtable fails

2017-06-18 Thread Sascha Steinbiss
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#863414: coyim FTBFS: xmpp: failed to verify TLS certificate: x509: certificate signed by unknown authority

2017-05-29 Thread Sascha Steinbiss
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#859111: [Debian-med-packaging] Bug#859111: Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

2017-04-27 Thread Sascha Steinbiss
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#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

2017-04-24 Thread Sascha Steinbiss
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#860692: gopacket: FTBFS on i386: XXX

2017-04-24 Thread Sascha Steinbiss
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#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

2017-04-21 Thread Sascha Steinbiss
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#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

2017-04-04 Thread Sascha Steinbiss
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

2017-04-04 Thread Sascha Steinbiss
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#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.

2017-03-01 Thread Sascha Steinbiss
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#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.

2017-02-26 Thread Sascha Steinbiss
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#750895: python3-tempita: doesn't work with python 3.3

2017-02-26 Thread Sascha Steinbiss
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#855932: sugar-physics-activity: FTBFS: unsatisfiable build-dependencies: python-sugar-0.88, python-sugar-toolkit-0.88

2017-02-26 Thread Sascha Steinbiss
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#853931: FTBFS: dh_install: debian/suricata-hyperscan.install returned exit code 127

2017-02-02 Thread Sascha Steinbiss
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)

2017-01-27 Thread Sascha Steinbiss
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

2017-01-25 Thread Sascha Steinbiss
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#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))]

2016-12-08 Thread Sascha Steinbiss
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))]

2016-12-07 Thread Sascha Steinbiss
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#828254: bro: FTBFS with openssl 1.1.0

2016-11-14 Thread Sascha Steinbiss
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?

2016-10-26 Thread Sascha Steinbiss
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#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

2016-10-24 Thread Sascha Steinbiss
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?

2016-10-23 Thread Sascha Steinbiss
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#839320: Would you upload with disabled test?

2016-10-21 Thread Sascha Steinbiss
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#840974: [Debian-med-packaging] Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

2016-10-20 Thread Sascha Steinbiss
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#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

2016-10-20 Thread Sascha Steinbiss
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#840826: marked as pending

2016-10-15 Thread Sascha Steinbiss
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#840826: princeprocessor: /usr/bin/pp64 is already used by polylib-utils

2016-10-15 Thread Sascha Steinbiss
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#839320: [Debian-med-packaging] Bug#839320: gubbins: FTBFS: Tests failures

2016-10-03 Thread Sascha Steinbiss
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#839309: [Debian-med-packaging] Bug#839309: orthanc-postgresql 2.0-3

2016-10-03 Thread Sascha Steinbiss
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#833965: tcsh: uses deprecated BSD union wait type

2016-09-17 Thread Sascha Steinbiss
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#837276: python-mne: FTBFS: build-dependency not installable: mayavi2 (>= 4.4.3-1)

2016-09-17 Thread Sascha Steinbiss
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#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

2016-09-07 Thread Sascha Steinbiss
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#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

2016-09-07 Thread Sascha Steinbiss
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()'

2016-09-07 Thread Sascha Steinbiss
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()'

2016-09-07 Thread Sascha Steinbiss
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()'

2016-09-07 Thread Sascha Steinbiss
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: [Debian-med-packaging] Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

2016-09-06 Thread Sascha Steinbiss
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

  1   2   >