From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] e17 overlay bug
Date: Tue, 4 Nov 2008 17:45:51 +0200 [thread overview]
Message-ID: <200811041745.51589.alan.mckinnon@gmail.com> (raw)
In-Reply-To: <38af3d670811040536ga03bbddic628f4f6e0fa3253@mail.gmail.com>
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 vapier@gentoo.org 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
next prev parent reply other threads:[~2008-11-04 15:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 8:38 [gentoo-user] e17 overlay bug Hazen Valliant-Saunders
2008-11-04 8:54 ` Alan McKinnon
2008-11-04 13:36 ` Jorge Peixoto de Morais Neto
2008-11-04 13:42 ` Hazen Valliant-Saunders
2008-11-04 15:57 ` Alan McKinnon
2008-11-04 15:45 ` Alan McKinnon [this message]
2008-11-04 17:45 ` Jorge Peixoto de Morais Neto
2008-11-08 3:35 ` Hal Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811041745.51589.alan.mckinnon@gmail.com \
--to=alan.mckinnon@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox