[bug#34758] [PATCH 1/4] gnu: Add libmirage.

[bug#34758] [PATCH 1/4] gnu: Add libmirage.

[Pierre Neidhardt]

* gnu/packages/cdrom.scm (libmirage): New variable.
---
 gnu/packages/cdrom.scm | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/cdrom.scm b/gnu/packages/cdrom.scm
index cdbe25fe4..846ce705b 100644
--- a/gnu/packages/cdrom.scm
+++ b/gnu/packages/cdrom.scm
@@ -860,3 +860,31 @@ Supported extensions to ISO 9660 are Rock Ridge, Joliet, AAIP, zisofs.")
 blanking CD-RW media, creating ISO-9660 file system images, extracting audio
 CD data, and more.  It's mostly compatible with @code{cdrtools}.")
     (license gpl2+)))
+
+(define-public libmirage
+  (package
+    (name "libmirage")
+    (version "3.2.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://downloads.sourceforge.net/cdemu/libmirage-"
+                    version ".tar.bz2"))
+              (sha256
+               (base32
+                "1ydph33sfxplp4872dp8ghp574jk5d4qr8hqz61qnznq1b11cnbr"))))
+    (build-system cmake-build-system)
+    (native-inputs
+     `(("pkg-config" ,pkg-config)
+       ("intltool" ,intltool)))
+    (inputs
+     `(("glib" ,glib)))
+    (arguments
+     ;; No tests.
+     '(#:tests? #f))
+    (home-page "https://cdemu.sourceforge.io/")
+    (synopsis "CD-ROM image (B6T/C2D/CCD/CDI/CIF/CUE/ISO/MDS/MDX/NRG/TOC) access library")
+    (description "libMirage is a CD-ROM image access library.  It is written
+in C and based on GLib.  Its aim is to provide uniform access to the data
+stored in various image formats.")
+    (license gpl2+)))
-- 
2.20.1

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Pierre Neidhardt]

* gnu/packages/cdrom.scm (vhba): New variable.
---
 gnu/packages/cdrom.scm | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/cdrom.scm b/gnu/packages/cdrom.scm
index 846ce705b..67b234e47 100644
--- a/gnu/packages/cdrom.scm
+++ b/gnu/packages/cdrom.scm
@@ -888,3 +888,31 @@ CD data, and more.  It's mostly compatible with @code{cdrtools}.")
 in C and based on GLib.  Its aim is to provide uniform access to the data
 stored in various image formats.")
     (license gpl2+)))
