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 Description: The Python keyring lib provides a easy way to access the system keyring service from python. It can be used in any application that needs safe password storage.
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 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.
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
Package Change Request ====================== Package Name: python-keyring New Branches: epel7 Owners: cicku pbrady rtnpro