Bug 232465 - Review Request: lv2core - An Audio Plugin Standard
Review Request: lv2core - An Audio Plugin Standard
Status: CLOSED DUPLICATE of bug 470913
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On:
Blocks: 429581 429585
  Show dependency treegraph
 
Reported: 2007-03-15 13:11 EDT by Anthony Green
Modified: 2008-11-10 17:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-09 10:26:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Green 2007-03-15 13:11:04 EDT
Spec URL: http://people.redhat.com/green/FE/devel/lv2.spec
SRPM URL: http://people.redhat.com/green/FE/devel/lv2-1.0-0.1.beta1.src.rpm
Description: 
There are a large number of open source and free software synthesis
packages in use or development at this time. This API ('LV2')
attempts to give programmers the ability to write simple 'plugin'
audio processors in C/C++ and link them dynamically ('plug') into
a range of these packages ('hosts').  It should be possible for any
host and any plugin to communicate completely through this interface.

LV2 is a successor to LADSPA, created to address the limitations of
LADSPA which many hosts have outgrown.
Comment 1 Bernard Johnson 2007-04-30 18:18:15 EDT
A few things:

1) This package creates 0 byte debuginfo packages.
2) There is no arch-dependent files in this package, it should be a noarch. 
This should fix the problem with #1 too.
3) Why do you create /usr/lib/lv2 directory?
Comment 2 Michael Schwendt 2007-06-27 08:07:24 EDT
> http://people.redhat.com/green/FE/devel/lv2.spec

Is broken. 1870 0x00 bytes.

> License: LGPL

The lv2.ttl file uses the MIT licence. Only lv2.h is LGPL.


Is there any package that "BuildRequires: lv2-devel" and accesses
the lv2.ttl file at its current location?
Comment 3 Jason Tibbitts 2008-01-18 23:19:59 EST
It's been over half a year since the last comment; is there still interest in
this package?
Comment 4 Anthony Green 2008-01-19 00:17:35 EST
(In reply to comment #3)
> It's been over half a year since the last comment; is there still interest in
> this package?

Yes, I think so.  The first official version of lv2 just came out about a week
ago.  I'll update this submission in the next couple of weeks.

Comment 5 Anthony Green 2008-01-21 13:41:04 EST
Upstream's 1.0 release is called lv2core.  I've renamed and updated this package
appropriately.

http://spindazzle.org/Fedora/lv2core.spec
http://spindazzle.org/Fedora/lv2core-1.0-1.fc8.src.rpm
Comment 6 Jason Tibbitts 2008-01-21 13:54:11 EST
Did you really want to set fedora-review to '?'?  It will drop out of the list
of new review tickets, so if you don't already have a reviewer then nobody will
see it.
Comment 7 Anthony Green 2008-01-21 14:08:57 EST
(In reply to comment #6)
> Did you really want to set fedora-review to '?'?  It will drop out of the list
> of new review tickets, so if you don't already have a reviewer then nobody will
> see it.

Thanks.  I've changed it.

AG
Comment 8 Jason Tibbitts 2008-01-21 17:46:52 EST
Builds OK; here's some rpmlint output:

  lv2core.x86_64: W: invalid-license LGPL2.1+
Valid tags are at http://fedoraproject.org/Licensing; should be LGPLv2+.

  lv2core.x86_64: E: no-binary
  lv2core.x86_64: E: only-non-binary-in-usr-lib
  lv2core-debuginfo.x86_64: E: empty-debuginfo-package
Comment #1 mentioned that this package should be noarch; is there some reason
why it needs to be arch-specific?  I can't find any reason why it would.

  lv2core-devel.x86_64: W: no-documentation
This is OK.

I'm afraid I don't know what a .ttl file is, but just to be sure: can you
confirm that the two ttl files are needed at runtime and not just during
compilation?  I'm trying to determine whether or not they need to live in the
-devel package (which would sort of make the whole thing a -devel package, I guess).
Comment 9 Anthony Green 2008-01-21 18:35:36 EST
(In reply to comment #8)
> Builds OK; here's some rpmlint output:
> 
>   lv2core.x86_64: W: invalid-license LGPL2.1+
> Valid tags are at http://fedoraproject.org/Licensing; should be LGPLv2+.

Ok.

> 
>   lv2core.x86_64: E: no-binary
>   lv2core.x86_64: E: only-non-binary-in-usr-lib
>   lv2core-debuginfo.x86_64: E: empty-debuginfo-package
> Comment #1 mentioned that this package should be noarch; is there some reason
> why it needs to be arch-specific?  I can't find any reason why it would.

It's conceivable that the .pc file could be different for different architectures.

>   lv2core-devel.x86_64: W: no-documentation
> This is OK.
> 
> I'm afraid I don't know what a .ttl file is, but just to be sure: can you
> confirm that the two ttl files are needed at runtime and not just during
> compilation?  I'm trying to determine whether or not they need to live in the
> -devel package (which would sort of make the whole thing a -devel package, I
guess).

They are used at runtime by lv2 hosts.

Comment 10 Jason Tibbitts 2008-01-21 21:01:35 EST
> It's conceivable that the .pc file could be different for different 
> architectures.

Then that would be a multilib conflict, and hence another blocker.  Anything in
the -devel package that installs into the same location on 64bit and 32bit
architectures must be identical.
Comment 11 Anthony Green 2008-01-21 22:57:54 EST
(In reply to comment #10)
> Then that would be a multilib conflict, and hence another blocker.  Anything in
> the -devel package that installs into the same location on 64bit and 32bit
> architectures must be identical.

The .pc files get installed under %{_libdir}/pkgconfig so there would be no
multilib conflict.
Comment 13 Jason Tibbitts 2008-01-24 00:25:10 EST
If you really think this should be noarch, then you will need to disable the
debuginfo package, because it's pointless to ship an empty one:
  %define debug_package %{nil}
Comment 14 Peter Jones 2008-06-25 14:30:48 EDT
Why does this need a .pc file at all?  Everything that it'll display is (and has
always been) the compiler default.  If you remove it, building against the
header will work just as well, but there'll be no need for it to be arch-specific.
Comment 15 Jason Tibbitts 2008-07-02 16:49:21 EDT
Well, it's been quite some time since the last comment from the submitter. 
Setting NEEDINFO; I'll close this soon if there's no further progress.
Comment 16 Jason Tibbitts 2008-08-09 10:26:50 EDT
This has been in needinfo for over a month, closing.
Comment 17 Jason Tibbitts 2008-11-10 17:08:31 EST

*** This bug has been marked as a duplicate of bug 470913 ***

Note You need to log in before you can comment on or make changes to this bug.