43046 2004-02-26 17:09 0000 Colorization of builds and configures via grc 2007-12-27 21:37:18 0000 1 1 1 Unclassified Portage Development Enhancement/Feature Requests unspecified All All RESOLVED WORKSFORME P2 enhancement --- 2679 1 tim@timburrell.net dev-portage@gentoo.org masterdriverz@gentoo.org tim@timburrell.net 2004-02-26 17:09:26 0000 I really enjoy using grc to colorize my builds and configures. I made a few small modifications to the portage 2.0.50-r1 source which allows the use of 'grc' as one of the FEATURES defined in make.conf. When grc is defined as a FEATURE, emerge will colorize all configure and make's. Who needs xscreensaver. I also have a set of customized grc configuration files which allow for configure to be colorized, and which make the colorization of gcc look 'nicer'. I am not certain of the correct procedure for submitting these patches, so I have pasted them into the Additional Information field. If this is incorrect, I will be happy to post them again in another manner. Reproducible: Always Steps to Reproduce: I will glady send the patches to any location / address. For now here they are: ##################### ## Patch for ebuild.sh ##################### --- portage-grc/ebuild.sh 2004-02-26 17:43:43.675248260 -0700 +++ portage-2.0.50-r1/bin/ebuild.sh 2004-02-09 08:57:32.000000000 -0700 @@ -353,7 +353,7 @@ if [ ! -z "${CBUILD}" ]; then EXTRA_ECONF="--build=${CBUILD} ${EXTRA_ECONF}" fi - $CONFIGURE_CMD ./configure \ + ./configure \ --prefix=/usr \ --host=${CHOST} \ --mandir=/usr/share/man \ @@ -1229,16 +1229,6 @@ export USER=portage fi - # GRC support for fun colorized builds and configures! - if has grc ${FEATURES} &>/dev/null; then - if [ -f /usr/bin/grc ]; then - CONFIGURE_CMD=${CONFIGURE_CMD//grc /""} - MAKE_CMD=${MAKE_CMD//grc /""} - export CONFIGURE_CMD="grc $CONFIGURE_CMD" - export MAKE_CMD="grc $MAKE_CMD" - fi - fi - if has distcc ${FEATURES} &>/dev/null; then if [ -d /usr/lib/distcc/bin ]; then #We can enable distributed compile support @@ -1253,7 +1243,7 @@ export CXX="distcc $CXX" fi fi - + if has ccache ${FEATURES} &>/dev/null; then #We can enable compiler cache support if [ -z "${PATH/*ccache*/}" ]; then ##################### ## Patch for emake ##################### --- portage-grc/emake 2004-02-26 17:43:46.987427593 -0700 +++ portage-2.0.50-r1/bin/emake 2003-02-22 09:59:08.000000000 -0700 @@ -11,4 +11,4 @@ # /etc/make.globals here because emake is only called from an # ebuild. -$MAKE_CMD make ${MAKEOPTS} ${EXTRA_EMAKE} "$@" +make ${MAKEOPTS} ${EXTRA_EMAKE} "$@" ##################### ## Patch for grc.conf ##################### --- /etc/grc.conf 2004-02-26 17:10:26.191696895 -0700 +++ grc-1.0.6/grc.conf 2002-08-18 11:39:23.000000000 -0600 @@ -15,21 +15,13 @@ conf.traceroute # gcc command -#(^|[/\w\.]+/)g?cc\s -#conf.gcc +(^|[/\w\.]+/)g?cc\s +conf.gcc # make command -#(^|[/\w\.]+/)g?make\s? -#conf.gcc - -# gcc/make command -(sudo )?(g?cc|g?make|g?\+\+) +(^|[/\w\.]+/)g?make\s? conf.gcc -# configure command -(^|[/\w\.]+/)configure -conf.configure - # netstat command (^|[/\w\.]+/)netstat\s? conf.netstat ##################### ## Patch for conf.gcc in /usr/share/grc/ ##################### --- /usr/share/grc/conf.gcc 2004-02-26 16:51:36.431956976 -0700 +++ grc-1.0.6/conf.gcc 1999-11-22 12:52:08.000000000 -0700 @@ -1,10 +1,10 @@ # -regexp=\b(g?cc|[gc]\+\+|g?as|ld)\b -colours=white bold -count=once +regexp=\bgcc\b +colours=yellow +count=more ......... # -regexp=^\S*: +regexp=^.*?: colours=red count=once ......... @@ -12,51 +12,22 @@ regexp=\`\w+\' colours=green ......... -# compilation method modifiers -regexp=\s\-(O\d?|f\S+|pthread|g\S*|c|W\S,\S+)\b -colours=yellow -......... -# source file name -regexp=\s[^-]\S*\.(c|C|cc|c[x\+p]{2,2}|m|o|a|s)\b +# -O +regexp=\-O\d colours=green ......... # -o -regexp=\-o\s+\S+ -colours=green bold -count=once -......... -# -W... or -w -regexp=\s\-(W\S[^,]\S*|w\b) -colours=blue -......... -# -D... -regexp=\s\-D\S+ -colours=blue bold -......... -# -I... -regexp=\s\-I[^- ]\S* -colours=cyan -......... -# -I- -regexp=\s\-I\- -colours=cyan bold -......... -# -L... -regexp=\s\-L\S* -colours=magenta -......... -# -l... -regexp=\s\-l\S+ -colours=magenta bold +regexp=\-o\s.+\b +colours=yellow ......... # warning and error won't work, unless you redirect also # stderr to grcat # # warning -regexp=[Ww]arning[:\b] -colours=yellow bold +regexp=warning +colours=yellow ......... # error -regexp=[Ee]rror[:\b] +regexp=error colours=red blink count=stop ##################### ## New file /usr/share/grc/conf.configure ##################### # cache functions regexp=\b(loading|updating|creating) cache\b colours=yellow bold ......... # checking regexp=\bchecking\s*(for|if|whether|command|how|that)?(\s*to)?\b colours=yellow ......... # result is complex regexp=\.\.\. .*$ colours=cyan ......... # check succeeded regexp=\.\.\.( \(cached\))? yes$ colours=blue bold ......... # check did not succeed regexp=\.\.\.( \(cached\))? no$ colours=magenta ......... # ... should be normal regexp=\.\.\. colours=default ......... # creating stuff regexp=\bcreating\b colours=green tim@timburrell.net 2004-02-26 17:11:39 0000 Created an attachment (id=26436) Patch for ebuild.sh to allow colorization of builds and configures via grc tim@timburrell.net 2004-02-26 17:12:17 0000 Created an attachment (id=26437) Patch to emake which alows colorization via grc tim@timburrell.net 2004-02-26 17:13:13 0000 Created an attachment (id=26438) Patch to grc.conf which allows makes AND configures to be colorized tim@timburrell.net 2004-02-26 17:14:13 0000 Created an attachment (id=26439) Patch to the grc gcc colorization which makes colors 'nicer'. File is located in /usr/share/grc/ vapier@gentoo.org 2004-02-26 17:15:01 0000 i'd just as soon mark this a dup of Bug 2679 but i'd imagine someone might throw a stink tim@timburrell.net 2004-02-26 17:15:10 0000 Created an attachment (id=26440) additional grc configure file which specifies color mapping for ./configures tim@timburrell.net 2004-02-26 17:19:49 0000 grc is much better than colorgcc. Not only does it color gcc builds, but anything, including configures. Which is much nicer. grc was, in fact, inspired by the likes of colorgcc. Apologies for the nasty cut 'n paste. I didn't know how the system worked. stubenschrott@gmx.net 2004-08-23 11:39:45 0000 Yes, grc is much more advanced than colorgcc, so I wouldn't say it's a duplicate of 2679. And thanks for the ./configure color script. If we now could only have this for portage apps as well, not only for self compiled apps. Hopefully, this patch gets accepted soon. tim@timburrell.net 2004-08-23 12:03:08 0000 I actually posted patches for portage that enabled colorized emerges (including configures and makes), but no one did anything with them. Of course the patches are out of date now, since it's been so long. It took me a while to create those patches since I had to partially figure out how portage was written, but I would think someone on the portage team could have done it in 15 minutes. All my emerge's were nicely colorized until the next update of portage came down the line and blew away all my changes. Now I'm back to black 'n white. :o(. I don't understand why this is such a low priority for them!? Especially when compiling a long build (kde), it's so much nicer (and cooler!) to have the output colorized. I also think it would be a little bit of a selling feature for the distro. Imagine your debian buddy comes over and sees you installing a new app. He'd be like, WHOA SWEET your gcc output is in color! I don't think a lot of people know about grc. Actually come to think of it the Gentoo team itself hasn't been very receptive to input. I've created ebuilds, submitted patches, and all to almost no avail. I know other people have expressed similar opinions as well. It's frustrating since Gentoo is such a good distro. stubenschrott@gmx.net 2004-08-23 21:09:30 0000 @Tim: if you don't follow the forums (I normally don't do either, it was pure luck), look at this brand new thread: http://forums.gentoo.org/viewtopic.php?t=213596 it shows how to use grc in the latest versions of portage. To your complaint about gentoo devs not accepting patches/listening to users: I heard this complaint from others as well and hopefully it's not that bad in future, that people get angry about gentoo. Because Gentoo is still by far the best distro I know, but well, things could always be even better :) I understand that often accepting/testing patches is a lot of work, but in this case it's actually just 10 lines in 2 core portage files (the conf.{gcc,configure} files are nice, but not essential, because they can be user created, without being overwritten after reemerging portage) which need to be changed. ferringb@gmail.com 2004-08-24 00:15:15 0000 "http://forums.gentoo.org/viewtopic.php?t=213596 it shows how to use grc in the latest versions of portage." I started that thread due to tim generating traffic on this bug; keep in mind we have 400+ portage bugs. It's *very* easy to miss the needle in the haystack. It's not intentional, but a lot of the minor fixes/features have plain been overlooked/ignored/dropped unless they were utterly critical. Generating noise on a bug (as you did, and lead to that thread) is a good way to get people to look at it; note that noise != flaming (although flaming is more entertaining):) Re: accepting patches/listening to users- You're not the only one who has suffered patch-rot in bugs.g.o; I have around a month of portage modifications sitting currently, although now it's sitting since it should be included post-.51. May not be visible, but the general consensus seems to be portage development is starting to accelerate a bit. Additionally, bantering around the 'lots of open bugs' excuse... well, we have lots of open bugs, most quite a bit more critical then adding color support (broken behaviour fex). Meanwhile, back to the bug. I'm not much for adding this into portage- I'd rather the bashrc trick be used, although if users find it useful, I spose I could slip it in. This would be down the line; as is, the bashrc trick works for everything but when the user has PORT_LOGDIR enabled, although that issue should go away in the near future. tim@timburrell.net 2004-08-24 10:21:39 0000 Thanks for the response :o). The bashrc trick is great, although the only problem I see with it is that it doesn't appear to work with colorizing the ./configure output (which is not only cool, but really helpful), as you can easily pick out the "no" and "yes" responses, to make sure you've got all your USE vars set correctly. Also if you're writing your own ebuilds it can help to make sure you've got your dependencies correct. At any rate if there's a way configure scripts can work using the bashrc trick, I'm all for it! I couldn't get it to work because it runs as `./configure` (as opposed to just `configure`) which I guess is different, although I didn't try a lot of different things so maybe it is possible after all? I know you're not totally for putting it directly into portage, but if the bashrc trick doesn't work with configure, I would still like to see it in there. And I think if it's implemented as an optional FEATURE (in make.conf) much like distcc or the other FEATURE's there's no reason why it has to be problematic. For people who don't like it they can just leave that FEATURE out. Just my .02 dollars. tim@timburrell.net 2004-08-24 10:29:44 0000 Ahh, I just noticed that there has been some development on colorizing ./configure as well using an alias. It appears to me though that this solution is somewhat sub-optimal, as seen by problems reported by MaxAuthority on the forum thread. My vote is to still include this in portage itself as, if done correctly there, it will work 100%. On the other hand, if the bugs get ironed out with the bashrc/alias trick I'll be more than happy to accept that as well. vapier@gentoo.org 2004-08-25 20:35:28 0000 added some of these tweaks to the grc ebuild and e-mailed them upstream stubenschrott@gmx.net 2004-10-23 15:07:31 0000 i have used this combination of grc and portage for 2 months now, and just want to confirm, that i didn't have any problems with the combination of setting: alias "./configure"="/usr/bin/grc -es ./configure" in /etc/portage/bashrc and /usr/bin/grc -es make ${MAKEOPTS} ${EXTRA_EMAKE} "$@" in /usr/lib/portage/bin/emake . The first one can be done with the current portage system, but I really opt for adding something like a MAKECMD variable in /etc/make.conf, so that you don't need to patch the emake file every time you update portage. As I said before, I used this combination for 2 months with dozens of ebuilds now, without any problems. tim@timburrell.net 2004-11-02 08:48:19 0000 I can confirm that this is the only method that works so far. There is a previously mentioned method that came from the forums which entirely uses alias's and various tricks in /etc/portage/bashrc. That method DOES NOT WORK in all cases. It would be nice to see the above method implemented with a flag added in make.conf to allow users to specify whether or not they want colorization. I know that portage developers have been leary of adopting any sort of colorization patches, however I emplore them to test the above method. It does work, and does not produce errors. dirtyepic@gentoo.org 2005-04-06 19:16:06 0000 this is cool. especially useful for spying warnings that would otherwise slip by on a large build. i just wanted to chime in and say that this: declare -xf make configure make() { /usr/bin/grc -es make "$@";} ./configure() { /usr/bin/grc -es ./configure "$@"; } ends up giving errors like this (tar-1.15.1): checking whether make sets $(MAKE)... ./configure: line 1643: ac_maketemp=make: command not found no moving make to /usr/lib/portage/bin/emake like mentioned above allows it to give the correct response. jstubbs@gentoo.org 2005-07-28 07:25:10 0000 Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) tim@timburrell.net 2006-07-05 13:43:44 0000 Any chance we could revisit this? I know that some people are against the colorizing of gcc in portage because of the potential for additional problems. As far as I can tell the only problems come into play when employing aliases or other tricks (usually to get ./configure's colorized as well). I've been testing colorizing builds by changing /usr/lib/portage/bin/emake from: exec ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" to: exec grc ${MAKE:-make} ${MAKEOPTS} ${EXTRA_EMAKE} "$@" I've never had an ebuild die or any other problem occur as a reslut of this. And if you ask me it greatly enhances portage's coolness factor. It's such a simple thing, and has the potential to bring so much joy to so many people :). I think it should be considered. At least for colorizing gcc. Perhaps configure coloring can come later, until a better method can be found). genone@gentoo.org 2006-07-05 18:12:13 0000 Uhm, can't you just set $MAKE to grc (or a wrapper script that calls the right thing) and be done? I'd really want to avoid any special support for 3rd party tools when it's not necessary. tim@timburrell.net 2006-07-06 03:37:45 0000 I hadn't thought of that... I always assumed that portage was using that variable internally. I tested setting $MAKE to "grc make" and it definitely works, however I still think it would be cool to add official support for it. If it were a FEATURE available in make.conf I think a lot of people would use it. And it's not like it's a difficult thing to add. Plus, there's also support for tons of third party tools, like ccache, distcc, etc. Another thing that would be nice is a similar way to colorize the configure scripts with grc. Is there a variable similar to $MAKE that portage uses? tim@timburrell.net 2006-07-06 03:47:14 0000 I revisted ebuild.sh and noted that it'll take changing 4 or 5 lines to add support for colorizing configures but it doesn't look difficult. If I were to make a proper patch with the necessary changes (add a FEATURE in make.conf and conditionally use grc to colorize both configures and compiles) would this be something that the portage team would consider including? blubb@gentoo.org 2006-07-06 04:14:25 0000 (In reply to comment #21) > Plus, there's also support for tons of third party tools, like ccache, distcc, > etc. Those add essential functionality which it is really worth supporting them. I somehow lack to see how colorized output is going to improve anything. You say that if there was a FEATURE for it, lots of people would use it. I doubt that: Who looks at emerge's output anyway? Beside that, this bug is really old and still has noone on CC, which usually means there aren't a lot of people who really care about it. tim@timburrell.net 2006-07-06 04:28:05 0000 Hmmm... point taken :). I suspect that most people aren't aware you can colorize the gcc output. I know it doesn't add significant functionality. I just think it's cool, and very much in the spirit of gentoo itself. When I emerge packages I always have the output up on a second monitor. And I know it's not just me that's interested. There's a few people that replied to this thread, and there was some other people interested on the forum post. I also remember seeing more than one bug opened regarding colorgcc (which btw is not a good way to go -- grc is much better). It's such a small change, like 5 or 6 lines of code probably, and although it's only cosmetic, you have to admit color is generally much cooler than black and white :). It's not like it adds any real complexity to portage, and if it's something that people can turn on and off easily why not? genone@gentoo.org 2006-07-06 05:55:33 0000 (In reply to comment #21) > Plus, there's also support for tons of third party tools, like ccache, distcc, > etc. Well, this "support" deals mainly with applying permissions and actually I'd prefer to move that out into the gcc wrapper (as IMO this is a general toolchain thing), see bug #128810 As for configure, might be useful to come up with a way to specify wrappers for that too to allow this and move confcache support out of portage (if possible). I'm quite reluctant about adding more FEATURES (that var is bloated enough already IMHO) if there are other ways to get things done. Closing as setting $MAKE solves it, adding support for $CONFIGURE would be another bug. tim@timburrell.net 2006-07-06 06:02:43 0000 Okay this makes sense to me. Adding the ability to have a wrapper for configure commands would solve my problem too. I'll open a new bug for $CONFIGURE. blubb@gentoo.org 2007-01-31 23:53:59 0000 *** Bug 139418 has been marked as a duplicate of this bug. *** czeryna@gmail.com 2007-12-24 21:24:23 0000 maybe i write this in wrong topic ? but i have this bug: [root]::[dupoliz]/var/log# traceroute wp.pl 22:20 Traceback (most recent call last): File "/usr/bin/grc", line 110, in <module> os.execvp(args[0], args) File "/usr/lib/python2.5/os.py", line 354, in execvp _execvpe(file, args) File "/usr/lib/python2.5/os.py", line 380, in _execvpe func(file, *argrest) OSError: [Errno 2] No such file or directory genone@gentoo.org 2007-12-27 21:37:18 0000 definitely the wrong place. 26436 2004-02-26 17:11 0000 Patch for ebuild.sh to allow colorization of builds and configures via grc ebuild.sh.patch text/plain LS0tIHBvcnRhZ2UtZ3JjL2VidWlsZC5zaAkyMDA0LTAyLTI2IDE3OjQzOjQzLjY3NTI0ODI2MCAt MDcwMAorKysgcG9ydGFnZS0yLjAuNTAtcjEvYmluL2VidWlsZC5zaAkyMDA0LTAyLTA5IDA4OjU3 OjMyLjAwMDAwMDAwMCAtMDcwMApAQCAtMzUzLDcgKzM1Myw3IEBACiAJCWlmIFsgISAteiAiJHtD QlVJTER9IiBdOyB0aGVuCiAJCQlFWFRSQV9FQ09ORj0iLS1idWlsZD0ke0NCVUlMRH0gJHtFWFRS QV9FQ09ORn0iCiAJCWZpCi0JCSRDT05GSUdVUkVfQ01EIC4vY29uZmlndXJlIFwKKwkJLi9jb25m aWd1cmUgXAogCQkgICAgLS1wcmVmaXg9L3VzciBcCiAJCSAgICAtLWhvc3Q9JHtDSE9TVH0gXAog CQkgICAgLS1tYW5kaXI9L3Vzci9zaGFyZS9tYW4gXApAQCAtMTIyOSwxNiArMTIyOSw2IEBACiAJ CWV4cG9ydCBVU0VSPXBvcnRhZ2UKIAlmaQogCi0JIyBHUkMgc3VwcG9ydCBmb3IgZnVuIGNvbG9y aXplZCBidWlsZHMgYW5kIGNvbmZpZ3VyZXMhCi0JaWYgaGFzIGdyYyAke0ZFQVRVUkVTfSAmPi9k ZXYvbnVsbDsgdGhlbgotCQlpZiBbIC1mIC91c3IvYmluL2dyYyBdOyB0aGVuCi0JCQlDT05GSUdV UkVfQ01EPSR7Q09ORklHVVJFX0NNRC8vZ3JjIC8iIn0KLQkJCU1BS0VfQ01EPSR7TUFLRV9DTUQv L2dyYyAvIiJ9Ci0JCQlleHBvcnQgQ09ORklHVVJFX0NNRD0iZ3JjICRDT05GSUdVUkVfQ01EIgot CQkJZXhwb3J0IE1BS0VfQ01EPSJncmMgJE1BS0VfQ01EIgotCQlmaQotCWZpCi0JCQogCWlmIGhh cyBkaXN0Y2MgJHtGRUFUVVJFU30gJj4vZGV2L251bGw7IHRoZW4KIAkJaWYgWyAtZCAvdXNyL2xp Yi9kaXN0Y2MvYmluIF07IHRoZW4KIAkJCSNXZSBjYW4gZW5hYmxlIGRpc3RyaWJ1dGVkIGNvbXBp bGUgc3VwcG9ydApAQCAtMTI1Myw3ICsxMjQzLDcgQEAKIAkJCWV4cG9ydCBDWFg9ImRpc3RjYyAk Q1hYIgogCQlmaQogCWZpCi0JCisKIAlpZiBoYXMgY2NhY2hlICR7RkVBVFVSRVN9ICY+L2Rldi9u dWxsOyB0aGVuCiAJCSNXZSBjYW4gZW5hYmxlIGNvbXBpbGVyIGNhY2hlIHN1cHBvcnQKIAkJaWYg WyAteiAiJHtQQVRILypjY2FjaGUqL30iIF07IHRoZW4K 26437 2004-02-26 17:12 0000 Patch to emake which alows colorization via grc emake.patch text/plain LS0tIHBvcnRhZ2UtZ3JjL2VtYWtlCTIwMDQtMDItMjYgMTc6NDM6NDYuOTg3NDI3NTkzIC0wNzAw CisrKyBwb3J0YWdlLTIuMC41MC1yMS9iaW4vZW1ha2UJMjAwMy0wMi0yMiAwOTo1OTowOC4wMDAw MDAwMDAgLTA3MDAKQEAgLTExLDQgKzExLDQgQEAKICMgICAgICAgIC9ldGMvbWFrZS5nbG9iYWxz IGhlcmUgYmVjYXVzZSBlbWFrZSBpcyBvbmx5IGNhbGxlZCBmcm9tIGFuCiAjICAgICAgICBlYnVp bGQuCiAKLSRNQUtFX0NNRCBtYWtlICR7TUFLRU9QVFN9ICR7RVhUUkFfRU1BS0V9ICIkQCIKK21h a2UgJHtNQUtFT1BUU30gJHtFWFRSQV9FTUFLRX0gIiRAIgo= 26438 2004-02-26 17:13 0000 Patch to grc.conf which allows makes AND configures to be colorized grc.conf.patch text/plain LS0tIC9ldGMvZ3JjLmNvbmYJMjAwNC0wMi0yNiAxNzoxMDoyNi4xOTE2OTY4OTUgLTA3MDAKKysr IGdyYy0xLjAuNi9ncmMuY29uZgkyMDAyLTA4LTE4IDExOjM5OjIzLjAwMDAwMDAwMCAtMDYwMApA QCAtMTUsMjEgKzE1LDEzIEBACiBjb25mLnRyYWNlcm91dGUKIAogIyBnY2MgY29tbWFuZAotIyhe fFsvXHdcLl0rLylnP2NjXHMKLSNjb25mLmdjYworKF58Wy9cd1wuXSsvKWc/Y2NccworY29uZi5n Y2MKIAogIyBtYWtlIGNvbW1hbmQKLSMoXnxbL1x3XC5dKy8pZz9tYWtlXHM/Ci0jY29uZi5nY2MK LQotIyBnY2MvbWFrZSBjb21tYW5kCi0oc3VkbyApPyhnP2NjfGc/bWFrZXxnP1wrXCspCisoXnxb L1x3XC5dKy8pZz9tYWtlXHM/CiBjb25mLmdjYwogCi0jIGNvbmZpZ3VyZSBjb21tYW5kCi0oXnxb L1x3XC5dKy8pY29uZmlndXJlCi1jb25mLmNvbmZpZ3VyZQotCiAjIG5ldHN0YXQgY29tbWFuZAog KF58Wy9cd1wuXSsvKW5ldHN0YXRccz8KIGNvbmYubmV0c3RhdAo= 26439 2004-02-26 17:14 0000 Patch to the grc gcc colorization which makes colors 'nicer'. File is located in /usr/share/grc/ conf.gcc.patch text/plain LS0tIC91c3Ivc2hhcmUvZ3JjL2NvbmYuZ2NjCTIwMDQtMDItMjYgMTY6NTE6MzYuNDMxOTU2OTc2 IC0wNzAwCisrKyBncmMtMS4wLjYvY29uZi5nY2MJMTk5OS0xMS0yMiAxMjo1MjowOC4wMDAwMDAw MDAgLTA3MDAKQEAgLTEsMTAgKzEsMTAgQEAKICMgCi1yZWdleHA9XGIoZz9jY3xbZ2NdXCtcK3xn P2FzfGxkKVxiCi1jb2xvdXJzPXdoaXRlIGJvbGQKLWNvdW50PW9uY2UKK3JlZ2V4cD1cYmdjY1xi Citjb2xvdXJzPXllbGxvdworY291bnQ9bW9yZQogLi4uLi4uLi4uCiAjIAotcmVnZXhwPV5cUyo6 CityZWdleHA9Xi4qPzoKIGNvbG91cnM9cmVkCiBjb3VudD1vbmNlCiAuLi4uLi4uLi4KQEAgLTEy LDUxICsxMiwyMiBAQAogcmVnZXhwPVxgXHcrXCcKIGNvbG91cnM9Z3JlZW4KIC4uLi4uLi4uLgot IyBjb21waWxhdGlvbiBtZXRob2QgbW9kaWZpZXJzCi1yZWdleHA9XHNcLShPXGQ/fGZcUyt8cHRo cmVhZHxnXFMqfGN8V1xTLFxTKylcYgotY29sb3Vycz15ZWxsb3cKLS4uLi4uLi4uLgotIyBzb3Vy Y2UgZmlsZSBuYW1lCi1yZWdleHA9XHNbXi1dXFMqXC4oY3xDfGNjfGNbeFwrcF17MiwyfXxtfG98 YXxzKVxiCisjIC1PCityZWdleHA9XC1PXGQgCiBjb2xvdXJzPWdyZWVuCiAuLi4uLi4uLi4KICMg LW8KLXJlZ2V4cD1cLW9ccytcUysKLWNvbG91cnM9Z3JlZW4gYm9sZAotY291bnQ9b25jZQotLi4u Li4uLi4uCi0jIC1XLi4uIG9yIC13Ci1yZWdleHA9XHNcLShXXFNbXixdXFMqfHdcYikKLWNvbG91 cnM9Ymx1ZQotLi4uLi4uLi4uCi0jIC1ELi4uCi1yZWdleHA9XHNcLURcUysKLWNvbG91cnM9Ymx1 ZSBib2xkCi0uLi4uLi4uLi4KLSMgLUkuLi4KLXJlZ2V4cD1cc1wtSVteLSBdXFMqCi1jb2xvdXJz PWN5YW4KLS4uLi4uLi4uLgotIyAtSS0KLXJlZ2V4cD1cc1wtSVwtCi1jb2xvdXJzPWN5YW4gYm9s ZAotLi4uLi4uLi4uCi0jIC1MLi4uCi1yZWdleHA9XHNcLUxcUyoKLWNvbG91cnM9bWFnZW50YQot Li4uLi4uLi4uCi0jIC1sLi4uCi1yZWdleHA9XHNcLWxcUysKLWNvbG91cnM9bWFnZW50YSBib2xk CityZWdleHA9XC1vXHMuK1xiCitjb2xvdXJzPXllbGxvdwogLi4uLi4uLi4uCiAjIHdhcm5pbmcg YW5kIGVycm9yIHdvbid0IHdvcmssIHVubGVzcyB5b3UgcmVkaXJlY3QgYWxzbwogIyBzdGRlcnIg dG8gZ3JjYXQgCiAjCiAjIHdhcm5pbmcKLXJlZ2V4cD1bV3ddYXJuaW5nWzpcYl0KLWNvbG91cnM9 eWVsbG93IGJvbGQKK3JlZ2V4cD13YXJuaW5nCitjb2xvdXJzPXllbGxvdwogLi4uLi4uLi4uCiAj IGVycm9yCi1yZWdleHA9W0VlXXJyb3JbOlxiXQorcmVnZXhwPWVycm9yCiBjb2xvdXJzPXJlZCBi bGluawogY291bnQ9c3RvcAo= 26440 2004-02-26 17:15 0000 additional grc configure file which specifies color mapping for ./configures conf.configure text/plain IyBjYWNoZSBmdW5jdGlvbnMKcmVnZXhwPVxiKGxvYWRpbmd8dXBkYXRpbmd8Y3JlYXRpbmcpIGNh Y2hlXGIKY29sb3Vycz15ZWxsb3cgYm9sZAouLi4uLi4uLi4KIyBjaGVja2luZwpyZWdleHA9XGJj aGVja2luZ1xzKihmb3J8aWZ8d2hldGhlcnxjb21tYW5kfGhvd3x0aGF0KT8oXHMqdG8pP1xiCmNv bG91cnM9eWVsbG93Ci4uLi4uLi4uLgojIHJlc3VsdCBpcyBjb21wbGV4CnJlZ2V4cD1cLlwuXC4g LiokCmNvbG91cnM9Y3lhbgouLi4uLi4uLi4KIyBjaGVjayBzdWNjZWVkZWQKcmVnZXhwPVwuXC5c LiggXChjYWNoZWRcKSk/IHllcyQKY29sb3Vycz1ibHVlIGJvbGQKLi4uLi4uLi4uCiMgY2hlY2sg ZGlkIG5vdCBzdWNjZWVkCnJlZ2V4cD1cLlwuXC4oIFwoY2FjaGVkXCkpPyBubyQKY29sb3Vycz1t YWdlbnRhCi4uLi4uLi4uLgojIC4uLiBzaG91bGQgYmUgbm9ybWFsCnJlZ2V4cD1cLlwuXC4KY29s b3Vycz1kZWZhdWx0Ci4uLi4uLi4uLgojIGNyZWF0aW5nIHN0dWZmCnJlZ2V4cD1cYmNyZWF0aW5n XGIKY29sb3Vycz1ncmVlbgo=