Bugzilla Bug 200689

Live ebuild for OpenOCD. It's a JTAG tool for embedded debugging. (More at
http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger) There
is no release of openocd, only svn.

I've tried it both with and without the ftdi flag, and only on AMD64.

(Maybe this ebuild could go into http://svn.engelkotzen.net/public/live-ebuilds
?)

Please take a look at it and point me in the right direction if I've made some
obvious mistakes.

Reproducible: Always

Created an attachment (id=137277) [details]
openocd-live-0.1.ebuild

I guess dev-embedded would be the right group for this ebuild?

Created an attachment (id=137352) [details]
An ebuild of openocd - all possible devices are useflags.

(From update of attachment 137352 [details])
I wish I knew about this ebuild when I started writing mine... anyway, this is
a more complete ebuild, with useflags for all devices

Created an attachment (id=137354) [details]
Minor correction

Sorry, I had a typo and a small fix to make.

Couple of ebuild issues:
        if use presto; then
           PRESTO="$(use_enable libftdi presto_libftdi) $(use_enable ftd2xx
presto_ftd2xx)"
        fi

        if use ft2232; then
           F2232="$(use_enable libftdi ft2232_libftdi) $(use_enable ftd2xx
ft2232_ftd2xx)"
        fi
Both of these, for the case that they disabled, need else statements, that do
--disable- for the relevant drivers.

It's also tough to follow which combinations of USE flags are/not valid.
Maybe look at IUSE_EXPAND (like the ALSA_DRIVERS/VIDEO_CARDS), combined with
functions like phpconfutils_use_conflict. (Can also avoid EAPI=1 by using the
profile-based package.use).

Do I follow it right here?
if use_one_or_more_of presto ft2232; then
   use_exactly_one_of libftdi ftd2xx || die "Need to have exactly one..."
fi

Is "--enable-presto_libftdi --enable-ft2232_libftdi" valid?

Your ./bootstrap.sh should go into src_unpack.
dev-embedded/ftd2xx is not in the tree, does it only install static libraries?
If it uses shared libs, it should be in RDEPEND as well.
dev-embedded/libftdi should be in DEPEND as well if it is checked or used in
any fashion during the build.

Thanks a lot for the ebuild updates and constructive comments! 

The compile instructions
(http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD) has the
following to say about the configuration flags: 

* Using the latest D2XX drivers from FTDI and following their installation
instructions, I had to use --enable-ft2232_libftd2xx for the OpenOCD to build
properly

* If you want to access the parallel port using the PPDEV interface you have to
specify both the '--enable-parport'- AND the '--enable-parport_ppdev'-option
since the '--enable-parport_ppdev' option actually is an option to the parport
driver.

I'm not sure all the possible combinations should be available as useflags.I
have to check more exactly what combinations of flags are valid. Will look into
the IUSE_EXPAND thing too when I get back from my 4-day vacation.

