lv2 @1.10.0, lilv @0.20.0, serd @0.20.0, sord @0.12.2, sratom @0.4.6: new ports

[agraef (Albert Graef)]

These are all needed for LV2 plugin development (required, e.g., by the upcoming ports of pure-lv2 and pure-lilv).

LV2 is an open, cross-platform plugin standard similar in scope to VST(i) and AU. It's most popular on Linux right now, but works fine on the Mac and other *BSD systems as well. An overview of LV2 can be found at ​http://lv2plug.in/.

The LV2 headers themselves are in the lv2 package, the other modules are all helper libraries (maybe they should be renamed to liblilv, libserd, etc.?). The interdependencies are roughly like this:

lilv -> sratom -> sord -> serd, lilv -> lv2 <- sratom

I made it so that lv2 has a +plugins variant which optionally installs the sample plugins, since these aren't needed for normal development and pull in quite a few dependencies (libsndfile, gtk2, cairo).

[agraef (Albert Graef)]

lv2 Portfile

[agraef (Albert Graef)]

lilv Portfile

[agraef (Albert Graef)]

serd Portfile

[agraef (Albert Graef)]

sord Portfile

[agraef (Albert Graef)]

sratom Portfile

[dbevans (David B. Evans)]

Can you comment on the relationship between your proposed port lv2 and existing port lv2core? Is lv2 meant to be an upgrade/replacement for lv2core or is it something else altogether?

[agraef (Albert Graef)]

Yes, exactly, the ports provided here are the latest releases by Dave Robillard (lv2 supersedes lv2core, lilv supersedes slv2) and are required by all newer LV2 applications.

We should probably keep slv2 for legacy LV2 hosts which still need it, however. The only problem with that is that lv2core (dependency of slv2) and lv2 (dependency of lilv) conflict (they install mostly the same files in the same locations). The way this is resolved in Linux distributions like Ubuntu is that they make the old lv2core just a dummy package which pulls in the new lv2 instead. (slv2 should probably work fine with lv2 in lieu of lv2core, but I haven't tried that yet.)

If that doesn't seem feasible, then IMHO we should just keep both sets of ports and have the programmer decide whether he needs/wants one or the other.

[dbevans (David B. Evans)]

You should resolve this before the new ports can be committed.

If, in fact, slv2 will build with lv2 and doesn't conflict with lilv then changing its dependency should be sufficient. lv2core should be marked obsolete, replaced by lv2 using the ​obsolete PortGroup.

If port conflicts cannot be avoided then each of the conflicting ports (old and new) should be marked as such using the conflicts keyword such as

conflicts lv2core

Concerning maintainership, unless you have made an agreement with ryandesign to maintain the ports, I suggest that you add yourself as maintainer using the openmaintainer keyword since you do not have (as yet?) commit rights.

maintainers gmail.com:aggraef openmaintainer

I would be happy to give up maintainership of lv2core and slv2 in your favor since you have gone to the work and are much more up to speed on the current situation.

[agraef (Albert Graef)]

Replying to devans@…:

If, in fact, slv2 will build with lv2 and doesn't conflict with lilv then changing its dependency should be sufficient.

slv2 indeed builds fine against lv2 in lieu of lv2core, by just changing the dependency. Suggested changes to the slv2 Portfile attached. I can't really test it, though, as there seem to be no ports depending on slv2 in MacPorts right now; at least that's what port echo depends:slv2 says.

lv2core should be marked obsolete, replaced by lv2 using the ​obsolete PortGroup.

Ryan, could you (or someone else with commit rights) please take care of this, and of updating the slv2 port? Thanks.

Concerning maintainership, unless you have made an agreement with ryandesign to maintain the ports, I suggest that you add yourself as maintainer using the openmaintainer keyword since you do not have (as yet?) commit rights.

Ryan, what would you suggest? I'm fine with it either way.

I would be happy to give up maintainership of lv2core and slv2 in your favor since you have gone to the work and are much more up to speed on the current situation.

devans, I think that it makes more sense if you keep maintainership of the old packages if you're still using them, since I don't and I'm not really familiar with slv2 (although I do know the LV2 standard and Lilv pretty well).

Otherwise, if you don't want to keep maintainership, we should ask ourselves whether it makes sense to declare lv2core and slv2 as unmaintained and up for grabs (if that's possible in MacPorts), as they don't seem to be used anywhere. LV2 1.x and Lilv is where all the action is now, and has been for quite some time (at least since LV2 1.0 which came out in April 2012 IIRC). I'm not aware of any major LV2 host that still uses slv2 (in fact its list of dependents in Ubuntu 14.04 is empty as well, I just checked that). Of course, there might be some projects out there that still use slv2, you never know. But IMHO we can't keep on maintaining the old stuff forever, unless there's someone who has a real interest in them.

