Bug 1246903

This is the review-request for my other extension: https://bugzilla.redhat.com/show_bug.cgi?id=1246904

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.

(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.

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).

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.

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

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).

> 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).

(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.

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.

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".

Here's an answer on GNOME Software and the extensions web site:
https://lists.fedoraproject.org/pipermail/desktop/2015-August/012697.html

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.

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.

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.

copr-builds now available:
http://copr.fedoraproject.org/coprs/jenslody/gnome-shell-extensions/build/110252/

Updated spec-file and srpm, reflecting newest upstream-changes:
https://rpm.jenslody.de/review/gnome-shell-extension-openweather.spec
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.1.20150913git98b4611.el7.centos.src.rpm

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

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

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

Incorrect url, here comes the correct one:
https://rpm.jenslody.de/review/gnome-shell-extension-openweather-1-0.2.20150918git6f2113f.el7.centos.src.rpm

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?

(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.

Which version of Fedora/gnome-shell did you use ?

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

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 ***

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?

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".

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).

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!

Many thanks for sponsoring you.

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

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:

Git done (by process-git-requests).

> # 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+.

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 :)

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

Thanks Kalev !
I just fixed this and just pushed my first package to testing.

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

Thanks, and welcome to Fedora! :)

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

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 :)

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

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

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

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.

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.

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.