Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 30 May 2008 19:17:59 +0000:
> 2008/5/30 Duncan <[EMAIL PROTECTED]>: >> 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@lists.gentoo.org mailing list
