[kde-linux] Hard Disk issues

[Duncan]

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 
my
>> "just what I'll use and what that requires" installation at all.  
(Which,
>> 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 
me
>> 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 
tools.)
>>
> 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 
packages.

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

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