[gentoo-desktop] KDE Overlay and failed downloads

[gentoo-desktop] KDE Overlay and failed downloads

[Graham Murray]

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

[gentoo-desktop] Re: KDE Overlay and failed downloads

[Duncan]

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

[gentoo-desktop] Re: KDE Overlay and failed downloads

[Duncan]

Duncan posted on Sat, 19 Nov 2011 04:08:27 +0000 as excerpted:

> 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...

> 4.8:  http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule
> 
> ... You'll see this:

> Wednesday, November 23, 2011: KDE SC 4.8 Beta 1 Release
> 
> The beta becomes available for general consumption.

> 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

> 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.

And... it's out!

http://dot2.kde.org/2011/11/24/kde-makes-48-beta1-available-testing

If you read the comments, the first one references kde bug #287472, but 
doesn't list what it's all about.  Kde bugzilla seems to not be working 
ATM (server error), but I was able to use some google foo and found it 
listed on the kde distro-bugs list.  Seems that bug relates to nepomuk 
issues with 4.8b1 but apparently affects akonadi and thus kmail as well.  
But if the nepomuk database is deleted and nepomuk allowed to regenerate 
it, the bug filer says it's the first nepomuk and akonadi so far to run 
without memory leaks on his system.

But after getting fed-up with akonadi and the semantic-desktop in 
general, I switched to claws mail, exterminated with prejudice any 
remnants of kdepim and akonadi on my system, and am now USE=-semantic-
desktop, so that one won't affect me.  Yay! =:^)

> 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.

In this regard, the mask-file was apparently added just a few hours after 
the initial ebuilds commit, according to the git whatchanged log for the 
overlay.  But you apparently had the bad luck to sync the overlay in the 
intervening hours.  Of course that was days ago, now, so even if you 
didn't fix it manually, it should have been fixed automatically with the 
next sync after the mask file was committed.

> 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.
> =:^)

That still applies, thus this post as an update/reminder. =:^)


As for me, I'm thinking hard whether I want to try the beta.  I really 
wish gentoo/kde would have a 4.7.9999 or 4.8.49.9999 series, which would 
be HEAD of the upstream 4.8 branch, which would get fixes to beta-1 as 
they came in, but I just synced (including layman) and I don't see that 
as an option.  There's -9999 versions for at least some things, but not 
for kdelibs, unfortunately.

Plus, I'd have thought -9999 is what will be 4.9, now, with 4.8 branched 
off at feature freeze.  But that schedule seems to suggest otherwise at 
least for the betas.  Both beta freezes are trunk, not branch.  But rc1 
says branch freeze, so it would seem that's when 4.8 is branched from 
trunk.

So it seems -9999 is what will be 4.8 up until Dec 19 or so (rc-1 tagging 
freeze, apparently they branch with rc-1 tagging, Dec 20).  But there's 
no -9999 kdelibs, and without that, the rest is a bit pointless.

Maybe I can make a kdelibs-9999 manually... or maybe I'll skip the hassle 
and just do the beta, or maybe I'll skip it entirely for now... and 
perhaps go with 4.7.49.9999, sticking with 4.7 branch.  I gotta decide 
which.

-- 
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