[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560805301217q5af4d9c3rc3ea014a012fe04f@××××××××××.com, excerpted
below, on  Fri, 30 May 2008 19:17:59 +0000:

> 2008/5/30 Duncan <1i5t5.duncan@×××.net>:

>> Do the KDE-live builds require paludis?  I recall reading that they
>> were headed that way, because it could support an EAPI with needed
>> features while portage couldn't yet.  Those builds were live only and
>> were to stay in the overlay since packages in the main tree must
>> support portage.

> the kde svn overlay yes, but from what i've read there's a new overlay
> which includes the 4.0.80 version (the 4.1 beta) which is usable with
> portage. the other overlay is the real development trunk so there quite
> a huge movement in it.

OK, thanks.  I wasn't aware of the other overlay, so that's news to me.  
The split does make sense, however, given that something semi-stable will 
eventually need to find its way to the tree, and by definition, the tree 
version would need to work with portage.

> also it doesn't really make sense to use binpkg
> for a svn or git ebuild that continues to change. it would mean a real
> huge amount of hd space.

I did it for awhile and didn't find space to be anything like an issue.  
Of course, "huge" would be relative to today's even "huger" disks, which 
could be considered the reason I didn't find it an issue.

As currently auto-handled, you have a bit of a point in that binpkgs 
don't make a lot of sense in the live-vcs environment, since it's the 
same "version" changed and remerged, thus overwriting the binpkg.  With 
normal versioning that's of course not an issue, since the versions 
change, so the binpkg filenames change and are not overwritten.  Thus 
it's possible to use the previous binpkgs to rollback to previous 
versions, or for reference, to peak inside them and see how say a config 
file changed between versions.  That's exactly the sorts of things I do 
with binpkgs, and you are correct, an overwritten binpkg isn't much help 
in that regard.

However, before I decided I was a bit too early in following the KDE4 
process for my needs and thus gave it up for the time being, I had 
decided to create a script that would have gathered up all the KDE4 
tarballs and saved them off to a dated subdir somewhere so they wouldn't 
have been overwritten each time I updated.  I could have then used 
logrotate or cron to setup a scheduled thinning down of the backups 
(keeping say the three last rollback versions, then one from each week 
for a month, addressing the accumulating space issue).  That would have 
effectively given me date-versioned fallbacks, thus filling the purpose 
binpkgs normally fill for me.

The reason I wasn't doing it before is that while I had had a chance to 
get the builds merging successfully and was in general keeping up with 
that (thanks to a nicely powerful machine), until then I hadn't really 
had a good chance to actually test it operationally.  Thus, if there were 
any regressions, I'd have (1) likely not even known it, and (2) wasn't 
actually depending on anything anyway.  I realized, however, that if I 
were to find it workable and try to start using it, since it was live-SVN 
I was running, I'd need a way to revert if something broke.  (Actually, 
there /was/ some big breakage at a few points, from what I read, as they 
merged some stuff before the other stuff needed to regain the former 
functionality.  So the case for keeping rollbacks around was a very good 
one!).  Thus the scripts I intended to write, to give me binary rollback 
capabilities even in the case of live version builds that would 
ordinarily overwrite each other.

As it happened, once I had a chance to actually test it, enough 
functionality I depended on was still missing, that I scrapped the entire 
testing process... which was all good anyway, since a couple weeks later 
was when the discussion on the dev list about them now requiring paludis 
took place.

> this tree instead is the official 4.1 branch
> and should have some sort of borders in which development would stay.

Makes sense and follows the plan they were in the process of developing 
when I split, tho I didn't know about the paludis angle at that time.

>> But I guess it hasn't been a priority (sort of like proxy support in
>> KDE4, from what I read).  <shrug>  If it works for them... but it's
>> not going to work for me without it.
>>
>>
> proxy support is working very well in kde4 (i'm actually using it
> without any issues). the problem is konqueror that isn't much compatible
> with sites designed for firefox and it isn't yet able to play well with
> flash. the binpkg in paludis isn't present as far as i know.

??

The flash and etc. stuff isn't a big deal, certainly for those used to 
dealing with KDE3 konqueror where the slaveryware Adobe Flash plugin 
might have worked, but where I never /did/ get either gnash or swfdec-
mozilla working, tho they worked in IceWeasel.  

