Re: [gentoo-dev] Modular X plans

2005-08-12 Thread Ferris McCormick
On Thu, 2005-08-11 at 23:29 +, Ferris McCormick wrote:

 

 On Thu, 11 Aug 2005, Donnie Berkholz wrote:
 
   --[PinePGP]--[begin]--
   Ferris McCormick wrote:
I'm happy with libGL; I just reverted the ebuild to be as it started,
but to define a sparc-specific set of dri drivers. All my problems came
from my mistaken belief that mesa would still build cleanly using the
sparc assembly code.  I thought about going ahead and installing the
drivers themselves while I was at it, but decided to do other things
first.  If you like, I'll take a shot at it tomorrow, since I've been
playing with mesa and its ebuild anyway.
 
   I'm thinking something really basic like:
 
   EXEDESTTREE=/usr/lib/xorg/modules/dri
   find $S -name '*_dri.so' | xargs doexe
 
   Does that work?
 
 
 It should.  I'll verify tomorrow.
 
Yes, it works fine.  I've gone ahead and committed it in the following
form (in src_install):
=
##
# Install the actual drivers --- 'make install' doesn't install them
# anywhere.
dodir /usr/$(get_libdir)/xorg/modules/dri
exeinto /usr/$(get_libdir)/xorg/modules/dri
einfo Installing drivers to ${EXEDESTTREE}.
find ${S}/lib -name '*_dri.so' | xargs doexe
=

By the way, in local testing, I have noticed that mesa builds fine with
a parallel make, and locally using

 src_compile() {
make ${CONFIG} ${MAKEOPTS} || die Build failed
}
===
is a timesaver.  I don't know if this works generally, but I have never
had any trouble making libGL in parallel when building it by hand.

Regards,
-- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Devrel)


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Modular X plans

2005-08-12 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
| is a timesaver.  I don't know if this works generally, but I have never
| had any trouble making libGL in parallel when building it by hand.

Alright, I've switched to emake and we'll see how it goes.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC/NymXVaO67S1rtsRAnExAKC6ep/gwYPAPQyT1UMoPicdBXiriACgtdST
it42aEA5W38hO8Uay0f5/Bg=
=0CcT
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
| Hm, why not just forget the transition, stick a warning telling people
| to add
|
| ModulesPath /usr/lib/modules
| ModulesPath /usr/lib/xorg/modules

Needing to set ModulePath at all in a standard installation is broken.
This shouldn't need to be in a configuration file; none of the tools I'm
aware of generate files with ModulePath by default, and it really
doesn't make sense to.

xorg.conf is difficult and user-unfriendly enough to set up already
without adding more Gentoo-only requirements to it.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+um6XVaO67S1rtsRAhOBAJwMfozXGAjqqS7K9G4TEXbfMEQS+wCfcruP
VDFJZWfMCT5r3zE/N9b6QUg=
=Xs0h
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Georgi Georgiev
maillog: 10/08/2005-23:01:30(-0700): Donnie Berkholz types
 Georgi Georgiev wrote:
 | Hm, why not just forget the transition, stick a warning telling people
 | to add
 |
 | ModulesPath /usr/lib/modules
 | ModulesPath /usr/lib/xorg/modules
 
 Needing to set ModulePath at all in a standard installation is broken.
 This shouldn't need to be in a configuration file; none of the tools I'm
 aware of generate files with ModulePath by default, and it really
 doesn't make sense to.
 
 xorg.conf is difficult and user-unfriendly enough to set up already
 without adding more Gentoo-only requirements to it.

Mmmm, xorgcfg does generate an xorg.conf with ModulePath in it. That's
why I had it in mine in the first place. Anyway, I agree with your other
points.

maillog: 10/08/2005-22:08:36(-0700): Donnie Berkholz types
 Georgi Georgiev wrote:
 | What about new revisions of the monolithic xorg that will install in
 | /usr/lib/xorg/modules followed by new revisions of all packages like
 | opengl-update, nvidia, ati-whatever, that will depend on the newer xorg
 | release?
 
 We still need to deal with the transition either way. We can't just
 ignore everything that's installed in /usr/lib/modules when we upgrade xorg.

I did not really understand the above. What I had in mind was making the
transition now, rather than later. This would avoid the need for
parallel ebuilds of all packages and if the appropriate packages block
on appropriate revisions, it shouldn't cause much hassle. Unlike the
/usr/X11R6 - /usr move, there are only a few packages that install x
modules (does anyone know how many packages these are?) so upgrading
said packages shouldn't be much of a hassle. I never thought about
ignoring /usr/lib/modules.

-- 
-*   Georgi Georgiev   -*  Then you admit confirming not denying  -*
*-[EMAIL PROTECTED]*- you ever said that? NO! ... I mean Yes!*-
-*  +81(90)2877-8845   -* WHAT? I'll put `maybe.' -- Bloom County   -*


pgpUUcZ2drI5K.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
| maillog: 10/08/2005-23:01:30(-0700): Donnie Berkholz types
|Needing to set ModulePath at all in a standard installation is broken.
|This shouldn't need to be in a configuration file; none of the tools I'm
|aware of generate files with ModulePath by default, and it really
|doesn't make sense to.
|
|xorg.conf is difficult and user-unfriendly enough to set up already
|without adding more Gentoo-only requirements to it.
|
|
| Mmmm, xorgcfg does generate an xorg.conf with ModulePath in it. That's
| why I had it in mine in the first place. Anyway, I agree with your other
| points.

OK, so one of them does. And I still consider that broken behavior.

|We still need to deal with the transition either way. We can't just
|ignore everything that's installed in /usr/lib/modules when we upgrade
xorg.
|
|
| I did not really understand the above. What I had in mind was making the
| transition now, rather than later. This would avoid the need for
| parallel ebuilds of all packages and if the appropriate packages block
| on appropriate revisions, it shouldn't cause much hassle. Unlike the
| /usr/X11R6 - /usr move, there are only a few packages that install x
| modules (does anyone know how many packages these are?) so upgrading
| said packages shouldn't be much of a hassle. I never thought about
| ignoring /usr/lib/modules.

There are a couple of reasons this isn't very interesting to me.

1) It involves work on the monolithic package, which I'd rather not
spend any more time on.

2) Keeping all changes in one big chunk makes for an easier transition
than spreading them out, because users only have to figure things out
once. So sticking it in with the modular move makes sense to me.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+vhmXVaO67S1rtsRAvv9AKDqeISd638V/UXDby4l9jkue/tN/ACgs2oY
gCQwlInZ2m7zfOQfcovvZxk=
=FKsB
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
| Per-Erik Westerberg wrote:
| | Ubuntu Breezy has also problems with the fixed font when I updated
| | it, the fonts.alias file is missing from the /usr/share/fonts/misc
| | directory, maybe it is the same problem that people are experiencing?
|
| I've recently been informed that just running mkfontdir in
| /usr/share/fonts/misc/ may work. Try it out.

I just made a vast number of commits to the fonts packages in an attempt
to fix this by regenerating the fonts.* files in pkg_postinst().
Upstream has a number of fonts installing into the same directory, so
just providing upstream's fonts.* files gives us a broken setup.

Things should work now.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+vo0XVaO67S1rtsRAsuyAJ9pjs+/ZMCsLNiDVQ/tvfMjA4jZJACeKcvf
GZtig0iIsl4EsiB0tCCV4Lw=
=67+0
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
| A few updates:
|
| I'm working on a Mesa ebuild to add; this will provide the gl.h
| everyone's been complaining about missing. My dev box is really screwy
| because of orphaned files, things lying around from CVS, etc, so I
| didn't realize this would actually be required until yesterday.
|
| Until then, just build xorg without glx.

This should be almost fixed, with the exception of opengl-update (see
patch in a reply to Georgi, and a proposal as a reply to that) and some
external apps installing xorg modules.

| People have been trouble actually starting the X server, because it
| can't find the 'fixed' font. I suspect that the font-misc-misc package
| is either installing wrong, or the font tools are messed up. Replace the
| /usr/share/fonts/misc/ directory with one from an older install.

Should be fixed; see post from ~5 min. ago.

| Also there have been errors of the freetype/type1/trap modules not found
| on startx. They aren't yet built in xorg-server, so you may need to copy
| them over from an older install.

Upstream problem, not yet fixed to my knowledge.

| You may need to create a symlink /usr/bin/X - Xorg.

I'm starting to work on an upstream patch for this.

| I also have reports that XKB isn't working properly yet. It'd be nice
| for someone to look into how to fix this.

This should be fixed in updated xkbdata.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+vr2XVaO67S1rtsRAnRUAKD257Uco/jvo1K3ZfLW5DDHKskfxgCfQ9vf
Q13JmdiLEsq6ztCBcSJ+YEw=
=+UQ5
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
 3.  With USE=-dri, for testing purposes (and in the end, perhaps for
 performance reasons as well), it seems better to change the make target
 to HOSTCONF=linux-sparc, and let user's CFLAGS define the architecture.
 When you do this, you get both a glx-capable libGL and a stand-alone
 libGL

And why is this a good thing? I'm adamantly against building the non-glx
libGL here for standard use, and I will continue to oppose it. Be normal
people and do the same thing as everybody else in the world who's ever
used libGL in X.

 4.  For now, in case USE=-dri, I am not calling fix_opengl_symlinks.
 Once I have all of X11R7 into test, I'll revisit this (and the Assembly
 code question) to see what gives the best performance.

Same as above.

 These changes are not very pretty, but they have the benefit of
 resulting in an ebuild for a mesa version of opengl which can actually
 be tested independently from the rest of Modular X.  It is even
 conceivable that other architecture/graphics-card combinations might
 require something similar.

I don't see how the standalone libGL has any relation to the ability to
test mesa with old or new X.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+49vXVaO67S1rtsRArphAJ9UrEwb0zjOkOvOP9mC4CkYlK8+jACgpFoa
mqJAZXt6otRKnsGGLGl2RC8=
=C0d6
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
 And why is this a good thing? I'm adamantly against building the non-glx
 libGL here for standard use, and I will continue to oppose it. Be normal
 people and do the same thing as everybody else in the world who's ever
 used libGL in X.

To give you some more concrete information:

1) The GLX one is almost certain to perform better in software
2) The standalone one definitely won't support ffb or any other form of
DRI (obviously), and building two libGL's is just silly.
3) When accelerated indirect rendering works, the standalone won't work
with it either.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+5KoXVaO67S1rtsRAnN2AKDY/kP6hOdNZsBLSASipXZ3gJ3/MQCgn/7D
1UdMjcZoBLAfg1yXNwd1hcc=
=Q0UM
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Ferris McCormick
On Thu, 2005-08-11 at 11:02 -0700, Donnie Berkholz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Donnie Berkholz wrote:
  And why is this a good thing? I'm adamantly against building the non-glx
  libGL here for standard use, and I will continue to oppose it. Be normal
  people and do the same thing as everybody else in the world who's ever
  used libGL in X.
 
 To give you some more concrete information:
 
 1) The GLX one is almost certain to perform better in software
 2) The standalone one definitely won't support ffb or any other form of
 DRI (obviously), and building two libGL's is just silly.
 3) When accelerated indirect rendering works, the standalone won't work
 with it either.
 
I don't disagree with any of these points, and it turns out that libGL
from mesa-6.3.1.1 (with DRI modules) works OK with current glx for mesa
indirect.  My problems have been related to the changes to the build in
mesa itself which result in either missing externals or doubly defined
externals when you use sparc assembly code.  So all I am really going to
need for sparc is to define a proper set of DRI drivers.

Notice, however, that the mesa ebuild does not seem to install the dri
drivers anyplace.  I suppose they should go
into /usr/lib/xorg/modules/drivers, but the don't.  It seems that the
ebuild uses mesa's 'installmesa' script to populate the image to
install, but installmesa looks only for include files and objects which
match lib*.  I don't see how it ever can install things like
mach64_dri.so (and, indeed, it doesn't).


Sorry for the confusion.


-- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Devrel)


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Jan Spitalnik
Dne čt 11. srpna 2005 20:58 Donnie Berkholz napsal(a):
 Donnie Berkholz wrote:
  Here's a slightly better version:

 And here's the enhanced, scripted version. It traces libs back to their
 packages to really make things easy.

you can replace (starting line 37)
if $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
static=1
fi
if ! $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
shared=1
fi

with
if $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
static=1
else
shared=1
fi

as it should be equivalent.


 Seems to work quite well.

 Thanks,
 Donnie

Have a nice day,
spity
-- 
Jan Spitalnik
[EMAIL PROTECTED]

We are now qualified to anything with nothing. -- Larry Wall

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
 Notice, however, that the mesa ebuild does not seem to install the dri
 drivers anyplace.  I suppose they should go
 into /usr/lib/xorg/modules/drivers, but the don't.  It seems that the
 ebuild uses mesa's 'installmesa' script to populate the image to
 install, but installmesa looks only for include files and objects which
 match lib*.  I don't see how it ever can install things like
 mach64_dri.so (and, indeed, it doesn't).

Hey, that's no problem now that we've resolved the libGL thing. =) We'll
just have to hack something together.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+6YrXVaO67S1rtsRAirEAKDVJUjQd2/NCr2kjZ4G/PolsTkOUgCg4mJ3
XAjlv0d0YEJp1P0FCX7hPPw=
=3BMd
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jan Spitalnik wrote:
 as it should be equivalent.

You'd think so, but consider this case:

Package A provides foo.so
Package B provides foo.a
Package C links against both

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+6aLXVaO67S1rtsRAvVpAKCKzCoeYvJ5tGns027wvZK7AJhsywCg1Y4i
pLswOQy4BDNJ+FnU7pxoxhI=
=VedS
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Ferris McCormick
On Thu, 2005-08-11 at 12:25 -0700, Donnie Berkholz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Ferris McCormick wrote:
  Notice, however, that the mesa ebuild does not seem to install the dri
  drivers anyplace.  I suppose they should go
  into /usr/lib/xorg/modules/drivers, but the don't.  It seems that the
  ebuild uses mesa's 'installmesa' script to populate the image to
  install, but installmesa looks only for include files and objects which
  match lib*.  I don't see how it ever can install things like
  mach64_dri.so (and, indeed, it doesn't).
 
 Hey, that's no problem now that we've resolved the libGL thing. =) We'll
 just have to hack something together.
 

I'm happy with libGL; I just reverted the ebuild to be as it started,
but to define a sparc-specific set of dri drivers. All my problems came
from my mistaken belief that mesa would still build cleanly using the
sparc assembly code.  I thought about going ahead and installing the
drivers themselves while I was at it, but decided to do other things
first.  If you like, I'll take a shot at it tomorrow, since I've been
playing with mesa and its ebuild anyway.


-- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Devrel)


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Georgi Georgiev
maillog: 11/08/2005-11:58:31(-0700): Donnie Berkholz types
 Donnie Berkholz wrote:
  Here's a slightly better version:
 
 And here's the enhanced, scripted version. It traces libs back to their
 packages to really make things easy.
 
 Seems to work quite well.
 
 Thanks,
 Donnie

 echo Looking for libraries ...
 for libname in ${libnames}; do
   static=0
   shared=0
   if $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
   static=1
   fi
   if ! $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
   shared=1
   fi

Why not pull these greps out of the loop? No need to do the *same* thing
for every library. Or did you forget to mention $libname in there?

   staticlibname=lib${libname}.a
   sharedlibname=lib${libname}.so
   if [[ ${static} -eq 1 ]]; then
   echo   Looking for ${staticlibname}
   for libdir in ${libdirs}; do
   if [[ -e ${libdir}/${staticlibname} ]]; then
   libpaths=${libpaths} 
 ${libdir}/${staticlibname}
   fi
   done
   fi
   if [[ ${shared} -eq 1 ]]; then
   echo   Looking for ${sharedlibname}
   for libdir in ${libdirs}; do
   if [[ -e ${libdir}/${sharedlibname} ]]; then
   libpaths=${libpaths} 
 ${libdir}/${sharedlibname}
   fi
   done
   fi
 done
 


-- 
\Georgi Georgiev   \  Experience is a good teacher, but she\
 /[EMAIL PROTECTED] / sends in terrific bills. -- Minna Antrim, /
\   +81(90)2877-8845   \  Naked Truth and Veiled Allusions   \


pgpRX8VjT3v5L.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
 Why not pull these greps out of the loop? No need to do the *same* thing
 for every library. Or did you forget to mention $libname in there?

My rationale was that over the course of a compilation, both shared and
static libs may be used. In one section it might link in a shared -lfoo,
while in another it does a static -lbar.

And yes I certainly did forget to mention $libname. =)

Attached an update to incorporate this and your other grep comments.

Thanks for the review!
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+8BvXVaO67S1rtsRArfiAJ916fUm2hN15fLd9eeecVPwmJndMwCg3R02
sAxoWHaBZPGf4zaXs86JRnY=
=CkNa
-END PGP SIGNATURE-


linking_libs.sh
Description: application/shellscript


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
 I'm happy with libGL; I just reverted the ebuild to be as it started,
 but to define a sparc-specific set of dri drivers. All my problems came
 from my mistaken belief that mesa would still build cleanly using the
 sparc assembly code.  I thought about going ahead and installing the
 drivers themselves while I was at it, but decided to do other things
 first.  If you like, I'll take a shot at it tomorrow, since I've been
 playing with mesa and its ebuild anyway.

I'm thinking something really basic like:

EXEDESTTREE=/usr/lib/xorg/modules/dri
find $S -name '*_dri.so' | xargs doexe

Does that work?

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+8E0XVaO67S1rtsRAtZeAKDxi0BF7XAqtL1bn61OLL/xMdW9OgCePh8N
sWmNLRJEPz1jtnBTFrdZRXA=
=x8YZ
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Ferris McCormick

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 11 Aug 2005, Donnie Berkholz wrote:


--[PinePGP]--[begin]--
Ferris McCormick wrote:

I'm happy with libGL; I just reverted the ebuild to be as it started,
but to define a sparc-specific set of dri drivers. All my problems came
from my mistaken belief that mesa would still build cleanly using the
sparc assembly code.  I thought about going ahead and installing the
drivers themselves while I was at it, but decided to do other things
first.  If you like, I'll take a shot at it tomorrow, since I've been
playing with mesa and its ebuild anyway.


I'm thinking something really basic like:

EXEDESTTREE=/usr/lib/xorg/modules/dri
find $S -name '*_dri.so' | xargs doexe

Does that work?



It should.  I'll verify tomorrow.

Regards,
Ferris
- --
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (sparc, devrel)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+8dsQa6M3+I///cRAjaDAKDUF7uUimEIzhMYScGpN+d2rrHcEACgquaA
XU11EiMqbphOkCN+TTAVU+8=
=t2iC
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
 Attached an update to incorporate this and your other grep comments.

Here's a new one. It prints some useful information while it's
searching, like OK or Not found!. Also fixes a little more ugly output
(double/single quotes and pipes showing up as parts of lib names) and
makes an attempt to use rpm if equery isn't around, and just prints the
lib paths otherwise.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+9meXVaO67S1rtsRAsuCAJ9KSuVoWyEWrGS0PspcvuVKGaOdowCcCLgx
C2zDxdm3YOkm/sJI2OvHztU=
=tpPa
-END PGP SIGNATURE-


linking_libs.sh
Description: application/shellscript


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Georgi Georgiev
maillog: 11/08/2005-16:05:02(-0700): Donnie Berkholz types
 Donnie Berkholz wrote:
  Attached an update to incorporate this and your other grep comments.
 
 Here's a new one. It prints some useful information while it's
 searching, like OK or Not found!. Also fixes a little more ugly output
 (double/single quotes and pipes showing up as parts of lib names) and
 makes an attempt to use rpm if equery isn't around, and just prints the
 lib paths otherwise.

Looks better and better. A couple more comments:

- I tried the script on the output of gvim, and it erroneously tried to
  find libatk-1.0.a. The problem was in this line:

  x86_64-pc-linux-gnu-gcc -L/usr/lib64   -L/usr/lib64   -rdynamic
  -L/usr/local/lib  -o gvim snip object files -lgdk_pixbuf-2.0
  -lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
  -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lacl -lgpm   -rdynamic
  -L/usr/local/lib
  /usr/lib/perl5/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a
  -L/usr/lib/perl5/5.8.6/x86_64-linux/CORE -lperl -lutil -lc
  -L/usr/lib/python2.4/config -lpython2.4 -L/usr/lib64 -lz -lutil -lm
  -Xlinker -export-dynamic static

  As you can see, it's the static in the end of the line. Maybe you
  should grep for -static instead.

- I'm sure I've seen makefiles that use tabs instead of spaces to
  separate the -l arguments. Maybe you should replace the space with a
  [:space:] or something?

