Bug 1246903 - Review Request: gnome-shell-extension-openweather - an extension to display weather information from many locations in the world
Summary: Review Request: gnome-shell-extension-openweather - an extension to display w...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-26 19:44 UTC by Jens Lody
Modified: 2015-10-04 22:51 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-01 16:02:26 UTC
hobbes1069: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Jens Lody 2015-07-26 19:44:37 UTC
Spec URL: https://rpm.jenslody.de/review/gnome-shell-extension-openweather.spec
SRPM URL: https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.1.20150726.gite56e4ae.fc22.src.rpm
Description: gnome-shell-extension-openweather is an extension to display weather information
from http://openweathermap.org/ or http://forecast.io for (almost) all locations
of the world in GNOME Shell.
Fedora Account System Username: jenslody

This is my first package and I need a sponsor.

I maintain the upstream-sources at https://github.com/jenslody/gnome-shell-extension-openweather and the extension on gnome.org: https://extensions.gnome.org/extension/750/openweather/

Successful builds can be found on my copr-site: https://copr.fedoraproject.org/coprs/jenslody/gnome-shell-extensions/ and as scratch-build: http://koji.fedoraproject.org/koji/taskinfo?taskID=10488604 .

I also add a review-request and a request for a sponsor for the other gnome-shell-extension maintained by me, I will add a link if I know the ticket number.

Comment 1 Jens Lody 2015-07-26 19:49:48 UTC
This is the review-request for my other extension: https://bugzilla.redhat.com/show_bug.cgi?id=1246904

Comment 2 Richard Shaw 2015-08-17 13:45:52 UTC
Is the main difference between your fork and Neroth's extension where it gets the weather data from?

I know his had to go into RPM Fusion as it wasn't acceptable in Fedora and I can't quite remember if that was the reason or not.

