SPEC URL: http://jskarvad.fedorapeople.org/bino/bino.spec SRPM URL: http://jskarvad.fedorapeople.org/bino/bino-1.1.3-1.fc17.src.rpm Description: Bino is a 3D video player. It supports stereoscopic 3D video with a wide variety of input and output formats. It also supports multi-display video and it can be used for powerwalls, virtual reality installations and other multi-projector setups. This package is not eligible in Fedora because it depends on ffmpeg from rpmfusion-free repository. $ rpmlint bino.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. $ rpmlint *.rpm bino.src: W: spelling-error %description -l en_US multi -> milt, malt, melt bino.src: W: spelling-error %description -l en_US powerwalls -> power walls, power-walls, Powell's bino.x86_64: W: spelling-error %description -l en_US multi -> milt, malt, melt bino.x86_64: W: spelling-error %description -l en_US powerwalls -> power walls, power-walls, Powell's 3 packages and 0 specfiles checked; 0 errors, 4 warnings. I think all warnings are false positive. This is my first rpmfusion package, but I am packaging for Fedora/RHEL (FAS: jskarvad). Thus, I probably need sponsor for rpmfusion. The above SPEC/SRPM is for rawhide (fc17), I can also provide older versions for FC14, FC15: SPEC FC14: http://jskarvad.fedorapeople.org/bino/bino.spec.fc14 SRPM FC14: http://jskarvad.fedorapeople.org/bino/bino-0.9.2-1.fc14.src.rpm SPEC FC15: http://jskarvad.fedorapeople.org/bino/bino.spec.fc15 SRPM FC15: http://jskarvad.fedorapeople.org/bino/bino-1.0.0-1.fc15.src.rpm
(In reply to comment #0) > This is my first rpmfusion package, but I am packaging for Fedora/RHEL (FAS: > jskarvad). Thus, I probably need sponsor for rpmfusion. > I don't need sponsor according to: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2011-August/010064.html I updated this review request accordingly.
The spec file looks pretty good overall. A couple of things I would change. 1. You don't need "%defattr(..." in %files anymore. 2. I would use this trick to get all the documentation into one directory: In %install: mkdir _tmpdoc mv %{buildroot}%{_datadir}/doc/%{name}/* _tmpdoc/ rm -rf %{buildroot}%{_datadir}/doc In %files: %doc AUTHORS COPYING ChangeLog README _tmpdoc/*
Richard, thanks. Updated SPEC and SRPM according to your comments are there: SPEC URL: http://jskarvad.fedorapeople.org/bino/bino.spec SRPM URL: http://jskarvad.fedorapeople.org/bino/bino-1.1.3-2.fc17.src.rpm BTW: The ld-fix patch was accepted by upstream and will be included in their next release.
I was not able to build this on F15 due to ffmpeg not being new enough. It also failed under mock for F16 but that may be an RPM Fusion repo issue. I was able to get it to build under rawhide. Which releases were you planning on building for? Richard
(In reply to comment #4) > Which releases were you planning on building for? > The most recent bino from comment 4 can be now probably only build for rawhide due to ffmpeg dependency. This one I am most interested in. For F14-F16, specific older bino versions have to be used (SPECs from the end of comment 1). I can also build them (and apply comments from comment 2 to them).
(In reply to comment #5) > (In reply to comment #4) > > Which releases were you planning on building for? > > > The most recent bino from comment 4 can be now probably only build for rawhide > due to ffmpeg dependency. This one I am most interested in. Figures :) > For F14-F16, specific older bino versions have to be used (SPECs from the end > of comment 1). I can also build them (and apply comments from comment 2 to > them). OK. As a side note I looked into building Equalizer since it's an optional dependency but it requires a newer version of OpenSceneGraph than is available for F15. Let me know if you're interested. I'll package up an (unfinished) SRPM in its current state. It's got some bundled libs I haven't had a chance to look into yet. Richard
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Which releases were you planning on building for? > > > > > The most recent bino from comment 4 can be now probably only build for rawhide > > due to ffmpeg dependency. This one I am most interested in. > > Figures :) > From the configure it requires FFmpeg >= 0.7, I successfully built it for F16 from the provided SPEC. > As a side note I looked into building Equalizer since it's an optional > dependency but it requires a newer version of OpenSceneGraph than is available > for F15. > > Let me know if you're interested. I'll package up an (unfinished) SRPM in its > current state. It's got some bundled libs I haven't had a chance to look into > yet. > Great, I am interested.
(In reply to comment #7) > (In reply to comment #6) > > Let me know if you're interested. I'll package up an (unfinished) SRPM in its > > current state. It's got some bundled libs I haven't had a chance to look into > > yet. > > > Great, I am interested. Here's the SRPM: http://hobbes1069.fedorapeople.org/Equalizer/Equalizer-1.0.1-1.fc15.src.rpm I think I have all or most of the build requires figured out but I can't be sure since I couldn't build it. You'll notice in the configuration that it unpacks from headers for vmml, I'm not sure what that is or if it constitutes a bundled library. Richard
FYI: F-15 branch is going to have FFmpeg-0.7.4 soon, so there's no need to package an older version there. FFmpeg-0.7.4 in F-14 is also a possibility.
FFmpeg-0.7.5 is in f15 updates and f14 is nearly dead, thus we can probably go with only one build. I fixed compilation of Equalizer, srpm: http://jskarvad.fedorapeople.org/Equalizer-1.0.1-1.fc17.src.rpm But there are still rpmlint issues that needs to be fixed. The vmmlib seems to be bundled. It is required otherwise the bino doesn't compile with Equalizer. The vmmlib is template library for vector matrix math, home: http://vmmlib.sourceforge.net/ I could package it for Fedora. Also the Equalizer contains two projects - the equalizer and the collage (home: http://www.equalizergraphics.com/downloads.html). Maybe it could be split into two packages. I tested it with bino. It requires another explicit link with glew, then it compiles fine. Updated bino srpm: http://jskarvad.fedorapeople.org/bino-1.1.3-3.fc17.src.rpm
Jaroslav, Can you send me the changes (and spec file additions) for Equalizer and vmmlib? I'll the incorporate them into the repositories. Regarding vmmlib: It is indeed a separate project, but has not yet been packaged properly. Regarding Equalizer/Collage: The idea is that they become separate packages, but there is some non-trivial work left in untangling the build system. I don't think it's too much of a problem to leave them in one package from now.
(In reply to comment #11) > Can you send me the changes (and spec file additions) for Equalizer and vmmlib? > I'll the incorporate them into the repositories. > The Equalizer spec and patch needed for build is in srpm in comment 10. As a source I used the spec from comment 8. I think it could go to Fedora (AFAIK LGPL license, no forbidden requires), thus I will probably create Fedora review request ticket when I handle the minor issues (e.g. vmmlib). Or is there another volunteer here? I haven't packaged the vmmlib yet. On the first look it seems easy, but I didn't have time to look more deep on it. I also think it could go to Fedora (AFAIK BSD license), I will probably open separate review request ticket on Fedora. Guys, could we go ahead with the bino review? I think it is mostly done. The current srpm compiles fine with and also without Equalizer. We could add it without Equalizer now and later when Equalizer gets into Fedora, we could simply add BuildRequires and rebuild.
(In reply to comment #12) > I will probably create Fedora review request ticket when I handle the minor > issues (e.g. vmmlib). Or is there another volunteer here? Not that I am aware of.
Jaroslav, I've integrated your changes into our 1.0 tree. Can you test https://github.com/Eyescale/Equalizer/tree/1.0 to see if you can build an RPM without patches? I'll then go ahead and tag the 1.0.2 release.
(In reply to comment #14) > Jaroslav, > > I've integrated your changes into our 1.0 tree. Can you test > https://github.com/Eyescale/Equalizer/tree/1.0 to see if you can build an RPM > without patches? I'll then go ahead and tag the 1.0.2 release. Stefan, thanks for incorporating this upstream. It builds fine now. I can maintain it in Fedora and I will open Fedora tickets - I will let you know (put links here).
Version bump: http://jskarvad.fedorapeople.org/bino-1.2.1-1.fc17.src.rpm
Would you like to swap this review for gmtk? https://bugzilla.rpmfusion.org/show_bug.cgi?id=1958
(In reply to comment #17) > Would you like to swap this review for gmtk? > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1958 No problem to swap, but unfortunately I was not fast enough this time.
For all interested, there are currently Fedora tickets for inclusion of vmmlib and Equalizer. All comments are welcome. http://bugzilla.redhat.com/show_bug.cgi?id=758470 http://bugzilla.redhat.com/show_bug.cgi?id=758472
Any volunteer to move this review forward? I think it shouldn't be hard to get this finished. I am ready to swap this for other rpmfusion/fedora review.
I will have a look at this, probably tomorrow if time permits. Not assigning it until I start working on it, if anyone else wants to step in feel free to do so.
My first "official" review... Could someone please look over my shoulder about the bundled icons, am I judging this correct? Package Review ============== Key: - = N/A x = Pass ! = Fail ? = Not evaluated ==== Generic ==== [x]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture (i386). [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: MUST Buildroot is not present [x]: MUST Package contains no bundled libraries. Contains a subset of icons from oxygen-icon-theme, a corner case. [x]: MUST Changelog in prescribed format. [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: MUST Sources contain only permissible code or content. [x]: MUST Each %files section contains %defattr if rpm < 4.4 [x]: MUST Macros in Summary, %description expandable at SRPM build time. [x]: MUST Package requires other packages for directories it uses. [x]: MUST Package uses nothing in %doc for runtime. [x]: MUST Package is not known to require ExcludeArch. [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Spec file lacks Packager, Vendor, PreReq tags. [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. Note: rm -rf would be needed if support for EPEL5 is required [x]: MUST If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [!]: MUST License field in the package spec file matches the actual license. pkg dir seems to contain MIT-type licenses for both MacOS and w32. Icons seems to be either MIT or LGPL3+ [!]: MUST Package consistently uses macros (instead of hard-coded directory names). Note: Using both %{buildroot} and $RPM_BUILD_ROOT [!]: MUST Package meets the Packaging Guidelines. OK besides what's noted in other remarks. [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST Package does not generates any conflict. [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [x]: MUST Package must own all directories that it creates. [x]: MUST Package does not own files or directories owned by other packages. [x]: MUST Package installs properly. [!]: MUST Requires correct, justified where necessary. Texinfo snippets in %post and %preun lacks corresponding deps. [x]: MUST Rpmlint output is silent, also on installed package. [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. MD5SUM this package : 8110094f05c02667760eda720f84618f MD5SUM upstream package : 8110094f05c02667760eda720f84618f [x]: MUST Spec file is legible and written in American English. [x]: MUST Spec file name must match the spec package %{name}, in the format %{name}.spec. [-]: MUST Package contains a SysV-style init script if in need of one. [x]: MUST File names are valid UTF-8. [x]: SHOULD Reviewer should test that the package builds in mock. [-]: SHOULD If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: SHOULD Dist tag is present. [x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: SHOULD Final provides and requires are sane (attached below). [x]: SHOULD Package functions as described. Looked at some clips without problems, but no 3D gear available. [-]: SHOULD Package does not include license text files separate from upstream. [!]: SHOULD Patches link to upstream bugs/comments/lists or are otherwise justified. [x]: SHOULD Scriptlets must be sane, if used. [x]: SHOULD SourceX / PatchY prefixed with %{name}. [x]: SHOULD SourceX is a working URL. [-]: SHOULD Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [?]: SHOULD Package should compile and build into binary rpms on all supported architectures. [-]: SHOULD %check is present and all tests pass. [x]: SHOULD Packages should try to preserve timestamps of original installed files. [-]: SHOULD Spec use %global instead of %define. Issues: [!]: MUST Package consistently uses macros (instead of hard-coded directory names). Note: Using both %{buildroot} and $RPM_BUILD_ROOT [!] SHOULD The ld-patch needs some kind of justification, an upstream bug reference or a comment. [!] MUST The %post and %preun texinfo snippets needs corresponding Requires(post): info and Requires(preun): info. [!] MUST: The License: tag should be updated to reflect the licenses in the package. Removing the pkg stuff in %prep might possibly make things simpler. Using system icons instead of src/icons might also help. Non-GPLv3+ licenses includes pkg/* and src/icons*/*. Some kind of license breakdown is probably needed. See: http://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment http://fedoraproject.org/wiki/Packaging:Guidelines#Macros http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Texinfo http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios https://launchpad.net/ubuntu/precise/+source/bino/+copyright Generated by fedora-review 0.1.2 External plugins: ~/rpmbuild/RPMS/i686/bino-1.2.1-1.fc16.i686.rpm mimehandler(application/ogg) [yet another 32 mimehandlers removed] bino = 1.2.1-1.fc16 bino(x86-32) = 1.2.1-1.fc16 = /bin/sh libGL.so.1 libGLEW.so.1.6 libGLEWmx.so.1.6 libQtCore.so.4 libQtGui.so.4 libQtOpenGL.so.4 libX11.so.6 libass.so.4 libavcodec.so.53(LIBAVCODEC_53) libavdevice.so.53(LIBAVDEVICE_53) libavformat.so.53(LIBAVFORMAT_53) libavutil.so.51(LIBAVUTIL_51) libc.so.6 libgcc_s.so.1(GCC_3.0) libopenal.so.1 libpthread.so.0 libstdc++.so.6 libswscale.so.2 libswscale.so.2(LIBSWSCALE_2) rtld(GNU_HASH) ~/rpmbuild/RPMS/i686/bino-debuginfo-1.2.1-1.fc16.i686.rpm bino-debuginfo = 1.2.1-1.fc16 bino-debuginfo(x86-32) = 1.2.1-1.fc16 =
(In reply to comment #22) Thanks for the review. Updated files: http://jskarvad.fedorapeople.org/bino-1.2.1-2.fc16.src.rpm http://jskarvad.fedorapeople.org/bino.spec > Issues: > [!]: MUST Package consistently uses macros (instead of hard-coded directory > names). > Note: Using both %{buildroot} and $RPM_BUILD_ROOT Fixed > [!] SHOULD The ld-patch needs some kind of justification, an upstream bug > reference or a comment. Added comment, this patch is required in order to build due to Fedora DSO linkage change. This patch has been accepted by upstream and is not needed for their devel release. > [!] MUST The %post and %preun texinfo snippets needs corresponding > Requires(post): info and Requires(preun): info. Fixed > [!] MUST: The License: tag should be updated to reflect the licenses > in the package. Removing the pkg stuff in %prep might possibly > make things simpler. Using system icons instead of src/icons might > also help. Non-GPLv3+ licenses includes pkg/* and src/icons*/*. > Some kind of license breakdown is probably needed. I am not expert about licensing, but I am not sure if there was any problem (but I implemented all the proposed changes): * The pkg stuff is not used/released in the RPM binary package, thus I think it was OK according to: http://fedoraproject.org/wiki/Licensing/FAQ#Does_the_License:_tag_cover_the_SRPM_or_the_binary_RPM.3F Even after the removal, the source code is still distributed in the srpm package. So I am not sure if the proposed change resolves anything. * For the oxygen icons, IMHO they are licensed under LGPLv3+ thus we probably don't need to explicitly note this because the resulting work is released under GPLv3+. I used the following reference: http://fedoraproject.org/wiki/Licensing/FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F http://fedoraproject.org/wiki/Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F
Licensing experts are rare out here... I learned a little reading your reply :) Basically, I can follow your arguments and they seem to be sound. However, the oxygen icons still worries me, partly because I'm not completely sure that they are not a "bundled library" issue. From a formal point of view they are(?) OTOH, the major argument not to bundle, security, just makes no sense here. More practically, bundling a set of icons is so common that making it a problem might be to open Pandora's box without any reasonable purpose. I'll wait until tomorrow. Unless there's more input on this issue then, I'll approve.
(In reply to comment #24) > However, the > oxygen icons still worries me, partly because I'm not completely sure that they > are not a "bundled library" issue. From a formal point of view they are(?) > OTOH, the major argument not to bundle, security, just makes no sense here. > More practically, bundling a set of icons is so common that making it a problem > might be to open Pandora's box without any reasonable purpose. > It makes sense to me. I will try to unbundle them. Please stay tuned.
Unbundled oxygen icons, new files: http://jskarvad.fedorapeople.org/bino-1.2.1-3.fc16.src.rpm http://jskarvad.fedorapeople.org/bino.spec
All open issues resolved. Fast progress, indeed :) ***Approved
Alec thanks for your review.
Package CVS request ====================== Package Name: bino Short Description: 3D video player Owners: jskarvad@redhat.com Branches: f16 InitialCC: ---------------------- License tag: free
Uhm, you aren't "unbundling" the icons at all there, you're still shipping them in the binary package, so license-wise it makes no difference whatsoever. That said, including LGPLv3+ icons in a GPLv3+ binary is fine and does not require a separate mention in the License tag. To really unbundle the icons, one would have to patch the code to stop using the Qt resource system (which bundles the icons in the binary) and make it use an icon loader compliant with the freedesktop.org icon theme spec instead, e.g. the one in kdelibs (i.e. link kdeui and replace all the uses of QIcon with KIcon, referencing the icon name as per the freedesktop.org icon naming spec). That would allow theming and adapting to different icon sizes.
(Well, another way to unbundle the icons would be to patch the code to just use the real file names instead of those resource names and to change the BuildRequires: oxygen-icon-theme to a runtime Requires, but that would just fix the bundling and not the hardcoding of size and theme.)
(In reply to comment #30) Hi Kevin, I am not unbundling icons from the binary, but from the sources, i.e. to build with the system oxygen-icon-theme. And it is there only as a fallback. The current code loads icons dynamically from the system theme and if it fails it fallbacks to the built-in icons.