- To avoid eventual problems with similarly named libraries (libpam and
  libpam_misc for example; grepping for -lpam would also match
  -lpam_misc) you could grep for \-l${libname}\ instead. This would
  also solve the space-or-tab problem.

-- 
/Georgi Georgiev   /  We must know, we will know. -- David /
\ [EMAIL PROTECTED]\  Hilbert  \
/   +81(90)2877-8845   /   /


pgpSOTNEWtojG.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
|   As you can see, it's the static in the end of the line. Maybe you
|   should grep for -static instead.

| - To avoid eventual problems with similarly named libraries (libpam and
|   libpam_misc for example; grepping for -lpam would also match
|   -lpam_misc) you could grep for \-l${libname}\ instead. This would
|   also solve the space-or-tab problem.

Try this one. It should address both issues.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC/CBJXVaO67S1rtsRAnsWAJ9q+x9c33TBxnpPSTqNtZvJPlEYSgCghQ+e
zEOZ5LyxT0TtvkRAkLOHAGM=
=N8Ha
-END PGP SIGNATURE-


linking_libs.sh
Description: application/shellscript


Re: [gentoo-dev] Modular X plans

2005-08-11 Thread Georgi Georgiev
maillog: 11/08/2005-21:06:34(-0700): Donnie Berkholz types
 Georgi Georgiev wrote:
 |   As you can see, it's the static in the end of the line. Maybe you
 |   should grep for -static instead.
 
 | - To avoid eventual problems with similarly named libraries (libpam and
 |   libpam_misc for example; grepping for -lpam would also match
 |   -lpam_misc) you could grep for \-l${libname}\ instead. This would
 |   also solve the space-or-tab problem.
 
 Try this one. It should address both issues.

I should have tested a bit more.

[EMAIL PROTECTED] ~ $ echo 'a -lbcd' | grep -- '-l'
a -lbcd
[EMAIL PROTECTED] ~ $ echo 'a -lbcd' | grep -- '\b-l'
[EMAIL PROTECTED] ~ $ echo 'a lbcd'  | grep -- '\bl'
a lbcd

It's the - that is not a part of a word. Any ideas? I guess the \b
after ${libname} is fine, but the one before the - is not. It's down
to [[:space:]]-l${libname}\b it seems. And hopefully there won't be any
any lines starting with -l, or any -llib being quoted which is legal
but unmatchable. Ah, cannot grep be told that - is a valid word
symbol.

The only reason the script currently works is because:

grep '\b-l[[:alnum:]].*\b' ${1}

matches the -l in x86_64-pc-linux-gnu-gcc

You also do not need the .*\b in the above. The .*\b would always
match until the last word on the line (grep doesn't do greedy wildcard
matching), and since it would *always* match, there is no need in
matching at all.

-- 
\Georgi Georgiev   \  Try the Moo Shu Pork. It is especially   \
 /[EMAIL PROTECTED] / good today.   /
\   +81(90)2877-8845   \   \


pgpgJCbFpja2U.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Ferris McCormick
On Wed, 2005-08-10 at 12:46 +, Ferris McCormick wrote:
 On Tue, 2005-08-09 at 19:40 -0700, Donnie Berkholz wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
 
  Good catch. I was going to get to the rest of the GL headers after
  getting Mesa working.
 
 Another comment about Mesa.  Mesa, as distributed, has built in
 architectures it can build for, and it substitutes its own idea of
 appropriate CFLAGS rather than using the user's request.  For sparc, at
 least, these are not appropriate, as can be seen from current
 xorg-x11-6.8.99.15, say, for which libGL does get built using
 make.conf's CFLAGS.
 
OK, now I have looked at the X modular ebuild for mesa-6.3.1.1, and half
of what I said is irrelevant.
1.  The good news:  CFLAGS are fine for X11R7 libGL build;
2.  But to get sparc assembler built correctly, the following patch
seems correct:

--- /home/cvsroot/gentoo-x86/media-libs/mesa/mesa-6.3.1.1.ebuild
2005-08-10 06:42:09.000
00 +
+++ mesa-6.3.1.1.ebuild 2005-08-10 15:03:22.0 +
@@ -17,7 +17,7 @@
http://xorg.freedesktop.org/extras/${LIBDRM_P}.tar.gz;
 LICENSE=LGPL-2
 SLOT=0
-KEYWORDS=~x86
+KEYWORDS=~x86 ~sparc
 IUSE=motif
 
 RDEPEND=dev-libs/expat
@@ -62,6 +62,10 @@
 
# Set up linux-dri configs
echo OPT_FLAGS = ${CFLAGS}  ${HOSTCONF}
+   if use sparc; then
+   echo ASM_FLAGS = -DUSE_SPARC_ASM  ${HOSTCONF}
+   echo 'ASM_SOURCES = $(SPARC_SOURCES) $(SPARC_API)' 
${HOSTCONF}
+   fi
echo CC = $(tc-getCC)  ${HOSTCONF}
echo CXX = $(tc-getCXX)  ${HOSTCONF}
echo DRM_SOURCE_PATH=\$(TOP)/../${LIBDRM_P}  ${HOSTCONF}
@@ -72,7 +76,7 @@
# Documented in configs/default
if use motif; then
# Add -lXm
-   echo GLW_LIB_DEPS = -L$(LIB_DIR) -l$(GL_LIB)
$(EXTRA_LIB_PATH) -lXt -lX11 -lXm
  ${HOSTCONF}
+   echo 'GLW_LIB_DEPS = -L$(LIB_DIR) -l$(GL_LIB)
$(EXTRA_LIB_PATH) -lXt -lX11 -lXm
'  ${HOSTCONF}

(Alternative is to create a complete linux-dri-sparc config file; I can
do that if you like.)

3.  I changed the double-quoted echo at GLW_LIB ... to single-quoted
echo, because I think we need to pass in the $(LIB_DIR), etc. as-is (at
least, the ebuild doesn't know what they are and portage complains
otherwise).

I've also attached the little strawman patch to this note, to make it
easier to read.  I can file a Bug for the change if you like.

Regards,
Ferris

-- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Devrel)
--- /home/cvsroot/gentoo-x86/media-libs/mesa/mesa-6.3.1.1.ebuild
2005-08-10 06:42:09.0 +
+++ mesa-6.3.1.1.ebuild 2005-08-10 15:03:22.0 +
@@ -17,7 +17,7 @@
http://xorg.freedesktop.org/extras/${LIBDRM_P}.tar.gz;
 LICENSE=LGPL-2
 SLOT=0
-KEYWORDS=~x86
+KEYWORDS=~x86 ~sparc
 IUSE=motif
 
 RDEPEND=dev-libs/expat
@@ -62,6 +62,10 @@
 
# Set up linux-dri configs
echo OPT_FLAGS = ${CFLAGS}  ${HOSTCONF}
+   if use sparc; then
+   echo ASM_FLAGS = -DUSE_SPARC_ASM  ${HOSTCONF}
+   echo 'ASM_SOURCES = $(SPARC_SOURCES) $(SPARC_API)'  
${HOSTCONF}
+   fi
echo CC = $(tc-getCC)  ${HOSTCONF}
echo CXX = $(tc-getCXX)  ${HOSTCONF}
echo DRM_SOURCE_PATH=\$(TOP)/../${LIBDRM_P}  ${HOSTCONF}
@@ -72,7 +76,7 @@
# Documented in configs/default
if use motif; then
# Add -lXm
-   echo GLW_LIB_DEPS = -L$(LIB_DIR) -l$(GL_LIB) $(EXTRA_LIB_PATH) 
-lXt -lX11 -lXm  ${HOSTCONF}
+   echo 'GLW_LIB_DEPS = -L$(LIB_DIR) -l$(GL_LIB) $(EXTRA_LIB_PATH) 
-lXt -lX11 -lXm'  ${HOSTCONF}
# Add GLwMDrawA.c
echo GLW_SOURCES = GLwDrawA.c GLwMDrawA.c  ${HOSTCONF}
fi


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Per-Erik Westerberg
Ubuntu Breezy has also problems with the fixed font when I updated
it, the fonts.alias file is missing from the /usr/share/fonts/misc
directory, maybe it is the same problem that people are experiencing?

  / Per-Erik

tis 2005-08-09 klockan 11:16 -0700 skrev Donnie Berkholz:
 Donnie Berkholz wrote:
 | If you find bugs that aren't purely ebuild problems, do not file them at
 | bugs.gentoo.org -- go to bugs.freedesktop.org, in the xorg product.
 |
 | Two USE flags you will care about are dri and glx -- both are
 | necessary to get accelerated 3D.
 
 A few updates:
 
 I'm working on a Mesa ebuild to add; this will provide the gl.h
 everyone's been complaining about missing. My dev box is really screwy
 because of orphaned files, things lying around from CVS, etc, so I
 didn't realize this would actually be required until yesterday.
 
 Until then, just build xorg without glx.
 
 People have been trouble actually starting the X server, because it
 can't find the 'fixed' font. I suspect that the font-misc-misc package
 is either installing wrong, or the font tools are messed up. Replace the
 /usr/share/fonts/misc/ directory with one from an older install.
 
 Also there have been errors of the freetype/type1/trap modules not found
 on startx. They aren't yet built in xorg-server, so you may need to copy
 them over from an older install.
 
 You may need to create a symlink /usr/bin/X - Xorg.
 
 I also have reports that XKB isn't working properly yet. It'd be nice
 for someone to look into how to fix this.
 
 That's all I can think of for now.
 
 Thanks,
 Donnie


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
| 2.  But to get sparc assembler built correctly, the following patch
| seems correct:

Looks good to me.

| (Alternative is to create a complete linux-dri-sparc config file; I can
| do that if you like.)

No need if you don't want to. But it could be useful to get something
like this so we could send it upstream and they'd have something that
worked well for everyone else on sparc.

| 3.  I changed the double-quoted echo at GLW_LIB ... to single-quoted
| echo, because I think we need to pass in the $(LIB_DIR), etc. as-is (at
| least, the ebuild doesn't know what they are and portage complains
| otherwise).

Could you do double quotes with \$ instead, so it matches the other
instance? I think that makes it more obvious what's going on to people
less experienced with bash's quoting. This one just slipped by me, it
was late.

| I've also attached the little strawman patch to this note, to make it
| easier to read.  I can file a Bug for the change if you like.

