Bug#1005011: lots of missing entries in debian/copyright
Tony, without commenting on severity and policy concerns I'm happy to have a first stab at this if you like. And seconding Tony, thank you for the detailed review Thorsten! On Sat, Feb 5, 2022 at 8:51 AM tony mancill wrote: > On Sat, Feb 05, 2022 at 12:08:03PM +, Thorsten Alteholz wrote: > > Package: capnproto > > please rework your debian/copyright. Especially > > Hi Thorsten, > > In my previous response, I neglected to say thank you for the thorough > review of the package and its debian/copyright. Thank you for the > effort and detail you put into these reviews! > > Regards, > tony > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
Bug#920230: Patch for your Git repository
Appreciate it Andreas, thank you. Working the NMU changes into a new release along with some other important changes that have come up. I'll look at moving things over to salsa.debian.org when time permits -- thanks for the suggestion. On Wed, Jan 30, 2019 at 12:21 AM Andreas Tille wrote: > Hi, > > I attached a commit for you Git repository to record the changes of my NMU. > BTW, it would be easier if you would decide to maintain capnproto on >https://salsa.debian.org/debian > > Hope this helps, Andreas. > > -- > http://fam-tille.de > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
Bug#873540: capnproto: FTBFS on mips64el: test.capnp wants AnyList::Pipeline
Thanks for the report Aaron, raised upstream at https://github.com/capnproto/capnproto/issues/541 I'll dig into it more later this week if upstream doesn't beat me to it. On Mon, Aug 28, 2017 at 1:01 PM, Aaron M. Ucko <u...@debian.org> wrote: > Source: capnproto > Version: 0.6.1-1 > Severity: serious > Tags: upstream > Justification: fails to build from source > > The latest mips64el build of capnproto failed, as detailed at > https://buildd.debian.org/status/fetch.php?pkg= > capnproto=mips64el=0.6.1-1=1503916947=0 > and (very briefly) excerpted below: > > src/capnp/test.capnp.h:12247:29: error: 'Pipeline' in 'struct > capnp::AnyList' does not name a type > inline ::capnp::AnyList::Pipeline getAnyListAsList(); >^~~~ > > AFAICT, there's not supposed to be any such type, so the problem > presumably lies in code generation. Could you please take a look? > Thanks! > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/ > finger/?a...@monk.mit.edu > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
Bug#826684: staden,spin: error when trying to install together
Thanks Andreas, appreciate you bringing this to my attention. Complicating this: we're still in the process of getting spin through the ITP/RFS process due to some licensing concerns with parts of the source package, I think the package may have been accidentally uploaded today instead of being rejected from the NEW queue. I'll follow up with the FTP folks to get a sense of what's going on and try to get this resolved as soon as I can. Keep you posted. On Tue, Jun 7, 2016 at 3:07 PM, Andreas Beckmann <a...@debian.org> wrote: > Package: staden,spin > Severity: serious > User: trei...@debian.org > Usertags: edos-file-overwrite > > Hi, > > automatic installation tests of packages that share a file and at the > same time do not conflict by their package dependency relationships has > detected the following problem: > > Selecting previously unselected package spin. > Preparing to unpack .../spin_6.4.5-1_amd64.deb ... > Unpacking spin (6.4.5-1) ... > dpkg: error processing archive > /var/cache/apt/archives/spin_6.4.5-1_amd64.deb (--unpack): >trying to overwrite '/usr/bin/spin', which is also in package staden > 2.0.0+b10-5 > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) > Errors were encountered while processing: >/var/cache/apt/archives/spin_6.4.5-1_amd64.deb > > This is a serious bug as it makes installation fail, and violates > sections 7.6.1 and 10.1 of the policy. An optimal solution would > consist in only one of the packages installing that file, and renaming > or removing the file in the other package. Depending on the > circumstances you might also consider Replace relations or file > diversions. If the conflicting situation cannot be resolved then, as a > last resort, the two packages have to declare a mutual > Conflict. Please take into account that Replaces, Conflicts and > diversions should only be used when packages provide different > implementations for the same functionality. > > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > usr/bin/spin > usr/share/man/man1/spin.1.gz > > This bug is assigned to both packages. If you, the maintainers of > the two packages in question, have agreed on which of the packages will > resolve the problem please reassign the bug to that package. You may > also register in the BTS that the other package is affected by the bug. > > Cheers, > > Andreas > > PS: for more information about the detection of file overwrite errors > of this kind see https://qa.debian.org/dose/file-overwrites.html > -- *Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>
Bug#777810: GCC 5 build issue
Will do Martin -- thank you! On Jun 25, 2015 9:55 AM, Martin Michlmayr t...@hp.com wrote: * Tom Lee m...@tomlee.co [2015-05-03 02:34]: Not sure if you're actively attempting test rebuilds every so often, but feel free to try for yourself when 0.5.2-1 hits unstable. I can confirm that the package in unstable builds fine with GCC 5. Tom, as the maintainer, I suggest you close this bug. -- Martin Michlmayr Linux for HP Helion OpenStack, Hewlett-Packard
Bug#788591: hiredis: FTBFS on powerpc
*)replies[i]) == 0' failed. See https://buildd.debian.org/status/fetch.php?pkg=hiredisarch=powerpcver=0.13.1-2stamp=1434137918 for a full log. Emilio -- Tom Lee / http://tomlee.co / @tglee -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785476: segfault when building against libhiredis0.13 due to vendored header files
Package: webdis
Version: 0.1.1-2
Severity: serious
Hello, I'm trying to transition the hiredis package from libhiredis0.10 to
libhiredis0.13, but some issues with the packaging (specifically the
vendored sources) of webdis are causing me some problems. Specifically, the
vendored hiredis and jansson headers are used instead of the headers from
libhiredis-dev and libjansson-dev.
The most noisy symptom is a segfault when building webdis against
libhiredis0.13, which gdb shows is pool_connect trying to call strlen(...)
on a null pointer:
(gdb) set follow-fork-mode child
(gdb) run /tmp/tmp.swHGJysNL5/webdis.json
Starting program: /home/tom/Source/debian/webdis-0.1.1/webdis
/tmp/tmp.swHGJysNL5/webdis.json
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New process 25152]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x76585700 (LWP 25153)]
[New Thread 0x75d84700 (LWP 25154)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x76585700 (LWP 25153)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x0040798f in pool_connect (p=0x623940, db_num=0,
attach=attach@entry=1) at pool.c:134
#2 0x004031a3 in worker_pool_connect (w=0x623b70, w=0x623b70) at
worker.c:133
#3 worker_main (p=0x623b70) at worker.c:153
#4 0x7715a0a4 in start_thread (arg=0x76585700) at
pthread_create.c:309
#5 0x76e8f04d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Stepping through gdb a little more carefully, we can trace the issue down
to the call out to redisAsyncConnectUnix in pool_connect.
Inside redisAsyncConnectUnix (all the way up until the final retq
instruction on amd64) the redisAsyncContext looks something like this:
p *ac
$4 = {c = {err = 1, errstr = No such file or directory, '\000' repeats
102 times, fd = -1, flags = 0,
obuf = 0x7f68 , reader = 0x7f80, connection_type =
REDIS_CONN_UNIX, timeout = 0x0, tcp = {
host = 0x0, source_addr = 0x0, port = 0}, unix_sock = {
path = 0x78c0 /tmp/tmp.ltIFMqN271/redis.sock}}, err = 1,
errstr = 0x700011e4 No such file or directory, data = 0x0, ev =
{data = 0x0, addRead = 0x0, delRead = 0x0,
addWrite = 0x0, delWrite = 0x0, cleanup = 0x0}, onDisconnect = 0x0,
onConnect = 0x0, replies = {head = 0x0,
tail = 0x0}, sub = {invalid = {head = 0x0, tail = 0x0}, channels =
0x7e80, patterns = 0x7ec0}}
*The moment the retq instruction in this function returns* the struct
layout changes in gdb (e.g. the connection_type field disappears):
p *ac
$6 = {c = {err = 1, errstr = No such file or directory, '\000' repeats
102 times, fd = -1, flags = 0,
obuf = 0x7f68 , reader = 0x7f80}, err = 1, errstr =
0x0, data = 0x0, ev = {data = 0x0,
addRead = 0x0, delRead = 0x78c0, addWrite = 0x1, delWrite =
0x700011e4, cleanup = 0x0},
onDisconnect = 0x0, onConnect = 0x0, replies = {head = 0x0, tail = 0x0},
sub = {invalid = {head = 0x0, tail = 0x0},
channels = 0x0, patterns = 0x0}}
So the layout of the redisContext struct used to build libhiredis-dev
0.13.1-1 differs from one used to build webdis. This can be explained by
the vendored headers can be further verified with strace when building
the package with gbp:
$ strace -e open -f -o ../strace.txt gbp buildpackage
--git-debian-branch=debian --git-upstream-branch=master
Any possibility you could sort that out? If it were up to me I'd use a
patch to blow away the vendored sources, but I'm not sure if that's the
best way to handle this sort of situation. gbp's support for filtering may
also be an option.
libhiredis0.13 and libhiredis-dev 0.13.1-1 have been uploaded to the
experimental distribution if you'd like to reproduce this for yourself.
Cheers,
Tom
--
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
] CharParsers.Number [ OK ] CharParsers.Number (0 ms) [ RUN ] CharParsers.DoubleQuotedString [ OK ] CharParsers.DoubleQuotedString (0 ms) [ RUN ] CharParsers.SingleQuotedString [ OK ] CharParsers.SingleQuotedString (0 ms) [--] 10 tests from CharParsers (1 ms total) [--] 4 tests from Blob [ RUN ] Blob.Text [ OK ] Blob.Text (0 ms) [ RUN ] Blob.Data [ OK ] Blob.Data (0 ms) [ RUN ] Blob.Compare [ OK ] Blob.Compare (0 ms) [ RUN ] Blob.StlInterop [ OK ] Blob.StlInterop (0 ms) [--] 4 tests from Blob (0 ms total) [--] 4 tests from Endian [ RUN ] Endian.Byte [ OK ] Endian.Byte (0 ms) [ RUN ] Endian.TwoBytes [ OK ] Endian.TwoBytes (0 ms) [ RUN ] Endian.FourBytes [ OK ] Endian.FourBytes (0 ms) [ RUN ] Endian.EightBytes [ OK ] Endian.EightBytes (0 ms) [--] 4 tests from Endian (1 ms total) [--] 4 tests from EndianUnoptimized [ RUN ] EndianUnoptimized.Byte [ OK ] EndianUnoptimized.Byte (0 ms) [ RUN ] EndianUnoptimized.TwoBytes [ OK ] EndianUnoptimized.TwoBytes (0 ms) [ RUN ] EndianUnoptimized.FourBytes [ OK ] EndianUnoptimized.FourBytes (0 ms) [ RUN ] EndianUnoptimized.EightBytes [ OK ] EndianUnoptimized.EightBytes (0 ms) [--] 4 tests from EndianUnoptimized (0 ms total) [--] 4 tests from EndianReverse [ RUN ] EndianReverse.Byte [ OK ] EndianReverse.Byte (0 ms) [ RUN ] EndianReverse.TwoBytes [ OK ] EndianReverse.TwoBytes (0 ms) [ RUN ] EndianReverse.FourBytes [ OK ] EndianReverse.FourBytes (0 ms) [ RUN ] EndianReverse.EightBytes [ OK ] EndianReverse.EightBytes (0 ms) [--] 4 tests from EndianReverse (1 ms total) [--] 5 tests from WireFormat [ RUN ] WireFormat.SimpleRawDataStruct [ OK ] WireFormat.SimpleRawDataStruct (0 ms) [ RUN ] WireFormat.StructRoundTrip_OneSegment [ OK ] WireFormat.StructRoundTrip_OneSegment (0 ms) [ RUN ] WireFormat.StructRoundTrip_OneSegmentPerAllocation [ OK ] WireFormat.StructRoundTrip_OneSegmentPerAllocation (0 ms) [ RUN ] WireFormat.StructRoundTrip_MultipleSegmentsWithMultipleAl locations [ OK ] WireFormat.StructRoundTrip_MultipleSegmentsWithMultipleAllocations (0 ms) [ RUN ] WireFormat.NanPatching [ OK ] WireFormat.NanPatching (0 ms) [--] 5 tests from WireFormat (0 ms total) [--] 1 test from Any [ RUN ] Any.AnyPointer [ OK ] Any.AnyPointer (1 ms) [--] 1 test from Any (1 ms total) [--] 1 test from Message [ RUN ] Message.MallocBuilderWithFirstSegment [ OK ] Message.MallocBuilderWithFirstSegment (0 ms) [--] 1 test from Message (0 ms total) [--] 14 tests from Capability [ RUN ] Capability.Basic [ OK ] Capability.Basic (1 ms) [ RUN ] Capability.Inheritance [ OK ] Capability.Inheritance (0 ms) [ RUN ] Capability.Pipelining [ OK ] Capability.Pipelining (1 ms) [ RUN ] Capability.TailCall [ OK ] Capability.TailCall (0 ms) [ RUN ] Capability.AsyncCancelation [ OK ] Capability.AsyncCancelation (0 ms) [ RUN ] Capability.DynamicClient [ OK ] Capability.DynamicClient (1 ms) [ RUN ] Capability.DynamicClientInheritance On Sun, Mar 29, 2015 at 11:01 PM, Niels Thykier ni...@thykier.net wrote: On 2015-03-30 04:30, Tom Lee wrote: Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Cheers, Tom [...] Hi Tom, I see no problem in adding a VERBOSE=1 (or --disable-silent-rules, or whatever), as it does not have an effect of the produced built. In fact, I am not aware of any other way to obtain the test-suite.log from the buildds. To my knowledge, the buildds more or less discards the build environment immediately after the build terminates. My best alternative is for you to get -guest access to a porterbox and try to reproduce it there[1]. It may take some time before you get such an account. It might make sense for you to try that in parallel with the build logs - just in case the build logs are not enough for you to fix the issue. DDs also have access to porterboxes, so you might also be able to convince your sponsor to help you with obtaining additional information from the porterbox. Though, in this case, you will probably want to stack up a few things to save a few roundtrips. Maybe something like: * Please build the package and which fail the tests * Extract test-build.log * Run the test via gdb and do a bt at the point
Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past
Hey Niels, Understood. Hard to see exactly what's going on here because we seem to be falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html. Do you happen to know if there's another way to get access to test-suite.log from these builds? The suggested work-around in that mailing list thread appears to require a change to the packaging, which I imagine we want to try and avoid. Cheers, Tom On Sun, Mar 29, 2015 at 4:45 AM, Niels Thykier ni...@thykier.net wrote: Source: capnproto Version: 0.4.1-3 Severity: serious Hi, It seems that the current version of capnproto FTBFS on armel and armhf due to a segmentation fault in one of the tests. This prevents the new version of migrating to testing as it is a regression compared to the version in testing. Thanks, ~Niels -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#780565: Integer overflow in pointer validation
Package: capnproto Version: 0.4.1-2 Severity: critical Upstream has reported a number of security issues in capnproto 0.4.1. Creating bugs to track these issues while I work on getting them fixed. This bug is tracking the Integer overflow in pointer validation bug reported on 2015-03-02. Full details + patch: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-0-c%2B%2B-integer-overflow.md -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#780568: CPU usage amplification attack #2
Package: capnproto Version: 0.4.1-2 Severity: critical Upstream has reported a number of security issues in capnproto 0.4.1. Creating bugs to track these issues while I work on getting them fixed. This bug is tracking the second CPU usage amplification attack bug reported on 2015-03-05. Full details + patch: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-05-0-c%2B%2B-addl-cpu-amplification.md -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#780567: CPU usage amplification attack
Package: capnproto Version: 0.4.1-2 Severity: critical Upstream has reported a number of security issues in capnproto 0.4.1. Creating bugs to track these issues while I work on getting them fixed. This bug is tracking the CPU usage amplification attack bug reported on 2015-03-02. Full details + patch: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-2-all-cpu-amplification.md -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#780566: Integer underflow in pointer validation
Package: capnproto Version: 0.4.1-2 Severity: critical Upstream has reported a number of security issues in capnproto 0.4.1. Creating bugs to track these issues while I work on getting them fixed. This bug is tracking the Integer underflow in pointer validation bug reported on 2015-03-02. Full details + patch: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-1-c%2B%2B-integer-underflow.md -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: no subject
Sorry, I probably haven't communicated my own inaction here. I've been holding off on an unblock request given a) this appears to be a bug in pbuilder, and b) we don't have a fix uploaded to unstable yet (which seems reasonable given `a`). The pbuilder bug has gone relatively quiet over the last few days too. Anyway: I've talked things over with jcristau (release team) and the suggestion is to reduce the severity of this bug to important, so it is no longer release-critical. On Thu, Dec 4, 2014 at 7:30 PM, Potter, Tim (Cloud Services) timothy.pot...@hp.com wrote: Hi everyone. I'm nervously following along with this bug since its presence is threatening the removal of a couple of dozen other packages as you can all probably see from the QA page. In the spirit of not hassling anyone (-: I was curious whether there was a plan to close this out? It sounds like a solution is very near, hopefully to the satisfaction of both the maintainers and release coordinators. Regards, Tim. -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: hiredis: FTBFS: Test failure
Alrighty, talking this over with Alessandro he made the case that we should keep tests that don't rely on *external *network connections. See e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753944 which makes the case for a loopback interface in pbuilder. Tobi, to that effect I modified your patch to keep the tests that work fine with localhost thus pass in pbuilder. Also, I feel like the serious severity is overstating the issue given that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed out the periodic rebuilds would have revealed this issue otherwise. If there are no objections I'd like to propose we adjust the severity of this bug to normal leave the fix for this particular bug until after the Jessie freeze. Otherwise, I can reach out to the release team to get the hiredis package unblocked work through getting a new package uploaded with the pbuilder fixes nocheck support. On Mon, Nov 24, 2014 at 4:32 AM, Tobias Frost t...@frost.de wrote: On Mon, 24 Nov 2014 00:45:04 -0800 Tom Lee deb...@tomlee.co wrote: Alrighty, patch applied pbuilder's clean. Now just waiting on Alessandro to review my changes push the package. On master here if you want to try things out in the interim: git:// anonscm.debian.org/collab-maint/hiredis.git Daniel, I also added support for DEB_BUILD_OPTS=nocheck since it caused you additional grief. Tobi, I haven't bothered addressing the pid file etc. in /tmp just yet, but I'll take a look at that sometime soon. Please remember we are in freeze: Both those changes are not covered by the freeze policy as they are not targeting RC bugs. As the DEB_BUILD_OPTIONS=nocheck is already committed, I suggest you ask on #debian-release if that they could accept this. The /tmp thing is unimportant now, and can be fixed for Stretch, (if you want to fix it) -- tobi -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: hiredis: FTBFS: Test failure
Talked this over with the release team on #debian-release, they agree it's a serious bug indicated that they'd prefer the fix to be something more along the lines of what Gregor is suggesting. I feel like the test should call out the fact it's skipped not passed, but otherwise imagine it would look the same. I'll open a bug against release.debian.org get this resolved -- thanks everyone! On Sun, Nov 30, 2014 at 10:17 AM, gregor herrmann gre...@debian.org wrote: On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote: On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote: Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee: Also, I feel like the serious severity is overstating the issue given that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed out the periodic rebuilds would have revealed this issue otherwise. If there are no objections I'd like to propose we adjust the severity of this bug to normal leave the fix for this particular bug until after the Jessie freeze. Here I can reprodcue the FTBFS locally with pbuilder 0.215+nmu3, so I disagree. It maybe has not been detected *yet*? What does this yet even mean? Except inside pbuilder, hiredis builds fine [1]. The fact that it fails *only* inside pbuilder (and the fact that hiredis is not the only package in this situation) suggests that this is indeed a pbuilder bug. I really don't see how this is release critical in any way on the part of the hiredis package. While I tend to agree in general, here's an additional data point: I rebuilt 0.11.0-4 in my sid amd64 cowbuilder chroot, which has USENETWORK=yes (due to #753944) but firewalls off everything except localhost during build. And in this environment I see a test failure: make check make[2]: Entering directory '/tmp/buildd/hiredis-0.11.0' echo \ daemonize yes\n \ pidfile /tmp/hiredis-test-redis.pid\n \ port 56379\n \ bind 127.0.0.1\n \ unixsocket /tmp/hiredis-test-redis.sock \ | redis-server - ./hiredis-test -h 127.0.0.1 -p 56379 -s /tmp/hiredis-test-redis.sock || \ ( kill `cat /tmp/hiredis-test-redis.pid` false ) #01 Format command without interpolation: PASSED #02 Format command with %s string interpolation: PASSED #03 Format command with %s and an empty string: PASSED #04 Format command with an empty string in between proper interpolations: PASSED #05 Format command with %b string interpolation: PASSED #06 Format command with %b and an empty string: PASSED #07 Format command with literal %: PASSED #08 Format command with printf-delegation (int): PASSED #09 Format command with printf-delegation (char): PASSED #10 Format command with printf-delegation (short): PASSED #11 Format command with printf-delegation (long): PASSED #12 Format command with printf-delegation (long long): PASSED #13 Format command with printf-delegation (unsigned int): PASSED #14 Format command with printf-delegation (unsigned char): PASSED #15 Format command with printf-delegation (unsigned short): PASSED #16 Format command with printf-delegation (unsigned long): PASSED #17 Format command with printf-delegation (unsigned long long): PASSED #18 Format command with printf-delegation (float): PASSED #19 Format command with printf-delegation (double): PASSED #20 Format command with invalid printf format: PASSED #21 Format command by passing argc/argv without lengths: PASSED #22 Format command by passing argc/argv with lengths: PASSED #23 Error handling in reply parser: PASSED #24 Memory cleanup in reply parser: PASSED #25 Set error on nested multi bulks with depth 7: PASSED #26 Works with NULL functions for reply: PASSED #27 Works when a single newline (\r\n) covers two calls to feed: PASSED #28 Don't reset state after protocol error: PASSED #29 Don't do empty allocation for empty multi bulk: PASSED #30 Returns error when host cannot be resolved: FAILED #31 Returns error when the unix socket path doesn't accept connections: PASSED [..] which seems to be the same as what Daniel originally reported. Adding a printf statement to test.c shows: #30 Returns error when host cannot be resolved: FAILED ERROR: Temporary failure in name resolution test.c currently looks for Name or service not known or Can't resolve: idontexist.local but not for what I get here ... Not sure what the best way forward is; adding a test for Temporary failure in name resolution might be an option (and works unsurprisingly): #v+ --- a/test.c +++ b/test.c @@ -286,7 +286,8 @@ c = redisConnect((char*)idontexist.local, 6379); test_cond(c-err == REDIS_ERR_OTHER (strcmp(c-errstr,Name or service not known) == 0 || - strcmp(c-errstr,Can't resolve: idontexist.local) == 0)); + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 || + strcmp(c-errstr,Temporary failure in name resolution) == 0)); redisFree(c
Bug#770648: hiredis: FTBFS: Test failure
D'oh :) There I go making assumptions. All the same, I feel like we can argue back and forth about the severity of this issue but we've got a potential fix ready to go. Might as well get the release team involved -- if we can arrange an unblock the whole issue is moot. On Sun, Nov 30, 2014 at 11:00 AM, gregor herrmann gre...@debian.org wrote: On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote: Talked this over with the release team on #debian-release, Except that noone who responded is a member of the release team :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Cat Stevens: I Love My Dog -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUe2l0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGscoQAJIK0qNAR4/HTYvVRo7barIC ZK9EombbjP8kK+iNoX2lAhDhawJgwEJ7fUOWtcjG4rjamYsSGI9HKB9abu7Brqhb nap+NS5NKFctfdQP2zSn9AXpu8TWwzdC73a5BOAs3Msr6T2BHcKX+e8xcdXj77xc FFtvcPUcFLzBtCxZA+wBrWWvPn+ZJAVIKhcoxf/85JFpfmbGyjHdwiwq9XoTgfHu f5esudD3UjSzYYDpMf1fgWbdfG3E1CDmbfNsuBMAmnp4TUUGlL5MiaFjIMggBk/f M8K9TuLah/I8/kTLNfoWjQ74+q6WJI3GySXPpHdmHny+wltY92gs0d7mea3pzov/ UiIMGUpO5kwX6CwL3mN9wFkhSbjEy6kBrUTBnDgXsH2ktGjn6bbjnDl8Tn++Idnz iLfDVStzlDtihg12zxT2gthoiFx7YcYFOlQSo6wxwDoOFUM0zJmuv1rov919UaQ4 5GJhHD4CWG1oFEn/s/7z+aOrjb39X2cF1OQa8FzqYTnmBTd+vwSLNNP4S2ipOKJU hTWb6cov7xpZwdxZJfOCzWX3PJEuxDHZZjLHWQy0QNdkeEJouEe6edMdb//tYQEk vDCplr7xZfcVbJ2ALz0uiKWyOaP48AB0r8MED7T1e8qwxEBp1LqS1AQA87NNsNgA G0q+Hrl4KbKUVI8I2RDO =6Enz -END PGP SIGNATURE- -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: hiredis: FTBFS: Test failure
Rather than add to the overhead of getting this change accepted, I'm going
to roll back the DEB_BUILD_OPTS=nocheck change given it's unrelated to this
bug (per the freeze policy
https://release.debian.org/jessie/freeze_policy.html). I'll roll it back in
after the freeze.
Proposed change to 0.11.0-4 looks like this:
$ debdiff ~/Source/hiredis_0.11.0-4.dsc ../hiredis_0.11.0-5.dsc
gpgv: Signature made Sun 30 Nov 2014 01:12:44 PM PST using RSA key ID
6C6608D1
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on
/home/tom/Source/debian/hiredis_0.11.0-5.dsc
diff -Nru hiredis-0.11.0/debian/changelog hiredis-0.11.0/debian/changelog
--- hiredis-0.11.0/debian/changelog 2014-10-03 20:30:13.0 -0700
+++ hiredis-0.11.0/debian/changelog 2014-11-30 13:09:15.0 -0800
@@ -1,3 +1,9 @@
+hiredis (0.11.0-5) unstable; urgency=medium
+
+ * Disable a network test failing in pbuilder (closes: #770648)
+
+ -- Tom Lee deb...@tomlee.co Mon, 24 Nov 2014 00:17:31 -0800
+
hiredis (0.11.0-4) unstable; urgency=medium
* Symlinks for cmake 3.0 (closes: #758548)
diff -Nru hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
--- hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
1969-12-31 16:00:00.0 -0800
+++ hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
2014-11-29 22:36:40.0 -0800
@@ -0,0 +1,25 @@
+Description: Disable Returns error when host cannot be resolved
+ This patch disables a test that relies on the presence of a
+ network connection.
+Author: Tobias Frost t...@debian.org
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/test.c
b/test.c
+@@ -282,12 +282,16 @@
+ static void test_blocking_connection_errors(void) {
+ redisContext *c;
+
++#if 0
+ test(Returns error when host cannot be resolved: );
+ c = redisConnect((char*)idontexist.local, 6379);
+ test_cond(c-err == REDIS_ERR_OTHER
+ (strcmp(c-errstr,Name or service not known) == 0 ||
+ strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
+ redisFree(c);
++#else
++test(SKIPPED: Returns error when host cannot be resolved\n);
++#endif
+
+ /*test(Returns error when the port is not open: );
+ c = redisConnect((char*)localhost, 1);
diff -Nru hiredis-0.11.0/debian/patches/series
hiredis-0.11.0/debian/patches/series
--- hiredis-0.11.0/debian/patches/series2014-10-03
20:30:13.0 -0700
+++ hiredis-0.11.0/debian/patches/series2014-11-24
00:11:32.0 -0800
@@ -1,3 +1,4 @@
01_use-proper-destdir.patch
02_disable-failing-test.patch
03_pkgconfig-cmake.patch
+04_disable-network-tests.patch
On Sun, Nov 30, 2014 at 12:59 PM, Tom Lee deb...@tomlee.co wrote:
D'oh :) There I go making assumptions.
All the same, I feel like we can argue back and forth about the severity
of this issue but we've got a potential fix ready to go. Might as well get
the release team involved -- if we can arrange an unblock the whole issue
is moot.
On Sun, Nov 30, 2014 at 11:00 AM, gregor herrmann gre...@debian.org
wrote:
On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote:
Talked this over with the release team on #debian-release,
Except that noone who responded is a member of the release team :)
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key
0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer -
http://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation
Europe
`- NP: Cat Stevens: I Love My Dog
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQJ8BAEBCgBmBQJUe2l0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGscoQAJIK0qNAR4/HTYvVRo7barIC
ZK9EombbjP8kK+iNoX2lAhDhawJgwEJ7fUOWtcjG4rjamYsSGI9HKB9abu7Brqhb
nap+NS5NKFctfdQP2zSn9AXpu8TWwzdC73a5BOAs3Msr6T2BHcKX+e8xcdXj77xc
FFtvcPUcFLzBtCxZA+wBrWWvPn+ZJAVIKhcoxf/85JFpfmbGyjHdwiwq9XoTgfHu
f5esudD3UjSzYYDpMf1fgWbdfG3E1CDmbfNsuBMAmnp4TUUGlL5MiaFjIMggBk/f
M8K9TuLah/I8/kTLNfoWjQ74+q6WJI3GySXPpHdmHny+wltY92gs0d7mea3pzov/
UiIMGUpO5kwX6CwL3mN9wFkhSbjEy6kBrUTBnDgXsH2ktGjn6bbjnDl8Tn++Idnz
iLfDVStzlDtihg12zxT2gthoiFx7YcYFOlQSo6wxwDoOFUM0zJmuv1rov919UaQ4
5GJhHD4CWG1oFEn/s/7z+aOrjb39X2cF1OQa8FzqYTnmBTd+vwSLNNP4S2ipOKJU
hTWb6cov7xpZwdxZJfOCzWX3PJEuxDHZZjLHWQy0QNdkeEJouEe6edMdb//tYQEk
vDCplr7xZfcVbJ2ALz0uiKWyOaP48AB0r8MED7T1e8qwxEBp1LqS1AQA87NNsNgA
G0q+Hrl4KbKUVI8I2RDO
=6Enz
-END PGP SIGNATURE-
--
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
--
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: hiredis: FTBFS: Test failure
On Sun, Nov 30, 2014 at 1:31 PM, Alessandro Ghedini gh...@debian.org wrote: This is, I think, the exact same problem as #759799 (which is btw severity: important). If the consensus is that this should be fixed in the affected packages (e.g. by disabling the tests), I'm all for it, but I really think that the effort should go into fixing pbuilder, since who knows how many packages are actually affected by this. Agreed, but I'm going to get the release team involved to get this sorted out given hiredis has been flagged for auto-removal in Jessie as a result of this bug. Specifically, I'm requesting an unblock for 0.11.0-5 alongside a request for clarification RE: the severity of this bug. I suspect they're going to need to see 0.11.0-5 in unstable to make the unblock happen, but if you like we can wait for them to comment on the unblock request. Not sure what the best way forward is; adding a test for Temporary failure in name resolution might be an option (and works unsurprisingly): #v+ --- a/test.c +++ b/test.c @@ -286,7 +286,8 @@ c = redisConnect((char*)idontexist.local, 6379); test_cond(c-err == REDIS_ERR_OTHER (strcmp(c-errstr,Name or service not known) == 0 || - strcmp(c-errstr,Can't resolve: idontexist.local) == 0)); + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 || + strcmp(c-errstr,Temporary failure in name resolution) == 0)); redisFree(c); /*test(Returns error when the port is not open: ); #v- But maybe there are better ways to fix this. That would make the test kinda useless, but I guess it's no worse than disabling it completely. I don't mind this approach if we call out the fact the test was skipped rather than silently passed, but at that point it's providing the same value as a test that's been completely disabled ... keeping Tobias' original patch for now. -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: hiredis: FTBFS: Test failure
it with USENETWORK=yes, which just makes the test take much longer to fail. It would also seem that the source package doesn't honor DEB_BUILD_OPTIONS=nocheck, which makes it difficult to disable the tests to get a package built despite the test failures. -- Daniel Schepler -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
Bug#770648: hiredis: FTBFS: Test failure
Thanks so much Daniel for the bug report Tobi for your patch. I'll get a new build together over the next day or so. Alessandro Ghedini has been pretty responsive wrt sponsoring my uploads, but I'll reach out if I can't get a hold of him. On Sun, Nov 23, 2014 at 2:52 AM, Tobias Frost t...@debian.org wrote: Package: src:hiredis Followup-For: Bug #770648 Dear Maintainer, As already mentioned by David, you must not use network when building the package, even lo might not be available. The attached patch disables the network-based tests. PS: The pid-file location hardcoded to /tmp looks weird.. Maybe should be patched to use $CURDIR or a relatie path ? If you want me to sponsor that upload, please ping me. -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee
