GNU bug report logs - #40468
[PATCH 3/3] gnu: Add shiru-lv2.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40468 in the body.
You can then email your comments to 40468 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: Guix patches <guix-patches <at> gnu.org>
Subject: [PATCH 3/3] gnu: Add shiru-lv2.
Date: Mon, 06 Apr 2020 15:16:12 +0100

[Message part 1 (text/plain, inline)]

Hi,

This patch adds shiru plugins (unofficial LV2 port). No tag is
available yet and I'm using the date instead of a commit in the version
so new versions can be detected easily.

Thanks,
Alex

[0003-gnu-Add-shiru-lv2.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: 40468 <at> debbugs.gnu.org
Subject: Re: [PATCH 3/3] gnu: Add shiru-lv2.
Date: Mon, 06 Apr 2020 22:28:35 +0100

[Message part 1 (text/plain, inline)]

Reattaching the patch with versioning according to 
https://guix.gnu.org/manual/en/html_node/Version-Numbers.html#Version-Numbers

[0003-gnu-Add-shiru-lv2.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Alexandros Theodotou <alex <at> zrythm.org>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Tue, 7 Apr 2020 14:25:11 -0400

On Mon, Apr 06, 2020 at 10:28:35PM +0100, Alexandros Theodotou wrote:
> * gnu/packages/music.scm (shiru-lv2): New variable.

Thanks!

> +(define-public shiru-lv2
> +  (let ((commit "08853f99140012234649e67e5647906fda74f6cc")
> +        (revision "1"))
> +    (package/inherit dragonfly-reverb

If inheriting, we should use the regular inherit procedure, like this:

(package
  (inherit dragonfly-reverb)
  ...)

package/inherit is for special cases related to grafting and replacement
packages. [0]

Anyways, it looks like the inherited fields are build-system,
native-inputs, and arguments. Is the idea that there is some build
complication common to the LV2 plugins that we don't want to copy
around? Maybe we could make a build system for them.

Does it work to inherit the custom install phase from dragonfly-reverb?
It seems like the install-file procedures would not apply here.

What do you think? Sorry if I've missed something.

[0]
https://guix.gnu.org/manual/en/html_node/Security-Updates.html

Message #14 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Tue, 07 Apr 2020 20:09:31 +0100

[Message part 1 (text/plain, inline)]

Hi Leo,

> package/inherit is for special cases related to grafting and
> replacement
> packages. [0]

Thank you, I initially thought it was just a shorthand.

> Is the idea that there is some build
> complication common to the LV2 plugins that we don't want to copy
> around? Maybe we could make a build system for them.
>
> Does it work to inherit the custom install phase from dragonfly-
> reverb?
> It seems like the install-file procedures would not apply here.

Plugins that use the DISTRHO plugin framework (
https://github.com/DISTRHO/DPF) use the same build/install procedure,
unless the author makes changes to the Makefiles (like in the case of
the zam-plugins package). Dragonfly reverb and shiru plugins both use
DPF as-is, so the build/install procedures are exactly the same - built
plugins will be produced inside "bin" as binaries, lv2 plugins and vst
plugins.

There are more DPF-based plugins I plan to package that leave the the
DPF Makefiles as-is so I thought inheriting from dragonfly-reverb would
be a nice way to do it.

Thanks,
Alex

On Tue, 2020-04-07 at 14:25 -0400, Leo Famulari wrote:
> On Mon, Apr 06, 2020 at 10:28:35PM +0100, Alexandros Theodotou wrote:
> > * gnu/packages/music.scm (shiru-lv2): New variable.
> 
> Thanks!
> 
> > +(define-public shiru-lv2
> > +  (let ((commit "08853f99140012234649e67e5647906fda74f6cc")
> > +        (revision "1"))
> > +    (package/inherit dragonfly-reverb
> 
> If inheriting, we should use the regular inherit procedure, like
> this:
> 
> (package
>   (inherit dragonfly-reverb)
>   ...)
> 
> package/inherit is for special cases related to grafting and
> replacement
> packages. [0]
> 
> Anyways, it looks like the inherited fields are build-system,
> native-inputs, and arguments. Is the idea that there is some build
> complication common to the LV2 plugins that we don't want to copy
> around? Maybe we could make a build system for them.
> 
> Does it work to inherit the custom install phase from dragonfly-
> reverb?
> It seems like the install-file procedures would not apply here.
> 
> What do you think? Sorry if I've missed something.
> 
> [0]
> https://guix.gnu.org/manual/en/html_node/Security-Updates.html

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Alexandros Theodotou <alex <at> zrythm.org>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Tue, 7 Apr 2020 15:41:38 -0400

[Message part 1 (text/plain, inline)]

On Tue, Apr 07, 2020 at 08:09:31PM +0100, Alexandros Theodotou wrote:
> Plugins that use the DISTRHO plugin framework (
> https://github.com/DISTRHO/DPF) use the same build/install procedure,
> unless the author makes changes to the Makefiles (like in the case of
> the zam-plugins package). Dragonfly reverb and shiru plugins both use
> DPF as-is, so the build/install procedures are exactly the same - built
> plugins will be produced inside "bin" as binaries, lv2 plugins and vst
> plugins.
> 
> There are more DPF-based plugins I plan to package that leave the the
> DPF Makefiles as-is so I thought inheriting from dragonfly-reverb would
> be a nice way to do it.

Okay, feel free to write the packages in whatever way works for you.

> > Does it work to inherit the custom install phase from dragonfly-
> > reverb?
> > It seems like the install-file procedures would not apply here.

However, I tried building it from the patch and the install phase does
fail there.

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Tue, 07 Apr 2020 21:04:40 +0100

[Message part 1 (text/plain, inline)]

> > > Does it work to inherit the custom install phase from dragonfly-
> > > reverb?
> > > It seems like the install-file procedures would not apply here.
> 
> However, I tried building it from the patch and the install phase
> does
> fail there.

Did you build it after applying the previous 2 patches? 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40466 and
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40467

This is supposed to be merged after those changes. The first patch
(40466) changes the install procedure in dragonfly-reverb, which is
inherited here.

[signature.asc (application/pgp-signature, inline)]

Message #23 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Alexandros Theodotou <alex <at> zrythm.org>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Tue, 7 Apr 2020 16:08:55 -0400

On Tue, Apr 07, 2020 at 09:04:40PM +0100, Alexandros Theodotou wrote:
> > > > Does it work to inherit the custom install phase from dragonfly-
> > > > reverb?
> > > > It seems like the install-file procedures would not apply here.
> > 
> > However, I tried building it from the patch and the install phase
> > does
> > fail there.
> 
> Did you build it after applying the previous 2 patches? 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40466 and
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40467
> 
> This is supposed to be merged after those changes. The first patch
> (40466) changes the install procedure in dragonfly-reverb, which is
> inherited here.

Ah, no, I didn't realize they were related.

It's annoyingly tricky, but patches that depend on each should be in the
same bug ticket. This can be accomplished by first sending an intro
message to get a bug number, then sending the patch series to e.g.
<NNN <at> debbugs.gnu.org>.

I'll merge them now.

Message #28 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Tue, 07 Apr 2020 21:14:39 +0100

[Message part 1 (text/plain, inline)]

> It's annoyingly tricky, but patches that depend on each should be in
> the
> same bug ticket. This can be accomplished by first sending an intro
> message to get a bug number, then sending the patch series to e.g.
> <NNN <at> debbugs.gnu.org>.
> 
> I'll merge them now.

Ah okay, thank you for letting me know. I'll send such patches in the
same ticket from now on.

Thanks,
Alex

[signature.asc (application/pgp-signature, inline)]

Message #31 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Alexandros Theodotou <alex <at> zrythm.org>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Wed, 8 Apr 2020 11:41:55 -0400

On Tue, Apr 07, 2020 at 09:04:40PM +0100, Alexandros Theodotou wrote:
> This is supposed to be merged after those changes. The first patch
> (40466) changes the install procedure in dragonfly-reverb, which is
> inherited here.

In general, I think that using syntactic inheritance to factorize build
phases is not the right way to go here. It can cause a big headache
later when the time comes to adjust things, and it removes the
advantages of Guix tools such as `guix graph` and `guix refresh`.

I think the better options are to create a new lv2-build-system that
inherits from gnu-build-system and replaces the install phase, or to
just copy and paste the code around. It depends on how many of these
packages we plan to add.

Let me know if you need help with any of that! The font-build-system is
a concise example of making a new build system based on the
gnu-build-system.

Message #34 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Wed, 08 Apr 2020 16:58:26 +0100

[Message part 1 (text/plain, inline)]

I'd say the eventual amount of packages that would use such a build
system are between 5-10. Should I go ahead and make a dpf-build-system
or do you think we should just copy the code around since it's not that
many packages?

By the way, we used inheritance in the case of other packages such as
gx-* and vl1-emulator/regrader/fogpad, although those are from the same
upstream so maybe it's reasonable there.

On Wed, 2020-04-08 at 11:41 -0400, Leo Famulari wrote:
> On Tue, Apr 07, 2020 at 09:04:40PM +0100, Alexandros Theodotou wrote:
> > This is supposed to be merged after those changes. The first patch
> > (40466) changes the install procedure in dragonfly-reverb, which is
> > inherited here.
> 
> In general, I think that using syntactic inheritance to factorize
> build
> phases is not the right way to go here. It can cause a big headache
> later when the time comes to adjust things, and it removes the
> advantages of Guix tools such as `guix graph` and `guix refresh`.
> 
> I think the better options are to create a new lv2-build-system that
> inherits from gnu-build-system and replaces the install phase, or to
> just copy and paste the code around. It depends on how many of these
> packages we plan to add.
> 
> Let me know if you need help with any of that! The font-build-system
> is
> a concise example of making a new build system based on the
> gnu-build-system.

[signature.asc (application/pgp-signature, inline)]

Message #37 received at 40468 <at> debbugs.gnu.org (full text, mbox):

From: Alexandros Theodotou <alex <at> zrythm.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 40468 <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Wed, 08 Apr 2020 17:34:06 +0100

[Message part 1 (text/plain, inline)]

I went ahead and removed the inheritance for now and copied the
procedure. I guess we can see in the future if it's necessary to add a
build system or not.

Patch attached.

Thanks,
Alex

[0001-gnu-Add-shiru-lv2.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 40468-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Alexandros Theodotou <alex <at> zrythm.org>
Cc: 40468-done <at> debbugs.gnu.org
Subject: Re: [bug#40468] [PATCH 3/3] gnu: Add shiru-lv2.
Date: Thu, 28 May 2020 21:41:14 -0400

[Message part 1 (text/plain, inline)]

On Wed, Apr 08, 2020 at 05:34:06PM +0100, Alexandros Theodotou wrote:
> * gnu/packages/music.scm (shiru-lv2): New variable.

Thank you! And sorry for the delay...

Pushed as d870fcfb099cf5b0ad25220e1fa36162cc3284a5

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.