Bug 165488 - Review Request: wmweather+ - Weather status dockapp
Review Request: wmweather+ - Weather status dockapp
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: José Matos
David Lawrence
http://sourceforge.net/projects/wmwea...
:
: 177832 (view as bug list)
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-08-09 15:12 EDT by Andreas Bierfert
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-15 09:49:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andreas Bierfert 2005-08-09 15:12:10 EDT
Spec Name or Url: http://fedora.lowlatency.de/review/wmweather+.spec
SRPM Name or Url: http://fedora.lowlatency.de/review/wmweather+-2.9-1.src.rpm
Description:
wmweather+ will download the National Weather Serivce METAR bulletins; AVN,
ETA, and MRF forecasts; and any weather map for display in a WindowMaker
dockapp. Think wmweather with a smaller font, forecasts, a weather map, and a
sky condition display.
Comment 1 José Matos 2005-09-15 09:33:48 EDT
+ the package builds in mock/x86_64     
+ rpmlint     
W: wmapmload no-version-in-last-changelog    
W: wmapmload-debuginfo no-version-in-last-changelog    
     
  These can be ignored.     
     
+ package name follows the guideline     
+ package follows packaging guidelines     
+ license is valid, matches upstream and is included    
+ spec file is legible and is written in American English     
+ source matches upstream     
+ Requires and BR OK     
+ files ownership OK    
    
Approved.  
  
There is no need to pack the ChangeLog in %doc, as this is mainly developper  
information, you can drop it. 
 
There is no need to list the man page in %files as this is done automatically. 
Comment 2 Paul Howarth 2005-09-15 10:03:55 EDT
(In reply to comment #1)
> + the package builds in mock/x86_64     
> + rpmlint     
> W: wmapmload no-version-in-last-changelog    
> W: wmapmload-debuginfo no-version-in-last-changelog    
>      
>   These can be ignored.

They are also trivially fixed, so they might as well be fixed. The version
number is actually specified in the spec file, but the packager's editor has
word-wrapped it onto the next line. Joining the two lines together will fix the
problem, e.g.:

* Fri Jun 03 2005 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de> 2.9-1
- Initial Release

> + package name follows the guideline     
> + package follows packaging guidelines     
> + license is valid, matches upstream and is included    
> + spec file is legible and is written in American English     
> + source matches upstream     
> + Requires and BR OK     
> + files ownership OK    
>     
> Approved.  
>   
> There is no need to pack the ChangeLog in %doc, as this is mainly developper  
> information, you can drop it.

Whilst it's mainly developer information, there are a few things in there of
interest to end users. Personally I would include it.

On the other hand, I would drop the README file, which is about how to build the
app, and include instead HINTS, which is about how to run it.

> There is no need to list the man page in %files as this is done automatically.

That is not true, at least not in any version of rpm I've ever used.
Comment 3 Andreas Bierfert 2005-09-15 10:14:47 EDT
I should really make some default text for this:
Splitting up rpmdate and version is agreed to be ok in my case as my name/mail
is quiet long.

As to ChangeLog and README... I don't know quiet yet whats the best way for
this. I will leave it without ChangeLog for now till next release.
Comment 4 José Matos 2005-09-15 10:35:13 EDT
>> There is no need to list the man page in %files as this is done  
>> automatically.  
  
> That is not true, at least not in any version of rpm I've ever used.  
  
This link disagrees with you. ;-)  
http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DOCDIR-DIRECTIVE  
  
By default the doc, info and man directories are searched for documents. 
 
Regarding the next issue, which files goes into %doc, I trust your judgement. 
Comment 5 Paul Howarth 2005-09-15 10:47:16 EDT
(In reply to comment #4)
> >> There is no need to list the man page in %files as this is done  
> >> automatically.  
>   
> > That is not true, at least not in any version of rpm I've ever used.  
>   
> This link disagrees with you. ;-)  
>
http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DOCDIR-DIRECTIVE


No, that agrees with me. About two thirds of the way down that page, it says:

  %docdir only directs RPM to mark the specified directory as holding
  documentation. It doesn't direct RPM to package any files in the
  directory

> By default the doc, info and man directories are searched for documents.

It means that any files you specify in the %files list that are in directories
marked as %docdir are treated as documentation, which will be excluded if the
package is installed using --excludedocs. This includes manpages, info etc. by
default. However, you still need to include the manpages etc. in the %files list.

If you try commenting out the manpages from the %files list, you'll find that
rpmbuild complains about unpackaged files.
Comment 6 Michael Schwendt 2005-09-17 04:26:47 EDT
Precisely, it means that by default files in %_defaultdocdir, %_infodir and
%_mandir are given the %doc attribute implicitly.
Comment 7 Ville Skyttä 2005-09-17 05:11:25 EDT
The full list of dirs for which (+ all their subdirs) this happens: from rpm 
CVS, build/files.c (processPackageFiles()): 
 
    /usr/doc 
    /usr/man 
    /usr/info 
    /usr/X11R6/man 
    /usr/share/doc 
    /usr/share/man 
    /usr/share/info 
    %{_docdir} 
    %{_mandir} 
    %{_infodir} 
    %{_javadocdir} 
Comment 8 José Matos 2005-09-23 13:01:24 EDT
Thanks for the information, we (I) learn a new thing everyday. :-) 
Comment 9 Christian Iseli 2006-10-18 05:05:04 EDT
Normalize summary field for easy parsing
Comment 10 Christian Iseli 2006-12-30 18:28:16 EST
*** Bug 177832 has been marked as a duplicate of this bug. ***

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