public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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