Plasma hangs, could not log in
Duncan
1i5t5.duncan at cox.net
Wed Jul 20 20:35:47 BST 2011
Anne Wilson posted on Wed, 20 Jul 2011 19:03:28 +0100 as excerpted:
> Before reading this I was under the impression that only Arch had put
> KMail2 into the main repos - but even then someone said it was tagged as
> not being mainstream - sorry, I can't remember what they call it.
> Certainly most distros have KMail2 firmly in the unstable repos, for
> testers only.
It may be that you are thinking of gentoo, not arch, because I had posted
that about Gentoo. But our testing is called ~arch, in the generic, altho
for actual users it's ~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc
~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd.
The way it works is that every arch has the stable arch keyword (ex: x86)
and the testing or ~arch keyword (ex: ~x86). Every package (not every
package version, but the package, period) starts out with no keywords or
often with only ~x86. Then as the other archs test that it works at all,
they add their ~arch keywords too. A binary-only package, like certain
proprietary codecs or games, that is known to work on only x86 (or
whatever, but x86 is the most common) gets -* ~x86, so users know not to
even try it on other archs.
Meanwhile, after a package has been in ~arch for a period, 30 days by
default, with no bugs, it's a candidate for arch-stable, (the ~ is
removed). The gentoo package maintainer, if they believe that version is
ready for stable, can then open a stabilization request bug, CCing all
the ~arch keyworded archs, asking them to test and stabilize. Then all
the individual arch project devs and ATs (arch-testers) run their tests
to see that it works with all the other stable packages, and if it does
and no other bugs are found, the package is stabilized on each arch
independently.
Once a package (any version, or at least any version within the major
version slot, kde4 is treated separately from kde3, for instance) has
been marked ~arch on a particular arch, then all new versions normally
get ~arch automatically as well, unless the package maintainer believes
there's a reason NOT to do so.
But that's quite a list of archs up there, some of which are pretty
minor, with only a single dev or two working on them, while others,
especially x86 and amd64, have a dozen or more devs and arch-testers
working on them. Some archs are considered experimental and generally do
not get arch-stable keywords at all, only ~arch, or they'll get stable
keywords only for a very limited subset of packages, the base toolchain,
bash, portage and the python it requires, the various GNU utils, little
else. Notably, experimental also means that security support isn't
guaranteed -- there isn't enough manpower to ensure that security-stables
get tested and stabilized on those archs, and Gentoo doesn't claim there
is. Others cast a wider net but not everything, and tend to be rather
behind in stabilizing. Every few years one of the minor archs gets
really behind, to the point the package maintainers are getting
frustrated because they can't pull old packages out of the tree because
it's the only stable version for that minor arch, and the arch hasn't
been able to keep up. Then there's a big debate on the gentoo-dev list,
and either the arch gets some help (if it's possible, some archs require
specialized knowledge), or it drops to experimental.
So not every package has all those arch keywords, in either stable or
~arch form. That list was pulled from gcc, since it's rather core to all
archs on a from-source distro like gentoo.
But some package versions can be moved to the tree without keywords, or
with them, but hard-masked, for testing. gcc 4.6.0 and 4.6.1 are
currently in this category. They are in the tree for those brave enough
to try them, but not all packages yet have the patches applied, even in
their ~arch versions, that are necessary to build them with gcc 4.6, so
4.6 can't be unmasked even to ~arch yet, for /any/ arch. But it's in the
tree for those who want to keyword unmask it locally, to try it. And
gentoo has a gcc-switcher mechanism that makes it easy to switch the
default gcc, which helps. However, as those (like me) who try often find
out, it's still possible to build 200+ of the kde packages, for instance,
then find one that won't build with a new gcc, but you've already built
cmake and all the others with the new gcc, so you either have to suffer
without that single package, drum up a patch from somewhere (often some
distro bugtracker or another has the patch already prepared, you just
have to apply it), or rebuild everything back to the OLD gcc again, just
because the 220th package out of 230 kde packages that you have
installed, won't build with the new gcc. THAT is why it takes so long to
get a new gcc into even ~arch on gentoo, because it get go to ~arch until
the entire ~arch keyworded tree (for whatever arch) can be built with
it. Then when it does, of course the process starts over for arch-
stable, as all those ~arch versions now have to be stabilized with their
patches supporting the new gcc, before the new gcc itself can be
stabilized.
So on gentoo, just being "in the tree" doesn't mean it's unmasked to
anyone at all, tho it /often/ means it's unmasked to at least ~arch users.
Meanwhile, the various projects like gentoo/kde have their own overlays
as well. This is where ebuilds that may well still be broken are kept,
and often, as with kde, the ebuilds for the pre-release versions, like
the 4.6.95 (aka 4.7-rc2) that I'm running, as well as the "live-vcs-
build" versions, normally signaled on gentoo with a variant on the 9999
version string (so 4.6.49.9999 denotes upstream 4.6 branch, except that's
removed now as there's no more 4.6 releases scheduled, 4.7.49.9999
denotes the 4.7 branch, and 9999 denotes trunk/master/HEAD, the
4.x.49.9999 being chosen so it's lower than the 4.x.50 first upstream
alpha that will eventually become 4.y).
As for current kdepim, including kmail, akregator, etc. 4.4.11.1 is
arch-stable (for amd64 ppc x86, also ~ppc64, but they don't have a stable
kde on gentoo at all) and 4.6.1 is ~arch for amd64 x86, and for the
prefix-builds (portage running as a guest on something other than gentoo)
for ~amd64-linux and ~x86-linux.
--
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.
More information about the kde
mailing list