Bug 593800

Koji scratch build URL : https://koji.fedoraproject.org/koji/taskinfo?taskID=2197597

*** Bug 593999 has been marked as a duplicate of this bug. ***

There is one rpmlint error and lot of warnings. Please fix those.


[sherry@brc ~]$ rpmlint Downloads/python-keyring-0.2-1.fc12.src.rpm 
1>python-keyring.src: W: summary-ended-with-dot C Store and access your passwords safely.
2>python-keyring.src: E: description-line-too-long C  from python. It can be used in any application that needs safe password storage.
python-keyring.src: W: no-version-in-last-changelog

Easy to fix.


3>python-keyring.src: W: invalid-license PSF
4>python-keyring.src: W: invalid-url URL: http://home.python-keyring.org/ HTTP Error 405: Method Not Allowed
5>python-keyring.src:26: W: setup-not-quiet
6>python-keyring.src: W: no-cleaning-of-buildroot %install
7>python-keyring.src: W: invalid-url Source0: keyring-0.2.tar.gz


You can refer to python-chm spec. Do "fedoracvs co python-chm"

Moreover, there is nothing in the %files section. So effectively, this does not package anything. Have you tried the rpm from the scratch build? Please refer to this and make the necessary changes.

Ratnadeep, check spec file from Bug 593999 if you wish, it can possibly help you.

(In reply to comment #4)
> Ratnadeep, check spec file from Bug 593999 if you wish, it can possibly help
> you.    

Thanks :). I made some changes in my spec based on spec file from Bug 593999. I will be uploading the changes shortly.

(In reply to comment #3)
> There is one rpmlint error and lot of warnings. Please fix those.
> 
> 
> [sherry@brc ~]$ rpmlint Downloads/python-keyring-0.2-1.fc12.src.rpm 
> 1>python-keyring.src: W: summary-ended-with-dot C Store and access your
> passwords safely.
> 2>python-keyring.src: E: description-line-too-long C  from python. It can be
> used in any application that needs safe password storage.
> python-keyring.src: W: no-version-in-last-changelog

oops ... forgot to run rpmlint before submitting the review. I will be uploading the changes shortly.

Update the srpm and spec files for python-keyring

Spec URL: http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM URL: http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.2-1.fc12.src.rpm

You can have a look to this: 

https://build.opensuse.org/package/view_file?file=python-keyring.spec&package=python-keyring&project=home:sergiopasra

Notice that the spec file has a few SUSEisms. 

The spec has subpackages python-keyring-gnome and python-keyring-kwallet for gnome and kde backends (that's what debian does: http://packages.debian.org/sid/python-keyring)

Please modify the ownership of the files. The package is architecture specific as it has C and CPP files. Please take care of those while packaging.

Update the spec and srpm file
Spec URL: http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM URL:
http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.2-1.fc12.src.rpm

This package needs additional BuildRequires . pkg-config is one of them. Please find out what else it requires and ad them accordingly. Make a scratch build and check that it compiles correctly ie. it creates the arch specific .so files and that too at the proper locations. python_sitelib and python_sitearch are same for 32 bit systems. So you should check the scratch builds on 64 bit systems as well.

Do an rpmls on the binary rpm creates and check whether the .so files have been packed or not.

Hello, Rangeen:

Are you a sponsor? While everyone can do informal review, review requests
blocking FE-NEEDSPONSOR must (finally) be reviewed and approved by sponsor
members, so only sponsor member must be formal assignee.

This did not have a FE-NEEDSPONSOR block when I took this. Thanks. Will change the state to new.

Created attachment 426326 [details]
0.2-1.1 - modified spec file that builds in mock

I don't want to interfere here but I needed this package so I adapted the spec file and fixed some of the issues mentioned above. Maybe it's useful to some. At least it builds in mock now. KWallet is disabled as I didn't have time to get the correct build requires.

Ratnadeep Debnath: Are you still interested in packaging python-keyring? I'm feeling a bit bad here just to hijack this review. Ratnadeep, please tell me if you're still interested - I'll step back then. If you don't have time right now, I'd like to take over.

However as I needed this package for my private workflow, I modified the spec file quite a bit so that it complies to Fedora's guidelines, see http://www.felix-schwarz.name/files/misc/2010/python-keyring-0.2-1.fc13.2.src.rpm
I think it is better than the previously linked versions.

There is one pylint error which I can't fix: 
python-keyring.x86_64: E: no-binary

As far as I know, it is not possible to have a noarch main package with arch-specific subpackages. Therefore the main package is not 'noarch' even though it does not contain binary files. Can we ignore this?

I don't understand pylint's invalid url warning. I suspect it tries to do a HEAD request which the web site does not support. The url is perfectly fine though.

Felix Schwarz: I got a bit busy with some other stuff, that's why I couldn't work on it for a while. But I am interested in packaging python-keyring. I'm having a look at the spec file updated by you. 

Will update soon.

I did some cleanup of the python-keyring.spec file of Felix Schwarz. 
The  "E: no-binary" error couldn't be fixed. We'll be ignoring this for now. Also, the warning for the url is absurd.

Anyways, I have updated the spec and SRPM files at
SPEC: http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM: http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.2-1.fc13.3.src.rpm

Some notes:

* Macro definition
  - For defining %python_sitearch macro and so on, please follow
    below:
    https://fedoraproject.org/wiki/Packaging/Python#Macros

* Filtering Provides
  - If you want to filter some Provides generated by rpmbuild,
    you can now use "%filter_provides_in" macro as defined in
    /usr/lib/rpm/redhat/macro (in redhat-rpm-config rpm):
    https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Preventing_files.2Fdirectories_from_being_scanned_for_provides_.28pre-scan_filtering.29

    ! Note that current way of yours does not work as you expected, see:
      http://koji.fedoraproject.org/koji/taskinfo?taskID=2327705
      http://koji.fedoraproject.org/koji/getfile?taskID=2327705&name=build.log

* Release number
  - Please use <integer>%{?dist} for Release number (expect for some exceptions)
    (2%{?dist}, for example).

* BuildRoot
  - BuildRoot tag is now no longer used on Fedora so please remove
    this.
    ! Note:
      - If you want to import this package also into EPEL, please follow:
        https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Distribution_specific_guidelines

* python-devel BuildRequires:
  - Now please explicitly specify python2-devel or python3-devel for
    (Build)Requires:
    https://fedoraproject.org/wiki/Packaging/Python#BuildRequires

* KDE BuildRequires
  - This packge uses Qt4, so only KDE4 should be needed.
    Please write "BR: kdelibs4-devel" only and remove "BR: kdelibs3-devel".
    ! Note
      - Unfortunately, it seems that the needed "libkdeui.so" (for -lkdeui) is
        under %_libdir/kde4/devel (in kdelibs-devel), so you have to
        add "export LDFLAGS=-L%{_libdir}/kde/devel" or something else
        before "python setup.py build".

* %defattr
  - We usually use %defattr(-,root,root,-) for default %defattr

* Directory ownership issue
  - The directory %{python_sitelib}/%{upstream_name}/ itself is not owned
    by any packages.

* python_sitelib v.s. python_sitearch
-------------------------------------------------------------------------
    24  # Actually the main package is noarch but -gnome and -kwallet contain
-------------------------------------------------------------------------
  - Well, however on x86_64 files in even main package are also installed
    under %python_sitearch:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=2327573

* rpmlint issue
-------------------------------------------------------------------------
python-keyring.src: W: strange-permission keyring-0.2.tar.gz 0777L
python-keyring.src: W: strange-permission python-keyring.spec 0777L
-------------------------------------------------------------------------
  - Please change the permission of the files in srpm to 0644.

ping?

(In reply to comment #18)
> * Release number
>   - Please use <integer>%{?dist} for Release number (expect for some
> exceptions)
>     (2%{?dist}, for example).

Yes that should be updated, I just put my numbers behind the dist tag to make sure I get the official Fedora RPM through updates...

> * python_sitelib v.s. python_sitearch
> -------------------------------------------------------------------------
>     24  # Actually the main package is noarch but -gnome and -kwallet contain
> -------------------------------------------------------------------------
>   - Well, however on x86_64 files in even main package are also installed
>     under %python_sitearch:
>     http://koji.fedoraproject.org/koji/taskinfo?taskID=2327573

Do you have a proposal how to fix that? As I wrote in the spec file: 
"Actually the main package is noarch but -gnome and -kwallet contain  architecture-specific code. Currently it's impossible to have a noarch main
package with arch-specific subpackages. Therefore we can't use 'noarch' here."

I'd be delighted if we can have a noarch main package with arch-specific code.

(In reply to comment #20)
> > * python_sitelib v.s. python_sitearch
> > -------------------------------------------------------------------------
> >     24  # Actually the main package is noarch but -gnome and -kwallet contain
> > -------------------------------------------------------------------------
> >   - Well, however on x86_64 files in even main package are also installed
> >     under %python_sitearch:
> >     http://koji.fedoraproject.org/koji/taskinfo?taskID=2327573
> 
> Do you have a proposal how to fix that? As I wrote in the spec file: 
> "Actually the main package is noarch but -gnome and -kwallet contain 
> architecture-specific code. 

- What I am saying here is that (as I said in the previous comment)
  even main package installs files under %python_sitearch, not
  %python_sitelib (i.e. the directory used by main package is
  arch-dependent)

  So even main package is currently arch-dependent, not noarch, and
  there is no need to fix this.

ping again, Ratnadeep?

Hi,

I got busy on coding for wordgroupz. It almost ready for v 0.3 release.

I updated the SPEC file as suggested, but koji scratch build is failing on
x86_64 platform. 

error: File not found: /builddir/build/BUILDROOT/python-keyring-0.2-2.fc13.x86_64/usr/lib/python2.6/site-packages/keyring
error: File not found by glob: /builddir/build/BUILDROOT/python-keyring-0.2-2.fc13.x86_64/usr/lib/python2.6/site-packages/keyring-*.egg-info
+ umask 022

while the following succeeds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2425350

the following fails:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2425379
https://koji.fedoraproject.org/koji/taskinfo?taskID=2425413
https://koji.fedoraproject.org/koji/taskinfo?taskID=2425429

Hi, 

I finally got the SRPM successfully built at koji.

Updated the spec and srpm files.

Koji scratch build Url: http://koji.fedoraproject.org/koji/taskinfo?taskID=2425529
SPEC: http://rtnpro.fedorapoeple.org/Packages/SPECS/python-keyring.spec
SRPM: http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.2-2.fc13.src.rpm

At least please address the issues I mentioned before.

(In reply to comment #18)
> Some notes:
> 
> * Macro definition
>   - For defining %python_sitearch macro and so on, please follow
>     below:
>     https://fedoraproject.org/wiki/Packaging/Python#Macros
> 
> * Filtering Provides
>   - If you want to filter some Provides generated by rpmbuild,
>     you can now use "%filter_provides_in" macro as defined in
>     /usr/lib/rpm/redhat/macro (in redhat-rpm-config rpm):
>    
> https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Preventing_files.2Fdirectories_from_being_scanned_for_provides_.28pre-scan_filtering.29

  ! And still the current way of yours does not work as you expected, see:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=2429162
    http://koji.fedoraproject.org/koji/getfile?taskID=2429162&name=build.log

> * python-devel BuildRequires:
>   - Now please explicitly specify python2-devel or python3-devel for
>     (Build)Requires:
>     https://fedoraproject.org/wiki/Packaging/Python#BuildRequires
> 
> * KDE BuildRequires
>   - This packge uses Qt4, so only KDE4 should be needed.
>     Please write "BR: kdelibs4-devel" only and remove "BR: kdelibs3-devel".
>     ! Note
>       - Unfortunately, it seems that the needed "libkdeui.so" (for -lkdeui) is
>         under %_libdir/kde4/devel (in kdelibs-devel), so you have to
>         add "export LDFLAGS=-L%{_libdir}/kde/devel" or something else
>         before "python setup.py build".


* duplicate files entry
  - Now build.log complains:
----------------------------------------------------------------------
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/__init__.py
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/__init__.pyc
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/__init__.pyo
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/backend.py
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/backend.pyc
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/backend.pyo
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/core.py
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/core.pyc
warning: File listed twice: /usr/lib64/python2.7/site-packages/keyring/core.pyo
----------------------------------------------------------------------
    Note that the %files entry
----------------------------------------------------------------------
%files
%{python_sitearch}/%{upstream_name}
----------------------------------------------------------------------
    contains the directory %{python_sitearch}/%{upstream_name} itself
    and all files / directories / etc under this directory, while
----------------------------------------------------------------------
%files
%dir %{python_sitearch}/%{upstream_name}
----------------------------------------------------------------------
    contains the directory %{python_sitearch}/%{upstream_name} only.

ping?

ping again?

If no one picks this up, I'm willing to take over. However I'd like to wait some time as I prefer some one else doing this for me.

I updated the buildrequires to kdelibs4-devel. I also added 
LDFLAGS="-L %{_libdir}/kde/devel"
in the %build section. I installed kdelibs4-devel in my system.
After executing rpmbuild -ba for python-keyring.spec, it successfully built the rpm and srpm. But it is failing to do a scratch build in koji.

(In reply to comment #29)
> I updated the buildrequires to kdelibs4-devel. I also added 
> LDFLAGS="-L %{_libdir}/kde/devel"
> in the %build section. I installed kdelibs4-devel in my system.
> After executing rpmbuild -ba for python-keyring.spec, it successfully built the
> rpm and srpm. But it is failing to do a scratch build in koji.

Koji scratch build successful.
Koji scratch build url : https://koji.fedoraproject.org/koji/taskinfo?taskID=2508667
I replaced  %{_libdir}/kde/devel with %{_libdir}/kde4/devel and build is working.

Please post the URLs of the new spec and srpm.
Also, please change the release version (when version number does
not change) every time you modify your spec file to avoid confusion.

ping?

SPEC Url : http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM Url : http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.2-3.fc13.src.rpm

Well, for -3:

* BR:
  - "BuildRequires: kdelibs-devel" is not needed. "BR: kdelib4-devel"
    is sufficient.

* Comments in macro
  - Please use %% instead of % in comment line to avoid unexpected
    macro expansion.
    And again, BuildRoot tag (line) is no longer needed on Fedora
    and EPEL6.

* %description
----------------------------------------------------------------------
python-keyring-kwallet.i686: E: description-line-too-long C Integrate python-keyring with KWallet so passwords can be read from/stored in the KWallet database.
----------------------------------------------------------------------
  - Please cut this line into 2 or so so that one line in %description
    won't exceed 79 characters.

* Filtering Provides/Requires
-----------------------------------------------------------------------
%global _use_internal_dependency_generator 0
%global __find_provides    %{_rpmconfigdir}/find-provides | grep -v 'gnome_keyring\|kde_kwallet'
%global __find_requires    %{_rpmconfigdir}/find-requires | grep -v 'gnome_keyring\|kde_kwallet'
-----------------------------------------------------------------------
  - Again this is not working. For example:
-----------------------------------------------------------------------
# rpm -qp --provides python-keyring-gnome-0.2-3.fc14.i686.rpm 
gnome_keyring.so  
python-keyring-gnome = 0.2-3.fc14
python-keyring-gnome(x86-32) = 0.2-3.fc14
-----------------------------------------------------------------------
    If you want to filter out "gnome_keyring.so" correctly, please refer
    to:
    https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
    e.g.
    https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Arch-specific_extensions_to_scripting_languages

SPEC Url : http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM Url :
http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.2-4.fc13.src.rpm

I removed the kdelibs-devel from BR, and filtered gnome_keyring.so from the output of rpm -qp --provides python-keyring-gnome-0.2-4.fc14.i686.rpm.

I still don't understand what you mean by comments in macros and to replace % by %%. Please explain.

Ah, it seems 0.4 is already released. Would you update to the
latest version first?

By the way these 3 lines
------------------------------------------------------------
%global _use_internal_dependency_generator 0
%global __find_provides    %%{_rpmconfigdir}/find-provides | grep -v 'gnome_keyring\|kde_kwallet'
%global __find_requires    %%{_rpmconfigdir}/find-requires | grep -v 'gnome_keyring\|kde_kwallet'
------------------------------------------------------------
are no longer needed. %filter_setup and so on actually do these
trick internally.

SPEC Url : http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM Url :
http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.4-1.fc13.src.rpm

I am unable to authenticate to the koji servers. So, I could not request to submit the srpm for a koji scratch build. I'm trying to get this issue fixed asap.

Okay.

-------------------------------------------------------------
    This package (python-keyring) is APPROVED by mtasaka
--------------------------------------------------------------

Please follow the procedure written on:
http://fedoraproject.org/wiki/PackageMaintainers/Join
from "Add Package to Source Code Management (SCM) system and Set Owner".

Now I am sponsoring you.

If you want to import this package into Fedora 13/14/EL?, you also have
to look at
http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT
(after once you rebuilt this package on koji Fedora rebuilding system).

When using Fedora SCM system, please check below for reference:
http://fedoraproject.org/wiki/Using_Fedora_GIT

If you have questions, please ask me.

Removing NEEDSPONSOR.

New Package SCM Request
=======================
Package Name: python-keyring
Short Description: keyring module for python
Owners: rtnpro
Branches: F-13 F-14 EL-5
InitialCC: rtnpro

Git done (by process-git-requests).

@Mamoru Tasaka

Please refer to https://koji.fedoraproject.org/koji/taskinfo?taskID=2583736
The EL-5 build is failing.

Blow is the build log:

Mock Version: 1.1.5
Mock Version: 1.1.5
Mock Version: 1.1.5
ENTER do(['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/python-keyring.spec'], False, '/var/lib/mock/dist-5E-epel-build-920083-135491/root/', None, 86400, True, 0, 497, 497, None, logger=<mock.trace_decorator.getLog object at 0x104c490>)
Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/python-keyring.spec']
error: Group field must be present in package: python-keyring-gnome
Building target platforms: x86_64
Building for target x86_64
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/python-keyring.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.6/site-packages/mock/util.py", line 345, in do
    raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bs --target x86_64 --nodeps builddir/build/SPECS/python-keyring.spec']
LEAVE do --> EXCEPTION RAISED

(In reply to comment #41)
> 
> error: Group field must be present in package: python-keyring-gnome

Try to add "Group:" entry for each subpackage.

I added "Group:" entry for the gnome and kde subpackages. I submitted it for koji scratch build and it failed.
https://koji.fedoraproject.org/koji/taskinfo?taskID=2583854
The build.log contains only:
Mock Version: 1.1.4
Mock Version: 1.1.4

(In reply to comment #43)
> I added "Group:" entry for the gnome and kde subpackages. I submitted it for
> koji scratch build and it failed.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=2583854
> The build.log contains only:
> Mock Version: 1.1.4
> Mock Version: 1.1.4

http://koji.fedoraproject.org/koji/getfile?taskID=2583857&name=root.log
> error: unpacking of archive failed on file /builddir/build/SOURCES/keyring-0.4.tar.gz;4cd62542: cpio: MD5 sum mismatch

EPEL5 rpm (4.4.2.3) does not support new file digest. If you want to
try scratch build on koji for EPEL5, recreate srpm with "$ rpmbuild-md5 -bs"

Would you rebuild this package at least for F-15, and
submit push requests on bodhi for F-14/13?

Sorry for the absence. :(
I got busy here with submission of my research paper for review, plus college seminars.

I am submitting a scratch build for my packages for f15. 
Do I need to make a SCM request for f15? I cannot switch to f15 in my fedora-git folder.

$fedpkg switch-branch f15 
Unable to switch to another branch: Unknown remote branch f15

Apart from that, for pushing the package to bodhi, please check if the fields chosen are correct :
Type : newpackage
Request : Testing
Bugs : #593800
and others default values

python-keyring-0.4-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/python-keyring-0.4-1.fc14

python-keyring-0.4-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/python-keyring-0.4-1.fc13

(In reply to comment #46)
> I am submitting a scratch build for my packages for f15. 
> Do I need to make a SCM request for f15? I cannot switch to f15 in my
> fedora-git folder.
> 
> $fedpkg switch-branch f15 
> Unable to switch to another branch: Unknown remote branch f15

- Currently there is no "f15" branch on Fedora git. Packages for
  F-15 (rawhide) is currently built from "master" branch, so please
  use "master".


> Apart from that, for pushing the package to bodhi, please check if the fields
> chosen are correct :
> Type : newpackage
> Request : Testing
> Bugs : #593800
> and others default values


- Seems correct, thank you.

python-keyring-0.4-1.fc13 has been pushed to the Fedora 13 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 'yum --enablerepo=updates-testing update python-keyring'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/python-keyring-0.4-1.fc13

@Mamoru Tasaka

built rpm for keyring-0.5

Koji scratch build Url: http://koji.fedoraproject.org/koji/taskinfo?taskID=2615701

Please check it. Now, I think we can release python-keyring as a noarch since it no longer depends on the c++ libraries. Also, I am uncertain about the Requires packages. Do I need to include
Requires : PyKDE4 PyQt4
for kde
Gnome doesn't seem to have any specific dependency.

(In reply to comment #51)
> @Mamoru Tasaka
> 
> built rpm for keyring-0.5
> 
> Koji scratch build Url:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2615701
> 
> Please check it. Now, I think we can release python-keyring as a noarch since
> it no longer depends on the c++ libraries. Also, I am uncertain about the
> Requires packages. Do I need to include
> Requires : PyKDE4 PyQt4
> for kde
> Gnome doesn't seem to have any specific dependency.

Well,
- at least new python-keyring binary rpm must have
  "Obsoletes: %{name}-gnome < 0.5", "Obsoletes: %{name}-kwallet < 0.5"
  and "Obsoletes: %{name}-debuginfo < 0.5" (because of arch-dependent ->
  noarch switch).

- Currently I don't think we should add "Requires: PyKDE4 PyQt4" for
  functionality on KDE, and we don't have to add "Provides: %{name}-gnome = foo"
  or so (repoquery shows that currently no packages on Fedora depend
  on python-keyring-{gnome,kwallet} on F-15/14/13)

(In reply to comment #52)
> Well,
> - at least new python-keyring binary rpm must have
>   "Obsoletes: %{name}-gnome < 0.5", "Obsoletes: %{name}-kwallet < 0.5"
>   and "Obsoletes: %{name}-debuginfo < 0.5" (because of arch-dependent ->
>   noarch switch).
> 
> - Currently I don't think we should add "Requires: PyKDE4 PyQt4" for
>   functionality on KDE, and we don't have to add "Provides: %{name}-gnome =
> foo"
Actually the latest python keyring code imports PyKDE4 and PyQt4 modules. So I think there should be "Requires: PyKDE4 PyQt4"

Also, is it necessary to keep the gnome and KDE subpackages with the new package?

(In reply to comment #53)
> (In reply to comment #52)
> > Well,
> > - at least new python-keyring binary rpm must have
> >   "Obsoletes: %{name}-gnome < 0.5", "Obsoletes: %{name}-kwallet < 0.5"
> >   and "Obsoletes: %{name}-debuginfo < 0.5" (because of arch-dependent ->
> >   noarch switch).
> > 
> > - Currently I don't think we should add "Requires: PyKDE4 PyQt4" for
> >   functionality on KDE, and we don't have to add "Provides: %{name}-gnome =
> > foo"
> Actually the latest python keyring code imports PyKDE4 and PyQt4 modules.
- If they exist, otherwise keyring/backend.py won't use them.
  So people who wants to use KDE support can install them afterwards.
  Forcing people to install PyKDE4 or PyQt4 even for GNOME user when
  wanting to use python-keyring is not a good idea.

> So I
> think there should be "Requires: PyKDE4 PyQt4"
> 
> Also, is it necessary to keep the gnome and KDE subpackages with the new
> package?
- So:
  - If you want to remove -gnome / -kwallet subpackage (because they
    have no files any longer),
    - As I said before "Obsoletes: foo" is needed, and "Requires: PyKDE4"
      or so should be removed
  - If you want to leave -gnome / -kwallet subpackages (even if they
    are empty), I don't oppose to it, however I prefer to remove
    these subpackages.

It seems that python-keyring-0.5 is failing to run in gnome

Importing keyring module installed by python-keyring-0.5 gives the following error:

>>> import keyring
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/keyring/__init__.py", line 9, in <module>
    from core import set_keyring, get_keyring, set_password, get_password
  File "/usr/lib/python2.7/site-packages/keyring/core.py", line 12, in <module>
    from keyring import backend
  File "/usr/lib/python2.7/site-packages/keyring/backend.py", line 171, in <module>
    if not kwallet.hasFolder('Python'):
AttributeError: 'NoneType' object has no attribute 'hasFolder'

Seems, even in gnome, it is calling for kwallet. This was not the case with python-keyring-0.4

Anyway once closing.

python-keyring has been updated to version 0.5.1 and I couldn't upload
the packages for some time because of proxy server issues with BSNL
3G. I, somehow, am able to upload and build at koji. The latest
packages for python-keyring built successfully for fc15, fc14, fc13.

SPEC Url:http://rtnpro.fedorapeople.org/Packages/SPECS/python-keyring.spec
SRPM Url:http://rtnpro.fedorapeople.org/Packages/SRPMS/python-keyring-0.5.1-1.fc14.src.rpm
Koji Url:http://koji.fedoraproject.org/koji/taskinfo?taskID=2747641

python-keyring-0.5.1-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/python-keyring-0.5.1-1.fc14

python-keyring-0.5.1-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/python-keyring-0.5.1-1.fc13

python-keyring-0.7-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/python-keyring-0.7-1.fc16

python-keyring-0.7-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/python-keyring-0.7-1.fc15

Package Change Request
======================
Package Name: python-keyring
New Branches: el6
Owners: pbrady rtnpro

Git done (by process-git-requests).

Package Change Request
======================
Package Name: python-keyring
New Branches: epel7
Owners: cicku pbrady rtnpro

Git done (by process-git-requests).