Spec URL: http://gotmail.cvs.sourceforge.net/gotmail/gotmail/gotmail.spec.in?revision=1.3&view=markup SRPM URL: http://heanet.dl.sourceforge.net/sourceforge/gotmail/gotmail-0.8.9-1.src.rpm Description: Gotmail is a perl script to download mail from hotmail.com without user interaction.
Hi - first submission to Fedora Extras - sure I will make mistakes. Please let me know what I need to do - obviously not sure the spec file via CVS is appropriate. Thanks in advance for your response.
The spec file in upstream CVS has a bunch of stuff for building CVS snapshot releases, and also groks the version number from elsewhere in the upstream release. For Fedora Extras, where you probably won't be releasing CVS snapshots at all and where the spec file is maintained in Fedora CVS away from all of the other upstream files, you won't need any of that. So I'd suggest removing all of that and hardcoding the version number in the Version: tag. Since that will then be a different spec file than the one in upstream CVS, you should provide a link to the modified spec file for Fedora Extras in this bugzilla ticket.
Updated spec file - http://svn.sourceforge.net/viewcvs.cgi/gotmail/gotmail/gotmail.spec?view=markup&rev=3
Hello, I'm not a official reviewer but I can help out a little... I tested a binary RPM generated from your source RPM with rpmlint, and it returned: W: gotmail incoherent-version-in-changelog 0.8.7-1 1:0.8.9-1 Your last entry in %changelog contains a version that is not coherent with the current version of your package. You just need to add a changelog into the SPEC to reflect the current version.
That should be fixed - there are two spec files: gotmail.spec.in - which is for our Gotmail CVS builds - IGNORE IT. gotmail.spec - which is for Fedora Extras
The link is not a link to a spec file. You should also post alink to the modified .src.rpm. Quick comments from a look at the spec: * perl requires should be autodetected * why an epoch of 1 and a release of 0? * the -n in %setup isn't needed since it is the default * [ "%{buildroot}" != "/" -a -n "%{buildroot}" ] is not needed %{buildroot} is set
Created attachment 137980 [details] Gotmail spec file Gotmail spec file
Not sure what the first comment means but here is a link to the updated spec file: http://svn.sourceforge.net/viewvc/*checkout*/gotmail/gotmail/gotmail.spec I have also attached the spec file. Also - which modified .src.rpm? Otherwise - all comments have been addressed in the current spec file.
When you update the spec file you should rebuild a .src.rpm and put it on the web. * You can drop Epoch: 0 from the spec file. * a release of 0 is not right, if I recall well, you should set it to 1 and increase it during review, or alternatively, some packagers set it to 0.1 and increase it to 0.2 and so on during review and set it to 1 when imported in cvs. * You misunderstood my comment about perl requires being autodetected. I meant that Requires: perl >= 5 is certainly not needed. * the following are set automatically: %define __find_provides /usr/lib/rpm/find-provides.perl %define __find_requires /usr/lib/rpm/find-requires.perl * in the comment about -n I talked about -n and its argument, not -n on its own. The %setup line is wrong now. * the release is missing from the changelog entries. It is not a blocker, but in general the changelog entries are like 0.8.9-0, or 0.8.9-1 once you have corrected the release...
I have adjusted the spec file based on Comment #9 but I am still missing your point regarding -n. Can you explain further? Sorry a newcomer to RPM and I am a little slow today. http://svn.sourceforge.net/viewvc/*checkout*/gotmail/gotmail/gotmail.spec
Do you mean that "-n gotmail-%{version}" is the default and as such I don't need to specify it?
(In reply to comment #11) > Do you mean that "-n gotmail-%{version}" is the default and as such I don't need > to specify it? Exactly. Except for this issue the spec looks right now, but there is still a link to the .src.rpm missing You can look at most of the other review request, to understand what is missing, like this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204513 Moreover it would allow to follow the chnages, while your spec file only show the latest version (although since it is in svn changes can be tracked, but no that easily).
Okay. I have updated the spec file. I've left in adjusted the %setup -n option as I want to use a structure different than gotmail-%{version} - I want to add %{release} to this also - -n gotmail-%{version}-%{release}. The link to the spec file is: http://prdownloads.sourceforge.net/gotmail/gotmail.spec?download The link to the source rpm is: http://prdownloads.sourceforge.net/gotmail/gotmail-0.8.9-1.src.rpm?download
(In reply to comment #6) > Quick comments from a look at the spec: > > * perl requires should be autodetected > * why an epoch of 1 and a release of 0? The epoch is 1 because the upstream packages have a an epoch of 1 (which was needed because of some version numbering goofiness earlier in the project's history). Having an epoch of zero means that all Extras versions of gotmail will be seen as "older" than even very old upstream packages, so I would suggest reverting the change that got rid of the epoch.
(In reply to comment #14) > The epoch is 1 because the upstream packages have a an epoch of 1 (which was > needed because of some version numbering goofiness earlier in the project's > history). Having an epoch of zero means that all Extras versions of gotmail will > be seen as "older" than even very old upstream packages, so I would suggest > reverting the change that got rid of the epoch. Ok, makes sense. May deserve a comment, though.
Added Epoch back to the spec file. I will document the additional somewhere.
(In reply to comment #13) > Okay. I have updated the spec file. I've left in adjusted the %setup -n option > as I want to use a structure different than gotmail-%{version} - I want to add > %{release} to this also - -n gotmail-%{version}-%{release}. I don't really understand what you mean. You should use a Source which is the upstream source, and may be downloaded with wget or the like (when it is possible, and it is the case here). You can check by doing spectool -g gotmail.spec and verify that the downloaded files are the right ones. Currently, it isn't the case. Then the -n argument is given by the directory name appearing after unpacking the source. As a side note, it would also be more convenient if the spec file and src.rpm could also be easily fetched with wget.
The Source is now fixed and I've copied the source, spec and src.rpm to: http://www.hardening-linux.com/gotmail/gotmail.spec http://www.hardening-linux.com/gotmail/gotmail-0.8.9-1.tar.bz2 http://www.hardening-linux.com/gotmail/gotmail-0.8.9-1.src.rpm They can be downloaded via wget.
We're moving forward, but it's still not right. The source should be the upstream source. spectool -g gotmail.spec currently fails. For example the following works Source: http://heanet.dl.sourceforge.net/sourceforge/gotmail/gotmail-%{version}.tar.bz2 It is still not optimal since there is a sourceforge mirror hardcoded but the generic paths without mirros fails. rpmlint gives: W: gotmail strange-permission gotmail.spec 0600 W: gotmail setup-not-quiet W: gotmail mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 30) The mixed-use-of-spaces-and-tabs may not be problematic. setup-not-quiet is also not a blocker, but I can't see why -q shouldn't be there for this package.
1. I've moved the upstream source, the spec file and the source RPM to the site listed in Comment #18. The spectool -g gotmail.spec should work now. 2. I've added the -q option back to the spec file. 3. I've fixed the mixed use error. 4. I am stumped as to where the strange-permissions error is coming from - the file is 0644 in the package from what I can see.
(In reply to comment #20) > 1. I've moved the upstream source, the spec file and the source RPM to the site > listed in Comment #18. The spectool -g gotmail.spec should work now. The upstream source is in sourceforge you cannot move it! I have checked that you are an upstream developper, but if you want to have the upstream source at a different location than the sourceforge mirrors, you should also add something on the project page. Currently the upstream source is still on sourceforge since it is where people download gotmail from. Regarding the spec file, it is really 600: $ rpm -Uvh ~/tmp/gotmail-0.8.9-1.src.rpm 1:gotmail ########################################### [100%] $ ls -l gotmail.spec -rw------- 1 dumas dumas 1413 oct 9 12:15 gotmail.spec
when you change anything during the review, you should bump the release, add a changelog entry and repost a modified .src.rpm. It is much easier for reviewers to track things.
1. Oh! I see. *thumps head* It is my understanding that the only option on Sourceforge will be to hardcode to one of the mirrors - whilst not optional - it seems to be the only way to maintain the upstream source at Sourceforge. I have hard-coded one of the mirrors for the moment but any suggestions of alternative ideas welcome. 2. I don't see where the gotmail.spec is getting the wrong permissions - any ideas? 3. Also bumped the release increment to 2 for the changes.
$ rpm -qlvp gotmail-0.8.9-1.src.rpm -rw-r--r-- 1 root root 34639 Oct 9 03:18 gotmail-0.8.9-1.tar.bz2 -rw------- 1 root root 1464 Oct 9 03:18 gotmail.spec Use "umask 0022" in your rpmbuild environment. And "chmod 0644 gotmail.spec" before building the src.rpm.
The rpmbuild environment is already set to umask 0022 and the gotmail.spec file is set to 0644 prior to the src.rpm build. I can find no reason why this is being changed to 0600.
(In reply to comment #23) > 1. Oh! I see. *thumps head* It is my understanding that the only option on > Sourceforge will be to hardcode to one of the mirrors - whilst not optional - it > seems to be the only way to maintain the upstream source at Sourceforge. I have > hard-coded one of the mirrors for the moment but any suggestions of alternative > ideas welcome. http://dl.sf.net/gotmail/gotmail-%{version}.tar.bz2 WORKSFORME.
Can the original commenter confirm that the suggestion from Paul also works for them? If so, I will change the spec file again to revert to this URL.
http://dl.sf.net/gotmail/gotmail-%{version}.tar.bz2 Works for me too. However, some hours ago it didn't work. It is indeed the prefered form, but now and then it breaks. Maybe the best thing would be to have 2 source lines, one being commented out such that when one don't work the other is used... Anyway I think using one or the other form is right.
Okay - I've incremented the release, reverted back to the old Source line and added a backup line that is commented out. Only issue I see outstanding is the strange-permissions error which I still can't seem to resolve.
What is the status of this bug?
Again what is the status of this bug?
As far as I can concerned it's ready for submission. The only issue is a permissions one that I can't replicate nor can anyone suggest a fix.
The URL of the spec (Comment #18) directs me to an add for a book. I doubt that this is the correct/intended behavior. I cannot retrieve the src.rpm either: [wolfy@wolfy2 tmp]$ wget http://www.hardening-linux.com/gotmail/gotmail-0.8.9-2.src.rpm --19:50:09-- http://www.hardening-linux.com/gotmail/gotmail-0.8.9-2.src.rpm => `gotmail-0.8.9-2.src.rpm' Resolving www.hardening-linux.com... 64.202.166.216 Connecting to www.hardening-linux.com|64.202.166.216|:80... connected. HTTP request sent, awaiting response... 404 Not Found 19:50:09 ERROR 404: Not Found. [wolfy@wolfy2 tmp]$ wget http://www.hardening-linux.com/gotmail/gotmail-0.8.9-1.src.rpm --19:50:12-- http://www.hardening-linux.com/gotmail/gotmail-0.8.9-1.src.rpm => `gotmail-0.8.9-1.src.rpm' Resolving www.hardening-linux.com... 64.202.166.216 Connecting to www.hardening-linux.com|64.202.166.216|:80... connected. HTTP request sent, awaiting response... 404 Not Found 19:50:13 ERROR 404: Not Found. James, could you please repost the correct URLs ?
http://dl.sf.net/gotmail/gotmail-0.8.9-1.tar.bz2 or http://easynews.dl.sourceforge.net/sourceforge/gotmail/gotmail-0.8.9-1.tar.bz2 If you read the comment thread you can see that I incorrectly moved the source and have since corrected that.
I appologize for not being more clear. It is customary for a reporter to help the potential reviewers by providing the URLs for the spec and for the source rpm under review. I was unable to locate/download either of these. Also, James, please note that a source rpm is _mandatory_ as it has to be made public in the fedora repositories. You could even store it at sf.net if you need to, alongside with the tar.bz2. I suggest replacing http://dl.sf.net with http://downloads.sourceforge.net. It has been proved to be more reliable. After running rpmbuild -ta over the tar.bz2, rpmlint is not happy about the resulting src.rpm: W: gotmail strange-permission gotmail.spec 0600 W: gotmail setup-not-quiet W: gotmail mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 30) First one was already discussed above; second one can be silenced by adding -q to %setup; last one is triggered by usage of spaces in the first lines of the spec, but tabs in the second to fifth lines of make install. It would be nice to fix all these. Since the wiki recommends preserving time stamps, I suggest keeping the timestamp of the man page, especially since the %make step does nothing but concat (and gzip) together the manual page and the AUTHORS file. A simple "touch -r" before and after running make will fix this. Also, using INSTALL="install -p" would probably preserve the timestamp of the gotmail perl script (which does not happen now). As an additional suggestion, it would be nice to remove the extra end of lines from the end of the man page before doing the cat and add comas to the end of each line in AUTHORS, as this will improve the aspect of the final man page. With the current way of generating the page, under the 'Authors" section we get an explanation about who wrote the manual, two empty lines and after that a very long list of names without any separators between them, without an obvious link to the previous paragraph (except of the title of the section ) and without a verb. Despite a sponsor being required, here is a pre-review, in order to push things a bit forward. Please mind that my hotmail account was canceled a couple of years ago for not using it no-idea-for-how long and I have no plans to create another one, so we will need a tester to validate that the script really works and that the Requires: are correct. According to the docs included, curl is the only separate package required. All other requirements seem to be picked by rpm at build time. However I think that this aspect should be tested, too. GOOD - rpmlint checks : see above for source rpm; no output for the binary rpm - package meets naming guidelines; However the first comments refer to Epoch=1; as far as I can see, this has disappeared from this version and I am perfectly happy so, but is Epoch=0 really intended, given comments #14 to #16? - package meets packaging guidelines - license (GPL ) OK, text in %doc, matches source - spec file legible, in am. english - source matches upstream (see above comments about the src.rpm not being supplied), sha1sum: adae68b51f8866eef5670f9f257d34675315d307 gotmail-0.8.9-1.tar.bz2 - the package actually bundles a Perl script included as such in the final rpm, so no compiling involved; the make step only creates a man page - no locales - not relocatable - owns all files/directories that it creates, does not take ownership of foreign files/dirs - no duplicate files - permissions ok (modulo the spec file!) - %clean ok - macro use consistent - code, not content - no need for -docs - nothing in %doc affects runtime - not a GUI, so no need for .desktop file - no static, .pc, .la files - no scriptlets needed SHOULD - builds in mock/devel/x86_64 - does not segfault when run without any arguments and a valid config file.
The src.rpm is in Sourceforge as is the spec file. Sorry I should have made that clearer myself. Try here: http://downloads.sourceforge.net/gotmail/gotmail-0.8.9-4.src.rpm http://downloads.sourceforge.net/gotmail/gotmail.spec All of the changes you've mentioned above have been made. I believe I have fixed the permissions problem also. Where to from here? Thanks for your feedback.
Thank you for your efforts, James, but there still are some problems: The spec from comment #36 says release 4 but the last Changelog entry is for release 3. This is again the same type of error as seen by comment #4. Please also note that it would be wise for the changelog entry to reflect the actual changes. Generic descriptions ("changes to spec for fedora extras") are completely useless to someone who wishes to know if a specific release should be used/updated etc. In my opinions explanations like "Modify makefile to preserve timestamps", "Modify the list of authors in order to obtain a better man page" would have been more appropiate. rpmlint on the src.rpm from comment #36 still complains about permissions: W: gotmail strange-permission gotmail.spec 0600 W: gotmail strange-permission gotmail-0.8.9.tar.bz2 0600 I wonder hou you missed these, since I assume that you do verify the src.rpm using rpmlint before uploading it to sf.net. Maybe your version of rpmlint is not uptodate ? Best option would be to use the one from FE, or even the one in cvs because it has some small patches which have not been included in the released version. The time preserving problem is not fixed either, as you can see from a list of the files included in the generated rpm: [wolfy@wolfy64 result]$ rpm -qlv -p gotmail-0.8.9-4.noarch.rpm|grep Apr -rwxr-xr-x 1 root root 46409 Apr 8 15:42 /usr/bin/gotmail drwxr-xr-x 2 root root 0 Apr 8 15:42 /usr/share/doc/gotmail-0.8.9 -rw-r--r-- 1 root root 24580 Apr 8 05:00 /usr/share/doc/gotmail-0.8.9/ChangeLog -rw-r--r-- 1 root root 346 Apr 8 05:00 /usr/share/doc/gotmail-0.8.9/NEWS -rw-r--r-- 1 root root 1682 Apr 8 05:00 /usr/share/doc/gotmail-0.8.9/PRESSRELEASE -rw-r--r-- 1 root root 3271 Apr 8 15:42 /usr/share/man/man1/gotmail.1.gz [wolfy@wolfy64 result]$ date Sun Apr 8 15:44:38 EEST 2007 One can notice that the application itself, as well as the man page have the current time (15:42), not the one from packaging the tar.bz2 (5:00) Given the fact that you seem to be the upstream maintainer, I strongly suggest to decide what modifications to perform via the tar.bz2 (which would be seen by anyone downloading the source from sf.net) and what you can/should do via the spec file. It is indeed a big plus to have the spec inside the tar, but at least until you have a correct spec, fiddling with the tar will confuse those users who retrieve the file directly from sf.net and see newer files with the same version. For instance the AUTHORS file could have remained as it was and adjust it in %make (using sed or a perl one liner), just before doing the cat which gives the final man. And anyway, if you want to have all authors listed in the man page, why not just add the content of AUTHORS to the gotmail.man file (before packing the tar) so that they can be seen by anyone who retrieves the source tar.bz2 ? Or, as an alternative, why do you modify the man page, and not just include both the man and the AUTHORS files just as they are (and are seen by whoever chooses to grab the tar and not the rpm) ? BTW, mind that Paul Cannon is listed twice in the modified man page because he is present both in gotmail.man and in the long list of authors. And leaving modesty apart, maybe your name should be listed too, as you seem to be the current maintainer. Anyway, these two are just cosmetic, feel free to ignore. WRT your question in comment #37, please see http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored
Thanks for your feedback Wolfgang - much appreciated. I've rebuilt my development box and downloaded a more recent rpmlint. I now see the errors you've identified. I cannot, however, work out what the problem is: 1. All commands I can see use -p to preserve permissions. 2. umask is set to 022 3. Permissions of the spec file are 0644. I cannot see where the spec file is getting the 0600 permissions from. Do you have any other ideas? I have fixed the other issues: 1. Timestamps should now be preserved. 2. AUTHORS file has been merged into the man file. 3. I even added myself to it. :) Given the other changes I will increment the version and upload new packages shortly but I wanted to fix the permissions issue first.
Upload the new tar and I'll take another look. If I were you, I would use INSTALL="%{__install} -p" (mind the quotes, you are not using them). They never hurt and sometimes quoting is .. heh.. needed. Like now, if I am not wrong: without them, the "-p" is not passed to "install" but to "make".
Tried that without success. New version uploaded here: http://sourceforge.net/project/showfiles.php?group_id=96810&package_id=103482&release_id=500052
Comment on attachment 137980 [details] Gotmail spec file Spec file obsoleted.
The problem has been fixed. The spec file and src rpm located at: http://sourceforge.net/project/showfiles.php?group_id=96810&package_id=103482&release_id=500052 Now build and rpmlint without error. Thanks to all for their help.
This time it is plain wrong. You try to set gotmail as user, which is certain to fail everywhere since that user does not exist: rpmlint of gotmail: W: gotmail incoherent-version-in-changelog 0.9.0-0 1:0.9.0-0 -> this comes from the Epoch=1; the full version (e-v-r) should be included in the %changelog entries E: gotmail non-standard-uid /usr/share/doc/gotmail-0.9.0/COPYING gotmail E: gotmail non-standard-gid /usr/share/doc/gotmail-0.9.0/COPYING gotmail E: gotmail non-standard-uid /usr/share/man/man1/gotmail.1.gz gotmail E: gotmail non-standard-gid /usr/share/man/man1/gotmail.1.gz gotmail E: gotmail non-standard-uid /usr/share/doc/gotmail-0.9.0/ChangeLog gotmail E: gotmail non-standard-gid /usr/share/doc/gotmail-0.9.0/ChangeLog gotmail E: gotmail non-standard-uid /usr/bin/gotmail gotmail E: gotmail non-standard-gid /usr/bin/gotmail gotmail E: gotmail non-standard-uid /usr/share/doc/gotmail-0.9.0/README gotmail E: gotmail non-standard-gid /usr/share/doc/gotmail-0.9.0/README gotmail E: gotmail non-standard-uid /usr/share/doc/gotmail-0.9.0/sample.gotmailrc gotmail E: gotmail non-standard-gid /usr/share/doc/gotmail-0.9.0/sample.gotmailrc gotmail E: gotmail non-standard-uid /usr/share/doc/gotmail-0.9.0 gotmail E: gotmail non-standard-gid /usr/share/doc/gotmail-0.9.0 gotmail E: gotmail non-standard-uid /usr/share/doc/gotmail-0.9.0/gotmail4evolution gotmail E: gotmail non-standard-gid /usr/share/doc/gotmail-0.9.0/gotmail4evolution gotmail Pretty please, stop trying to work around packaging bugs and read a bit about preserving the modes. The umask=022 is not needed, the (-,root,root,-) was fine... All you have to do is - work as an regular user (not root) - ensure umask is 022 - chmod all files which have to be included to 0644 (minus the executable which should be 0755, of course) - create a tarball where all the included stuff is chmod-ed as above - rpmbuild -bs (or -bt) using the correctly created spec (or tarball) By the way, if you remove the exec bit from gotmail4evolution you'll avoid later warnings from rpmlint (this script -- which is a %doc -- because it has the executable bit set, will pull bash as a dependency; generally it is considered bad habit to have %doc bring in deps; in this particular case I would accept this, because bash is present already on any fedora system but as I said this is a very bad habit that you should avoid) [*] Also, please increase the release each time you modify something and (in the future) start counting the release from 1. [*] this problem seems to be fixed in the package listed at comment #43 but I am not sure at this point that you actually intendted it or it was just an unwanted side effect of the other modifications.
Okay - my apologies - that's entirely my fault. I inherited the packing system and I should just have dumped it and started again rather than learn someone else's method. I've: 1. Reverted back to (-,root,root,-) 2. Removed the umask 3. Incremented the spec file to 1 (I will start counting from 1 next time also) 4. Ensured the Makefile will chmod the files 5. Removed the x from the gotmail4evolution script 6. Fixed the epoch tupple error The rpm now builds and installs without error - at least for me. The new files have been uploaded and you can see the -1 rpms and the spec file.
Excellent, James, all problems but one seem to be fixed now. There is one issue which must be fixed before having the package accepted: Source gotmail-0.9.0.tar.bz2 is different from upstream Given the fact that you are the upstream maintainer, the large number of changes which have occured during these last days and the fact that all files are hosted on SF servers, it might be that not all the servers have synced with the new version (see? that's why it's a good idea to not touch the tarball and to increment the release when you do...). Just to be sure, please verify that the tar.bz2 included in the src.rpm and the standalone one are identical. The other issue that might be discussed is that, given the script's ability to forward the messages to SA and procmail, it might be a good idea to Require: these two. Because these two are "soft requires", I for one am happy with it such as it is now, leaving the option to install or not the other two packages to the user. So: from my point of view and assuming the script works as advertised (I assume it does since the perl script has not been modified in 3 months, but as I said I don't have a hotmail account and I have no intent to create one), the package is ready for approval. You now have to convince a sponsor.
There is a delay with sync between mirrors on SF. But I can verify that they are identical as I have been uploading the new tar.bz2 files whenever the RPMs have changed. It may take a little time to distribute all the new files - this is one of the drawbacks of SF. As both procmail and SA are optional for Gotmail I'd prefer to leave them as is.
My thoughts exactly. I suggest hunting for a sponsor :) The ball is in your yard.
Hey James. Have you taken a look at: http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored I see a number of sponsors have commented here, so perhaps one of them would be interested in sponsoring you if you do some pre-reviews on other submissions or otherwise show that you know the guidelines.
Thanks Kevin Not sure how relevant submission is going to be now that it appears Hotmail is migrating to Hotmail Live - which Gotmail does not support. Another package, GetLive - which supports both Hotmail Classic and Hotmail Live, looks to replace Gotmail in the near future. Considering closing this submission request as a result.
So perhaps we should go ahead and close this. When it's ready, feel free to go ahead and submit GetLive in another ticket if you like. I'll go ahead and close this out in a week unless someone indicates that I shouldn't. Or James can close it whenever he wishes.
Closed.