Version: (using KDE KDE 3.5.1) Installed from: FreeBSD Ports Compiler: gcc version 3.4.4 [FreeBSD] 20050518 Configured with: FreeBSD/i386 system compiler OS: FreeBSD All of the following is on a Kopete 0.12 checkout from around 1st March 2006. I have two groups in my contact list, let's call them A and B. What I am trying to do is to move a Gadu-Gadu contact (that is, a metacontact with a single Gadu-Gadu subcontact) from group A to group B. This can be done by using the contextual menu or by dragging the contact to the other group. Both methods work at first - the contact moves from A to B. However, after Kopete is restarted, the contact appears in both groups. It seems that it was not correctly deleted from group A. When I try to fix this by manually deleting the contact from group A, it will disappear at first, but on the next restart of Kopete, the contact will be back. So, no matter what I do to remove the contact from group A, nothing works. The only way to get rid of the contact seems to be to delete it from *all* groups. When this is done, it seems, the Gadu-Gadu plugin actually realizes the contact should be removed from the contact list. Unfortunately, this leads to the nast effect that the contact is gone for good because adding contacts actually is broken as well... I will file another report about this in a moment. All of this is broken for Gadu-Gadu only. I can move ICQ and MSN contacts at will without any problems at all.
Just for reference, I filed bug 122997 for not being able to add Gadu-Gadu contacts to my contact list.
This keeps getting weirder... I just realized that after I have removed the contact from all groups, it doesn't actually go away. After I have restarted Kopete, the contact appears in group A (but not group B) and its display name is reset to the Gadu-Gadu nick (which is why I didn't realize the contact was back at first).
Now I noticed that this actually seems to affect ICQ and MSN as well. Contacts can be moved and deleted from groups at will, but after Kopete is restarted, they appear in both the group they were in before and the group they were moved to.
now that you mention it, I've been having this problem too... it first started when I was using kopete on two computers, with two overlapping-but-different sets of accounts. I changed something at work that I shouldn't have... and the metacontact involved at home got confused, bouncing between two groups. I eventualy calmed it down by separating out some contacts (gtalk I think) and adding them back into the metacontact... but then later the metacontact showed up in two groups, and my halfhearted attempts to get it back to normal failed - it insists on being in both groups. -- This insane ranting was brought to you by evyl bananas, and the number 3. www.chani3.com
Matt: As noted in comment #3, this is actually not specific to Gadu at all - it affects ICQ and MSN as well. Could you change the component to something more general than the Gadu plugin?
if that ain't gadu specific, please create another bug report that would not say GG in topic. That's important.
Grzegorz: Matt fixed the bug summary. No "Gadu" in there any more :).
I can't reproduce that here with Jabber or with MSN.
Chani wrote: > [...] and the metacontact involved at home got confused, > bouncing between two groups [...] I fixed this bug today. It occurred when you have several jabber contact in one metacontact And i still can't reproduce the bug as described in the original report with Jabber or MSN.
> ------- Additional Comments From ogoffart kde org 2006-03-10 22:47 ------- > Chani wrote: > > [...] and the metacontact involved at home got confused, > > bouncing between two groups [...] > > I fixed this bug today. It occurred when you have several jabber contact in one metacontact > > And i still can't reproduce the bug as described in the original report with Jabber or MSN. cool. btw, I eventually did get that contact back into one group, by deleting it from the other group. I'd avoided doing that because I was afraid hitting the 'delete' key might totally delete the metacontact instead; it'd be nice to have a 'remove from group' option in the right-click menu.
Re comment #9: I seem to be unable to reproduce this with MSN myself. I have lots of contacts with different combinations of ICQ, MSN and Gadu. I hadn't tried enough combinations to be 100% sure what works and what doesn't - sorry. Just now I tried reproducing the bug again. It happens reliably for me with Gadu. For ICQ, it looks like it sometimes happens and sometimes doesn't. For example, I have had some ICQ contacts in both of my groups for a long time because I simply couldn't delete them. Everytime I removed them from one of the groups, they would reappear on next start. Today, it suddenly worked. Since I seem to be unable to reproduce this reliably with ICQ but it happens every time with ICQ, could this please be reassigned to the Gadu plugin? I will watch closely what's going on with ICQ and if the bug reappears, I will file a new report for that. Sorry for the noise with going fore and back between general and Gadu. PS: Where would I apply for a KDE bugzilla account? I don't want to bother people with changing components in my bug reports when I could just do it myself.
I think I know why ICQ sometimes seems affected. Imagine the following scenario: I have a metacontact that contains both ICQ and Gadu subcontacts. It is present in both groups A and B. When I try to delete the metacontact from group B, the bug in Gadu that prevents deletion occurs. The effect of this is not only that the Gadu contact respawns after Kopete is next restarted - it's actually the entire metacontact that reappears. So, all the subcontacts, be it ICQ or something else, come back from the dead. But the one at fault is only Gadu. When that's fixed, the entire metacontact can hopefully be deleted.
I was wrong, I *didn't* fix the contact being in two groups. it looked like it was fixed, but came back. that metacontact has many contacts from msn, ym and gtalk... so I'm not sure which is causing trouble. don't have time to investigate right now.
I tested with kopete svn trunk r836553. 1. added a contact (12345 in that case) and put it into group A 2. rightclick on it and create a new metacontact for it 3. move metacontact 12345 into group B 4. reconnect to gadu -> metacontact 12345 is in group B, group A shows the same metacontact after gadu is online again
*** Bug 139609 has been marked as a duplicate of this bug. ***
I managed to get this, when deleting maaany contacts: Thread 4 (Thread 0x7f0f29dd1950 (LWP 25107)): #0 0x00007f0f322d4b7b in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #1 0x00007f0f322d4f4f in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f0f322d53cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f0f37dc774e in QEventDispatcherGlib::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #4 0x00007f0f37d9cc12 in QEventLoop::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #5 0x00007f0f37d9cfdd in QEventLoop::exec () from /usr/lib64/qt4/libQtCore.so.4 #6 0x00007f0f21b0c85a in QCA::SyncThread::run () from /usr/lib64/qca2/libqca.so.2 #7 0x00007f0f37cb6952 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #8 0x00007f0f37a433fa in start_thread () from /lib/libpthread.so.0 #9 0x00007f0f361bb4fd in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f0f22f5b950 (LWP 25108)): #0 0xffffffffff600167 in ?? () #1 0x00007fff43dfe5fb in ?? () #2 0x00007f0f3258059d in clock_gettime () from /lib/librt.so.1 #3 0x00007f0f37dc9205 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #4 0x00007f0f37dc9401 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #5 0x00007f0f37dc782b in ?? () from /usr/lib64/qt4/libQtCore.so.4 #6 0x00007f0f322d4832 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #7 0x00007f0f322d5119 in ?? () from /usr/lib/libglib-2.0.so.0 #8 0x00007f0f322d53cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #9 0x00007f0f37dc774e in QEventDispatcherGlib::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #10 0x00007f0f37d9cc12 in QEventLoop::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #11 0x00007f0f37d9cfdd in QEventLoop::exec () from /usr/lib64/qt4/libQtCore.so.4 #12 0x00007f0f21f66806 in ?? () from /usr/kde/live/lib64/kde4/kopete_jabber.so #13 0x00007f0f37cb6952 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #14 0x00007f0f37a433fa in start_thread () from /lib/libpthread.so.0 #15 0x00007f0f361bb4fd in clone () from /lib/libc.so.6 #16 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f0f1f778950 (LWP 25158)): #0 0x00007f0f361b3c32 in select () from /lib/libc.so.6 #1 0x00007f0f2189045a in posix_timer_do () from /usr/lib/libortp.so.5 #2 0x00007f0f21891125 in rtp_scheduler_schedule () from /usr/lib/libortp.so.5 #3 0x00007f0f37a433fa in start_thread () from /lib/libpthread.so.0 #4 0x00007f0f361bb4fd in clone () from /lib/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f0f3bbbe770 (LWP 24858)): #0 0x00007f0f3617ce51 in nanosleep () from /lib/libc.so.6 #1 0x00007f0f3617cc77 in sleep () from /lib/libc.so.6 #2 0x00007f0f38a207f9 in ?? () from /usr/kde/live/lib64/libkdeui.so.5 #3 0x00007f0f38a211aa in KCrash::defaultCrashHandler () from /usr/kde/live/lib64/libkdeui.so.5 #4 <signal handler called> #5 0x00007f0f2251dda0 in ?? () from /usr/kde/live/lib64/kde4/kopete_gadu.so #6 0x00007f0f2252681c in ?? () from /usr/kde/live/lib64/kde4/kopete_gadu.so #7 0x00007f0f225268f9 in ?? () from /usr/kde/live/lib64/kde4/kopete_gadu.so #8 0x00007f0f22528cee in ?? () from /usr/kde/live/lib64/kde4/kopete_gadu.so #9 0x00007f0f2252ead5 in ?? () from /usr/kde/live/lib64/kde4/kopete_gadu.so #10 0x00007f0f37db3bf2 in QMetaObject::activate () from /usr/lib64/qt4/libQtCore.so.4 #11 0x00007f0f37dadf33 in QObject::event () from /usr/lib64/qt4/libQtCore.so.4 #12 0x00007f0f36d8de1d in QApplicationPrivate::notify_helper () from /usr/lib64/qt4/libQtGui.so.4 #13 0x00007f0f36d95f8a in QApplication::notify () from /usr/lib64/qt4/libQtGui.so.4 #14 0x00007f0f389b663b in KApplication::notify () from /usr/kde/live/lib64/libkdeui.so.5 #15 0x00007f0f37d9e36b in QCoreApplication::notifyInternal () from /usr/lib64/qt4/libQtCore.so.4 #16 0x00007f0f37dcaf2e in ?? () from /usr/lib64/qt4/libQtCore.so.4 #17 0x00007f0f37dc77cd in ?? () from /usr/lib64/qt4/libQtCore.so.4 #18 0x00007f0f322d1ba0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #19 0x00007f0f322d5230 in ?? () from /usr/lib/libglib-2.0.so.0 #20 0x00007f0f322d53cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #21 0x00007f0f37dc772f in QEventDispatcherGlib::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #22 0x00007f0f36e2535f in ?? () from /usr/lib64/qt4/libQtGui.so.4 #23 0x00007f0f37d9cc12 in QEventLoop::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #24 0x00007f0f37d9cfdd in QEventLoop::exec () from /usr/lib64/qt4/libQtCore.so.4 #25 0x00007f0f37d9f294 in QCoreApplication::exec () from /usr/lib64/qt4/libQtCore.so.4 #26 0x000000000044b888 in _start () #0 0x00007f0f3617ce51 in nanosleep () from /lib/libc.so.6
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
I've received the following message: "Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. " This bug has been opened 15 years ago. I have commented on it 12 years ago. Don't get me wrong, but for all I care, you can just close all my bug reports if they're going to be handled like that.
Dear user, unfortunately Kopete is no longer maintained. Please migrate to another solution, e.g. for Jabber a possibility is Kaidan, for Matrix a candidate is NeoChat.