On Tuesday 04 November 2008 15:36:54 Jorge Peixoto de Morais Neto wrote: > >> I've found that the recent EINA library release for e17 has broken just > >> about everything. > >> > >> Gentoo's overlay system should be simple enough to modify however after > >> reading the fine manual I am no closer to understanding the appropriate > >> course of action to create eina as a dependency in the overlay (I've > >> bugged [EMAIL PROTECTED] to no avail) > > > > Mike is usually pretty quick with these things. > > "Mike"?!, What, Vapier's formal name is "Mike"?
Mike Frysinger - he's a busy man :-) He heads up the gentoo toolchain team, is a lead kernel dev on the blackfin architecture, recently was (maybe still is) on the gentoo council. And maintains an e17 overlay. Oh, he also has a regular job as well. > Back to important stuff, is the overlay in good shape (apart from > this specific problem)? For example, is it compatible with Portage's > new requirements for Manifest? Yes, it dumped digests a long time ago and has been manifest only for ages now. I've been using it for years and supplement it with extra ebuild I find on gentoo forums or write myself. This is usually modules, itaask, winlist, etc etc and I keep them in my local provate overlay. Quality was always good, mainly because the e17 team were not ripping huge chunks of code out of libs and putting them elsewhere. So the build process stayed the same, only the code changed. Remember edb, evoak, med? It was ages since that level of disruptive change went into svn. Until eina :-) I think this is being driven by raster's work on openmoko. Finally, someone is paying him to work on e17, and he's writing low-level libs to make e17 better on tiny screens. Looks like a lot pf refactoring is going on, and we all just have to wit till it settles down. > Also, why are the snapshot ebuilds so horribly outdated? Is it because > Vapier is too busy to update them or because he just thinks that e17 > is like Mplayer, a project where the developers actually take care to > keep the svn code in good shape (only committing working code)? The snapshot ebuilds are not out of date - the e17 snapshots are :-) the team keeps mumbling that "they really ought to do this more often, like once a month", then carry on doing it once a year... > My computer has some bugs*. I am trying Xfce instead of e17 to see if > the bugs were e17's fault, but the bugs continue. I wonder if I should > go back to e17 > 1) It is *very* fast and *very* lightweight (even when compared to Xfce) > 2) It is vastly configurable and does things Xfce does not (like, for > a quick example, remembering per-window configuration, fine tuning > window borders, and even making windows borderless) > but > 1) It is unreleased; users have to compile code from svn. > 2) Outputs a truckload of text to .xsession-errors. Does it mean that > the code is full of little problems that cause warnings? Xfce, in > comparison, only outputs two "assertion failed"s > 3) Does not seem to have a Trash Bin or a System tray. I care little > about these, though (and I imagine there are plugins to provide them, > but I didn't bother to search). You want a trash bin? No problem: http://www.gurumeditation.it/blog/enlightenment/trash/ > Do you think a user who expects a reasonably stable and bug-free > environment (say, a user who accepts the latest Ubuntu, instead of > demanding the stability of Debian stable) can rely on e17? No, not in the current state. It was fine till 3 months ago. Users who want that should be using one of the suse- or debian or ubuntu-derived distro that run a stable e17 as the primary wm. Those maintainers try hard to use only workable svn checkouts when building the distro. If you use e17 svn code, be prepared to act like a dev. That's what the e17 team expects, that's how they build the thing currently and that's the price we have to pay to get to use that wm. I myself got tired of eternally fiddling with e and have resorted to using kde until things settle down... -- alan dot mckinnon at gmail dot com