Graham Murray posted on Fri, 18 Nov 2011 18:57:43 +0000 as excerpted:
> It seems that almost every time a new KDE version is keyworded ~arch in
> the KDE overlay[1] that none (or at most 1 or 2) of the tarballs can be
> fetched. The tarballs must exist otherwise the maintainers would not be
> able to generate the manifests.
>
> [1] Today it is version 4.7.80
If you look at the kde upstream schedules...
bookmarkable general link:
http://techbase.kde.org/Schedules 4.8:
http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule ... You'll see this:
>>>>>
Thursday, November 17, 2011: KDE SC 4.8 Beta 1 Tagging
Trunk is frozen for beta release tagging. Only urgent fixes, such as
those fixing compilation errors, should be committed. The usual beta
rules apply as soon as the Beta tarballs have been generated.
Wednesday, November 23, 2011: KDE SC 4.8 Beta 1 Release
The beta becomes available for general consumption.
<<<<<
If you read a bit more of the schedule, as well as check the gentoo/kde
overlay's gitlog (change into the overlay dir and run git whatchanged),
what you'll find is this:
About a week before a kde version is announced to the public and tarballs
made available for public download, it's tagged and preliminary tarballs
made available to the distros for testing and creating their own builds.
In this way, on the day of the announcement, they can already link to
packages available from cooperating distros, who have been able to build
them based on the preview copies they were able to get before the public
announcement and release.
However, it's worth noting that these preview tarballs aren't always
exactly the same as the ones finally made available on public release
day. Often there's a show-stopper bug or two discovered after the pre-
release, that's fixed for the public announcement and release. It seems
that nearly ever time, at least one of the tarballs is updated in the
interim. Again, if you check the overlay commit logs, you'll see the
entries where they update the manifests accordingly. That's also why if
you try building the first day after public release, often packages based
on one tarball or another fail the manifest check -- upstream changed the
tarballs after the pre-release, and the gentoo/kde overlay hasn't caught
up yet.
What all that means in practice is that 4.8-beta1 (aka 4.7.80) hasn't yet
been publicly released. It's only available to the distro kde
maintainers. Wait until the 23rd or so (sometimes it's a day late, so
try the 24th, or even the 25th), then try updating.
Meanwhile, the gentoo/kde folks have been TRYING to keep those pre-
releases hard-masked until public release, and they've had a chance to
verify that their manifests still match those of the public release.
However, that's a work in progress, and sometimes they forget, or they
mask most of it but miss a package or two, which then try to pull in the
rest of the update when they try to upgrade, causing problems because
most of that version is still hard-masked.
What you can usually do as a workaround, is take the closest
package.(un)mask and/or package.keywords file from the kde overlay's
Documentation dir and drop it in your /etc/portage/package.mask/ dir (or
copy the list into the file, if you're still using a file instead of a
dir).
That usually fixes it, unless your other package.unmask entries are too
broad, for example >=kde-base/kdelibs-4.7 or <=kde-base/kdelibs-4.8
instead of <=kde-base/kdelibs-4.7.50, if you were previously trying to
early-unmask new 4.7 series versions, since 4.7.80 is really 4.8-beta1,
and unmasks override masks.
Also, as I said, sometimes a package slips thru the cracks and isn't
listed on the (un)mask/keywords list, in which case you'll have to add
it, to reestablish order.
Just don't forget to delete that mask-file after the public release,
assuming of course that you want to update to it as soon as you can. =:^)
--
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