Spec URL: http://pastebin.ca/1296899 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-1.fc10.src.rpm Description: GGet is a Download Manager for the GNOME desktop, developed during Google Summer of Code 2008. http://live.gnome.org/GGet This, along with https://bugzilla.redhat.com/show_bug.cgi?id=475144 are my first packages and I am looking for a sponsor.
Hi Christoph, are you going to sponsor Ant? By the way I am reviewing another review request by Ant (bug 475144 : metalink) and I guess this one (metalink) can be approved (with a little more fix if needed).
Spec URL: http://pastebin.ca/1303751 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-2.fc10.src.rpm I have tried to incorporate Mamoru's suggestions for my other package, where applicable here. I also added the Epiphany extension with a BuildRequires: epiphany-devel but without a Requires: epiphany is that the correct way to do it?
(In reply to comment #1) > Hi Christoph, are you going to sponsor Ant? Depends on the review here. (In reply to comment #2) > I also added the Epiphany extension with a > BuildRequires: epiphany-devel > > but without a > Requires: epiphany > > is that the correct way to do it? Nope. You should make a subpackage for the epiphany extension. Please have a look at my gwget spec if you need help with this: http://cvs.fedoraproject.org/viewvc/rpms/gwget/F-10/gwget.spec?view=markup
(In reply to comment #3) > (In reply to comment #2) > > I also added the Epiphany extension with a > > BuildRequires: epiphany-devel > > > > but without a > > Requires: epiphany > > > > is that the correct way to do it? > > Nope. You should make a subpackage for the epiphany extension. Please have a > look at my gwget spec if you need help with this: > http://cvs.fedoraproject.org/viewvc/rpms/gwget/F-10/gwget.spec?view=markup Thank you, that more than helps! I've borrowed heavily from it. :) Spec URL: http://pastebin.ca/1303914 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-3.fc10.src.rpm Here is what rpmlint reports gget.noarch: W: conffile-without-noreplace-flag /etc/gconf/schemas/gget.schemas gget-epiphany-extension.noarch: W: no-documentation gget-epiphany-extension.noarch: E: only-non-binary-in-usr-lib 2 packages and 0 specfiles checked; 1 errors, 2 warnings. The bad news: gget will not run for me now, either this new rpm or the old ones I made. I updated my system today, I wonder if that's the cause.
(In reply to comment #4) > Here is what rpmlint reports > gget.noarch: W: conffile-without-noreplace-flag /etc/gconf/schemas/gget.schemas > gget-epiphany-extension.noarch: W: no-documentation > gget-epiphany-extension.noarch: E: only-non-binary-in-usr-lib > 2 packages and 0 specfiles checked; 1 errors, 2 warnings. All these are save to ignore: gconf files are no config files, but rpmlint thinks so because they are in /etc. The epiphany-extension package needs no docs because they are in the main package. The last error is because it's a noarch python package and rpmlint expects some binaries. But now we have another problem: The package needs to be arch-dependent instead of noarch, at least the epiphany subpackage because %{_libdir}/epiphany/ depends on the installed architecture. > The bad news: gget will not run for me now, either this new rpm or the old ones > I made. I updated my system today, I wonder if that's the cause. No, it because gget can't find it's icon and crashes: $ gget Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or Symbol »gget« nicht im Thema vorhanden) Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or Symbol »gget« nicht im Thema vorhanden) Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or Symbol »gget« nicht im Thema vorhanden) Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or Symbol »gget« nicht im Thema vorhanden) Traceback (most recent call last): File "/usr/bin/gget", line 42, in <module> application.run() File "/usr/lib/python2.5/site-packages/gget/application.py", line 50, in run gtk.window_set_default_icon_list(*gui.get_icon_list([16, 22, 24, 32])) TypeError: icons must be GdkPixbufs This is because you are installing icons in /usr/share/icons/hicolor but you are not running gtk-update-icon-cache afterwards. See https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GTK.2B_icon_cache You can remove the "%define epimajor 2.23" it's not really needed for your package. Using wildcards IMO is ok here.
(In reply to comment #5) > (In reply to comment #4) > > Here is what rpmlint reports > > gget.noarch: W: conffile-without-noreplace-flag /etc/gconf/schemas/gget.schemas > > gget-epiphany-extension.noarch: W: no-documentation > > gget-epiphany-extension.noarch: E: only-non-binary-in-usr-lib > > 2 packages and 0 specfiles checked; 1 errors, 2 warnings. > > All these are save to ignore: gconf files are no config files, but rpmlint > thinks so because they are in /etc. The epiphany-extension package needs no > docs because they are in the main package. The last error is because it's a > noarch python package and rpmlint expects some binaries. Thanks, Christoph. Ok. > But now we have another problem: The package needs to be arch-dependent instead > of noarch, at least the epiphany subpackage because %{_libdir}/epiphany/ > depends on the installed architecture. I took out the noarch, because it wouldn't let me have a subpackage that was arch-dependent when the package was noarch. Do I need to switch to %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} at the beginning of the spec file? It says "sitelib for noarch packages, sitearch for others" > > The bad news: gget will not run for me now, either this new rpm or the old ones > > I made. I updated my system today, I wonder if that's the cause. > > No, it because gget can't find it's icon and crashes: > > $ gget > Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or > Symbol »gget« nicht im Thema vorhanden) > Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or > Symbol »gget« nicht im Thema vorhanden) > Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or > Symbol »gget« nicht im Thema vorhanden) > Error:load_icon:Icon Load Error:Symbol »gget« nicht im Thema vorhanden (or > Symbol »gget« nicht im Thema vorhanden) > Traceback (most recent call last): > File "/usr/bin/gget", line 42, in <module> > application.run() > File "/usr/lib/python2.5/site-packages/gget/application.py", line 50, in run > gtk.window_set_default_icon_list(*gui.get_icon_list([16, 22, 24, 32])) > TypeError: icons must be GdkPixbufs Why don't I see any output when I run gget from a terminal? Even with this change, gget still doesn't run for me. > This is because you are installing icons in /usr/share/icons/hicolor but you > are not running gtk-update-icon-cache afterwards. See > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GTK.2B_icon_cache Ok, done. > You can remove the "%define epimajor 2.23" it's not really needed for your > package. Using wildcards IMO is ok here. I removed "%define epimajor 2.23". Where should I use wildcards? Spec URL: http://pastebin.ca/1304091 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-4.fc10.src.rpm
(In reply to comment #6) > Do I need to switch to > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > at the beginning of the spec file? It says "sitelib for noarch packages, > sitearch for others" No, because you are not using %{python_arch} anywhere in the %files section. Remove the %{!?python_sitearch:... from the spec, you are not going to need it. > Why don't I see any output when I run gget from a terminal? No idea, you should. > Even with this change, gget still doesn't run for me. What version and arch are you using? > Ok, done. Yeah, but you are using /usr/share/icons/hicolor/*/apps/gget.* which is STRICTLY forbidden. Needs to be %{_datadir}/icons/hicolor/*/apps/gget.* > I removed "%define epimajor 2.23". Where should I use wildcards? You removed the 'define...', but you did not remove %{epimajor} from Requires/BuildRequires. IMO you can remove both and then use wildcards in the files section (as you already do). A site note on this issue: $ rpm -ql gget-epiphany-extension | grep epi /usr/lib/epiphany /usr/lib/epiphany/2.22 /usr/lib/epiphany/2.22/extensions ... As you can see these three directories are already owned by epiphany and there should not be duplicate dir ownerships as outlined in https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership So usually we would just own the files, not the dirs with %{_libdir}/epiphany/2.22/extensions/py* The problem is: If epiphany gets updated from 2.22 to 2.23 the three directories will become unowned. BTW: This also means you will need to to a rebuild gget after every major version update of epiphany.
(In reply to comment #7) > (In reply to comment #6) > > Do I need to switch to > > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from > > distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > > > at the beginning of the spec file? It says "sitelib for noarch packages, > > sitearch for others" > > No, because you are not using %{python_arch} anywhere in the %files section. > Remove the %{!?python_sitearch:... from the spec, you are not going to need it. Removed. > > Why don't I see any output when I run gget from a terminal? > > No idea, you should. It works now. > > Even with this change, gget still doesn't run for me. > > What version and arch are you using? It runs now, my 0.0.4-4 and 0.0.4-5 versions, i386. > > Ok, done. > > Yeah, but you are using /usr/share/icons/hicolor/*/apps/gget.* which is > STRICTLY forbidden. Needs to be %{_datadir}/icons/hicolor/*/apps/gget.* Ok, changed it. > > I removed "%define epimajor 2.23". Where should I use wildcards? > > You removed the 'define...', but you did not remove %{epimajor} from > Requires/BuildRequires. IMO you can remove both and then use wildcards in the > files section (as you already do). Ok, removed %{epimajor} everywhere. > A site note on this issue: > > $ rpm -ql gget-epiphany-extension | grep epi > /usr/lib/epiphany > /usr/lib/epiphany/2.22 > /usr/lib/epiphany/2.22/extensions > ... > > As you can see these three directories are already owned by epiphany and there > should not be duplicate dir ownerships as outlined in > https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership > So usually we would just own the files, not the dirs with > %{_libdir}/epiphany/2.22/extensions/py* I'm using Fedora 10, which has Epiphany 2.24. So I used %{_libdir}/epiphany/*/extensions/gget* Is that ok? > The problem is: If epiphany gets updated from 2.22 to 2.23 the three > directories will become unowned. What do I need to do? Just the rebuilds you mention below? > BTW: This also means you will need to to a rebuild gget after every major > version update of epiphany. That's not a problem for me. Spec URL: http://pastebin.ca/1305804 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-5.fc10.src.rpm
(In reply to comment #8) > (In reply to comment #7) > > As you can see these three directories are already owned by epiphany and there > > should not be duplicate dir ownerships as outlined in > > https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership > > So usually we would just own the files, not the dirs with > > %{_libdir}/epiphany/2.22/extensions/py* > > I'm using Fedora 10, which has Epiphany 2.24. So I used > > %{_libdir}/epiphany/*/extensions/gget* > > Is that ok? No. It would be ok if you followed the 'no duplicate directory ownership' rule, but in this case we cannot use it, because it will leave unowned dirs behind. It's better if two packages own the a dir than no package. So you should use %{_libdir}/epiphany/*/ > > > The problem is: If epiphany gets updated from 2.22 to 2.23 the three > > directories will become unowned. > > What do I need to do? Just the rebuilds you mention below? With the line you are using now you would need to do a rebuild a rebuild in time with epiphany, but _after_ it has been pushed out, because you are building against it. The users would have to install your update in the same rpm transaction as the epiphany update and in the correct order. You see: This is nearly impossible, that's why the 'no duplicate ownership' model doesn't work here. I have to admit that this is a very special case, but you can take it as a chance to learn something about packaging. ;) Maybe we can clean this up with a symlink without version, but this would need to be done in the epiphany package. %{_sysconfdir}/gconf/schemas/gget.schemas should not be marked as %config because gconf schemas are not meant to be changed by users and need to get replaced on updates. No need to update your package now, wait for the review and then fix all issues in one release. Sorry I did not manage to do the review today, but I will tomorrow.
(In reply to comment #9) > (In reply to comment #8) > > I'm using Fedora 10, which has Epiphany 2.24. So I used > > > > %{_libdir}/epiphany/*/extensions/gget* > > > > Is that ok? > > No. It would be ok if you followed the 'no duplicate directory ownership' rule, > but in this case we cannot use it, because it will leave unowned dirs behind. > It's better if two packages own the a dir than no package. > > So you should use > %{_libdir}/epiphany/*/ Please ask nautilus maintainer to make nautilus own %{_libdir}/epiphany/%{ephy_major}/extensions before doing such a thing ref: https://bugzilla.redhat.com/show_bug.cgi?id=459088#c25 https://bugzilla.redhat.com/show_bug.cgi?id=469491 > > > The problem is: If epiphany gets updated from 2.22 to 2.23 the three > > > directories will become unowned. > > > > What do I need to do? Just the rebuilds you mention below? > > With the line you are using now you would need to do a rebuild a rebuild in > time with epiphany, but _after_ it has been pushed out, because you are > building against it. This should only happen on rawhide, no problem.
(In reply to comment #10) > Please ask nautilus maintainer to make nautilus own > %{_libdir}/epiphany/%{ephy_major}/extensions before doing such a thing > ref: > https://bugzilla.redhat.com/show_bug.cgi?id=459088#c25 > https://bugzilla.redhat.com/show_bug.cgi?id=469491 No nautilus, epiphany...
(In reply to comment #10) > Please ask nautilus maintainer to make nautilus own > %{_libdir}/epiphany/%{ephy_major}/extensions before doing such a thing > ref: > https://bugzilla.redhat.com/show_bug.cgi?id=459088#c25 > https://bugzilla.redhat.com/show_bug.cgi?id=469491 Mamoru, at least %{_libdir}/epiphany/ and %{_libdir}/epiphany/%{version} _are_ already owned by epiphany and also owning %{_libdir}/epiphany/%{version}/extensions will _not_ help us here. Imagine this: /usr/lib/epiphany /usr/lib/epiphany/2.22 /usr/lib/epiphany/2.22/extensions/gget.py* When epiphany gets updated to 2.23 we have: /usr/lib/epiphany (unowned) /usr/lib/epiphany/2.22 (unowned) /usr/lib/epiphany/2.22/extensions/gget.py* (unowned) /usr/lib/epiphany /usr/lib/epiphany/2.23 /usr/lib/epiphany/2.23/extensions The next day the gget update comes: /usr/lib/epiphany (unowned) /usr/lib/epiphany/2.22 (unowned) /usr/lib/epiphany/2.22/extensions (unowned and empty) /usr/lib/epiphany /usr/lib/epiphany/2.23 /usr/lib/epiphany/2.23/extensions/gget.py* The problem is the version number in there. > This should only happen on rawhide, no problem. You are right, there will be no major version update in the stable release. But the other two problems will remain. We only have the alternatives of - ether let both packages own the dirs or - use strictly versioned deps and delay the epiphany update in rawhide because of them. This is just like the firefox nightmares. To me the latter is the worst. I'm open to suggestions though, because my gwget package is also affected. I have been trying to find it's review, but gwget is one of the former fedora.us packages and I took it over some time ago. The only solution I can think of: Make epiphany own %{_libdir}/epiphany/ %{_libdir}/epiphany/plugins %{_libdir}/epiphany/extensions %{_libdir}/epiphany/%{version} %{_libdir}/epiphany/%{version}/plugins -> %{_libdir}/epiphany/plugins %{_libdir}/epiphany/%{version}/extensions -> %{_libdir}/epiphany/extensions What do you think, Mamoru?
(In reply to comment #12) > (In reply to comment #10) > Imagine this: > /usr/lib/epiphany > /usr/lib/epiphany/2.22 > /usr/lib/epiphany/2.22/extensions/gget.py* > > When epiphany gets updated to 2.23 we have: > /usr/lib/epiphany (unowned) > /usr/lib/epiphany/2.22 (unowned) > /usr/lib/epiphany/2.22/extensions/gget.py* (unowned) > /usr/lib/epiphany > /usr/lib/epiphany/2.23 > /usr/lib/epiphany/2.23/extensions Well, - As when epiphany is upgrade from 2.22 to 2.23, then I guess gget-epiphany-extension will no longer work (although I don't know this package well) unless gget is rebuilt against new epiphany. i.e. if epiphany can be upgraded without gget-epiphany-extension is rebuilt, it is _already_ wrong. Not-rebuilt gget-epiphany-extension should prevent epiphany from being upgraded in such a case (theoretically). Some idea: - Add "Conflicts: epiphany >= 2.23" "Conflicts: epiphany < 2.22" - Ask epiphany maintainer to support "Provides: epiphany(abi) = 2.22", for example.
Also, as some packages already use %_libdir/epiphany/XXXX/extensions, making every package use this directory own this directory cannot be accepted and the owner of this directory must be unified.
(In reply to comment #13) > - As when epiphany is upgrade from 2.22 to 2.23, then > I guess gget-epiphany-extension will no longer work (although > I don't know this package well) unless gget is rebuilt > against new epiphany. Correct. It will no longer work because epiphany won't find it, because it's looking in a different location. > i.e. if epiphany can be upgraded without gget-epiphany-extension > is rebuilt, it is _already_ wrong. Not-rebuilt gget-epiphany-extension > should prevent epiphany from being upgraded in such a case > (theoretically). I disagree. It's better to temporarily loose a certain functionality than prevent epiphany from being updated. People who are using rawhide are used to thinks breaking from time to time, but still they are running rawhide because they want to follow the latest development. What if the epiphany update is part of a larger Gnome update? The older epiphany might no longer work with the updated Gnome stuff and then we make the whole app useless instead of a single extension. > Some idea: > - Add "Conflicts: epiphany >= 2.23" > "Conflicts: epiphany < 2.22" Congratulations, you have just made it conflict with _every_ epiphany release! :) > - Ask epiphany maintainer to support "Provides: epiphany(abi) = 2.22", > for example. And them make the extension "Requires: epiphany(abi) = 2.22"? What's the advantage over "Requires: epiphany = 2.22"? (In reply to comment #14) > Also, as some packages already use %_libdir/epiphany/XXXX/extensions, > making every package use this directory own this directory cannot be > accepted and the owner of this directory must be unified. Why? We have a couple of these situations whenever one package does not necessarily depend on the other. Duplicate ownership of a dir is bad, but unowned dirs are even worse.
(In reply to comment #15) > (In reply to comment #13) > > i.e. if epiphany can be upgraded without gget-epiphany-extension > > is rebuilt, it is _already_ wrong. Not-rebuilt gget-epiphany-extension > > should prevent epiphany from being upgraded in such a case > > (theoretically). > > I disagree. It's better to temporarily loose a certain functionality than > prevent epiphany from being updated. People who are using rawhide are used to > thinks breaking from time to time, but still they are running rawhide because > they want to follow the latest development. > What if the epiphany update is part of a larger Gnome update? The older > epiphany might no longer work with the updated Gnome stuff and then we make the > whole app useless instead of a single extension. "A larger Gnome update" in your sense had been already disturbed before many times (largely because some new gnome components won't build against new gnome libraries, gnome-desktop for example...). Other packages failing to rebuild have also prevented major packages in your sense from being upgraded. I can see no gain to loose dependency on this package for the reason you raised (and for this package you can simply remove this, while for gnome-desktop (for example) we actually have to wait until (almost) all package are rebuilt) > > Some idea: > > - Add "Conflicts: epiphany >= 2.23" > > "Conflicts: epiphany < 2.22" > > Congratulations, you have just made it conflict with _every_ epiphany release! > :) First of all: - Please don't use "congratulations" ":)" or "!" carelessly, please. While I don't know how commonly these words or emoticons are used in discussions like this bug report in your country, these words can be taken very differently than what you expect in other countries. Then: if epiphany has 2.22{,X} version, the epiphany won't conflict with these two. Note that this method is sometimes used when - A srpm creates 2 (or more) subpackages - The two packages don't depend on each other, and can be installed seperately or together - However if the versions of the two package differ, something nasty could occur > > - Ask epiphany maintainer to support "Provides: epiphany(abi) = 2.22", > > for example. > > And them make the extension "Requires: epiphany(abi) = 2.22"? What's the > advantage over "Requires: epiphany = 2.22"? It won't work for ephiphany minor release bump (i.e. 2.22.3, for example) For example ruby has "Provides: ruby(abi) = 1.8" while the current ruby version (on Fedora) is 1.8.6(.287) (and actually I think if epiphany changes the extension every time its major/middle version changes, epiphany should provide such information to rpm, like ruby, python or so actually do) > (In reply to comment #14) > > Also, as some packages already use %_libdir/epiphany/XXXX/extensions, > > making every package use this directory own this directory cannot be > > accepted and the owner of this directory must be unified. > > Why? We have a couple of these situations whenever one package does not > necessarily depend on the other. Duplicate ownership of a dir is bad, but > unowned dirs are even worse. But they all depend on epiphany. So I am asking you to ask epiphany maintainer first (as I did to vim maintainer). It is not desired that no one using that directory tries to argue with epiphany maintainer and gets satisfied with his/her "local" hack. KDE has kde-filesystem, font packages got to use fontpackages-filesystem and so on. Please contact with epiphany maintainer first.
(In reply to comment #16) > Other packages failing to rebuild have also prevented major packages in > your sense from being upgraded. I can see no gain to loose dependency > on this package for the reason you raised (and for this package > you can simply remove this, while for gnome-desktop (for example) > we actually have to wait until (almost) all package are rebuilt) I was not talking about packages that fail to rebuild but about packages that stop working after an update, although all dependencies are still met. Please ask yourself, what is better from a users point of view: a) When epiphany gets updated he will loose the functionality of the gget extension until it's getting rebuilt. When gget gets updated afterwards, everything is fine again: everything works, no orphaned dirs b) When epiphany gets updated the update will fail due to broken deps. The user has to work around them by removing gget-epiphany-extension and installing it and to re-install it when it was rebuilt. Or he has to wait and to bear the risk that epiphany itself gets broken. I know that my suggestion does not follow the rules, but IMO we don't need to follow a rule as if it was a mantra. > Then: > if epiphany has 2.22{,X} version, the epiphany won't conflict > with these two. You are right, I did not think if the minor version. Nevertheless "Conflicts" must only be used when packages really conflict, this means they cannot be installed at the same time, e.g. because both provide the same files or functionality. > So I am asking you to ask epiphany maintainer first (as I did to > vim maintainer). It is not desired that no one using that > directory tries to argue with epiphany maintainer and gets satisfied with > his/her "local" hack. > KDE has kde-filesystem, font packages got to use fontpackages-filesystem > and so on. Please contact with epiphany maintainer first. And we have mozilla-filesystem and we have ... I think a filesystem package would be overkill here, but I agree you pointed out some valid points. OK, but I want to make a constructive suggestion and not only open a bug. So hat do you think abut my suggestion from the bottom of comment #13?
(In reply to comment #17) > So > hat do you think abut my suggestion from the bottom of comment #13? Of course I meant comment #12
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > As you can see these three directories are already owned by epiphany and there > > > should not be duplicate dir ownerships as outlined in > > > https://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership > > > So usually we would just own the files, not the dirs with > > > %{_libdir}/epiphany/2.22/extensions/py* > > > > I'm using Fedora 10, which has Epiphany 2.24. So I used > > > > %{_libdir}/epiphany/*/extensions/gget* > > > > Is that ok? > > No. It would be ok if you followed the 'no duplicate directory ownership' rule, > but in this case we cannot use it, because it will leave unowned dirs behind. > It's better if two packages own the a dir than no package. > > So you should use > %{_libdir}/epiphany/*/ Ok. > > > The problem is: If epiphany gets updated from 2.22 to 2.23 the three > > > directories will become unowned. > > > > What do I need to do? Just the rebuilds you mention below? > > With the line you are using now you would need to do a rebuild a rebuild in > time with epiphany, but _after_ it has been pushed out, because you are > building against it. The users would have to install your update in the same > rpm transaction as the epiphany update and in the correct order. You see: This > is nearly impossible, that's why the 'no duplicate ownership' model doesn't > work here. > I have to admit that this is a very special case, but you can take it as a > chance to learn something about packaging. ;) Maybe we can clean this up with a > symlink without version, but this would need to be done in the epiphany > package. Maybe I should have just disabled the epiphany-extension :) Nah, this is interesting. > %{_sysconfdir}/gconf/schemas/gget.schemas should not be marked as %config > because gconf schemas are not meant to be changed by users and need to get > replaced on updates. No need to update your package now, wait for the review > and then fix all issues in one release. Ok, removed the %config there. > Sorry I did not manage to do the review today, but I will tomorrow. No rush!
(In reply to comment #17) > (In reply to comment #16) > > Other packages failing to rebuild have also prevented major packages in > > your sense from being upgraded. I can see no gain to loose dependency > > on this package for the reason you raised (and for this package > > you can simply remove this, while for gnome-desktop (for example) > > we actually have to wait until (almost) all package are rebuilt) > > I was not talking about packages that fail to rebuild but about packages that > stop working after an update, although all dependencies are still met. So my viewpoint is that in this case the dependency is _not_ satisfied because gget-epiphany _actually_ needs epiphany(abi) = 2.22. For ruby, all ruby modules package have "Requires: ruby(abi) = 1.8" even if they are noarch and currently this is mandatory by ruby packaging guideline on Fedora. With forcely removing "Requires: ruby(abi) = 1.8" line from the spec file for ruby module package built as noarch, the package will allow ruby to be upgraded to 1.9 or so (I don't know ETA on Fedora, though), however then the ruby module will stop working. Current ruby package guideline strictly bans this. > Please ask yourself, what is better from a users point of view: > a) When epiphany gets updated he will loose the functionality of the gget > extension until it's getting rebuilt. When gget gets updated afterwards, > everything is fine again: everything works, no orphaned dirs > b) When epiphany gets updated the update will fail due to broken deps. The user > has to work around them by removing gget-epiphany-extension and installing it > and to re-install it when it was rebuilt. Or he has to wait and to bear the > risk that epiphany itself gets broken. So my opinition is b) (and on rawhide this frequently happens because it's rawhide... On released stable branches this should not occur) > > Then: > > if epiphany has 2.22{,X} version, the epiphany won't conflict > > with these two. > > You are right, I did not think if the minor version. Nevertheless "Conflicts" > must only be used when packages really conflict, this means they cannot be > installed at the same time, e.g. because both provide the same files or > functionality. This is exactly "functionality" case. > And we have mozilla-filesystem and we have ... I think a filesystem package > would be overkill here, but I agree you pointed out some valid points. > > OK, but I want to make a constructive suggestion and not only open a bug. So > hat do you think abut my suggestion from the bottom of comment #13? Well, I don't know if I grasped what you want to say here correctly, however anyway my current idea is - ephiphany should have "Provides: epiphany(abi) = 2.22" or so - epiphany should own %_libdir/epiphany/XXXX/extensions (and some other epiphany related directories if any)
(In reply to comment #20) > (In reply to comment #17) > > "Conflicts" > > must only be used when packages really conflict, this means they cannot be > > installed at the same time, e.g. because both provide the same files or > > functionality. > > This is exactly "functionality" case. You suggested epiphany to conflict with gget-epiphany-extension, but a web browser certainly does not provide the same functionality as download manager. > Well, I don't know if I grasped what you want to say here correctly, > however anyway my current idea is > - ephiphany should have "Provides: epiphany(abi) = 2.22" or so Please take a look at bug # 479921, where I have taken this suggestion into account. Malte obviously understood what I'm talking about. > - epiphany should own %_libdir/epiphany/XXXX/extensions (and > some other epiphany related directories if any) Yes, also applies to the plugins dir. Simply owning %_libdir/epiphany/XXXX/extensions will not help. We also need to get rid of the version, but all this is explained in bug # 479921. (In reply to comment #19) > Maybe I should have just disabled the epiphany-extension :) No need to, Malte already fixed it in rawhide, see http://koji.fedoraproject.org/koji/taskinfo?taskID=1052223 Not sure if/when this will appear in the other releases. > Nah, this is interesting. Indeed. Thanks to Mamoru for his feedback.
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #17) > > > "Conflicts" > > > must only be used when packages really conflict, this means they cannot be > > > installed at the same time, e.g. because both provide the same files or > > > functionality. > > > > This is exactly "functionality" case. > > You suggested epiphany to conflict with gget-epiphany-extension, but a web > browser certainly does not provide the same functionality as download manager. Ah, what I wanted to say is that - Package A can work with B installed or without B installed - But A won't work if B with _old_ version is installed: https://fedoraproject.org/wiki/Packaging/Conflicts#Optional_Functionality > > Well, I don't know if I grasped what you want to say here correctly, > > however anyway my current idea is > > - ephiphany should have "Provides: epiphany(abi) = 2.22" or so > > Please take a look at bug # 479921, where I have taken this suggestion into > account. Malte obviously understood what I'm talking about. > > > - epiphany should own %_libdir/epiphany/XXXX/extensions (and > > some other epiphany related directories if any) > > Yes, also applies to the plugins dir. Simply owning > %_libdir/epiphany/XXXX/extensions will not help. We also need to get rid of the > version, but all this is explained in bug # 479921. This seems pretty good!! Thank you for your effort (By the way if epiphany(abi) = foo is provided, Conflict method is no longer needed, just using "Requires: epiphany(abi) = foo" is much preferred. Or maybe also using this method is no longer needed... now that version-independent symlink is provided, need checking)
Although we are still waiting for the epipahny bug to be fixed, here is a preliminary review: Review for 969acdd5a5ca3e849221489021fdc9f5 gget-0.0.4-5.fc10.src.rpm FIX - MUST: $ rpmlint /var/lib/mock/fedora-rawhide-i386/result/gget-* gget.i386: E: no-binary gget.i386: W: conffile-without-noreplace-flag /etc/gconf/schemas/gget.schemas gget-debuginfo.i386: E: empty-debuginfo-package gget-epiphany-extension.i386: W: no-documentation gget-epiphany-extension.i386: E: only-non-binary-in-usr-lib 4 packages and 0 specfiles checked; 3 errors, 2 warnings. - First error is because of python and can be ignored. rpmlint expects python packages to be noarch, but we need to make this one arch dependent because of the epiphany extension. - Warning about the gconf schema can be ignored, see comment # 9 - The debuginfo package is empty because of python. You need to prevent it from being built by adding %define debug_package %{nil} somewhere at the beginning of the spec. See https://fedoraproject.org/wiki/Packaging/Debuginfo for more info - no doc warning for extension package can be ignored, doc is in the base package - the last error is also because of python and can be ignored. OK - MUST: The package is named according to the Package Naming Guidelines. OK - MUST: The spec file name matches the base package %{name}, in the format %{name}.spec. OK - MUST: The package meets the Packaging Guidelines (except for the issues mentioned) OK - MUST: The package is licensed with a Fedora approved license (GPLv2+) and meets the Licensing Guidelines. FIX - MUST: The License field in the package spec file does not match the actual license: The license included is GPLv2, but if you take a look at the py files you will see the typical "or any later version", so this is GPLv2+ FIX - MUST: The license file from the source package is not included in %doc. OK - MUST: The spec file is in American English. OK - MUST: The spec file for the package is legible. OK - MUST: The sources used to build the package match the upstream source by MD5 914d2d51186f6d24237409e59f8f9cde OK - MUST: The package successfully compiles and builds into binary rpms on i386 N/A - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. OK - MUST: All build dependencies are listed in BuildRequires, but there are a couple of redundant packages that don't need to be listed explicitly: python is required by python-devel pygobject2-devel is required by pygtk2-devel OK - MUST: The spec file handles locales properly with the %find_lang macro. N/A - MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. N/A - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. OK - MUST: The package owns all directories that it creates. OK - MUST: The package does not contain any duplicate files in the %files listing. OK - MUST: Permissions on files are set properly. Every %files section includes a %defattr(...) line. OK - MUST: The package has a %clean section, which contains ( or $RPM_BUILD_ROOT ). OK - MUST: The package consistently uses macros, as described in the macros section of Packaging Guidelines. OK - MUST: The package contains code. N/A - MUST: Large documentation files should go in a -doc subpackage. OK - MUST: Files included as %doc do not affect the runtime of the application. N/A - MUST: Header files must be in a -devel package. N/A - MUST: Static libraries must be in a -static package. N/A - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. N/A - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} OK - MUST: The package does not contain any .la libtool archives. FIX - MUST: The package contains a GUI application and includes a %{name}.desktop file, but that file is not properly installed with desktop-file-install in the %install section. See https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files FIX - MUST: The package does not own files or directories already owned by other packages, but you need to wait until bug # 479921 is fixed and add "%define epimajor 2.24", "Requires: epiphany(abi) = %{epimajor}" and "BuildRequires: epiphany-devel >= %{epimajor}" to the extension package again. BTW: Instead of %{_libdir}/epiphany/*/extensions/gget* I suggest %{_libdir}/epiphany/*/extensions/gget.py* to make sure you don't package unwanted files, but shouldn't really matter. OK - MUST: At the beginning of %install, the package runs $RPM_BUILD_ROOT. OK - MUST: All filenames in rpm packages are valid UTF-8. N/A - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. N/A - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. OK - SHOULD: The the package builds in mock. OK - SHOULD: The package should compile and build into binary rpms on all supported architectures. OK - SHOULD: The package basically functions as described, but tends to crash if the downloads.xml is malformed. Traceback mailed to upstream with Ant cc'ed. OK - SHOULD: Scriptlets are sane, but remember the mimeinfo stuff N/A - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. N/A - SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. N/A - SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. Other issues: - Changelog is incomplete, there is a gap between 0.0.4-1 and 0.0.4-5. Please fix it up with the specs from the pastebin. - ChangeLog from source needs to be included in %doc - "chmod +x ..." of the py files during install is not needed, remove it. - There are some issues with the desktop file: - Categories includes "Application" which is no longer valid in latest freedesktop.org specs. Use "--remove-category="Application" in desktop-file-install - the desktop file contains a mimetype, so you have to run update-mime-database, see https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#mimeinfo - Add "Requires: dbus" because dbus-python and notify-python will only pull in dbus-libs automatically - Timestamp of Source0 does not match. Please download it again with wget or alike, see https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps Suggestions: - Summary of the epiphany extension could be improved a little: "GGet extension for the Epiphany web browser" - lowercase some words in the descriptions: download manager, package. Only names (such as Gnome or GGet) should be upper case.
(In reply to comment #23) > Although we are still waiting for the epipahny bug to be fixed, here is a > preliminary review: > > FIX - MUST: The package does not own files or directories already owned by > other packages, but you need to wait until bug # 479921 is fixed and add > "%define epimajor 2.24", "Requires: epiphany(abi) = %{epimajor}" and > "BuildRequires: epiphany-devel >= %{epimajor}" to the extension package again. Changed everything besides this, waiting until bug # 479921 is fixed. > BTW: Instead of > %{_libdir}/epiphany/*/extensions/gget* > I suggest > %{_libdir}/epiphany/*/extensions/gget.py* > to make sure you don't package unwanted files, but shouldn't really matter. That leads to: Processing files: gget-epiphany-extension-0.0.4-6.fc10 error: File not found by glob: /home/tuxdistro/rpmbuild/BUILDROOT/gget-0.0.4-6.fc10.i386/usr/lib/epiphany/*/extensions/gget.py* RPM build errors: File not found by glob: /home/tuxdistro/rpmbuild/BUILDROOT/gget-0.0.4-6.fc10.i386/usr/lib/epiphany/*/extensions/gget.py* Instead, using what you said in comment #9: %{_libdir}/epiphany/*/ Spec URL: http://pastebin.ca/1308934 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-6.fc10.src.rpm
(In reply to comment #24) > error: File not found by glob: > /home/tuxdistro/rpmbuild/BUILDROOT/gget-0.0.4-6.fc10.i386/usr/lib/epiphany/*/extensions/gget.py* Sorry, the files are named gget-epiphany.py* and gget.ephy-extension. So you could use %{_libdir}/epiphany/*/extensions/gget-epiphany.py* %{_libdir}/epiphany/*/extensions/gget.ephy-extension or simply %{_libdir}/epiphany/*/extensions/gget* as you did before. > RPM build errors: > File not found by glob: > /home/tuxdistro/rpmbuild/BUILDROOT/gget-0.0.4-6.fc10.i386/usr/lib/epiphany/*/extensions/gget.py* > > Instead, using what you said in comment #9: > %{_libdir}/epiphany/*/ This would be ok if we did what I suggested first and did _not_ file the bug against epiphany, but now it's no longer ok. > Spec URL: http://pastebin.ca/1308934 > SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-6.fc10.src.rpm Ok, I will have a final look over them tonight and if everything is ok approve them. Leave the files as they are now and do the final fixes in the -7 release.
(In reply to comment #25) > (In reply to comment #24) > > error: File not found by glob: > > /home/tuxdistro/rpmbuild/BUILDROOT/gget-0.0.4-6.fc10.i386/usr/lib/epiphany/*/extensions/gget.py* > > Sorry, the files are named gget-epiphany.py* and gget.ephy-extension. > So you could use > %{_libdir}/epiphany/*/extensions/gget-epiphany.py* > %{_libdir}/epiphany/*/extensions/gget.ephy-extension > or simply > %{_libdir}/epiphany/*/extensions/gget* > as you did before. Ok. > > Spec URL: http://pastebin.ca/1308934 > > SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-6.fc10.src.rpm > > Ok, I will have a final look over them tonight and if everything is ok approve > them. Leave the files as they are now and do the final fixes in the -7 release. Alright, I'll do the -7 release after your comments.
Trying to build a package from the spec in pastebin fails due to some weird formating error I can't find. Can you please build the -7 release now?
(In reply to comment #27) > Trying to build a package from the spec in pastebin fails due to some weird > formating error I can't find. Can you please build the -7 release now? My pleasure! :) Spec URL: http://pastebin.ca/1341199 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-7.fc10.src.rpm
The package doesn't build in Rawhide: Processing files: gget-epiphany-extension-0.0.4-7.fc11 error: File not found by glob: /builddir/build/BUILDROOT/gget-0.0.4-7.fc11.i386/usr/lib/epiphany/*/extensions/gget* The epiphany extension does not get build because configure only checks for epiphany <= 2.24, but rawhide already has 2.25. So you need to patch configure/configure.ac, I will attach a patch. Issues that needed to be fixed according to comment # 23: OK - MUST: The License field in the package spec file matches the actual license. OK - MUST: The license file from the source package is included in %doc. OK - MUST: The package contains a GUI application and includes a %{name}.desktop file, and that file is properly installed with desktop-file-install in the %install section. OK - MUST: The packages do not own files or directories already owned by other packages. OK - %changelog is complete now OK - ChangeLog from source is included in %doc OK - The desktop file contains a mimetype and update-mime-database is run properly. OK - Includes "Requires: dbus" now. OK - Timestamp of Source0 is matching. $ rpmlint /var/lib/mock/fedora-rawhide-i386/result/gget-* gget.i386: W: non-conffile-in-etc /etc/gconf/schemas/gget.schemas gget.i386: E: non-executable-script /usr/lib/python2.6/site-packages/gget/metalink.py 0644 gget.i386: E: no-binary gget.src: W: mixed-use-of-spaces-and-tabs (spaces: line 68, tab: line 6) gget-epiphany-extension.i386: W: no-documentation gget-epiphany-extension.i386: E: non-executable-script /usr/lib/epiphany/2.25/extensions/gget-epiphany.py 0644 gget-epiphany-extension.i386: E: only-non-binary-in-usr-lib 3 packages and 0 specfiles checked; 4 errors, 3 warnings. Two of these need fixing: The non-executable-script error was my fault, please enable the chmod again. The mixed-use-of-spaces-and-tabs warning is only cosmetic, but I suggest you ether use spaces or tabs. Personally I prefer spaces, because tabs sometimes look weird in (cvs) diffs. Final Notes: The BR could be reworked to be more precise and more legible: BuildRequires: pygtk2-devel >= 2.10.0 BuildRequires: pygobject2-devel >= 2.12.0 BuildRequires: gnome-python2-devel >= 2.16.0 BuildRequires: gnome-python2-extras >= 2.14.2 BuildRequires: dbus-python-devel >= 0.82 BuildRequires: notify-python >= 0.1.1 BuildRequires: intltool This is what configure really checks for. The versions are not really needed for Fedora because all supported releases are up to date, but they might be helpful for people who want to rebuild the package for EPEL or other older releases. Please add "--add-category=FileTransfer" to desktop-file-install to allow nested menus (we are working on a set of submenu-packages for user who have a lot of stuff installed) The outstanding issues are only minor. Please do one more build to fix them and to apply the patch and I will approve the package.
Created attachment 332659 [details] Patch to support epiphany up to 2.26
(In reply to comment #29) > The package doesn't build in Rawhide: > > Processing files: gget-epiphany-extension-0.0.4-7.fc11 > error: > File not found by glob: > /builddir/build/BUILDROOT/gget-0.0.4-7.fc11.i386/usr/lib/epiphany/*/extensions/gget* > > The epiphany extension does not get build because configure only checks for > epiphany <= 2.24, but rawhide already has 2.25. So you need to patch > configure/configure.ac, I will attach a patch. # Detects Epiphany 2.26/2.25 for rawhide # http://bugzilla.gnome.org/show_bug.cgi?id=572602 Patch0: gget-0.0.4-epiphany.patch > Issues that needed to be fixed according to comment # 23: > OK - MUST: The License field in the package spec file matches the actual > license. > OK - MUST: The license file from the source package is included in %doc. > OK - MUST: The package contains a GUI application and includes a > %{name}.desktop file, and that file is properly installed with > desktop-file-install in the %install section. > OK - MUST: The packages do not own files or directories already owned by other > packages. > OK - %changelog is complete now > OK - ChangeLog from source is included in %doc > OK - The desktop file contains a mimetype and update-mime-database is run > properly. > OK - Includes "Requires: dbus" now. > OK - Timestamp of Source0 is matching. > > $ rpmlint /var/lib/mock/fedora-rawhide-i386/result/gget-* > gget.i386: W: non-conffile-in-etc /etc/gconf/schemas/gget.schemas > gget.i386: E: non-executable-script > /usr/lib/python2.6/site-packages/gget/metalink.py 0644 > gget.i386: E: no-binary > gget.src: W: mixed-use-of-spaces-and-tabs (spaces: line 68, tab: line 6) > gget-epiphany-extension.i386: W: no-documentation > gget-epiphany-extension.i386: E: non-executable-script > /usr/lib/epiphany/2.25/extensions/gget-epiphany.py 0644 > gget-epiphany-extension.i386: E: only-non-binary-in-usr-lib > 3 packages and 0 specfiles checked; 4 errors, 3 warnings. > > Two of these need fixing: > The non-executable-script error was my fault, please enable the chmod again. > The mixed-use-of-spaces-and-tabs warning is only cosmetic, but I suggest you > ether use spaces or tabs. Personally I prefer spaces, because tabs sometimes > look weird in (cvs) diffs. Re-added chmod, using spaces not tabs: rpmlint gget-0.0.4-8.fc10.i386.rpm gget-epiphany-extension-0.0.4-8.fc10.i386.rpm gget.i386: W: non-conffile-in-etc /etc/gconf/schemas/gget.schemas gget.i386: E: no-binary gget-epiphany-extension.i386: W: no-documentation gget-epiphany-extension.i386: E: only-non-binary-in-usr-lib 2 packages and 0 specfiles checked; 2 errors, 2 warnings. > Final Notes: > > The BR could be reworked to be more precise and more legible: > BuildRequires: pygtk2-devel >= 2.10.0 > BuildRequires: pygobject2-devel >= 2.12.0 > BuildRequires: gnome-python2-devel >= 2.16.0 > BuildRequires: gnome-python2-extras >= 2.14.2 > BuildRequires: dbus-python-devel >= 0.82 > BuildRequires: notify-python >= 0.1.1 > BuildRequires: intltool > This is what configure really checks for. The versions are not really needed > for Fedora because all supported releases are up to date, but they might be > helpful for people who want to rebuild the package for EPEL or other older > releases. Ok. > Please add "--add-category=FileTransfer" to desktop-file-install to allow > nested menus (we are working on a set of submenu-packages for user who have a > lot of stuff installed) Done. Should I ask upstream to add this as well? > The outstanding issues are only minor. Please do one more build to fix them and > to apply the patch and I will approve the package. Spec URL: http://pastebin.ca/1343199 SRPM URL: http://www.metalinker.org/mirrors/gget/gget-0.0.4-8.fc10.src.rpm
(In reply to comment #31) > > Re-added chmod, using spaces not tabs: The only chmod that is actually needed is chmod +x $RPM_BUILD_ROOT%{python_sitelib}/%{name}/metalink.py You can remove the other one after import. > > Please add "--add-category=FileTransfer" to desktop-file-install to allow > > nested menus (we are working on a set of submenu-packages for user who have a > > lot of stuff installed) > > Done. Should I ask upstream to add this as well? Yes please. It's not really important, but if it's fixed upstream you have less work. 8063441d8f95cee10efc9ee72bb429ae gget-0.0.4-8.fc10.src.rpm fixes all outstanding issues, so this package is ================================================================= APROVED by cwickert ================================================================= Ant, please get your self a FAS account, so I can sponsor you.
(In reply to comment #32) > (In reply to comment #31) > > > > Re-added chmod, using spaces not tabs: > > The only chmod that is actually needed is > chmod +x $RPM_BUILD_ROOT%{python_sitelib}/%{name}/metalink.py > > You can remove the other one after import. Ok. > > > Please add "--add-category=FileTransfer" to desktop-file-install to allow > > > nested menus (we are working on a set of submenu-packages for user who have a > > > lot of stuff installed) > > > > Done. Should I ask upstream to add this as well? > > Yes please. It's not really important, but if it's fixed upstream you have less > work. I like less work :) > 8063441d8f95cee10efc9ee72bb429ae gget-0.0.4-8.fc10.src.rpm > fixes all outstanding issues, so this package is > > ================================================================= > APROVED by cwickert > ================================================================= > > Ant, please get your self a FAS account, so I can sponsor you. YAY! My FAS account is "ant"
Ok, I sponsored you. Time for the cvs admin procedure: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
New Package CVS Request ======================= Package Name: gget Short Description: Download Manager for the GNOME desktop Owners: ant Branches: F-9 F-10 F-11 InitialCC:
cvs done.
gget-0.0.4-9.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/gget-0.0.4-9.fc9
gget-0.0.4-9.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gget-0.0.4-9.fc10
gget-0.0.4-9.fc9 has been pushed to the Fedora 9 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-newkey update gget'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2277
gget-0.0.4-9.fc10 has been pushed to the Fedora 10 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 gget'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2305
gget-0.0.4-9.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
gget-0.0.4-9.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.