Comment 3 Jens Lody 2015-08-17 14:33:03 UTC
(In reply to Richard Shaw from comment #2)
> Is the main difference between your fork and Neroth's extension where it
> gets the weather data from?
> 
> I know his had to go into RPM Fusion as it wasn't acceptable in Fedora and I
> can't quite remember if that was the reason or not.

I don't know why it was not acceptable, probably because he used yahoo.
I forked the extension, after he switched to gnome-weather, which was useless for people not living in major cities (and even then the location was often nit found).

So I reverted these changes and switched to openweathermap.org and used their site also to search the location.

In the meantime I also added forecast.io as weather provider and switched location-search to openstreetmaps.org (nomination), which works much better.

I personally like my extension more, because it has a slightly different layout (more clear in my opinion, but that's a matter of taste) and more configuration options.

User can freely chose between both weather-providers as default provider and chose which one to use for single locations (instead of default), if one of the (at the moment two) providers is known to have better results/forecasts for a location.

One problem might be, that forecast.io forces the use of an api-key. The api-key is free for up to thousand requests per day, but nevertheless a user will not get data without it. Openweathermap.org works without an api-key, but the prefer users to use one.

Comment 4 Jens Lody 2015-08-17 15:26:18 UTC
Just for the record:
The api of openweathermap.org is under CC BY-SA and should therefore be acceptable.
Whether the license of forecast.io's api is acceptable is beyond my knowledge (I'm not a lawyer):
https://developer.forecast.io/terms_of_use.txt
The nominatim service I use is the one provided by http://open.mapquestapi.com/nominatim/ .
I'm not sure if it is acceptable.
If not and that would be the only reason for abandoning the package I probably can use my own server for the nominatim part of my extension (that depends on the requirements).

Comment 5 Richard Shaw 2015-08-17 21:09:19 UTC
Ok, just for reference is the BZ from RPM Fusion:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2017

And the reason was due to the terms of use with Yahoo! Weather

Here's Spot's legal rationale:
https://lists.fedoraproject.org/pipermail/legal/2011-May/001633.html

So as long as there's not a "Terms of use" problem then we may be OK.

Comment 6 Jens Lody 2015-08-18 11:20:34 UTC
https://rpm.jenslody.de/review/gnome-shell-extension-openweather.spec
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.1.20150818.gitcb1f6f6.fc22.src.rpm

New (tiny updates) versions of sources and spec-file.
fedora-review finds no issues, except the issue with owning directories owned by other packages.
But this is a must for gnome-shell-extensions, that do not require gnome-shell-extensions-common.
They can be the only package that uses these directories and therefore they have to own them.

Here comes the informal review of one of my two gnome-shell-extensions.

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "BSD (3 clause)", "GPL (v3 or later)". Detailed output of
     licensecheck in /home/jens/gnome-shell-extension-
     openweather/licensecheck.txt
[x]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[ ]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by: /usr/share/gnome-
     shell/extensions(gnome-shell-extension-background-logo, gnome-shell-
     extension-common)
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: glib-compile-schemas is run in %postun and %posttrans if package has
     *.gschema.xml files.
     Note: gschema file(s) in gnome-shell-extension-openweather
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: No rpmlint messages.
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[-]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: No rpmlint messages.
[x]: Package should not use obsolete m4 macros


Rpmlint
-------
Checking: gnome-shell-extension-openweather-1-0.1.20150818.gitcb1f6f6.fc24.noarch.rpm
          gnome-shell-extension-openweather-1-0.1.20150818.gitcb1f6f6.fc24.src.rpm
2 packages and 0 specfiles checked; 0 errors, 0 warnings.




Rpmlint (installed packages)
----------------------------
sh: /usr/bin/python: Datei oder Verzeichnis nicht gefunden
1 packages and 0 specfiles checked; 0 errors, 0 warnings.



Requires
--------
gnome-shell-extension-openweather (rpmlib, GLIBC filtered):
    /bin/sh
    gnome-shell



Provides
--------
gnome-shell-extension-openweather:
    gnome-shell-extension-openweather



Source checksums
----------------
https://github.com/jenslody/gnome-shell-extension-openweather/tarball/master/jenslody-gnome-shell-extension-openweather-cb1f6f6.tar.gz :
  CHECKSUM(SHA256) this package     : c28b926a97bcc622325eb3a8a8f4f63c0a1f36d26b6372d008ec8f953e10525d
  CHECKSUM(SHA256) upstream package : c28b926a97bcc622325eb3a8a8f4f63c0a1f36d26b6372d008ec8f953e10525d


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -r -m fedora-rawhide-x86_64 -n Downloads/gnome-shell-extension-openweather-1-0.1.20150818.gitcb1f6f6.fc22.src.rpm
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api
Disabled plugins: Java, C/C++, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Comment 7 Jens Lody 2015-08-18 11:47:18 UTC
Successful (actual) copr-builds: http://copr.fedoraproject.org/coprs/jenslody/gnome-shell-extensions/monitor/
koji seems to be unavailable at the moment (there is an upgrade running if I remember correctly).

Comment 8 Michael Schwendt 2015-08-18 12:04:23 UTC
> Release:        0.1.%(date +%Y%m%d).%{checkout}%{?dist}

The extra dot before "git" is slightly off the guidelines for snapshot packages:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages


> fedora-review finds no issues, except the issue with owning
> directories owned by other packages. But this is a must for
> gnome-shell-extensions, that do not require gnome-shell-extensions-common.
> They can be the only package that uses these directories and
> therefore they have to own them.

In case of doubt, better ask for feedback on packaging@ list.

In my opinion, "Requires: gnome-shell-extension-common" would be the way to go.

The gnome-shell-extension-common package description tells that it is also sort of a -filesystem package (similar to the main purpose the hicolor-icon-theme package serves nowadays):

  $ rpm -qi gnome-shell-extension-common|tail  -2
  optional functionality to GNOME Shell. Common files and directories
  needed by extensions are provided here.

The yellow box here covers -filesystem packages:
https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function


> %postun
> %posttrans

News for Rawhide. File triggers:
https://lists.fedoraproject.org/pipermail/desktop/2015-August/012685.html

[...]

What else?

As I don't call myself an expert on GNOME Shell extensions, let me ask: What is the standard way to find these packages in the Fedora package collection. In gnome-tweak-tool I may only visit the web site to install more. And in GNOME Software, I cannot find them either (likely because of no appdata files in those packages).

Comment 9 Jens Lody 2015-08-18 12:54:48 UTC
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #8)
Thanks for the comments advices.
> > Release:        0.1.%(date +%Y%m%d).%{checkout}%{?dist}
> 
> The extra dot before "git" is slightly off the guidelines for snapshot
> packages:
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
> 
> 
> > fedora-review finds no issues, except the issue with owning
> > directories owned by other packages. But this is a must for
> > gnome-shell-extensions, that do not require gnome-shell-extensions-common.
> > They can be the only package that uses these directories and
> > therefore they have to own them.
> 
> In case of doubt, better ask for feedback on packaging@ list.
> 
> In my opinion, "Requires: gnome-shell-extension-common" would be the way to
> go.
> 
> The gnome-shell-extension-common package description tells that it is also
> sort of a -filesystem package (similar to the main purpose the
> hicolor-icon-theme package serves nowadays):
> 
>   $ rpm -qi gnome-shell-extension-common|tail  -2
>   optional functionality to GNOME Shell. Common files and directories
>   needed by extensions are provided here.
> 
> The yellow box here covers -filesystem packages:
> https://fedoraproject.org/wiki/Packaging:
> Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your
> _package_to_function
> 
I will fix the first two this evening (UTC+2).

By the way: I just removed the dependency to gnome-shell-extensions-common, because it's not an "official" filesystem-package (as far as I know) and at least one other package does it the same way I did (gnome-shell-extension-background-logo).

> 
> > %postun
> > %posttrans
> 
> News for Rawhide. File triggers:
> https://lists.fedoraproject.org/pipermail/desktop/2015-August/012685.html
> 
For the file triggers: does it mean I have to distinct between different versions of Fedora in the spec-file or use a different spec-file for rawhide ?
And do I need the direct dependency to glib2, or is the indirect dependency via gnome-shell-extensions-common enough ?
Rpmlint in fedora-review spits out an error if I use this, I think it's because the extension-package is noarch, but glib2 (obviously) not.

> [...]
> 
> What else?
> 
> As I don't call myself an expert on GNOME Shell extensions, let me ask: What
> is the standard way to find these packages in the Fedora package collection.
> In gnome-tweak-tool I may only visit the web site to install more. And in
> GNOME Software, I cannot find them either (likely because of no appdata
> files in those packages).

I have to admit, that I use yumex (or yumex-dnf) on my laptop, so it's easy to find by name, on commandline: "dnf list gnome-shell-extension*".
I do not use gnome-software often, so I did not even recognize, that it does not even list the extensions.
Probably some kind of bug (or design-flaw) in gnome-software.

Comment 10 Michael Schwendt 2015-08-19 11:14:41 UTC
I've sent a mail to packaging@ list to seek clarification. It's not pretty that there are filesystem packages in disguise, such as hicolor-icon-theme. And there used to be others, too. The guidelines still mention "man", which is gone meanwhile. I don't think all filesystem packages must end with -filesystem in their name. If that's a strict requirement for them to be named like that, the guidelines ought to be fixed.

It's only gnome-shell-extension-background-logo that doesn't require gnome-shell-extension-common. All other extensions depend on that filesystem package. And yes, I wish the guidelines were more clear.

[...]

> For the file triggers: does it mean I have to distinct between
> different versions of Fedora in the spec-file or use a different
> spec-file for rawhide ?

Using conditionals would be convenient, if you plan to use the same spec for multiple dist releases:

  https://fedoraproject.org/wiki/Packaging:DistTag#Conditionals

I think the implicit/automatic dependency on glib2 via gnome-shell is sufficient. If adding a temporary explicit dependency on glib2 -- as mentioned in the mail to desktop@ list -- it cannot be arch-specific, of course. But depsolvers usually do the right thing and, for example, would not pull in glib2.i686 on x86_64 (unless they run into unresolvable deps).

[...]

> dnf list gnome-shell-extension*

Of course.

I've sent a message to desktop@ list.

Comment 11 Michael Schwendt 2015-08-19 11:25:16 UTC
News from packaging@ list: gnome-shell-extension-common is an internal subpackage for the gnome-shell-extensions source package. 

There has been a fresh commit to gnome-shell to make it include two directories instead.

I've also had a look at other separate extension packages. They only depend on "gnome-shell" and don't explicitly own /usr/share/gnome-shell/extensions/ so far. They likely assume that directory will be available via "gnome-shell".

Comment 12 Michael Schwendt 2015-08-19 11:52:07 UTC
Here's an answer on GNOME Software and the extensions web site:
https://lists.fedoraproject.org/pipermail/desktop/2015-August/012697.html

Comment 13 Jens Lody 2015-08-19 12:29:30 UTC
Thank you very much Michael.
So I keep gnome-shell as dependency and add a conditional to distinguish between Fedora >= 24 and other (even not Fedora) build-systems.
My extensions are build for actual Fedora and Epel 7 on copr.
I'm not sure how to set the conditional: one that hides %postun and %posttrans from rawhide completely or one that sets a global, that is used inside these macros.
The second might make the spec-file less readable.
But this is just one conditional, for Code::Blocks we have tons of conditionals that clutter the spec-file (I should see if I find the time to clean this up).

I will test whether the trigger works without explicit requiring glib2.

Comment 14 Jens Lody 2015-08-21 04:55:48 UTC
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.1.20150821git97c21a5.fc22.src.rpm
https://rpm.jenslody.de/review/gnome-shell-extension-openweather.spec

Updated spec-file and small updates to the build-system, so the about-tab in preferences shows either the version automatically given by extensions.gnome.org (as it was before) or the value of the %{checkout}-variable from the specfile (gitabcd1234).

The triggers seem to work, installing and removing the package do a recompile of gschemas.compiled.
I made the requirement on gnome-shell conditional and used gnome-shell-extension-common for older releases to avoid unowned directories.
Without gnome-shell as requirement I also get a warning about using unowned directories (glib2.0/schemas), but I decided to ignore these, because glib2 is in the dependency-chain of gnome-shell-extension-common, so this should not be a problem.

With fedora-review I get an issue (in fc24-builds), because of the missing (or better conditional) schema-compiling in %postun and %posttrans, but this can be ignored with the new file-triggers.

I also shortened the summary, after reading some more about it.

Comment 15 Jens Lody 2015-08-21 04:58:37 UTC
No copr-builds available at the moment, because it hangs in importing for several packages (not only mine).
And doing a koji scratch-build does not make sense, because the conditionals will not work here, or I have to build different src-rpms for fc24 and older releases.

Comment 16 Jens Lody 2015-08-21 08:05:49 UTC
copr-builds now available:
http://copr.fedoraproject.org/coprs/jenslody/gnome-shell-extensions/build/110252/

Comment 18 Richard Shaw 2015-09-17 16:39:50 UTC
Copying the interesting bits to the top:
[*]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/glib-2.0/schemas,
     /usr/share/glib-2.0
	 Ignoring based on above comments.

gnome-shell-extension-openweather.noarch: W: incoherent-version-in-changelog 1-0.1.20150913git98b4611 ['1-0.1.20150917git98b4611.fc21', '1-0.1.20150917git98b4611']

You need to fix your date in the version to be static as it's supposed to be the checkout date, not the date the package was built.

Unless anyone else has any comments, pending that update I'm ready to approve.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "BSD (3 clause)", "GPL (v3 or later)". Detailed output of
     licensecheck in /home/build/fedora-review/1246903-gnome-shell-
     extension-openweather/licensecheck.txt
[x]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[*]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/glib-2.0/schemas,
     /usr/share/glib-2.0
	 Ignoring based on above comments.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: glib-compile-schemas is run in %postun and %posttrans if package has
     *.gschema.xml files.
     Note: gschema file(s) in gnome-shell-extension-openweather
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Scriptlets must be sane, if used.
[?]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Package should not use obsolete m4 macros
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: gnome-shell-extension-openweather-1-0.1.20150917git98b4611.fc21.noarch.rpm
          gnome-shell-extension-openweather-1-0.1.20150917git98b4611.fc21.src.rpm
gnome-shell-extension-openweather.noarch: W: incoherent-version-in-changelog 1-0.1.20150913git98b4611 ['1-0.1.20150917git98b4611.fc21', '1-0.1.20150917git98b4611']
2 packages and 0 specfiles checked; 0 errors, 1 warnings.




Rpmlint (installed packages)
----------------------------
gnome-shell-extension-openweather.noarch: W: incoherent-version-in-changelog 1-0.1.20150913git98b4611 ['1-0.1.20150917git98b4611.fc21', '1-0.1.20150917git98b4611']
1 packages and 0 specfiles checked; 0 errors, 1 warnings.



Requires
--------
gnome-shell-extension-openweather (rpmlib, GLIBC filtered):
    /bin/sh
    gnome-shell-extension-common



Provides
--------
gnome-shell-extension-openweather:
    gnome-shell-extension-openweather



Source checksums
----------------
https://github.com/jenslody/gnome-shell-extension-openweather/tarball/master/jenslody-gnome-shell-extension-openweather-98b4611.tar.gz :
  CHECKSUM(SHA256) this package     : a45cca4fb358ef907b356ac064569ddc7878d63c07e6bc2de92efae43b2b7579
  CHECKSUM(SHA256) upstream package : a45cca4fb358ef907b356ac064569ddc7878d63c07e6bc2de92efae43b2b7579


Generated by fedora-review 0.5.3 (bcf15e3) last change: 2015-05-04
Command line :/bin/fedora-review -b 1246903
Buildroot used: fedora-21-x86_64
Active plugins: Generic, Shell-api
Disabled plugins: Java, C/C++, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Comment 19 Jens Lody 2015-09-18 00:03:09 UTC
Date is now fixed in new spec-file, newest upstream included.
I had add a new geolocation-provider, because mapquest uses an AppKey since 15. September 2015 and broke the extension (at least the search for a new location).
Default geolocation-provider is now geocode.farm, mapquest can still be chosen, but requires a (free) AppKey.


https://rpm.jenslody.de/review/gnome-shell-extension-openweather.spec
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.2.20150917git6dea6cf.el7.centos.src.rpm

Comment 20 Jens Lody 2015-09-18 14:35:40 UTC
Updated srpm, containing newest upstream, now using openstreetmaps nominatim service directly:
This is now possible,because the user can change the geolocation-data provider easily ans the extension nowuses an own user-agent-string.
Spec-file is updated, but has the same name.

https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.2.20150917git6dea6cf.el7.centos.src.rpm

Comment 21 Jens Lody 2015-09-18 14:43:56 UTC
Incorrect url, here comes the correct one:
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.2.20150918git6f2113f.el7.centos.src.rpm

Comment 22 Richard Shaw 2015-09-20 19:46:17 UTC
Ok, I think all the packaging issues are resolved but I do have a question. I tried installing it and configuring it for my location. I got an openweathermap API key and plugged it in. 

No location is ever "found"
The "searching" widget locks out all other activity, even trying to switch applications.

Ideas?

Comment 23 Jens Lody 2015-09-20 20:16:50 UTC
(In reply to Richard Shaw from comment #22)
> Ok, I think all the packaging issues are resolved but I do have a question.
> I tried installing it and configuring it for my location. I got an
> openweathermap API key and plugged it in. 
> 
> No location is ever "found"
> The "searching" widget locks out all other activity, even trying to switch
> applications.
> 
> Ideas?

Openweathermap should work without api-key, but is sometimes less correct than forecast.io and sometimes unresponsive. That was the cause for adding forecast.io.

I just uploaded a new srpm, that has updated russion translation, adds an own user-agent and uses the git-version as version in metadata.json and in the about-tab.

There was another issue with the user-agent string, but only if it was numeric.

Can you please tes, whether the issue is still there, and probably run journalctl -fln when reloading the gnome-shell and/or starting the search, to see if an error-message occurs ?
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.2.20150920gitbcd4b78.el7.centos.src.rpm

You can use geocode.farm or openstreetmaps nominatim as geolocation-provider without a key. OPenstreetmaps is now he default for newlyinstalled extensions.

Comment 24 Jens Lody 2015-09-20 20:17:44 UTC
Which version of Fedora/gnome-shell did you use ?

Comment 25 Jens Lody 2015-09-20 21:01:44 UTC
There was a typo in the enum for geolocation-services (missing S), that prevents openstreetmaps from being used. Fixed in this version:
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.2.20150920git6ee5ce3.el7.centos.src.rpm

Comment 26 Richard Shaw 2015-09-21 02:11:51 UTC
Ok, that got it. But to answer your question I'm still running Fedora 21

# rpm -q gnome-shell
gnome-shell-3.14.4-2.fc21.x86_64

Sill needs a few tweaks but overall looks pretty good. I noticed that if I add more than 3 days to the forecast the high temp get's truncated even though it adds a horizontal scroll.

*** APPROVED ***

Comment 27 Richard Shaw 2015-09-21 02:13:07 UTC
Just noticed the needs sponsor flag. I can do that but you'll be the first, let me research what I have to do tomorrow. 

Have you done any other informal reviews? Any packages you'd like to co-maintain?

Comment 28 Jens Lody 2015-09-21 04:08:35 UTC
Some review-requests I jumped in (more or less deep):
https://bugzilla.redhat.com/show_bug.cgi?id=1245255
https://bugzilla.redhat.com/show_bug.cgi?id=1252130
https://bugzilla.redhat.com/show_bug.cgi?id=755510

https://bugzilla.redhat.com/show_bug.cgi?id=1259002
https://bugzilla.redhat.com/show_bug.cgi?id=1258874

One package where I was asked to (co)maintain it:
https://bugzilla.redhat.com/show_bug.cgi?id=1195002#c26

and I would of course like to comaintain codeblocks, but this is a quite more complex package and I did not get in contact with Dan (the maintainer) except in our (upstream) forum.
I hope I could fix some of the unbundling stuff upstream, so it would be easier to package it.
By the way: it's interestant to see how it changes the view on a package, if you know "both sides".

Comment 29 Jens Lody 2015-09-21 04:35:34 UTC
Another package I'm interested in, is aeskulap, which was retired because of missing dependencies, so it does not exist for fc>=22.

It seems to be dead upstream and I did not really check how much work it would need to make it usable again or if it is even possible.

But aeskulap is one of the causes to kee fc21 on a vm (besides the ability to test my extensions on "older" gnome-shell's).

Comment 30 Richard Shaw 2015-09-22 17:43:59 UTC
Ok, I think I've done what I'm supposed to do to sponsor you. I'm not sure if there is any delay before you can be granted scm access so go ahead and try your scm request.

Also, sponsoring is not a one time activity. If you run into any issues feel free to contact me. If I don't know the answer I'll try to get it from someone who does.

Use your powers for good!

Comment 31 Jens Lody 2015-09-22 19:18:40 UTC
Many thanks for sponsoring you.

I will not hesitate to ask for help if I get stuck.

Comment 32 Jens Lody 2015-09-22 19:19:46 UTC
New Package SCM Request
=======================
Package Name: gnome-shell-extension-openweather
Short Description: Display weather information for (almost) all locations in the world
Upstream URL: https://github.com/jenslody/gnome-shell-extension-openweather
Owners: jenslody
Branches: f21 f22 f23
InitialCC:

Comment 33 Gwyn Ciesla 2015-09-23 15:34:20 UTC
Git done (by process-git-requests).

Comment 34 Kalev Lember 2015-09-24 21:11:25 UTC
> # In Fedora  >= 24 %%{_datadir}/gnome-shell/extensions/ is owned by gnome-shell,
> # before it was owned by gnome-shell-extension-common
> %if 0%{?fedora} >= 24
> Requires:       gnome-shell >= 3.12.0
> %else
> Requires:       gnome-shell-extension-common >= 3.12.0
> %endif

Depending on gnome-shell-extension-common is wrong, please don't do that. It's an internal subpackage for gnome-shell-extensions srpm and ships translations and a few other things for packages that come from that srpm. It is not meant for other packages to depend on. Just use multiple directory ownership on F22 and older as per https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership and depend on gnome-shell on F23+.

Comment 35 Kalev Lember 2015-09-24 21:44:26 UTC
It's probably easiest if you depend on gnome-shell unconditionally on all Fedora versions -- it's a gnome-shell extension after all and it makes sense to have a hard dep.

And then in %files, do

%if 0%{?fedora} < 23
%dir %{_datadir}/gnome-shell/extensions
%endif

Beyond this small issue, great work :)

Comment 36 Fedora Update System 2015-09-24 22:44:29 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9fd324e09e

Comment 37 Jens Lody 2015-09-24 22:49:04 UTC
Thanks Kalev !
I just fixed this and just pushed my first package to testing.

Comment 38 Fedora Update System 2015-09-24 22:50:10 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-bcb0b726a9

Comment 39 Kalev Lember 2015-09-24 22:50:48 UTC
Thanks, and welcome to Fedora! :)

Comment 40 Fedora Update System 2015-09-24 22:52:09 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-b1d32ed839

Comment 41 Richard Shaw 2015-09-25 00:30:23 UTC
I think it would be worth expanding the packaging guidelines here as:

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28gnome_shell_extensions.29

Doesn't say much :)

Comment 42 Fedora Update System 2015-09-25 15:20:19 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update gnome-shell-extension-openweather'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9fd324e09e

Comment 43 Fedora Update System 2015-09-25 16:32:07 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update gnome-shell-extension-openweather'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-b1d32ed839

Comment 44 Fedora Update System 2015-09-27 00:38:09 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update gnome-shell-extension-openweather'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-bcb0b726a9

Comment 45 Fedora Update System 2015-10-01 16:02:24 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 46 Fedora Update System 2015-10-03 21:50:57 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Comment 47 Fedora Update System 2015-10-04 22:51:40 UTC
gnome-shell-extension-openweather-1-0.4.20150924gite55253e.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.


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