This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 456256 - Review Request: frei0r-plugins - Frei0r - a minimalistic plugin API for video effects
Review Request: frei0r-plugins - Frei0r - a minimalistic plugin API for video...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jon Ciesla
Fedora Extras Quality Assurance
:
Depends On: 456242
Blocks: RussianFedoraRemix
  Show dependency treegraph
 
Reported: 2008-07-22 10:41 EDT by Nicolas Chauvet (kwizart)
Modified: 2009-05-02 00:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-17 11:22:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
limburgher: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Nicolas Chauvet (kwizart) 2008-07-22 10:41:30 EDT
Spec URL:
http://kwizart.fedorapeople.org/SPECS/frei0r-plugins.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/frei0r-plugins-1.1.21-2.fc8.kwizart.src.rpm
Description: Frei0r - a minimalistic plugin API for video effects
Comment 1 Jon Ciesla 2008-10-10 14:57:42 EDT
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.
Comment 2 Jeff Moe (jebba) 2008-10-21 10:23:41 EDT
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.
Comment 3 Zarko (grof) 2009-03-19 04:02:05 EDT
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
Comment 4 Nicolas Chauvet (kwizart) 2009-03-23 22:34:01 EDT
@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
Comment 5 Jon Ciesla 2009-03-24 09:25:31 EDT
Checked new version, comments from #1 stand.
Comment 6 Nicolas Chauvet (kwizart) 2009-03-24 10:18:22 EDT
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.
Comment 7 Jon Ciesla 2009-03-24 11:03:41 EDT
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?
Comment 8 Zarko (grof) 2009-03-24 11:12:25 EDT
> 
> 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
Comment 9 Jon Ciesla 2009-04-10 09:01:29 EDT
Mock build and BRs good.  What about #7?
Comment 10 Nicolas Chauvet (kwizart) 2009-04-10 09:26:28 EDT
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.
Comment 11 Jon Ciesla 2009-04-10 09:34:12 EDT
Ok, sounds reasonable.

APPROVED.
Comment 12 Nicolas Chauvet (kwizart) 2009-04-10 09:37:37 EDT
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
Comment 13 Kevin Fenzi 2009-04-10 17:47:06 EDT
This is the plugins for frei0r right? 
The short description sounds like this is the base package, is that right?
Comment 14 Nicolas Chauvet (kwizart) 2009-04-10 18:21:15 EDT
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·
Comment 15 Kevin Fenzi 2009-04-12 14:18:39 EDT
ok, makes sense, just a bit confusing. ;) 

cvs done.

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