Actually, for flash (read youtube since that's about all the flash I care 
about), I used iceweasel/firefox with swfdec for awhile, but couldn't 
keep it working reliably, apparently due to dependency merge order issues 
such that it worked if things had been upgraded in the right order, but 
failed as soon as an update came to one of the several, that killed the 
order again.   Then I used iceweasel with a download plugin to download 
the *.flv and played it in kaffeine, better player environment anyway, 
but it was a hassle downloading, playing, and deleting all those files 
manually.  I scrapped swfdec and depends, tho, since I never did figure 
out what magic order they needed to be merged in to reliably work.

Just recently, I found and merged the kde-misc/youtube-servicemenu 
package.  This is what I had been looking for, as it allowed me to 
download youtube videos from konqueror, even without a working plugin to 
view them in konqueror.  It integrated with the desktop better too 
(unsurprising, being KDE), so manually dealing with all those downloaded 
and mostly played and deleted files was much easier.  I continue to 
actually play them in kaffeine, which works much better than trying to 
play them in a tiny segment of the browser window did back on iceweasel 
even when it did work.  

So, hoping/assuming the same youtube-servicemenu package will continue to 
work or they will update it and that'll work, I don't anticipate a whole 
lot of problems there.  (It shouldn't be a major problem, and even if the 
service menu mechanism is changed a bit, I expect I could do the 
necessary fixes here if needed, since it's basically just a MIME-type 
association and a couple scripts.)

However, the proxy stuff I'm now confused on, as you say it works, but 
the comments on the KDE 4.1 beta announcement on the dot say otherwise, 
several people agreed, and nobody, last I checked, corrected them saying 
it worked.

http://dot.kde.org/1211898836/

Now that I look again, there's a mention of a patch, with a comment that 
it fixes socks5 but breaks std http proxy.  So maybe it's only socks-
proxy support that was broken (apparently in 4.0 as well) and that is 
what all the complaints have been about, but std http-proxy support has 
worked.  If so, that's /some/ better than I had though.  I think the 
privoxy I use here as a personal ad-busting junk-rewriting proxy is std 
http, for instance, so it shouldn't be an issue here.  However, it's 
apparently a blocker for many, those who'd be using it on desktops 
connected thru a socks proxy at work, that they have no control over and 
no choice of direct route to the Internet, for instance.  It's still a 
pretty basic feature.

Not to sound too whiny (probably too late =8^( ), but it also appears 
that while multiple panels and panel configs are now working (that was 
the blocker for me earlier, post 4.0 on the 4.1 trunk but still early in 
it, I tried desktop applets instead but the functionality I needed just 
wasn't there, and couldn't be made to be there), panel-autohide isn't, in 
the beta.  It's apparently still on the 4.1 list, even tho feature freeze 
has hit, so maybe there's hope if it was mostly implemented and it's a 
bug they can fix to get it working again.  I don't use it a lot on my KDE 
3.5.9 desktop; at dual 1600x1200 stacked for 1600x2400, I don't need it 
as much as say 1024x768 folks would, but I do use it for a (600x300) 
popout panel containing a kpager applet.  Since IIRC KDE4 has an applet 
that can be put on the desktop for that, there's a decent chance I won't 
miss it a lot once I get a suitably customized arrangement going, but 
it'd be nice to have the option.

In any case, 4.1 appears to have fixed at least some of the 4.0 blockers, 
including the big one here, the lack of multipanel support and 
configuration, so unless there's something really stupid like that 
missing proxy support (tho it looks like it'll work for me after all), 
there's at least a decent chance I'll find it at least minimally usable, 
now, enough to remerge it and start the task of customizing it to my 
needs and switching my habits to the 4.x methodology, even if I have to 
keep parts of KDE3 around for awhile.  That's what I had intended to do 
with 4.0, but it was just too *broken*, too many now vital but missing in 
4.0 features, to make it work, even for this normally out-in-front 
bleeding edge guy who /loves/ many betas.  That's why I say 4.0 was only 
early tech-preview alpha, not even beta, because betas normally have the 
features all there or at least blocked out even if buggy, and 4.0... 
didn't!  So 4.1's the first real beta, if it even reaches that.  It might 
still be more a late tech preview alpha.  Time will tell.

-- 
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-amd64@l.g.o mailing list