Just go ahead and commit it.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+j8SXVaO67S1rtsRAvlFAKCINple85NJC6AoCAFxpLU+Sq4xugCgxd5f
o+C3F220/XCTOBJB4+9/Z44=
=2DlM
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Per-Erik Westerberg wrote:
| Ubuntu Breezy has also problems with the fixed font when I updated
| it, the fonts.alias file is missing from the /usr/share/fonts/misc
| directory, maybe it is the same problem that people are experiencing?

I've recently been informed that just running mkfontdir in
/usr/share/fonts/misc/ may work. Try it out.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+kBkXVaO67S1rtsRAmJnAJ9pD+8gl/fKfm2cgsvI7oH9F+Ps3ACeNZkE
Zjmm/SffYXljISJ2kImnDQE=
=maox
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Ferris McCormick
On Wed, 2005-08-10 at 10:53 -0700, Donnie Berkholz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Ferris McCormick wrote:
 | 2.  But to get sparc assembler built correctly, the following patch
 | seems correct:
 
 Looks good to me.
 
 |
 
 Just go ahead and commit it.
Done.  It's not quite right, yet, but it can now be worked with.  For
sparc, we do not want a lot of ..._dri.so modules (even though that is
the target being used) because the kernel does not support them.  So,
currently, I have it set to in effect build libGL for stand-alone.  For
some reason, it builds two versions of libGL, and during the install
phase, links libGL.so to the incorrect one (it's correct in the work
directory, and I think the install target tries to correct it again for
gentoo, but for sparc right now I don't want it to do that) ---
libGL.so.1.2 on sparc is incorrect, and libGL.so.1.5.xxx seems
incomplete.  But it's in a state it can be worked with.
 
 Thanks,
 Donnie
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.1 (GNU/Linux)
 
 iD8DBQFC+j8SXVaO67S1rtsRAvlFAKCINple85NJC6AoCAFxpLU+Sq4xugCgxd5f
 o+C3F220/XCTOBJB4+9/Z44=
 =2DlM
 -END PGP SIGNATURE-
-- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Devrel)


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
| Ferris McCormick wrote:
| | Done.  It's not quite right, yet, but it can now be worked with.  For
| | sparc, we do not want a lot of ..._dri.so modules (even though that is
| | the target being used) because the kernel does not support them.  So,
| | currently, I have it set to in effect build libGL for stand-alone.  For
| | some reason, it builds two versions of libGL, and during the install
| | phase, links libGL.so to the incorrect one (it's correct in the work
| | directory, and I think the install target tries to correct it again for
| | gentoo, but for sparc right now I don't want it to do that) ---
| | libGL.so.1.2 on sparc is incorrect, and libGL.so.1.5.xxx seems
| | incomplete.  But it's in a state it can be worked with.
|
| You want the 1.2 one for DRI to work properly on e.g., sunffb and
| mach64. If you don't want various _dri.so modules, that can be hacked
| around in a different way, such as changing DRI_DIRS.

I found some more info for you on this:

http://www.mesa3d.org/faq.html

Look at 1.4 What's the difference between Stand-Alone Mesa and the
DRI drivers? to understand why stand-alone isn't the right thing to build.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+l+1XVaO67S1rtsRAtbjAJ4ygpqnLbXofKg/6Os7xLDFooGQnwCg+4PL
tjdq1HvxAmx7F1YFAsT/giI=
=C4fn
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Ferris McCormick

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 10 Aug 2005, Donnie Berkholz wrote:


--[PinePGP]--[begin]--
Ferris McCormick wrote:
|   Done.  It's not quite right, yet, but it can now be worked with.  For
|   sparc, we do not want a lot of ..._dri.so modules (even though that is
|   the target being used) because the kernel does not support them.  So,
|   currently, I have it set to in effect build libGL for stand-alone.  For
|   some reason, it builds two versions of libGL, and during the install
|   phase, links libGL.so to the incorrect one (it's correct in the work
|   directory, and I think the install target tries to correct it again for
|   gentoo, but for sparc right now I don't want it to do that) ---
|   libGL.so.1.2 on sparc is incorrect, and libGL.so.1.5.xxx seems
|   incomplete.  But it's in a state it can be worked with.

You want the 1.2 one for DRI to work properly on e.g., sunffb and
mach64. If you don't want various _dri.so modules, that can be hacked
around in a different way, such as changing DRI_DIRS.

I don't understand your comment about the kernel not supporting DRI at
all. It clearly does in 2.4, but I haven't tried 2.6. Do you mean the
DRM is no longer included in the kernel source?

I wrote the note very fast, and it was not too clear.  With sunffb, the 
kernel code for current 2.6.x (x  6) is broken, and davem has taken dri 
support out of the xorg sunffb driver (to paraphrase him, you can't do 
both drm and correct font rendering).


With mach64, the problem on sparc has been the hardware itself, if I 
remember correctly.  That is, kernel, xorg are fine, but the mach64 card 
used on U5/U10 is memory-deficient.  Someone who has looked at it more 
recently than I have will correct this.  (There is a mach64-based sparc 
frame buffer which should be OK for DRI, but I've never seen one.  I'll 
chase it down in the framebuffer handbook a little later.)


Changing DRI_DIRS is exactly what I did.  I will look at it more closely 
over the next few days to figure out precisely what sparc needs; it's not 
DRI_DIRS= nothing, but unfortunately, on my test systems, that is what I
have to have.  (Either Creator+sunffb-without-DRM-support, or 
Elite-+sunffb+can't-support-DRM.)


Yes, it's ugly.  My goal is (1) a ~sparc suite for X modular which can be 
built and tested, and then (2) an optimal libGL  friends.  I'm starting 
with Mesa, because that has always seemed to be the hardest part to get 
right for sparc.



Thanks,
Donnie


Regards,
Ferris
- --
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (sparc, devrel)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+nbfQa6M3+I///cRAj8WAJ4xv6CtzR7ff8Iz4nR6d3gghKND3gCgmal4
FvgwKuedJC/Si+yTyBcHAS4=
=O/cy
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
| I wrote the note very fast, and it was not too clear.  With sunffb, the
| kernel code for current 2.6.x (x  6) is broken, and davem has taken dri
| support out of the xorg sunffb driver (to paraphrase him, you can't do
| both drm and correct font rendering).

OK, it might be nice to bring alanh in on this conversation since he
recently fixed up the ffb DRI code, also to retest with the new code.

And as far as davem taking out DRI from the DDX code, that seems easy
enough to re-enable and test again -- just #if 0 changed back to XF86DRI.

[EMAIL PROTECTED]
/usr/local/share/xorg/modular/driver/xf86-video-sunffb/src $ grep -i
xf86dri *
ffb_dri.c:#define _XF86DRI_SERVER_
ffb_driver.c:/*#ifdef XF86DRI*/
ffb_driver.c:#if 0 /*def XF86DRI*/
ffb_driver.c:#if 0 /*def XF86DRI*/
ffb_driver.c:#if 0 /*def XF86DRI*/
ffb.h:#ifdef XF86DRI
ffb.h:#ifdef XF86DRI
ffb.h:#ifdef XF86DRI
ffb.h:#ifdef XF86DRI

| With mach64, the problem on sparc has been the hardware itself, if I
| remember correctly.  That is, kernel, xorg are fine, but the mach64 card
| used on U5/U10 is memory-deficient.  Someone who has looked at it more
| recently than I have will correct this.  (There is a mach64-based sparc
| frame buffer which should be OK for DRI, but I've never seen one.  I'll
| chase it down in the framebuffer handbook a little later.)

My u5 works just fine with DRI at 800x600 resolution, 16-bit color. Any
higher than this and you're right, not enough memory.

| Changing DRI_DIRS is exactly what I did.

Not really...

DRIVER_DIRS != DRI_DIRS

e.g., DRIVER_DIRS = dri, DRI_DIRS = mach64 ffb

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+oMZXVaO67S1rtsRAr4zAJ9pdiE+OY9olRg3iLet8TPZ+cc0LACgz2nc
Z+702RsgsYdWHvYWoErTeaE=
=Wo8g
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Ferris McCormick

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 10 Aug 2005, Donnie Berkholz wrote:


--[PinePGP]--[begin]--
Ferris McCormick wrote:
|  I wrote the note very fast, and it was not too clear.  With sunffb, the
|  kernel code for current 2.6.x (x  6) is broken, and davem has taken dri
|  support out of the xorg sunffb driver (to paraphrase him, you can't do
|  both drm and correct font rendering).

OK, it might be nice to bring alanh in on this conversation since he
recently fixed up the ffb DRI code, also to retest with the new code.



Probably.  Kernel seems to be changing so quickly now that as soon as the 
ffb DRI code gets fixed, the kernel changes out from under it.  So when we 
get to 2.6.13-rcxx, I have problems building it and have nothing to test 
it on.  (I am really not interested in kernel-2.4.30+, because one of 
these days davem really will fix kernel-2.6.82 (or something) for sparc, 
and we can start burying the 2.4.xx series.  I am speaking for myself, 
here, but I don't think sparc is hanging on to kernel-2.4.xx because we 
are in love with it.)


And as far as davem taking out DRI from the DDX code, that seems 

easy

enough to re-enable and test again -- just #if 0 changed back to XF86DRI.

[EMAIL PROTECTED]
/usr/local/share/xorg/modular/driver/xf86-video-sunffb/src $ grep -i
xf86dri *
ffb_dri.c:#define _XF86DRI_SERVER_
ffb_driver.c:/*#ifdef XF86DRI*/
ffb_driver.c:#if 0 /*def XF86DRI*/
ffb_driver.c:#if 0 /*def XF86DRI*/
ffb_driver.c:#if 0 /*def XF86DRI*/
ffb.h:#ifdef XF86DRI
ffb.h:#ifdef XF86DRI
ffb.h:#ifdef XF86DRI
ffb.h:#ifdef XF86DRI



Yes, it's easy enough to re-enable.  I haven't tried it yet, though, 
because I have figured davem had a good reason to disable it, and I 
generally trust his knowledge on such matters.  So discovering what

that reason is has been pretty low priority.  (I don't know if anyone
else has tested or not.  The question comes up every now and then,
and so far my response has been (tongue in cheek) along the 
lines of your observation along with a request If you try this, we'd all 
like to know how it goes.)



|  With mach64, the problem on sparc has been the hardware itself, if I
|  remember correctly.  That is, kernel, xorg are fine, but the mach64 card
|  used on U5/U10 is memory-deficient.  Someone who has looked at it more
|  recently than I have will correct this.  (There is a mach64-based sparc
|  frame buffer which should be OK for DRI, but I've never seen one.  I'll
|  chase it down in the framebuffer handbook a little later.)

My u5 works just fine with DRI at 800x600 resolution, 16-bit color. Any
higher than this and you're right, not enough memory.


That is new information for me;  I had been led to believe otherwise, and 
I have not been in a position to verify for myself.  Thanks.




|  Changing DRI_DIRS is exactly what I did.

Not really...

DRIVER_DIRS != DRI_DIRS



Yes.  I answered you without reading carefully.


e.g., DRIVER_DIRS = dri, DRI_DIRS = mach64 ffb



You are correct, of course.  Actually, there should probably be a 
corresponding dri driver for each sparc-enabled frame buffer, which makes 
it something like mach64 ffb savage ...


The actual ebuild will have to be a bit more subtle than my immediate 
patch-to-enable-assembly+get-to-testable for the following reason:


It always makes sense to enable glx (Mesa) whether there is DRI support or 
not; some applications can run adequately well using the Mesa-indirect 
approach, and some graphics cards --- e.g., Elite == afb --- don't allow 
dri at all.  That is what (for sparc, at least) USE=glx should control.
On some systems, however, like your U5+mach64, it is beneficial to build 
the _dri.so module.  That is what the USE=dri flag (on sparc) 
should control.  So, USE=dri without also USE=glx does not make any sense 
on sparc, but USE=glx -dri is required for, say, Elite-graphics systems 
for which one does want libGL built (Like my SB1000+afb system, which is 
fast enough to do reasonable glx-like things (e.g., blender), but can't do 
dri at all).  Further, there is no way for the ebuild to determine for 
itself just what case it is addressing.


So, ultimately, the mesa ebuild should work as you have it if it is given 
USE=dri glx, but it should build sparc-specific modules.  However, it it 
gets USE=-dri glx, it should arrange to build libGL stand-alone, because 
the user is saying in effect I do want mesa/openGL installed, but I am 
unable to support DRI, and mesa can be built that way.  This requires, I 
think, the ebuild to determine the HOSTCONFIG for sparc based on whether 
or not it has USE=dri, and to go on and set a sensible DRI_DIRS for the 
USE=dri case.  In all cases, the CFLAGS, SPARC_ASM, etc. should be set up 
as they are now.


I hope this isn't too incoherent; this has been a hectic day.
Regards,
Ferris

- --
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (sparc, devrel)

Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Georgi Georgiev
maillog: 09/08/2005-11:16:52(-0700): Donnie Berkholz types
 Donnie Berkholz wrote:
 | If you find bugs that aren't purely ebuild problems, do not file them at
 | bugs.gentoo.org -- go to bugs.freedesktop.org, in the xorg product.
 |
 | Two USE flags you will care about are dri and glx -- both are
 | necessary to get accelerated 3D.
 
 A few updates:
 
 I'm working on a Mesa ebuild to add; this will provide the gl.h
 everyone's been complaining about missing. My dev box is really screwy
 because of orphaned files, things lying around from CVS, etc, so I
 didn't realize this would actually be required until yesterday.
 
 Until then, just build xorg without glx.
 
 People have been trouble actually starting the X server, because it
 can't find the 'fixed' font. I suspect that the font-misc-misc package
 is either installing wrong, or the font tools are messed up. Replace the
 /usr/share/fonts/misc/ directory with one from an older install.
 
 Also there have been errors of the freetype/type1/trap modules not found
 on startx. They aren't yet built in xorg-server, so you may need to copy
 them over from an older install.

Ah...

It seems that the current xorg-server installs all modules in
/usr/lib/xorg/modules. Any idea why? It used to be /usr/lib/modules
until recently, and that's still where opengl-update symlinks stuff to,
and also where vnc and nvidia-glx put their own X modules.

-- 
\Georgi Georgiev   \  When Dexter's on the Internet, can Hell be   \
/ [EMAIL PROTECTED]/  far behind? /
\   +81(90)2877-8845   \   \


pgpWoVgxa2SLh.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
 It seems that the current xorg-server installs all modules in
 /usr/lib/xorg/modules. Any idea why? It used to be /usr/lib/modules
 until recently, and that's still where opengl-update symlinks stuff to,
 and also where vnc and nvidia-glx put their own X modules.

Yeah, it's a more specific location. /usr/lib/modules is a very generic
name that doesn't specify that only X modules go in it.

Here's a quick patch for opengl-update -- we'll have to figure out a
better solution for the future.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+tGUXVaO67S1rtsRAk2kAKDKWYnA4hb8OBs+o1PAL4a6zfQIFQCgs4LS
baBpcHsCP6Khc9rS/Okb+l4=
=ogfd
-END PGP SIGNATURE-
--- opengl-update.orig	2005-08-10 21:17:32.0 -0700
+++ opengl-update	2005-08-10 21:17:47.0 -0700
@@ -262,8 +262,8 @@
 			fi
 
 			if [[ -e ${PREFIX}/${LIBDIR}/opengl/${GL_LOCAL}/extensions ]]; then
-mkdir -p ${DST_PREFIX}/${LIBDIR}/modules/extensions
-pushd ${DST_PREFIX}/${LIBDIR}/modules/extensions  /dev/null
+mkdir -p ${DST_PREFIX}/${LIBDIR}/xorg/modules/extensions
+pushd ${DST_PREFIX}/${LIBDIR}/xorg/modules/extensions  /dev/null
 	# First remove old symlinks
 	for file in libglx.so libglx.a; do
 		[[ -h ${file} ]]  rm -f ${file}


Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
 Georgi Georgiev wrote:
 
It seems that the current xorg-server installs all modules in
/usr/lib/xorg/modules. Any idea why? It used to be /usr/lib/modules
until recently, and that's still where opengl-update symlinks stuff to,
and also where vnc and nvidia-glx put their own X modules.
 
 
 Yeah, it's a more specific location. /usr/lib/modules is a very generic
 name that doesn't specify that only X modules go in it.
 
 Here's a quick patch for opengl-update -- we'll have to figure out a
 better solution for the future.

Here's what I'm thinking.

Option 1) We add new revisions of nvidia, vnc, opengl-update that only
work with 7.0RC and newer. This may require some extra work to keep them
in sync with ebuilds compatible with older X, as long as we care about
older X (In essence, until 7.0 release).

Option 2) We make some function like get-x-module-dir in x11.eclass.
Ebuilds that need it inherit and decide what to do based on what's
installed.

Yes this sucks for binary packages built to use on the other X version,
but I think it's a better option because it doesn't require as much
ongoing time investment. This is similar to what most packages to which
it mattered did with the xorg/xfree switch.

Option 3) Other ideas?

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+tgFXVaO67S1rtsRAuVKAKDlEAmkC4/oK8DjybuPi5VDS//oswCg1YHA
O8k1LhosBnVUelhrGPqIRi0=
=tBMC
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Georgi Georgiev
maillog: 10/08/2005-21:45:58(-0700): Donnie Berkholz types
 Donnie Berkholz wrote:
  Georgi Georgiev wrote:
  
 It seems that the current xorg-server installs all modules in
 /usr/lib/xorg/modules. Any idea why? It used to be /usr/lib/modules
 until recently, and that's still where opengl-update symlinks stuff to,
 and also where vnc and nvidia-glx put their own X modules.
  
  
  Yeah, it's a more specific location. /usr/lib/modules is a very generic
  name that doesn't specify that only X modules go in it.
  
  Here's a quick patch for opengl-update -- we'll have to figure out a
  better solution for the future.
 
 Here's what I'm thinking.
 
 Option 1) We add new revisions of nvidia, vnc, opengl-update that only
 work with 7.0RC and newer. This may require some extra work to keep them
 in sync with ebuilds compatible with older X, as long as we care about
 older X (In essence, until 7.0 release).
 
 Option 2) We make some function like get-x-module-dir in x11.eclass.
 Ebuilds that need it inherit and decide what to do based on what's
 installed.
 
 Yes this sucks for binary packages built to use on the other X version,
 but I think it's a better option because it doesn't require as much
 ongoing time investment. This is similar to what most packages to which
 it mattered did with the xorg/xfree switch.
 
 Option 3) Other ideas?

