Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 814040 - LV2 1.0.0 released
Summary: LV2 1.0.0 released
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lv2core
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anthony Green
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 814542
Blocks: FedoraAudio
TreeView+ depends on / blocked
 
Reported: 2012-04-19 05:24 UTC by Brendan Jones
Modified: 2012-05-28 01:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-28 01:18:04 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
What the new spec may look like (2.10 KB, text/x-rpm-spec)
2012-04-20 03:00 UTC, Brendan Jones 		no flags Details
View All

Description Brendan Jones 2012-04-19 05:24:23 UTC 
Hi,

you may not have seen the announcement below, but the LV2 team has released a meta-package of the LV2 spec.

This basically encompasses all of the LV2 spec 'bundles' into one package, making it much easier to package removing the need to create >15 packages which contain only a directory, header file and TTL file. It also packages what we now package as lv2core. I think this is a great thing - I along with some others pushed for something like this to happen while the adoption of the LV2 spec extensions is still small. Developers up until now have tended to bundle the headers rather than rely on pkg-config. 

I propose creating a new package LV2 that obsolotes/provides lv2core (along with the few spec bundles that I have already packaged).

Packaging does not seem to be too much of an issue, in fact using the lv2core spec file as a base, the only real differences (on first looks) are the files section and the obsoletes/provides statement.

lv2.spec
<snip>
%files
%doc COPYING NEWS README
%{_libdir}/%{name}/
%exclude %{_libdir}/%{name}/*/*.h

%files devel
%{_includedir}/%{name}.h
%{_includedir}/%{name}/
%{_libdir}/%{name}/*/*.h
%{_libdir}/pkgconfig/lv2core.pc
%{_libdir}/pkgconfig/%{name}.pc

What do you think, is this approach reasonable? We would have to modify all packages that use lv2core (happy to do it). If so, were should we start F16/f17/F18?

Brendan

-------- Original Message --------
Subject: [LV2] LV2 1.0.0 Released
Date: Wed, 18 Apr 2012 22:40:53 -0400
From: David Robillard <d>
To: devel.in

The first unified LV2 release, LV2 1.0.0, is out.

This release merges the previous lv2core package with all the official
extension packages, as well as example plugins, lv2specgen, and
additional data.  From a developer point of view, the biggest change is
that all LV2 API headers can be used by simply checking for the single
pkg-config package "lv2" (for compatibility the previous "lv2core"
package is still installed).  Implementations are encouraged to abandon
the "copy paste headers" practice and depend on this package instead.

With this release, several new extensions have become stable that
together greatly increase the power of LV2: atom, log, parameters,
patch, port-groups, port-props, resize-port, state, time, worker.  

Download: http://lv2plug.in/spec/lv2-1.0.0.tar.bz2

Documentation and more detailed change logs: http://lv2plug.in/ns/

More information about LV2: http://lv2plug.in/
Comment 1 Orcan Ogetbil 2012-04-19 12:34:19 UTC 
I would skip F-16 as it is too far into the stable release cycle. For F-17 I am not sure. Does this update require all the dependant plugin and the library packages to be rebuilt and/or modified?
Comment 2 Brendan Jones 2012-04-19 14:02:22 UTC 
Could we just treat this as a package rename? All the lv2core files are in place. 

repoquery --whatrequires lv2core
lv2-EQ10Q-plugins-0:1.0-8.fc15.x86_64
lv2-abGate-0:1.1.3-2.fc16.x86_64
lv2-avw-plugins-0:0.0.6-3.fc16.x86_64
lv2-calf-plugins-0:0.0.18.6-3.fc15.x86_64
lv2-fil-plugins-0:2.0-4.fc15.x86_64
lv2-invada-plugins-0:1.2.0-4.fc15.x86_64
lv2-kn0ck0ut-0:1.1-0.3.git60421a3.fc16.x86_64
lv2-ll-plugins-0:0.2.8-5.fc15.x86_64
lv2-mdaEPiano-0:0-0.2.git9db45842.fc16.x86_64
lv2-swh-plugins-0:1.0.15-6.20110510.9c9935egit.fc16.x86_64
lv2-ui-0:2.4-4.fc16.x86_64
lv2-vocoder-plugins-0:1-3.fc15.x86_64
lv2-zynadd-plugins-0:1-5.fc15.x86_64
lv2-ui-devel-0:2.4-4.fc16.i686
lv2-ui-devel-0:2.4-4.fc16.x86_64

