Bug 199905 - Review Request: gotmail
Review Request: gotmail
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2006-07-24 04:26 EDT by James Turnbull
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-15 18:24:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Gotmail spec file (1.57 KB, application/octet-stream)
2006-10-07 16:22 EDT, James Turnbull
no flags Details

  None (edit)
Description James Turnbull 2006-07-24 04:26:50 EDT
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.
Comment 1 James Turnbull 2006-07-24 04:29:37 EDT
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.
Comment 2 Paul Howarth 2006-07-24 16:08:40 EDT
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.
Comment 4 Stewart Adam 2006-09-17 22:23:21 EDT
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.
Comment 5 James Turnbull 2006-09-18 00:04:42 EDT
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
Comment 6 Patrice Dumas 2006-10-07 14:33:41 EDT
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
Comment 7 James Turnbull 2006-10-07 16:22:22 EDT
Created attachment 137980 [details]
Gotmail spec file

Gotmail spec file
Comment 8 James Turnbull 2006-10-07 16:24:07 EDT
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.
Comment 9 Patrice Dumas 2006-10-07 17:44:09 EDT
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...
Comment 10 James Turnbull 2006-10-07 18:18:47 EDT
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
Comment 11 James Turnbull 2006-10-07 18:24:21 EDT
Do you mean that "-n gotmail-%{version}" is the default and as such I don't need
to specify it?
Comment 12 Patrice Dumas 2006-10-08 02:46:29 EDT
(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).
Comment 13 James Turnbull 2006-10-08 21:45:32 EDT
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
Comment 14 Paul Howarth 2006-10-09 03:04:29 EDT
(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.
Comment 15 Patrice Dumas 2006-10-09 03:55:51 EDT
(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.
Comment 16 James Turnbull 2006-10-09 04:14:52 EDT
Added Epoch back to the spec file.  I will document the additional somewhere.
Comment 17 Patrice Dumas 2006-10-09 04:18:06 EDT
(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.
Comment 18 James Turnbull 2006-10-09 05:23:55 EDT
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. 
Comment 19 Patrice Dumas 2006-10-09 06:01:15 EDT
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.
Comment 20 James Turnbull 2006-10-09 06:17:42 EDT
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.
Comment 21 Patrice Dumas 2006-10-09 06:27:37 EDT
(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
Comment 22 Patrice Dumas 2006-10-09 06:28:50 EDT
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.
Comment 23 James Turnbull 2006-10-09 07:24:59 EDT
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.
Comment 24 Michael Schwendt 2006-10-09 08:04:38 EDT
$ 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.
Comment 25 James Turnbull 2006-10-09 08:50:41 EDT
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.
Comment 26 Paul Howarth 2006-10-09 09:02:14 EDT
(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.
Comment 27 James Turnbull 2006-10-09 09:08:34 EDT
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.
Comment 28 Patrice Dumas 2006-10-09 09:43:38 EDT
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. 
Comment 29 James Turnbull 2006-10-09 18:09:49 EDT
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.
Comment 31 Mamoru TASAKA 2007-01-26 12:03:47 EST
What is the status of this bug?
Comment 32 Mamoru TASAKA 2007-04-06 14:07:24 EDT
Again what is the status of this bug?
Comment 33 James Turnbull 2007-04-07 10:07:59 EDT
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.
Comment 34 manuel wolfshant 2007-04-07 12:52:46 EDT
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 ?

Comment 35 James Turnbull 2007-04-07 19:48:26 EDT
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.  
Comment 36 manuel wolfshant 2007-04-07 21:10:56 EDT
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.
Comment 37 James Turnbull 2007-04-07 22:13:59 EDT
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.
Comment 38 manuel wolfshant 2007-04-08 09:25:41 EDT
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
Comment 39 James Turnbull 2007-04-10 05:38:25 EDT
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.
Comment 40 manuel wolfshant 2007-04-10 06:19:17 EDT
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".
Comment 41 James Turnbull 2007-04-10 08:39:17 EDT
Tried that without success.  New version uploaded here:

http://sourceforge.net/project/showfiles.php?group_id=96810&package_id=103482&release_id=500052
Comment 42 James Turnbull 2007-04-10 10:06:59 EDT
Comment on attachment 137980 [details]
Gotmail spec file

Spec file obsoleted.
Comment 43 James Turnbull 2007-04-10 10:07:56 EDT
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.
Comment 44 manuel wolfshant 2007-04-10 10:46:23 EDT
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.
Comment 45 James Turnbull 2007-04-10 11:12:49 EDT
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.
Comment 46 manuel wolfshant 2007-04-10 13:18:59 EDT
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.
Comment 47 James Turnbull 2007-04-10 17:39:16 EDT
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.
Comment 48 manuel wolfshant 2007-04-10 19:15:43 EDT
My thoughts exactly. I suggest hunting for a sponsor :) The ball is in your yard.
Comment 49 Kevin Fenzi 2007-06-01 02:13:25 EDT
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. 
Comment 50 James Turnbull 2007-06-01 03:36:24 EDT
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.
Comment 51 Jason Tibbitts 2007-06-15 12:35:08 EDT
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.
Comment 52 James Turnbull 2007-06-15 18:24:38 EDT
Closed.

Note You need to log in before you can comment on or make changes to this bug.