CDemu-0.8 hasn't worked out-of-the-box with latest Linux kernel for a long time... Userspace CDemu brings improvements like - stabler kernel driver, supporting HAL notifications etc. - all CD image reading done in userspace Reproducible: Always Steps to Reproduce:
Created attachment 135631 [details] app-cdr/vhba-module-2007.08.23.ebuild Kernel-side driver for userspace CDemu
Created attachment 135633 [details] app-cdr/libmirage-2007.08.23.ebuild Library for CD image reading
Created attachment 135634 [details] app-cdr/cdemu-daemon-2007.08.23.ebuild CDemu userspace daemon, which manages CD images
Created attachment 135635 [details] app-cdr/cdemu-daemon/files/cdemu-daemon.conf.d Configuration for cdemu-daemon rcscript
Created attachment 135637 [details] app-cdr/cdemu-daemon/files/cdemu-daemon.init.d Executable for cdemu-daemon rcscript
Created attachment 135638 [details] app-cdr/cdemu-client-2007.08.23 Command-line client to control cdemu-daemon
Created attachment 135639 [details] app-cdr/gcdemu-2007.08.23 GNOME applet and GUI to control cdemu-daemon
Everything compiles and seems to run great. Thanks for the ebuilds!
hi, works great here with amd64, so you can add ~amd64 to the keywords! hmm, could you add vhba-module as runtime depency to the daemon? and perhaps in the vhba ebuild a check for the kernel option BLK_DEV_SR...i first compiled vhba and my device just wasn't created in the /dev dir...after some minutes i recognized that i need the scsi cd module (SR, which i hadn't compiled...why ever ;) ). the problem i see is, that there's no error message in /var/log/messages or dmesg if sr isn't present. thank you! sebastian
Created attachment 137297 [details] app-cdr/vhba-module-2007.08.23.ebuild Check for CONFIG_BLK_DEV_SR before compiling.
Created attachment 137402 [details] app-cdr/cdemu-daemon-2007.08.23.ebuild Oh, duh... add app-cdr/vhba-module to DEPEND.
A small fix seems to be required in cdemu-daemon.init.d: start-stop-daemon needs --oknodo parameter or else this script fails.
Well, I was wrong. It's not --oknodo that solves any problem, cause in fact it does not. The probles came from /etc/conf.d file. CDEMUD_BACKEND=alsa should actually be CDEMUD_BACKEND=ALSA otherwise daemon fails. I'm not sure whether it's my problem with alsa or a case of wrong documentation.
*** Bug 203736 has been marked as a duplicate of this bug. ***
Hi, I've created my own ebuilds for cdemu-1.0.0 before I've seen and checked out yours ( see Bug 203736 ). Some ideas I had: - Maybe renaming the client to cdemu-1.0.0.ebuild would be convenient. This could avoid blockages with cdemu-0.8 and make updating easier. - cdemu-daemon could simply be named cdemud, like the executable. That's shorter and less confusing. - libmirage should have an useflag for advanced developer documentation, like it is provided in it's makefile. - libmirage also depends on >=sys-devel/flex-2.5.33 and sys-devel/bison . - The vhba module should create a new udev rule and group, so users can start the daemon themselves. This way the initscript and the new config file become redundant and alsa problems are avoided, too. Users can start their own daemons in local mode, which is more scalable and more close to intention of the documentation at http://cdemu.sourceforge.net/pkg_daemon.php. Alsa is automatically detected by the makefile of cdemu-daemon, so there's no need to change it's behaviour with useflags. - Some of your ebuilds are missing RDEPEND. - Why did you rename and repack the Sourceforge files? This will make updating more complicated Greetings, Jan
(In reply to comment #15) > Hi, > I've created my own ebuilds for cdemu-1.0.0 before I've seen and checked out > yours ( see Bug 203736 ). > Some ideas I had: > - Maybe renaming the client to cdemu-1.0.0.ebuild would be convenient. This > could avoid blockages with cdemu-0.8 and make updating easier. > - cdemu-daemon could simply be named cdemud, like the executable. That's > shorter and less confusing. > - libmirage should have an useflag for advanced developer documentation, like > it is provided in it's makefile. > - libmirage also depends on >=sys-devel/flex-2.5.33 and sys-devel/bison . Sounds reasonable. > - The vhba module should create a new udev rule and group, so users can start > the daemon themselves. This way the initscript and the new config file become > redundant and alsa problems are avoided, too. Users can start their own daemons > in local mode, which is more scalable and more close to intention of the > documentation at http://cdemu.sourceforge.net/pkg_daemon.php. Alsa is > automatically detected by the makefile of cdemu-daemon, so there's no need to > change it's behaviour with useflags. Ebuilds changing compilation behavior based on auto-detected options is a no-no. > - Some of your ebuilds are missing RDEPEND. Okay. I keep forgetting that it's "required" now. > - Why did you rename and repack the Sourceforge files? This will make updating > more complicated I didn't. That was the latest work of the upstream developer at the time. The Sourceforge files were finally brought up to date last week.
Created attachment 139813 [details] app-cdr/cdemu-1.0.0 ebuild (cdemu-client)
Created attachment 139815 [details] app-cdr/cdemud-1.0.0 ebuild (cdemu-daemon)
Created attachment 139817 [details] app-cdr/gcdemu-1.0.0 ebuild
Created attachment 139819 [details] dev-libs/libmirage-1.0.0 ebuild
Created attachment 139821 [details] sys-fs/vhba-1.0.0 ebuild
Created attachment 139822 [details] cdemu daemon init file (updated)
Created attachment 139823 [details] cdemu daemon config file (updated)
Updated all ebuilds as discussed before.
Comment on attachment 139823 [details] cdemu daemon config file (updated) ><HTML><HEAD/><BODY><PRE># Config file for /etc/init.d/cdemu-daemon > >CDEMUD_DEVICES=1 >#ifndef ALSA >CDEMUD_BACKEND=null >#else >CDEMUD_BACKEND=ALSA >CDEMUD_AUDIODEV=default >#endif ></PRE></BODY></HTML>
Created attachment 140056 [details] cdemud.conf.d alsa->ALSA fixed
Created attachment 140058 [details] cdemud.init.d alsa->ALSA fixed
Created attachment 140640 [details, diff] Patch for vhba makefile Patch for vhba-1.0.0 Makefile to use EXTRA_CFLAGS and correct MAKE value
Created attachment 140642 [details, diff] patch for vhba to work with kernel >= 2.6.23 This is my patch to make vhba-module compiled with kernel >= 2.6.23 with commit 18dabf473e15850c0dbc8ff13ac1e2806d542c15 If you got error like: error: 'struct scatterlist' has no member named 'page' then this patch is for you. Tested with kernel 2.6.24-rc4 on x86_64 arch
Created attachment 140643 [details] New vhba-1.0.0.ebuild with patchs This is a modified version of Jan Bessai's ebuild with patches applied.
One minor annoyance with 1.0.0 version, compared to 2007.08.23 versions. It's mentioned in the docs, but still blindsided me. If you run CDemud by initscript, now you have add `-b system` while calling cdemu. That was not needed before.
Paludis requires whitespace after ( in DEPEND, this is not met in libmirage-1.0.0.ebuild.
Created attachment 143207 [details] dev-libs/libmirage-1.0.0 ebuild - added whitespace to satisfy paludis Paludis requires whitespace after ( in DEPEND, this is not met in libmirage-1.0.0.ebuild. Sorry for double post, I'm new to using this bugzilla.
Compiling of the kernel module fails here with: >>> Compiling source in /var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0 ... * Preparing vhba module make -C /lib/modules/`uname -r`/build M=/var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0 clean make -C /lib/modules/`uname -r`/build M=/var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0 modules make[1]: Entering directory `/usr/src/linux-2.6.23-gentoo-r6' make[1]: Entering directory `/usr/src/linux-2.6.23-gentoo-r6' make[1]: Leaving directory `/usr/src/linux-2.6.23-gentoo-r6' rm -fr vhba-module-1.0.0 CC [M] /var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0/vhba.o /bin/sh: /var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0/.tmp_versions/vhba.mod: No such file or directory Building modules, stage 2. MODPOST 0 modules I'm trying the older ebuild now.
The older ebuild works fine.
Okay, not exactly fine, it installed the module into the wrong directory: # ls /lib/modules/ 2.6.19-gentoo-r5 2.6.23-gentoo-r6 block
And on a modprobe I get MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0. Bank 2: 940040000000017a scsi0 : vhba WARNING: at kernel/softirq.c:139 local_bh_enable() [<c0121ddd>] local_bh_enable+0x7d/0xa0 [<f8de80a1>] init_module+0x2450a1/0x245f70 [vhba] [<c02dada0>] scsi_done+0x0/0x20 [<f8de8de7>] init_module+0x245de7/0x245f70 [vhba] [<c02db2c4>] scsi_dispatch_cmd+0x104/0x250 [<c02e0497>] scsi_request_fn+0x177/0x330 [<c0227ef5>] __generic_unplug_device+0x25/0x30 [<c0227f5b>] blk_execute_rq_nowait+0x5b/0xc0 [<c0228026>] blk_execute_rq+0x66/0xc0 [<c0227430>] blk_end_sync_rq+0x0/0x30 [<c0230030>] cfq_set_request+0x0/0x330 [<c02dfea5>] scsi_execute+0xe5/0x120 [<c02dff59>] scsi_execute_req+0x79/0xf0 [<c02e1319>] scsi_probe_and_add_lun+0x1c9/0x940 [<c03f666f>] klist_add_tail+0xf/0x40 [<c02b0e0d>] device_add+0x3d/0x4b0 [<c02b02ae>] get_device+0xe/0x20 [<c02e1e01>] scsi_alloc_target+0x231/0x390 [<c02e2b3b>] __scsi_add_device+0xcb/0xd0 [<c02e2c18>] scsi_add_device+0x18/0x30 [<f8de8d78>] init_module+0x245d78/0x245f70 [vhba] [<f8de8ce0>] init_module+0x245ce0/0x245f70 [vhba] [<c012c060>] run_workqueue+0x80/0x130 [<c012c7e0>] worker_thread+0x0/0x100 [<c012c87d>] worker_thread+0x9d/0x100 [<c012f820>] autoremove_wake_function+0x0/0x50 [<c012c7e0>] worker_thread+0x0/0x100 [<c012f512>] kthread+0x42/0x70 [<c012f4d0>] kthread+0x0/0x70 [<c0104c6f>] kernel_thread_helper+0x7/0x18 ======================= scsi 0:0:0:0: CD-ROM CDEmu Virt. CD/DVD-ROM 0.01 PQ: 0 ANSI: 0 scsi 0:0:0:0: Attached scsi generic sg0 type 5 scsi 0:0:1:0: CD-ROM CDEmu Virt. CD/DVD-ROM 0.01 PQ: 0 ANSI: 0 scsi 0:0:1:0: Attached scsi generic sg1 type 5 And when I try to mount /dev/sg0 to /mnt/drive I get (after mounting an image with cdemu, this seems to work and cdemu status displays it correctly): mount: /dev/sg0 is not a block device
Previous error was caused by not having SCSI CD-ROM support in kernel, looks like the ebuild isn't verifying this correctly.
It does check that, it just warns instead of failing completely.
Hi, vhba, cdemud, cdemu and gcdemu working out of the Box with newest ebuilds. But I get a Kernel Warning if loading vhba (see below): Kernel is 2.6.23-tuxonice-r6, some CONFIG: CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_CHR_DEV_SG=y ------------------- Any Ideas on this warning? -------------------------- scsi4 : vhba WARNING: at kernel/softirq.c:139 local_bh_enable() [<c011de7a>] local_bh_enable+0x3c/0x8c [<f8e8806a>] 0xf8e8806a [<c0235352>] scsi_done+0x0/0x16 [<f8e88b2f>] 0xf8e88b2f [<c0235820>] scsi_dispatch_cmd+0x178/0x1c7 [<c0239d66>] scsi_request_fn+0x22f/0x2fb [<c01cffa8>] blk_remove_plug+0x4e/0x5a [<c01cffd1>] __generic_unplug_device+0x1d/0x1f [<c01d004e>] blk_execute_rq_nowait+0x7b/0x9f [<c01d00eb>] blk_execute_rq+0x79/0x93 [<c01cf6d8>] blk_end_sync_rq+0x0/0x23 [<c01d50c4>] cfq_set_request+0x0/0x302 [<c023947a>] scsi_execute+0xc8/0xdb [<c0239544>] scsi_execute_req+0xb7/0xd5 [<c023a56d>] scsi_probe_and_add_lun+0x1ab/0x7d3 [<c03118f0>] klist_add_tail+0xf/0x3f [<c023ce6e>] spi_device_match+0xa/0x4f [<c023295e>] attribute_container_device_trigger+0x7e/0x86 [<c0232bb7>] transport_setup_classdev+0x0/0x1a [<c01d7273>] kobject_get+0xf/0x13 [<c022e2f8>] get_device+0xe/0x14 [<c023af37>] scsi_alloc_target+0x299/0x347 [<f8e88a77>] 0xf8e88a77 [<c023b9a6>] __scsi_add_device+0x90/0xb3 [<c023ba87>] scsi_add_device+0x18/0x2a [<f8e88aeb>] 0xf8e88aeb [<c01262ff>] run_workqueue+0x8c/0x128 [<c01268f2>] worker_thread+0x0/0xbe [<c01269a4>] worker_thread+0xb2/0xbe [<c0128f37>] autoremove_wake_function+0x0/0x35 [<c0128e7e>] kthread+0x36/0x5c [<c0128e48>] kthread+0x0/0x5c [<c01048c7>] kernel_thread_helper+0x7/0x10 ======================= scsi 4:0:0:0: CD-ROM CDEmu Virt. CD/DVD-ROM 0.01 PQ: 0 ANSI: 0 sr1: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray sr 4:0:0:0: Attached scsi CD-ROM sr1
Created attachment 145284 [details] Patch to make vhba-1.0.0 compiled with kernel 2.6.25 Patch the following errors: /setup/work/cdemu-1.0/vhba-module-org/vhba.c:484: error: ‘struct scsi_cmnd’ has no member named ‘request_bufflen’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:488: error: ‘struct scsi_cmnd’ has no member named ‘request_bufflen’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:490: error: ‘struct scsi_cmnd’ has no member named ‘request_bufflen’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:491: error: ‘struct scsi_cmnd’ has no member named ‘request_bufflen’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:496: error: ‘struct scsi_cmnd’ has no member named ‘use_sg’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:500: error: ‘struct scsi_cmnd’ has no member named ‘request_buffer’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:510: error: ‘struct scsi_cmnd’ has no member named ‘use_sg’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:523: error: ‘struct scatterlist’ has no member named ‘page’ /setup/work/cdemu-1.0/vhba-module-org/vhba.c:537: error: ‘struct scsi_cmnd’ has no member named ‘request_buffer’
Created attachment 145286 [details] New ebuild for the scsi_cmnd patch (kernel 2.6.25) This ebuild uses scatterlist and scsicmnd patch, vhba now compiles with kernel 2.6.25
I'm using two patches for libmirage, see link below for details. http://sourceforge.net/mailarchive/forum.php?thread_name=47779E2D.3030201%40cs.tu-berlin.de&forum_name=cdemu-devel
There's one more thing that should be patched in Makefile. It uses `uname -r` to determine dir where module should be installed. In most cases it works just fine, but is broken i.e. when you run `module-rebuild rebuild`.
Created attachment 146241 [details] vhba ebuild, kernel version corrected This ebuild makes the module build with the correct kernel.
Hello guys, I cleaned up the ebuilds and added them to my overlay. http://dev.gentoo.org/~vanquirius/overlay/vanquirius Ebuilds: app-cdr/cdemu app-cdr/cdemud app-cdr/gcdemu dev-libs/libmirage sys-fs/vhba They all emerge and install fine. I am, however, having problems to get cdemu running properly. I start the cdemud daemon and here is what I get when I try to run cdemu: $ cdemu status ERROR: Failed to connect to CDEmu daemon: org.freedesktop.DBus.Error.ServiceUnknown: The name net.sf.cdemu.CDEMUD_Daemon was not provided by any .service files ERROR: Failed to connect to daemon!
*** Bug 209874 has been marked as a duplicate of this bug. ***
try cdemu -b system status/...
Marcelo: if you're interested in taking over all the cdemu packages (punting/whatever), feel free
Those patches for vhba still work for kernel 2.6.26-rc2.
Alright, got cdemu working fine in my box. I added dev-libs/libmirage, sys-fs/vhba, app-cdr/cdemud and app-cdr/gcdemu to the tree and bumped app-cdr/cdemu to 1.0.0 in cvs. amd64, hppa and ppc: given that there has been substantial change to cdemu, I dropped your keywords. If you would like, please test and re-add your keywords. Many thanks, Marcelo
*** Bug 159015 has been marked as a duplicate of this bug. ***
@Marcelo: I can confirm that this ebuild(s) work well on amd64. I use kernel version 2.6.24-gentoo-r3 .
cdemu is working fine on amd64 for me too. kernel 2-6.24-gentoo-r8
Confirming that cdemu(d)-1.0.0 with vhba-1.0.0 works on my amd64 system, with kernel 2.6.25 greetings Jan
*** Bug 227027 has been marked as a duplicate of this bug. ***
Same here. I think it's time to add ~amd64
Added ~amd64 keyword to all of them.
Thanks. Working beautifully here.
(In reply to comment #34) > Compiling of the kernel module fails here with: > > >>> Compiling source in /var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0 ... > * Preparing vhba module > make -C /lib/modules/`uname -r`/build > M=/var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0 clean > make -C /lib/modules/`uname -r`/build > M=/var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0 modules > make[1]: Entering directory `/usr/src/linux-2.6.23-gentoo-r6' > make[1]: Entering directory `/usr/src/linux-2.6.23-gentoo-r6' > make[1]: Leaving directory `/usr/src/linux-2.6.23-gentoo-r6' > rm -fr vhba-module-1.0.0 > CC [M] /var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0/vhba.o > /bin/sh: > /var/tmp/portage/sys-fs/vhba-1.0.0/work/vhba-module-1.0.0/.tmp_versions/vhba.mod: > No such file or directory > Building modules, stage 2. > MODPOST 0 modules > > I'm trying the older ebuild now. > I'm having the same problem on my x86_64 dualcore system. apparently, the module is cleaned after building, before it can be moved elsewhere, so the merging fails until "MAKEOPTS=-j1" is used. (-j3 is my system default)
Created attachment 159468 [details] Ebuild for sys-fs/vhba version 1.1.0 The new version (1.1.0) of cdemu has come out a few days ago. The new vhba module comes with a bash script to check the kernel version so we dont need to patch the module any more. All the other related packages like libmirage, cdemu, cdemud are just version bump so just change the ebuild file names will do.
There's a little patch to vhba on Sourceforge mailing list, that probably should be applied (http://sourceforge.net/mailarchive/forum.php?thread_name=4871427E.6060105%40kabelkaos.net&forum_name=cdemu-devel)
Two corrections: 1. that patch on the list is not quite correct, better to use the version that went into svn 2. cdemud ebuild needs some fixes: ALSA is now incorrect (it's alsa now), '-s' option for the deamon is no more, it uses libao now (and that's a hard dependency)
Thanks, vhba-1.1.0 in cvs. Rafał, would you mind posting the correct patch here? (Guys, for other cdemu issues, please open a new bug...) Cheers!
I'm getting this error now: CC [M] /var/tmp/portage/sys-fs/vhba-1.1.0/work/vhba-module-1.1.0/vhba.o /var/tmp/portage/sys-fs/vhba-1.1.0/work/vhba-module-1.1.0/vhba.c:35:24: error: kernel.api.h: No such file or directory It looks like it deletes this file, a coupe of lines before that: make[1]: Leaving directory `/usr/src/linux-2.6.25-gentoo-r4' rm -fr vhba-module-1.1.0 kernel.api.h
Created attachment 160539 [details, diff] fix kernel version detection Again, vhba-1.1.0 (the one in portage) doesn't compile against the proper kernel (always against the running one). I'm attaching a fixed ebuild. This one also does not check config options twice.
Created attachment 160544 [details, diff] svn-based patch Well, I used this patch. It worked with gentoo-sources 2.6.25-r4
Created attachment 160555 [details, diff] remove invasive api tester This patch removes the use of the invasive 'kat' api tester and instead adds a simple version check. The 'kat' way has a race condition in the build system and may cause a random compilation failure when using -j3. This makes the patch by Rafa? unneeded.
Created attachment 160556 [details] vhba 1.1.0 ebuild - kernel version detection, remove 'kat' this ebuild includes proper kernel version detection and also adds applying my previous patch that removes 'kat'
(In reply to comment #65) > I'm getting this error now: > > CC [M] /var/tmp/portage/sys-fs/vhba-1.1.0/work/vhba-module-1.1.0/vhba.o > /var/tmp/portage/sys-fs/vhba-1.1.0/work/vhba-module-1.1.0/vhba.c:35:24: error: > kernel.api.h: No such file or directory > > It looks like it deletes this file, a coupe of lines before that: > > make[1]: Leaving directory `/usr/src/linux-2.6.25-gentoo-r4' > rm -fr vhba-module-1.1.0 kernel.api.h > Same problem here. Using kernel gentoo-2.6.26. Stopping the the merge right after it deletes the file and copying it back from a backup, then resuming the merge works flawlessly.
W00t, didn't notice version 1.1.0 of cdemu is already out! Any news when we'll see that in portage? Greets, Tobias
(In reply to comment #71) > W00t, didn't notice version 1.1.0 of cdemu is already out! > > Any news when we'll see that in portage? > > Greets, > Tobias > Renaming the ebuilds above does the trick, but I had to change version 1.0.0 by ${PV} in the ebuild of gcdemu.
(In reply to comment #72) > Renaming the ebuilds above does the trick, but I had to change version 1.0.0 by > ${PV} in the ebuild of gcdemu. > Oops, it seems like I was too quick. Minor adjustments to be made. I used the gcdemu from portage and renamed it. I had to change the version from 1.0.0 to ${PV} but I also had to add before the line einfo: gnome2_pkg_postinst Also, the file /etc/init.d/cdemud had to be changed as options of cdemud apparently changed.
Created attachment 160982 [details] cdemud-init.d-v1.1.0 The /etc/init.d/cdemud file with changed options Please feel free to correct
I just want to mention that the Bug I speak about in Comment #40 is still there with new kernel and vhba, so I opened a new Bug: http://bugs.gentoo.org/show_bug.cgi?id=233102
In comment 63 I said that there's a hard dependency on libao now, but somehow people missed that when they added cdemud 1.1.0 to the tree.
Please file a keywording bug when all these problems have been ironed out.
These fixes have been here for months and are still not in portage. I suppose a new maintainer is needed?
This bug is dead. For keywording clone bug 300331 was created. If some problems reported here still exist in the recent versions of software, please, open new bug(s). This one is dead.
