[gentoo-user] e17 overlay bug

[gentoo-user] e17 overlay bug

[Hazen Valliant-Saunders]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

Good Day;

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)

is there a manuel outlineing the overlay for e17? (it's rather large and
convoluted).

Regards,
-- 
Hazen Valliant-Saunders
IT/IS Consultant
(613) 355-5977

[-- Attachment #2: Type: text/html, Size: 608 bytes --]

Re: [gentoo-user] e17 overlay bug

[Alan McKinnon]

On Tuesday 04 November 2008 10:38:48 Hazen Valliant-Saunders wrote:
> Good Day;
>
> 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. This time he's taking his 
time, which means:

he's busy, or
it's tricky, or
both, or
he's fed up with it (this is unlikely)

So, you now get to do it yourself. Copy Mike's overlay files to your personal 
overlay area, open the relevant ebuilds for low-level libs, and add eina to 
the DEPEND clauses. Rebuild. Make sure your overlay takes precedence over all 
others.

> is there a manuel outlineing the overlay for e17? (it's rather large and
> convoluted).

Nope, the manual is the code. It's largely self-documenting and the only 
tricky bit is the enlightenment eclass, which covers svn, snapshots and 
releases for both cvs and svn. The ebuilds themselves are simplicity in the 
extreme where you just specify the svn module and the eclass does all the 
heavy lifting.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] e17 overlay bug

[Jorge Peixoto de Morais Neto]

>> 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"?

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?

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)?

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).

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?

*Regarding my bugs, they are mostly X-related. When I have time I will
dive in xorg.conf documentation. Also, maybe they are related to the
fact that some of my X-related packages may have been built with
different USE flags (I have disabled the IPv6 USE flag at some point).
I will recompile them all, either when Gentoo updates Xorg (which, by
the way, is taking a long time) or when Gentoo updates GCC (which is
also taking a very long time. I hope that when Debian Stable is
released with GCC 4.3, it will motivate Gentoo to declare GCC 4.3.2
stable).

--
Software is like sex: it is better when it is free - Linus Torvalds

Re: [gentoo-user] e17 overlay bug

[Hazen Valliant-Saunders]

[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

Good Day all;

Sorry to sound like a luddite;

Where would I create my own user overlay? (so I may go about fiddling with
the settings?)

Regards,
Hazen.

On Tue, Nov 4, 2008 at 8:36 AM, Jorge Peixoto de Morais Neto <
please.no.spam.here@gmail.com> 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"?
>
> 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?
>
> 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)?
>
> 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).
>
> 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?
>
> *Regarding my bugs, they are mostly X-related. When I have time I will
> dive in xorg.conf documentation. Also, maybe they are related to the
> fact that some of my X-related packages may have been built with
> different USE flags (I have disabled the IPv6 USE flag at some point).
> I will recompile them all, either when Gentoo updates Xorg (which, by
> the way, is taking a long time) or when Gentoo updates GCC (which is
> also taking a very long time. I hope that when Debian Stable is
> released with GCC 4.3, it will motivate Gentoo to declare GCC 4.3.2
> stable).
>
> --
> Software is like sex: it is better when it is free - Linus Torvalds
>
>


-- 
Hazen Valliant-Saunders
IT/IS Consultant
(613) 355-5977

[-- Attachment #2: Type: text/html, Size: 3617 bytes --]

Re: [gentoo-user] e17 overlay bug

[Alan McKinnon]

On Tuesday 04 November 2008 15:42:21 Hazen Valliant-Saunders wrote:
> Good Day all;
>
> Sorry to sound like a luddite;
>
> Where would I create my own user overlay? (so I may go about fiddling with
> the settings?)

It's in the handbook somewhere :-) But I can't be bothered finding it, so I'll 
type it.

All it really is, is a directory somewhere and you tell portage where it is. 
In that directory you have a sub-directory structure that looks the same as 
the portage tree, but with just the categories you have ebuilds for.

I have my portage tree at /var/portage (yes, I'm a stickler for detail and the 
tree is a database so it should not go into /usr/ per LFS and in case I 
mount /usr/ read-only....). The normal place for overlays is 
thus /var/portage/local:

$ ls -l /var/portage/local/
total 3
drwxrwsr-x 15 root portage 1024 Oct 28 10:31 alan
drwxr-sr-x  8 alan portage 1024 Sep 25 10:28 e17
drwxrwsr-x  5 root portage 1024 Oct 12 18:27 layman

Ignore layman, that's a gentoo tool to make it easy to use gentoo dev's own 
overlays that they publish. My private overlays are alan and e17. Inside alan 
I have:

$ ls -l /var/portage/local/alan/
total 23
-rw-rw-r--   1 root portage 1161 Jun  6 17:51 TODO
drwxr-sr-x   3 root portage 1024 Oct 28 10:31 app-doc
drwxrwsr-x   3 root portage 1024 Jun  4 10:49 app-misc
drwxrwsr-x   2 root portage 1024 Mar 16  2008 app-text
drwxrwsr-x   3 root portage 1024 Jan  3  2008 dev-util
drwxrwsr-x   2 root portage 1024 Aug 29 14:58 eclass
-rw-rw-r--   1 alan portage    0 Feb 27  2008 manifest1_obsolete
drwxr-sr-x   4 root portage 1024 Sep 15 16:36 net-libs
drwxrwsr-x   3 root portage 1024 May  3  2008 net-mail
drwxr-sr-x   5 root portage 1024 Sep 15 21:16 net-misc
drwxrwsr-x   2 root portage 1024 Jun 26 13:13 profiles
drwxrwsr-x   2 alan portage 1024 Sep  9 14:24 x11-libs
drwxrwsr-x   3 alan portage 1024 Apr 27  2008 x11-misc
drwxrwsr-x   8 root portage 1024 Sep 15 16:37 x11-plugins
drwxrwsr-x 146 root portage 9216 Nov  2 18:38 x11-themes

It looks just like a piece of a portage tree. Tell portage where the overlay 
is with an edit to make.conf:

$ grep -i overlay /etc/make.conf
PORTDIR_OVERLAY="$PORTDIR_OVERLAY /var/portage/local/e17 /var/portage/local/alan"

and you are all set. Put ebuilds in the obvious place in the directory. The 
only extra step before you can use them is to build a manifest for each 
package with an ebuild:

ebuild /path/to/your/ebuild/<package>-<version>.ebuild manifest

Do this once per package (it manifests all files in the directory, not just 
that one ebuild) and emerge.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] e17 overlay bug

[Alan McKinnon]

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

Re: [gentoo-user] e17 overlay bug

[Jorge Peixoto de Morais Neto]

> 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 boy. I would donate money to him if I wasn't a poor student and if
the dollar wasn't so overvalued related to my national currency ($1
was R$1,58 some months ago, but is now R$2,10). By the way, people
like him should keep an easy way of receiving anonymous donations. I
plan on donating a little money to free software in the future. I
think I will donate to national projects, because they are probably
more starved than projects in the US, the land where  hammers are made
of gold.

>> Also, why are the snapshot ebuilds so horribly outdated?
> The snapshot ebuilds are not out of date - the e17 snapshots are :-)
It seems (see http://download.enlightenment.org/snapshots/LATEST/)
that the latest e17 snapshots are from 2008-09-24. However, last time
I checked the e17 overlay (and I can't easily check it now because I
am at work), the snapshot ebuilds were a year old or something.

> 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.
Well, I guess I will stick with Xfce for a while then. After all, it
takes something like two more seconds to load (I measured it some time
ago, but forgot the results) than e17 on my Athlon XP 2600+, and
that's bearable. Also, while I miss e17 power*, the loss of it is also
bearable

> I myself got tired of eternally fiddling with e and have resorted to using kde
> until things settle down...
KDE?! To go from e17 to KDE is a bit extreme; like "this micro-compact
does not fulfill my transportation needs, so I will buy an SUV". Why
don't you use Xfce? It is small, fast, lightweight, quite configurable
(both by GUI and by text files**), compiles very quickly and has
everything I want a DE to have. Have you not thought about it?

And going off-topic: I mentioned that Gentoo's GCC and Xorg are too
old. Do you know if there is any prediction (yes, I know predictions
can fail; I am waiting for Debian Lenny since September) for their
upgrade? Is there anywhere I can get information like this?

* A quick example of e17 power is making my TV-viewing program
borderless. Programs that are always on top should be borderless to
save screen space. Imagine if, for example, the KDE panel had a
border.

** That "programs with a GUI should also have a command-line
interface, and configuration should be accessable via both a GUI tool
and text files" should be on Software Engineering 101.

-- 
Software is like sex: it is better when it is free - Linus Torvalds

Re: [gentoo-user] e17 overlay bug

[Hal Martin]

Alan McKinnon wrote:
> 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.
>   
Wow.
>   
>> 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 :-)
>   
What's eina? I guess it's been too long since I've updated e17...
> 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/
>   
Trash? Sounds like you need to get out and use rm more.
>
>   
>> 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?
>>     
Yes, I do it everyday. E17 is my primary window manager, and I have come
to expect that for the most part, it will be rock solid. There are
occasions where it crashes on me, but I've been able to recover every
time it's done that.
>
> 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.
>   
Really, what's it like now? I haven't updated E17 in several months...
not regretting that choice now though.
I occasionally get a crash on E17, but I can always recover it without
loosing my X session.
> 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.
>   
Yes, I remember having to switch to Xfce for several weeks late last
year when E17 went to hell in a hand basket... that wasn't really fun.
> I myself got tired of eternally fiddling with e and have resorted to using kde 
> until things settle down...
>
>