Re: Debian Archive architecture removals
On 05/05/15 at 09:17 +0200, Samuel Thibault wrote: > * Appearing on packages' and maintainers' PTS > pages like http://buildd.debian.org/bash and > https://buildd.debian.org/sthiba...@debian.org > > * Being considered as "second-class citizen" Note that our developer dashboards (DDPO, Tracker, DMD) are already widely able to pick and combine data from various sources. So as long as the debian-ports data is reliable and useful, I don't think that it would be a problem to expose it more prominently. For example, it would be fairly trivial to add a "TODO" in https://udd.debian.org/dmd/ or tracker.d.o when there's a package in d-p's unreleased suite _and_ a bug tagged 'hurd' in the BTS. (UDD already knows about all the needed data for that, and I would happily create a json export for tracker to use) - Lucas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505073156.ga6...@xanadu.blop.info
Re: Debian Archive architecture removals
On 04/05/15 at 18:04 +0800, Paul Wise wrote: > On Mon, May 4, 2015 at 5:48 PM, Cyril Brulebois wrote: > > Lucas Nussbaum (2015-05-04): > >> I'm wondering if we could find a way to accomodate those architectures > >> in an official way, while still limiting the impact on ftpmasters and > >> other teams. I'm not entirely clear on the status of debian-ports.org, > >> and of what the current downsides of using debian-ports are. Maybe it's > >> just about supporting and advertising debian-ports as Debian's official > >> way to host second-class architectures. Maybe there's more to it. What > >> are the current downsides of moving hurd-i386 and sparc to debian-ports? > > > > Last I heard about it, it was understaffed and infra was undersized + > > needed some changes to make it possible to grow. > > > > This was some time ago, so I've added admin@ to make sure we get updated > > intel on this topic. > > zumbi was working on moving debian-ports to debian.org infrastructure > and got some of it done (the website for instance). I asked him about > it on IRC and got this response: > > zumbi: this mail looks like it needs a status update re > ports.d.o https://lists.debian.org/20150504062822.ga24...@xanadu.blop.info > pabs: we had this: https://titanpad.com/debian-ports > pabs: I was hoping for debcamp/debconf to be able to finish it up > (however I am still unsure about if I'll be able to attend event) > zumbi: may I copy that into email or can you? > pabs: feel free to copy it > pabs: it needs someone with wanna-build database experience, > some dsa, aurel32 (and maybe some ftp-master) to complete the work That pad says: "As a result of current state, d-ports cannot accept more ports". If that's still true, it would make sense to postpone dropping hurd and sparc until this is fixed... Lucas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504104741.ga18...@xanadu.blop.info
Re: Debian Archive architecture removals
On 20/04/15 at 00:22 +0200, Joerg Jaspert wrote: > Hi, > > As the jessie release approaches, the ftp-team have been reviewing the > status of the architectures in unstable. > > Neither sparc nor hurd-i386 are going to release with jessie and we are > therefore looking at their future in unstable. > > > SPARC > = > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745938 > > Given the current lack of proper kernel support and the lack of upstream > toolchain support, we intend to remove sparc *at the latest*, three > months after the release of jessie. This could be avoided if there is a > team of Debian Developers putting in a serious effort to revive this > port, thus the 3 months timeframe. If this happens, please keep track in > an easy reviewable way, so we can recheck it before actual removal (for > example list of closed bugs, uploads, upstream patch work, ...). > > It is noted that the sparc64 port is likely to be a more suitable basis > for any future SPARC work but that nobody has approached us about > inclusion. > > hurd-i386 > = > Well before wheezy was released, we talked with the HURD porters, and > they agreed to re-check their archive status just after the wheezy > release[1]. The plan was to move the HURD port off ftp-master if it > wasn't included as a technology preview or full release arch. HURD > wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. > > We'll be removing HURD, as discussed, from the ftp-master archive after > the Jessie release. > > [1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html Hi, I fully understand that those architectures cause an additional load on ftpmasters (and various other teams). But I've always been very proud that Debian was able to accomodate a wide variety of architectures and kernels (even if I've not done much to achieve that). I find it sad that we will soon have to say "oh, and there are also people maintaining an unofficial Hurd port outside Debian". I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? Lucas signature.asc Description: Digital signature
Re: Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On 14/12/11 at 23:40 +0100, Jakub Wilk wrote: > Source: ruby1.8 > Version: 1.8.7.352-2 > Severity: serious > Justification: fails to build from source > User: debian-sparc@lists.debian.org > Usertags: sparc > > ruby1.8 FTBFS on sparc: > | ./sample/test.rb:1848: [BUG] Bus Error > | ruby 1.8.7 (2011-06-30 patchlevel 352) [sparc-linux] > | > | test failed > | make[1]: *** [test] Error 1 > | make[1]: Leaving directory > `/build/buildd-ruby1.8_1.8.7.352-2-sparc-NViQ1Z/ruby1.8-1.8.7.352' > | make: *** [debian/stamp-makefile-build] Error 2 > > Full build log: > https://buildd.debian.org/status/fetch.php?pkg=ruby1.8&arch=sparc&ver=1.8.7.352-2&stamp=1323883832 Hi debian-sparc@, Could someone take a look at this? It might be similar to #593138, #545345 and http://redmine.ruby-lang.org/issues/5244 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/20111219203057.ga29...@xanadu.blop.info
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
Re: ruby1.9.1 migration to testing
On 03/11/11 at 00:45 +, Jurij Smakov wrote: > > > [sparc] continuations are completely broken. > > > See http://redmine.ruby-lang.org/issues/5244 (minimal test case > > > included) > > > > Much progress on that, thanks to Jurij Smakov who also took it to the > > sparclinux list (thread at > > http://thread.gmane.org/gmane.linux.ports.sparc/15364). > > A partial fix has been commited upstream. I'm waiting for a final > > decision to backport it. > > FWIW, I've posted a patch which implements what I consider a proper > fix for this issue to the upstream bug. Since it's already closed and > Ruby bug tracker does not allow mere mortals to reopen, I'm not > even certain whether any of the upstream maintainers will notice it. Thanks a lot! I will monitor the bug and make sure it ends up in Ruby upstream and in the Debian package. 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/2003053145.ga9...@xanadu.blop.info
ruby1.9.1 migration to testing
Dear release team, ruby1.9.1 1.9.3~rc1-1 is ready to migrate on some architectures. The status on the others is a bit problematic. I'm commenting below on the state of the various issues. The original mail can be found at http://lists.debian.org/debian-sparc/2011/08/msg00038.html. On 29/08/11 at 23:48 +0200, Lucas Nussbaum wrote: > Ruby 1.9.3 is going to be released in september, and is a candidate for > the default ruby version in wheezy. A snapshot is available in > experimental. Now is an ideal time to work on porting issues and get the > fixes integrated upstream. Ruby has a fairly large test suite, which > makes finding problems easy, but exercises the threading library in > interesting ways. > > Most of the issues are reproducible by re-building the Debian package. > Use make && make test to get a shorter build. > > Here is the current complete list of issues I'm aware of. My time will > be very limited in the coming weeks, but I will try my best to provide > help. > > [armel,sparc] FTBFS due to miscompilation with -ftree-sra (inc. in -O3). > See http://bugs.debian.org/635126. > Currently worked-around by using -fno-tree-sra. > Other packages might be affected. > -> FIXED from ruby1.9.1's POV, but you really want to look at this >for other packages. Still fixed for Ruby thanks to the workaround. #635126 was downgraded to 'important' by a GCC co-maintainer. I disagree that miscompilations are not RC, but I'm not going to argue. > [armel] I've just seen that now that this one is fixed, the test suite > segfaults. > See > https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1&arch=armel&ver=1.9.3~preview1%2Bsvn33077-1&stamp=1314634969 > search for 'TestFiber#test_many_fibers'. > 'make test-all' to reproduce. Failures during test-all are currently not > fatal. The remaining ones needs more investigation, but I don't think > that they are arch-specific. I'd like to make test-all failures fatal at > some point. No progress on that. It's likely that the binary randomly breaks on armel. 1.9.3~rc1-1's testsuite didn't crash, but 1.9.3~rc1-3 (experimental) hanged. > [sparc] continuations are completely broken. > See http://redmine.ruby-lang.org/issues/5244 (minimal test case > included) Much progress on that, thanks to Jurij Smakov who also took it to the sparclinux list (thread at http://thread.gmane.org/gmane.linux.ports.sparc/15364). A partial fix has been commited upstream. I'm waiting for a final decision to backport it. > [ia64] crashes during test suite, linked to continuations according to > backtrace. > See http://redmine.ruby-lang.org/issues/5246. 'make test' to reproduce. > Might be related to the sparc problem above. No progress on that one. I don't think that the sparc fix will improve the situation on ia64, but maybe the issue is similar. > [kfreebsd] waitpid from threads problem > http://redmine.ruby-lang.org/issues/5239 > http://bugs.debian.org/639658 > Will add a patch in test suite runner to work-around this > -> FIXED from ruby1.9.1's POV. > > [kfreebsd] mmap() with MAP_STACK requires non-null first arg > http://redmine.ruby-lang.org/issues/5241 > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=158755 > patch will be applied upstream, added to Debian package in the meantime > -> FIXED from ruby1.9.1's POV. > > [kfreebsd] thread-related hangs > http://redmine.ruby-lang.org/issues/5240 > bisected the upstream commit. > Petr Salinger working on a fix, see > http://lists.debian.org/debian-bsd/2011/08/msg00180.html A patch has been submitted upstream by Petr Salinger, but it still needs some work. (btw, -bsd@ folks, there's a suggestion from upstream on http://redmine.ruby-lang.org/issues/5240 that was not answered). 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. 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/20111023121126.ga4...@xanadu.blop.info
status of ruby 1.9.1 wrt porting
Hi, Ruby 1.9.3 is going to be released in september, and is a candidate for the default ruby version in wheezy. A snapshot is available in experimental. Now is an ideal time to work on porting issues and get the fixes integrated upstream. Ruby has a fairly large test suite, which makes finding problems easy, but exercises the threading library in interesting ways. Most of the issues are reproducible by re-building the Debian package. Use make && make test to get a shorter build. Here is the current complete list of issues I'm aware of. My time will be very limited in the coming weeks, but I will try my best to provide help. [armel,sparc] FTBFS due to miscompilation with -ftree-sra (inc. in -O3). See http://bugs.debian.org/635126. Currently worked-around by using -fno-tree-sra. Other packages might be affected. -> FIXED from ruby1.9.1's POV, but you really want to look at this for other packages. [armel] I've just seen that now that this one is fixed, the test suite segfaults. See https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1&arch=armel&ver=1.9.3~preview1%2Bsvn33077-1&stamp=1314634969 search for 'TestFiber#test_many_fibers'. 'make test-all' to reproduce. Failures during test-all are currently not fatal. The remaining ones needs more investigation, but I don't think that they are arch-specific. I'd like to make test-all failures fatal at some point. [sparc] continuations are completely broken. See http://redmine.ruby-lang.org/issues/5244 (minimal test case included) [ia64] crashes during test suite, linked to continuations according to backtrace. See http://redmine.ruby-lang.org/issues/5246. 'make test' to reproduce. Might be related to the sparc problem above. [kfreebsd] waitpid from threads problem http://redmine.ruby-lang.org/issues/5239 http://bugs.debian.org/639658 Will add a patch in test suite runner to work-around this -> FIXED from ruby1.9.1's POV. [kfreebsd] mmap() with MAP_STACK requires non-null first arg http://redmine.ruby-lang.org/issues/5241 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=158755 patch will be applied upstream, added to Debian package in the meantime -> FIXED from ruby1.9.1's POV. [kfreebsd] thread-related hangs http://redmine.ruby-lang.org/issues/5240 bisected the upstream commit. Petr Salinger working on a fix, see http://lists.debian.org/debian-bsd/2011/08/msg00180.html I've just uploaded (to experimental) a new version fixing the issues marked FIXED. Thanks! - 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/20110829214834.ga2...@xanadu.blop.info
Re: [DRE-maint] Bug#591539: librmagick-ruby: FTBFS on sparc: ruby1.8: free(): invalid pointer
On 10/10/10 at 16:45 +0100, Adam D. Barratt wrote: > On Tue, 2010-08-03 at 15:39 -0400, Cyril Brulebois wrote: > > your package no longer builds on sparc: > > | /usr/bin/ruby1.8 -I > > /build/buildd-librmagick-ruby_2.13.1-1-sparc-DDHTOO/librmagick-ruby-2.13.1/./lib > > -I > > /build/buildd-librmagick-ruby_2.13.1-1-sparc-DDHTOO/librmagick-ruby-2.13.1/./ext/RMagick > > median_filter.rb (example 90 of 188) > > | *** glibc detected *** /usr/bin/ruby1.8: free(): invalid pointer: > > 0x7178 *** > [...] > > | 7170-71c28000 rw-p 00:00 0 > > | fff7c000-fffa6000 rw-p 00:00 0 > > [stack] > > | debian-setup.rb: Too many examples failed. Search for "Help!" > > at > > | http://rmagick.rubyforge.org/install-faq.html. > > | post-setup.rb: median_filter.rb example returned error code 6 > > | make: *** [install/librmagick-ruby1.8] Error 1 > > Ping? This is preventing the fix for #591152 from migrating. That's sparc-specific. Sparc porters, could you take a look? - 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/20101010162715.ga7...@xanadu.blop.info
Re: Bug#593138: ruby1.9.1: FTBFS on sparc: test suite hangs
On 15/08/10 at 19:57 +, brian m. carlson wrote: > On Sun, Aug 15, 2010 at 08:36:28PM +0200, Lucas Nussbaum wrote: > > Ruby's test suite (make test-all) hangs on sparc. I had to do a manual > > upload after disabling the test suite. > > Could you provide us with a log of the failing build? buildd.debian.org > doesn't have one, and it would be helpful to know exactly where the > problem occurred. I'll run a test build on my Ultra 5, but it's not > SMP, so it may not trigger the bug. I'll report back. Sorry, I didn't keep it, but it was reproducible on sperger.d.o. 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/20100815200508.ga8...@xanadu.blop.info
Bug#593138: ruby1.9.1: FTBFS on sparc: test suite hangs
Source: ruby1.9.1 Version: 1.9.2~svn28788-1 Severity: serious Ruby's test suite (make test-all) hangs on sparc. I had to do a manual upload after disabling the test suite. There's an history of sparc problems with ruby 1.9.*. See #545345 and #565765. Since it works fine on amd64, armel, i386, mips, mipsel, powerpc and s390, I believe this is an architecture-specific problem. Ruby's test suite is known to exercise threads in interesting ways. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100815183628.ga1...@xanadu.blop.info
Re: Bug#565765: ruby1.9.1: FTBFS on sparc
Hi, Outcome of the discussion on debian-qa@ about this issue: - ruby1.9.1 still fails on both lebrun and spontini - needs to be tried on smetana (porter box with the higher chances to reproduce the failure) Any help is welcomed... -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100221200833.ga27...@xanadu.blop.info
Bug#565765: ruby1.9.1: FTBFS on sparc
Package: src:ruby1.9.1 Version: 1.9.1.378-1 Severity: serious Hi, ruby1.9.1 FTBFS on sparc with the following error: > make[2]: Leaving directory > `/build/buildd-ruby1.9.1_1.9.1.378-1-sparc-KMvrBv/ruby1.9.1-1.9.1.378' > compiling bigdecimal > Aborted > make[1]: *** [mkmain.sh] Error 134 > make: *** [debian/stamp-makefile-build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 Also, we have #545345 (ruby1.9.1: test suite fails on sparc). For which upstream said (in the redmine bug) that Sparc is no supported. Sparc porters, could you help us investigate this? This is extremely worrying, because we still need to transition all ruby 1.9.0 packages to 1.9.1 (so we can drop 1.9.0) before the squeeze release. Not releasing ruby1.9.1 on sparc isn't really an option because of all the reverse-dependencies. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545345: ruby1.9.1: test suite fails on sparc
parc-linux/continuation.so 705a6000-705b4000 ---p 2000 09:03 707173 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/continuation.so 705b4000-705b6000 rwxp 09:03 707173 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/continuation.so 705b8000-705ba000 r-xp 09:03 707202 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/etc.so 705ba000-705ca000 ---p 2000 09:03 707202 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/etc.so 705ca000-705cc000 rwxp 2000 09:03 707202 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/etc.so 705cc000-705ce000 r-xp 09:03 707204 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/fiber.so 705ce000-705dc000 ---p 2000 09:03 707204 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/fiber.so 705dc000-705de000 rwxp 09:03 707204 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/fiber.so 705e-705e2000 r-xp 09:03 707122 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/euc_jp.so 705e2000-705f ---p 2000 09:03 707122 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/euc_jp.so 705f-705f2000 rwxp 09:03 707122 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/euc_jp.so 705f4000-705f6000 r-xp 09:03 707145 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/shift_jis.so 705f6000-70604000 ---p 2000 09:03 707145 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/shift_jis.so 70604000-70606000 rwxp 09:03 707145 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/shift_jis.so 70608000-7060a000 r-xp 09:03 707150 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/windows_1251.so 7060a000-70618000 ---p 2000 09:03 707150 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/windows_1251.so 70618000-7061a000 rwxp 09:03 707150 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/enc/windows_1251.so 7061c000-7061e000 r-xp 09:03 707203 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/fcntl.so 7061e000-7062c000 ---p 2000 09:03 707203 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/fcntl.so 7062c000-7062e000 rwxp 09:03 707203 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/fcntl.so 7063-70636000 r-xp 09:03 707264 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/stringio.so 70636000-70644000 ---p 6000 09:03 707264 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/stringio.so 70644000-70646000 rwxp 4000 09:03 707264 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/stringio.so 70648000-70654000 r-xp 09:03 707260 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/socket.so 70654000-70662000 ---p c000 09:03 707260 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/socket.so 70662000-70664000 rwxp a000 09:03 707260 /build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243/.ext/sparc-linux/socket.so 70664000-706e6000 rw-p 70664000 00:00 0 706e6000-706e8000 ---p 706e6000 00:00 0 706e8000-707e8000 rw-p 706e8000 00:00 0 707e8000-707ea000 ---p 707e8000 00:00 0 707ea000-70868000 rw-p 707ea000 00:00 0 ff9da000-ffa04000 rw-p 7fefffd6000 00:00 0 [stack] Aborted make[1]: *** [test-all] Error 134 TestArray#test_sample: make[1]: Leaving directory `/build/buildd-ruby1.9.1_1.9.1.243-1-sparc-OciaSc/ruby1.9.1-1.9.1.243' -- | Lucas Nussbaum | lu...@luc
