Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232465 - Review Request: lv2core - An Audio Plugin Standard
Summary: Review Request: lv2core - An Audio Plugin Standard
Keywords:
Status: CLOSED DUPLICATE of bug 470913
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: 429581 429585
TreeView+ depends on / blocked
 
Reported: 2007-03-15 17:11 UTC by Anthony Green
Modified: 2008-11-10 22:08 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-09 14:26:50 UTC


Attachments (Terms of Use)

Description Anthony Green 2007-03-15 17:11:04 UTC
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 22:18:15 UTC
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 12:07:24 UTC
> 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-19 04:19:59 UTC
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 05:17:35 UTC
(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 18:41:04 UTC
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 18:54:11 UTC
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 19:08:57 UTC
(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 22:46:52 UTC
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 23:35:36 UTC
(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-22 02:01:35 UTC
> 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-22 03:57:54 UTC
(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 05:25:10 UTC
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 18:30:48 UTC
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 20:49:21 UTC
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 14:26:50 UTC
This has been in needinfo for over a month, closing.

Comment 17 Jason Tibbitts 2008-11-10 22:08:31 UTC

*** 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.