Description of problem: Starting gget does nothing. Version-Release number of selected component (if applicable): gget-0.0.4-14.fc15(x86_64) How reproducible: Steps to Reproduce: 1. Select gget from Gnome Shell Activities 2. 3. Actual results: Nothing Expected results: Application starts and displays a window on the desktop Additional info: Starting from a terminal using gget Gives: /usr/bin/env: python2.5: No such file or directory
Also fails on Rawhide. See also bug 523870, bug 614147, and bug 619961. These are all dupes. They should all be marked as dupes of one of them, and maybe make that one a FutureFeature, so it doesn't expire. If this program can't even be run, there's no point in continuing to package it.
Also arch-independent so Platform can be changed to "All Linux" (the other 3 bugs already have this).
On the grounds that I touched this package last, I've taken the liberty of pushing a patch for this to "master" (for F16) here: http://pkgs.fedoraproject.org/gitweb/?p=gget.git;a=commitdiff;h=0e2ea3e32cc0fad1c50e7bf3e1013517bc7b1e51 Building gget-0.0.4-15.fc16 for dist-rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3103441
*** Bug 614147 has been marked as a duplicate of this bug. ***
*** Bug 523870 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Building gget-0.0.4-15.fc16 for dist-rawhide > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3103441 This seems to be stuck in today's general buildsystem issues; see: https://fedorahosted.org/fedora-infrastructure/ticket/2800
(In reply to comment #6) > (In reply to comment #3) > > Building gget-0.0.4-15.fc16 for dist-rawhide > > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3103441 > > This seems to be stuck in today's general buildsystem issues; see: > https://fedorahosted.org/fedora-infrastructure/ticket/2800 The build system outage was resolved, and the above build successfully completed. I believe that this build fixes the bug, for Fedora 16 onwards, so I'm closing this bug out with resolution "RAWHIDE". (I don't personally used gget, so I'm not going to apply the patch to the other branches, though that ought to be fairly simple for the package maintainer; see the change mentioned in comment #3 above). Hope this is helpful Dave
Some progress, but it's still not working in Rawhide: [andre@localhost ~]$ gget Traceback (most recent call last): File "/usr/bin/gget", line 38, in <module> from gget.application import Application File "/usr/lib/python2.7/site-packages/gget/application.py", line 33, in <module> import config File "/usr/lib/python2.7/site-packages/gget/config.py", line 28, in <module> import dialogs File "/usr/lib/python2.7/site-packages/gget/dialogs.py", line 32, in <module> import download File "/usr/lib/python2.7/site-packages/gget/download.py", line 35, in <module> from notify import Notification File "/usr/lib/python2.7/site-packages/gget/notify.py", line 30, in <module> from status_icon import TrayIcon File "/usr/lib/python2.7/site-packages/gget/status_icon.py", line 22, in <module> import egg.trayicon ImportError: No module named egg.trayicon [andre@localhost ~]$
(In reply to comment #8) > Some progress, but it's still not working in Rawhide: [...snip...] > ImportError: No module named egg.trayicon Do you have gnome-python2-libegg installed? $ rpm -qf /usr/lib64/python2.7/site-packages/gtk-2.0/egg/trayicon.so gnome-python2-libegg-2.25.3-31.fc15.x86_64
I didn't, but after installing it that error goes away. However, if I run gget without arguments, it doesn't open any windows, I don't get the prompt back, and top doesn't show significant CPU usage. It's also very hard to kill - I can't Ctrl-C it, "killall gget" doesn't work, even though "ps -A | grep gget" shows a /usr/bin/gget process. I can kill it with -9, though. Running "gget --help" gives the expected output.
Someone please reopen, since it's not completely fixed (the GUI never starts). I'll start the process in https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers for Ant Bryan if he doesn't respond soon (he's not listed as being on vacation).
I filed bug 711629. If this bug is not reopened and the maintainer does not respond, I'll eventually open a new gget bug. I think it would be better to reopen this one, since the description is still fairly accurate (the gget GUI never appears).
gget-0.0.4-16.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/gget-0.0.4-16.fc15
gget-0.0.4-16.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gget-0.0.4-16.fc14
Tried the rawhide build - the behavior is almost the same as described in comment 10, except that now I can kill it with "kill <PID>", although Ctrl-C still doesn't work. If I try "gget http://kojipkgs.fedoraproject.org/packages/gget/0.0.4/16.fc16/x86_64/gget-0.0.4-16.fc16.x86_64.rpm", I get an "Unhandled exception" window that says An internal program error has occurred. Traceback (most recent call last): File "/usr/bin/gget", line 42, in <module> application.run() File "/usr/lib/python2.7/site-packages/gget/application.py", line 83, in run self.download_list.add_download(uri, self.config.default_folder) File "/usr/lib/python2.7/site-packages/gget/download_list.py", line 96, in add_download download = Download(uri, path) File "/usr/lib/python2.7/site-packages/gget/download.py", line 85, in __init__ self.file = os.path.join(path, self.file_name) File "/usr/lib64/python2.7/posixpath.py", line 68, in join elif path == '' or path.endswith('/'): AttributeError: 'NoneType' object has no attribute 'endswith' I'm not sure if I'm using it correctly - there doesn't seem to be any documentation, other than the output of "gget --help": Usage: /usr/bin/gget [OPTION]... [URI]... OPTIONS: -d, --debug enable debug messages -h, --help show this help message and exit
Behavior with F14 and F15 builds is the same. Two steps in the right direction, but still not functional.
What I see is with -15 the command line behaviour works, and -16 I get the error in #15. But with -16, I can open gget with no args, either from the .desktop or the command line, and then use it via the GUI with no issues. I can quit from the GUI, but hitting Crtl-C on the command line freezes it, and I have to Ctrl-Z and kill -9 <pid>. But. . .now I can't launch it. I'm guessing something it requires may have changed from 2.5 to 2.7, but I'm not yet sure what.
Package gget-0.0.4-16.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gget-0.0.4-16.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/gget-0.0.4-16.fc14 then log in and leave karma (feedback).
I used the fc15 package as I run f15. It looks good to me but I have not had time to test it in anger. Gget icon is now showing on the Gnome 3 'panel replacement' and the "/usr/bin/env: python2.5: No such file or directory" message is gone. Anything else would be a new bug for me,
Ok, let's see what happens.
gget-0.0.4-16.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
gget-0.0.4-16.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
In F15 with Gnome Shell, it's still not really working for me. If I start it either from the command line or the Applications icon, I see a gget notification icon in the lower right, with a black square. It doesn't work - nothing happens if I click on it. I can kill the process with "kill <PID>" after getting its PID with ps. BTW, "ps -A | grep gget" shows the process name as /usr/bin/gget - other applications seem to use the last component of the path, and you can kill them with "killall <PROCESSNAME>". This doesn't work with gget - neither "killall gget" nor "killall /usr/bin/gget" work, you have to use "kill <PID>".
I've just installed 0.0.4-16.fc15 (did not have it installed before), but running it from the console gives an Error: Could not find configuration directory in GConf Please make sure that gget.schemas was correctly installed.
After a clean F16 x86_64 install, when attempting to run gget from a terminal I get a popup window Could not find configuration directory in GConf Please make sure that gget.schemas was correctly installed. and get prompt back when closing. No other error messages.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.