Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georgi Georgiev wrote: | Hm, why not just forget the transition, stick a warning telling people | to add | | ModulesPath /usr/lib/modules | ModulesPath /usr/lib/xorg/modules Needing to set ModulePath at all in a standard installation is broken. This shouldn't need to be in a configuration file; none of the tools I'm aware of generate files with ModulePath by default, and it really doesn't make sense to. xorg.conf is difficult and user-unfriendly enough to set up already without adding more Gentoo-only requirements to it. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+um6XVaO67S1rtsRAhOBAJwMfozXGAjqqS7K9G4TEXbfMEQS+wCfcruP VDFJZWfMCT5r3zE/N9b6QUg= =Xs0h -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
maillog: 10/08/2005-23:01:30(-0700): Donnie Berkholz types Georgi Georgiev wrote: | Hm, why not just forget the transition, stick a warning telling people | to add | | ModulesPath /usr/lib/modules | ModulesPath /usr/lib/xorg/modules Needing to set ModulePath at all in a standard installation is broken. This shouldn't need to be in a configuration file; none of the tools I'm aware of generate files with ModulePath by default, and it really doesn't make sense to. xorg.conf is difficult and user-unfriendly enough to set up already without adding more Gentoo-only requirements to it. Mmmm, xorgcfg does generate an xorg.conf with ModulePath in it. That's why I had it in mine in the first place. Anyway, I agree with your other points. maillog: 10/08/2005-22:08:36(-0700): Donnie Berkholz types Georgi Georgiev wrote: | What about new revisions of the monolithic xorg that will install in | /usr/lib/xorg/modules followed by new revisions of all packages like | opengl-update, nvidia, ati-whatever, that will depend on the newer xorg | release? We still need to deal with the transition either way. We can't just ignore everything that's installed in /usr/lib/modules when we upgrade xorg. I did not really understand the above. What I had in mind was making the transition now, rather than later. This would avoid the need for parallel ebuilds of all packages and if the appropriate packages block on appropriate revisions, it shouldn't cause much hassle. Unlike the /usr/X11R6 - /usr move, there are only a few packages that install x modules (does anyone know how many packages these are?) so upgrading said packages shouldn't be much of a hassle. I never thought about ignoring /usr/lib/modules. -- -* Georgi Georgiev -* Then you admit confirming not denying -* *-[EMAIL PROTECTED]*- you ever said that? NO! ... I mean Yes!*- -* +81(90)2877-8845 -* WHAT? I'll put `maybe.' -- Bloom County -* pgpUUcZ2drI5K.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georgi Georgiev wrote: | maillog: 10/08/2005-23:01:30(-0700): Donnie Berkholz types |Needing to set ModulePath at all in a standard installation is broken. |This shouldn't need to be in a configuration file; none of the tools I'm |aware of generate files with ModulePath by default, and it really |doesn't make sense to. | |xorg.conf is difficult and user-unfriendly enough to set up already |without adding more Gentoo-only requirements to it. | | | Mmmm, xorgcfg does generate an xorg.conf with ModulePath in it. That's | why I had it in mine in the first place. Anyway, I agree with your other | points. OK, so one of them does. And I still consider that broken behavior. |We still need to deal with the transition either way. We can't just |ignore everything that's installed in /usr/lib/modules when we upgrade xorg. | | | I did not really understand the above. What I had in mind was making the | transition now, rather than later. This would avoid the need for | parallel ebuilds of all packages and if the appropriate packages block | on appropriate revisions, it shouldn't cause much hassle. Unlike the | /usr/X11R6 - /usr move, there are only a few packages that install x | modules (does anyone know how many packages these are?) so upgrading | said packages shouldn't be much of a hassle. I never thought about | ignoring /usr/lib/modules. There are a couple of reasons this isn't very interesting to me. 1) It involves work on the monolithic package, which I'd rather not spend any more time on. 2) Keeping all changes in one big chunk makes for an easier transition than spreading them out, because users only have to figure things out once. So sticking it in with the modular move makes sense to me. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+vhmXVaO67S1rtsRAvv9AKDqeISd638V/UXDby4l9jkue/tN/ACgs2oY gCQwlInZ2m7zfOQfcovvZxk= =FKsB -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | Per-Erik Westerberg wrote: | | Ubuntu Breezy has also problems with the fixed font when I updated | | it, the fonts.alias file is missing from the /usr/share/fonts/misc | | directory, maybe it is the same problem that people are experiencing? | | I've recently been informed that just running mkfontdir in | /usr/share/fonts/misc/ may work. Try it out. I just made a vast number of commits to the fonts packages in an attempt to fix this by regenerating the fonts.* files in pkg_postinst(). Upstream has a number of fonts installing into the same directory, so just providing upstream's fonts.* files gives us a broken setup. Things should work now. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+vo0XVaO67S1rtsRAsuyAJ9pjs+/ZMCsLNiDVQ/tvfMjA4jZJACeKcvf GZtig0iIsl4EsiB0tCCV4Lw= =67+0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | A few updates: | | I'm working on a Mesa ebuild to add; this will provide the gl.h | everyone's been complaining about missing. My dev box is really screwy | because of orphaned files, things lying around from CVS, etc, so I | didn't realize this would actually be required until yesterday. | | Until then, just build xorg without glx. This should be almost fixed, with the exception of opengl-update (see patch in a reply to Georgi, and a proposal as a reply to that) and some external apps installing xorg modules. | People have been trouble actually starting the X server, because it | can't find the 'fixed' font. I suspect that the font-misc-misc package | is either installing wrong, or the font tools are messed up. Replace the | /usr/share/fonts/misc/ directory with one from an older install. Should be fixed; see post from ~5 min. ago. | Also there have been errors of the freetype/type1/trap modules not found | on startx. They aren't yet built in xorg-server, so you may need to copy | them over from an older install. Upstream problem, not yet fixed to my knowledge. | You may need to create a symlink /usr/bin/X - Xorg. I'm starting to work on an upstream patch for this. | I also have reports that XKB isn't working properly yet. It'd be nice | for someone to look into how to fix this. This should be fixed in updated xkbdata. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+vr2XVaO67S1rtsRAnRUAKD257Uco/jvo1K3ZfLW5DDHKskfxgCfQ9vf Q13JmdiLEsq6ztCBcSJ+YEw= =+UQ5 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Put DESCRIPTION HOMEPAGE and LICENSE in another place
Carlos Silva wrote: I know that portage team is closed for new features :) but this just came to my mind just 5 minutes ago and seemed good enought to try. Let's just think that portage handles 5 version of package foo and foo has http://www.foo.org; and homepage, GPL-v2 license and foo just make your pc look faster as DESCRIPTION. If we sum all the bytes that this _repeated_ info occupies in app-misc/foo we get 90 bytes (including '=' and '' for package foo. If all the packages in portage were foo's, according to p.g.o there are 9923 packages, we would have 90*9923 witch gives us 893070bytes (893KB) of information that is repeated in many places. Also, we know that some packages have homepages/descriptions/linceses that are bigger then this so, in reality, this number will probably be bigger in real like. With portage growing every day, this will get even bigger. My ideia was to put this kind of repeated information in some other place that is not the ebuild, let's say for e.g. under app-misc/foo/info or metadata.xml. This way, users with slow connections don't download almost 1MB of info every time they sync. What do you think of this? Not going to happen anytime soon. Would introduce xml parsing code in core portage functions (bad), removing the info from ebuilds breaks compability (very bad) and there isn't any real benefit. You're not going to save any significant amount (= more than a *few* KB) of space during transmission or on disc. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] We have doc USE flag, why not a man USE flag too
On Thursday 11 August 2005 09:04, Mike Frysinger wrote:
On Wednesday 10 August 2005 07:56 pm, Jason Stubbs wrote:
On Thursday 11 August 2005 00:39, Mike Frysinger wrote:
On Wednesday 10 August 2005 11:24 am, Jason Stubbs wrote:
On Wednesday 10 August 2005 22:19, Ciaran McCreesh wrote:
On Wed, 10 Aug 2005 09:10:39 -0400 Michael Cummings
[EMAIL PROTECTED] wrote:
| (not directed at dsd in particular, just the last one in my
| inbox to reply :) That's great and all that its in features for
| the installation, but what about packages with optional
| dependencies based on doc and man?
Join in the quest to get FEATURES added to the expand list! Bug
#82513.
How much do you like C code that has
#ifdef's for the compiler being used? It's the same thing.
i'll take
#ifdef __x86_64__
over
use amd64
any day
I was referring to compiler version. Portage FEATURES are not a
guaranteed part of an ebuild's shell. Let me put it another way,
should ebuilds handle NOCOLOR as well?
no, but why should NOCOLOR affect how a package is built/installed ? the
point here is that we dont really care whether it's FEATURES or USE or
what, as long as we have the ability to control DEPEND/SRC_URI/behavior
in an ebuild depending on whether the user wants tests/manpages/etc...
As well as having the option presented to the user in a unified way. ;)
Really, something along the lines of Carsten's base.eclass suggestion sounds
best to me. The fact that ebuilds are find what are currently portage
FEATUREs to be interesting implies in my mind that they either shouldn't be
FEATUREs (noman, noinfo) or that the relation to ebuilds should be
investigated further and dealt with appropriately (test, debug).
With noman and the like, how's the following for a solution? A lot of the
ebuild functions contained within portage will be moving into the tree once
signing is in. What about adding {pre,post}_src_{compile,install,...} hooks
into portage that will live in the tree that USE=man support can be
implemented in globally? For those packages that have a specific interest,
the USE flag will be available. Everything should be happy on the ebuild
side of things. (On the U/I side of things, stuff can be done to cut down
the noise.)
--
Jason Stubbs
pgpPOnnZ2ACgo.pgp
Description: PGP signature
Re: [gentoo-dev] We have doc USE flag, why not a man USE flag too
On Thursday 11 August 2005 07:02 am, Jason Stubbs wrote:
On Thursday 11 August 2005 09:04, Mike Frysinger wrote:
On Wednesday 10 August 2005 07:56 pm, Jason Stubbs wrote:
I was referring to compiler version. Portage FEATURES are not a
guaranteed part of an ebuild's shell. Let me put it another way,
should ebuilds handle NOCOLOR as well?
no, but why should NOCOLOR affect how a package is built/installed ? the
point here is that we dont really care whether it's FEATURES or USE or
what, as long as we have the ability to control DEPEND/SRC_URI/behavior
in an ebuild depending on whether the user wants tests/manpages/etc...
With noman and the like, how's the following for a solution? A lot of the
ebuild functions contained within portage will be moving into the tree once
signing is in. What about adding {pre,post}_src_{compile,install,...} hooks
into portage that will live in the tree that USE=man support can be
implemented in globally? For those packages that have a specific interest,
the USE flag will be available. Everything should be happy on the ebuild
side of things. (On the U/I side of things, stuff can be done to cut down
the noise.)
so you're saying that the default ebuild.sh functions are going to be moving
into the tree to a place which will be auto-sourced before the ebuild and its
eclasses ?
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] We have doc USE flag, why not a man USE flag too
On Thu, 11 Aug 2005 08:26:49 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
On Thursday 11 August 2005 07:02 am, Jason Stubbs wrote:
With noman and the like, how's the following for a solution? A lot
of the ebuild functions contained within portage will be moving
into the tree once signing is in. What about adding
{pre,post}_src_{compile,install,...} hooks into portage that will
live in the tree that USE=man support can be implemented in
globally? For those packages that have a specific interest, the USE
flag will be available. Everything should be happy on the ebuild
side of things. (On the U/I side of things, stuff can be done to
cut down the noise.)
so you're saying that the default ebuild.sh functions are going to be
moving into the tree to a place which will be auto-sourced before the
ebuild and its eclasses ?
-mike
If you read it again you'll notice the {pre,post} part ;)
IIRC that's already in HEAD for /etc/portage/bashrc, so extending it to
$PORTDIR shouldn't be an issue.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
pgpZdrSgxpWWA.pgp
Description: PGP signature
Re: [gentoo-dev] We have doc USE flag, why not a man USE flag too
On Thu, 11 Aug 2005 10:03:13 -0400
Mike Frysinger [EMAIL PROTECTED] wrote:
On Thursday 11 August 2005 09:40 am, Marius Mauch wrote:
If you read it again you'll notice the {pre,post} part ;)
IIRC that's already in HEAD for /etc/portage/bashrc, so extending
it to $PORTDIR shouldn't be an issue.
and if *you* read it again you'll notice that he said moving a lot of
ebuild functions out of ebuild.sh *and* adding new {pre,post} hooks
new*, do*, emake, ...
NOT src_*, pkg_* or dyn_*, use, has, ...
Basically the helper scripts should go in the tree, but the stuff
that's tied to portage internals stays in portage.
The list isn't final yet though.
though.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
pgpBpzJg4kjoF.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Proper commit messages
Mike Frysinger [EMAIL PROTECTED] wrote: also, four tabs rule I prefer single-character tabs. (0x09) -- I used to think romantic love was a neurosis shared by two, a supreme foolishness. I no longer thought that. There's nothing foolish in loving anyone. Thinking you'll be loved in return is what's foolish. -- Rita Mae Brown -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] portage-2.1_alpha20050718 out
Hi, For all those drooling over their keyboards after reading this topic, please also read the rest of this mail. So yes, finally a portage-2.1 pre-pre-pre-alpha version is out and in the tree (p.masked). However, it's not the 2.1 that some of you might expect as it doesn't have a new dep resolver, so still no use deps. Correct, still no use deps. However, there was a reason to release a 2.1 witout the new dep resolver. It needs a lot of work not only on the resolver itself, but also most of the other portage code, so it's taking quite some time. And we really didn't want to withold other important and long-awaited features for so long. As there are no release notes yet (did I say that it's a pre-pre-pre alpha?) I'll give you a quick summary: - elog, also known as bug 11359, finally solves the but-I-missed-the-postinst-notice problem. See the comments in make.conf.example on how to use it (open task: write a viewer app for saved logs) - ebuild-daemon, basically a rewrite of the bash subsystem, improves performance and makes it more flexible - verify-rdepend optionally checks link dependencies of packages against their RDEPEND value (open task: add more checks) - everyone not using the ebuild will be glad to hear that portage finally uses autotools - not usable yet, but promising are the new set and transport frameworks, the former also includes the integration of GLEP14 I probably missed a lot of stuff here. While I call this a pre-pre-pre alpha release it should be generally usable, but doesn't look as smooth as 2.0 yet, so you'll see some debug and error messages, and rarely might encounter a backtrace. Make sure you check the metabug (#102126) for known issues. Now have fun with it ;) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. pgpVC3MiByrBX.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick wrote: 3. With USE=-dri, for testing purposes (and in the end, perhaps for performance reasons as well), it seems better to change the make target to HOSTCONF=linux-sparc, and let user's CFLAGS define the architecture. When you do this, you get both a glx-capable libGL and a stand-alone libGL And why is this a good thing? I'm adamantly against building the non-glx libGL here for standard use, and I will continue to oppose it. Be normal people and do the same thing as everybody else in the world who's ever used libGL in X. 4. For now, in case USE=-dri, I am not calling fix_opengl_symlinks. Once I have all of X11R7 into test, I'll revisit this (and the Assembly code question) to see what gives the best performance. Same as above. These changes are not very pretty, but they have the benefit of resulting in an ebuild for a mesa version of opengl which can actually be tested independently from the rest of Modular X. It is even conceivable that other architecture/graphics-card combinations might require something similar. I don't see how the standalone libGL has any relation to the ability to test mesa with old or new X. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+49vXVaO67S1rtsRArphAJ9UrEwb0zjOkOvOP9mC4CkYlK8+jACgpFoa mqJAZXt6otRKnsGGLGl2RC8= =C0d6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: And why is this a good thing? I'm adamantly against building the non-glx libGL here for standard use, and I will continue to oppose it. Be normal people and do the same thing as everybody else in the world who's ever used libGL in X. To give you some more concrete information: 1) The GLX one is almost certain to perform better in software 2) The standalone one definitely won't support ffb or any other form of DRI (obviously), and building two libGL's is just silly. 3) When accelerated indirect rendering works, the standalone won't work with it either. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+5KoXVaO67S1rtsRAnN2AKDY/kP6hOdNZsBLSASipXZ3gJ3/MQCgn/7D 1UdMjcZoBLAfg1yXNwd1hcc= =Q0UM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
On Thu, 2005-08-11 at 11:02 -0700, Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: And why is this a good thing? I'm adamantly against building the non-glx libGL here for standard use, and I will continue to oppose it. Be normal people and do the same thing as everybody else in the world who's ever used libGL in X. To give you some more concrete information: 1) The GLX one is almost certain to perform better in software 2) The standalone one definitely won't support ffb or any other form of DRI (obviously), and building two libGL's is just silly. 3) When accelerated indirect rendering works, the standalone won't work with it either. I don't disagree with any of these points, and it turns out that libGL from mesa-6.3.1.1 (with DRI modules) works OK with current glx for mesa indirect. My problems have been related to the changes to the build in mesa itself which result in either missing externals or doubly defined externals when you use sparc assembly code. So all I am really going to need for sparc is to define a proper set of DRI drivers. Notice, however, that the mesa ebuild does not seem to install the dri drivers anyplace. I suppose they should go into /usr/lib/xorg/modules/drivers, but the don't. It seems that the ebuild uses mesa's 'installmesa' script to populate the image to install, but installmesa looks only for include files and objects which match lib*. I don't see how it ever can install things like mach64_dri.so (and, indeed, it doesn't). Sorry for the confusion. -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Modular X plans
Dne čt 11. srpna 2005 20:58 Donnie Berkholz napsal(a):
Donnie Berkholz wrote:
Here's a slightly better version:
And here's the enhanced, scripted version. It traces libs back to their
packages to really make things easy.
you can replace (starting line 37)
if $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
static=1
fi
if ! $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
shared=1
fi
with
if $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
static=1
else
shared=1
fi
as it should be equivalent.
Seems to work quite well.
Thanks,
Donnie
Have a nice day,
spity
--
Jan Spitalnik
[EMAIL PROTECTED]
We are now qualified to anything with nothing. -- Larry Wall
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick wrote: Notice, however, that the mesa ebuild does not seem to install the dri drivers anyplace. I suppose they should go into /usr/lib/xorg/modules/drivers, but the don't. It seems that the ebuild uses mesa's 'installmesa' script to populate the image to install, but installmesa looks only for include files and objects which match lib*. I don't see how it ever can install things like mach64_dri.so (and, indeed, it doesn't). Hey, that's no problem now that we've resolved the libGL thing. =) We'll just have to hack something together. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+6YrXVaO67S1rtsRAirEAKDVJUjQd2/NCr2kjZ4G/PolsTkOUgCg4mJ3 XAjlv0d0YEJp1P0FCX7hPPw= =3BMd -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Spitalnik wrote: as it should be equivalent. You'd think so, but consider this case: Package A provides foo.so Package B provides foo.a Package C links against both Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+6aLXVaO67S1rtsRAvVpAKCKzCoeYvJ5tGns027wvZK7AJhsywCg1Y4i pLswOQy4BDNJ+FnU7pxoxhI= =VedS -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
On Thu, 2005-08-11 at 12:25 -0700, Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick wrote: Notice, however, that the mesa ebuild does not seem to install the dri drivers anyplace. I suppose they should go into /usr/lib/xorg/modules/drivers, but the don't. It seems that the ebuild uses mesa's 'installmesa' script to populate the image to install, but installmesa looks only for include files and objects which match lib*. I don't see how it ever can install things like mach64_dri.so (and, indeed, it doesn't). Hey, that's no problem now that we've resolved the libGL thing. =) We'll just have to hack something together. I'm happy with libGL; I just reverted the ebuild to be as it started, but to define a sparc-specific set of dri drivers. All my problems came from my mistaken belief that mesa would still build cleanly using the sparc assembly code. I thought about going ahead and installing the drivers themselves while I was at it, but decided to do other things first. If you like, I'll take a shot at it tomorrow, since I've been playing with mesa and its ebuild anyway. -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Devrel) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Modular X plans
maillog: 11/08/2005-11:58:31(-0700): Donnie Berkholz types
Donnie Berkholz wrote:
Here's a slightly better version:
And here's the enhanced, scripted version. It traces libs back to their
packages to really make things easy.
Seems to work quite well.
Thanks,
Donnie
echo Looking for libraries ...
for libname in ${libnames}; do
static=0
shared=0
if $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
static=1
fi
if ! $(grep ' \-l[a-zA-Z]' ${1} | grep static); then
shared=1
fi
Why not pull these greps out of the loop? No need to do the *same* thing
for every library. Or did you forget to mention $libname in there?
staticlibname=lib${libname}.a
sharedlibname=lib${libname}.so
if [[ ${static} -eq 1 ]]; then
echo Looking for ${staticlibname}
for libdir in ${libdirs}; do
if [[ -e ${libdir}/${staticlibname} ]]; then
libpaths=${libpaths}
${libdir}/${staticlibname}
fi
done
fi
if [[ ${shared} -eq 1 ]]; then
echo Looking for ${sharedlibname}
for libdir in ${libdirs}; do
if [[ -e ${libdir}/${sharedlibname} ]]; then
libpaths=${libpaths}
${libdir}/${sharedlibname}
fi
done
fi
done
--
\Georgi Georgiev \ Experience is a good teacher, but she\
/[EMAIL PROTECTED] / sends in terrific bills. -- Minna Antrim, /
\ +81(90)2877-8845 \ Naked Truth and Veiled Allusions \
pgpRX8VjT3v5L.pgp
Description: PGP signature
[gentoo-dev] X modular migration howto
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I started a brief migrating to modular X howto, on popular demand. Comments and additions would be appreciated. It's at http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+6otXVaO67S1rtsRAtpcAKCEnZ/6O1EiACG+59jCSK24SH9ptACfZhLo 3aIsScGzHMFQYK6cyvVp5jQ= =ayhI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X modular migration howto
Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I started a brief migrating to modular X howto, on popular demand. Comments and additions would be appreciated. Just a quick note for any brave amd64 users who might want to try this, it seems that something isn't quite right as all X apps seem to cause BadValue X errors in XCreateWindow. I'm unsure as to whether I've done something wrong, or this is a problem upstream. Ben. It's at http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+6otXVaO67S1rtsRAtpcAKCEnZ/6O1EiACG+59jCSK24SH9ptACfZhLo 3aIsScGzHMFQYK6cyvVp5jQ= =ayhI -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georgi Georgiev wrote: Why not pull these greps out of the loop? No need to do the *same* thing for every library. Or did you forget to mention $libname in there? My rationale was that over the course of a compilation, both shared and static libs may be used. In one section it might link in a shared -lfoo, while in another it does a static -lbar. And yes I certainly did forget to mention $libname. =) Attached an update to incorporate this and your other grep comments. Thanks for the review! Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+8BvXVaO67S1rtsRArfiAJ916fUm2hN15fLd9eeecVPwmJndMwCg3R02 sAxoWHaBZPGf4zaXs86JRnY= =CkNa -END PGP SIGNATURE- linking_libs.sh Description: application/shellscript
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferris McCormick wrote: I'm happy with libGL; I just reverted the ebuild to be as it started, but to define a sparc-specific set of dri drivers. All my problems came from my mistaken belief that mesa would still build cleanly using the sparc assembly code. I thought about going ahead and installing the drivers themselves while I was at it, but decided to do other things first. If you like, I'll take a shot at it tomorrow, since I've been playing with mesa and its ebuild anyway. I'm thinking something really basic like: EXEDESTTREE=/usr/lib/xorg/modules/dri find $S -name '*_dri.so' | xargs doexe Does that work? Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+8E0XVaO67S1rtsRAtZeAKDxi0BF7XAqtL1bn61OLL/xMdW9OgCePh8N sWmNLRJEPz1jtnBTFrdZRXA= =x8YZ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 11 Aug 2005, Donnie Berkholz wrote: --[PinePGP]--[begin]-- Ferris McCormick wrote: I'm happy with libGL; I just reverted the ebuild to be as it started, but to define a sparc-specific set of dri drivers. All my problems came from my mistaken belief that mesa would still build cleanly using the sparc assembly code. I thought about going ahead and installing the drivers themselves while I was at it, but decided to do other things first. If you like, I'll take a shot at it tomorrow, since I've been playing with mesa and its ebuild anyway. I'm thinking something really basic like: EXEDESTTREE=/usr/lib/xorg/modules/dri find $S -name '*_dri.so' | xargs doexe Does that work? It should. I'll verify tomorrow. Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (sparc, devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+8dsQa6M3+I///cRAjaDAKDUF7uUimEIzhMYScGpN+d2rrHcEACgquaA XU11EiMqbphOkCN+TTAVU+8= =t2iC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Attached an update to incorporate this and your other grep comments. Here's a new one. It prints some useful information while it's searching, like OK or Not found!. Also fixes a little more ugly output (double/single quotes and pipes showing up as parts of lib names) and makes an attempt to use rpm if equery isn't around, and just prints the lib paths otherwise. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+9meXVaO67S1rtsRAsuCAJ9KSuVoWyEWrGS0PspcvuVKGaOdowCcCLgx C2zDxdm3YOkm/sJI2OvHztU= =tpPa -END PGP SIGNATURE- linking_libs.sh Description: application/shellscript
Re: [gentoo-dev] portage-2.1_alpha20050718 out
On Friday 12 August 2005 02:26, Marius Mauch wrote: Hi, For all those drooling over their keyboards after reading this topic, please also read the rest of this mail. So yes, finally a portage-2.1 pre-pre-pre-alpha version is out and in the tree (p.masked). However, it's not the 2.1 that some of you might expect as it doesn't have a new dep resolver, so still no use deps. Correct, still no use deps. Actually, it does have a new dep resolver. ;) Well, not exactly new. A full dep graph is built though and very primitive circular dep handling in place. This means that pretty much all misordering of packages that happens with 2.0 should no longer occur. -- Jason Stubbs pgpRts1ysC0lO.pgp Description: PGP signature
Re: [gentoo-dev] We have doc USE flag, why not a man USE flag too
On Thursday 11 August 2005 21:26, Mike Frysinger wrote:
On Thursday 11 August 2005 07:02 am, Jason Stubbs wrote:
On Thursday 11 August 2005 09:04, Mike Frysinger wrote:
On Wednesday 10 August 2005 07:56 pm, Jason Stubbs wrote:
I was referring to compiler version. Portage FEATURES are not a
guaranteed part of an ebuild's shell. Let me put it another way,
should ebuilds handle NOCOLOR as well?
no, but why should NOCOLOR affect how a package is built/installed ?
the point here is that we dont really care whether it's FEATURES or
USE or what, as long as we have the ability to control
DEPEND/SRC_URI/behavior in an ebuild depending on whether the user
wants tests/manpages/etc...
With noman and the like, how's the following for a solution? A lot of
the ebuild functions contained within portage will be moving into the
tree once signing is in. What about adding
{pre,post}_src_{compile,install,...} hooks into portage that will live
in the tree that USE=man support can be implemented in globally? For
those packages that have a specific interest, the USE flag will be
available. Everything should be happy on the ebuild side of things. (On
the U/I side of things, stuff can be done to cut down the noise.)
so you're saying that the default ebuild.sh functions are going to be
moving into the tree to a place which will be auto-sourced before the
ebuild and its eclasses ?
As Marius said, the list of what be moved isn't finalized yet. Essentially,
the goal is to move anything that is not affected by portage version into
the tree. What I was suggesting was extra hooks that would essentially
allow ebuild devs to modify ebuilds at the abstract level, such as adding a
noman, noinfo or nostaticlibs to all ebuilds.
This is merely a suggestion, however. Putting aside my general dislike of
USE_EXPAND, adding FEATURES to it means that all portage versions (and
replacements) are required to have a global FEATURES setting and must have
a certain subset of FEATURES available that must each provide a specific
function. I'm not really attached to the solution I suggested; I'm just
looking for a way to get rid of those musts. Portage currently has no
idea what anything in USE or USE_EXPAND is or what it does. It needs to be
kept that way.
--
Jason Stubbs
pgpcgWZqevb4L.pgp
Description: PGP signature
[gentoo-dev] imlate x86 Editon and more x86 fun
Hi, After Ciaran's comment on -core, I wondered how imlate would fare on x86. For those who are not familiar with it, imlate list all packages on one architecture that are outdated compared to another architecture. All other architectures use x86 as a reference.. That clearly didn't work for us. So I hacked it to compare x86 to all other Linux keywords. The results are surprising, 214 packages are more recent on non-x86 architectures. But its pretty hard to know if its because they have arch specific patches or because the maintainer's arch is not x86... We should really have a way to specify in the ebuild or metadata.xml what arch is the maintainer arch. I also ran the notx86 (notamd64 renamed) script on the tree (it finds packages that dont have an x86 keyword at all)... and I handfiltered the result for obvious errors.. This is all available at http://dev.gentoo.org/~tester/imlate/ Ah yea, and I also tried my new imlate script on amd64 and it finds about 50% more packages than the regular version.. We really need to form an x86 team... -- Olivier Crête [EMAIL PROTECTED] x86 Security Liaison signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Modular X plans
maillog: 11/08/2005-16:05:02(-0700): Donnie Berkholz types
Donnie Berkholz wrote:
Attached an update to incorporate this and your other grep comments.
Here's a new one. It prints some useful information while it's
searching, like OK or Not found!. Also fixes a little more ugly output
(double/single quotes and pipes showing up as parts of lib names) and
makes an attempt to use rpm if equery isn't around, and just prints the
lib paths otherwise.
Looks better and better. A couple more comments:
- I tried the script on the output of gvim, and it erroneously tried to
find libatk-1.0.a. The problem was in this line:
x86_64-pc-linux-gnu-gcc -L/usr/lib64 -L/usr/lib64 -rdynamic
-L/usr/local/lib -o gvim snip object files -lgdk_pixbuf-2.0
-lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lacl -lgpm -rdynamic
-L/usr/local/lib
/usr/lib/perl5/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.6/x86_64-linux/CORE -lperl -lutil -lc
-L/usr/lib/python2.4/config -lpython2.4 -L/usr/lib64 -lz -lutil -lm
-Xlinker -export-dynamic static
As you can see, it's the static in the end of the line. Maybe you
should grep for -static instead.
- I'm sure I've seen makefiles that use tabs instead of spaces to
separate the -l arguments. Maybe you should replace the space with a
[:space:] or something?
- To avoid eventual problems with similarly named libraries (libpam and
libpam_misc for example; grepping for -lpam would also match
-lpam_misc) you could grep for \-l${libname}\ instead. This would
also solve the space-or-tab problem.
--
/Georgi Georgiev / We must know, we will know. -- David /
\ [EMAIL PROTECTED]\ Hilbert \
/ +81(90)2877-8845 / /
pgpSOTNEWtojG.pgp
Description: PGP signature
Re: [gentoo-dev] X modular migration howto
maillog: 12/08/2005-07:16:10(+1000): Ben Skeggs types Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I started a brief migrating to modular X howto, on popular demand. Comments and additions would be appreciated. Just a quick note for any brave amd64 users who might want to try this, it seems that something isn't quite right as all X apps seem to cause BadValue X errors in XCreateWindow. I'm unsure as to whether I've done something wrong, or this is a problem upstream. I haven't given it a try on my athlon64 yet, but if you could take a look at https://bugs.gentoo.org/show_bug.cgi?id=100767 and see if it could be in any way related. -- ) Georgi Georgiev) wwoods I don't like to have fun.) ( [EMAIL PROTECTED]( wwoods Fun upsets me. SpanKY shuddap * ( ) +81(90)2877-8845) SpanKY pokes wwoods wwoods OW! wwoods ) ( --- ( my secret area! SpanKY YOU LIKED IT( -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Georgi Georgiev wrote:
| As you can see, it's the static in the end of the line. Maybe you
| should grep for -static instead.
| - To avoid eventual problems with similarly named libraries (libpam and
| libpam_misc for example; grepping for -lpam would also match
| -lpam_misc) you could grep for \-l${libname}\ instead. This would
| also solve the space-or-tab problem.
Try this one. It should address both issues.
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC/CBJXVaO67S1rtsRAnsWAJ9q+x9c33TBxnpPSTqNtZvJPlEYSgCghQ+e
zEOZ5LyxT0TtvkRAkLOHAGM=
=N8Ha
-END PGP SIGNATURE-
linking_libs.sh
Description: application/shellscript
Re: [gentoo-dev] Modular X plans
maillog: 11/08/2005-21:06:34(-0700): Donnie Berkholz types
Georgi Georgiev wrote:
| As you can see, it's the static in the end of the line. Maybe you
| should grep for -static instead.
| - To avoid eventual problems with similarly named libraries (libpam and
| libpam_misc for example; grepping for -lpam would also match
| -lpam_misc) you could grep for \-l${libname}\ instead. This would
| also solve the space-or-tab problem.
Try this one. It should address both issues.
I should have tested a bit more.
[EMAIL PROTECTED] ~ $ echo 'a -lbcd' | grep -- '-l'
a -lbcd
[EMAIL PROTECTED] ~ $ echo 'a -lbcd' | grep -- '\b-l'
[EMAIL PROTECTED] ~ $ echo 'a lbcd' | grep -- '\bl'
a lbcd
It's the - that is not a part of a word. Any ideas? I guess the \b
after ${libname} is fine, but the one before the - is not. It's down
to [[:space:]]-l${libname}\b it seems. And hopefully there won't be any
any lines starting with -l, or any -llib being quoted which is legal
but unmatchable. Ah, cannot grep be told that - is a valid word
symbol.
The only reason the script currently works is because:
grep '\b-l[[:alnum:]].*\b' ${1}
matches the -l in x86_64-pc-linux-gnu-gcc
You also do not need the .*\b in the above. The .*\b would always
match until the last word on the line (grep doesn't do greedy wildcard
matching), and since it would *always* match, there is no need in
matching at all.
--
\Georgi Georgiev \ Try the Moo Shu Pork. It is especially \
/[EMAIL PROTECTED] / good today. /
\ +81(90)2877-8845 \ \
pgpgJCbFpja2U.pgp
Description: PGP signature
Re: [gentoo-dev] X modular migration howto
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I started a brief migrating to modular X howto, on popular demand. | Comments and additions would be appreciated. | | It's at | http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt I just updated it to tell people to install font-cursor-misc, font-alias and encodings. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC/CyeXVaO67S1rtsRArjLAKCbAH7JATFVqsKLOZ8Yx0pNVi+cxACeOeZ6 3Ao5oCGQkZJgP54qrW7de8c= =A8ao -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] imlate x86 Editon and more x86 fun
On Thu, 11 Aug 2005 23:15:17 -0400 Olivier Crête [EMAIL PROTECTED] wrote: We really need to form an x86 team... -- Olivier Crête [EMAIL PROTECTED] x86 Security Liaison I really do agree with not only this, but the need for stable marking as well. Gentoo is very bleeding edge at this point, and I feel that stable packages are somewhat lacking. However, the problems I see is what is considered Let the herd handle it and what is considered sure why not. The script output should help, I'm just afraid that if a person marks a package that the maintainer was planning on working at, things could go wrong. I'm open to ideas on such a team, but I'm not sure how to workout the major issues at this point. Chris White pgpDusSaR2vwk.pgp Description: PGP signature
Re: [gentoo-dev] imlate x86 Editon and more x86 fun
On Thu, Aug 11, 2005 at 11:15:17PM -0400, Olivier Cr?te wrote: After Ciaran's comment on -core, I wondered how imlate would fare on x86. For those who are not familiar with it, imlate list all packages on one architecture that are outdated compared to another architecture. All other architectures use x86 as a reference.. That clearly didn't work for us. So I hacked it to compare x86 to all other Linux keywords. [snip] Ok, I admit, a fair number of the ebuilds on your list I am responsible for. I used to keep track of them via aliz's 30-day in ~arch webpage, so if somebody could rig something like that up again, I'd love it to allow me to easily track my packages. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpTGAYxN5jyT.pgp Description: PGP signature
Re: [gentoo-portage-dev] PATCH: portage_checksum prelink optimization (#83379)
On Thursday 11 August 2005 14:19, Zac Medico wrote: http://bugs.gentoo.org/show_bug.cgi?id=83379 Author: Zac Medico This patch uses prelink --undo-output=prelink_tmpfile in order to avoid extra copying. Files rejected by prelink are checksummed in place. With this patch applied, I have measured a 7.75% decrease in the time taken to checksum non-elf files when prelink is enabled. Comments? Also for 2.1. -- Jason Stubbs pgpNuBzRGRdMG.pgp Description: PGP signature