+
+(define-public vhba-module
+  (package
+    (name "vhba-module")
+    (version "20170610")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "http://downloads.sourceforge.net/cdemu/vhba-module-"
+                    version ".tar.bz2"))
+              (sha256
+               (base32
+                "1v6r0bgx0a65vlh36b1l2965xybngbpga6rp54k4z74xk0zwjw3r"))))
+    (build-system gnu-build-system)
+    (arguments
+     ;; TODO: No tests?
+     `(#:tests? #f
+       #:phases
+       (modify-phases %standard-phases
+         ;; TODO: Compress kernel modules?
+         ;; TODO: Build does not work because it needs the Makefile in
+         ;; /lib/modules/$(KERNELRELEASE)/build which we don't ship in Guix.
+         (delete 'configure))))
+    (home-page "https://cdemu.sourceforge.io/")
+    (synopsis "Kernel module that emulates SCSI devices")
+    (description "VHBA module provides a Virtual (SCSI) HBA, which is the link
+between the CDemu userspace daemon and linux kernel.")
+    (license gpl2+)))
-- 
2.20.1

[bug#34758] [PATCH 3/4] gnu: Add cdemu-daemon.

[Pierre Neidhardt]

* gnu/packages/cdrom.scm (cdemu-daemon): New variable.
---
 gnu/packages/cdrom.scm | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/gnu/packages/cdrom.scm b/gnu/packages/cdrom.scm
index 67b234e47..48d6f58a2 100644
--- a/gnu/packages/cdrom.scm
+++ b/gnu/packages/cdrom.scm
@@ -916,3 +916,32 @@ stored in various image formats.")
     (description "VHBA module provides a Virtual (SCSI) HBA, which is the link
 between the CDemu userspace daemon and linux kernel.")
     (license gpl2+)))
+
+(define-public cdemu-daemon
+  (package
+    (name "cdemu-daemon")
+    (version "3.2.1")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://downloads.sourceforge.net/cdemu/cdemu-daemon/cdemu-daemon-"
+                    version ".tar.bz2"))
+              (sha256
+               (base32
+                "171qqcziqgf6dd9n8xs9hc71krhjiyx9qr767s8znidyjj88hbc4"))))
+    (build-system cmake-build-system)
+    (native-inputs
+     `(("pkg-config" ,pkg-config)
+       ("intltool" ,intltool)))
+    (inputs
+     `(("libmirage" ,libmirage)
+       ("glib" ,glib)
+       ("ao" ,ao)))
+    (arguments
+     ;; No tests.
+     '(#:tests? #f))
+    (home-page "https://cdemu.sourceforge.io/")
+    (synopsis "CD/DVD-ROM device emulator")
+    (description "CDemu is a software suite designed to emulate an optical
+drive and disc (including CD-ROMs and DVD-ROMs).")
+    (license gpl2+)))
-- 
2.20.1

[bug#34758] [PATCH 4/4] gnu: Add cdemu-client.

[Pierre Neidhardt]

* gnu/packages/cdrom.scm (cdemu-client): New variable.
---
 gnu/packages/cdrom.scm | 49 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/gnu/packages/cdrom.scm b/gnu/packages/cdrom.scm
index 48d6f58a2..9fd3b9201 100644
--- a/gnu/packages/cdrom.scm
+++ b/gnu/packages/cdrom.scm
@@ -945,3 +945,52 @@ between the CDemu userspace daemon and linux kernel.")
     (description "CDemu is a software suite designed to emulate an optical
 drive and disc (including CD-ROMs and DVD-ROMs).")
     (license gpl2+)))
+
+(define-public cdemu-client
+  (package
+    (name "cdemu-client")
+    (version "3.2.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://downloads.sourceforge.net/cdemu/cdemu-client-"
+                    version ".tar.bz2"))
+              (sha256
+               (base32
+                "1zwz987pb2pakfk9kz8a6xa9hq1ip48cn4ryl9z85dik8k2sizm9"))))
+    (build-system cmake-build-system)
+    (native-inputs
+     `(("pkg-config" ,pkg-config)
+       ("intltool" ,intltool)))
+    (inputs
+     `(("python" ,python)
+       ("python-pygobject" ,python-pygobject)
+       ("cdemu-daemon" ,cdemu-daemon)))
+    (arguments
+     ;; No tests.
+     `(#:tests? #f
+       #:phases
+       (modify-phases %standard-phases
+         (add-after 'install 'patch-shebang
+           (lambda* (#:key outputs #:allow-other-keys)
+             (patch-shebang (string-append (assoc-ref outputs "out")
+                                           "/bin/cdemu"))
+             #t))
+         (add-after 'patch-shebang 'wrap-program
+           (lambda* (#:key outputs #:allow-other-keys)
+             (let ((prog (string-append (assoc-ref outputs "out")
+                                        "/bin/cdemu")))
+               (wrap-program prog
+                 `("PYTHONPATH" = (,(getenv "PYTHONPATH")))
+                 ;; `("GI_TYPELIB_PATH" = (,(getenv "GI_TYPELIB_PATH")))
+                 )
+               #t))))))
+    (home-page "https://cdemu.sourceforge.io/")
+    (synopsis "Command-line client for controlling cdemu-daemon")
+    (description "CDEmu client is a simple command-line client for controlling
+CDEmu daemon.
+
+It provides a way to perform the key tasks related to controlling the CDEmu
+daemon, such as loading and unloading devices, displaying devices' status and
+retrieving/setting devices' debug masks.")
+    (license gpl2+)))
-- 
2.20.1

[bug#34758] Acknowledgement ([PATCH 1/4] gnu: Add libmirage.)

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

libmirage, cdemu-daemon and cdemu-client seems to be fine.

The VHBA kernel module is not package properly and this a blocker for
cdemu-daemon.

1. This raises the more general issue of building kernel modules on Guix.

For the record, here is the VHBA makefile:

--8<---------------cut here---------------start------------->8---
VHBA_VERSION := 20170610

KERNELRELEASE ?= $(shell uname -r)
KDIR ?= /lib/modules/$(KERNELRELEASE)/build
PWD ?= $(shell pwd)

obj-m := vhba.o
ccflags-y := -DVHBA_VERSION=\"$(VHBA_VERSION)\" -Werror

default: modules
install: modules_install

modules modules_install clean:
	$(MAKE) -C $(KDIR) M=$(PWD) $@
--8<---------------cut here---------------end--------------->8---

As you can see, it relies on the Makefile (and probably a bunch of other
files) in /lib/modules/$(KERNELRELEASE)/build.

In our linux-libre package, "build" is a broken symlink, e.g. to
/tmp/guix-build-linux-libre-4.20.12.../linux-4.20.12.

Shouldn't we include this folder in the linux-libre package?  Without
it, I can't see how to build kernel modules.

Once we have this, we will be able to build vhba-module.



2. Next question: how do we load this module?  In `operating-system' we
have `initrd-modules', but in this case vhba is probably not needed in
the initrd.  What we really want, I think, is a union of kernel modules
in say

/run/booted-system/kernel/lib/modules/4.20.7/

Makes sense?

Thoughts?

--
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[bug#34758] [PATCH 1/4] gnu: Add libmirage.

[Ludovic Courtès]

Hello Pierre,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> * gnu/packages/cdrom.scm (libmirage): New variable.

[...]

> +              (uri (string-append
> +                    "https://downloads.sourceforge.net/cdemu/libmirage-"

Please use mirror://sourceforge instead (in the other patches as well).

> +    (home-page "https://cdemu.sourceforge.io/")
> +    (synopsis "CD-ROM image (B6T/C2D/CCD/CDI/CIF/CUE/ISO/MDS/MDX/NRG/TOC) access library")

I’d remove the list that’s in parentheses here.

Otherwise LGTM, thanks!

Ludo’.

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> * gnu/packages/cdrom.scm (vhba): New variable.

[...]

> +       (modify-phases %standard-phases
> +         ;; TODO: Compress kernel modules?
> +         ;; TODO: Build does not work because it needs the Makefile in
> +         ;; /lib/modules/$(KERNELRELEASE)/build which we don't ship in Guix.
> +         (delete 'configure))))

So it doesn’t build, right?  In that case I’d rather not add it.  :-)

It’s true that /build is a dangling link:

--8<---------------cut here---------------start------------->8---
$ readlink $(guix build linux-libre)/lib/modules/5.0.2-gnu/build
/tmp/guix-build-linux-libre-5.0.2.drv-0/linux-5.0.2
--8<---------------cut here---------------end--------------->8---

Ludo’.

[bug#34758] [PATCH 3/4] gnu: Add cdemu-daemon.

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> * gnu/packages/cdrom.scm (cdemu-daemon): New variable.

LGTM!

[bug#34758] [PATCH 4/4] gnu: Add cdemu-client.

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> * gnu/packages/cdrom.scm (cdemu-client): New variable.

[...]

> +         (add-after 'patch-shebang 'wrap-program
> +           (lambda* (#:key outputs #:allow-other-keys)
> +             (let ((prog (string-append (assoc-ref outputs "out")
> +                                        "/bin/cdemu")))
> +               (wrap-program prog
> +                 `("PYTHONPATH" = (,(getenv "PYTHONPATH")))
> +                 ;; `("GI_TYPELIB_PATH" = (,(getenv "GI_TYPELIB_PATH")))
> +                 )

What’s the story with GI_TYPELIB_PATH?

Otherwise LGTM, thanks!

Ludo’.

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

I should have explained a little bit more: the whole patchset makes no
sense (beside libmirage) without this kernel module.  CDEmu needs it or
it won't run.

This raises a general, important question: how do we build kernel
modules on guix?  At the moment, it seems that it's only possible by
re-building the kernel.

I suggest we add a "build" output to the kernel  that can be used as an
input to build kernel modules.  Maybe I should should an email to
guix-devel to ask for more opinions / advice. 

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[bug#34758] [PATCH 4/4] gnu: Add cdemu-client.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> What’s the story with GI_TYPELIB_PATH?

Hasty copy-pasting! ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

Also see my other email from Tue, 05 Mar 2019 18:44:25 +0100 in this thread.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Ludovic Courtès]

Hello,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> I should have explained a little bit more: the whole patchset makes no
> sense (beside libmirage) without this kernel module.  CDEmu needs it or
> it won't run.

Oh I see, I didn’t know that.

> This raises a general, important question: how do we build kernel
> modules on guix?  At the moment, it seems that it's only possible by
> re-building the kernel.

… or maybe just unpacking the kernel source so you have the makefile
snippet around?  Perhaps that’s enough?

I’m generally dubious about out-of-tree modules.  Given the way kernel
development works, we’re often talking about modules of poor quality, or
proprietary modules.  Do you know the reason this one is not in the main
tree?

> I suggest we add a "build" output to the kernel  that can be used as an
> input to build kernel modules.  Maybe I should should an email to
> guix-devel to ask for more opinions / advice. 

Yes, sounds like a good idea.

Thanks,
Ludo’.

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> This raises a general, important question: how do we build kernel
>> modules on guix?  At the moment, it seems that it's only possible by
>> re-building the kernel.
>
> … or maybe just unpacking the kernel source so you have the makefile
> snippet around?  Perhaps that’s enough?

Nope, because we need the "build" folder which is only available after
building the kernel.  Re-building the kernel just to build a module
sounds like a waste of time :p

> I’m generally dubious about out-of-tree modules.  Given the way kernel
> development works, we’re often talking about modules of poor quality, or
> proprietary modules.  Do you know the reason this one is not in the main
> tree?

I don't.  I'll investigate a bit.

Anyways, I think it's nice as a _free software distribution_ to make it
accessible to the user to build custom modules.

>> I suggest we add a "build" output to the kernel  that can be used as an
>> input to build kernel modules.  Maybe I should should an email to
>> guix-devel to ask for more opinions / advice. 
>
> Yes, sounds like a good idea.

Will do!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[bug#34758] [PATCH 2/4] gnu: Add vhba.

[Ludovic Courtès]

Hi,

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> This raises a general, important question: how do we build kernel
>>> modules on guix?  At the moment, it seems that it's only possible by
>>> re-building the kernel.
>>
>> … or maybe just unpacking the kernel source so you have the makefile
>> snippet around?  Perhaps that’s enough?
>
> Nope, because we need the "build" folder which is only available after
> building the kernel.  Re-building the kernel just to build a module
> sounds like a waste of time :p

I wasn’t suggesting a kernel rebuild.  I thought that perhaps it’s
enough to use the makefiles and build machinery directly from the kernel
source tree, without rebuilding the kernel itself.  Dunno if that’s possible.

>> I’m generally dubious about out-of-tree modules.  Given the way kernel
>> development works, we’re often talking about modules of poor quality, or
>> proprietary modules.  Do you know the reason this one is not in the main
>> tree?
>
> I don't.  I'll investigate a bit.
>
> Anyways, I think it's nice as a _free software distribution_ to make it
> accessible to the user to build custom modules.

I agree, no argument here.  :-)

Thanks,
Ludo’.