Spread desktop on television - 4.6.0 problems

[Duncan]

John Woodhouse posted on Sat, 07 May 2011 11:41:17 -0700 as excerpted:

> Noticing the comments about 4.6.0 has anyone any specific info
> on problems with it? I'm running that at release 6 on kernel
> 2.6.37.6-0.5-desktop x86_64. In general terms I haven't had any problems
> at all except is one specific activity and that's the general
> kpackager.area.

>From what I've seen and read here, 4.6.0 wasn't actually that bad, which 
is why I recommended either it or 4.5.5.   The problems have been with the 
4.6.x update series, which is worrying as it is counter to the continual 
positive trend, every release minor or micro better than the previous, 
from at least 4.2.4 (the still alpha quality despite kde claims to the 
contrary pre-release release that I switched with, only because it was 
clear at that point that kde was dropping proper-stable kde3 support 
despite an earlier insistence that it would be supported as long as there 
were users, thus leaving users caught between a rock and a hard place) thru 
4.5.5 (with 4.5.4 and 4.5.5 finally reaching reasonable release quality, 
what SHOULD have been 4.0, with stable kde 3.5 supported until it reached 
that point).

I honestly didn't see any problems with 4.6.1 either, and there were few 
bad reports here either, altho the gentoo/kde devs were aware of enough 
that they considered it a regression from 4.6.0.

4.6.2 has had a number of issues, however, with two personal regressions 
from 4.6.1 for me, and enough other users reporting problems with it here 
(unlike with 4.6.1) and similar issues on kde bugzilla that it definitely 
seemed to continue the negative trend that the gentoo/kde devs mentioned 
for 4.6.1.

One of the problems I had with 4.6.2 personally was a konqueror network 
regression, related to how kongueror connected to proxies such as the 
local privoxy I run.  This /may/ have been a final settling out of much 
earlier (4.2/4.3) problems that had been fixed, as it ended up being a 
config issue -- I had to toggle the use persistent connections to the 
proxy option.  I'd have thought little of it except for two things: (1) 
the far more serious (not easily fixed by toggling config options) proxy 
related problems in earlier 4.x, and (2) the fact that I'm reasonably 
computer technology inclined and so found and toggled that option within a 
few minutes of discovering the issue, but I know *MOST* users are going to 
be rather less so, and I can only imagine the issues such a problem might 
pose for them.

The other 4.6.2 problem I had personally was FAR more serious, as it 
continues thru 4.6.3.  It's kde/plasma-workspace related, causing panels 
to relocate to incorrect locations on the desktop.  As I've experienced 
the problem, it has to do with multi-monitor support, and causes the panel 
at the top of the top monitor of my two stacked monitors, to jump down to 
slightly below the top of the /bottom/ monitor, every time I restart 
plasma-desktop, whether I only restart it, or whether I restart all of kde 
or the entire computer.  I can unlock widgets, hit that panel's cashew, 
click and drag on the screen edge button to place it back where it's 
supposed to be, and it stays there for that plasma-desktop session, but 
the next time I start a new plasma-desktop session, the panel's back in 
the wrong place again!

