FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Desktop

 
 
LinkBack Thread Tools
 
Old 11-18-2011, 05:57 PM
Graham Murray
 
Default KDE Overlay and failed downloads

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
 
Old 11-19-2011, 03:08 AM
Duncan
 
Default KDE Overlay and failed downloads

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
 
Old 11-25-2011, 03:43 AM
Duncan
 
Default KDE Overlay and failed downloads

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
 

Thread Tools




All times are GMT. The time now is 08:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org