Created attachment 359212 [details] backtrace Description of problem: crash when browsing (see below for description) Version-Release number of selected component (if applicable): gq-1.3.4-5.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.go to Browse tab 2.switch to another window and back 3. Actual results: core dump Expected results: gq still working Additional info:
Created attachment 359213 [details] backtrace
Created attachment 359214 [details] backtrace
I believe I need help with this one, gq is a bit problematic as upstream seems dead.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 544041 has been marked as a duplicate of this bug. ***
*** Bug 554404 has been marked as a duplicate of this bug. ***
*** Bug 560115 has been marked as a duplicate of this bug. ***
*** Bug 567237 has been marked as a duplicate of this bug. ***
*** Bug 570115 has been marked as a duplicate of this bug. ***
*** Bug 578156 has been marked as a duplicate of this bug. ***
*** Bug 580221 has been marked as a duplicate of this bug. ***
*** Bug 592840 has been marked as a duplicate of this bug. ***
*** Bug 598028 has been marked as a duplicate of this bug. ***
*** Bug 598235 has been marked as a duplicate of this bug. ***
*** Bug 604693 has been marked as a duplicate of this bug. ***
*** Bug 615323 has been marked as a duplicate of this bug. ***
*** Bug 623159 has been marked as a duplicate of this bug. ***
*** Bug 626880 has been marked as a duplicate of this bug. ***
*** Bug 628389 has been marked as a duplicate of this bug. ***
*** Bug 455402 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Number of duplicates on this bug feels serious, but I am not able to test this anymore. There is no LDAP server in sight and not enough interest to test it. So, if it wasn't for the number of duplicates, I would call this CLOSED/INSUFFICIENT_DATA. Do as you think.
This bug still exist ( at least did for me on f13 I can confirm if it's still present tomorrow on F14 ) Last time I looked Sven had stopped maintaining it Terje can you confirm if upstream is dead?
I have pinged Sven several times, I think he too busy to really work on all these issues (there are several different crashes). My current plan is orphan gq and replace with something better. I have a idea about what that "something" is, stay tuned.
(In reply to comment #22) > Number of duplicates on this bug feels serious, but I am not able to test this > anymore. There is no LDAP server in sight and not enough interest to test it. > So, if it wasn't for the number of duplicates, I would call this > CLOSED/INSUFFICIENT_DATA. Do as you think. And of course, another sucky thing is that there is no other desktop LDAP client available (except of PHPLDAPAdmin which requires webserver, and an Eclipse LDAP plugin).
*** Bug 645744 has been marked as a duplicate of this bug. ***
*** Bug 635409 has been marked as a duplicate of this bug. ***
*** Bug 667875 has been marked as a duplicate of this bug. ***
*** Bug 661446 has been marked as a duplicate of this bug. ***
*** Bug 710533 has been marked as a duplicate of this bug. ***
*** Bug 714666 has been marked as a duplicate of this bug. ***
*** Bug 738432 has been marked as a duplicate of this bug. ***
*** Bug 757865 has been marked as a duplicate of this bug. ***
*** Bug 789006 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > (In reply to comment #22) > > Number of duplicates on this bug feels serious, but I am not able to test this > > anymore. There is no LDAP server in sight and not enough interest to test it. > > So, if it wasn't for the number of duplicates, I would call this > > CLOSED/INSUFFICIENT_DATA. Do as you think. > > And of course, another sucky thing is that there is no other desktop LDAP > client available (except of PHPLDAPAdmin which requires webserver, and an > Eclipse LDAP plugin). Really sad... I love gq and being obliged to setup a php-ldap thing is really annoying...
(In reply to comment #35) > (In reply to comment #25) > > (In reply to comment #22) > > > Number of duplicates on this bug feels serious, but I am not able to test this > > > anymore. There is no LDAP server in sight and not enough interest to test it. > > > So, if it wasn't for the number of duplicates, I would call this > > > CLOSED/INSUFFICIENT_DATA. Do as you think. > > > > And of course, another sucky thing is that there is no other desktop LDAP > > client available (except of PHPLDAPAdmin which requires webserver, and an > > Eclipse LDAP plugin). > > Really sad... > I love gq and being obliged to setup a php-ldap thing is really annoying... just for information: the only non-web non-java already-packaged-for-fedora ldap gui I found is luma ( http://sourceforge.net/projects/luma/ ) python based, the "browser" plugin is quite similar to gq, I did not test the other plugins (or any actual modification on the ldap server) I assume we're all gq orphans here so I would venture to say that any other gq-replacement-suggestions at this point are welcome
Hi guys, gq is in sad state that's for sure. My recommended LDAP browser these days is Apache Directory Studio: http://directory.apache.org/studio/2.0/download/download-linux.html Just unpack the tarball, change into the newly created directory on do: ./ApacheDirectoryStudio If interest is there it might turn up in Fedora repos some day...
*** Bug 804803 has been marked as a duplicate of this bug. ***
Package: gq-1.3.4-9.fc13 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. 2. 3.I don`t know
*** Bug 820756 has been marked as a duplicate of this bug. ***
*** Bug 872757 has been marked as a duplicate of this bug. ***
*** Bug 868900 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
*** Bug 965551 has been marked as a duplicate of this bug. ***
Steps to reproduce on F19: Install 389-ds, following http://youtu.be/p31-gW82TAg instructions and creating one posix user. Start gq, file->preferences, create new server connection (my server is not on localhost, I used all defaults other then host and connection names) uncheck "ask for password on first connection". Close preferences. Restart gq. Click on browse tab. Wait for a minute or two, observe several new threads (LWP) as reported if started under gdb, then click on sever name. The SIGSEGV is instantaneous. If server content expanded quickly after startup, the qg appears to read contents just fine but then get the same SIGSEGV, unrelated to what was read. Feels like a problem with threads stepping on each other somehow. Using http://pkgs.org/download/gq I found several other gq releases and tried gq-1.2.3-1.el5.rf.x86_64.rpm from rpmforge and gq-1.3.4-4-rosa.lts2012.0.x86_64.rpm from rosa desktop. Both work flawlessly.
gq-1.3.4-18.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/gq-1.3.4-18.fc19
gq-1.3.4-18.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/gq-1.3.4-18.fc20
gq-1.3.4-18.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gq-1.3.4-18.fc18
Package gq-1.3.4-18.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gq-1.3.4-18.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21651/gq-1.3.4-18.fc18 then log in and leave karma (feedback).
gq-1.3.4-19.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
gq-1.3.4-19.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
gq-1.3.4-19.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.