What about new revisions of the monolithic xorg that will install in
/usr/lib/xorg/modules followed by new revisions of all packages like
opengl-update, nvidia, ati-whatever, that will depend on the newer xorg
release?

If that's too much effort, then I'm all for Option 1.

-- 
*)   Georgi Georgiev   *) I HAVE to buy a new DODGE MISER and two*)
(*[EMAIL PROTECTED](* dozen JORDACHE JEANS because my viewscreen   (*
*)  +81(90)2877-8845   *) is USER-FRIENDLY!! *)


pgppoGdeX9SkQ.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-10 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
| What about new revisions of the monolithic xorg that will install in
| /usr/lib/xorg/modules followed by new revisions of all packages like
| opengl-update, nvidia, ati-whatever, that will depend on the newer xorg
| release?

We still need to deal with the transition either way. We can't just
ignore everything that's installed in /usr/lib/modules when we upgrade xorg.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+t1UXVaO67S1rtsRAg5QAJ9cuA1KXb1e489rjbfU2gMrG26PdQCgsgyY
3gJ6qBqgj3qljGni7frF3zM=
=9b3b
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Georgi Georgiev
maillog: 08/08/2005-01:08:03(-0700): Donnie Berkholz types
 snip
 The font-server flag may be necessary in libXfont, but I haven't fully
 explored this yet. If it turns out to be the case, it'll be removed as
 an optional flag and forced on.

Unfortunately, it seems it does. I did it with -font-server and the
build of xorg-server failed with errors about missing functions:

check_fs_register_fpe_functions
fs_register_fpe_functions

emerging libXfont with font-server made xorg-server link just fine.

Still, I believe that it is xorg-server that has to be fixed. It needs
to get NOFONTSERVERACCESS defined, which will avoid the call to
fs_register_fpe_functions, and it would need to do something about the
call to check_fs_register_fpe_functions, but I have no idea what.

-- 
Georgi Georgiev If there is a wrong way to do something,  
 [EMAIL PROTECTED]  then someone will do it. -- Edward A.
   +81(90)2877-8845 Murphy Jr.


pgplFeOBIrbC6.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Caleb Tennis
On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote:
 If you could bring up some specific examples, we could discuss them.

Sure.  Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, 
xcursor, xinerama (already a use flag), xshape, and xsm.

I'd really hate to add 8 more use flags for those things.  I find it fairly 
hard to believe that a user would want to, for example, configre xrender and 
xcursor but not xrandr.

