public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] rgb file specification
@ 2008-01-19 17:43 Ferris McCormick
  2008-01-19 18:24 ` Harald van Dijk
  2008-01-19 18:30 ` [gentoo-dev] " Steve Long
  0 siblings, 2 replies; 4+ messages in thread
From: Ferris McCormick @ 2008-01-19 17:43 UTC (permalink / raw
  To: gentoo-dev

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 1207 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is random musing based based on perhaps my own problems.
  I need a local color.file to see well what I have going on, and
current xorg ignores that.  Thus, at every build, there is in
oscolor.c a "constant" I must change from 1 to 0.

This is frustrating, especially since the fix is completely trivial
on a USE or configure flag. As best as I can tell, xorg people have
ignored my request, although it it is real.

I am asking if anyone cares if one can give a local rgb file or not,
or if I am stuck with "fixing" every update so that it will take mine
so that I can see it.  Perhaps no one cares but me.  Well, so be it,
but it slows down xorg-server testing (or upgrading) for me because I
have to keep changing that file by hand.  I'm really tired of
fixing this trivial thing by hand.

Regards,
  
- -- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel, Userrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHkjbaQa6M3+I///cRAm3NAJ4oWcvMcAYSn+MxAg+RBNiRAC6+AACghTHr
QvlQV65GYVva2FHttZmnyQU=
=HzFW
-----END PGP SIGNATURE-----
éí¢‡^¾X¬¶È\x1ežÚ(¢¸&j)bž	b²

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gentoo-dev] rgb file specification
  2008-01-19 17:43 [gentoo-dev] rgb file specification Ferris McCormick
@ 2008-01-19 18:24 ` Harald van Dijk
  2008-01-19 18:30 ` [gentoo-dev] " Steve Long
  1 sibling, 0 replies; 4+ messages in thread
From: Harald van Dijk @ 2008-01-19 18:24 UTC (permalink / raw
  To: gentoo-dev

On Sat, Jan 19, 2008 at 05:43:18PM +0000, Ferris McCormick wrote:
> This is random musing based based on perhaps my own problems.
>   I need a local color.file to see well what I have going on, and
> current xorg ignores that.  Thus, at every build, there is in
> oscolor.c a "constant" I must change from 1 to 0.

While I don't have any need for your specific change, I do have the same
problem with some other unrelated patches for unrelated packages. Instead
of manually changing the code for every version bump, you can set up your
bashrc to define a post_src_unpack function, which checks if
${CATEGORY}/${PN} == x11-base/xorg-server, and if so, applies the patch.
solar's old bashrc which does this is still found at
<http://dev.gentoo.org/~solar/bashrc>, and I've put up the function as
I'm using it at <http://dev.gentoo.org/~truedfx/bashrc>.
-- 
gentoo-dev@lists.gentoo.org mailing list



^ permalink raw reply	[flat|nested] 4+ messages in thread

* [gentoo-dev]  Re: rgb file specification
  2008-01-19 17:43 [gentoo-dev] rgb file specification Ferris McCormick
  2008-01-19 18:24 ` Harald van Dijk
@ 2008-01-19 18:30 ` Steve Long
  2008-01-20 12:39   ` Markus Ullmann
  1 sibling, 1 reply; 4+ messages in thread
From: Steve Long @ 2008-01-19 18:30 UTC (permalink / raw
  To: gentoo-dev

Ferris McCormick wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This is random musing based based on perhaps my own problems.
>   I need a local color.file to see well what I have going on, and
> current xorg ignores that.  Thus, at every build, there is in
> oscolor.c a "constant" I must change from 1 to 0.
>
I don't understand why this is an issue for "every build"; surely a patched
ebuild in local overlay is trivial? It's only a quick sed -i line added.

> This is frustrating, especially since the fix is completely trivial
> on a USE or configure flag. As best as I can tell, xorg people have
> ignored my request, although it it is real.
> 
> I am asking if anyone cares if one can give a local rgb file or not,
> or if I am stuck with "fixing" every update so that it will take mine
> so that I can see it.  Perhaps no one cares but me.  Well, so be it,
> but it slows down xorg-server testing (or upgrading) for me because I
> have to keep changing that file by hand.  I'm really tired of
> fixing this trivial thing by hand.
> 
Fair enough for upgrades, it might be worth adding to the ebuild; I
certainly agree user control of rgb is worth having.


-- 
gentoo-dev@lists.gentoo.org mailing list



^ permalink raw reply	[flat|nested] 4+ messages in thread

* [gentoo-dev]  Re: rgb file specification
  2008-01-19 18:30 ` [gentoo-dev] " Steve Long
@ 2008-01-20 12:39   ` Markus Ullmann
  0 siblings, 0 replies; 4+ messages in thread
From: Markus Ullmann @ 2008-01-20 12:39 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

Steve Long schrieb:
> Ferris McCormick wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> This is random musing based based on perhaps my own problems.
>>   I need a local color.file to see well what I have going on, and
>> current xorg ignores that.  Thus, at every build, there is in
>> oscolor.c a "constant" I must change from 1 to 0.
>>
> I don't understand why this is an issue for "every build"; surely a patched
> ebuild in local overlay is trivial? It's only a quick sed -i line added.
> 

And with the gentoo-x86 follow script grobian uses for prefix syncing, 
it should even be doable to always have an up-to-date current ebuild.

Greetz
-Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-01-20 12:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-19 17:43 [gentoo-dev] rgb file specification Ferris McCormick
2008-01-19 18:24 ` Harald van Dijk
2008-01-19 18:30 ` [gentoo-dev] " Steve Long
2008-01-20 12:39   ` Markus Ullmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox