Hi,
I would like to let you know that I am going to NMU magic-wormhole 0.14
which fixes #1073069 and #1073799. I have packaged python-iterable-io as
a dependency and can verify that magic-wormhole builds fine and tests
succeed.
Since Antoine has low threshold NMU declared, I will upload dire
Hi Charles,
many thanks (and to Sergio) for reporting this and for providing such a
deep insight into the issue.
I have added a patch to stenokeys.sh (the script that creates the CA,
certs, etc.) so it sets sensible subjectAltNames [1].
Just uploaded a new version containing this patch. Let
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
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 team-up
Hi,
https://buildd.debian.org/status/fetch.php?pkg=seqan-needle&arch=amd64&ver=1.0.2%2Bds-2&stamp=1707394988&raw=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
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 adding
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
O
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 versio
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 caus
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 shirou/g
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 pa
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
![$SMTP_SERVERS,$DNS_S
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 n
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 f
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
Sasch
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 Toolki
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
> /build/relion-cuda-3.1.0/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o.NVCC
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 matching
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:
>
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
> Per
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 rules
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
(2021
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
.
+ * 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
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 situatio
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
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
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
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 wa
Hi,
has anyone taken any action here already? Some of my packages are
affected by this as well.
Cheers
Sascha
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 b
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
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 t
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
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
>>> /<>/.pybuild/cpyt
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 re
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: /usr/lib
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 far
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 mo
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 addi
> 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.
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
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 se
> 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)
>>
>>
>
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
> /usr/local/
27; option.
+
+ -- 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/patch
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
0 +0200
+++ 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
@@ -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, 0
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
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 (2.35.5
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 into
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 s
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 pbuilder/cowbuil
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.
Ch
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 n
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
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 signe
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 it
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 tha
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 th
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" deni
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 "/usr/lib/python3/dist-packages/
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 fail
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" <mailto
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:
>
> https://buildd.debian.org/status/fetch
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
>
> ...
> make check-TESTS
>
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
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 --
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)
>> /usr/lib/go-1.7/s
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 'override_dh_auto_config
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 00.Sam
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
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 whether
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.
Ch
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
> (/usr/share/texlive/texmf-dist/tex/l
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 that
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 install
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
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 file
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
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 d
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
a
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 c
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, w
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
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 b
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 -DHAVE_
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 commen
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 otherw
75e58607c5d13c027f55015c19a495e26d9f7712
Author: Sascha Steinbiss
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 @@
+princeprocessor (0.21-3
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: serious
> User: debian..
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 si
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&revision=22821
>
> This new version of the package solv
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:
> > On Thu, 1 Sep 2016 12:51
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 you
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 https://github.com/COMBINE-lab/salm
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:
>> /build/salmon-0.
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 libdivsuf
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 state
1 - 100 of 120 matches
Mail list logo