Description of problem: rubyripper writes "Scanning drive" and then does not proceed to show the track listing. However, strace shows rubyripper executed cdparanoia -vQ just fine. Version-Release number of selected component (if applicable): 1.8.6.399-5 How reproducible: 100% Steps to Reproduce: 1. insert CD inside appropriate drive 2. start rubyripper using the aforementioned drive Actual results: track listing not shown Expected results: track listing shown Additional info: x86_64 arch (tried self-compiled ruby and fedora binary), rubyripper 0.6.0rc2 11976 10:22:06.844873 write(2, "TOTAL 270476 [60:06.26] (aud"..., 40) = 40 <0.000012> 11976 10:22:06.844936 write(2, "\n", 1) = 1 <0.000013> 11976 10:22:06.844996 write(2, " ", 1) = 1 <0.000013> 11976 10:22:06.845054 write(2, "\n", 1) = 1 <0.000012> 11976 10:22:06.845114 close(4) = 0 <0.000012> 11976 10:22:06.845176 close(3) = 0 <0.000229> 11976 10:22:06.845471 exit_group(0) = ? 11975 10:22:06.845680 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 11976 <0.091059> 11975 10:22:06.845748 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000012> 11975 10:22:06.845804 --- SIGCHLD (Child exited) @ 0 (0) --- 11975 10:22:06.845835 wait4(-1, 0x7ffff0f0155c, WNOHANG, NULL) = -1 ECHILD (No child processes) <0.000011> 11975 10:22:06.845892 rt_sigreturn(0xffffffffffffffff) = 0 <0.000013> 11975 10:22:06.845949 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x30004337d0}, {0x445c60, [], SA_RESTORER, 0x30004337d0}, 8) = 0 <0.000012> 11975 10:22:06.846090 exit_group(0) = ? 11966 10:22:06.846311 <... poll resumed> ) = ? ERESTART_RESTARTBLOCK (To be restarted) <0.073322> 11966 10:22:06.846347 --- SIGCHLD (Child exited) @ 0 (0) --- 11966 10:22:06.846390 restart_syscall(<... resuming interrupted call ...>) = ? ERESTART_RESTARTBLOCK (To be restarted) <3.245671> 11966 10:22:10.092199 --- SIGINT (Interrupt) @ 0 (0) --- 11966 10:22:10.092311 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000014> 11966 10:22:10.092382 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 <0.000012> 11966 10:22:10.092448 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 <0.000012> 11966 10:22:10.092512 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 <0.000012> 11966 10:22:10.092599 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 <0.000011>
(Currently I am working for ruby 1.8.7) For 1.8.7p249: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8_7/io.c?r1=27957&r2=28203 I will check for ruby 1.8.6.x later.
(In reply to comment #1) > (Currently I am working for ruby 1.8.7) > For 1.8.7p249: > http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/branches/ruby_1_8_7/io.c?r1=27957&r2=28203 This patch doesn't seem to fix this issue for 1.8.6.399...
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
1.8.7.299-5.fc15 hangs in state "Analyzing files for mismatching chunks"
Someone fixed something, and ruby-1.8.7.352-2.fc17 + rubyripper 0.6.1 combination works OK.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping