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
Reply to: