Summary: | =net-im/qutim-0.3.1 fails to connect | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Fat-Zer <fatzer2> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | fatzer2, nikoli, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
LD_DEBUG="files libs" qutim
scanelf -yrR |
Description
Agostino Sarubbo
2013-04-05 08:59:12 UTC
It does not work as well in a non-hardened environment. Connecting using what? xmpp? (In reply to comment #2) > Connecting using what? xmpp? yes Interesting, I can reproduce similar errors but the libraries are there! (In reply to comment #4) > Interesting, I can reproduce similar errors but the libraries are there! I can reproduce the failure after the kde upgrade to 4.10.1. Worked before. Try exporting LD_DEBUG="files libs" before running qutim please. Created attachment 346118 [details]
LD_DEBUG="files libs" qutim
(In reply to comment #7) > Created attachment 346118 [details] > LD_DEBUG="files libs" qutim Interesting... for some reason libsimplecontactlist.so has a wrong or incomplete runpath. Can you run 'scanelf -yrR' on the plugins directory? and on qutim itself please Created attachment 346122 [details]
scanelf -yrR
(In reply to comment #9) > and on qutim itself please ET_DYN /usr/lib:/usr/lib/qt4 /usr/bin/qutim Does this problem still exist with qutim-0.3.2? bug #501808 (In reply to Nikoli from comment #12) > Does this problem still exist with qutim-0.3.2? bug #501808 I do not use this program anymore. Because of lack of people how can still reproduce it and finally bumping a new version in bug #501808 I'm gonna mark it WORKSFORME in a couple of weeks if there will be no objections. (In reply to Fat-Zer from comment #14) > Because of lack of people how can still reproduce it and finally bumping a > new version in bug #501808 I'm gonna mark it WORKSFORME in a couple of weeks > if there will be no objections. You can just mark it as RESOLVED TEST-REQUEST now. So you don't have to remember resolving that bug later. (In reply to Manuel Rüger from comment #15) > You can just mark it as RESOLVED TEST-REQUEST now. So you don't have to > remember resolving that bug later. Ok, but can you explain what's that mean? It's not described on the documentation page (https://bugs.gentoo.org/page.cgi?id=fields.html) as well as some other resolutions, am I supposed to complain (e.g. fill a bug report) about it? (In reply to Fat-Zer from comment #16) > (In reply to Manuel Rüger from comment #15) > > You can just mark it as RESOLVED TEST-REQUEST now. So you don't have to > > remember resolving that bug later. > > Ok, but can you explain what's that mean? > > It's not described on the documentation page > (https://bugs.gentoo.org/page.cgi?id=fields.html) as well as some other > resolutions, am I supposed to complain (e.g. fill a bug report) about it? This resolution means the reporter and CC'ed people who had the same problem should test again and report back if the error still exists. This solves two issues: - don't upset people by telling them it's "FIXED" or "WORKSFORME", if they might still see this error. - keep the number of open 'rotting/forgotten' bugs down. (In reply to Manuel Rüger from comment #17) > This resolution means the reporter and CC'ed people who had the same problem > should test again and report back if the error still exists. > > This solves two issues: > - don't upset people by telling them it's "FIXED" or "WORKSFORME", if they > might still see this error. > - keep the number of open 'rotting/forgotten' bugs down. should I still later put it into WORKSFORME state or just keep it as-is? |