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.
