Spec URL: http://www.seekline.net/fedora/pyicq-t.spec SRPM URL: http://www.seekline.net/fedora/pyicq-t-0.8.1.5-1.fc11.src.rpm Description: Hi all, The package pyicq-t already exists but I would like to become a co-maintainer. I already talked to the package maintainer and he said that it would be good to have a co-maintainer because he could need some support/help. I already created a dozen packages myself (but never released them to the public) and would like to contribute now. I'm using pyicq-t for a long time on my own servers. I added myself to the package and the owner accepted the watchcommits and watchbugzilla perms. I already did some changes to the package. The most import one is that the daemon shouldn't run as root. This is a security bug/fix! A new upstream release is out since August 24. And some minor changes. The thing left is a sponsor, who would be willing to sponsor me?
Could we see the packages that you have not released in public, or are they for some reason or another proprietary (e.g. done for a company under contract)? As discussed in the mailing list, any extra indication of packaging skill would help. There are a lot of packages that are waiting for reviewers that you can do pre-reviews for (say, 2 or 3); but looking at your previous packages would work too, even if they can't end up in Fedora for one reason or another.
Created attachment 360878 [details] quick creation of a RPM package for crystalspace
Created attachment 360880 [details] my favourite project the GNOME keyring XML interface
Created attachment 360881 [details] a quick creation of a RPM package for pbbuttonsd
(In reply to comment #1) > Could we see the packages that you have not released in public, or are they for > some reason or another proprietary (e.g. done for a company under contract)? Sure, I attached three SPEC files which I created in the last year or two. A lot of other SPEC files I already deleted because I didn't need them anymore. But since I'm using pyicq-t for a while I would like to contribute to this package. For example making it more compliant/easier to write a SELinux policy and so on. > As discussed in the mailing list, any extra indication of packaging skill would > help. There are a lot of packages that are waiting for reviewers that you can > do pre-reviews for (say, 2 or 3); but looking at your previous packages would > work too, even if they can't end up in Fedora for one reason or another. Yeah, I will have a look at some other packages too.
(In reply to comment #1) > As discussed in the mailing list, any extra indication of packaging skill would > help. Oh btw I'm not sure if this counts but I also created in the last five to ten years a couple of Gentoo ebuilds, Debian APT packages and one package for OpenBSD. Nothing Fedora related but these distributions have their packaging guidelines/standards too. But again I was to lazy to publish these packages too ;-) Since for a couple of years I stick to Fedora and will use this distribution for a long time I guess.
Spec URL: http://www.seekline.net/fedora/pyicq-t.spec SRPM URL: http://www.seekline.net/fedora/pyicq-t-0.8.1.5-2.fc11.src.rpm Created a new RPM for some minor changes. For example, added the requirement shadow-utils like indicated here: https://fedoraproject.org/wiki/Packaging:UsersAndGroups % rpmlint pyicq-t-mysql-0.8.1.5-2.fc11.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. % rpmlint pyicq-t-0.8.1.5-2.fc11.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. % rpmlint pyicq-t-0.8.1.5-2.fc11.noarch.rpm pyicq-t.noarch: W: non-standard-uid /var/run/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-gid /var/run/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-uid /etc/pyicq-t/config.xml pyicqt pyicq-t.noarch: W: non-standard-gid /etc/pyicq-t/config.xml pyicqt pyicq-t.noarch: E: non-readable /etc/pyicq-t/config.xml 0600 pyicq-t.noarch: W: non-standard-uid /var/spool/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-gid /var/spool/pyicq-t pyicqt pyicq-t.noarch: E: non-standard-dir-perm /var/spool/pyicq-t 0700 pyicq-t.noarch: W: non-standard-uid /etc/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-gid /etc/pyicq-t pyicqt pyicq-t.noarch: E: non-standard-dir-perm /etc/pyicq-t 0700 pyicq-t.noarch: W: doc-file-dependency /usr/share/doc/pyicq-t-0.8.1.5/managessi.py /usr/bin/env pyicq-t.noarch: W: doc-file-dependency /usr/share/doc/pyicq-t-0.8.1.5/migrate.py /usr/bin/env pyicq-t.noarch: W: doc-file-dependency /usr/share/doc/pyicq-t-0.8.1.5/managessi.py R pyicq-t.noarch: W: doc-file-dependency /usr/share/doc/pyicq-t-0.8.1.5/migrate.py R pyicq-t.noarch: W: no-reload-entry /etc/rc.d/init.d/pyicq-t 1 packages and 0 specfiles checked; 3 errors, 13 warnings. I guess the warnings non-standard-{g,u}id and errors non-standard-dir-perm can be ignored. The config files in /etc/pyicq-t shouldn't be readable by any other user because they contain clear text passwords. The daemon spool files under /var/spool/pyicq-t contain all clear text passwords for all clients. Therefore it shouldn't be readable too. I'm unsure about the doc-file-dependency warning. Since /usr/bin/env will be available on all other systems, my guess is that we can ignore this too. Or what does the crowd say? Additionally the warning no-reload-entry can be ignored too, or does it? Not every daemon needs a reload entry, right? For the last two warnings I couldn't find something in here: https://fedoraproject.org/wiki/Common_Rpmlint_issues So I'm not 100% sure what to do.
> pyicq-t.noarch: W: no-reload-entry /etc/rc.d/init.d/pyicq-t https://fedoraproject.org/wiki/Packaging:SysVInitScript#Required_Actions > pyicq-t.noarch: W: doc-file-dependency "rpmlint -i ..." explains this. > -%defattr(-,root,root,-) > +%defattr(0644,root,root,0755) AFAIK, this doesn't improve anything (contrary to the %attr usage). [...] * The "config.patch" doesn't match with the initscript and spec file. Please review carefully. * The rpmdiff against pyicq-t-0.8.1.3-2 reveals two https://fedoraproject.org/wiki/Packaging:UnownedDirectories
Spec URL: http://www.seekline.net/fedora/pyicq-t.spec SRPM URL: http://www.seekline.net/fedora/pyicq-t-0.8.1.5-3.fc11.src.rpm (In reply to comment #8) > > pyicq-t.noarch: W: no-reload-entry /etc/rc.d/init.d/pyicq-t > > https://fedoraproject.org/wiki/Packaging:SysVInitScript#Required_Actions Yeah added try-restart, reload and force-reload to the init script. > > pyicq-t.noarch: W: doc-file-dependency > > "rpmlint -i ..." explains this. Jep, removed the execution permissions. > > -%defattr(-,root,root,-) > > +%defattr(0644,root,root,0755) > > AFAIK, this doesn't improve anything (contrary to the %attr usage). I added the 0644 perms because I wanted to circumvent the problem with a couple of files which where accidentally labelled as executables. Now I changed that and do a chmod in the %install section. Additionally I will inform upstream. Maybe they want to change this too. Because the executable files don't have a sha-bang, so no real intention to execute them. > * The "config.patch" doesn't match with the initscript and spec file. Please > review carefully. Argl, your right. A typo which I looked over and over. > * The rpmdiff against pyicq-t-0.8.1.3-2 reveals two > https://fedoraproject.org/wiki/Packaging:UnownedDirectories Hmm, I can't reproduce this. Can you tell me your exact commands? The latest changes are in release 3.
Spec URL: http://www.seekline.net/fedora/pyicq-t.spec SRPM URL: http://www.seekline.net/fedora/pyicq-t-0.8.1.5-4.fc11.src.rpm In https://fedoraproject.org/wiki/Packaging:SysVInitScript a couple of suggestions are made for a proper init script. I followed some and changed the file, e.g. the return/exit codes are now much better (exit 2 if invalid arguments, exit 5 if no exec file, exit 6 if no config file). % rpmlint pyicq-t.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. % rpmlint pyicq-t-0.8.1.5-4.fc11.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. % rpmlint pyicq-t-mysql-0.8.1.5-4.fc11.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. % rpmlint pyicq-t-0.8.1.5-4.fc11.noarch.rpm pyicq-t.noarch: W: non-standard-uid /var/run/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-gid /var/run/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-uid /etc/pyicq-t/config.xml pyicqt pyicq-t.noarch: W: non-standard-gid /etc/pyicq-t/config.xml pyicqt pyicq-t.noarch: E: non-readable /etc/pyicq-t/config.xml 0600 pyicq-t.noarch: W: non-standard-uid /var/spool/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-gid /var/spool/pyicq-t pyicqt pyicq-t.noarch: E: non-standard-dir-perm /var/spool/pyicq-t 0700 pyicq-t.noarch: W: non-standard-uid /etc/pyicq-t pyicqt pyicq-t.noarch: W: non-standard-gid /etc/pyicq-t pyicqt pyicq-t.noarch: E: non-standard-dir-perm /etc/pyicq-t 0700 1 packages and 0 specfiles checked; 3 errors, 8 warnings.
From the spec file diff: -%{_datadir}/pyicq-t +%{_datadir}/pyicq-t/data Now the directory %{_datadir}/pyicq-t is no longer included: $ rpm -qf /usr/share/pyicq-t/ file /usr/share/pyicq-t is not owned by any package It can also be seen in "rpm -qlv" or "rpmls" output. Basically you would need to make sure that for every file path a 'd' entry is present: $ rpmls -p /home/qa/tmp/rpm/RPMS/pyicq-t-0.8.1.5-4.fc11.noarch.rpm|grep ^d drwx------ /etc/pyicq-t drwxr-xr-x /usr/share/doc/pyicq-t-0.8.1.5 drwxr-xr-x /usr/share/pyicq-t/data drwxr-xr-x /usr/share/pyicq-t/data/www drwxr-xr-x /usr/share/pyicq-t/data/www/css drwxr-xr-x /usr/share/pyicq-t/data/www/images drwxr-xr-x /usr/share/pyicq-t/src drwxr-xr-x /usr/share/pyicq-t/src/chardet_utf drwxr-xr-x /usr/share/pyicq-t/src/langs drwxr-xr-x /usr/share/pyicq-t/src/legacy drwxr-xr-x /usr/share/pyicq-t/src/legacy/services drwxr-xr-x /usr/share/pyicq-t/src/services drwxr-xr-x /usr/share/pyicq-t/src/tlib drwxr-xr-x /usr/share/pyicq-t/src/web drwxr-xr-x /usr/share/pyicq-t/src/xdb drwxr-xr-x /var/run/pyicq-t drwx------ /var/spool/pyicq-t => Missing is: drwxr-xr-x /usr/share/pyicq-t [...] -touch %{buildroot}/etc/pyicq-t/config.xml +cp config_example.xml %{buildroot}/etc/pyicq-t/config.xml This doesn't achieve what you think it does (according to %changelog). The problem here is that the file is made a %ghost. This also means that somebody (a person or a program) must create it after package installation, or else it won't exist like normal files. [...] The new initscript no longer displays the service name: $ sudo service pyicq-t status (pid 47117) is running... $ sudo service pyicq-t status is stopped [...] Conclusively, just as with ordinary package reviews, after a package has been included in the Fedora Package collection, you are on your own with updates which bear a risk of introducing new problems. One can beat a package to death during review, and with the next update/upgrade some packagers still add stuff that won't pass an official review. You know where to find the packaging guidelines. You are willing to study them in order to make packages adhere to them. But the guidelines don't help with all sorts of problems. In particular, they don't cover run-time issues and lack of testing. So, if I approve your account for the packager group, you can request commit access as planned. Continue to be careful. Test your changes painstakingly. It should become more easy as you're two package maintainers.
Spec URL: http://www.seekline.net/fedora/pyicq-t.spec SRPM URL: http://www.seekline.net/fedora/pyicq-t-0.8.1.5-5.fc11.src.rpm (In reply to comment #11) > From the spec file diff: > > -%{_datadir}/pyicq-t > +%{_datadir}/pyicq-t/data [...] > => Missing is: > drwxr-xr-x /usr/share/pyicq-t Yeah this was the problem. Due to the change of "%defattr(-,root,root,-)" I also changed the directories. The tip to have a look at "rpmls ... | grep ^d" is really good. I checked everything again and should be fine now. > -touch %{buildroot}/etc/pyicq-t/config.xml > +cp config_example.xml %{buildroot}/etc/pyicq-t/config.xml > > This doesn't achieve what you think it does (according to %changelog). The > problem here is that the file is made a %ghost. This also means that somebody > (a person or a program) must create it after package installation, or else it > won't exist like normal files. Quite right. I also removed the ghost entry to create a default config file. > The new initscript no longer displays the service name: > > $ sudo service pyicq-t status > (pid 47117) is running... > > $ sudo service pyicq-t status > is stopped Argl, changed this one too. Had a look at other init scripts how they handle this and changed it accordingly. Actually only a "$prog" was missing. One question left. In https://fedoraproject.org/wiki/Packaging:SysVInitScript they show a init script template. The sha-bang points to "/bin/sh" but my init script uses "/bin/bash". I guess this is no problem, because about 30 other packages installed on my Fedora system are using bash too. Or should we prefer /bin/sh? I know that /bin/sh is only a symlink to bash but maybe someday Fedora will change this behaviour? Yesterday and today I did quite a lot of tests. Installed/removed the package etc. The default config file is now created fine. Also the status of the init script works fine. I checked every allowed init script argument and they all seem to work fine. Additionally I checked all files listed by rpmls. rpmlint still shows only the warnings/errors which are OK and shown in comment #10. Fifth release is out.
> rpmls ... | grep ^d Note, though, that more often you would omit the grep, because it would not reveal unowned directories that don't contain any sub-dirs. E.g. drwxr-xr-x /usr/data/foo -rw-r--r-- /usr/data/foo/file1 -rw-r--r-- /usr/data/foo/file2 -rw-r--r-- /usr/data/foo/bar/file3 (!) drwxr-xr-x /var/spool/foo When doing grep ^d, drwxr-xr-x /usr/data/foo drwxr-xr-x /var/spool/foo there would be no evidence that /usr/data/foo/bar is missing. [...] > The sha-bang points to "/bin/sh" but my init script uses "/bin/bash". It's "shebang". /bin/sh is LSB, but /bin/bash is a requirement of the "initscripts" package, too, and used in many of the scripts (not limited to rc.sysinit). Of course, if you have strong feelings about it, you could avoid using any bash-specific features.