Re: [kde-linux] Hard Disk issues
- Date: Thu, 23 Jan 2014 20:53:51 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Hard Disk issues
James Tyrer posted on Thu, 23 Jan 2014 11:11:43 -0700 as excerpted:
> On 01/22/2014 10:29 PM, Duncan wrote:
>> James Tyrer posted on Wed, 22 Jan 2014 21:24:06 -0700 as excerpted:
>>> The fist strange issue is that KInfoCenter doesn't find my Hard Disk.
>> Can't help you with that one as I don't have kinfocenter installed in
>> "just what I'll use and what that requires" installation at all.
>> given that I follow kde-live-branch and generally have fifty-ish kde
>> package updates when I update every week or so already... doesn't make
>> inclined to add another package I don't actually need to the list, when
>> the info it would provide is available at the CLI or in other GUI
> Have you considered writing some scripts? :-) At least that was what I
> did. I found that having a script that read a text file to tell it
> what to do was the most efficient method.
I had omitted further detail as too far OT, but since you brought it up...
Actually, I'm already using a gentoo-live-ebuild-specific tool called
smart-live-rebuild (python based, so there's your script! =:^) that
checks current HEAD commit ID of the followed branch of the (generally
git) live repo behind a package, comparing it to the one stored in the
package database from the last update, and only queues that package for
rebuild if the two differ.
It works reasonably well in general -- I have installed and was
rebuilding about 250 live packages (all but four or so kde packages) at
every update previous to switching to this tool, now it's about 50
packages -- but there's a few limitations, at least currently.
The biggest such limitation for kde live packages on gentoo is the big
monolithic tarballs and combined repos that kde is gradually moving away
from, since smart-live-rebuild may be "smart" but it isn't /that/ smart,
and will rebuild every package based on a repo when the target branch
(4.12 in this case) updates. So when for instance kde-baseapps or kde-
workspace updates, it triggers a rebuild of all the (installed) packages
based on them, even if the update only really affected one of the
Of course as kde upstream splits up those large monolithics into
individual repos, an ongoing process that I guess will take a big jump
with kde-frameworks-5, this limitation should eventually cease to be a
big issue in practice.
Another limitation is that smart-live-rebuild defaults to rebuilding if
its initial update check errors out for some reason. There's an option
to change it to no-rebuild-on-update-check-error, but that can mean
missed updates. The initial update checks are normally done in parallel,
capped to N checks at once, and at first I bumped up this number,
figuring my net connection could handle it.
What I didn't consider is that since well over 90% of my live-packages
are kde, that meant multiple connections hitting kde's public repos at
once, and I guess I was triggering some presumably anti-abuse limit
there, as I was getting lots of failures to connect (and thus default
rebuilds) on the initial check, when the more reasonable actual git pull
would go thru just fine... and find nothing to update, but by then it
(which might be multiple packages due to the first limitation) was
already set to rebuild.
So I reset that to the default, I think six in parallel, which has helped
altho I do still get occasional check failures and the resulting rebuilds
I suppose at some point smart-live-rebuild will get smart enough to try
several (configurable) times if the first check errors out, at which
point don't-rebuild-on-update-check-error would be a saner setting, since
at that point, it could be presumed that if the update check failed to
connect after several tries, the actual git pull would fail as well.
However, it's not /that/ smart yet, and with a reasonably fast machine,
it's easier to just let those unnecessary but automatic rebuilds happen
than to try to worry about it or handle it manually.
Without those limitations, that 50+ packages updated every week or so,
would I'd guess be more like 20+ or 30+. But 50+ is still much better
than the 250-ish live-rebuilds I was doing before I came to know of this
tool, even if with enough smarts that could in theory be reduced to 20-
something on average! =:^)
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-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.