Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 200689 - New ebuild: dev-embedded/openocd-9999 - The Open On-Chip Debugger
Summary: New ebuild: dev-embedded/openocd-9999 - The Open On-Chip Debugger
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Default Assignee for New Packages
URL:
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks:
 
Reported: 2007-11-28 21:24 UTC by Claes Mogren
Modified: 2008-04-19 22:43 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
openocd-live-0.1.ebuild (openocd-live-0.1.ebuild,1.06 KB, text/plain)
2007-11-28 21:25 UTC, Claes Mogren
Details
An ebuild of openocd - all possible devices are useflags. (openocd-svn-1.0.ebuild,2.01 KB, text/plain)
2007-11-30 00:02 UTC, Kliakhandler Kosta
Details
Minor correction (openocd-svn-1.0.ebuild,1.96 KB, text/plain)
2007-11-30 00:30 UTC, Kliakhandler Kosta
Details
New version - most things are installed by default (openocd-svn-1.0.ebuild,1.65 KB, text/plain)
2007-12-01 19:33 UTC, Kliakhandler Kosta
Details
Another fix to the useflag handling in DEPEND (openocd-9999.ebuild,1.64 KB, text/plain)
2007-12-02 02:04 UTC, Kliakhandler Kosta
Details
cleaned up (openocd-9999.ebuild,1.35 KB, text/plain)
2008-03-30 17:59 UTC, SpanKY
Details
ebuild with relating to the last comment (openocd-9999.ebuild,1.60 KB, text/plain)
2008-03-30 20:42 UTC, Kliakhandler Kosta
Details
Correction of the quotes (openocd-9999.ebuild,1.60 KB, text/plain)
2008-03-31 17:36 UTC, Kliakhandler Kosta
Details
opencd-9999.ebuild (opencd-9999.ebuild,1.38 KB, text/plain)
2008-04-14 01:00 UTC, SpanKY
Details
openocd-9999.ebuild (openocd-9999.ebuild,1.46 KB, text/plain)
2008-04-14 10:36 UTC, SpanKY
Details
This removes EAPI=1 as Denis requested, and a little shuffling of lines. (openocd-9999.ebuild,1.45 KB, text/plain)
2008-04-19 09:18 UTC, Kliakhandler Kosta
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claes Mogren 2007-11-28 21:24:31 UTC
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
Comment 1 Claes Mogren 2007-11-28 21:25:35 UTC
Created attachment 137277 [details]
openocd-live-0.1.ebuild

I guess dev-embedded would be the right group for this ebuild?
Comment 2 Kliakhandler Kosta 2007-11-30 00:02:53 UTC
Created attachment 137352 [details]
An ebuild of openocd - all possible devices are useflags.
Comment 3 Kliakhandler Kosta 2007-11-30 00:04:43 UTC
Comment on attachment 137352 [details]
An ebuild of openocd - all possible devices are useflags.

I wish I knew about this ebuild when I started writing mine... anyway, this is a more complete ebuild, with useflags for all devices
Comment 4 Kliakhandler Kosta 2007-11-30 00:30:01 UTC
Created attachment 137354 [details]
Minor correction

Sorry, I had a typo and a small fix to make.
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-11-30 00:39:32 UTC
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.
Comment 6 Claes Mogren 2007-11-30 05:43:11 UTC
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.
Comment 7 Denis Dupeyron gentoo-dev 2007-11-30 07:17:46 UTC
(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.
Comment 8 Kliakhandler Kosta 2007-11-30 11:19:15 UTC
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.
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-11-30 22:28:55 UTC
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.
Comment 10 Kliakhandler Kosta 2007-12-01 19:33:56 UTC
Created attachment 137492 [details]
New version - most things are installed by default
Comment 11 Kliakhandler Kosta 2007-12-01 23:32:47 UTC
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.
Comment 12 Kliakhandler Kosta 2007-12-02 02:04:37 UTC
Created attachment 137521 [details]
Another fix to the useflag handling in DEPEND
Comment 13 Kliakhandler Kosta 2008-03-27 00:25:47 UTC
Added to the sabayon overlay. Please close.
Comment 14 Denis Dupeyron gentoo-dev 2008-03-27 13:35:39 UTC
(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.
Comment 15 Kliakhandler Kosta 2008-03-28 17:24:57 UTC
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.
Comment 16 Denis Dupeyron gentoo-dev 2008-03-28 17:42:31 UTC
(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.
Comment 17 SpanKY gentoo-dev 2008-03-30 17:59:05 UTC
Created attachment 147718 [details]
cleaned up
Comment 18 Kliakhandler Kosta 2008-03-30 20:07:23 UTC
(In reply to comment #17)
> Created an attachment (id=147718) [edit]
> 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)
Comment 19 Kliakhandler Kosta 2008-03-30 20:39:33 UTC
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.
> 

Comment 20 Kliakhandler Kosta 2008-03-30 20:42:34 UTC
Created attachment 147750 [details]
ebuild with relating to the last comment
Comment 21 Kliakhandler Kosta 2008-03-30 20:45:15 UTC
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.
> > 
> 

Comment 22 SpanKY gentoo-dev 2008-03-31 01:45:43 UTC
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.
Comment 23 Kliakhandler Kosta 2008-03-31 08:31:55 UTC
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.

> 

Comment 24 Kliakhandler Kosta 2008-03-31 09:26:01 UTC
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.
> 

Comment 25 Kliakhandler Kosta 2008-03-31 17:36:43 UTC
Created attachment 147868 [details]
Correction of the quotes

SpanKY, you were right about one thing - the quotes were unnecessary.
Comment 26 SpanKY gentoo-dev 2008-04-14 01:00:16 UTC
Created attachment 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.
Comment 27 Kliakhandler Kosta 2008-04-14 08:09:14 UTC
(In reply to comment #26)
> Created an attachment (id=149642) [edit]
> 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?
Comment 28 SpanKY gentoo-dev 2008-04-14 10:36:54 UTC
Created attachment 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.
Comment 29 Kliakhandler Kosta 2008-04-14 10:57:01 UTC
(In reply to comment #28)
> Created an attachment (id=149666) [edit]
> 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.
Comment 30 SpanKY gentoo-dev 2008-04-15 01:47:28 UTC
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.
Comment 31 Kliakhandler Kosta 2008-04-18 23:55:14 UTC
(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()?
Comment 32 SpanKY gentoo-dev 2008-04-19 06:11:15 UTC
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
Comment 33 Kliakhandler Kosta 2008-04-19 09:18:27 UTC
Created attachment 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?
Comment 34 SpanKY gentoo-dev 2008-04-19 21:00:43 UTC
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.
Comment 35 Kliakhandler Kosta 2008-04-19 21:27:55 UTC
(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.
Comment 36 SpanKY gentoo-dev 2008-04-19 21:44:48 UTC
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.
Comment 37 Kliakhandler Kosta 2008-04-19 22:43:43 UTC
(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.