[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #42 from Fedora Update System 2009-03-18 15:11:52 EDT --- 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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Fedora Update System changed: What|Removed |Added Fixed In Version|0.0.4-9.fc9 |0.0.4-9.fc10 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||0.0.4-9.fc9 Resolution||NEXTRELEASE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #41 from Fedora Update System 2009-03-18 15:01:44 EDT --- 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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #40 from Fedora Update System 2009-03-04 11:24:26 EDT --- 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #39 from Fedora Update System 2009-03-04 11:21:06 EDT --- 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #38 from Fedora Update System 2009-02-28 18:31:48 EDT --- 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #37 from Fedora Update System 2009-02-28 18:31:39 EDT --- 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Kevin Fenzi changed: What|Removed |Added Flag|fedora-cvs? |fedora-cvs+ --- Comment #36 from Kevin Fenzi 2009-02-24 15:58:22 EDT --- cvs done. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Ant Bryan changed: What|Removed |Added Flag||fedora-cvs? --- Comment #35 from Ant Bryan 2009-02-23 13:47:42 EDT --- 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: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #34 from Christoph Wickert 2009-02-20 18:00:53 EDT --- Ok, I sponsored you. Time for the cvs admin procedure: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #33 from Ant Bryan 2009-02-20 17:49:02 EDT --- (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" -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Christoph Wickert changed: What|Removed |Added Blocks|177841 | Flag|fedora-review? |fedora-review+ --- Comment #32 from Christoph Wickert 2009-02-20 17:34:08 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #31 from Ant Bryan 2009-02-20 16:30:27 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #30 from Christoph Wickert 2009-02-19 20:48:14 EDT --- Created an attachment (id=332659) --> (https://bugzilla.redhat.com/attachment.cgi?id=332659) Patch to support epiphany up to 2.26 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #29 from Christoph Wickert 2009-02-19 20:46:25 EDT --- 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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #28 from Ant Bryan 2009-02-18 12:31:14 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #27 from Christoph Wickert 2009-02-18 08:29:45 EDT --- 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? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Bug 478504 depends on bug 479921, which changed state. Bug 479921 Summary: Directory ownership problems https://bugzilla.redhat.com/show_bug.cgi?id=479921 What|Old Value |New Value Status|FAILS_QA|ON_QA Resolution||NEXTRELEASE Status|ON_QA |CLOSED --- Comment #26 from Ant Bryan 2009-01-29 23:08:15 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #25 from Christoph Wickert 2009-01-15 08:48:05 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #24 from Ant Bryan 2009-01-15 01:54:07 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #23 from Christoph Wickert 2009-01-14 22:56:58 EDT --- 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}
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #22 from Mamoru Tasaka 2009-01-14 14:06:11 EDT --- (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//extensions (and > > some other epiphany related directories if any) > > Yes, also applies to the plugins dir. Simply owning > %_libdir/epiphany//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) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #21 from Christoph Wickert 2009-01-14 10:18:13 EDT --- (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//extensions (and > some other epiphany related directories if any) Yes, also applies to the plugins dir. Simply owning %_libdir/epiphany//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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #20 from Mamoru Tasaka 2009-01-14 09:57:28 EDT --- (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//extensions (and some other epiphany related directories if any) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Christoph Wickert changed: What|Removed |Added Depends on||479921 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #19 from Ant Bryan 2009-01-12 16:48:47 EDT --- (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! -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #18 from Christoph Wickert 2009-01-12 16:45:07 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #17 from Christoph Wickert 2009-01-12 16:34:37 EDT --- (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? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #16 from Mamoru Tasaka 2009-01-12 13:27:00 EDT --- (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//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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #15 from Christoph Wickert 2009-01-12 12:16:33 EDT --- (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//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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #14 from Mamoru Tasaka 2009-01-12 08:44:29 EDT --- Also, as some packages already use %_libdir/epiphany//extensions, making every package use this directory own this directory cannot be accepted and the owner of this directory must be unified. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #13 from Mamoru Tasaka 2009-01-12 08:30:33 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #12 from Christoph Wickert 2009-01-12 05:22:39 EDT --- (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? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #11 from Mamoru Tasaka 2009-01-11 23:14:18 EDT --- (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... -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #10 from Mamoru Tasaka 2009-01-11 22:33:56 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #9 from Christoph Wickert 2009-01-11 21:14:23 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #8 from Ant Bryan 2009-01-11 03:23:45 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #7 from Christoph Wickert 2009-01-10 21:08:36 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #6 from Ant Bryan 2009-01-09 01:09:28 EDT --- (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 > 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #5 from Christoph Wickert 2009-01-08 19:17:20 EDT --- (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 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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #4 from Ant Bryan 2009-01-08 18:31:40 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #3 from Christoph Wickert 2009-01-08 16:07:30 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #2 from Ant Bryan 2009-01-08 15:34:47 EDT --- 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? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 --- Comment #1 from Mamoru Tasaka 2009-01-08 13:46:56 EDT --- 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). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Christoph Wickert changed: What|Removed |Added Status|NEW |ASSIGNED CC||fed...@christoph-wickert.de AssignedTo|nob...@fedoraproject.org|fed...@christoph-wickert.de Flag||fedora-review? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 478504] Review Request: gget - Download Manager for the GNOME desktop.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=478504 Ant Bryan changed: What|Removed |Added Blocks||177841 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review