200689 2007-11-28 21:24 0000 New ebuild: dev-embedded/openocd-9999 - The Open On-Chip Debugger 2008-04-19 22:43:43 0000 1 1 1 Unclassified Gentoo Linux Development unspecified All Linux RESOLVED FIXED EBUILD P2 enhancement --- 1 cm@acc.umu.se maintainer-wanted@gentoo.org dev-embedded@gentoo.org public@kosta.tk cm@acc.umu.se 2007-11-28 21:24:31 0000 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 cm@acc.umu.se 2007-11-28 21:25:35 0000 Created an attachment (id=137277) openocd-live-0.1.ebuild I guess dev-embedded would be the right group for this ebuild? public@kosta.tk 2007-11-30 00:02:53 0000 Created an attachment (id=137352) An ebuild of openocd - all possible devices are useflags. public@kosta.tk 2007-11-30 00:04:43 0000 (From update of attachment 137352) I wish I knew about this ebuild when I started writing mine... anyway, this is a more complete ebuild, with useflags for all devices public@kosta.tk 2007-11-30 00:30:01 0000 Created an attachment (id=137354) Minor correction Sorry, I had a typo and a small fix to make. robbat2@gentoo.org 2007-11-30 00:39:32 0000 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. cm@acc.umu.se 2007-11-30 05:43:11 0000 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. calchan@gentoo.org 2007-11-30 07:17:46 0000 (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. public@kosta.tk 2007-11-30 11:19:15 0000 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. robbat2@gentoo.org 2007-11-30 22:28:55 0000 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. public@kosta.tk 2007-12-01 19:33:56 0000 Created an attachment (id=137492) New version - most things are installed by default public@kosta.tk 2007-12-01 23:32:47 0000 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. public@kosta.tk 2007-12-02 02:04:37 0000 Created an attachment (id=137521) Another fix to the useflag handling in DEPEND public@kosta.tk 2008-03-27 00:25:47 0000 Added to the sabayon overlay. Please close. calchan@gentoo.org 2008-03-27 13:35:39 0000 (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. public@kosta.tk 2008-03-28 17:24:57 0000 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. calchan@gentoo.org 2008-03-28 17:42:31 0000 (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. vapier@gentoo.org 2008-03-30 17:59:05 0000 Created an attachment (id=147718) cleaned up public@kosta.tk 2008-03-30 20:07:23 0000 (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) public@kosta.tk 2008-03-30 20:39:33 0000 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. > public@kosta.tk 2008-03-30 20:42:34 0000 Created an attachment (id=147750) ebuild with relating to the last comment public@kosta.tk 2008-03-30 20:45:15 0000 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. > > > vapier@gentoo.org 2008-03-31 01:45:43 0000 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. public@kosta.tk 2008-03-31 08:31:55 0000 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. > public@kosta.tk 2008-03-31 09:26:01 0000 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. > public@kosta.tk 2008-03-31 17:36:43 0000 Created an attachment (id=147868) Correction of the quotes SpanKY, you were right about one thing - the quotes were unnecessary. vapier@gentoo.org 2008-04-14 01:00:16 0000 Created an attachment (id=149642) 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. public@kosta.tk 2008-04-14 08:09:14 0000 (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? vapier@gentoo.org 2008-04-14 10:36:54 0000 Created an attachment (id=149666) 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. public@kosta.tk 2008-04-14 10:57:01 0000 (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. vapier@gentoo.org 2008-04-15 01:47:28 0000 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. public@kosta.tk 2008-04-18 23:55:14 0000 (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()? vapier@gentoo.org 2008-04-19 06:11:15 0000 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 public@kosta.tk 2008-04-19 09:18:27 0000 Created an attachment (id=150264) 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? vapier@gentoo.org 2008-04-19 21:00:43 0000 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. public@kosta.tk 2008-04-19 21:27:55 0000 (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. vapier@gentoo.org 2008-04-19 21:44:48 0000 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. public@kosta.tk 2008-04-19 22:43:43 0000 (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. 137277 2007-11-28 21:25 0000 openocd-live-0.1.ebuild openocd-live-0.1.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkVTVk5fUkVQT19VUkk9Imh0dHA6Ly9z dm4uYmVybGlvcy5kZS9zdm5yb290L3JlcG9zL29wZW5vY2QvdHJ1bmsvIgpFU1ZOX1BST0pFQ1Q9 Im9wZW5vY2QiCkVTVk5fQk9PVFNUUkFQPSIuL2Jvb3RzdHJhcCIKCkRFU0NSSVBUSU9OPSJUaGUg T3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5mYWN0cy5iZXJsaW9z LmRlL2luZGV4LWVuLnBodG1sP3RpdGxlPU9wZW5fT24tQ2hpcF9EZWJ1Z2dlciIKTElDRU5TRT0i R1BMLTIiClNMT1Q9IjAiCktFWVdPUkRTPSJ+YW1kNjQgfng4NiIKSVVTRT0iZnRkaSIKClJERVBF TkQ9ImZ0ZGk/ICggPj1kZXYtZW1iZWRkZWQvbGliZnRkaS0wLjggKSIKCkRFUEVORD0iJHtSREVQ RU5EfQoJPj1zeXMtZGV2ZWwvYXV0b21ha2UtMS45Cgk+PXN5cy1kZXZlbC9hdXRvY29uZi0yLjEz IgoKc3JjX3VucGFjaygpIHsKCXN1YnZlcnNpb25fc3JjX3VucGFjawp9CgpzcmNfY29tcGlsZSgp IHsKCQoJbG9jYWwgbXljb25mCgoJIyBUaGVyZSBhcmUgbW9yZSBmbGFncyB0byBlbmFibGUsIGJ1 dCB0aGV5IGFyZSB0b28gY29tcGxpY2F0ZWQgZm9yIG1lLgoJaWYgdXNlIGZ0ZGkgOyB0aGVuCgkJ CW15Y29uZj0iJHtteWNvbmZ9IC0tZW5hYmxlLWZ0MjIzMl9saWJmdGRpIgoJZmkKCgllY29uZiBc CgkJLS1lbmFibGUtcGFycG9ydCBcCgkJLS1lbmFibGUtcGFycG9ydF9wcGRldiBcCgkJJChteWNv bmYpIFwKCQl8fCBkaWUgImVjb25mIGZhaWxlZCIKCWVtYWtlIHx8IGRpZSAiZW1ha2UgZmFpbGVk Igp9CgpzcmNfaW5zdGFsbCgpIHsKCW1ha2UgREVTVERJUj0ke0R9IGRvY2Rpcj0vdXNyL3NoYXJl L2RvYy8ke1BGfSBcCgkJaW5zdGFsbCB8fCBkaWUgIm1ha2UgaW5zdGFsbCBmYWlsZWQiCgoJZG9k b2MgQVVUSE9SUyBDaGFuZ2VMb2cgUkVBRE1FIFRPRE8gTkVXUyB8fCBkaWUgImRvZG9jIGZhaWxl ZCIKfQo= 137352 2007-11-30 00:02 0000 An ebuild of openocd - all possible devices are useflags. openocd-svn-1.0.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKRUFQST0iMSIKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJP cGVuT0NEIC0gT3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2Qu YmVybGlvcy5kZS93ZWIvIgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy8ke1BOfS90cnVuayIKU1JDX1VSST0iIgpMSUNFTlNFPSJHUEwtMiIKClNMT1Q9 IjAiCktFWVdPUkRTPSJ+eDg2IH5hbWQ2NCIKSVVTRT0iK2Z0MjIzMiAtbGliZnRkaSArZnRkMnh4 ICtwYXJwb3J0IC1hbW9udGVjIC1lcDkzIC1hdDkxIC11c2Jwcm9nIC1ndyAtcHJlc3RvIC1wYXJw b3J0X3BwZGV2IC1wYXJwb3J0X2dpdmVpbyIKCgpTPSIke1dPUktESVJ9L3RydW5rIgoKREVQRU5E PSJmdGQyeHg/ICggZGV2LWVtYmVkZGVkL2Z0ZDJ4eCApCgk+PXN5cy1kZXZlbC9hdXRvbWFrZS0x LjkKCT49c3lzLWRldmVsL2F1dG9jb25mLTIuMTMiCgpSREVQRU5EPSJsaWJmdGRpPyAoIGRldi1l bWJlZGRlZC9saWJmdGRpICkiCgpwa2dfc2V0dXAgKCkgewoJaWYgdXNlIGxpYmZ0ZGkgJiYgdXNl IGZ0ZDJ4eDsgdGhlbgoJICAgZWVycm9yICJvcGVub2NkIGNhbid0IGJlIGJ1aWx0IHdpdGggYm90 aCBsaWJmdGRpIEFORCBmdGQyeHguIgoJICAgZWVycm9yICJwbGVhc2UgZGlzYWJsZSBlaXRoZXIg b25lIG9mIHRob3NlIHVzZWZsYWdzIGFuZCB0cnkgYWdhaW4iCgkgICBkaWUgIkluY29tcGxhdGli bGUgdXNlZmxhZ3MhIgoJZmkKCglpZiB1c2UgcHJlc3RvIHx8IHVzZSBmdDIyMzI7IHRoZW4KCSAg IGlmICEgdXNlIGxpYmZ0ZGkgJiYgISB1c2UgZnRkMnh4OyB0aGVuCgkgICAgICBlZXJyb3IgIllv dSBtdXN0IGhhdmUgZWl0aGVyIGxpYmZ0ZGkgb3IgZnRkMnh4IGVuYWJsZWQgaWYiCgkgICAgICBl ZXJyb3IgInlvdSB3YW50IHByZXN0byBvciBmdDIyMzIhIgoJICAgICAgZGllICJJbmNvbXBhdGli bGUgdXNlZmxhZ3MhIgoJICAgZmkKCWZpCgoJZXdhcm4gIkNoZWNrcyBhcmUgb25seSBtYWRlIGFn YWluc3QgbGliZnRkaSBhbmQgZnRkMnh4ISIKCWV3YXJuICJZb3UgYXJlIHJlc3BvbnNpYmxlIHRv IHZlcmlmeSB5b3UgaGF2ZSB0aGUgZHJpdmVycyIKCWV3YXJuICJmb3IgYW55IG90aGVyIGRldmlj ZXMgeW91IGVuYWJsZSEiCn0KCnNyY19jb21waWxlICgpIHsKCWNkICIke1N9IgoJLi9ib290c3Ry YXAgfHwgZGllICJDYW4ndCBib290c3RyYXAhIgoKIyBDaGVjayB3aGljaCBpbnRlcmZhY2VzIGFy ZSBlbmFibGVkOgoKICAJaWYgdXNlIHByZXN0bzsgdGhlbgoJICAgUFJFU1RPPSIkKHVzZV9lbmFi bGUgbGliZnRkaSBwcmVzdG9fbGliZnRkaSkgJCh1c2VfZW5hYmxlIGZ0ZDJ4eCBwcmVzdG9fZnRk Mnh4KSIKCWZpCgogIAlpZiB1c2UgZnQyMjMyOyB0aGVuCgkgICBGMjIzMj0iJCh1c2VfZW5hYmxl IGxpYmZ0ZGkgZnQyMjMyX2xpYmZ0ZGkpICQodXNlX2VuYWJsZSBmdGQyeHggZnQyMjMyX2Z0ZDJ4 eCkiCglmaQoKCUlOVEVSRkFDRVM9IiQodXNlX2VuYWJsZSBvb2NkX3RyYWNlKSAkKHVzZV9lbmFi bGUgcGFycG9ydF9wcGRldikgXAoJCSAgICAkKHVzZV9lbmFibGUgcGFycG9ydCkgJCh1c2VfZW5h YmxlIGFtb250ZWMgYW10anRhZ2FjY2VsKSBcCgkJICAgICQodXNlX2VuYWJsZSBlcDkzIGVwOTN4 eCkgJCh1c2VfZW5hYmxlIGF0OTEgYXQ5MXJtOTIwMCkgXAoJCSAgICAkKHVzZV9lbmFibGUgZ3cg Z3cxNjAxMikgJCh1c2VfZW5hYmxlIHVzYnByb2cpICQodXNlX2VuYWJsZSBwYXJwb3J0X2dpdmVp bykgXAoJCSAgICAke1BSRVNUT30gJHtGMjIzMn0iCgkKCWVjb25mICR7SU5URVJGQUNFU30gfHwg ZGllICJFcnJvciBpbiBlY29uZiEiCgllbWFrZSB8fCBkaWUgIkVycm9yIGluIGVtYWtlISIKfQoK c3JjX2luc3RhbGwgKCkgewoJY2QgIiR7U30vYnVpbGQiCgllbWFrZSBERVNURElSPSIkRCIgaW5z dGFsbAp9Cg== 137354 2007-11-30 00:30 0000 Minor correction openocd-svn-1.0.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKRUFQST0iMSIKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJP cGVuT0NEIC0gT3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2Qu YmVybGlvcy5kZS93ZWIvIgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy8ke1BOfS90cnVuayIKU1JDX1VSST0iIgpMSUNFTlNFPSJHUEwtMiIKClNMT1Q9 IjAiCktFWVdPUkRTPSJ+eDg2IH5hbWQ2NCIKSVVTRT0iK2Z0MjIzMiAtbGliZnRkaSArZnRkMnh4 ICtwYXJwb3J0IC1hbW9udGVjIC1lcDkzIC1hdDkxIC11c2Jwcm9nIC1ndyAtcHJlc3RvIC1wYXJw b3J0X3BwZGV2IC1wYXJwb3J0X2dpdmVpbyIKCgpTPSIke1dPUktESVJ9L3RydW5rIgoKREVQRU5E PSJmdGQyeHg/ICggZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApIgoKUkRFUEVORD0ibGliZnRkaT8g KCBkZXYtZW1iZWRkZWQvbGliZnRkaSApIgoKcGtnX3NldHVwICgpIHsKCWlmIHVzZSBsaWJmdGRp ICYmIHVzZSBmdGQyeHg7IHRoZW4KCSAgIGVlcnJvciAib3Blbm9jZCBjYW4ndCBiZSBidWlsdCB3 aXRoIGJvdGggbGliZnRkaSBBTkQgZnRkMnh4LiIKCSAgIGVlcnJvciAicGxlYXNlIGRpc2FibGUg ZWl0aGVyIG9uZSBvZiB0aG9zZSB1c2VmbGFncyBhbmQgdHJ5IGFnYWluIgoJICAgZGllICJJbmNv bXBsYXRpYmxlIHVzZWZsYWdzISIKCWZpCgoJaWYgdXNlIHByZXN0byB8fCB1c2UgZnQyMjMyOyB0 aGVuCgkgICBpZiAhIHVzZSBsaWJmdGRpICYmICEgdXNlIGZ0ZDJ4eDsgdGhlbgoJICAgICAgZWVy cm9yICJZb3UgbXVzdCBoYXZlIGVpdGhlciBsaWJmdGRpIG9yIGZ0ZDJ4eCBlbmFibGVkIGlmIgoJ ICAgICAgZWVycm9yICJ5b3Ugd2FudCBwcmVzdG8gb3IgZnQyMjMyISIKCSAgICAgIGRpZSAiSW5j b21wYXRpYmxlIHVzZWZsYWdzISIKCSAgIGZpCglmaQoKCWV3YXJuICJDaGVja3MgYXJlIG9ubHkg bWFkZSBhZ2FpbnN0IGxpYmZ0ZGkgYW5kIGZ0ZDJ4eCEiCglld2FybiAiWW91IGFyZSByZXNwb25z aWJsZSB0byB2ZXJpZnkgeW91IGhhdmUgdGhlIGRyaXZlcnMiCglld2FybiAiZm9yIGFueSBvdGhl ciBkZXZpY2VzIHlvdSBlbmFibGUhIgp9CgpzcmNfY29tcGlsZSAoKSB7CgljZCAiJHtTfSIKCS4v Ym9vdHN0cmFwIHx8IGRpZSAiQ2FuJ3QgYm9vdHN0cmFwISIKCiMgQ2hlY2sgd2hpY2ggaW50ZXJm YWNlcyBhcmUgZW5hYmxlZDoKCiAgCWlmIHVzZSBwcmVzdG87IHRoZW4KCSAgIFBSRVNUTz0iJCh1 c2VfZW5hYmxlIGxpYmZ0ZGkgcHJlc3RvX2xpYmZ0ZGkpICQodXNlX2VuYWJsZSBmdGQyeHggcHJl c3RvX2Z0ZDJ4eCkiCglmaQoKICAJaWYgdXNlIGZ0MjIzMjsgdGhlbgoJICAgRjIyMzI9IiQodXNl X2VuYWJsZSBsaWJmdGRpIGZ0MjIzMl9saWJmdGRpKSAkKHVzZV9lbmFibGUgZnRkMnh4IGZ0MjIz Ml9mdGQyeHgpIgoJZmkKCglJTlRFUkZBQ0VTPSIkKHVzZV9lbmFibGUgb29jZF90cmFjZSkgJCh1 c2VfZW5hYmxlIHBhcnBvcnRfcHBkZXYpIFwKCQkgICAgJCh1c2VfZW5hYmxlIHBhcnBvcnQpICQo dXNlX2VuYWJsZSBhbW9udGVjIGFtdGp0YWdhY2NlbCkgXAoJCSAgICAkKHVzZV9lbmFibGUgZXA5 MyBlcDkzeHgpICQodXNlX2VuYWJsZSBhdDkxIGF0OTFybTkyMDApIFwKCQkgICAgJCh1c2VfZW5h YmxlIGd3IGd3MTYwMTIpICQodXNlX2VuYWJsZSB1c2Jwcm9nKSAkKHVzZV9lbmFibGUgcGFycG9y dF9naXZlaW8pIFwKCQkgICAgJHtQUkVTVE99ICR7RjIyMzJ9IgoJCgllY29uZiAke0lOVEVSRkFD RVN9IHx8IGRpZSAiRXJyb3IgaW4gZWNvbmYhIgoJZW1ha2UgfHwgZGllICJFcnJvciBpbiBlbWFr ZSEiCn0KCnNyY19pbnN0YWxsICgpIHsKCWNkICIke1N9L2J1aWxkIgoJZW1ha2UgREVTVERJUj0i JEQiIGluc3RhbGwKfQo= 137492 2007-12-01 19:33 0000 New version - most things are installed by default openocd-svn-1.0.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKRUFQST0iMSIKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJP cGVuT0NEIC0gT3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2Qu YmVybGlvcy5kZS93ZWIvIgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy9vcGVub2NkL3RydW5rIgpTUkNfVVJJPSIiCkxJQ0VOU0U9IkdQTC0yIgoKU0xP VD0iMCIKS0VZV09SRFM9In54ODYgfmFtZDY0IgpJVVNFPSIrZnQyMjMyICtwcmVzdG8gbGliZnRk aSBwYXJwb3J0X2dpdmVpbyIKCgpTPSIke1dPUktESVJ9L3RydW5rIgoKIyBsaWJmdGQyeHggaXMg dGhlIGRlZmF1bHQgYmVjYXVzZSBpdCBpcyByZXBvcnRlZCB0byB3b3JrIGJldHRlci4KREVQRU5E PSJsaWJmdGRpPyAoIGRldi1lbWJlZGRlZC9saWJmdGRpICkKCWZ0MjIzMj8gfHwgKCAoIGRldi1l bWJlZGRlZC9saWJmdGQyeHggKSAoIGRldi1lbWJlZGRlZC9saWJmdGRpICkgKQoJcHJlc3RvPyAo IGRldi1lbWJlZGRlZC9saWJmdGQyeHggKSIKClJERVBFTkQ9IiR7REVQRU5EfSIKCnBrZ19zZXR1 cCAoKSB7CglpZiB1c2UgbGliZnRkaSAmJiAhIHVzZSBmdDIyMzI7IHRoZW4KCSAgICAgIGV3YXJu ICJZb3UgZW5hYmxlZCBsaWJmdGRpIGJ1dCBub3QgZnQyMjMyISIKCSAgICAgIGV3YXJuICJsaWJm dGRpIGlzIG9ubHkgdXNlZCBmb3IgZnQyMjMyLCBzbyB0aGlzIGlzIG1lYW5pbmdsZXNzISIKCWZp CgoJZXdhcm4gIkNoZWNrcyBhcmUgb25seSBtYWRlIGZvciBsaWJmdGRpIGFuZCBsaWJmdGQyeHgh IgoJZXdhcm4gIllvdSBhcmUgcmVzcG9uc2libGUgdG8gdmVyaWZ5IHlvdSBoYXZlIHRoZSBkcml2 ZXJzIgoJZXdhcm4gImZvciBhbnkgb3RoZXIgZGV2aWNlcyB5b3UgZW5hYmxlISIKfQoKc3JjX2Nv bXBpbGUgKCkgewoJY2QgIiR7U30iCgkuL2Jvb3RzdHJhcCB8fCBkaWUgIkNhbid0IGJvb3RzdHJh cCEiCgojIENoZWNrIHdoaWNoIGludGVyZmFjZXMgYXJlIGVuYWJsZWQ6CiAgCWlmIHVzZSBmdDIy MzI7IHRoZW4KCSAgIEYyMjMyPSIkKHVzZV9lbmFibGUgbGliZnRkaSBmdDIyMzJfbGliZnRkaSkg JCh1c2VfZW5hYmxlICFsaWJmdGRpIGZ0MjIzMl9mdGQyeHgpIgoJZmkKCgkKCURFRkFVTFRfSU5U RVJGQUNFUz0iLS1lbmFibGUtcGFycG9ydCAtLWVuYWJsZS1wYXJwb3J0X3BwZGV2IC0tZW5hYmxl LWFtdGp0YWdhY2NlbCBcCgkJCSAgICAtLWVuYWJsZS1lcDkzeHggLS1lbmFibGUtYXQ5MXJtOTIw MCAtLWVuYWJsZS1ndzE2MDEyIFwKCQkJICAgIC0tZW5hYmxlLXVzYnByb2cgLS1lbmFibGUtb29j ZF90cmFjZSIKCglJTlRFUkZBQ0VTPSIke0RFRkFVTFRfSU5URVJGQUNFU30gJCh1c2VfZW5hYmxl IHBhcnBvcnRfZ2l2ZWlvKSAkKHVzZV9lbmFibGUgcHJlc3RvIHByZXN0b19mdGQyeHgpICR7RjIy MzJ9IgoJCgllY29uZiAke0lOVEVSRkFDRVN9IHx8IGRpZSAiRXJyb3IgaW4gZWNvbmYhIgoJZW1h a2UgfHwgZGllICJFcnJvciBpbiBlbWFrZSEiCn0KCnNyY19pbnN0YWxsICgpIHsKCWNkICIke1N9 L2J1aWxkIgoJZW1ha2UgREVTVERJUj0iJEQiIGluc3RhbGwKfQo= 137521 2007-12-02 02:04 0000 Another fix to the useflag handling in DEPEND openocd-9999.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKRUFQST0iMSIKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJP cGVuT0NEIC0gT3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2Qu YmVybGlvcy5kZS93ZWIvIgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy9vcGVub2NkL3RydW5rIgpTUkNfVVJJPSIiCkxJQ0VOU0U9IkdQTC0yIgoKU0xP VD0iMCIKS0VZV09SRFM9In54ODYgfmFtZDY0IgpJVVNFPSIrZnQyMjMyICtwcmVzdG8gbGliZnRk aSBwYXJwb3J0X2dpdmVpbyIKCgpTPSIke1dPUktESVJ9L3RydW5rIgoKIyBsaWJmdGQyeHggaXMg dGhlIGRlZmF1bHQgYmVjYXVzZSBpdCBpcyByZXBvcnRlZCB0byB3b3JrIGJldHRlci4KREVQRU5E PSJmdDIyMzI/ICggfHwgKCBsaWJmdGRpPyAoIGRldi1lbWJlZGRlZC9saWJmdGRpICkKCQkgICAg ICggZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApCgkJKSApCglwcmVzdG8/ICggZGV2LWVtYmVkZGVk L2xpYmZ0ZDJ4eCApIgoKUkRFUEVORD0iJHtERVBFTkR9IgoKcGtnX3NldHVwICgpIHsKCWlmIHVz ZSBsaWJmdGRpICYmICEgdXNlIGZ0MjIzMjsgdGhlbgoJICAgICAgZXdhcm4gIllvdSBlbmFibGVk IGxpYmZ0ZGkgYnV0IG5vdCBmdDIyMzIhIgoJICAgICAgZXdhcm4gImxpYmZ0ZGkgaXMgb25seSB1 c2VkIGZvciBmdDIyMzIsIHNvIHRoaXMgaXMgbWVhbmluZ2xlc3MhIgoJZmkKCglld2FybiAiQ2hl Y2tzIGFyZSBvbmx5IG1hZGUgZm9yIGxpYmZ0ZGkgYW5kIGxpYmZ0ZDJ4eCEiCglld2FybiAiWW91 IGFyZSByZXNwb25zaWJsZSB0byB2ZXJpZnkgeW91IGhhdmUgdGhlIGRyaXZlcnMiCglld2FybiAi Zm9yIGFueSBvdGhlciBkZXZpY2VzIHlvdSBlbmFibGUhIgp9CgpzcmNfY29tcGlsZSAoKSB7Cglj ZCAiJHtTfSIKCS4vYm9vdHN0cmFwIHx8IGRpZSAiQ2FuJ3QgYm9vdHN0cmFwISIKCiMgQ2hlY2sg d2hpY2ggaW50ZXJmYWNlcyBhcmUgZW5hYmxlZDoKICAJaWYgdXNlIGZ0MjIzMjsgdGhlbgoJICAg RjIyMzI9IiQodXNlX2VuYWJsZSBsaWJmdGRpIGZ0MjIzMl9saWJmdGRpKSAkKHVzZV9lbmFibGUg IWxpYmZ0ZGkgZnQyMjMyX2Z0ZDJ4eCkiCglmaQoKCQoJREVGQVVMVF9JTlRFUkZBQ0VTPSItLWVu YWJsZS1wYXJwb3J0IC0tZW5hYmxlLXBhcnBvcnRfcHBkZXYgLS1lbmFibGUtYW10anRhZ2FjY2Vs IFwKCQkJICAgIC0tZW5hYmxlLWVwOTN4eCAtLWVuYWJsZS1hdDkxcm05MjAwIC0tZW5hYmxlLWd3 MTYwMTIgXAoJCQkgICAgLS1lbmFibGUtdXNicHJvZyAtLWVuYWJsZS1vb2NkX3RyYWNlIgoKCUlO VEVSRkFDRVM9IiR7REVGQVVMVF9JTlRFUkZBQ0VTfSAkKHVzZV9lbmFibGUgcGFycG9ydF9naXZl aW8pICQodXNlX2VuYWJsZSBwcmVzdG8gcHJlc3RvX2Z0ZDJ4eCkgJHtGMjIzMn0iCgkKCWVjb25m ICR7SU5URVJGQUNFU30gfHwgZGllICJFcnJvciBpbiBlY29uZiEiCgllbWFrZSB8fCBkaWUgIkVy cm9yIGluIGVtYWtlISIKfQoKc3JjX2luc3RhbGwgKCkgewoJY2QgIiR7U30vYnVpbGQiCgllbWFr ZSBERVNURElSPSIkRCIgaW5zdGFsbAp9Cg== 147718 2008-03-30 17:59 0000 cleaned up openocd-9999.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA4IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCkVBUEk9IjEiCgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy9vcGVub2NkL3RydW5rIgppbmhlcml0IGV1dGlscyBzdWJ2ZXJzaW9uCgpERVND UklQVElPTj0iT3Blbk9DRCAtIE9wZW4gT24tQ2hpcCBEZWJ1Z2dlciIKSE9NRVBBR0U9Imh0dHA6 Ly9vcGVub2NkLmJlcmxpb3MuZGUvd2ViLyIKU1JDX1VSST0iIgoKTElDRU5TRT0iR1BMLTIiClNM T1Q9IjAiCktFWVdPUkRTPSJ+eDg2IH5hbWQ2NCIKSVVTRT0iK2Z0MjIzMiArcHJlc3RvIGxpYmZ0 ZGkgcGFycG9ydF9naXZlaW8iCgpTPSIke1dPUktESVJ9L3RydW5rIgoKIyBsaWJmdGQyeHggaXMg dGhlIGRlZmF1bHQgYmVjYXVzZSBpdCBpcyByZXBvcnRlZCB0byB3b3JrIGJldHRlci4KREVQRU5E PSJwcmVzdG8/ICggZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApCglmdDIyMzI/ICggfHwgKCBsaWJm dGRpPyAoIGRldi1lbWJlZGRlZC9saWJmdGRpICkgZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApICki Cgpwa2dfc2V0dXAoKSB7CglpZiB1c2UgbGliZnRkaSAmJiAhIHVzZSBmdDIyMzI7IHRoZW4KCQll d2FybiAiWW91IGVuYWJsZWQgbGliZnRkaSBidXQgbm90IGZ0MjIzMiEiCgkJZXdhcm4gImxpYmZ0 ZGkgaXMgb25seSB1c2VkIGZvciBmdDIyMzIsIHNvIHRoaXMgaXMgbWVhbmluZ2xlc3MhIgoJZmkK fQoKc3JjX3VucGFjaygpIHsKCXN1YnZlcnNpb25fc3JjX3VucGFjawoJY2QgIiR7U30iCgkuL2Jv b3RzdHJhcCB8fCBkaWUgIkNhbid0IGJvb3RzdHJhcCEiCn0KCnNyY19jb21waWxlKCkgewoJZWNv bmYgXAoJCS0tZW5hYmxlLXBhcnBvcnQgXAoJCS0tZW5hYmxlLXBhcnBvcnRfcHBkZXYgXAoJCS0t ZW5hYmxlLWFtdGp0YWdhY2NlbCBcCgkJLS1lbmFibGUtZXA5M3h4IFwKCQktLWVuYWJsZS1hdDkx cm05MjAwIFwKCQktLWVuYWJsZS1ndzE2MDEyIFwKCQktLWVuYWJsZS11c2Jwcm9nIFwKCQktLWVu YWJsZS1vb2NkX3RyYWNlIFwKCQkkKHVzZV9lbmFibGUgcGFycG9ydF9naXZlaW8pIFwKCQkkKHVz ZV9lbmFibGUgcHJlc3RvIHByZXN0b19mdGQyeHgpIFwKCQkkKHVzZV9lbmFibGUgbGliZnRkaSBm dDIyMzJfbGliZnRkaSkgXAoJCSQodXNlX2VuYWJsZSAhbGliZnRkaSBmdDIyMzJfZnRkMnh4KSBc CgkJfHwgZGllICJFcnJvciBpbiBlY29uZiEiCgllbWFrZSB8fCBkaWUgIkVycm9yIGluIGVtYWtl ISIKfQoKc3JjX2luc3RhbGwoKSB7CgljZCBidWlsZAoJZW1ha2UgREVTVERJUj0iJHtEfSIgaW5z dGFsbCB8fCBkaWUKfQo= 147750 2008-03-30 20:42 0000 ebuild with relating to the last comment openocd-9999.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJPcGVuT0NEIC0g T3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2QuYmVybGlvcy5k ZS93ZWIvIgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zucm9vdC9yZXBv cy9vcGVub2NkL3RydW5rIgpTUkNfVVJJPSIiCkxJQ0VOU0U9IkdQTC0yIgoKU0xPVD0iMCIKS0VZ V09SRFM9In54ODYgfmFtZDY0IgpJVVNFPSJmdDIyMzIgcHJlc3RvIGxpYmZ0ZGkgcGFycG9ydF9n aXZlaW8iCgoKUz0iJHtXT1JLRElSfS90cnVuayIKCiMgbGliZnRkMnh4IGlzIHRoZSBkZWZhdWx0 IGJlY2F1c2UgaXQgaXMgcmVwb3J0ZWQgdG8gd29yayBiZXR0ZXIuCkRFUEVORD0iZnQyMjMyPyAo IHx8ICggbGliZnRkaT8gKCBkZXYtZW1iZWRkZWQvbGliZnRkaSApCgkJICAgICAoIGRldi1lbWJl ZGRlZC9saWJmdGQyeHggKQoJCSkgKQoJcHJlc3RvPyAoIGRldi1lbWJlZGRlZC9saWJmdGQyeHgg KSIKClJERVBFTkQ9IiR7REVQRU5EfSIKCnBrZ19zZXR1cCAoKSB7CglpZiB1c2UgbGliZnRkaSAm JiAhIHVzZSBmdDIyMzI7IHRoZW4KCSAgICAgIGV3YXJuICJZb3UgZW5hYmxlZCBsaWJmdGRpIGJ1 dCBub3QgZnQyMjMyISIKCSAgICAgIGV3YXJuICJsaWJmdGRpIGlzIG9ubHkgdXNlZCBmb3IgZnQy MjMyLCBzbyB0aGlzIGlzIG1lYW5pbmdsZXNzISIKCWZpCgoJZXdhcm4gIkNoZWNrcyBhcmUgb25s eSBtYWRlIGZvciBsaWJmdGRpIGFuZCBsaWJmdGQyeHghIgoJZXdhcm4gIllvdSBhcmUgcmVzcG9u c2libGUgdG8gdmVyaWZ5IHlvdSBoYXZlIHRoZSBkcml2ZXJzIgoJZXdhcm4gImZvciBhbnkgb3Ro ZXIgZGV2aWNlcyB5b3UgZW5hYmxlISIKfQoKc3JjX2NvbXBpbGUgKCkgewoJY2QgIiR7U30iCgku L2Jvb3RzdHJhcCB8fCBkaWUgIkNhbid0IGJvb3RzdHJhcCEiCgojIENoZWNrIHdoaWNoIGludGVy ZmFjZXMgYXJlIGVuYWJsZWQ6CiAgCWlmIHVzZSBmdDIyMzI7IHRoZW4KCSAgIEYyMjMyPSIkKHVz ZV9lbmFibGUgbGliZnRkaSBmdDIyMzJfbGliZnRkaSkgJCh1c2VfZW5hYmxlICFsaWJmdGRpIGZ0 MjIzMl9mdGQyeHgpIgoJZmkKCglERUZBVUxUX0lOVEVSRkFDRVM9Ii0tZW5hYmxlLXBhcnBvcnQg LS1lbmFibGUtcGFycG9ydF9wcGRldiAtLWVuYWJsZS1hbXRqdGFnYWNjZWwgXAoJCQkgICAgLS1l bmFibGUtZXA5M3h4IC0tZW5hYmxlLWF0OTFybTkyMDAgLS1lbmFibGUtZ3cxNjAxMiBcCgkJCSAg ICAtLWVuYWJsZS11c2Jwcm9nIC0tZW5hYmxlLW9vY2RfdHJhY2UiCgoJZWNvbmYgIiR7REVGQVVM VF9JTlRFUkZBQ0VTfSAkKHVzZV9lbmFibGUgcGFycG9ydF9naXZlaW8pICQodXNlX2VuYWJsZSBw cmVzdG8gcHJlc3RvX2Z0ZDJ4eCkgJHtGMjIzMn0iIHx8IGRpZSAiRXJyb3IgaW4gZWNvbmYhIgoJ ZW1ha2UgfHwgZGllICJFcnJvciBpbiBlbWFrZSEiCn0KCnNyY19pbnN0YWxsICgpIHsKCWNkICIk e1N9L2J1aWxkIgoJZW1ha2UgREVTVERJUj0iJEQiIGluc3RhbGwKfQo= 147868 2008-03-31 17:36 0000 Correction of the quotes openocd-9999.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA3IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJPcGVuT0NEIC0g T3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2QuYmVybGlvcy5k ZS93ZWIvIgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zucm9vdC9yZXBv cy9vcGVub2NkL3RydW5rIgpTUkNfVVJJPSIiCkxJQ0VOU0U9IkdQTC0yIgoKU0xPVD0iMCIKS0VZ V09SRFM9In54ODYgfmFtZDY0IgpJVVNFPSJmdDIyMzIgcHJlc3RvIGxpYmZ0ZGkgcGFycG9ydF9n aXZlaW8iCgoKUz0iJHtXT1JLRElSfS90cnVuayIKCiMgbGliZnRkMnh4IGlzIHRoZSBkZWZhdWx0 IGJlY2F1c2UgaXQgaXMgcmVwb3J0ZWQgdG8gd29yayBiZXR0ZXIuCkRFUEVORD0iZnQyMjMyPyAo IHx8ICggbGliZnRkaT8gKCBkZXYtZW1iZWRkZWQvbGliZnRkaSApCgkJICAgICAoIGRldi1lbWJl ZGRlZC9saWJmdGQyeHggKQoJCSkgKQoJcHJlc3RvPyAoIGRldi1lbWJlZGRlZC9saWJmdGQyeHgg KSIKClJERVBFTkQ9IiR7REVQRU5EfSIKCnBrZ19zZXR1cCAoKSB7CglpZiB1c2UgbGliZnRkaSAm JiAhIHVzZSBmdDIyMzI7IHRoZW4KCSAgICAgIGV3YXJuICJZb3UgZW5hYmxlZCBsaWJmdGRpIGJ1 dCBub3QgZnQyMjMyISIKCSAgICAgIGV3YXJuICJsaWJmdGRpIGlzIG9ubHkgdXNlZCBmb3IgZnQy MjMyLCBzbyB0aGlzIGlzIG1lYW5pbmdsZXNzISIKCWZpCgoJZXdhcm4gIkNoZWNrcyBhcmUgb25s eSBtYWRlIGZvciBsaWJmdGRpIGFuZCBsaWJmdGQyeHghIgoJZXdhcm4gIllvdSBhcmUgcmVzcG9u c2libGUgdG8gdmVyaWZ5IHlvdSBoYXZlIHRoZSBkcml2ZXJzIgoJZXdhcm4gImZvciBhbnkgb3Ro ZXIgZGV2aWNlcyB5b3UgZW5hYmxlISIKfQoKc3JjX2NvbXBpbGUgKCkgewoJY2QgIiR7U30iCgku L2Jvb3RzdHJhcCB8fCBkaWUgIkNhbid0IGJvb3RzdHJhcCEiCgojIENoZWNrIHdoaWNoIGludGVy ZmFjZXMgYXJlIGVuYWJsZWQ6CiAgCWlmIHVzZSBmdDIyMzI7IHRoZW4KCSAgIEYyMjMyPSIkKHVz ZV9lbmFibGUgbGliZnRkaSBmdDIyMzJfbGliZnRkaSkgJCh1c2VfZW5hYmxlICFsaWJmdGRpIGZ0 MjIzMl9mdGQyeHgpIgoJZmkKCglERUZBVUxUX0lOVEVSRkFDRVM9Ii0tZW5hYmxlLXBhcnBvcnQg LS1lbmFibGUtcGFycG9ydF9wcGRldiAtLWVuYWJsZS1hbXRqdGFnYWNjZWwgXAoJCQkgICAgLS1l bmFibGUtZXA5M3h4IC0tZW5hYmxlLWF0OTFybTkyMDAgLS1lbmFibGUtZ3cxNjAxMiBcCgkJCSAg ICAtLWVuYWJsZS11c2Jwcm9nIC0tZW5hYmxlLW9vY2RfdHJhY2UiCgoJZWNvbmYge0RFRkFVTFRf SU5URVJGQUNFU30gJCh1c2VfZW5hYmxlIHBhcnBvcnRfZ2l2ZWlvKSAkKHVzZV9lbmFibGUgcHJl c3RvIHByZXN0b19mdGQyeHgpICR7RjIyMzJ9IHx8IGRpZSAiRXJyb3IgaW4gZWNvbmYhIgoJZW1h a2UgfHwgZGllICJFcnJvciBpbiBlbWFrZSEiCn0KCnNyY19pbnN0YWxsICgpIHsKCWNkICIke1N9 L2J1aWxkIgoJZW1ha2UgREVTVERJUj0iJEQiIGluc3RhbGwKfQo= 149642 2008-04-14 01:00 0000 opencd-9999.ebuild opencd-9999.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA4IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCkVBUEk9IjEiCgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy9vcGVub2NkL3RydW5rIgppbmhlcml0IGV1dGlscyBzdWJ2ZXJzaW9uCgpERVND UklQVElPTj0iT3Blbk9DRCAtIE9wZW4gT24tQ2hpcCBEZWJ1Z2dlciIKSE9NRVBBR0U9Imh0dHA6 Ly9vcGVub2NkLmJlcmxpb3MuZGUvd2ViLyIKU1JDX1VSST0iIgoKTElDRU5TRT0iR1BMLTIiClNM T1Q9IjAiCktFWVdPUkRTPSJ+eDg2IH5hbWQ2NCIKSVVTRT0iK2Z0MjIzMiArcHJlc3RvIGxpYmZ0 ZGkgcGFycG9ydF9naXZlaW8iCgpTPSIke1dPUktESVJ9L3RydW5rIgoKIyBsaWJmdGQyeHggaXMg dGhlIGRlZmF1bHQgYmVjYXVzZSBpdCBpcyByZXBvcnRlZCB0byB3b3JrIGJldHRlci4KREVQRU5E PSJwcmVzdG8/ICggZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApCglmdDIyMzI/ICggfHwgKCBsaWJm dGRpPyAoIGRldi1lbWJlZGRlZC9saWJmdGRpICkgZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApICki Cgpwa2dfc2V0dXAoKSB7CglpZiB1c2UgbGliZnRkaSAmJiAhIHVzZSBmdDIyMzIgOyB0aGVuCgkJ ZXdhcm4gIllvdSBlbmFibGVkIGxpYmZ0ZGkgYnV0IG5vdCBmdDIyMzIhIgoJCWV3YXJuICJsaWJm dGRpIGlzIG9ubHkgdXNlZCBmb3IgZnQyMjMyLCBzbyB0aGlzIGlzIG1lYW5pbmdsZXNzISIKCWZp Cn0KCnNyY191bnBhY2soKSB7CglzdWJ2ZXJzaW9uX3NyY191bnBhY2sKCWNkICIke1N9IgoJLi9i b290c3RyYXAgfHwgZGllICJDYW4ndCBib290c3RyYXAhIgp9CgpzcmNfY29tcGlsZSgpIHsKCWVj b25mIFwKCQktLWVuYWJsZS1wYXJwb3J0IFwKCQktLWVuYWJsZS1wYXJwb3J0X3BwZGV2IFwKCQkt LWVuYWJsZS1hbXRqdGFnYWNjZWwgXAoJCS0tZW5hYmxlLWVwOTN4eCBcCgkJLS1lbmFibGUtYXQ5 MXJtOTIwMCBcCgkJLS1lbmFibGUtZ3cxNjAxMiBcCgkJLS1lbmFibGUtdXNicHJvZyBcCgkJLS1l bmFibGUtb29jZF90cmFjZSBcCgkJJCh1c2VfZW5hYmxlIHBhcnBvcnRfZ2l2ZWlvKSBcCgkJJCh1 c2VfZW5hYmxlIHByZXN0byBwcmVzdG9fZnRkMnh4KSBcCgkJJCh1c2UgZnQyMjMyICYmIHVzZV9l bmFibGUgbGliZnRkaSBmdDIyMzJfbGliZnRkaSkgXAoJCSQodXNlIGZ0MjIzMiAmJiB1c2VfZW5h YmxlICFsaWJmdGRpIGZ0MjIzMl9mdGQyeHgpIFwKCQl8fCBkaWUgIkVycm9yIGluIGVjb25mISIK CWVtYWtlIHx8IGRpZSAiRXJyb3IgaW4gZW1ha2UhIgp9CgpzcmNfaW5zdGFsbCgpIHsKCWNkIGJ1 aWxkCgllbWFrZSBERVNURElSPSIke0R9IiBpbnN0YWxsIHx8IGRpZQp9Cg== 149666 2008-04-14 10:36 0000 openocd-9999.ebuild openocd-9999.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA4IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCkVBUEk9IjEiCgpFU1ZOX1JFUE9fVVJJPSJodHRwOi8vc3ZuLmJlcmxpb3MuZGUvc3Zu cm9vdC9yZXBvcy9vcGVub2NkL3RydW5rIgppbmhlcml0IGV1dGlscyBzdWJ2ZXJzaW9uCgpERVND UklQVElPTj0iT3Blbk9DRCAtIE9wZW4gT24tQ2hpcCBEZWJ1Z2dlciIKSE9NRVBBR0U9Imh0dHA6 Ly9vcGVub2NkLmJlcmxpb3MuZGUvd2ViLyIKU1JDX1VSST0iIgoKTElDRU5TRT0iR1BMLTIiClNM T1Q9IjAiCktFWVdPUkRTPSJ+eDg2IH5hbWQ2NCIKSVVTRT0iK2Z0MjIzMiArcHJlc3RvIGxpYmZ0 ZGkgcGFycG9ydF9naXZlaW8iClJFU1RSSUNUPSJzdHJpcCIgIyBpbmNsdWRlcyBub24tbmF0aXZl IGJpbmFyaWVzCgojIGxpYmZ0ZDJ4eCBpcyB0aGUgZGVmYXVsdCBiZWNhdXNlIGl0IGlzIHJlcG9y dGVkIHRvIHdvcmsgYmV0dGVyLgpERVBFTkQ9InByZXN0bz8gKCBkZXYtZW1iZWRkZWQvbGliZnRk Mnh4ICkKCWZ0MjIzMj8gKCB8fCAoIGxpYmZ0ZGk/ICggZGV2LWVtYmVkZGVkL2xpYmZ0ZGkgKSBk ZXYtZW1iZWRkZWQvbGliZnRkMnh4ICkgKSIKCnBrZ19zZXR1cCgpIHsKCWlmIHVzZSBsaWJmdGRp ICYmICEgdXNlIGZ0MjIzMjsgdGhlbgoJCWV3YXJuICJZb3UgZW5hYmxlZCBsaWJmdGRpIGJ1dCBu b3QgZnQyMjMyISIKCQlld2FybiAibGliZnRkaSBpcyBvbmx5IHVzZWQgZm9yIGZ0MjIzMiwgc28g dGhpcyBpcyBtZWFuaW5nbGVzcyEiCglmaQp9CgpzcmNfdW5wYWNrKCkgewoJc3VidmVyc2lvbl9z cmNfdW5wYWNrCgljZCAiJHtTfSIKCS4vYm9vdHN0cmFwIHx8IGRpZSAiQ2FuJ3QgYm9vdHN0cmFw ISIKfQoKc3JjX2NvbXBpbGUoKSB7CgllY29uZiBcCgkJLS1lbmFibGUtcGFycG9ydCBcCgkJLS1l bmFibGUtcGFycG9ydF9wcGRldiBcCgkJLS1lbmFibGUtYW10anRhZ2FjY2VsIFwKCQktLWVuYWJs ZS1lcDkzeHggXAoJCS0tZW5hYmxlLWF0OTFybTkyMDAgXAoJCS0tZW5hYmxlLWd3MTYwMTIgXAoJ CS0tZW5hYmxlLXVzYnByb2cgXAoJCS0tZW5hYmxlLW9vY2RfdHJhY2UgXAoJCSQodXNlX2VuYWJs ZSBwYXJwb3J0X2dpdmVpbykgXAoJCSQodXNlX2VuYWJsZSBwcmVzdG8gcHJlc3RvX2Z0ZDJ4eCkg XAoJCSQodXNlIGZ0MjIzMiAmJiB1c2VfZW5hYmxlIGxpYmZ0ZGkgZnQyMjMyX2xpYmZ0ZGkpIFwK CQkkKHVzZSBmdDIyMzIgJiYgdXNlX2VuYWJsZSAhbGliZnRkaSBmdDIyMzJfZnRkMnh4KSBcCgkJ fHwgZGllICJFcnJvciBpbiBlY29uZiEiCgllbWFrZSB8fCBkaWUgIkVycm9yIGluIGVtYWtlISIK fQoKc3JjX2luc3RhbGwoKSB7CgllbWFrZSBERVNURElSPSIke0R9IiBpbnN0YWxsIHx8IGRpZQoJ ZG9kb2MgQVVUSE9SUyBDaGFuZ2VMb2cgTkVXUyBSRUFETUUgVE9ETwoJcHJlcHN0cmlwICIke0R9 Ii91c3IvYmluCn0K 150264 2008-04-19 09:18 0000 This removes EAPI=1 as Denis requested, and a little shuffling of lines. openocd-9999.ebuild text/plain IyBjb3B5cmlnaHQgMTk5OS0yMDA4IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6ICQKCmluaGVyaXQgZXV0aWxzIHN1YnZlcnNpb24KCkRFU0NSSVBUSU9OPSJPcGVuT0NEIC0g T3BlbiBPbi1DaGlwIERlYnVnZ2VyIgpIT01FUEFHRT0iaHR0cDovL29wZW5vY2QuYmVybGlvcy5k ZS93ZWIvIgpMSUNFTlNFPSJHUEwtMiIKU1JDX1VSST0iIgoKRVNWTl9SRVBPX1VSST0iaHR0cDov L3N2bi5iZXJsaW9zLmRlL3N2bnJvb3QvcmVwb3Mvb3Blbm9jZC90cnVuayIKClNMT1Q9IjAiCktF WVdPUkRTPSJ+eDg2IH5hbWQ2NCIKSVVTRT0iZnQyMjMyIHByZXN0byBsaWJmdGRpIHBhcnBvcnRf Z2l2ZWlvIgpSRVNUUklDVD0ic3RyaXAiICMgaW5jbHVkZXMgbm9uLW5hdGl2ZSBiaW5hcmllcwoK IyBsaWJmdGQyeHggaXMgdGhlIGRlZmF1bHQgYmVjYXVzZSBpdCBpcyByZXBvcnRlZCB0byB3b3Jr IGJldHRlci4KREVQRU5EPSJwcmVzdG8/ICggZGV2LWVtYmVkZGVkL2xpYmZ0ZDJ4eCApCglmdDIy MzI/ICggfHwgKCBsaWJmdGRpPyAoIGRldi1lbWJlZGRlZC9saWJmdGRpICkgZGV2LWVtYmVkZGVk L2xpYmZ0ZDJ4eCApICkiCgpwa2dfc2V0dXAoKSB7CglpZiB1c2UgbGliZnRkaSAmJiAhIHVzZSBm dDIyMzI7IHRoZW4KCQlld2FybiAiWW91IGVuYWJsZWQgbGliZnRkaSBidXQgbm90IGZ0MjIzMiEi CgkJZXdhcm4gImxpYmZ0ZGkgaXMgb25seSB1c2VkIGZvciBmdDIyMzIsIHNvIHRoaXMgaXMgbWVh bmluZ2xlc3MhIgoJZmkKfQoKc3JjX3VucGFjaygpIHsKCXN1YnZlcnNpb25fc3JjX3VucGFjawoJ Y2QgIiR7U30iCgkuL2Jvb3RzdHJhcCB8fCBkaWUgIkNhbid0IGJvb3RzdHJhcCEiCn0KCnNyY19j b21waWxlKCkgewoJZWNvbmYgXAoJCS0tZW5hYmxlLXBhcnBvcnQgXAoJCS0tZW5hYmxlLXBhcnBv cnRfcHBkZXYgXAoJCS0tZW5hYmxlLWFtdGp0YWdhY2NlbCBcCgkJLS1lbmFibGUtZXA5M3h4IFwK CQktLWVuYWJsZS1hdDkxcm05MjAwIFwKCQktLWVuYWJsZS1ndzE2MDEyIFwKCQktLWVuYWJsZS11 c2Jwcm9nIFwKCQktLWVuYWJsZS1vb2NkX3RyYWNlIFwKCQkkKHVzZV9lbmFibGUgcGFycG9ydF9n aXZlaW8pIFwKCQkkKHVzZV9lbmFibGUgcHJlc3RvIHByZXN0b19mdGQyeHgpIFwKCQkkKHVzZSBm dDIyMzIgJiYgdXNlX2VuYWJsZSBsaWJmdGRpIGZ0MjIzMl9saWJmdGRpKSBcCgkJJCh1c2UgZnQy MjMyICYmIHVzZV9lbmFibGUgIWxpYmZ0ZGkgZnQyMjMyX2Z0ZDJ4eCkgXAoJCXx8IGRpZSAiRXJy b3IgaW4gZWNvbmYhIgoJZW1ha2UgfHwgZGllICJFcnJvciBpbiBlbWFrZSEiCn0KCnNyY19pbnN0 YWxsKCkgewoJZW1ha2UgREVTVERJUj0iJHtEfSIgaW5zdGFsbCB8fCBkaWUKCWRvZG9jIEFVVEhP UlMgQ2hhbmdlTG9nIE5FV1MgUkVBRE1FIFRPRE8KCXByZXBzdHJpcCAiJHtEfSIvdXNyL2Jpbgp9 Cg==