Re: ruby1.9.1 migration to testing
[leaving only debian-sparc in the cc list]
On Sun, Oct 23, 2011 at 02:11:26PM +0200, Lucas Nussbaum wrote:
> 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
> 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.
> > [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
> (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
> To UNSUBSCRIBE, email to debian-release-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
> Archive: http://lists.debian.org/20111023121126.GA4461@xanadu.blop.info
Jurij Smakov firstname.lastname@example.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC