Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
On Thu, Dec 04, 2008 at 09:08:53AM +0200, Penguin Lover Alan McKinnon squawked:
The answer is not in the ebuild, it's in the eclass. You will find it at
$PORTDIR/ecalss/enlightenment.eclass. I'll take you through the relevant bits
step by step. Lines 34 to 58 are the relevant ones, and everything afterwards
depends on the value assigned to E_STATE. I'll assume you are familiar with
bash's parameter expansion syntax (man bash, line 1135 if not)
E_STATE=release
if [[ ${PV/} != ${PV} ]] ; then
E_STATE=live
elif [[ -n ${E_SNAP_DATE} ]] ; then
E_STATE=snap
else
E_STATE=release
fi
D'oh. My earlier snip was also from the same eclass. For some reason I
just didn't look hard enough to see if those variables were defined in
the same file. Thanks!
In other words, is it hardcoded somethere in portage that all
version numbers automatically trigger that variable above to be live?
Or is there some configuration somewhere?
It's a convention. No sane coder will ever release a package with version
, that is conventionally used by devs for their development stuff in
cvs/svn/git/whatever, so vapier is just falling in line.
Not exactly what I meant. But your answer above already solve the
problem: in my opinion it is one thing to fall in line for each
package (in this case, enlightenment) separately, and a completely
different thing to just make the assumption that version numbers
will never be used (practical experience aside, of course :) ).
so you could simply emerge a specific version and as long as your keywords
were correct in portage.keywords, the right thing would happen.
Okay, so since I run a mostly ~x86 system, I can just keyword mask e17
if I don't want those packages.
I will probably just suck it up and install e17 anyway: I use DR16 on
my stable desktop, but mostly fvwm on my testing laptop. I tried DR17
a bit back on my laptop, but way back then something in the chain of
DR17-Xorg-my ATI video card doesn't like the eye candy. I'll give it
another try to see if it has miraculously gotten better. (Though I am
rather fond of my fvwm setup now; I just wish I can figure out a way
to get transparencies to play nice with some of the quirky stuff I
have in my configs.)
I recommend you do what I did - read the eclass and all the ebuilds, plus man
5 ebuild, plus a long wiki document I found on the dev section at gentoo.org
written by Ciaran McCreesh.
I've read man 5 ebuild and the HOWTO on the gentoo.org page. Haven't
seen Ciaran's wiki document yet. I think (if I have some time) I
should take your advice and just read the eclass and the ebuilds. I
read about ebuilds when I was trying to write a ebuild myself--3 days
into the effort, something still wasn't working, and someone else beat
me by putting one into sunrise. C'est la vie.
Thanks
W
PS, I'll give e17 another look. Perhaps I'll take you up on your offer
for the overlay.
--
I couldn't repair your brakes, so I made your horn louder.
Sortir en Pantoufles: up 727 days, 13:15
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
On Thursday 04 December 2008 16:50:20 Willie Wong wrote: It's a convention. No sane coder will ever release a package with version , that is conventionally used by devs for their development stuff in cvs/svn/git/whatever, so vapier is just falling in line. Not exactly what I meant. But your answer above already solve the problem: in my opinion it is one thing to fall in line for each package (in this case, enlightenment) separately, and a completely different thing to just make the assumption that version numbers will never be used (practical experience aside, of course :) ). yeah, those things that will never happen somehow always do happen. Like Y2k :-) I will probably just suck it up and install e17 anyway: I use DR16 on my stable desktop, but mostly fvwm on my testing laptop. I tried DR17 a bit back on my laptop, but way back then something in the chain of DR17-Xorg-my ATI video card doesn't like the eye candy. I'll give it another try to see if it has miraculously gotten better. (Though I am rather fond of my fvwm setup now; I just wish I can figure out a way to get transparencies to play nice with some of the quirky stuff I have in my configs.) e17 doesn't like transparency and compiz-style effects. You can get it to work with the bling module or by using a compositing manager like xcompmgr or a derivative, but I found it wasn't exactly stable on nVidia. You may have better luck with ATI. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
e17 doesn't like transparency and compiz-style effects. You can get it to work with the bling module or by using a compositing manager like xcompmgr or a derivative, but I found it wasn't exactly stable on nVidia. You may have better luck with ATI. Going offtopic, I for myself don't care about fancy eye-candy at all. I consider it futile. For example, my Xfce (with all compositing effects disabled) looks beautiful enough, and is fast, lightweight, customizable, simple and understandable. The things I miss from e17 are that e17 is even more configurable (you can configure what keyboard+mouse combination resizes a windows, for example, while on Xfce it seems hardwired to altright-click, while I would prefer to use altmiddle-click, since I often have to use GNOME and would like to use the same shortcuts), and even more lightweight (disk space, memory, speed) than Xfce. I should give e17 another try when it gets a little more stable, or when at least Vapier finds the time to update the snapshot ebuilds (which, last time I checked, were horribly outdated). Regards, Jorge Peixoto -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
I should give e17 another try when it gets a little more stable, or when at least Vapier finds the time to update the snapshot ebuilds (which, last time I checked, were horribly outdated). Regards, Jorge Peixoto Oh, great, it seems vapier updated the snapshots! Alan, would you recommend an e17 snapshot (dated 2008-09-25) to a system that is mostly stable? I love simplicity, weightlessness and speed, but I don't want too many (or severe) bugs. -- Software is like sex: it is better when it is free - Linus Torvalds
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
On Friday 05 December 2008 05:46:30 Jorge Peixoto de Morais Neto wrote: I should give e17 another try when it gets a little more stable, or when at least Vapier finds the time to update the snapshot ebuilds (which, last time I checked, were horribly outdated). Regards, Jorge Peixoto Oh, great, it seems vapier updated the snapshots! Alan, would you recommend an e17 snapshot (dated 2008-09-25) to a system that is mostly stable? I love simplicity, weightlessness and speed, but I don't want too many (or severe) bugs. The snapshots are really just cvs dumps at a point in time where the devs get relatively few bugs reports. IIRC, august/september was a quiet period with no breakages so it should be ok to try out. The only gotcha I can think of is that there's a new base EFL package called eina and the ebuilds might not include it. See what eix eina returns. If nothing, then copy one of the smaller e17 libs ebuilds into your private overlay, change the obvious places to eina and emerge it first. Then emerge e. -- alan dot mckinnon at gmail dot com
[gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
emerge --update --deep --pretend world is pulling in x11-wm/enlightenment-0.16.999.050 I currently have x11-wm/enlightenment-0.16.8.14 installed, and was given to understand that the *.999 branch is the devel branch. Looking at the ebuilds show that 0.16.8.14 has KEYWORDS=alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86 ~x86-fbsd while 0.16.999.50 has KEYWORDS= I don't have any /etc/portage/package.keywords entry. So why is 0.16.999.50 being pulled in? I am using portage 2.1.6_rc2 Thanks, W -- Support medical examiners... die strangely. Sortir en Pantoufles: up 726 days, 13:15
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
On Wed, Dec 03, 2008 at 09:37:45AM -0500, Penguin Lover Willie Wong squawked:
emerge --update --deep --pretend world is pulling in
x11-wm/enlightenment-0.16.999.050
I currently have
x11-wm/enlightenment-0.16.8.14
installed, and was given to understand that the *.999 branch is the
devel branch. Looking at the ebuilds show that 0.16.8.14 has
KEYWORDS=alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86
~x86-fbsd
while 0.16.999.50 has
KEYWORDS=
I don't have any /etc/portage/package.keywords entry.
So why is 0.16.999.50 being pulled in?
Ah... nevermind. It was not a problem with portage. 0.16.999.50 is not
even in the tree; it was added to the enlightenment overlay by
vapier. Apparently it inherits from the enlightenment eclass, which
has
snip
case ${EKEY_STATE:-${E_STATE}} in
release) KEYWORDS=alpha amd64 arm hppa ia64 mips ppc ppc64 sh sparc
x86 ~x86-fbsd;;
snap)KEYWORDS=~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh
~sparc ~x86 ~x86-fbsd;;
live)KEYWORDS=;;
esac
/snip
Can anyone tell me what this is about? I know some people on this list
use the enlightenment overlay: so why is it that the ebuilds for
0.16.999.50 and , which don't look all that different to my untrained
eye, which both inherit enlightenment, and thus both set the KEYWORDS
using that snipplet above, will behave such that the former is trying
to be installed on my system while the latter is not?
W
--
Anyone who is capable of getting themselves made President
should on no account be allowed to do the job.
- Some wisdom from The Book.
Sortir en Pantoufles: up 726 days, 13:28
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
The Builds are Live CVS Builds.
The default is to use the Snapshot builds which are getting pulled in.
-Rajat
On Wed, Dec 3, 2008 at 8:29 PM, Willie Wong [EMAIL PROTECTED] wrote:
On Wed, Dec 03, 2008 at 09:37:45AM -0500, Penguin Lover Willie Wong
squawked:
emerge --update --deep --pretend world is pulling in
x11-wm/enlightenment-0.16.999.050
I currently have
x11-wm/enlightenment-0.16.8.14
installed, and was given to understand that the *.999 branch is the
devel branch. Looking at the ebuilds show that 0.16.8.14 has
KEYWORDS=alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86
~x86-fbsd
while 0.16.999.50 has
KEYWORDS=
I don't have any /etc/portage/package.keywords entry.
So why is 0.16.999.50 being pulled in?
Ah... nevermind. It was not a problem with portage. 0.16.999.50 is not
even in the tree; it was added to the enlightenment overlay by
vapier. Apparently it inherits from the enlightenment eclass, which
has
snip
case ${EKEY_STATE:-${E_STATE}} in
release) KEYWORDS=alpha amd64 arm hppa ia64 mips ppc ppc64 sh sparc
x86 ~x86-fbsd;;
snap)KEYWORDS=~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64
~sh ~sparc ~x86 ~x86-fbsd;;
live)KEYWORDS=;;
esac
/snip
Can anyone tell me what this is about? I know some people on this list
use the enlightenment overlay: so why is it that the ebuilds for
0.16.999.50 and , which don't look all that different to my untrained
eye, which both inherit enlightenment, and thus both set the KEYWORDS
using that snipplet above, will behave such that the former is trying
to be installed on my system while the latter is not?
W
--
Anyone who is capable of getting themselves made President
should on no account be allowed to do the job.
- Some wisdom from The Book.
Sortir en Pantoufles: up 726 days, 13:28
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
On Thu, Dec 04, 2008 at 12:58:28AM +0530, Penguin Lover Rajat Vig squawked:
The Builds are Live CVS Builds.
The default is to use the Snapshot builds which are getting pulled in.
-Rajat
Okay, a better question then is: how does
case ${EKEY_STATE:-${E_STATE}} in
release) KEYWORDS=alpha amd64 arm hppa ia64 mips ppc ppc64 sh sparc
x86 ~x86-fbsd;;
snap)KEYWORDS=~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64
~sh ~sparc ~x86 ~x86-fbsd;;
live)KEYWORDS=;;
esac
know that the ebuilds should be live, and that default it should
be snap? I am completely puzzled by the ebuilds.
In other words, is it hardcoded somethere in portage that all
version numbers automatically trigger that variable above to be live?
Or is there some configuration somewhere?
Also, is this what all that fuss about EAPI is about? The
enlightenment ebuilds in the tree looks quite different from the ones
in the overlay.
Thanks,
W
--
ZM: prolly
ZM: eeb's are weird
Sortir en Pantoufles: up 726 days, 23:12
Re: [gentoo-user] emerge --update pulling in enlightenment-0.16.9999.050
On Thursday 04 December 2008 02:42:34 Willie Wong wrote:
On Thu, Dec 04, 2008 at 12:58:28AM +0530, Penguin Lover Rajat Vig squawked:
The Builds are Live CVS Builds.
The default is to use the Snapshot builds which are getting pulled in.
-Rajat
Okay, a better question then is: how does
case ${EKEY_STATE:-${E_STATE}} in
release) KEYWORDS=alpha amd64 arm hppa ia64 mips ppc ppc64 sh
sparc x86 ~x86-fbsd;;
snap)KEYWORDS=~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc
~ppc64 ~sh ~sparc ~x86 ~x86-fbsd;;
live)KEYWORDS=;;
esac
know that the ebuilds should be live, and that default it should
be snap? I am completely puzzled by the ebuilds.
The answer is not in the ebuild, it's in the eclass. You will find it at
$PORTDIR/ecalss/enlightenment.eclass. I'll take you through the relevant bits
step by step. Lines 34 to 58 are the relevant ones, and everything afterwards
depends on the value assigned to E_STATE. I'll assume you are familiar with
bash's parameter expansion syntax (man bash, line 1135 if not)
E_STATE=release
if [[ ${PV/} != ${PV} ]] ; then
E_STATE=live
elif [[ -n ${E_SNAP_DATE} ]] ; then
E_STATE=snap
else
E_STATE=release
fi
So, release is the default.
If the version number is , it's live.
If E_SNAP_DATE is defined, then it's snapshot
Otherwise, the ebuild is for a release
Later on, various other ebuild variable are defined depending on the value of
E_STATE - such things as KEYWORDS and a whole slew of things used by the svn
eclass (which does the actual checkout)
In other words, is it hardcoded somethere in portage that all
version numbers automatically trigger that variable above to be live?
Or is there some configuration somewhere?
It's a convention. No sane coder will ever release a package with version
, that is conventionally used by devs for their development stuff in
cvs/svn/git/whatever, so vapier is just falling in line.
The intention was to have version numbers work like this:
enlightenment-0.16.8a stable e16 release
enlightenment-0.16. Kim's testing code for e16
enlightenment- current cvs code for e17
so you could simply emerge a specific version and as long as your keywords
were correct in portage.keywords, the right thing would happen.
That all looks cute and dandy and all, but stuff has broken a bit lately. I
think vapier is extremely busy with other stuff and the e17 overlay took
lower priority, he took 6 weeks to reply to a one-line patch I sent him.
I recommend you do what I did - read the eclass and all the ebuilds, plus man
5 ebuild, plus a long wiki document I found on the dev section at gentoo.org
written by Ciaran McCreesh. At the end of that, I knew a whole lot more about
portage that I didn't before and it all made sense. These days I maintain my
own e17 overlay, based off Vapier's stuff. I can share it if you want.
--
alan dot mckinnon at gmail dot com
