Re: hiredis FTBFS on sparc
On Tue, Nov 01, 2011 at 06:09:54PM +0100, Alessandro Ghedini wrote: On Mon, Oct 24, 2011 at 08:45:05PM +0200, Alessandro Ghedini wrote: Hi, the package hiredis is failing to build on sparc because of test failures and I can't understand why. The tests are run against a local redis instance listening on 127.0.0.1:6379 but on sparc the connections get refused: Testing against TCP connection (127.0.0.1:6379): Connection error: Connection refused make[2]: *** [test] Error 1 Given that sparc is the only architecture where this happens, I disabled the tests on it in the last upload, but I'd like to find a better solution if possible. Any clue on why this happens only on sparc? Am I doing something wrong? Full build logs at [0] and [1] (the package never built on sparc with the tests enabled). Thanks P.S. Please CC me since I'm not subscribed to this list. [0] https://buildd.debian.org/status/fetch.php?pkg=hiredisarch=sparcver=0.10.0-1stamp=1309300018 [1] https://buildd.debian.org/status/fetch.php?pkg=hiredisarch=sparcver=0.10.1-2stamp=1309770719 Ping? It happens because redis-server you are trying to test against dies with a segmentation fault on startup on sparc. I see the following in the redis-server.log: [3491] 03 Nov 19:37:36 # === Ooops! Redis 2.2.12 got signal: -10- === [3491] 03 Nov 19:37:36 # === Ooops! Redis 2.2.12 got signal: -11- === and in dmesg: [ 1826.573524] redis-server[3491]: segfault at 24 ip 0001cc70 (rpc 0001cc54) sp ffe7e6d8 error 30001 in redis-server[1+36000] Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003193940.ga3...@wooyd.org
Re: ruby1.9.1 migration to testing
On Sun, Oct 23, 2011 at 14:11:26 +0200, Lucas Nussbaum wrote: At this point, I'm confident that we can reach a (at least partially) working Ruby on kfreebsd, sparc and armel at some point. I'm less confident about ia64. Question: what should we do in the meantime? Options are: (1) keep 1.9.3~rc1-1 in unstable until all the issues are fixed. (2) build it with nocheck on ia64, sparc, kfreebsd, so that it can migrate. (3) disable test suite on ia64, sparc, kfreebsd until issues are fixed, so that it can migrate. (4) remove ruby1.9.1 binary packages on ia64, sparc, kfreebsd for now (not really an option due to the large number of reverse dependencies). The version in testing is also affected by most of those issues, and was uploaded by porters after a nocheck build on some architectures. My preference is 3,2,4,1 but I wanted to check with you before going forward. I don't think knowingly shipping a broken package is ok, which means 1 and 4 have my preference. I'm assuming the testsuite failures really mean ruby is broken on those archs; if the failures were for fringe features then my answer would probably be different. I'm also assuming the current version in testing works better; if not then there's no point keeping the newer one out because of this. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003202748.ge3...@radis.liafa.jussieu.fr
Re: ruby1.9.1 migration to testing
On 03/11/11 at 21:27 +0100, Julien Cristau wrote: On Sun, Oct 23, 2011 at 14:11:26 +0200, Lucas Nussbaum wrote: At this point, I'm confident that we can reach a (at least partially) working Ruby on kfreebsd, sparc and armel at some point. I'm less confident about ia64. Question: what should we do in the meantime? Options are: (1) keep 1.9.3~rc1-1 in unstable until all the issues are fixed. (2) build it with nocheck on ia64, sparc, kfreebsd, so that it can migrate. (3) disable test suite on ia64, sparc, kfreebsd until issues are fixed, so that it can migrate. (4) remove ruby1.9.1 binary packages on ia64, sparc, kfreebsd for now (not really an option due to the large number of reverse dependencies). The version in testing is also affected by most of those issues, and was uploaded by porters after a nocheck build on some architectures. My preference is 3,2,4,1 but I wanted to check with you before going forward. I don't think knowingly shipping a broken package is ok, which means 1 and 4 have my preference. I'm assuming the testsuite failures really mean ruby is broken on those archs; if the failures were for fringe features then my answer would probably be different. I'm also assuming the current version in testing works better; if not then there's no point keeping the newer one out because of this. Given I hadn't got a reply, I implemented (3) and uploaded 1.9.3.0-1 to unstable. I haven't checked very closely, but it's very unlikely that those problems are regressions, so keeping the testing version isn't a solution. Lucas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003205440.ga10...@xanadu.blop.info
