Bug 666763

Hi Guido,

since this is your first package submission, you need a sponsor who approves you. Thus, add FE-NEEDSPONSOR to the Blocks field above, and see the following web pages for further information:
https://fedoraproject.org/wiki/PackageMaintainers/Join
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Here are some quick comments on your spec file:
- use macro %{version} in Source0 to simplify future updates

- According to COPYRIGHT, the license is GPLv3+ (because of the addition
  "or (at your option) any later version"). This should be reflected in the 
  License field.

- drop BR: autoconf automake as both packages are picked up automatically

- drop Requires: libax25, ncurses (the dependency is detected automatically)

- drop INSTALL from %files (not needed in a binary package)

- drop empty file NEWS

$ rpmlint /var/lib/mock/fedora-14-x86_64/result/*.rpm
ax_emergency_listen.x86_64: E: explicit-lib-dependency libax25
ax_emergency_listen.x86_64: E: zero-length /usr/share/doc/ax_emergency_listen-1.3.2/NEWS
3 packages and 0 specfiles checked; 2 errors, 0 warnings.

Also, don't use trademark characters in Summary and %description. See
http://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description

Thanks Martin, I am very grateful to you for the comments. I have updated the SPEC file, removed the Trademark symbol and introduced the sponsor block.

A new release is available for review at http://iz6rdb.trentalancia.com/en/ax_emergency_listen-1.3.2-2.fc11.src.rpm

It adds an init script and a configuration file so that the program can be run as a sort of daemon. Also it makes ax25-tools "Required", because it is very useful to have it installed for configuring the AX25 interface beforehand.

No reviewer ? No sponsor ? (as yet)

This ticket has existed for just under a day so far; I'm not sure how fast you believe the process is but it's a bit early to be anxious about obtaining a sponsor.

Have you read the documentation Martin provided in comment 1?  Have you done any package review work?  Looked over any of the 250+ other tickets awaiting reviews?  We have far fewer sponsors than new contributors and some folks have been waiting for months.  Helping out with that and demonstrating your understanding of packaging will help to attract a sponsor.

Personally I'm not interested in reviewing this because if I can't figure out what the package is supposed to do from reading the %description, I rarely bother.  Jargon like "APRS" and "Mic-E" might mean something to someone, but they mean nothing to me.  It's generally considered polite to try to define acronyms and such in your package description, if for no other reason than it gives more useful search terms.

Thanks very much for your comments Jason, I have improved the description according to your tips which have been much appreciated. The latest available release is now 1.3.2-4 available at:

http://iz6rdb.trentalancia.com/en/ax_emergency_listen-1.3.2-4.src.rpm

Having already written the software, it is not easy to find the time to package it and build it for every distribution available and then also review other packages in every distribution. But I will try to do my best...

I am getting the following rpmlint error:

E: invalid-build-requires libax25-devel

But the package requires libax25 for running and libax25-devel when building from source (requires for example <netax25/axconfig.h>). I cannot access an x86_64 installation but libax25-devel is also available there...

What does the error really mean ?

rpmlint -I invalid-build-requires just says:
  Your source package contains a dependency not compliant with the lib64 naming.
  This BuildRequires dependency will not be resolved on lib64 platforms (eg.
  amd64).
which isn't very helpful.  So, rpmlint source to the rescue.  These three lines from TagsCheck.py are relevant:

lib_devel_number_regex = re.compile('^lib(.*?)([0-9.]+)(_[0-9.]+)?-devel')
if is_source and lib_devel_number_regex.search(d[0]):
  printError(pkg, 'invalid-build-requires', d[0])

So, libax25-devel trips the warning.  I can't see why it should, so the complaint looks bogus to me.  I suspect that said warning is more meaningful on some other distribution having that would use a naming convention like 'libfoo32-devel'.  I've really only experience with Fedora, though, so I can't say what distribution that would be.

I'd simply note that the rpmlint complaint is invalid and move on.

I don't get the mentioned rpmlint warning when checking the packages based on the SRPM given in comment #6 (mock build, f14, x86_64). However, there are a some other things to be fixed:

$ rpmlint /var/lib/mock/fedora-14-x86_64/result/*.rpm
ax_emergency_listen.src: W: strange-permission ax_emergency_listen_helper 0755L
ax_emergency_listen.src: W: strange-permission ax_emergency_listen.init 0755L
ax_emergency_listen.src:93: W: macro-in-%changelog %{_sysconfdir}
ax_emergency_listen.src:66: W: mixed-use-of-spaces-and-tabs (spaces: line 66, tab: line 1)
ax_emergency_listen.x86_64: W: non-conffile-in-etc /etc/sysconfig/ax_emergency_listen
ax_emergency_listen.x86_64: W: no-manual-page-for-binary ax_emergency_listen_helper
ax_emergency_listen.x86_64: W: service-default-enabled /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.x86_64: W: missing-lsb-keyword Required-Start in /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.x86_64: W: missing-lsb-keyword Required-Stop in /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.x86_64: W: service-default-enabled /etc/rc.d/init.d/ax_emergency_listen
3 packages and 0 specfiles checked; 0 errors, 10 warnings.

Thanks Jason and thanks Martin for your latest comments and interest !

Jason and Martin: I was using rpmlint version 1.0 and not on Fedora. So perhaps, it is a warning being triggered only by upstream rpmlint. Let's leave the issue as it is.

Martin: yes, I do get more or less the same Warnings that you get. More specifically:

[root@tesla rpmlint-1.0]# python2.6 -O -u rpmlint.py -C . /home/guido/rpmbuild/SRPMS/ax_emergency_listen-1.3.2-4.src.rpm 
ax_emergency_listen.src: W: spelling-error %description -l en_US startup -> start up, start-up, starter
ax_emergency_listen.src: W: strange-permission ax_emergency_listen-1.3.2.tar.bz2 0664
ax_emergency_listen.src: W: strange-permission ax_emergency_listen.spec 0664
ax_emergency_listen.src:93: W: macro-in-%changelog %{_sysconfdir}
ax_emergency_listen.src:66: W: mixed-use-of-spaces-and-tabs (spaces: line 66, tab: line 1)
1 packages and 0 specfiles checked; 3 errors, 6 warnings.

- Fixed the spelling issue in release 1.3.2-5 that is about to come;
- Don't know what's wrong with permissions set to 664 (or 644) on the source archive ???
- Fixed the use of macros in changelog (rel 5);
- Fixed the use of spaces (rel 5).


[root@tesla rpmlint-1.0]# python2.6 -O -u rpmlint.py -C . /home/guido/rpmbuild/SRPMS/ax_emergency_listen-1.3.2-4.src.rpm /home/guido/rpmbuild/RPMS/i386/ax_emergency_listen-1.3.2-4.fc11.i386.rpm 
ax_emergency_listen.src: W: spelling-error %description -l en_US startup -> start up, start-up, starter
ax_emergency_listen.src: W: strange-permission ax_emergency_listen-1.3.2.tar.bz2 0664
ax_emergency_listen.src: W: strange-permission ax_emergency_listen.spec 0664
ax_emergency_listen.src:93: W: macro-in-%changelog %{_sysconfdir}
ax_emergency_listen.src:66: W: mixed-use-of-spaces-and-tabs (spaces: line 66, tab: line 1)
ax_emergency_listen.i386: W: manpage-not-compressed bz2 /usr/share/man/man1/ax_emergency_listen.1.gz
ax_emergency_listen.i386: W: spelling-error %description -l en_US startup -> start up, start-up, starter
ax_emergency_listen.i386: W: unstripped-binary-or-object /usr/bin/ax_emergency_listen
ax_emergency_listen.i386: W: non-conffile-in-etc /etc/sysconfig/ax_emergency_listen
ax_emergency_listen.i386: W: no-manual-page-for-binary ax_emergency_listen_helper
ax_emergency_listen.i386: W: missing-lsb-keyword Required-Start in /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: missing-lsb-keyword Required-Stop in /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: service-default-enabled /etc/rc.d/init.d/ax_emergency_listen
2 packages and 0 specfiles checked; 5 errors, 15 warnings.

- Fixed the spelling issue in release 1.3.2-5 that is about to come;
- Don't know what's wrong with permissions set to 664 (or 644) on the source archive ???
- Fixed the use of macros in changelog (rel 5);
- Fixed the use of spaces (rel 5);
- Why should I strip binaries ? To loose debugging information when at the end it is compiled with it ?
- What's wrong with the config file being place in /etc/sysconfig (is there a list of known config files somewhere, that is not listing mine ?) ?
- Fixed the init script with empty Required-Start and Required-Stop; in the end, the only thing that is required is that the (kiss) interface has been configured with kissattach or something equivalent to that; it doesn't even need the network interface to be up (such as ax0);
- It's really pointless to provide a manual page for the daemonizer script (by the way, do you have any better idea on how to "daemonize" without touching the source files ?);
- The service is enabled by default, otherwise ? Who decides what is good and what is bad ? Other packages with init files are doing the same... And if the user is installing the package there is a very good chance that he/she intends to use it;
- Manual page not compressed in bzip2 ?? No idea. You don't even have got that, Martin. Something to do with upstream rpmlint 1.0 that I am using.

Honestly, apart from those warnings that I have already fixed in release 5, I would say everything is fine, at the end it's only warnings and the Packaging Guidelines don't even mention about warnings.

However, I remain open to any advice on possible fixes.

The latest release is now 1.3.2-5 and it's available at:

http://iz6rdb.trentalancia.com/en/ax_emergency_listen-1.3.2-5.src.rpm

(In reply to comment #10)
> - Don't know what's wrong with permissions set to 664 (or 644) on the source
> archive ???

I suggest just to change the file permissions to 644 in the srpm. It makes rpmlint happy and doesn't hurt as install assigns the proper permissions anyway.


> - Why should I strip binaries ? To loose debugging information when at the end
> it is compiled with it ?

You should not strip the binaries manually. rpmbuild does that automatically when creating the debuginfo package. Obviously, your rpmbuild utility behaves a bit different.


> - What's wrong with the config file being place in /etc/sysconfig (is there a
> list of known config files somewhere, that is not listing mine ?) ?

config files must be marked with %config(noreplace) or plain %config. See
http://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files


> - Fixed the init script with empty Required-Start and Required-Stop; in the
> end, the only thing that is required is that the (kiss) interface has been
> configured with kissattach or something equivalent to that; it doesn't even
> need the network interface to be up (such as ax0);

OK. You should also have a look at
http://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscript_packaging
and adapt the iniscript and the spec file accordingly.



> - It's really pointless to provide a manual page for the daemonizer script 
> (by the way, do you have any better idea on how to "daemonize" without 
> touching the source files ?);

The warning about the missing manpage can be ignored, of course.


> - The service is enabled by default, otherwise ? Who decides what is good and
> what is bad ?

The Fedora guidelines want the packagers not to start services by default. See
http://fedoraproject.org/wiki/Packaging/SysVInitScript#Why_don.27t_we....



> - Manual page not compressed in bzip2 ?? No idea. You don't even have got 
> that, Martin. Something to do with upstream rpmlint 1.0 that I am using.

Fedora's rpmbuild compresses manpages by default. So no action is required here.

Hi Martin,

thanks again for your thoughtful comments !

- Fixed the third issue (in rel 6), very good point I had forgotten that !
- Fixed the init script and the spec for the chkconfig issue (rel 6), although in truth it's not a "network listening" thing, it has nothing to do with network interfaces, not even the ax25 ones (which could well be inactive), it just deals with the serial interface to which, supposedly, a TNC is connected; and also, have a look below...
- The very last issue, from my understanding, is about the manual page being compressed using gzip rather than bz2 and possibly this is something to do with the fact that I am using rpmlint from upstream. Anyway, something not to bother with...

But then, have a look at what happens with the binary package after removing completely %post and %postun:

ax_emergency_listen.i386: E: init-script-without-chkconfig-postin /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: E: init-script-without-chkconfig-preun /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: no-default-runlevel /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/ax_emergency_listen

and after re-adding %post and %postun:

ax_emergency_listen.i386: W: no-default-runlevel /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/ax_emergency_listen

I have just followed the Guidelines and your suggestions.

Of course, rpmlint on the SRPMS is clean.

(In reply to comment #13)
> - Fixed the init script and the spec for the chkconfig issue (rel 6), although
> in truth it's not a "network listening" thing, it has nothing to do with
> network interfaces, not even the ax25 ones (which could well be inactive), it
> just deals with the serial interface to which, supposedly, a TNC is connected;
> and also, have a look below...

OK. As far as I understand the guideline text, it doesn't matter whether the service listens to network ports or not. When using the snippets, you're usually on the safe side.


> - The very last issue, from my understanding, is about the manual page being
> compressed using gzip rather than bz2 and possibly this is something to do 
> with the fact that I am using rpmlint from upstream. 

Yes, sorry. I didn't read the message carefully enough. :)


> But then, have a look at what happens with the binary package after removing
> completely %post and %postun:

Why did you remove %post and %postun? They should be present (together with %preun) as they are in the spec file snippets given at
http://fedoraproject.org/wiki/Packaging/SysVInitScript#Initscript_packaging


> and after re-adding %post and %postun:
> 
> ax_emergency_listen.i386: W: no-default-runlevel
> /etc/rc.d/init.d/ax_emergency_listen
> ax_emergency_listen.i386: W: missing-lsb-keyword Default-Stop in
> /etc/rc.d/init.d/ax_emergency_listen

Since you haven't posted the latest version yet, I can't say anything about the origin of these warnings. They are probably related to missing parameters in the header of the init script.

Ok, I have just uploaded the latest release 1.3.2-6 to:

http://iz6rdb.trentalancia.com/en/ax_emergency_listen-1.3.2-6.src.rpm

Everything should be sorted in the best manner. There were rpmlint warnings about:

ax_emergency_listen.i386: W: missing-lsb-keyword Required-Start in /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: missing-lsb-keyword Required-Stop in /etc/rc.d/init.d/ax_emergency_listen
ax_emergency_listen.i386: W: missing-lsb-keyword Default-Stop in /etc/rc.d/init.d/ax_emergency_listen

which obviously are in conflict with the Packaging Guidelines, but I preferred to keep rpmlint silent. At the end, it's just exactly the same either ways, as those lines are now empty.

Do you need anything about ways to get this package sponsored and finally getting it pushed into the distribution ? I have also done a little bit of an informal review for another package, so should I just keep waiting ?

And I forgot, I have also reported a bug and proposed a patch to fix it for an important APRS package. So I really expect someone to push this package, as it is now beginning to take more time for packaging and other collateral stuff than it took to develop the utility itself !

(In reply to comment #16)
> So I really expect someone to push this package, as it
> is now beginning to take more time for packaging and other collateral stuff
> than it took to develop the utility itself !

Sorry, Guido, but it doesn't work this way. Preparing clean packages is as important as developing working program code. Thus, it can take some time to get a package approved. As Jason already mentioned, the initial sponsoring process can delay the approval of the first package because there are quite a few new contributers waiting to get sponsored (see http://fedoraproject.org/PackageReviewStatus/NEW.html for example). 

Joining the packager group requires that you're willing to invest time in preparing and maintaining packages and that you have an understanding of the packaging guidelines. The latter is usually shown by doing some informal reviews of other packager's submissions.

Personally, I'm pretty busy with my job at the moment, and I still have two contributors waiting for my sponsorship which also takes time. So I'm currently not able to sponsor you.

BTW, if you don't have the time and/or don't want to maintain this package yourself, you can also add your utility to the package wishlist (http://fedoraproject.org/wiki/PackageMaintainers/WishList) and wait for some other packager to pick it.

(In reply to comment #17)
> (In reply to comment #16)
> > So I really expect someone to push this package, as it
> > is now beginning to take more time for packaging and other collateral stuff
> > than it took to develop the utility itself !
> 
> Sorry, Guido, but it doesn't work this way. Preparing clean packages is as
> important as developing working program code.

Of course, I understand this. But consider the point of someone who developed the utility for free, has done already most of the packaging, has done an informal review on another package, has submitted a bug report and a relative patch to fix it. Everything for free.

And in the end, the utility can be just fetched from the Internet as it is (tar archive, GNU packaging), built and installed on the fly on any recent distribution...

Also, the latest release (1.3.2-6) looks fine to me. It adheres to Packaging Guidelines, it builds and installs fine on Fedora.

> Thus, it can take some time to get a package approved.

If it is just a matter of waiting, then that's fine to me.

> Joining the packager group requires that you're willing to invest time in
> preparing and maintaining packages and that you have an understanding of the
> packaging guidelines. The latter is usually shown by doing some informal
> reviews of other packager's submissions.

I have no interest at the moment for joining the packager or maintainer group other than what relates this package. For example, I am already doing upstream testing of most Linux stuff.

> BTW, if you don't have the time and/or don't want to maintain this package
> yourself, you can also add your utility to the package wishlist
> (http://fedoraproject.org/wiki/PackageMaintainers/WishList) and wait for some
> other packager to pick it.

If this is the only solution, then I could do that. But what's wrong with the latest release ? What prevents it from being pushed in ? If there is something else that I can do in a reasonably short time, I will do. Otherwise if it's too complicated, then we'd better leave it to the WishList or let somebody pick this request and follow up...

(In reply to comment #18)
> Of course, I understand this. But consider the point of someone who developed
> the utility for free, has done already most of the packaging, has done an
> informal review on another package, has submitted a bug report and a relative
> patch to fix it. Everything for free.

Yes, sure. I'm also an upstream developer and a Fedora packager. All this work is done in my spare time and offered for free too. This is probably true for most of the Fedora people. So you're in good company.


> If this is the only solution, then I could do that. But what's wrong with the
> latest release ? What prevents it from being pushed in ? 

No, it's not the only solution. The point is that you can't open a review request for someone else. If a package is approved, it's assigned to the person who created the review request. This person is responsible for the package and has to maintain it, i.e request git distro branches, create koji builds, push the builds to the update server etc. Thus, simply speaking, it's not possible that someone else pushes the package of this ticket into Fedora. So, one aspect that prevents your latest release from being added to Fedora is that you're not sponsored yet.

(In reply to comment #19)
> (In reply to comment #18)
> Yes, sure. I'm also an upstream developer and a Fedora packager. All this work
> is done in my spare time and offered for free too. This is probably true for
> most of the Fedora people. So you're in good company.

Oh yes, good company for sure !

> So, one aspect that prevents your latest release from being added to Fedora
> is that you're not sponsored yet.

I suppose it's just a matter of waiting a sponsor... Let's wait.

The idea is that the utility could be useful to newbies ham and it can do something quite useful such as picking emergency packets on the air and reacting upon receiving them. Of course, it can also be used by non-newbies and by non-hams (as it is not transmitting on the air, then usually no license is required). In fact, there are similar pieces of code but they are intended to integrate with GUI applications and pop-up windows. I believe this utility is original in the sense that it is intended to automate the task of handling emergency packets without requiring an operator to sit in front of a GUI. Also, where and when legally possible alerts of any kind (email, text messages, facsimiles or whatever else) can be forwarded directly to public emergency services. And everything is done with just a few lines of very simple code.

Thanks again very much for your support Martin !

Hi Guido,

I spotted this Review Request while I was adding another one of mine to the list. (I'm working on some APRS tool packaging too) -- Have a look at bug #669010 and the soon-to-be-submitted aprsg package (am just working on that now). Also are you aware of http://fedoraproject.org/wiki/SIGs/AmateurRadio 

Good luck with your sponsorship request!

Andrew

I'm looking over the oldest NEEDSPONSOR tickets and came across this one which seems to have fallen through the cracks.  I'm guessing you never got in contact with anyone in the amateur radio SIG who could help you out.

In any case I can't promise anything as my time is limited, but if you're still interested in submitting this, let me know and I'll see what I can do.

Hi Jason,

it's free ham radio software derived from free ham radio software.

At the moment is completely unmantained as I have no time for it.

Therefore, feel free to do whatever you like with it under the terms of the LICENSE and without any warranty of any kind.

There might or there might not be other releases.

I guess the above means that you don't wish to continue to submit this package to Fedora, so I'll close this ticket out.