My *thought* here is why not let the Qt ebuild rely on the base packages of X, 
and if these other packages are also installed ahead of time, then configure 
support for them as well, but don't make them use flag deps.

Something like:

if xcursor is installed
  turn on xcursor support
  DEPEND+=xcursor
fi

I'm sure someone will cast me as a heretic, but I think this is much more 
elegant than 8 more use flags.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Brian Harring
On Tue, Aug 09, 2005 at 07:36:31AM -0500, Caleb Tennis wrote:
 On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote:
  If you could bring up some specific examples, we could discuss them.
 
 Sure.  Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, 
 xcursor, xinerama (already a use flag), xshape, and xsm.
 
 I'd really hate to add 8 more use flags for those things.  I find it fairly 
 hard to believe that a user would want to, for example, configre xrender and 
 xcursor but not xrandr.
 
 My *thought* here is why not let the Qt ebuild rely on the base packages of 
 X, 
 and if these other packages are also installed ahead of time, then configure 
 support for them as well, but don't make them use flag deps.
 
 Something like:
 
 if xcursor is installed
   turn on xcursor support
   DEPEND+=xcursor
 fi
 
 I'm sure someone will cast me as a heretic, but I think this is much more 
 elegant than 8 more use flags.
Yep, you're a heretic. :)
How would you propose that DEPEND information make it's way up the 
portage stack, and ultimately affects the depgraph?

What you're suggesting is effectively suggested deps, which are a 
bit backwards considering we have optional deps, the 8 flags you 
dislike :)
~harring


pgpQeXiqrH1BU.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Caleb Tennis
 Yep, you're a heretic. :)
 How would you propose that DEPEND information make it's way up the
 portage stack, and ultimately affects the depgraph?

 What you're suggesting is effectively suggested deps, which are a
 bit backwards considering we have optional deps, the 8 flags you
 dislike :)

Let me follow up with that I'm all for adding the use flags IF other packages 
would make use of them as well.  I just really hate adding 8 local use flags 
for this pretty heavily used package that won't add much utility to anything 
else and will add a bit of headache to making sure Qt is installed with all 
of the bells and whistles the end user wants. :)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Carsten Lohrke
On Tuesday 09 August 2005 15:03, Caleb Tennis wrote:
 Let me follow up with that I'm all for adding the use flags IF other
 packages would make use of them as well.  I just really hate adding 8 local
 use flags for this pretty heavily used package that won't add much utility
 to anything else and will add a bit of headache to making sure Qt is
 installed with all of the bells and whistles the end user wants. :)

I strongly dislike your indeed heretic idea of stepping back from 
deterministic dependencies as well. On the other hand I don't see why you 
should support these optional dependencies, when you feel you can't or it 
doesn't make sense. Just add them as hard dependencies. Non-issue imho. :)


Carsten


pgpUVRgm67mNC.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Caleb Tennis wrote:
| On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote:
|
|If you could bring up some specific examples, we could discuss them.
|
|
| Sure.  Qt has optional support for xkb, tablet, fontconfig, xrender,
xrandr,
| xcursor, xinerama (already a use flag), xshape, and xsm.
|
| I'd really hate to add 8 more use flags for those things.  I find it
fairly
| hard to believe that a user would want to, for example, configre
xrender and
| xcursor but not xrandr.

Then group stuff together, and force some things on always. I find it
hard to believe that a user would ever want to turn most of those things
off, with only a couple of exceptions.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+PF0XVaO67S1rtsRAuy2AKDXgmhWBl30RNjWcTn/gS59ae0LYwCg5amr
4TN8tgzOx6qJaWhoguiwaVE=
=ezhB
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Georgi Georgiev
maillog: 09/08/2005-11:16:52(-0700): Donnie Berkholz types
 Donnie Berkholz wrote:
 | If you find bugs that aren't purely ebuild problems, do not file them at
 | bugs.gentoo.org -- go to bugs.freedesktop.org, in the xorg product.
 |
 | Two USE flags you will care about are dri and glx -- both are
 | necessary to get accelerated 3D.
 
 A few updates:
 
 I'm working on a Mesa ebuild to add; this will provide the gl.h
 everyone's been complaining about missing. My dev box is really screwy
 because of orphaned files, things lying around from CVS, etc, so I
 didn't realize this would actually be required until yesterday.

Furthermore, make sure you don't install the headers in /usr/include/GL,
but in a location that opengl-update would know how to handle.

$ equery b /usr/include/GL/glx.h 
[ Searching for file(s) /usr/include/GL/glx.h in *... ]
x11-proto/glproto-1.4 (/usr/include/GL/glx.h)

-- 
\Georgi Georgiev   \  Youth is a disease from which we all \
 /[EMAIL PROTECTED] / recover. -- Dorothy Fuldheim  /
\   +81(90)2877-8845   \   \


pgpg4JovncXGd.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Georgi Georgiev
maillog: 09/08/2005-11:16:52(-0700): Donnie Berkholz types

 Also there have been errors of the freetype/type1/trap modules not found
 on startx. They aren't yet built in xorg-server, so you may need to copy
 them over from an older install.

Add to that the bitmap and pcidata modules -- the only modules that
X is complaining about here.

-- 
/\   Georgi Georgiev   /\ Observe yon plumed biped fine. To activate   /\
\/[EMAIL PROTECTED]\/ its captivation, Deposit on its termination, \/
/\  +81(90)2877-8845   /\ A quantity of particles saline.  /\
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georgi Georgiev wrote:
| Furthermore, make sure you don't install the headers in /usr/include/GL,
| but in a location that opengl-update would know how to handle.

Good catch. I was going to get to the rest of the GL headers after
getting Mesa working.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+WkPXVaO67S1rtsRAn/ZAKCdjiIBGACi2Ns39GFMdCVYy5FDmgCfTPvK
bNJwJxGVMcxTbXb1DI5LFKM=
=5VBT
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-09 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
| Ciaran McCreesh wrote:
| | Hrm. Is this going to be sanely doable by your average dev? How long
| | a dep string would we be having in typical cases? How about in bad
| | cases?
|
| It shouldn't be difficult in most cases, for those capable of finding
| linker lines in a build.
|
| I wrote a quick one-liner that works reasonably well on a couple of
| tests, but could use a little tweaking. Just set log to your build log
| beforehand.
|
| for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ ${linkline} =~
| -l[a-zA-Z] ]]; then echo $linkline; fi; done | sort | uniq

Here's a slightly better version:

for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ ${linkline} =
- -l[a-zA-Z]* ]]; then echo $linkline; fi; done | sort | uniq

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+W4pXVaO67S1rtsRAmF+AKC5bNS6ZbxU6nlCJUG44VhBeC+w1ACgvziz
BrqUPIlvWnp0sx2MVM6A82M=
=VtA+
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-08 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
| What I meant by tomorrow was next week, of course. =) I just made
| the first commits.

Most things are committed, with the exception of the metabuilds. I'm
still working on them.

If you want to try it, you'll have to add a bunch of stuff to
package.unmask. Then emerge xorg-server, then whatever drivers you want
(look in x11-drivers/).

If you do unmerge your xorg-x11 install, you'll probably have to emerge
a few apps in x11-apps for things to work properly (xinit, xauth,
iceauth, xhost, mkfontdir/mkfontscale, xkbcomp. You'll also want to grap
xbitmaps, xkbdata and xcursor-themes from x11-misc.

Currently, it will overwrite parts of your xorg-x11 installation. I
purposely didn't set it to block yet so it would be possible to mix and
match parts to help find breakages.

If you find bugs that aren't purely ebuild problems, do not file them at
bugs.gentoo.org -- go to bugs.freedesktop.org, in the xorg product.

Two USE flags you will care about are dri and glx -- both are
necessary to get accelerated 3D.

The font-server flag may be necessary in libXfont, but I haven't fully
explored this yet. If it turns out to be the case, it'll be removed as
an optional flag and forced on.

I will be re-adding a few patches; in particular, the customized
startx/xinit stuff and the cursor paths (/usr/share/cursors and
/usr/local/share/cursors), along with anything else I consider
non-upstream material and worth my time.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC9xLjXVaO67S1rtsRAtshAKDqb28WYEJuvoGUD8XtpkOTVofIIgCeLVrt
dzNIOsWWOHiiogUG0yvTed4=
=sZIv
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-08 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ferris McCormick wrote:
| Donnie,
|   Unless you a good reason for me not to do so, I am going to start
| adding the ~sparc keyword to the Modular X ebuilds and then start
| playing with them locally.  (I'm not going to mess with your global
| package masks, of course, but I do want to work with a real ~sparc
| keyword rather than faking it.)

Fine w/ me.

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC95BPXVaO67S1rtsRAuQ8AJ4nLmwo4v/n7+XejmMSkQPAoBtd6wCfeA9P
oZDZOCtGjvCnvPb2NFXp60E=
=3yr0
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-08 Thread Caleb Tennis
On Monday 01 August 2005 03:54 pm, Donnie Berkholz wrote:
 I eagerly await your questions and concerns.

Donnie,

What is the plan for packages (I'm thinking other x11-libs/ packages and 
window managers) which can optionally depend on various X11 libraries?  Do we 
need use flags for xcursor, xrender,xsm and the like to pull in the 
deps?

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



Re: [gentoo-dev] Modular X plans

2005-08-08 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Caleb Tennis wrote:
| What is the plan for packages (I'm thinking other x11-libs/ packages and
| window managers) which can optionally depend on various X11 libraries?
 Do we
| need use flags for xcursor, xrender,xsm and the like to pull in the
| deps?

Optional dependence does suggest USE flags, yes. =)

But it might make more sense to have flags describing the functionality
rather than the package they build with; more like render and cursor.

In some cases, it may not make sense to have a flag at all and just
force it one way or the other.

If you could bring up some specific examples, we could discuss them.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+AOPXVaO67S1rtsRAqsOAKCcp6PGvjhcuQ+4+5jJWFQD6lrdLgCfcd6O
0vmiRv7g3ieI8JTlNLUCQKQ=
=j2fe
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-04 Thread Bertrand Jacquin
that's great :)

Thanks for doing that.
That's exactly what I done with XCB ebuilds. Maybe some of you don't
know xcb, it a remplacement for Xlib. Currently it only available on
cvs. I think it couldn't have to be ignore it.

Some ebuilds for :
http://guybrush.ath.cx/svn/public/portage/x11-libs/

Website :
http://freedesktop.org/Software/xcb