Also, to use this program at all you probably need the ftdi_sio kernel module.
(http://ftdi-usb-sio.sourceforge.net) As a module is perfered, since you
usually need to load it with parameters.

(In reply to comment #6)
> I'm not sure all the possible combinations should be available as useflags.I
> have to check more exactly what combinations of flags are valid.

For those options which do not trigger external dependencies I would prefer
them to be compiled in unconditionally. Let's try and avoid deploying the big
artillery (i.e. IUSE_EXPAND) when it's not needed.

Denis.

Hello,

Thanks both for your good comments!

First, libftdi is indeed only a runtime dependency and libftd2xx (this is one
of the corrections in the reposted ebuild) is only a build time dependency.

As for the ftdi_sio kernel module, it has nothing to do with openocd and is
*not* needed for it's functioning, even with the ftdi devices enabled.

The install instructions mention nothing of any drivers besides the ftdi ones,
which leads me to believe that none are indeed needed (except maybe for presto)
To verify this I tried to build it with all options enabled, and the only I had
was with presto_libftdi, which after looking up turns out to not be supported
yet.

since no other drivers are required at build time and if any are needed at all,
they are not in portage, I think it is safe to build with all of them enabled
(except maybe ft2232 and presto) as you said, and have the user take care of
any runtime drivers needed.

As for disabling preso and ft2232, it is not really required, since all the
interfaces are disabled by default - I will add the disabling code explicitly
if I can think of an elegant way to do it (i.e. *not* using if else).

Also in principle it should be possible to compile presto with libftdi and
ft2232 with libftd2xx, but this complicated the ebuild too much, so I would
rather not deal with it - I think people who need both presto AND ft2322 are
rare enough, and people needing a different library for each is even rarer.

I will move the bootstrap to the appropriate function. Why should it be in
unpack and not compile though?

Anyway, if IUSE_EXPAND would still be relevant after I do all those changes,
I'll look it up.

Thanks,
Shwouchk.

I'm with calchan on the building it in by default, if only it doesn't greatly
incease build requirements (that's why alsa and xorg have USE_EXPAND). Since
you say it's safe to just include all of them, go for it.

Couple more bits.
1. The package name is 'openocd', not 'openocd-live'. I have numbered it 9999
in my own 

2.
> First, libftdi is indeed only a runtime dependency and libftd2xx (this is one
> of the corrections in the reposted ebuild) is only a build time dependency.
If you read the src/Makefile.am, you see libftdi is linked against at build
time, and it is a shared library (built it to check), so it DOES need to be in
both DEPEND and RDEPEND. THe same goes for ftd2xxx (libftd2xx.so.0.4.13 is the
upstream binary shared library). They need to be present at build time so their
headers are avialable and can be linked against, and they need to be present at
runtime for the dynamic link loading.

3. For ftd2xx, I'm of the mindset to just exclude it for now, and leave it for
later, since it isn't in the tree yet, and because I'm on a different arch
where it is useless being a binary package.

4. Calchan/dragonheart: do you have any of this gear? I would have loved this
package back when I was in uni, and doing this stuff, but I don't have access
to any of the gear anymore.

Created an attachment (id=137492) [details]
New version - most things are installed by default

Alright, the file I posted is pretty much a final build.

It has everything enabled by default, except for presto which is available as a
useflag and pulls in libftd2xx, ft2232 which is also a useflag which is enabled
by default (because I think most users use ft2232 devices) and pulls in either
libftd2xx or libftdi (libftd2xx by default, because it reportedly works
better).

There is also a 'libftdi' flag to build ft2232 with libftdi instead of ftd2xx,
a 'parport_giveio' tag to build with --enable-parport_giveio.

I believe Claes meant the -live to indicate that this is pulled from a
repository and not from a tarball. Anyway, after some thought, I also prefer to
not have a postfix.

Robin,
You were correct - for some reason I clearly remember not needing libftdi at
build time (with it enabled), but after a second check and trying to build it
again, I see that I was wrong.
As for ftd2xx, it's not in the tree because it's called libftd2xx (which *is*
in the tree). For that reason, I must disagree about not adding it -
furthermore, it is supposed to work better for ft2232 devices, so it is on by
default - and if your architecture doesn't support the precompiled binary, it
should be masked anyway, which would then pull libftdi.

P.S.
Who is Calchan/dragonheart?

P.S. 2
If a dev is willing to add this ebuild, I'm willing to maintain it.

Kosta.

Created an attachment (id=137521) [details]
Another fix to the useflag handling in DEPEND

Added to the sabayon overlay. Please close.

(In reply to comment #13)
> Added to the sabayon overlay. Please close.

While I always love to close a bug, this particular reason isn't a valid one.

Sorry for not getting back to you but I was away for a few weeks and I'm still
trying to catch up. I will make a few comments on your ebuild.

The first thing I have to say is that it is very well written. I was a bit wary
about adding yet another live cvs or svn ebuild to the tree but I eventually
found out that upstream does not make releases. Considering the target audience
this is a minor issue anyway. Here are a few changes I would make, though.

1 - EAPI. I'd rather not use EAPI=1 when not absolutely necessary just yet.
Also, why did you want ft2232 and presto by default and not the others?

2 - When needing kernel drivers (either built-in or modules) you need to check
for them. In your case that's PPDEV and PARPORT, see an example in
net-print/hplip. Don't you need to check for usb too ?

3 - Due to this I'd have all parport related configure options depend on a more
global parport USE flag triggering suitable checks. Same for usb if necessary.

4 - Do you really need eutils.eclass ?

5 - You do not need both DEFAULT_INTERFACES and INTERFACES variables. Only one,
and local, is enough. You could also make that whole configuration part
cleaner.

I do not have the necessary hardware to maintain this, but I'll be happy to
serve as your proxy if you want it.

Denis.

Hi,

Thanks for your response!
I thought that no one was interested in maintaining the ebuild and I added it
to another overlay, so it seemed that closing the bug was the right thing to
do...

In any case, I have to admit that I didn't look inside the ebuild in a while,
so it will take me another day or two to address your concerns properly. I will
repost a new ebuild/replies when  done.

Kosta.

(In reply to comment #15)
> Thanks for your response!
> I thought that no one was interested in maintaining the ebuild and I added it
> to another overlay, so it seemed that closing the bug was the right thing to
> do...

We're always interested, but we're lacking manpower. However your ebuild is so
close to good enough that it would be a shame to not commit it.

> In any case, I have to admit that I didn't look inside the ebuild in a while,
> so it will take me another day or two to address your concerns properly. I will
> repost a new ebuild/replies when  done.

That's OK, take your time. Do not hesitate to contact me in private in case you
have any questions.

Denis.

Created an attachment (id=147718) [details]
cleaned up

(In reply to comment #17)
> Created an attachment (id=147718) [edit] [details]
> cleaned up
> 

You did not clean up, you fucked it up (forgive me for the language).

Most of the things there had a specific reason (especially the FT2232 block)

Alright, I finally have a little time to look over the ebuild.

Here is what I see...

(In reply to comment #14)
> (In reply to comment #13)
> > Added to the sabayon overlay. Please close.
> 
> While I always love to close a bug, this particular reason isn't a valid one.
> 
> Sorry for not getting back to you but I was away for a few weeks and I'm still
> trying to catch up. I will make a few comments on your ebuild.
> 
> The first thing I have to say is that it is very well written. I was a bit wary
> about adding yet another live cvs or svn ebuild to the tree but I eventually
> found out that upstream does not make releases. Considering the target audience
> this is a minor issue anyway. Here are a few changes I would make, though.
> 
> 1 - EAPI. I'd rather not use EAPI=1 when not absolutely necessary just yet.
> Also, why did you want ft2232 and presto by default and not the others?

In this case the EAPI was necessary for the way the ebuild was written (for the
+ useflags), but not absolutely necessary to write the ebuild, so I'll remove
it. 

(From what I remember) I enabled ft2232 because afaik most people using it
today use a usb ft2232 device. I enabled presto because it doesn't require any
extra dependencies. I did not enable libftdi because although it is open
source, it does not perform as well as libftd2xx, and I guess somewhat as a
personal preference.

I don't remember exactly what parport_giveio does, but afair it causes some
nonstandard functionality in the parport driver which "regular" users do not
want. I can check exactly what functionality it is if you want.

Oh, looking over the ebuild again I remember that presto_ftd2xx and
ft2232_ftd2xx need the same (libftd2xx) dependency so essentially by enabling
both those useflags by default I meant to have a maximum of available devices
compiled in with a minimum dependencies (libftdi) and the most "standard"
behavior (-parport_giveio). What I know for certain is that next time I write
an ebuild I will comment such things to avoid confusion in the future...

I will remove the + in the useflags and the EAPI and let the users figure it
out I guess.


> 
> 2 - When needing kernel drivers (either built-in or modules) you need to check
> for them. In your case that's PPDEV and PARPORT, see an example in
> net-print/hplip. Don't you need to check for usb too ?
> 
> 3 - Due to this I'd have all parport related configure options depend on a more
> global parport USE flag triggering suitable checks. Same for usb if necessary.

AFAIK this ebuild doesn't need the kernel drivers to build - only to operate
(it builds fine with most things enabled but w/o a parport driver back here)

I thought to let the users figure out this one as it seemed somewhat obvious
(esp. since someone might want to build it while using a certain kernel with
certain drivers, but use it on another kernel), but if you feel it would be
better to check for those drivers, I will. Let me know about this...

> 
> 4 - Do you really need eutils.eclass ?

Can I issue warnings some other way?

> 
> 5 - You do not need both DEFAULT_INTERFACES and INTERFACES variables. Only one,
> and local, is enough. You could also make that whole configuration part
> cleaner.

I don't understand what you mean about local, but as for one var, done. I
really don't remember why I had two. As for the TF2232 if, it is a must have.

> 
> I do not have the necessary hardware to maintain this, but I'll be happy to
> serve as your proxy if you want it.
> 
> Denis.
> 

Created an attachment (id=147750) [details]
ebuild with relating to the last comment

Actually, now that I think about it, if you can put two useflags into one
use_enable statement, then it could work w/o an if

(In reply to comment #19)
> Alright, I finally have a little time to look over the ebuild.
> 
> Here is what I see...
> 
> (In reply to comment #14)
> > (In reply to comment #13)
> > > Added to the sabayon overlay. Please close.
> > 
> > While I always love to close a bug, this particular reason isn't a valid one.
> > 
> > Sorry for not getting back to you but I was away for a few weeks and I'm still
> > trying to catch up. I will make a few comments on your ebuild.
> > 
> > The first thing I have to say is that it is very well written. I was a bit wary
> > about adding yet another live cvs or svn ebuild to the tree but I eventually
> > found out that upstream does not make releases. Considering the target audience
> > this is a minor issue anyway. Here are a few changes I would make, though.
> > 
> > 1 - EAPI. I'd rather not use EAPI=1 when not absolutely necessary just yet.
> > Also, why did you want ft2232 and presto by default and not the others?
> 
> In this case the EAPI was necessary for the way the ebuild was written (for the
> + useflags), but not absolutely necessary to write the ebuild, so I'll remove
> it. 
> 
> (From what I remember) I enabled ft2232 because afaik most people using it
> today use a usb ft2232 device. I enabled presto because it doesn't require any
> extra dependencies. I did not enable libftdi because although it is open
> source, it does not perform as well as libftd2xx, and I guess somewhat as a
> personal preference.
> 
> I don't remember exactly what parport_giveio does, but afair it causes some
> nonstandard functionality in the parport driver which "regular" users do not
> want. I can check exactly what functionality it is if you want.
> 
> Oh, looking over the ebuild again I remember that presto_ftd2xx and
> ft2232_ftd2xx need the same (libftd2xx) dependency so essentially by enabling
> both those useflags by default I meant to have a maximum of available devices
> compiled in with a minimum dependencies (libftdi) and the most "standard"
> behavior (-parport_giveio). What I know for certain is that next time I write
> an ebuild I will comment such things to avoid confusion in the future...
> 
> I will remove the + in the useflags and the EAPI and let the users figure it
> out I guess.
> 
> 
> > 
> > 2 - When needing kernel drivers (either built-in or modules) you need to check
> > for them. In your case that's PPDEV and PARPORT, see an example in
> > net-print/hplip. Don't you need to check for usb too ?
> > 
> > 3 - Due to this I'd have all parport related configure options depend on a more
> > global parport USE flag triggering suitable checks. Same for usb if necessary.
> 
> AFAIK this ebuild doesn't need the kernel drivers to build - only to operate
> (it builds fine with most things enabled but w/o a parport driver back here)
> 
> I thought to let the users figure out this one as it seemed somewhat obvious
> (esp. since someone might want to build it while using a certain kernel with
> certain drivers, but use it on another kernel), but if you feel it would be
> better to check for those drivers, I will. Let me know about this...
> 
> > 
> > 4 - Do you really need eutils.eclass ?
> 
> Can I issue warnings some other way?
> 
> > 
> > 5 - You do not need both DEFAULT_INTERFACES and INTERFACES variables. Only one,
> > and local, is enough. You could also make that whole configuration part
> > cleaner.
> 
> I don't understand what you mean about local, but as for one var, done. I
> really don't remember why I had two. As for the TF2232 if, it is a must have.
> 
> > 
> > I do not have the necessary hardware to maintain this, but I'll be happy to
> > serve as your proxy if you want it.
> > 
> > Denis.
> > 
> 

if you cant grasp the aspects of the ebuild that were wrong based on the
version i posted, that's your problem.  ive posted a cleaned up version that
would be acceptable to the tree where as the other ones clearly are not.  if
you cant work with people, then feel free to go somewhere else.

actually, the newer one you've posted is even worse: you pass everything as one
argument to econf.

ignoring the invalid combination of USE flags was on purpose.  if you cant
handle a warning, then make it a hard failure in pkg_config.

I actually wrote a lengthy reply but it got deleted, so in short:

(In reply to comment #22)
> if you cant grasp the aspects of the ebuild that were wrong based on the
> version i posted, that's your problem.  ive posted a cleaned up version that
> would be acceptable to the tree where as the other ones clearly are not.  if
> you cant work with people, then feel free to go somewhere else.

Is what you did "working together"? I don't think so.

I adressed all the concerns given to me either in rewriting the ebuild or by
actual replies, instead of trying to attack someone's intelligence. It's quite
ironic that you accuse of such things yet yourself fail to see how your ebuild
is broken. did you actually try to build yours with various useflags enabled?
because I tried with mine.

I can't see how your ebuild would make it to the tree instead of mine if you
didn't touch 80% of the concerns which were raised, and the ones you did touch
were with a destructive Midas touch.

> 
> actually, the newer one you've posted is even worse: you pass everything as one
> argument to econf.
> 
> ignoring the invalid combination of USE flags was on purpose.  if you cant
> handle a warning, then make it a hard failure in pkg_config.

Your "cleaned up" version looks marginally better (and in your opinion only)
while breaking functionality. What invalid combination of uselags? is it not
valid for someone to not want ft2232 and presto build in because of the
dependencies? what happens to your ebuild if someone tries that?

it breaks.

> 

P.S.

Some free advice: if you do something differently from the way someone else
does it, don't assume they should automatically "see the error of their ways".
Even if there is an objective benchmark for who is "more correct", you are just
as likely to be wrong.

(In reply to comment #22)
> if you cant grasp the aspects of the ebuild that were wrong based on the
> version i posted, that's your problem.  ive posted a cleaned up version that
> would be acceptable to the tree where as the other ones clearly are not.  if
> you cant work with people, then feel free to go somewhere else.
> 
> actually, the newer one you've posted is even worse: you pass everything as one
> argument to econf.
> 
> ignoring the invalid combination of USE flags was on purpose.  if you cant
> handle a warning, then make it a hard failure in pkg_config.
> 

Created an attachment (id=147868) [details]
Correction of the quotes

SpanKY, you were right about one thing - the quotes were unnecessary.

Created an attachment (id=149642) [details]
opencd-9999.ebuild

for all your loud mouth rants and blaming, you obviously havent even tested
your own ebuilds.  both of the last two you posted are broken.

i took an obviously unacceptable ebuild an cleaned it up for you.  instead of
responding with foul language, you should have looked at the example of how to
do things properly.  there is no objectiveness here: i work in the tree every
day and know the correct conventions.  you clearly dont.

the only combination that breaks with my ebuild is the invalid one:
USE="-ft2232 libftdi".  whether this is handled for the user or not is a matter
of taste.

as for not touching "concerns raised", i merely cleaned up your last ebuild.

(In reply to comment #26)
> Created an attachment (id=149642) [edit] [details]
> opencd-9999.ebuild
> 
> for all your loud mouth rants and blaming, you obviously havent even tested
> your own ebuilds.  both of the last two you posted are broken.

Have I written anything to indicate I was being loud? Have I "blamed" anyone
(you) for something?
I didn't think so.

The former one was broken and I proceeded to test it and fix it. I installed
the latter before posting and it works perfectly. Have you done the same for
your previous upload? It doesn't really matter because it was still broken.

> 
> i took an obviously unacceptable ebuild an cleaned it up for you.  instead of
> responding with foul language, you should have looked at the example of how to
> do things properly.  there is no objectiveness here: i work in the tree every
> day and know the correct conventions.  you clearly dont.

Don't kid yourself that you did anything "for me" or that you did me a favor.
As I told Denis (and if you actually bother to look at the posts) I was in a
hurry and it quickly summed up what you did. Most people I know don't consider
"to fuck up" foul language. In any case, I didn't attack you in any way - can
you say the same?

If you intended the ebuild you uploaded to serve only as an example and not as
a real installable ebuild, you shouldn't have obsoleted mine. If you intended
it to be installed, you shouldn't have uploaded a broken ebuild. It's a shame
you haven't learned that from working in the tree every day. 

> 
> the only combination that breaks with my ebuild is the invalid one:
> USE="-ft2232 libftdi".  whether this is handled for the user or not is a matter
> of taste.

Really? then what happens to your previous ebuild if the user tries to build it
with all useflags turned off? It breaks, that's what happens (unless they
happen to have libftd2xx installed - even then, what happens is not what they
wanted to happen). 

You are obviously lying here, since it looks like you fixed that in the ebuild
you have just uploaded. Can't admit your mistakes because working in the tree
every day makes you unable to make them?

> 
> as for not touching "concerns raised", i merely cleaned up your last ebuild.
> 

We've already been through this, but you haven't cleaned it - you broke it.

I don't see why you can't work in cooperation with others - instead of taking
my last ebuild and making w/e revisions you deem necessary, you just took your
own and revised it. I had other changes and improvements in it unrelated to
this argument. Again - if you just upload something to serve as an example,
don't obsolete working ebuilds. If you intend this to go into the tree, (and
are too proud to edit something someone else wrote) then why not fix/touch all
the issues DEnise talked about?

Created an attachment (id=149666) [details]
openocd-9999.ebuild

i dont actually use openocd, so i dont really care about it, nor did i test any
of it.  i was only doing you a favor by cleaning up the ebuild and actually
making it acceptable to the tree.  in the path to merging, your ebuilds are
obsolete.  you should have fixed whatever issue you found with the ones i
posted instead of insisting on updating dead/wrong code.

pardon me if i dont accept your claims about testing when the last two are
obviously broken.  first you quoted too much, and then you removed too much. 
and then ignored the valid "WARNING:" messages that configure spat out at you. 
it makes all your claims about posting broken ebuilds quite laughable
considering you dont apparently follow your own sarcastic statements.

foul language is not tolerated in any Gentoo communication channel regardless
of how you may feel on the topic.

as for the last version "being still broken", i dont think you actually read
the ebuild.  it builds just fine with USE='-*'.

i'm not going to continually rewrite your ebuilds form scratch.  you changing
the right ebuilds to suite your needs makes sense, not vice versa.

(In reply to comment #28)
> Created an attachment (id=149666) [edit] [details]
> openocd-9999.ebuild
> 
> i dont actually use openocd, so i dont really care about it, nor did i test any
> of it.  i was only doing you a favor by cleaning up the ebuild and actually
> making it acceptable to the tree.  in the path to merging, your ebuilds are
> obsolete.  you should have fixed whatever issue you found with the ones i
> posted instead of insisting on updating dead/wrong code.
> 
> pardon me if i dont accept your claims about testing when the last two are
> obviously broken.  first you quoted too much, and then you removed too much. 
> and then ignored the valid "WARNING:" messages that configure spat out at you. 
> it makes all your claims about posting broken ebuilds quite laughable
> considering you dont apparently follow your own sarcastic statements.
> 
> foul language is not tolerated in any Gentoo communication channel regardless
> of how you may feel on the topic.
> 
> as for the last version "being still broken", i dont think you actually read
> the ebuild.  it builds just fine with USE='-*'.
> 
> i'm not going to continually rewrite your ebuilds form scratch.  you changing
> the right ebuilds to suite your needs makes sense, not vice versa.
> 

I give up.

This "discussion" is wasting too much of my time and energy. I'll fix both our
ebuilds sometime and post something which you won't complain about.

Have a great life,
Kosta.

why quit now when we're clearly such good buddies ?  the last ebuild i posted
should have every fix you posted as well as build/install properly, and afaik
you've addressed every point Denis raised which means it should be ready to
add.

(In reply to comment #30)
> why quit now when we're clearly such good buddies ?  the last ebuild i posted
> should have every fix you posted as well as build/install properly, and afaik
> you've addressed every point Denis raised which means it should be ready to
> add.
> 

Two questions about your ebuild;
What is RESTRICT="strip"?
Why do you bootstrap in src_unpack()?

since openocd installs non-native ELF binaries, we have to control the
stripping step ourselves (see prepstrip in src_install)

bootstrap is part of "source setup" or "source preparation" which means it
belongs in src_unpack, not src_compile

Created an attachment (id=150264) [details]
This removes EAPI=1 as Denis requested, and a little shuffling of lines.

This does not build atm but it looks like it's a problem with this svn revision
as it breaks on a certain file.

How can you tell that the ebuild installs non-native elf execs?

just do a tree on $D and you'll see arm ELFs and other fun stuff.  i forget
exactly.

you dont want to go shuffling the lines ... the order was already correct.

(In reply to comment #34)
> just do a tree on $D and you'll see arm ELFs and other fun stuff.  i forget
> exactly.
> 
> you dont want to go shuffling the lines ... the order was already correct.
> 

The order is still correct, I just swapped a couple of the definitions in the
beginning to make them more pleasing to my eye...

If it really bothers you, you can switch them back.

I think the ebuild is fit for production now, so hopefully when Denis returns
it will get added.

it isnt a matter of being pleasing to the eye ... one form has the same
structure as the rest of the tree, the other does not.  keeping everything
consistent makes developers' lives a lot easier.

unfortunately, since it's a live svn ebuild, it cant be in ~arch.  so ive added
to the tree minus the KEYWORDS.  cheers.

(In reply to comment #36)
> it isnt a matter of being pleasing to the eye ... one form has the same
> structure as the rest of the tree, the other does not.  keeping everything
> consistent makes developers' lives a lot easier.
> 
> unfortunately, since it's a live svn ebuild, it cant be in ~arch.  so ive added
> to the tree minus the KEYWORDS.  cheers.
> 

Fair enough. Thanks.