repoquery --whatrequires lv2core-devel
lilv-devel-0:0.5.0-3.fc16.i686
lilv-devel-0:0.5.0-3.fc16.x86_64
lv2-ui-devel-0:2.4-4.fc16.i686
lv2-ui-devel-0:2.4-4.fc16.x86_64
slv2-devel-0:0.6.6-7.fc15.i686
slv2-devel-0:0.6.6-7.fc15.x86_64
Comment 3 Orcan Ogetbil 2012-04-20 02:05:50 UTC 
I just checked lv2.h. There is no API change, at least for Linux. There is some API addition, but nothing to prevent us to push this to stable Fedora.

For the versioned obsoletes/provides, we need to come up with a version greater that 6.0. How about 6.5, that is the revision number in lv2.h?

Would you like to submit a review? I can review if no one else acts before me.
Comment 4 Brendan Jones 2012-04-20 02:38:43 UTC 
For some reason I was thinking lv2core was 0.6.0 not 6.0. We should probably track upstream version and modify all of the packages above. 

It's not a great deal of work, and as you noted lv2core-6.0 is included unchanged . New releases of lilv and suil were also announced yesterday so they will be rebuilt in any case, and lv2-ui would be deprecated by this new package as well.

How about I submit lv2-1.0.0 for review, using obsoletes/provides as appropriate and while I'm waiting to get this review I'll work on updating the plugins and slv2? I'll push into rawhide and then we can make a decision on F17?

Many of the new projects coming out now are starting to embrace the new extensions, so this process should still be quicker than waiting for individual extensions to be packaged and reviewed beforehand.
Comment 5 Orcan Ogetbil 2012-04-20 02:53:44 UTC 
Indeed, I was once thinking about packaging ingen and friends and then gave up after I realized how much work it would be to package all those lv2 extensions. This will become a convenience for all developers and packagers.

Please submit a review request if/when you get a change, and let me know. lv2core was one of the packages I was planning to hand over this summer, now I can cross it off my list.
Comment 6 Brendan Jones 2012-04-20 03:00:43 UTC 
Created attachment 578844 [details]
What the new spec may look like

OK, will do.

Attached what the spec may look like. Given the change  in version numbering we only need to specify the Obsoletes clause if I have it correctly.
Comment 7 Orcan Ogetbil 2012-04-20 03:10:26 UTC 
[1] states that "Examples of packages that should explicitly provide only arch-specific Provides: include native code libraries or plug-ins and their associated -devel packages." I believe lv2core falls in this category. No?


[1] http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
Comment 8 Brendan Jones 2012-04-20 03:51:51 UTC 
Its arch specific in the sense that its ttl files locations are arch specific, even though there are no binaries, I would have thought that qualified?
Comment 9 Brendan Jones 2012-04-20 06:15:47 UTC 
Yes, you are right re: arch specific Provides
Comment 10 Orcan Ogetbil 2012-04-29 02:27:34 UTC 
I guess we need to retire lv2core now. What is the plan?
Comment 11 Brendan Jones 2012-04-29 03:02:47 UTC 
I want to release the lv2-1.0.0 stack together with suil/lilv etc which now rely on the new upstream tarball.

I'm working through an issue with sratom (new dependency of lilv), so I'm in no hurry to move anything out of rawhide just yet. Should be sorted in the next week or so, one way or the other.
Comment 12 Brendan Jones 2012-05-02 10:33:06 UTC 
I guess we can start moving on this now - still waiting on resolution to sratom which may result in an update to lv2 but that shan't hold us back. 

Should we then proceed to F17 only at this stage? I'm happy with that for the moment - I have had a request to backport into F16 such that the latest jalv/suil/lilv are available, however the previous versions of suil and lilv are already there, so there's nothing stopping us pushing qtractor without the new lv2 stack if need be. The only package to miss out in F16 would then be jalv.
Comment 13 Orcan Ogetbil 2012-05-02 12:29:00 UTC 
If there are no regressions whatsoever, I am fine with updating F-16+. If we need more testing time to make sure that there are no regressions, then I would say F-17+. Your call.
Comment 14 Fedora Update System 2012-05-14 21:03:17 UTC 
lv2-1.0.0-6.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/lv2-1.0.0-6.fc17
Comment 15 Fedora Update System 2012-05-15 02:30:46 UTC 
lv2-1.0.0-6.fc17 has been pushed to the Fedora 17 testing repository.
Comment 16 Orcan Ogetbil 2012-05-15 12:19:17 UTC 
lv2core is now retired on F-17 and later.
Comment 17 Fedora Update System 2012-05-28 01:18:04 UTC 
lv2-1.0.0-6.fc17 has been pushed to the Fedora 17 stable repository.
Note You need to log in before you can comment on or make changes to this bug.