Also It's on heavy devlopment, and I'not a dev. So take the choice
you'll find the best :)

++
Beber

On 8/1/05, Donnie Berkholz [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 (This is an expanded, updated version of a recent blog post, so some of
 you may have already seen parts of it.)
 
 Background: Upstream is splitting up the monolithic X.Org X11 release
 into a huge number of modular releases, the combination of which will be
 released as X11R7. Simultaneously, a source-identical monolith will be
 released as X11R6.9.
 
 Gentoo will only add X11R7, the modular release. Roughly 280 packages
 will comprise this release, so this will entail adding a few new
 categories to deal with them.
 
 Here's the categories I'm looking at using, which is mostly a mirror of
 how upstream breaks it down:
 
 ~* x11-apps: The various applications that come along with all X11RX
 releases. 86 ebuilds.
 
 ~* x11-proto: The protocol headers. 30 ebuilds.
 
 ~* x11-libs: 43 ebuilds.
 
 ~* media-fonts: 35 ebuilds.
 
 ~* x11-drivers: All the video and input drivers. 68 ebuilds.
 
 ~* x11-base: The actual X server, and meta-ebuilds. 10 ebuilds.
 
 ~* app-doc: Old-format docs that haven't been broken into individual
 packages yet. Probably just a couple ebuilds.
 
 ~* x11-misc: The data module, which contains bitmaps and xkbdata.
 Also the util module, with imake, etc. 10 ebuilds.
 
 The new categories are x11-apps, x11-proto and x11-drivers. Of these,
 the name for x11-proto (the protocol headers) is debatable. The upstream
 module they're all in is called proto, and their pkg-config (*.pc)
 files are called fooproto. But I'm also open to names such as
 x11-protocol or x11-headers, so let me know what you think makes the
 most sense, both in understanding the meaning and in combination with
 upstream's naming.
 
 My plan is to have a series of submetabuilds that combine into a
 supermetabuild, which will be the actual xorg-x11 ebuild. There will
 be one submetabuild for each major component: apps, drivers, libraries,
 etc. This will allow me to split USE flags out a bit (so e.g., x11-fonts
 would have 100dpi, 75dpi, truetype as flags) as well as allow people who
 only want e.g. libraries for a headless server to get them cleanly.
 
 I intend to begin adding these packages to the tree shortly after the
 first release candidate, which should be happening very soon.
 
 
 Repercussions:
 
 All packages in the tree will need to clearly enunciate exactly which
 parts of X they need as DEPENDs and RDEPENDs, down to the library or
 application level.
 
 Until such time as that becomes possible for everyone to do, the
 x11-libs metabuild will PROVIDE virtual/x11. But realize that not
 everybody will have or want all the X libraries installed, when they
 only need a few.
 
 If your package depends on virtual/x11 for any reason besides libraries,
 it will require a dependency update to work with the new packages.
 
 
 My preliminary work on the modular ebuilds is at
 http://dev.gentoo.org/~spyderous/x-modular/ -- browse this at your
 leisure. The metabuilds are all in x11-base/. There will be no tarball
 of this overlay available because I'm not interested in dealing with
 other testers before the first release candidate has even come out.
 
 I eagerly await your questions and concerns.
 
 Thanks,
 Donnie
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.1 (GNU/Linux)
 
 iD8DBQFC7owDXVaO67S1rtsRAu68AJwISOSEwUChCvgQ96Y1KJGFmNYb/wCfaOEz
 WURqd84yUyrb9cJqmiZE6sc=
 =L4yH
 -END PGP SIGNATURE-
 --
 gentoo-dev@gentoo.org mailing list
 


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-03 Thread Diego 'Flameeyes' Pettenò
On Wednesday 03 August 2005 07:41, Donnie Berkholz wrote:
 If you want your patch back in, you will _need_ to file it upstream and
 have it committed before we will re-add it.
While I generally agree with this the closer to upstream, the better, I hope 
that this can be a bit more easy for compile-fixes for arches. Taking this 
upstream can need a bit of time as the problem can manifests just on a 
specific architecture (or os, thinking about g/fbsd) and there can be noone 
on upsteram to take care of that at the moment we need the fix.

I'm wondering about this because latest two snapshot from Xorg doesn't compile 
at all under G/FBSD.. while having it modular will probably resolve the issue 
(at that point we will just p.mask or not keyword a package until it's fixed, 
for example xconsole that doesn't work on fbsd), if the problem manifests in 
one of the core packages needs to be fixed ASAP.

[Unfortunately our parent project FreeBSD doesn't seem to send always the 
fixes upstream, that's why there can be problems that we need to address and 
report upstream at the same time]

-- 
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpNlCUQPhXRJ.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-02 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Donnie Berkholz wrote:
| The new categories are x11-apps, x11-proto and x11-drivers. Of these,
| the name for x11-proto (the protocol headers) is debatable. The upstream
| module they're all in is called proto, and their pkg-config (*.pc)
| files are called fooproto. But I'm also open to names such as
| x11-protocol or x11-headers, so let me know what you think makes the
| most sense, both in understanding the meaning and in combination with
| upstream's naming.

I'm still awaiting any solid arguments against x11-proto, and they had
best be expedited (read below for why).

| I intend to begin adding these packages to the tree shortly after the
| first release candidate, which should be happening very soon.

As I said, very soon. It's out. I will begin adding new categories as
necessary and the beginnings of the modular tree tomorrow.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC7w2ZXVaO67S1rtsRAom4AJ9r3J8Y8QzfNzSXD5ArbrIdh9xMnwCguB6k
UJ8lEfU6ex06MnENpZuJhhQ=
=CgWz
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-02 Thread Maurice van der Pot
On Mon, Aug 01, 2005 at 02:23:06PM -0700, Donnie Berkholz wrote:
 Your suggestion of adding a few new virtuals is a good idea, but I think
 the metabuilds for libraries, drivers, etc. can substitute for it. It's
 not clear to me that there are many common configurations that could be
 dealt with cleanly by a virtual in a better way, that also retains a low
 level of complexity in the ebuilds.

Regardless of whether it's gonna be virtuals or metabuilds, aren't we
going to have problems with mixed X installs (different parts from
different implementations)? 

Will we be able to make sure if the user emerges some app that requires 
library A from an X implementation and later emerges an application that 
requires library B, that A and B are taken from the same implementation?
If not, what would happen if the user later emerged the top-level xorg
ebuild?

Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   [EMAIL PROTECTED] http://www.gentoo.org
Creator of BiteMe!   [EMAIL PROTECTED]   http://www.kfk4ever.com



pgpLKiwNqXsUo.pgp
Description: PGP signature


Re: [gentoo-dev] Modular X plans

2005-08-02 Thread Jeremy Maitin-Shepard
If I understand correctly, all of the packages in x11-proto will only
install header files.  Are these header files ever useful on their own
though?  Would it make more sense to include the header files
in various library packages?

-- 
Jeremy Maitin-Shepard
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-02 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremy Maitin-Shepard wrote:
| If I understand correctly, all of the packages in x11-proto will only
| install header files.  Are these header files ever useful on their own
| though?  Would it make more sense to include the header files
| in various library packages?

No, we follow what upstream does. This saves us from needing to bump
headers when a library changes, bump a library when a header changes,
and also has the benefit that the headers are just DEPENDs so you can
uninstall them all after you finish compiling.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC7893XVaO67S1rtsRAi9uAJ95DNAPqhA3Dhv9QJqY6RGklbYewACfbbLQ
oDnkXPNFW1MWKkPozs2jAVU=
=Q/tK
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-02 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As a further note on this:

We will be dropping all patches that are not upstream and are not
obviously Gentoo-specific configuration changes.

If you want your patch back in, you will _need_ to file it upstream and
have it committed before we will re-add it.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC8FkNXVaO67S1rtsRAsgiAJ4ruYXDyve6ylMfoNTo9OTiXpoMUACdFY6r
iJ43g2kO5003+Fs3IlCfHlU=
=O/54
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Ciaran McCreesh
On Mon, 01 Aug 2005 13:54:27 -0700 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| Until such time as that becomes possible for everyone to do, the
| x11-libs metabuild will PROVIDE virtual/x11. But realize that not
| everybody will have or want all the X libraries installed, when they
| only need a few.
| 
| If your package depends on virtual/x11 for any reason besides
| libraries, it will require a dependency update to work with the new
| packages.

I'd suggest keeping virtual/x11 as a 'full, complete, everything X', and
adding in a few new virtuals to take care of the common dependency
configurations. Remember, versioned virtual deps should be eschewed...

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
| On Mon, 01 Aug 2005 13:54:27 -0700 Donnie Berkholz
| [EMAIL PROTECTED] wrote:
| | Until such time as that becomes possible for everyone to do, the
| | x11-libs metabuild will PROVIDE virtual/x11. But realize that not
| | everybody will have or want all the X libraries installed, when they
| | only need a few.
|
| I'd suggest keeping virtual/x11 as a 'full, complete, everything X', and
| adding in a few new virtuals to take care of the common dependency
| configurations. Remember, versioned virtual deps should be eschewed...

The virtual will retain its meaning, as I have always publicized it to
be the libraries and not the X server or anything else. That's why
kdrive doesn't provide it, among other things. Having x11-libs provide
the virtual should also work the best for headless X servers, which have
been in fairly high demand.

Your suggestion of adding a few new virtuals is a good idea, but I think
the metabuilds for libraries, drivers, etc. can substitute for it. It's
not clear to me that there are many common configurations that could be
dealt with cleanly by a virtual in a better way, that also retains a low
level of complexity in the ebuilds.

Frankly, the only reason the virtual will even exist after the 7.0
release is so people have time to play catch-up. I don't want the
virtual to stay in use.

If you could provide some examples of how the virtuals would be more
helpful to other devs, I'd enjoy hearing (or reading) them.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC7pK5XVaO67S1rtsRAq+gAJ9uwg60S2OTt982efkLyPXcI6ZXlgCaAmyA
buyybKLsk3fRCKOZ7nfsP8w=
=qEkI
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Ciaran McCreesh
On Mon, 01 Aug 2005 14:23:06 -0700 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| Your suggestion of adding a few new virtuals is a good idea, but I
| think the metabuilds for libraries, drivers, etc. can substitute for
| it. It's not clear to me that there are many common configurations
| that could be dealt with cleanly by a virtual in a better way, that
| also retains a low level of complexity in the ebuilds.

Well... What I was mainly thinking (and assuming we don't have the new
virtuals system by whenever this becomes relevant) is that a metapackage
could represent, say, the core x11 libraries as provided by xorg. This
is all well and good, but there are other X implementations out there.
It could well save a lot of work in the long term if deps were generally
upon the core x11 libraries instead.

| Frankly, the only reason the virtual will even exist after the 7.0
| release is so people have time to play catch-up. I don't want the
| virtual to stay in use.

Is it your assumption that in the future xorg-x11 will be the only
serious X server?

*shrug* I realise we make similar assumptions about a lot of packages,
but X is a) an at least vaguely standard protocol, b) heavily depended
upon and c) implemented by more than one vendor.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
| Well... What I was mainly thinking (and assuming we don't have the new
| virtuals system by whenever this becomes relevant) is that a metapackage
| could represent, say, the core x11 libraries as provided by xorg. This
| is all well and good, but there are other X implementations out there.
| It could well save a lot of work in the long term if deps were generally
| upon the core x11 libraries instead.