[agraef (Albert Graef)]

Suggested changes to slv2 Portfile to make it build against lv2 instead of lv2core

[dbevans (David B. Evans)]

Replying to aggraef@…:

we should ask ourselves whether it makes sense to declare lv2core and slv2 as unmaintained and up for grabs (if that's possible in MacPorts), as they don't seem to be used anywhere. LV2 1.x and Lilv is where all the action is now, and has been for quite some time (at least since LV2 1.0 which came out in April 2012 IIRC). I'm not aware of any major LV2 host that still uses slv2 (in fact its list of dependents in Ubuntu 14.04 is empty as well, I just checked that). Of course, there might be some projects out there that still use slv2, you never know. But IMHO we can't keep on maintaining the old stuff forever, unless there's someone who has a real interest in them.

I agree. Drobilla describes lilv as the improved successor to slv2, so I would propose to mark both lv2core and slv2 as obsolete, replaced by their respective successors, unless someone really wants to make a case for slv2.

[dbevans (David B. Evans)]

I'll commit these for you if you want to take maintainership of the ports. Otherwise, I'll wait for confirmation/action from ryandesign. Once they are committed, I'll make the appropriate changes to lv2core and slv2.

[agraef (Albert Graef)]

Replying to devans@…:

I'll commit these for you if you want to take maintainership of the ports.

Yes sure, please go ahead.

[ryandesign (Ryan Carsten Schmidt)]

FYI Dave, Dr. Graef is the creator of the Pure programming language and I've been working with him for years in regard to the pure ports in MacPorts, and now that he has a Mac he's becoming more active in MacPorts, but I haven't been involved with these new ports in this ticket. They look straightforward and I don't mind maintaining them, but it would also be a good opportunity for him to maintain some ports himself—or we could co-maintain them.

Dr. Graef, the implication of assuming maintainership of a port means that tickets about that port will be assigned to you, and you'll be expected to keep the port updated (by filing tickets and attaching patches, which a committer then checks and commits). I was going to ask you also about the pure ports: would you like to be listed as co-maintainer of those?

[dbevans (David B. Evans)]

Replying to ryandesign@…:

FYI Dave, Dr. Graef is the creator of the Pure programming language and I've been working with him for years in regard to the pure ports in MacPorts, and now that he has a Mac he's becoming more active in MacPorts, but I haven't been involved with these new ports in this ticket. They look straightforward and I don't mind maintaining them, but it would also be a good opportunity for him to maintain some ports himself—or we could co-maintain them.

Dr. Graef, the implication of assuming maintainership of a port means that tickets about that port will be assigned to you, and you'll be expected to keep the port updated (by filing tickets and attaching patches, which a committer then checks and commits). I was going to ask you also about the pure ports: would you like to be listed as co-maintainer of those?

Thanks for resolving my confusion, Ryan. I agree that Dr. Graef would make an excellent addition to our corps of maintainers/co-maintainers.

[dbevans (David B. Evans)]

Ports committed as follows:

• lv2 in r125884
• lv2core marked obsolete, replaced by lv2 in r125885
• serd in r125886
• sord in r125889
• sratom in r125891
• lilv in r125893
• slv2 marked obsolete, replaced by lilv in r125894

Minor issues:

• updated library dependencies where necessary
• asserting 'revision 0' is unnecessary as this is the default
• when using the waf Port Group, build dependencies should be declared using depends_build-append to avoid overriding the group's internal declaration of python27

Thanks for your submission and welcome to MacPorts!

[agraef (Albert Graef)]

Replying to ryandesign@…:

Dr. Graef, the implication of assuming maintainership of a port means that tickets about that port will be assigned to you, and you'll be expected to keep the port updated (by filing tickets and attaching patches, which a committer then checks and commits). I was going to ask you also about the pure ports: would you like to be listed as co-maintainer of those?

Yes, please go ahead. As many of my colleagues and students have Macs now and I want them to use those packages, I'm interested in keeping the ports updated in a timely manner anyway.

However, as you can see from the glitches in my ports, my understanding of MacPorts is rather limited. I'm also maintaining a bunch of Pure-related packages for Arch Linux and Ubuntu while doing basically all upstream development in Pure, so the time I have to dedicate to these tasks is limited as well. So I hope that you'll keep helping me with the OS X ports as you've kindly done for such a long time. :)

[agraef (Albert Graef)]

Replying to devans@…:

• asserting 'revision 0' is unnecessary as this is the default

Yes, I realize that it's redundant, but I thought that I might just as well keep it in there as a reminder that this is where I have to increment the revision number. ;-)

• when using the waf Port Group, build dependencies should be declared using depends_build-append to avoid overriding the group's internal declaration of python27

Ah, I didn't notice that. Thanks for committing!

[agraef (Albert Graef)]

Replying to devans@…:

• updated library dependencies where necessary

Hmm, I messed those up pretty badly, I'm afraid. The way that I'm testing new ports right now is to put them into my local ports repository and run port build portname. Is it possible to have port do this in a pristine MacPorts environment (kind of chrooted MacPorts installation) so that I can check the dependencies before the ports are submitted and checked by the buildbots?

[dbevans (David B. Evans)]

Replying to aggraef@…:

Replying to devans@…:

• updated library dependencies where necessary

Hmm, I messed those up pretty badly, I'm afraid. The way that I'm testing new ports right now is to put them into my local ports repository and run port build portname. Is it possible to have port do this in a pristine MacPorts environment (kind of chrooted MacPorts installation) so that I can check the dependencies before the ports are submitted and checked by the buildbots?

I noticed the issue by running

sudo port -d configure

on each port and examining the configure debug messages to see what dependencies were being checked.

You can simulate the way the buildbots work by doing something like this

sudo port deactivate active
sudo port configure

If you don't want to do this in your main MacPorts environment, then you can install a second (or more) MacPorts installation(s) for testing using different prefixes. See ​Install Multiple MacPorts Copies in the Guide.

Hope this helps.

[ryandesign (Ryan Carsten Schmidt)]

Sure, I'll continue to maintain the pure ports with you. I figure you'll appreciate being Cc'd on tickets so you're aware of any issues, and also so that if you have any patches or updates you want to contribute for these ports, other committers can address your tickets without needing to wait for my approval.

A less inconvenient way to identify missing dependencies is to try "trace mode":

sudo port -t install ...

This will do something like a chroot. Some ports may not work with trace mode yet.

[agraef (Albert Graef)]

Replying to devans@…:

If you don't want to do this in your main MacPorts environment, then you can install a second (or more) MacPorts installation(s) for testing using different prefixes. See ​Install Multiple MacPorts Copies in the Guide.

Thanks, I'm going to give this a try next time.

[agraef (Albert Graef)]

Replying to ryandesign@…:

Sure, I'll continue to maintain the pure ports with you. I figure you'll appreciate being Cc'd on tickets so you're aware of any issues, and also so that if you have any patches or updates you want to contribute for these ports, other committers can address your tickets without needing to wait for my approval.

Yes, thanks.

A less inconvenient way to identify missing dependencies is to try "trace mode":

I'm going to give this a shot as well, thanks.