Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.0-1.fc9.src.rpm Description: A decoder for nexTView - an electronic TV program guide for the analog domain. It enables you to receive and browse free TV program listings for all of the major networks in Germany, Austria, France and Switzerland. The package contains a browser application for the EPG data and a daemon which should run in the background to gather the data. Multiple browser instances and the daemon exchange information via a socket and a common directory. Please review this, my FIRST package for Fedora. Therefore I also need a SPONSOR. I tried hard to follow that myriads of guidelines. So I hope there won't be much to gripe :) I get some warnings from rpmlint in the binary packages: $ rpmlint nxtvepg-2.8.0-1.fc9.x86_64.rpm nxtvepg.x86_64: W: file-not-utf8 /usr/share/doc/nxtvepg-2.8.0/TODO nxtvepg.x86_64: W: file-not-utf8 /usr/share/man/man1/nxtvepg.1.gz nxtvepg.x86_64: W: file-not-utf8 /usr/share/doc/nxtvepg-2.8.0/COPYRIGHT nxtvepg.x86_64: W: file-not-utf8 /usr/share/doc/nxtvepg-2.8.0/CHANGES I don't know if the docs must be UTF-8 encoded. I decided to not bother yet. nxtvepg.x86_64: W: non-standard-uid /var/lib/nxtvepg nxtvepg nxtvepg.x86_64: W: non-standard-gid /var/lib/nxtvepg nxtvepg This is intended. The daemon running as unprivileged user dumps his databases there. nxtvepg.x86_64: W: incoherent-subsys /etc/rc.d/init.d/nxtvepgd $prog It seems rpmlint doesn't get this right. It should be fine because of $prog=nxtvepgd. 1 packages and 0 specfiles checked; 0 errors, 7 warnings.
Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.0-2.fc9.src.rpm All files should be UTF-8 encoded now.
Some remarks: ! iconv script - Not a blocker, however would you write them shorter like below? ------------------------------------------------------- %setup -q for f in \ CHANGES COPYRIGHT TODO nxtvepg.1 do iconv -f ISO-8859-15 -t UTF-8 $f > $f.new touch -c -r $f $f.new mv -f $f.new $f done ------------------------------------------------------- * optflags - Fedora specific compilation flags are not correctly honored: https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags You can check what flags are used by $ rpm --eval %optflags * app-defaults directory - I guess we should use %_datadir/X11/app-defaults as app-defaults directory * On my system %_sysconfdir/X11/app-defaults is not owned by any packages * Also there are no files under %_sysconfdir/X11/app-defaults * Desktop file ------------------------------------------------------- 206 + desktop-file-install --vendor=fedora --dir=/builddir/build/BUILDROOT/nxtvepg-2.8.0-2.fc10.i386/usr/share/applications /builddir/b uild/SOURCES/nxtvepg.desktop 207 /builddir/build/SOURCES/nxtvepg.desktop: key "Categories" is a list and does not have a semicolon as trailing character, fixing ------------------------------------------------------- - Category line should be "Categories=AudioVideo;".
Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.0-3.fc9.src.rpm %changelog * Tue Sep 16 2008 Torsten Rausche <trausche> - 2.8.0-3 - Cleaned up the UTF-8 conversion - Use optflags for building - Use _datadir/X11/app-defaults instead of _sysconfdir/X11/app-defaults - Added semicolon to Categories in the desktop file
Assigning.
Okay, now for 2.8.0-3: * app-defaults directory - build.log shows: ----------------------------------------------- 50 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.ubLuyM 51 + umask 022 52 + cd /builddir/build/BUILD 53 + cd nxtvepg-2.8.0 54 + LANG=C 55 + export LANG 56 + unset DISPLAY 57 + CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i 386 -mtune=generic -fasynchronous-unwind-tables' 58 + make -j4 TCL_VER=8.5 TCL_LIBRARY_PATH=/usr/share/tcl8.5 TK_LIBRARY_PATH=/usr/share/tk8.5 SYS_DBDIR=/var/lib/nxtvepg all 59 gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wno-pointer-sign -I. -I/usr/X11R6/include -Ibuild-i386 -DX11_APP_DEFAULTS=\"/etc/X11/app-defaults/Nxtvepg\" -DTK_LIBRARY_PATH=\"/usr/share/tk8.5\" -DTCL_LIBRARY_PATH=\"/usr/share/tcl8.5\" -DUSE_THREADS -DUSE_XMLTV_IMPORT -DUSE_TTX_GRABBER -DUSE_DAEMON -DEPG_DB_DIR=\"/var/lib/nxtvepg\" -o build-i386/tcl2c tcl2c.c ----------------------------------------------- Check the build option of "-DX11_APP_DEFAULTS". A more fix seems to be needed. * Desktop file - %_bindir/nxtvepg seems a GUI application and a proper desktop file is needed: https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files
(In reply to comment #5) > Check the build option of "-DX11_APP_DEFAULTS". A more fix seems > to be needed. Yes, I changed it for %install only. But it seems to be important in %build too. This is fixed in 2.8.0-4. > * Desktop file > - %_bindir/nxtvepg seems a GUI application and a proper > desktop file is needed: > https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files I am confused now. There is already a desktop file (Source1) for the nxtvepg binary and it seems to get installed properly.
Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.0-4.fc9.src.rpm %changelog * Wed Sep 17 2008 Torsten Rausche <trausche> - 2.8.0-4 - Try harder to use _datadir/X11/app-defaults
(In reply to comment #6) > > * Desktop file > > - %_bindir/nxtvepg seems a GUI application and a proper > > desktop file is needed: > > https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files > > I am confused now. There is already a desktop file (Source1) for the nxtvepg > binary and it seems to get installed properly. Sorry, it seems I was half asleep :( I will check your latest srpm later.
Okay. Now this package itself is okay, so: ------------------------------------------------------------- NOTE: Before being sponsored: This package will be accepted with another few work. But before I accept this package, someone (I am a candidate) must sponsor you. Once you are sponsored, you have the right to review other submitters' review requests and approve the packages formally. For this reason, the person who want to be sponsored (like you) are required to "show that you have an understanding of the process and of the packaging guidelines" as is described on : http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored Usually there are two ways to show this. A. submit other review requests with enough quality. B. Do a "pre-review" of other person's review request (at the time you are not sponsored, you cannot do a formal review) When you have submitted a new review request or have pre-reviewed other person's review request, please write the bug number on this bug report so that I can check your comments or review request. Fedora package collection review requests which are waiting for someone to review can be checked on: http://fedoraproject.org/PackageReviewStatus/NEW.html (NOTE: please don't choose "Merge Review") Review guidelines are described mainly on: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ScriptletSnippets ------------------------------------------------------------
ping?
(In reply to comment #10) > ping? Pong! Don't worry. I'm still alive, just a bit busy. I'll try this pre-review thing as my spare time permits it. I think there should be some in the next days. At the moment there is no more software I use but is not packaged in Fedora already. I think it is better to only maintain packages to which you are related usage- or development-wise somehow.
ping again?
ping again??
I will close this bug as NOTABUG if no response is received from the reporter within ONE WEEK.
I did a new release in the meantime. You see I maintain the package -- as I actively use it. I just have a problem with the time I have to spend with reviewing other packages. There is an enormous list of points to check for which i needed hours for my own package. How much time will it cost then to do the same with a foreign package? Are there any helpful tools I missed? Do I have to check every single point in that pre-reviews to get them honored? How many pre-reviews will I have to do? I submitted this package because I created it for myself anyway and thought it could be useful for other people too. I am not doing it to polish my ego by getting an elite Fedora packager at any cost. Therefore I will only invest as much time in this process as is pleasing to me. --------------------------------------------------------- Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.1-1.fc9.src.rpm %changelog * Sat Oct 11 2008 Torsten Rausche <trausche> - 2.8.1-1 - New bugfix release - Include the (experimental) Teletext grabber - Require Perl for the Teletext grabber
First of all: (In reply to comment #16) > SRPM URL: > http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.1-1.fc9.src.rpm - I must say this srpm (tarball in this srpm) is problematic. Almost all codes in 2.8.1 tarball are still under GPLv2 (strict), however newly added tv_grab_ttx.pl is under GPLv3+, which are, unfortunately, incompatible: http://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix You need to fix license issue first. (In reply to comment #16) > How much time will it cost then to do > the same with a foreign package? I guess you will take much less time than the package you develop by yourself and release by yourself. > Do I > have to check every single point in that pre-reviews to get them honored? I don't know what you mean by "single point", however please check at least what is written on "ReviewGuidelines" and "Guidelines" wiki > How > many pre-reviews will I have to do? At least one.
If the submitter is more interested in upstream development, I can take over the package submission/maintainer-ship, or simply become co-maintainer.
(In reply to comment #17) > - I must say this srpm (tarball in this srpm) is problematic. > > Almost all codes in 2.8.1 tarball are still under GPLv2 (strict), however > newly added tv_grab_ttx.pl is under GPLv3+, which are, unfortunately, > incompatible: > http://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix > You need to fix license issue first. Upstream doesn't want to change the licenses and suggests to split out the Perl script because it is not essential for the main application and can also be used stand-alone. Is it possible/allowed to move it into a subpackage with a different license tag? As the Perl script is still an experimental feature I could also exclude it for now.
(In reply to comment #18) > If the submitter is more interested in upstream development, I can > take over the package submission/maintainer-ship, or simply become > co-maintainer. I don't develop upstream. I am just a daily user of it and track its development. Therefore I already package fresh releases for myself and thought other people would like this package too. I don't mind if another person would take over and maintain this package as long as this person steadily pushs new releases and is open for submissions from my side :)
(In reply to comment #19) > (In reply to comment #17) > > - I must say this srpm (tarball in this srpm) is problematic. > > > > Almost all codes in 2.8.1 tarball are still under GPLv2 (strict), however > > newly added tv_grab_ttx.pl is under GPLv3+, which are, unfortunately, > > incompatible: > > http://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix > > You need to fix license issue first. > > Upstream doesn't want to change the licenses and suggests to split out the Perl > script because it is not essential for the main application and can also be > used stand-alone. Is it possible/allowed to move it into a subpackage with a > different license tag? > > As the Perl script is still an experimental feature I could also exclude it for > now. This depends on how this perl script is related to the rest part of nxtvepg. If this perl script "uses" (i.e. depends on) the rest part of nxtvepg, then the license conflict cannot be resolved only by moving it into a subpackage and this script must be removed completely.
(In reply to comment #21) > This depends on how this perl script is related to the rest part of nxtvepg. > If this perl script "uses" (i.e. depends on) the rest part of nxtvepg, then > the license conflict cannot be resolved only by moving it into a subpackage > and this script must be removed completely. Are you sure? After reading http://fedoraproject.org/wiki/Licensing/FAQ I even think it would be enough to add GPLv3+ to the License tag: <cite> Q: How should I handle multiple licensing situations? A: It depends on the situation. Here are some common cases: # A package has multiple binaries, some of them are GPLv2, some are GPLv3, and some are MIT licensed. In this case, you do need to list all of the individual licenses of the compiled binaries in the License tag, so it should read: License: GPLv2 and GPLv3 and MIT </cite> If this is possible for binaries, it should also be possible for scripts, shouldn't it?
This is the case in which GPLv2 part of the codes does not depend on GPLv3 part (i.e. GPLv2 part binaries can be rebuilt even if the codes licensed under GPLv3 are completely removed from the tarball and GPLv2 binaries does not use GPLv3 binaries in essence). So the question is how this perl script is tied to nxtvepg binary. - If this perl script can be used without nxtvepg binary (i.e. with this binary removed), then multiple licensing situation can be applied. - If this perl script essencially uses nxtvepg binary, then license needs fixing.
We have following situation: [1] Nxtvepg (GPLv2) does not need the Perl script (GPLv3+). It can use the script if it is there but also runs fine without it. Both communicate with each other and exchange data. But there is no hard link between both. Nxtvepg simply pipes preprocessed data from /dev/vbi to the script, the script parses the data and gives XML as output, which in turn nxtvepg reads via pipe. My opinion is that if this is not legal then no GPLv2 UNIX tool could interact with a GPLv3+ one. Upstream also does not seem to see a problem here. [2] The Perl script (GPLv3+) can also run without nxtvepg. But it needs preprocessed input data to do something useful. This data has to come from a file or standard input. Optionally it can use the VBI device directly -- if the Perl module Video-ZVBI (GPLv2+) is available. This module is not packaged for Fedora yet. But this could be done... Because of [1] the script is included in the nxtvepg tarball. Because of [2] it is also available in its own tarball under http://nxtvepg.sourceforge.net/tv_grab_ttx I think it is enough to set License to GPLv2 and GPLv3+ and keep the script in the nxtvepg package. But I admit that my knowledge about licensing is pretty low. There is also the way to introduce two new packages (no subpackages, one for the script and one for the Video-ZVBI Perl module) and remove the script from the nxtvepg package. Of course this also means two more package reviews to work on ;-)
Thanks for the explanation for the situation on this package. From your explanation the license fix is not needed. (But the license tag on the spec file needs fixing, it should be "License: GPLv2 and GPLv3+". Would you fix that? I will check the other issues on your srpm (if any) later, however as currently I am on semi- vacation and the response from me may be less frequent.)
For 2.8.1-1: * License tag - As said above, the license tag should be "GPLv2 and GPLv3+" * desktop file prefix - Desktop file install guidelines changed and now for new packages "--vendor=fedora" must be removed on Fedora. https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor
Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.1-2.fc10.src.rpm %changelog * Sat Nov 29 2008 Torsten Rausche <trausche> - 2.8.1-2 - The Teletext grabber is licensed under GPLv3+, changed License tag - New packages should not use "--vendor=fedora" for desktop files anymore The package should be in good shape again. I noticed Tom's proposal some time ago. But I didn't notice a change in the guidelines. Anyway I think the change is a good idea.
Umm... Sorry for delay... Perhaps I missed the mail from this bug. I will check it later.
Okay, now for 2.8.1-2: * Duplicate file entry ------------------------------------------------------- 129 %files .... 142 %{_datadir}/%{name}/ 143 %attr(0755, root, root) %{_datadir}/%{name}/tv_grab_ttx.pl ------------------------------------------------------- - This causes the warning like ------------------------------------------------------- 276 warning: File listed twice: /usr/share/nxtvepg/tv_grab_ttx.pl ------------------------------------------------------- because the %files entry "%{_datadir}/%{name}" contains the directory %_datadir/%name itself and all files/directores/etc under this directory. For this package it is better that you explicitly modify the permission of this script at %install like ------------------------------------------------------- %install rm -rf %{buildroot} make %{?_smp_mflags} \ ..... install ..... ..... chmod 0755 %{buildroot}%{_datadir}/%{name}/*.pl ------------------------------------------------------- and remove "%attr(........ tv_grah_ttx.pl" line. Now - This package itself is okay (but please fix above) - Now I will sponsor you (if you are still seeking for sponsors) --------------------------------------------------------------------- This package (nxtvepg) is APPROVED by mtasaka --------------------------------------------------------------------- Please follow the procedure written on: http://fedoraproject.org/wiki/PackageMaintainers/Join from "Get a Fedora Account". After you request for sponsorship a mail will be sent to sponsor members automatically (which is invisible for you) which notifies that you need a sponsor. After that, please also write on this bug for confirmation that you requested for sponsorship and your FAS (Fedora Account System) name. Then I will sponsor you. If you want to import this package into Fedora 10/9, you also have to look at http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT (after once you rebuilt this package on koji Fedora rebuilding system). If you have questions, please ask me.
OK, the last flaw is fixed in Spec URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg.spec SRPM URL: http://www.torsten.rausche.net/fedora/review/nxtvepg/nxtvepg-2.8.1-3.fc10.src.rpm %changelog * Sun Dec 07 2008 Torsten Rausche <trausche> - 2.8.1-3 - The script permissions are better handled in the install section (This removes the "File listed twice" warning during the package build)
===> Requested sponsorship ===> FAS account name: trausche
Okay, now I am sponsoring you. Please follow "Join" wiki again.
New Package CVS Request ======================= Package Name: nxtvepg Short Description: A nexTView EPG decoder and browser Owners: trausche Branches: F-9 F-10 EL-5 InitialCC:
cvs done.
- Package builds done - Closing this ticket
nxtvepg-2.8.1-3.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/nxtvepg-2.8.1-3.fc9
nxtvepg-2.8.1-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/nxtvepg-2.8.1-3.fc10
nxtvepg-2.8.1-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
nxtvepg-2.8.1-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.