Christoph Wickert wrote: > But I can and I haven't seen any instructions what I should do. I am > willing to try broken update again in order to provide more info, but I > can only provide the info I am asked for. Well, one thing worth testing is trying to figure out what part of kdepim or Akonadi causes the problem. (I wrote in the bug report that this is information which would be useful.) For example, downgrade, disable the "Kolab server" contacts source, upgrade again, does it still misbehave? If that's not it, you can try temporarily disabling other data sources. (For example, do you have akonadi-googledata installed? If so, try removing that, it helped for the other person who reported having this issue.) But obviously, all this is a PITA to test, and I cannot make any promises about its effectiveness. What's sure is that IF this works, it will help us reduce the problem space from a very huge amount of code to a merely large amount of code. Another thing which SOMETIMES helps debugging hangs (and only hangs; if you're now seeing other kinds of misbehavior, this won't be useful) is to send a SIGABRT to the process (using kill -SIGABRT) to trigger DrKonqi (or ABRT, for stuff not using DrKonqi) and get a backtrace of where it's stuck. But that doesn't work if DrKonqi isn't printing the backtraces properly (running the app in gdb can help in that case), nor if the "hang" is actually a result of getting stuck in the main event loop with nothing to do (I've seen that kind of hangs, the backtrace is useless in those cases). It's also very hard to provide debugging instructions because the symptoms you report change all the time. I'm not even sure that what you're seeing is one bug and not several different ones. >> The update was also in updates-testing for 11 days total and >> had a karma of +2, with 2 -1 comments about regressions which were both >> fixed in the version we pushed to stable, and 4 +1 comments. One of the >> +1 votes was from a proventester, so this update would have fulfilled >> even the stricter requirements for critical path packages.) It's hard to >> fix an issue we cannot reproduce. > > This means we need more testing rather than less, so your suggestion to > remove "red tape" is counterproductive. No, we don't need more testing. It's not realistically possible to test things more than we did. Considering the statistical incidence of the bug in question, we'd have needed hundreds, if not thousands, of testers to catch it. It's just not a commonly hit bug. > I don't expect you to know the code but as the maintainers I expect you > to be able to give me some debugging instructions that you would then > use to get in touch with the developers. I think the upstream developers would certainly be able to give you better instructions for debugging their code. > I haven't met them again because I only see them once a week and when I > do, I will try to get some help there. Upstream also has an IRC chan, #kontact. You've been to our IRC chan to ask for help, why haven't you tried the upstream chan? (I actually told you on IRC to try talking to upstream.) You also haven't filed an upstream bug, why? The only linked upstream bug is the one you say is a different issue. https://bugs.kde.org/ > As a matter of fact you pushed a very hairy update to a stable release and > it broke for some people It broke for 2 people (one of whom found a workaround that solved the problem for him) out of thousands of users. I'm also fairly sure it fixed dozens of times more bugs than it caused. > No, I wanted to ship the final, not the beta because I relied on my > colleagues. The fact is, the promised (kdepim 4.6) RC still isn't there, weeks after it was scheduled, let alone an actual release. Instead, we got another (very late) beta, after weeks of no updates at all. And somehow, they managed to break 4.4.10 too. I don't think we should be the ones to blame for kdepim being broken. Kevin Kofler -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