But see, that's the thing; no packages should just generally say Give
me the X libraries other than temporarily. They should be specifically
demanding upon the exact libraries they require.

| Is it your assumption that in the future xorg-x11 will be the only
| serious X server?

My assumption is that if there's another fork, it will be easier to deal
with || ( xorg-libfoo forkx-libfoo ) than a virtual for every single
package X provides.

| *shrug* I realise we make similar assumptions about a lot of packages,
| but X is a) an at least vaguely standard protocol, b) heavily depended
| upon and c) implemented by more than one vendor.

Indeed. But what I've begun to discover is that virtuals aren't always
the best solution when there is more than one provider, much less when
that's a largely hypothetical question.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7pn8XVaO67S1rtsRApYwAJ4wTzdCv2E8Lf9Yu5rjEVC+tZIGdACg6cOT
yNxBHXc4DpBh3e8r76pBFrc=
=vWPO
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
| On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
| [EMAIL PROTECTED] wrote:
| | Ciaran McCreesh wrote:
| | But see, that's the thing; no packages should just generally say Give
| | me the X libraries other than temporarily. They should be
| | specifically demanding upon the exact libraries they require.
|
| Hrm. Is this going to be sanely doable by your average dev? How long
| a dep string would we be having in typical cases? How about in bad
| cases?

It shouldn't be difficult in most cases, for those capable of finding
linker lines in a build.

I wrote a quick one-liner that works reasonably well on a couple of
tests, but could use a little tweaking. Just set log to your build log
beforehand.

for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ ${linkline} =~
-l[a-zA-Z] ]]; then echo $linkline; fi; done | sort | uniq

I ran it on gedit and thunderbird and got largely reasonable output. In
gedit's case, there would be 5
X library dependencies. In thunderbird's case, there would be 9.

| | | Is it your assumption that in the future xorg-x11 will be the only
| | | serious X server?
| |
| | My assumption is that if there's another fork, it will be easier to
| | deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every
| | single package X provides.
|
| So X deps will be by package ('either xorg-libfoo or forkx-foo or
| sgi-x'), rather than by concept in the future?

This makes more sense to me, particularly given the objection people
have to adding new virtuals. Adding a hundred or two wouldn't make them
happy.

| | | *shrug* I realise we make similar assumptions about a lot of
| | | packages, but X is a) an at least vaguely standard protocol, b)
| | | heavily depended upon and c) implemented by more than one vendor.
| |
| | Indeed. But what I've begun to discover is that virtuals aren't always
| | the best solution when there is more than one provider, much less when
| | that's a largely hypothetical question.
|
| Mmm, possibly true. For the big things though, I was hoping we could
| switch more towards depending by concept rather than by implementation,
| especially once we get improved virtuals. The current X situation is
| sort of a concept dependency -- moving away from that could arguably be
| seen as a regression from one perspective.

It could be, but X is no longer a big thing. It's a few hundred small ones.

Thanks for your ideas,
Donnie

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7qP6XVaO67S1rtsRAhAQAKC2hBxwGSV3RJDZaKK/bAm9fF2kDgCeP7qo
vPyx7bXz6vKDWEEGtI4LMng=
=ZPiY
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Alec Warner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
 [EMAIL PROTECTED] wrote:
 | Ciaran McCreesh wrote:
 | | Well... What I was mainly thinking (and assuming we don't have the
 | | new virtuals system by whenever this becomes relevant) is that a
 | | metapackage could represent, say, the core x11 libraries as
 | | provided by xorg. This is all well and good, but there are other X
 | | implementations out there. It could well save a lot of work in the
 | | long term if deps were generally upon the core x11 libraries
 | | instead.
 | 
 | But see, that's the thing; no packages should just generally say Give
 | me the X libraries other than temporarily. They should be
 | specifically demanding upon the exact libraries they require.
 
 Hrm. Is this going to be sanely doable by your average dev? How long
 a dep string would we be having in typical cases? How about in bad
 cases?
 
  The more formal the depstring, the quicker the packages build ( using
only needed packages instead of lumping them in one group ).  This is
essentially what the DEPEND should be, just what the packages needs to
compile and run.  This especially benefits embedded targets who need a
bare-bones set of libraries and nothing else.
 | | Is it your assumption that in the future xorg-x11 will be the only
 | | serious X server?
 | 
 | My assumption is that if there's another fork, it will be easier to
 | deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every
 | single package X provides.
 
 So X deps will be by package ('either xorg-libfoo or forkx-foo or
 sgi-x'), rather than by concept in the future?
 
  I think concepts are important and abstract complexity from a packages
DEPEND.  However, having the DEPEND be accurate is important as well.
This almost reeks of the USE group GLEP being applied here as well.
Setting up DEPEND-set would be great for this, although it is difficult
to imagine sets that can be shared between many packages.  eclasses are
marginally decent for this right now anyway.

 | | *shrug* I realise we make similar assumptions about a lot of
 | | packages, but X is a) an at least vaguely standard protocol, b)
 | | heavily depended upon and c) implemented by more than one vendor.
 | 
 | Indeed. But what I've begun to discover is that virtuals aren't always
 | the best solution when there is more than one provider, much less when
 | that's a largely hypothetical question.
  The problem with the individual approach is if I wanted to run XFree,
or a competing X implementation, I have to add about 200+ packages to
/etc/portage/package.provided.  This is not clean at all; it's hideous.
If I add the meta-build to /etc/portage/package.provided it just means
that I am managing the meta-ebuild and it is valid to count it as
installed for dep calculation.  This is not true of any of the
dependencies of the meta-ebuild however.  Thats just what I remember fro
m discussion about it, so correct me if it's wrong ;)

 
 Mmm, possibly true. For the big things though, I was hoping we could
 switch more towards depending by concept rather than by implementation,
 especially once we get improved virtuals. The current X situation is
 sort of a concept dependency -- moving away from that could arguably be
 seen as a regression from one perspective.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQu6u+GzglR5RwbyYAQI+Jw/+NZ1e0S687AjvBFwbK9qOGekgjd37WIxk
w5Y+t66OgULeU9XTNRW9hLY63Eg7q5nOByAH4HyUwntrgPTHr9s3c/GhP80f4Jwa
cDfhSnR6axMaNS5CgmZ/DyrfVGlCPTa6JWWdjt9rTcuFIIx1/SbMxcGcg0Lv7JJE
SCGchwugKOjoy+uhsEDVh6/nUhzdb/Nj5wsz/CbNdFPtnob87w/iTB0AVcNyXn2T
fJ4q5Lvrmb1/CyUso26am2dpAw+0xY0kmWSDzBxiMPbP06zX39ZrMEkTxLfsQoZO
ISVQmQ5K532qWpziSaktDtzKdxcw+vJU9ObelJX2deGyurl7mUxfjALoQ702eSI7
1Bmx9QqvtGWWmzDRtw1VNXr0645QKX+HFsPR1o9vZHqT2orKLs6FcHTjNKr6nCRx
Y0ixYRSSwk5Ik3WeG/3ydNJs45NrcOa9qE66uU9OIvM+ONIxVTey6WpF/XGHqcC/
6K8QiQw1eJV5qIK3vH72dZ+B+Bk9fYX3Pn+q7gVLYHFekCIVwxZu0R6wWkQIcgAt
fb6WLILnduo4wvDdgRToTswdaQbxP5qaX7Y4uB1PerXDgwG4/kVK+ZhYVjhJpnN2
nj38OBLQZUJ0WaiReYygiFz1ePiaAWG4Fy2uH/kNUFsHt0QvjFnzkw+7s9/dst6t
j42vluI+/fk=
=O+1e
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Modular X plans

2005-08-01 Thread Ciaran McCreesh
On Mon, 01 Aug 2005 19:23:37 -0400 Alec Warner [EMAIL PROTECTED]
wrote:
|  Hrm. Is this going to be sanely doable by your average dev? How
|  long a dep string would we be having in typical cases? How about in
|  bad cases?
|  
|   The more formal the depstring, the quicker the packages build (
|   using
| only needed packages instead of lumping them in one group ).  This is
| essentially what the DEPEND should be, just what the packages needs to
| compile and run.  This especially benefits embedded targets who need a
| bare-bones set of libraries and nothing else.

The problem is... By hard-coding a bunch of xorg packages, you're making
your DEPEND *less* accurate. Most packages will build just fine with
other X implementations.

Mmm, but for now this is pretty much a pointless argument. We're not a
real metadistribution yet :)

|   I think concepts are important and abstract complexity from a
|   packages
| DEPEND.  However, having the DEPEND be accurate is important as well.
| This almost reeks of the USE group GLEP being applied here as well.
| Setting up DEPEND-set would be great for this, although it is
| difficult to imagine sets that can be shared between many packages. 
| eclasses are marginally decent for this right now anyway.

GLEP 37 allows that, in effect.

Speaking of GLEP 37... Jason -- I'm assuming that virtual-x11/ (say)
would be possible?

|   The problem with the individual approach is if I wanted to run
|   XFree,
| or a competing X implementation, I have to add about 200+ packages to
| /etc/portage/package.provided.  This is not clean at all; it's
| hideous. If I add the meta-build to /etc/portage/package.provided it
| just means that I am managing the meta-ebuild and it is valid to count
| it as installed for dep calculation.  This is not true of any of the
| dependencies of the meta-ebuild however.  Thats just what I remember
| fro m discussion about it, so correct me if it's wrong ;)

Providing a specific metapackage is a bad idea. What if a package really
does depend upon xorg? Providing a specific concept would be better.
Whether such a thing is implementable currently is up for debate...

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list