There's a very possibly related kde bugzilla filing on similar behavior, 
but triggered for a user with a single monitor and apparently an auto-hide 
panel, again, normally at the top of his desktop.  In that case, he has 
traced the problem down to how close to the top the focused window is.  If 
there's enough room between the focused window and the top of the monitor 
for the panel to unhide, it works normally.  If however, the focused 
window is slightly closer to the top (and there's room under it), the 
panel suddenly jumps to BELOW the window, docking to its bottom edge.  If 
the focused window is vertically maximized or close to it, so there's no 
place for the panel to fit, it'll unhide at the top again, where it's 
supposed to be, covering the top edge of the window as one might expect of 
an auto-hide panel.

Back to my bug.  I've actually gone to the sources and played with the git 
commits between 4.6.1 and 4.6.2, until I found the one triggering the 
regression.  It's all reported on the bug I filed, which BTW has screen 
shots attached if you want to see what it's supposed to look like and what 
it ends up looking like.  Since I've found the bad commit, at least until 
the code changes too drastically (probably with 4.7, I expect I'll be safe 
thru the bugfix-only 4.6 series), if the problem doesn't get fixed I now 
have a patch that I apply to fix it.  At first, I was simply replacing the 
bad library with the one from 4.6.1, which worked, but now that I know the 
commit and have a patch reversing it, that's what I'm doing now, with 
4.6.3 which as I said, otherwise still has the bug.

The other bug similarly has screen-shots demonstrating the problem.

My bug: https://bugs.kde.org/show_bug.cgi?id=271532

The possibly related bug: https://bugs.kde.org/show_bug.cgi?id=272663

4.6.3 has an even more irritating and even potentially financially 
impacting bug, if you bank or shop using konqueror.  On at least some web-
forms, when you hit submit, it DOUBLE-submits, as if you double-clicked on 
the submit button instead of single-clicking it, but you didn't!  
Apparently, this one hits everybody using 4.6.3 konqueror on sites that 
trigger the problem, including bugzilla bug changes, thus including kde's 
own bugzilla.  It apparently also hits at least some forum sites as well.  
In bugzilla and apparently on at least some forums, the server-side 
processing detects the double-post and warns about it.  In the case of 
bugzilla, it shows up as what it calls a "mid-air collision", which 
normally simply means that while you were editing the bug, someone else 
made changes to it as well.  Bugzilla then gives you the chance to 
continue the submission or cancel it and go back to the bug, where you 
could see what changed and possibly adapt your changes to that.  But here, 
the first submit goes thru, and bugzilla warns of a second one, by you, 
with the same exact changes as the first one that it accepted!  Obviously 
you'd want to cancel and go back to the bug instead of hitting submit 
again, as that'll look like you repeated your comment or attachment or 
whatever.  According to the bug I found when I went looking, as I was 
experiencing the problem myself, it's doing the same thing with at least 
some forum sites, tho I don't regularly do webforums so haven't seen that 
personally.  But what I'm *REALLY* worried about is those shopping 
websites where this bug could potentially cause the site to bill you 
twice, or the bank to pay the same amount twice, etc.  I don't KNOW that 
this is happening yet, but if it does, some people running kde 4.6.3 are 
going to be VERY unhappy!!

The status on this bug is that they've tracked it to a series of commits 
by one specific developer.  They're going to try to get him to fix the 
mess he created.  They're getting to it fast enough that the fix will 
almost certainly ship with 4.6.4 a month from now, making 4.6.3 the only 
affected version, for one month, and I expect at least some distributions 
and other kde-package suppliers will provide updated packages as soon as a 
fix is available and tested, hopefully within a week or two, so affected 
users don't have to wait the full month.

Here's that bug: https://bugs.kde.org/show_bug.cgi?id=272466

But really, the only real problems I know of that might appear with 4.6.0 
itself are related to the fact that it dumps the hal dependency that 4.5 
and previous had (hal being deprecated and on its way out, good riddance, 
I expect most users who've had to hand-modify a hal *.fdi file, will agree!
), relying on udev/udisks/upower and friends for the services hal formerly 
provided.  Being the first release using the new u* based services, 
there's bound to be bugs there, that in theory should be fixed by the 4.6 
series bugfix releases.  Only those bugfix releases seem to have more bugs 
of their own than they fix, thus making 4.5.5 (for those who are still on 
a hal-based distro or who don't mind that dependency) or 4.6.0 (for those 
on distros that are dumping hal already or who have tangled with hal 
before and can't wait to have it off their system!) very likely the 
releases to provide the best results at this time.

As for kpackage or whatever, Gentoo uses its own package system primarily 
designed for from-source build-scripts, tho it does handle binaries as 
well, and I have it configured to package the binaries when it builds the 
package in case I need to reinstall or for easy rollback or tracing a bug 
thru different versions (it came in handy for that with the bug above, 
since once I figured out the library, I could just pull the working one 
from the old version and use it, for awhile), so I use both from-source 
and binaries package functionality, here.  (And, FWIW, Gentoo even has 
three separately developed package managers to choose from, all supporting 
the same from-source-build-scripts at least, one doesn't support binary 
packages.)  So I have little use for kpackage as it doesn't support Gentoo 
packages either from-source or binary anyway, and thus have no real 
opinion or recent experience (I did play with kpackage back on Mandrake, 
2001-2004 era) in that regard.

> So what else is bad about 4.6.0.

As I said, 4.6.0 should be reasonably good, except that it might be buggy 
on some distributions due to it being the first release to use u* tools 
instead of hal.  It's the later 4.6.* releases that have been the big 
problem.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.