[gentoo-dev] Modular X plans

[gentoo-dev] Modular X plans

[Donnie Berkholz]

-----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

Re: [gentoo-dev] Modular X plans

[Ciaran McCreesh]

On Mon, 01 Aug 2005 13:54:27 -0700 Donnie Berkholz
<spyderous@gentoo.org> 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

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
| On Mon, 01 Aug 2005 13:54:27 -0700 Donnie Berkholz
| <spyderous@gentoo.org> 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

[Ciaran McCreesh]

On Mon, 01 Aug 2005 14:23:06 -0700 Donnie Berkholz
<spyderous@gentoo.org> 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

[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

[Ciaran McCreesh]

On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
<spyderous@gentoo.org> 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.

Hrmmmmm. 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?

| | 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?

| | *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.

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

Re: [gentoo-dev] Modular X plans

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
| On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
| <spyderous@gentoo.org> 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.
|
| Hrmmmmm. 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

[Alec Warner]

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

Ciaran McCreesh wrote:
> On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz
> <spyderous@gentoo.org> 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.
> 
> Hrmmmmm. 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

[Ciaran McCreesh]

On Mon, 01 Aug 2005 19:23:37 -0400 Alec Warner <warnera6@egr.msu.edu>
wrote:
| > Hrmmmmm. 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

Re: [gentoo-dev] Modular X plans

[Alec Warner]

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

Ciaran McCreesh wrote:
> On Mon, 01 Aug 2005 19:23:37 -0400 Alec Warner <warnera6@egr.msu.edu>
> wrote:
> | > Hrmmmmm. 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.
[1]  Yes but at present we have only 1 provider of X11 in the tree
(xorg).  If we were to make a bunch of virtuals (concepts if you will),
then all packages should/will work fine with xorg, because they are all
tested with xorg.  Then all of a sudden a new X server comes out, call
it Foo.  So we add Foo to our virtual/concept and things break...because
no one has tested every package with Foo, it's only been tested with xorg.

> 
> 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...
> 
[2]  Virtuals are basically concepts, things are only added to
virtual/mta fex, when they fulfill the concept and real-world
requirements of mta.  As long as one can define exactly what the
real-world requirements of each x11 concept is, then it shouldn't be a
problem.  Mostly this is a discussion with x11 geeks about the standard.

To sum up the two pieces of the above.  In order to prevent [1] we need
to come up with an agreement on what constitutes each concept/virtual
[2].  Virtual/x11 was originally for xfree/xorg migration, but I don't
believe that there is any kind of agreed upon requirement set for a
package to be added to virtual/x11.  A quick grep of the tree shows 2115
ebuilds DEPEND on x11, which is a lot of ebuilds to do QA on for any new
 x11 provider.  Most other virtuals adhere to a simple binary interface
( call sendmail, mail is sent), as opposed to X11's library based
interface (although it has binaries as well.)

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

iQIVAwUBQu7I5mzglR5RwbyYAQLJdg/+OQf8MY16CMkmR4mceDPH+uTO+4dMwiqt
MUVuXm520bH5jD0dITogxrPWNMZXLPY2topENKoCsvM0ex1hqB3/mNs9WcXre27a
4QtowNX4rFG2oBSxFUEphvJD+dH9XUptBUaecL+g286G9rqlc6DNvl7LfHTokCa6
TmG2sbArEofOQpQOa4YPDfahUp9Bzvmusb9gLKHtMPIGokbmD4fSLhNVlAsqjH9L
mrs6a+ZNt1GzOVAuDnnDUYYgIhHk5J4EEPTnqfZ4ByaKokUCSSMzzJ+fJDTkNBe9
Zz++vAcR2QaER0jvL3r99r4xMM/MYzrQMG+tbZ3i8UY/RQZ5u886s4K899bcAA0s
qa0W9xP61vtxghQy60tkmdvFi3y+GVRGrNwVlPi82Mi8nrCBN19sj9N6k2xVetnr
esJmZ7mL+JA0gmXAfGTZ8DUpi8huPwYtKcDBRTq7F9fpPGchiy/IXTnizcv5bQF8
C0ADKSdNshKasr/iGWfP+pGgCMWDsEOqe9hR8phRoECx6N0xCRPgfP/chvKIumvs
oqVW2EEB0Wk6f3vUmp/vE5qIFX1T3UQGNkHtdRnwn48Btj/C0FfuEdmGqyCbR+Yp
u/jW4AZGL8MrbkpbUIzJyR7gAYe3MAYt3QcBFgRuEX2W2bhD+K7R2jy3rfzEkLx4
dcXCpCyuqSM=
=7TLN
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[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

[Ian Leitch]

Donnie Berkholz wrote:
> -----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 don't dislike x11-proto, x11-headers is just a little more descriptive 
from the perspective of an ignorant user. More informed users know that 
X is the actual protocol, so x11-proto could read to them as "protocol 
protocols", or "protocols of a protocol". Besides, we have category 
metadata anyway.

Regards,
Ian.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Modular X plans

[Michael Sterrett -Mr. Bones.-]

On Mon, 1 Aug 2005, Donnie Berkholz wrote:

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

Well, I kind of mentioned it on irc, but I'll throw it out here too.
I think the name "proto" is pretty vague and would prefer
to see headers (ala sys-kernel/linux-headers, etc.) but since upstream
uses that name, I guess I can live with it.

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Maurice van der Pot]

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

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   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

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

[Kevin F. Quinn]

On 2/8/2005 16:30:45, Michael Sterrett -Mr. Bones.- (msterret@coat.com) wrote:
> On Mon, 1 Aug 2005, Donnie Berkholz wrote:
> 
> > I'm still awaiting any solid arguments against x11-proto, and they had
> > best be expedited (read below for why).
> 
> Well, I kind of mentioned it on irc, but I'll throw it out here too.
> I think the name "proto" is pretty vague and would prefer
> to see headers (ala sys-kernel/linux-headers, etc.) but since upstream
> uses that name, I guess I can live with it.

IMHO living with the upstream name is worth more than renaming to 'x11-headers'.
It isn't an extraction/repackaging of something else (c.f. sys-kernel/linux-headers),
which would be implied by a name different from upstream.  x11-proto does include
the docs for the apis as well, so that's a small point against renaming to x11-headers.
In the long term, people programming to the x11 protocol will be conditioned to
program against the upstream 'proto' module, so sticking with that name shouldn't
really cause any confusion.

Kev.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[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

[Diego 'Flameeyes' Pettenò]

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

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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 <spyderous@gentoo.org> 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

[Donnie Berkholz]

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

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

What I meant by "tomorrow" was "next week," of course. =) I just made
the first commits.

Please let me know if I accidentally break anything while I'm at it.

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

iD8DBQFC9sisXVaO67S1rtsRAuCHAKDbQSFKK/ImvUK0GhEJlvDbgIh/uACgn/TK
S/467WUc0HGWjnwgY9NqPq0=
=gf6h
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[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

[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

[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

[Georgi Georgiev]

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

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,      >
<     chutz@gg3.net    <  then someone will do it. -- Edward A.        <
 >  +81(90)2877-8845    > Murphy Jr.                                    >

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[Brian Harring]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[Carsten Lohrke]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Modular X plans

[Donnie Berkholz]

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

Georgi Georgiev wrote:
| 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.

I think this USE flag was inappropriate, because the X Font Server is
distinct from X Font Services, which it was really controlling.

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

iD8DBQFC+PCxXVaO67S1rtsRAlKEAJ4s7My+Z1PlY7uNcdgib4kWFeUJyACggMpm
Y7yBMEtQGen6xa7+7Ep/tas=
=mzTh
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[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

[Donnie Berkholz]

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+PMTXVaO67S1rtsRArwHAKCNyGwgm8RZd8/RKtTYuXhar/iJKgCg2xGC
HRnUdluQNTsYeU+NSb1FGFA=
=j1P7
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Georgi Georgiev]

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

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         \
 /    chutz@gg3.net     / recover. -- Dorothy Fuldheim                  /
\   +81(90)2877-8845   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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   /\
\/    chutz@gg3.net    \/ 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

[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

[Donnie Berkholz]

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

Donnie Berkholz wrote:
| Ciaran McCreesh wrote:
| | Hrmmmmm. 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

[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.

As of 1 minute ago, I've added everything I can figure out needs to be
added for OpenGL to work properly.

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

iD8DBQFC+aY+XVaO67S1rtsRAlVGAJ4285AXMkriYm8mVvpapCMe/lRKGACfbTy5
ac0v4P3r9ibrqPbKr9rpTNs=
=XzC3
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

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

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.

If fact, I think this is a regression.  I know that at one point, at
least, I had opened a bug on this, and it was resolved.  I can't find
any record of it, though, at bugs.freedesktop.org (my original was filed
long ago at sourceforge).

The point is that libGL performance is important for those who use it,
and on sparc, we meed to keep whatever the user asked for with -mcpu=xxx
(-mv8 is just wrong on ultrasparc unless you can't build with it for
some reason, but libGL can build with it).  Further, and problems with
using sparc assembly on linux were corrected long ago, so sparc really
should -DUSE_SPARC_ASM. I am sure the USE_SPARC_ASM bit is also a
regression, because I remember when Mesa was corrected to figure out
correctly whether or not ultrasparc was building for 32-bit user mode or
for 64-bit user mode. (Mesa-6.3.1.1 uses "#ifdef __arch64__" as the
test, and it turns out that gcc does not define this just for
-mcpu=ultrasparc[3], so assembly code should be fine.)

For reference, current xorg-x11 (on ultrasparc3) builds libGL with,
among lots of other CFLAGS, "-O2 -mcpu=ultrasparc3 -DUSE_SPARC_ASM ..."
the first two of which are taken from my CFLAGS.

Of course, all of this might be irrelevant, but I'd rather raise the
concern and be beat up on now than come back later and say "Oh, by the
way, libGL build is all messed up on sparc." :-)

(Point is that xorg-x11 nowadays gets libGL & friends right for
linux-sparc, but Mesa by itself does not, and has regressed from earlier
versions.  So X Modular should configure Mesa as it does now --- for
xorg --- not as Mesa has built-in, which looks wrong.)

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

[-- Attachment #1.1: Type: text/plain, Size: 2753 bytes --]

On Wed, 2005-08-10 at 12:46 +0000, 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
000000 +0000
+++ mesa-6.3.1.1.ebuild 2005-08-10 15:03:22.000000000 +0000
@@ -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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

[-- Attachment #1.2: S --]
[-- Type: text/plain, Size: 1141 bytes --]

--- /home/cvsroot/gentoo-x86/media-libs/mesa/mesa-6.3.1.1.ebuild	2005-08-10 06:42:09.000000000 +0000
+++ mesa-6.3.1.1.ebuild	2005-08-10 15:03:22.000000000 +0000
@@ -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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[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

[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

[Donnie Berkholz]

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

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?

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

iD8DBQFC+lpXXVaO67S1rtsRAsxlAKC2mctGoHa1w7RJeF8ukcz2pH2YIACeJTh1
99JTVhzGryIloUEcLAXiGww=
=dQOi
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[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

[Ferris McCormick]

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

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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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) <fmccor@gentoo.org>
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

[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.

donnie@supernova
/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

[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.
>
> donnie@supernova
> /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 xxxx_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) <fmccor@gentoo.org>
Developer, Gentoo Linux (sparc, devrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+ptFQa6M3+I///cRAja3AJ93r592HPu8k9riqsvhJEDGz+ZntACgjqOv
Q13+BsRVaZ2v4xoa4Pvi/B0=
=nCQQ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Donnie Berkholz]

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

Ferris McCormick wrote:
| 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.

I don't see why mesa should have a glx USE flag, unless you're referring
to a flag in xorg-server?

| 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.

I still don't understand why they wouldn't just build a glx-using libGL
instead of an Xlib-using libGL. This would mean setting a blank DRI_DIRS
and keeping DRIVER_DIRS = mesa.

I can understand, however, that one might like to avoid building the DRI
drivers with a USE=dri flag.

In fact, you've actually convinced me that the glx USE flag as a whole
is probably a bad idea and I should always force it on in xorg-server too.

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

iD8DBQFC+p/nXVaO67S1rtsRAtX2AKC0tCW1WwHURu1ZYGdoTiu3dOwEVACg1ueW
tYBYd/QFC8xbf5mSE8sJymg=
=O7eX
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Georgi Georgiev]

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

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   \
/     chutz@gg3.net    /  far behind?"                                 /
\   +81(90)2877-8845   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[Donnie Berkholz]

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

-----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-----

[-- Attachment #2: opengl-update-modules.patch --]
[-- Type: text/x-patch, Size: 590 bytes --]

--- opengl-update.orig	2005-08-10 21:17:32.000000000 -0700
+++ opengl-update	2005-08-10 21:17:47.000000000 -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

[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

[Georgi Georgiev]

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

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    *)
(*    chutz@gg3.net    (* dozen JORDACHE JEANS because my viewscreen   (*
*)  +81(90)2877-8845   *) is "USER-FRIENDLY"!!                         *)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[Georgi Georgiev]

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

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.

Hm, why not just forget the transition, stick a warning telling people
to add

ModulesPath "/usr/lib/modules"
ModulesPath "/usr/lib/xorg/modules"

in xorg.conf and forget about it?

-- 
\    Georgi Georgiev   \  <Marticus> There's too much blood in my      \
 /    chutz@gg3.net     / caffeine system.                              /
\   +81(90)2877-8845   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[Jason Wever]

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

On Thu, 11 Aug 2005, Ferris McCormick wrote:

>> |   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.

The few times I have tried this, I hadn't been using that screen res/combo 
so that could be a problem.

mach64 shows up a few ways on SPARC which can make life tricky.  In the 
Ultra 5/10 boxes, it comes as an onboard framebuffer in either 2MB or 4MB 
RAM sizes depending on the age of the box.  Similarly, the Blade 100/150 
has a mach64 with 8MB of RAM onboard (which is what I tested DRI on many 
moons ago).  Also there is the PGX24 framebuffer IIRC which is a PCI card 
version of the mach64 that can be used in machines like an Ultra 30 or 60 
where there is no onboard framebuffer.


Another note is that the radeon driver should probably be considered for 
the DRI list as the XVR-100 Sun framebuffer is a rebranded ATI Radeon 7000 
VE.  I have one I can test with/on once I get back from LWE.

Cheers,
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+uyAdKvgdVioq28RAvefAKC2MrZSO5O89ui/DYf6WLg+F2Ui5wCgohXd
AJIIytvNXCV7nU8/IOzFjTA=
=lnRz
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Georgi Georgiev]

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

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      -*
*-    chutz@gg3.net    *- you ever said that?" "NO! ... I mean Yes!    *-
-*  +81(90)2877-8845   -* WHAT?" "I'll put `maybe.'" -- Bloom County   -*

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[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

[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

[Ferris McCormick]

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

On Wed, 2005-08-10 at 17:46 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ferris McCormick wrote:
> | 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.
> 
> I don't see why mesa should have a glx USE flag, unless you're referring
> to a flag in xorg-server?

I was refering to the USE=glx flag for the xorg-server, not a new flag
for mesa.
> 
> | 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.
> 
> I still don't understand why they wouldn't just build a glx-using libGL
> instead of an Xlib-using libGL. This would mean setting a blank DRI_DIRS
> and keeping DRIVER_DIRS = mesa.
> 

I don't know yet.

> I can understand, however, that one might like to avoid building the DRI
> drivers with a USE=dri flag.
> 

Right.  On my afb (Elite) systems, the only reason I ever have for
building dri drivers is to see if they build; afb has never been dri
capable.

> In fact, you've actually convinced me that the glx USE flag as a whole
> is probably a bad idea and I should always force it on in xorg-server too.
> 
> Thanks,
> Donnie

Regards,
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

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

On Wed, 2005-08-10 at 17:46 -0700, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ferris McCormick wrote:
> | 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.
> 
After a lot of experimenting, I have concluded the following:
1.  The mesa build source tree has been rearranged enough that getting
sparc assembly code to work properly is not trivial.  Instead of
building the assembly versions of the code for sparc into base libGL,
the build puts into all the dri drivers instead, thereby leaving
undefined externals if you link against libGL.  So, those flags are not
defined in the builtin mesa targets for a good reason.

2.  In case of USE=dri, for sparc right now this looks like a good set
of drivers:  DRI_DIRS = fb ffb mach64 mga radeon savage

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, but no dri drivers.

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.

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.

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[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

[Donnie Berkholz]

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

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC+5/XXVaO67S1rtsRAkmjAJ0Zangro1+L9VlOeIR8Ga0z0mlrXgCeNgZQ
4ZHVBoPBHG54mUPkctkWiOQ=
=K5ki
-----END PGP SIGNATURE-----

[-- Attachment #2: linking_libs.sh --]
[-- Type: application/x-shellscript, Size: 1366 bytes --]

Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

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

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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[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
jan.spitalnik@sun.com

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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[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

[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

[Georgi Georgiev]

maillog: 11/08/2005-21:11:35(+0200): Jan Spitalnik types
> 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

The script currently breaks with static libs.

The fix is:

- remove the $( -- no need to execute the output of the grep in a
  subshell.
- make the "grep static" a "grep -q static" -- we don't need to see
  the lines that match "static"

-- 
*>   Georgi Georgiev   *> There's a little picture of ED MCMAHON       *>
<*    chutz@gg3.net    <* doing BAD THINGS to JOAN RIVERS in a         <*
*>  +81(90)2877-8845   *> $200,000 MALIBU BEACH HOUSE!!                *>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

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

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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[Georgi Georgiev]

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

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        \
 /    chutz@gg3.net     / sends in terrific bills. -- Minna Antrim,     /
\   +81(90)2877-8845   \  "Naked Truth and Veiled Allusions"           \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[Donnie Berkholz]

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

-----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-----

[-- Attachment #2: linking_libs.sh --]
[-- Type: application/x-shellscript, Size: 1402 bytes --]

Re: [gentoo-dev] Modular X plans

[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

[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) <fmccor@gentoo.org>
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

[Donnie Berkholz]

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

-----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-----

[-- Attachment #2: linking_libs.sh --]
[-- Type: application/x-shellscript, Size: 1917 bytes --]

Re: [gentoo-dev] Modular X plans

[Georgi Georgiev]

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

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         /
\     chutz@gg3.net    \  Hilbert                                      \
/   +81(90)2877-8845   /                                               /

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Modular X plans

[Donnie Berkholz]

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

-----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-----

[-- Attachment #2: linking_libs.sh --]
[-- Type: application/x-shellscript, Size: 1958 bytes --]

Re: [gentoo-dev] Modular X plans

[Georgi Georgiev]

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

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.

chutz@lion ~ $ echo 'a -lbcd' | grep -- '-l'
a -lbcd
chutz@lion ~ $ echo 'a -lbcd' | grep -- '\b-l'
chutz@lion ~ $ 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       \
 /    chutz@gg3.net     / good today.                                   /
\   +81(90)2877-8845   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]