Bug 456256

rpmlint clean on SRPM.

on RPMS:
frei0r-devel.i386: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

Fix, if applicable.

Mightn't we want to call frei0r-devel frei0r-plugins-devel, since the base pacakge is frei0r-plugins?

License is good, but I hope gavl turns out to be GPLv2.

What's the status of the patches WRT upstream?

Do we not need ldconfig in the post/postun for the main package?

Otherwise looks good, waiting on libgdither and gavl for a mock build to test BRs.

Upstream git is now located here:
http://git.dyne.org/index.cgi?url=frei0r/log/

I have sent kwizart's patches to upstream dev for inclusion.

Hello,

What happened with this packet?

I want prepare frei0r-plugins for Fedora because I need them for MLT and Kdenlive.

I prepare this packet for Fedora 10 so please, if you want to see my spec and
src:

http://dl.getdropbox.com/u/728801/kdenlive/sources/frei0r-plugins.spec

http://dl.getdropbox.com/u/728801/kdenlive/sources/frei0r-plugins-1.1.22-1.fc10.src.rpm

Please see them.

kind regards, Zarko

@Zarko

If you want to maintain kdeneline, you should really take a look at mlt mlt++ and kdenlive. There are lot of projects to package, so you can get sponsored.
Until then, you need to sign the Fedora_cla in order to continue the packager sponsor process.

Spec URL:
http://kwizart.fedorapeople.org/SPECS/frei0r-plugins.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/frei0r-plugins-1.1.22-1.fc10.src.rpm
Description: Frei0r - a minimalistic plugin API for video effects

Changelog:
- Update to 1.1.22
- Prevent timestamp change when installing

Checked new version, comments from #1 stand.

Sorry for not having answeared earlier.

(In reply to comment #1)

> on RPMS:
> frei0r-devel.i386: W: no-documentation
> The package contains no documentation (README, doc, etc). You have to include
> documentation files.
This is optional there is no documentation (this is a warning only)
 
> Mightn't we want to call frei0r-devel frei0r-plugins-devel, since the base
> pacakge is frei0r-plugins?
It is just a matter of choice, it was keept this way for historical reasons, When the package was named frei0r-header, but naming it -devel will elect it for multilibs capability.

> License is good, but I hope gavl turns out to be GPLv2.
gavl is licensed under GPLv3+, as freir-plugins is GPLv2+, this is right.
Do you see a problem with this ?

> What's the status of the patches WRT upstream?
According to the freir current specification, the library path is 
 /usr/lib/frei0r-1/<vendor>, either the main library directoy is /usr/lib64 or not.
On our side, we cannot accept 64bit shared object to be located in /usr/lib
instead of /usr/lib64. If I remember well, that will need to be fixed in any application that will use frei0r-plugins. With the change we will introduce, 64bit application compiled on distribution where the main  is /usr/lib
will not be capable of using 64bit native frei0r-plugin on Fedora. (Thus will be binary incompatible).
A permanent solution will be to add another possible directory to look into within the frei0r plugin specification.

> Do we not need ldconfig in the post/postun for the main package?
No, we are not in the usual system library case, where shared object are meant to be linked. We are in the plugin world where unversioned shared object will be dlopened. So they are not meant to be registered from any system linker using ldconfig.

Ok on the docs, names and ldconfig.  

Re: the license, I thought if using a GPLed library, the GPL version of the code must be >= the GPL version of the library?  Or so I have that wrong?  Or do the +s moot the whole thing?  

Re: the patches, so essentially these allow us to work around an upstream limitation that upstream will be fixing in another manner?

> 
> Re: the patches, so essentially these allow us to work around an upstream
> limitation that upstream will be fixing in another manner?  

Sorry on my "non-sponsored" interrupting, but - yes!

Without patch .so files on x86_64 system will be installed into /usr/lib directory (what is forbidden) instead in /usr/lib64...



Zarko

Mock build and BRs good.  What about #7?

License: this library is GPLv2+
the "+" means and later, so it can be linked with GPLv3 library. But according to quick advices asked on IRC, the license should remains the one of the source code of the library itself. Not a computation over the dependencies.

If a package using freir-plugin is GPLv2 (only), then it will not be compatible with our build of the freird-plugin. But that must be checked on the related review.

The patch only change the default installation path for the dso. But each project will need to check and tweak the right path in order to find it, because they will use dlopen to access frei0r-plugins dso.

Ok, sounds reasonable.

APPROVED.

New Package CVS Request
=======================
Package Name: frei0r-plugins
Short Description: Frei0r - a minimalistic plugin API for video effects
Owners: kwizart
Branches: F-10 F-9
Cvsextras Commits: yes

This is the plugins for frei0r right? 
The short description sounds like this is the base package, is that right?

There is no frei0r main package actually or frei0r-plugins is the main package.
We are not in the usual library world here. freir0-plugins bundled dso which are aimed to be dlopened by various applications. But this is not the usual library scheme here·

ok, makes sense, just a bit confusing. ;) 

cvs done.