On Sat, 08 Jul 2006 14:24:57 +0100, Andy Burns wrote: > Jason L Tibbitts III wrote: > > > Some sat for so long that it would not be surprising > > to me if the the submitters had completely lost interest. > > I admit I *partly* lost interest in getting my first package > reviewed/sponsored, I don't know if I haven't followed right procedures, > or haven't spoken up loudly enough to attract attention > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179758 There has been quite some traffic in that ticket. Feedback on mistakes in the packaging, for instance. 17 comments in total is much more than many trivial-to-review packages get. One cannot say that you have been ignored. :) Let me point out some things here instead of posting this in bugzilla: The ticket is assigned to you instead of the default dummy owner of Package Review tickets. This may be misunderstood by anyone who browses the FE-NEW list, looking for "unassigned" package reviews. When loading the ticket, it appears as if Paul Howarth is doing reviews already. Some of the package revisions look half-hearted, though. As somebody who has contributed reviews since the era before the Fedora Project, let me tell you that it can also happen that reviewers lose interest if the review'n'approval process gets too long and tiresome for a package. This can lead to potential sponsors waiting longer and observing you and your packages for a longer time. Usually it should be come obvious that the package submitter spends more time and thought into the package than the reviewer. Because it is the packager who wants to maintain the package later on. From my point of view, as much as I like to sponsor new contributors as soon as they provide one or two clean packages (fixing any reported issues without too much trouble), I would consider it a mistake to sponsor somebody, who will likely run into too many problems when working inside Fedora Extras CVS, with the buildsys, with the need to respond to bug reports, and so on. In addition to perusing existing documents, new [unsupported] contributors can seek for communication on fedora-extras-list actively, ask questions, request help and hints and demonstrate general interest in becoming a packager. On the contrary, new contributors who modify their offered packages only reluctantly or half-heartedly, give the [possibly false] impression that they don't really want to adhere to packaging guidelines and project policies. If a reviewer supplies a patch against your .spec, accept it or refuse it and discuss the reason. As a rule of thumb: don't modify your package too much in response to reviewer's feedback. Better ask before applying major changes, especially if you are not sure about them. This makes reviewing much easier. Taking a brief look at your latest package: $ rpmlint eiciel-0.9.2-4.src.rpm E: eiciel hardcoded-library-path in /usr/lib/debug/%{_bindir}/%{name}.debug E: eiciel hardcoded-library-path in /usr/lib/debug/%{_libdir}/nautilus/extensions-1.0/lib%{name}*.debug This smells like "packager confusion". Right now I can't take the time to read all 17 comments in the review ticket (writing all this probably has taken more, but well, ...). There is cleanup in the spec file needed. The debug files need not be excluded at all. They are not included in your package unless you include them explicitly or recursively (e.g. by including %_libdir which in turn would be a packaging mistake). > BuildRequires: nautilus Although this works, you really want "nautilus-devel", the virtual package for the Nautilus extension development files. "Nautilus" is written with upper-case 'N', so I would do the same in the package %description. > %{_datadir}/%{name}/* With this, the directory %{_datadir}/%{name} would not be included in your package. Listing the binary rpm confirms it: drwxr-xr-x /usr/share/eiciel/doc drwxr-xr-x /usr/share/eiciel/doc/C -rw-r--r-- /usr/share/eiciel/doc/C/eiciel.xml The fix is this %files entry: %{_datadir}/%{name}/ This includes the directory and the entire tree in it. The explicit slash at the end makes the .spec file easier to read. You see immediately that this entry includes a directory [recursively], instead of a single file. The package listing will look like (notice the top dir!): drwxr-xr-x /usr/share/eiciel drwxr-xr-x /usr/share/eiciel/doc drwxr-xr-x /usr/share/eiciel/doc/C -rw-r--r-- /usr/share/eiciel/doc/C/eiciel.xml > Summary: Eiciel graphical access control list editor Better: Summary: Graphical access control list (ACL) editor In wide parts of the RPM packaging world and for the majority of packages, it is considered bad taste to repeat or mention an application's name in the Summary. There is the package name "eiciel", which is very likely displayed together with the summary. And for anyone who doesn't know that "Eiciel" is a name, above summary is confusing. The one important thing to mention is the summary is to give a brief description of what this package does: it provides a graphical access control list editor. Everything beyond that can go into the %description. > -rw-r--r-- /usr/share/applications/eiciel.desktop > -rw-r--r-- /usr/share/applications/fedora-eiciel.desktop Two desktop entries. The one that appeared here in the menu does not work: Could not launch menu item Details: Failed to execute child process "/home/roger/eiciel/TEST/bin/eiciel" (No such file or directory) This indicates that you either want to remove "eiciel.desktop" or use it as the source for "desktop-file-install", adding vendor and your own changes, and using --delete-original to get rid of it. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
