Re: [gentoo-dev] Modular X plans
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
-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
-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
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
-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
-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
-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
-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
-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
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
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
-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
-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
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
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
-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
-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
-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
-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
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
-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
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
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
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
-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
-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
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
-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
-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
-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
-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
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
-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
-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
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
-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
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
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
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
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
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
-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
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
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
-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
-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
-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
-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
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
-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
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
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
-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
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
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
-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
-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
-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
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
-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
-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
-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
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
