Re: [gentoo-dev] Modular X plans
maillog: 08/08/2005-01:08:03(-0700): Donnie Berkholz types snip The font-server flag may be necessary in libXfont, but I haven't fully explored this yet. If it turns out to be the case, it'll be removed as an optional flag and forced on. Unfortunately, it seems it does. I did it with -font-server and the build of xorg-server failed with errors about missing functions: check_fs_register_fpe_functions fs_register_fpe_functions emerging libXfont with font-server made xorg-server link just fine. Still, I believe that it is xorg-server that has to be fixed. It needs to get NOFONTSERVERACCESS defined, which will avoid the call to fs_register_fpe_functions, and it would need to do something about the call to check_fs_register_fpe_functions, but I have no idea what. -- Georgi Georgiev If there is a wrong way to do something, [EMAIL PROTECTED] then someone will do it. -- Edward A. +81(90)2877-8845 Murphy Jr. pgplFeOBIrbC6.pgp Description: PGP signature
Re: [gentoo-dev] Proper commit messages
Ciaran McCreesh wrote: If you're the sort that writes good ChangeLog messages anyway, there's nothing wrong with reusing them as the commit message. If you have a really really good reason for not using a ChangeLog message, or if you haven't yet written a shell alias for reusing ChangeLog messages for commits, you still need to come up with something for the commit message. Personaly I find it a little bit annoying to write changes twise. One time in Changelog and one time in --commitmsg. How about using the commitmsg for Changelog as default, but if a Changelog entry already exists, then write nothing to Changelog. Regards, Markus Rothe pgpicx32SYWRw.pgp Description: PGP signature
Re: [gentoo-dev] Proper commit messages
On Tue, 9 Aug 2005 11:36:18 + Markus Rothe [EMAIL PROTECTED] wrote: Personaly I find it a little bit annoying to write changes twise. One time in Changelog and one time in --commitmsg. How about using the commitmsg for Changelog as default, but if a Changelog entry already exists, then write nothing to Changelog. I'm sure you can manage to write a bash function to call echangelog and repoman commit with the same message. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proper commit messages
Stephen Bennett wrote: On Tue, 9 Aug 2005 11:36:18 + Markus Rothe [EMAIL PROTECTED] wrote: Personaly I find it a little bit annoying to write changes twise. One time in Changelog and one time in --commitmsg. How about using the commitmsg for Changelog as default, but if a Changelog entry already exists, then write nothing to Changelog. I'm sure you can manage to write a bash function to call echangelog and repoman commit with the same message. Sure, I can and the other mail shows that it is *realy* simple, but why should every dev write his own script, when this could be done once for all? Nevermind.. If I don't provide patches for repoman I shouldn't bitching around! ;-) Regards, Markus Rothe pgp5r0VEVkfRd.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote: If you could bring up some specific examples, we could discuss them. Sure. Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, xcursor, xinerama (already a use flag), xshape, and xsm. I'd really hate to add 8 more use flags for those things. I find it fairly hard to believe that a user would want to, for example, configre xrender and xcursor but not xrandr. My *thought* here is why not let the Qt ebuild rely on the base packages of X, and if these other packages are also installed ahead of time, then configure support for them as well, but don't make them use flag deps. Something like: if xcursor is installed turn on xcursor support DEPEND+=xcursor fi I'm sure someone will cast me as a heretic, but I think this is much more elegant than 8 more use flags. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proper commit messages
On Tuesday 09 August 2005 13:55, Simon Stelling wrote:
#!/bin/bash
echangelog ${1}
repoman scan
repoman commit -m ${1}
Even simpler, as repoman commit abort in case of errors in repoman scan:
ecommit() {
echangelog $@
repoman commit -m $@
}
add that to your .bashrc.
I use it always:
ecommit Stable on amd64
and it's done :)
If something is bad, it stops me.
If the package is mine and I want to have it clear, repoman full before
ecommit to be safe.
--
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
pgpffOfZBG2kt.pgp
Description: PGP signature
Re: [gentoo-dev] Modular X plans
On Tue, Aug 09, 2005 at 07:36:31AM -0500, Caleb Tennis wrote: On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote: If you could bring up some specific examples, we could discuss them. Sure. Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, xcursor, xinerama (already a use flag), xshape, and xsm. I'd really hate to add 8 more use flags for those things. I find it fairly hard to believe that a user would want to, for example, configre xrender and xcursor but not xrandr. My *thought* here is why not let the Qt ebuild rely on the base packages of X, and if these other packages are also installed ahead of time, then configure support for them as well, but don't make them use flag deps. Something like: if xcursor is installed turn on xcursor support DEPEND+=xcursor fi I'm sure someone will cast me as a heretic, but I think this is much more elegant than 8 more use flags. Yep, you're a heretic. :) How would you propose that DEPEND information make it's way up the portage stack, and ultimately affects the depgraph? What you're suggesting is effectively suggested deps, which are a bit backwards considering we have optional deps, the 8 flags you dislike :) ~harring pgpQeXiqrH1BU.pgp Description: PGP signature
Re: [gentoo-dev] Proper commit messages
On Tue, 9 Aug 2005 12:23:20 + Markus Rothe [EMAIL PROTECTED] wrote: | Stephen Bennett wrote: | On Tue, 9 Aug 2005 11:36:18 + | Markus Rothe [EMAIL PROTECTED] wrote: | | Personaly I find it a little bit annoying to write changes twise. | One time in Changelog and one time in --commitmsg. How about | using the commitmsg for Changelog as default, but if a Changelog | entry already exists, then write nothing to Changelog. | | I'm sure you can manage to write a bash function to call echangelog | and repoman commit with the same message. | | Sure, I can and the other mail shows that it is *realy* simple, but | why should every dev write his own script, when this could be done | once for all? Isn't this one of those things that's best done on a per-dev basis? It's so trivial there's no point shipping an app that does it -- reading the associated documentation would take longer than writing your own. Plus that way you can incorporate personalised clever things such as auto keyword messages for arch teams -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp2tHY5rV26E.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
Yep, you're a heretic. :) How would you propose that DEPEND information make it's way up the portage stack, and ultimately affects the depgraph? What you're suggesting is effectively suggested deps, which are a bit backwards considering we have optional deps, the 8 flags you dislike :) Let me follow up with that I'm all for adding the use flags IF other packages would make use of them as well. I just really hate adding 8 local use flags for this pretty heavily used package that won't add much utility to anything else and will add a bit of headache to making sure Qt is installed with all of the bells and whistles the end user wants. :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
On Tuesday 09 August 2005 15:03, Caleb Tennis wrote: Let me follow up with that I'm all for adding the use flags IF other packages would make use of them as well. I just really hate adding 8 local use flags for this pretty heavily used package that won't add much utility to anything else and will add a bit of headache to making sure Qt is installed with all of the bells and whistles the end user wants. :) I strongly dislike your indeed heretic idea of stepping back from deterministic dependencies as well. On the other hand I don't see why you should support these optional dependencies, when you feel you can't or it doesn't make sense. Just add them as hard dependencies. Non-issue imho. :) Carsten pgpUVRgm67mNC.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Caleb Tennis wrote: | On Monday 08 August 2005 08:14 pm, Donnie Berkholz wrote: | |If you could bring up some specific examples, we could discuss them. | | | Sure. Qt has optional support for xkb, tablet, fontconfig, xrender, xrandr, | xcursor, xinerama (already a use flag), xshape, and xsm. | | I'd really hate to add 8 more use flags for those things. I find it fairly | hard to believe that a user would want to, for example, configre xrender and | xcursor but not xrandr. Then group stuff together, and force some things on always. I find it hard to believe that a user would ever want to turn most of those things off, with only a couple of exceptions. Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+PF0XVaO67S1rtsRAuy2AKDXgmhWBl30RNjWcTn/gS59ae0LYwCg5amr 4TN8tgzOx6qJaWhoguiwaVE= =ezhB -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-config 2.0 development
On Tue, 09 Aug 2005 13:53:25 -0700 Jeremy Huddleston [EMAIL PROTECTED] wrote: | The configuration files are in XML. I'm a little apprehensive about | having such a core package depend on an outside library like this, As you should be. | but I think having the xml configuration files allows a much more | robust configuration. How so? Using XML doesn't magically make your data files any different. It simply makes them much harder to parse. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpgf0SkkHH3q.pgp Description: PGP signature
Re: [gentoo-dev] Re: gcc-config 2.0 development
On Wednesday 10 August 2005 00:12, Jeremy Huddleston wrote: I'd probably go for something similar to the samba/gdm config files if we were to go down this road: Such a format would be also simpler to parse in C, for example using libconfuse (that's *really* simple to use, and quite small), and KDE too has a way to parse it automatically. Probably that's the best way to go. -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpj31F3Qs5BU.pgp Description: PGP signature
Re: [gentoo-dev] Re: gcc-config 2.0 development
On Tue, 2005-08-09 at 18:14 -0400, Daniel Ostrow wrote: On Tue, 2005-08-09 at 15:12 -0700, Jeremy Huddleston wrote: On Tue, 2005-08-09 at 22:19 +0100, Ciaran McCreesh wrote: | but I think having the xml configuration files allows a much more | robust configuration. How so? Using XML doesn't magically make your data files any different. It simply makes them much harder to parse. That's a matter of opinion. I see it as a way to abstract away the configuration and utilize an existing library to handle the parsing. If we do want to eliminate outside dependencies (which I think is an extremely valid point and concern), then we could internally implement a different configuration format that is easier to parse. I'd probably go for something similar to the samba/gdm config files if we were to go down this road: snip I've always been a fan of samba style config files..unlike xml they tend to be both easy to parse and are human readable. I'd far rather see this over XML. It's especially attractive as this is also the way that portage is moving (at the moment) as well. AOL me too /AOL I highly prefer the samba style config file over an XML file. It is easy to read, parse, and edit by both human and machine. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: gcc-config 2.0 development
On Tuesday 09 August 2005 06:37 pm, Paul Varner wrote: On Tue, 2005-08-09 at 18:14 -0400, Daniel Ostrow wrote: On Tue, 2005-08-09 at 15:12 -0700, Jeremy Huddleston wrote: On Tue, 2005-08-09 at 22:19 +0100, Ciaran McCreesh wrote: | but I think having the xml configuration files allows a much more | robust configuration. How so? Using XML doesn't magically make your data files any different. It simply makes them much harder to parse. That's a matter of opinion. I see it as a way to abstract away the configuration and utilize an existing library to handle the parsing. If we do want to eliminate outside dependencies (which I think is an extremely valid point and concern), then we could internally implement a different configuration format that is easier to parse. I'd probably go for something similar to the samba/gdm config files if we were to go down this road: snip I've always been a fan of samba style config files..unlike xml they tend to be both easy to parse and are human readable. I'd far rather see this over XML. It's especially attractive as this is also the way that portage is moving (at the moment) as well. AOL me too /AOL I highly prefer the samba style config file over an XML file. It is easy to read, parse, and edit by both human and machine. arent 'samba style configs' just glorified ini files ? :) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: gcc-config 2.0 development
On Wednesday 10 August 2005 00:43, Mike Frysinger wrote: arent 'samba style configs' just glorified ini files ? :) they are -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpj14cFi3NUy.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proper commit messages
On Tuesday 09 August 2005 07:40 pm, Ciaran McCreesh wrote: On Wed, 10 Aug 2005 01:31:48 +0200 Arnaud Launay [EMAIL PROTECTED] wrote: | Le Tue, Aug 09, 2005 at 03:54:34PM -0700, Tuan Van a écrit: | and for those of us (nano users) ;) | | BTW, I never understood why it was nano which is on the CD, and | not some vi... ? Executive order from Daniel a long time ago. It's right up there with why are we indenting with four wide tabs? on the will never be changed list. that may be, but removing nano from the livecd would be stupid ... vi isnt n00b friendly in the least also, four tabs rule -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
maillog: 09/08/2005-11:16:52(-0700): Donnie Berkholz types Donnie Berkholz wrote: | If you find bugs that aren't purely ebuild problems, do not file them at | bugs.gentoo.org -- go to bugs.freedesktop.org, in the xorg product. | | Two USE flags you will care about are dri and glx -- both are | necessary to get accelerated 3D. A few updates: I'm working on a Mesa ebuild to add; this will provide the gl.h everyone's been complaining about missing. My dev box is really screwy because of orphaned files, things lying around from CVS, etc, so I didn't realize this would actually be required until yesterday. Furthermore, make sure you don't install the headers in /usr/include/GL, but in a location that opengl-update would know how to handle. $ equery b /usr/include/GL/glx.h [ Searching for file(s) /usr/include/GL/glx.h in *... ] x11-proto/glproto-1.4 (/usr/include/GL/glx.h) -- \Georgi Georgiev \ Youth is a disease from which we all \ /[EMAIL PROTECTED] / recover. -- Dorothy Fuldheim / \ +81(90)2877-8845 \ \ pgpg4JovncXGd.pgp Description: PGP signature
Re: [gentoo-dev] Modular X plans
maillog: 09/08/2005-11:16:52(-0700): Donnie Berkholz types Also there have been errors of the freetype/type1/trap modules not found on startx. They aren't yet built in xorg-server, so you may need to copy them over from an older install. Add to that the bitmap and pcidata modules -- the only modules that X is complaining about here. -- /\ Georgi Georgiev /\ Observe yon plumed biped fine. To activate /\ \/[EMAIL PROTECTED]\/ its captivation, Deposit on its termination, \/ /\ +81(90)2877-8845 /\ A quantity of particles saline. /\ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Georgi Georgiev wrote: | Furthermore, make sure you don't install the headers in /usr/include/GL, | but in a location that opengl-update would know how to handle. Good catch. I was going to get to the rest of the GL headers after getting Mesa working. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC+WkPXVaO67S1rtsRAn/ZAKCdjiIBGACi2Ns39GFMdCVYy5FDmgCfTPvK bNJwJxGVMcxTbXb1DI5LFKM= =5VBT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
| Ciaran McCreesh wrote:
| | Hrm. Is this going to be sanely doable by your average dev? How long
| | a dep string would we be having in typical cases? How about in bad
| | cases?
|
| It shouldn't be difficult in most cases, for those capable of finding
| linker lines in a build.
|
| I wrote a quick one-liner that works reasonably well on a couple of
| tests, but could use a little tweaking. Just set log to your build log
| beforehand.
|
| for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ ${linkline} =~
| -l[a-zA-Z] ]]; then echo $linkline; fi; done | sort | uniq
Here's a slightly better version:
for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ ${linkline} =
- -l[a-zA-Z]* ]]; then echo $linkline; fi; done | sort | uniq
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC+W4pXVaO67S1rtsRAmF+AKC5bNS6ZbxU6nlCJUG44VhBeC+w1ACgvziz
BrqUPIlvWnp0sx2MVM6A82M=
=VtA+
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
