On 21/04/2010 17:33, David Gerard wrote:
On 20 April 2010 23:44, Peter Hutterer wrote:
On Tue, Apr 20, 2010 at 11:29:28PM +0100, David Gerard wrote:
[ re: http://www.x.org/wiki/JhBuildInstructions ]
Yes, if you look at the page you'll see I grovelled through setting it
up from scratch on
On 26 April 2010 18:05, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
I think you are somewhat making a rod for you own back by making this harder
than it needs to be.
There is no reason I can see not to do 'make Makefile.plain install' for
jhbuild if it can't configure: All this omits is
On 20 April 2010 23:44, Peter Hutterer peter.hutte...@who-t.net wrote:
On Tue, Apr 20, 2010 at 11:29:28PM +0100, David Gerard wrote:
[ re: http://www.x.org/wiki/JhBuildInstructions ]
Yes, if you look at the page you'll see I grovelled through setting it
up from scratch on several distros!
(I
On Mon, Apr 19, 2010 at 01:19:30PM +0200, Florian Mickler wrote:
On Sun, 18 Apr 2010 19:30:31 +0200
Dirk Wallenstein hals...@t-online.de wrote:
A full-fledged meta-git repo management tool suite would be nice. Such
an application would, for example, be able to:
- inform about the state
On 18 April 2010 17:21, Joel Feiner jafei...@gmail.com wrote:
Or you could use build.sh or jhbuild or moral equivalent. For testing, I
have an entire X system checked out and use jhbuild to update it. It also
automatically saves your work (via git stash) so you can deal with merge
conflicts
On Tue, Apr 20, 2010 at 09:16:22PM +0100, David Gerard wrote:
On 18 April 2010 17:21, Joel Feiner jafei...@gmail.com wrote:
Or you could use build.sh or jhbuild or moral equivalent. For testing, I
have an entire X system checked out and use jhbuild to update it. It also
automatically
On 20 April 2010 23:24, Peter Hutterer peter.hutte...@who-t.net wrote:
On Tue, Apr 20, 2010 at 09:16:22PM +0100, David Gerard wrote:
I spent a little while playing with jhbuild under various operating
systems a while ago. Once jhbuild is installed and working it's
fantastic, but setting it up
On Tue, Apr 20, 2010 at 11:29:28PM +0100, David Gerard wrote:
On 20 April 2010 23:24, Peter Hutterer peter.hutte...@who-t.net wrote:
On Tue, Apr 20, 2010 at 09:16:22PM +0100, David Gerard wrote:
I spent a little while playing with jhbuild under various operating
systems a while ago. Once
On Sat, Apr 17, 2010 at 09:20:45PM -0700, Keith Packard wrote:
On Fri, 16 Apr 2010 22:45:02 +0200, olafbuddenha...@gmx.net wrote:
On Tue, Apr 06, 2010 at 06:43:22PM -0700, Keith Packard wrote:
This isn't a git super-module,
Well, why not?
I don't think the wire protocol is a place
On Sun, 18 Apr 2010 19:30:31 +0200
Dirk Wallenstein hals...@t-online.de wrote:
A full-fledged meta-git repo management tool suite would be nice. Such
an application would, for example, be able to:
- inform about the state of the modules (dirty, ahead of origin/master,
not on master, etc)
-
From: Keith Packard kei...@keithp.com
Date: Sat, 17 Apr 2010 21:17:28 -0700
On Fri, 16 Apr 2010 21:57:47 +0200, olafbuddenha...@gmx.net wrote:
I don't see why other distributions can't provide something similar.
Even without true live bulids, IMHO this makes the whole point about
On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis mark.kette...@xs4all.nlwrote:
From: Keith Packard kei...@keithp.com
Date: Sat, 17 Apr 2010 21:17:28 -0700
On Fri, 16 Apr 2010 21:57:47 +0200, olafbuddenha...@gmx.net wrote:
I don't see why other distributions can't provide something
On Sun, Apr 18, 2010 at 12:21:21PM -0400, Joel Feiner wrote:
On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis mark.kette...@xs4all.nlwrote:
From: Keith Packard kei...@keithp.com
Date: Sat, 17 Apr 2010 21:17:28 -0700
On Fri, 16 Apr 2010 21:57:47 +0200, olafbuddenha...@gmx.net wrote:
Hi,
On Tue, Apr 06, 2010 at 06:43:22PM -0700, Keith Packard wrote:
This isn't a git super-module,
Well, why not?
-antrik-
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info:
Hi,
On Wed, Apr 07, 2010 at 11:32:21AM -0500, Donnie Berkholz wrote:
On 23:14 Tue 06 Apr , Keith Packard wrote:
The people we're trying to reach with this are those people building
From source.
For people like me, who really can't rely on a distribution to be up
to date enough, I
On Sun, Apr 18, 2010 at 2:17 PM, Keith Packard kei...@keithp.com wrote:
On Fri, 16 Apr 2010 21:57:47 +0200, olafbuddenha...@gmx.net wrote:
I don't see why other distributions can't provide something similar.
Even without true live bulids, IMHO this makes the whole point about
xserver being
The merger would probably also be the ideal time to finally get around to
moving *proto.pc to $(datadir)/pkgconfig as we've discussed a bunch but never
followed through on. (See https://bugs.freedesktop.org/show_bug.cgi?id=27444
for instance.)
--
-Alan Coopersmith-
On Fri, Apr 16, 2010 at 8:19 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
The merger would probably also be the ideal time to finally get around to
moving *proto.pc to $(datadir)/pkgconfig as we've discussed a bunch but never
followed through on. (See
On Fri, 2010-04-16 at 08:34 -0700, Dan Nicholson wrote:
Although orthogonal to the merging, I think this is a good change.
Furthermore, we already have modules installing .pc files to $datadir,
so people will have to deal with this type of change anyway. It's just
the right thing to do.
Gaetan Nadon wrote:
On Fri, 2010-04-16 at 08:34 -0700, Dan Nicholson wrote:
Although orthogonal to the merging, I think this is a good change.
Furthermore, we already have modules installing .pc files to $datadir,
so people will have to deal with this type of change anyway. It's just
the
On Fri, 2010-04-16 at 08:34 -0700, Dan Nicholson wrote:
Do any of the proto packages install arch-specific headers? Certainly
there are arch-dependent definitions in the headers, but they go in
the same file with #ifdefs, right?
If you look at build.sh. none of the libraries have platform
On Fri, Apr 16, 2010 at 11:18 AM, Gaetan Nadon mems...@videotron.ca wrote:
On Fri, 2010-04-16 at 08:34 -0700, Dan Nicholson wrote:
Do any of the proto packages install arch-specific headers? Certainly
there are arch-dependent definitions in the headers, but they go in
the same file with
On Wed, Apr 14, 2010 at 08:29:35AM -0700, Dan Nicholson wrote:
On Tue, Apr 13, 2010 at 4:20 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
On Tue, Apr 13, 2010 at 06:05:49AM -0700, Dan Nicholson wrote:
On Mon, Apr 12, 2010 at 10:41 PM, Keith Packard kei...@keithp.com wrote:
On Mon, 12
Keith Packard wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto' repository with the current bits.
Eric had an additional suggestion this afternoon -- would it be crazy to
consider
On 2010-04-12 23:58, Keith Packard wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto' repository with the current bits.
I have a few outstanding questions:
1) Right now we have a
On Mon, Apr 12, 2010 at 09:58:12PM -0700, Keith Packard wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto' repository with the current bits.
You claim that you're doing this because
On Mon, Apr 12, 2010 at 10:41 PM, Keith Packard kei...@keithp.com wrote:
On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard kei...@keithp.com wrote:
Eric had an additional suggestion this afternoon -- would it be crazy to
consider merging util/macros and/or util/modular into this package at
On Tue, Apr 13, 2010 at 3:36 AM, Luc Verhaegen l...@skynet.be wrote:
On Mon, Apr 12, 2010 at 09:58:12PM -0700, Keith Packard wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto'
(which will be
often in a merged scenario).
Let's just avoid this by making the top level called xorg-proto.pc or
something and keep xproto.pc tied to just the bare X headers. Since no
packages are using the merged proto package, now is the right time to
make a new name instead of overloading
On Tue, Apr 13, 2010 at 06:14:44AM -0700, Dan Nicholson wrote:
On Tue, Apr 13, 2010 at 3:36 AM, Luc Verhaegen l...@skynet.be wrote:
This will force everyone to update _all_ protos at once, which, in a
normal world, forces updating of _all_ the packages depending on each
of the formerly
On Tue, Apr 13, 2010 at 06:21:01AM -0700, Dan Nicholson wrote:
On Mon, Apr 12, 2010 at 9:58 PM, Keith Packard kei...@keithp.com wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto'
On Fri, Apr 09, 2010 at 11:43:52AM +0200, Florian Mickler wrote:
On Fri, 9 Apr 2010 09:45:01 +0200
Luc Verhaegen l...@skynet.be wrote:
But don't the protocol headers each have packages depending on them
separately, so that an update of the amalgamut triggers an update of
many of the
Luc Verhaegen wrote:
X is a client server architecture, and the proto headers define the
protocol that exists between the clients (through libraries usually) and
the xserver. Both the xserver and the clients depend on these protocol
headers, but not all of those clients depend on the full
On 4/13/10 5:01 PM, Alan Coopersmith wrote:
If the server was moved to xcb protocol definitions (like we'd all like to see
so we can stop having every extension have it's own handwritten protocol
marshalling with the same byte swapping and integer overflow bugs in each),
would we then be merging
On Tue, Apr 13, 2010 at 8:01 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
If the server was moved to xcb protocol definitions (like we'd all like to see
so we can stop having every extension have it's own handwritten protocol
marshalling with the same byte swapping and integer
On Tue, Apr 13, 2010 at 8:36 PM, Luc Verhaegen l...@skynet.be wrote:
On Mon, Apr 12, 2010 at 09:58:12PM -0700, Keith Packard wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto'
Twas brillig at 12:36:19 13.04.2010 UTC+02 when l...@skynet.be did gyre and
gimble:
LV This will force everyone to update _all_ protos at once, which, in
LV a normal world, forces updating of _all_ the packages depending on
LV each of the formerly separate and (mostly) atomic proto headers.
of the merged-protos-package changing.
but if you keep the proto-version seperate from the
merged-proto-package version, nothing changes from the implementation
point of view. it only affects packaging and distribution.
and i guess few developers are using distribution packaging for
development
On Tue, 13 Apr 2010 23:10:12 +0200
Florian Mickler flor...@mickler.org wrote:
if there is no other way to find these dependencies than to rely on the
package-dependencies, i would say indeed. this proposed change does not
help me at all.
and here comes the addendum:
proto changes
On Tue, 13 Apr 2010 16:00:32 +0200
Luc Verhaegen l...@skynet.be wrote:
On Tue, Apr 13, 2010 at 06:21:01AM -0700, Dan Nicholson wrote:
On Mon, Apr 12, 2010 at 9:58 PM, Keith Packard kei...@keithp.com wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone
On Tue, 13 Apr 2010 03:40:40 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
1) Right now we have a bunch of COPYING files in each proto subdirectory
and there is no top-level COPYING. Unfortunately each proto is under a
slightly different license, so consolidating them
On Tue, Apr 13, 2010 at 06:05:49AM -0700, Dan Nicholson wrote:
On Mon, Apr 12, 2010 at 10:41 PM, Keith Packard kei...@keithp.com wrote:
On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard kei...@keithp.com wrote:
Eric had an additional suggestion this afternoon -- would it be crazy to
On Tue, Apr 13, 2010 at 03:40:40AM -0500, Yaakov (Cygwin/X) wrote:
On 2010-04-12 23:58, Keith Packard wrote:
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto' repository with the current
Looks like comments on the xproto package have tapered off; I'll give
everyone another chance, but then I'll go ahead and create a new
xorg-level 'xproto' repository with the current bits.
Eric had an additional suggestion this afternoon -- would it be crazy to
consider merging util/macros
On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard kei...@keithp.com wrote:
Eric had an additional suggestion this afternoon -- would it be crazy to
consider merging util/macros and/or util/modular into this package at
some point? Again, with the goal of making it easier to build the server
or
On Tue, Apr 13, 2010 at 1:41 AM, Keith Packard kei...@keithp.com wrote:
On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard kei...@keithp.com wrote:
Eric had an additional suggestion this afternoon -- would it be crazy to
consider merging util/macros and/or util/modular into this package at
On Tue, Apr 06, 2010 at 11:14:18PM -0700, Keith Packard wrote:
On Wed, 07 Apr 2010 07:38:12 +0200, Rémi Cardona r...@gentoo.org wrote:
We (in gentoo) have spent a lot of time trying to figure out which
protos each app really needs. Now that the split has been done for so
long, I just
On Wed, Apr 07, 2010 at 07:03:56AM -0700, Dan Nicholson wrote:
On Wed, Apr 7, 2010 at 6:50 AM, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
On Wed, Apr 07, 2010 at 08:14:18AM +0200, ext Keith Packard wrote:
In my ideal world, a user interested in trying out the latest driver
bits for
On Thu, Apr 08, 2010 at 12:14:50PM -0700, Dan Nicholson wrote:
You'd have to change all the libraries and apps that depend on them.
That's fine for xorg packages, but it's a little tougher to know about
libraries out in the wild. At the very least, it would require that
you reinstall all
On Fri, 9 Apr 2010 09:45:01 +0200
Luc Verhaegen l...@skynet.be wrote:
But don't the protocol headers each have packages depending on them
separately, so that an update of the amalgamut triggers an update of
many of the packages above the protocol header amalgamut?
is this a valid concern?
On 2010-04-06 17:41, Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get merged in.
The goal is to make the installed files exactly match what
On Thu, Apr 08, 2010 at 02:33:22AM -0500, Yaakov (Cygwin/X) wrote:
On 2010-04-06 17:41, Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get
On Thu, Apr 8, 2010 at 4:40 AM, Peter Hutterer peter.hutte...@who-t.net wrote:
On Thu, Apr 08, 2010 at 02:33:22AM -0500, Yaakov (Cygwin/X) wrote:
On 2010-04-06 17:41, Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're
On Thu, 08 Apr 2010 02:33:22 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
1) Keeping per-extension proto .pc files makes sense wrt to
compatibility, but perhaps keeping all the old version number schemes
does not. For example, in the future, if a package requires
On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard kei...@keithp.com wrote:
On Thu, 08 Apr 2010 02:33:22 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
6) Please tell me you're not planning on releasing this package with the
name proto. :-)
Oh. Yeah, probably not the best
On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard kei...@keithp.com wrote:
On Thu, 08 Apr 2010 02:33:22 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
6) Please tell me you're not planning on
On Thu, 2010-04-08 at 10:17 -0700, Keith Packard wrote:
On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard kei...@keithp.com wrote:
On Thu, 08 Apr 2010 02:33:22 -0500, Yaakov (Cygwin/X)
On Thu, Apr 8, 2010 at 11:24 AM, Gaetan Nadon mems...@videotron.ca wrote:
On Thu, 2010-04-08 at 10:17 -0700, Keith Packard wrote:
On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson dbn.li...@gmail.com
wrote:
On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard kei...@keithp.com wrote:
On Thu, 08 Apr
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
These patches have also been uploaded to annarchy:
http://cgit.freedesktop.org/~yselkowitz/xproto/
Yaakov Selkowitz (6):
Remove deprecated fontcacheproto
Unify gitignore files
Install xproto.pc
Use PACKAGE_VERSION as Version for all
I see that there are no tags in the combined proto repo. Retaining
history should require retaining the tags, too.
The only way I can think of to retain the tags would be to create a repo
with each existing proto tree as a branch (perhaps called legacy/FOO/BAR
for each BAR head of each existing
On Thu, 08 Apr 2010 16:24:44 -0400, James Cloos cl...@jhcloos.com wrote:
I see that there are no tags in the combined proto repo. Retaining
history should require retaining the tags, too.
Almost all of the tags were from CVS days; are those really interesting?
I hope the goal is to
On Thu, 08 Apr 2010 16:24:44 -0400, James Cloos cl...@jhcloos.com wrote:
I see that there are no tags in the combined proto repo. Retaining
history should require retaining the tags, too.
Almost all of the tags in the proto modules are old CVS tags, and
they're all the same names, so we can't
On Thu, 08 Apr 2010 14:24:29 -0400, Gaetan Nadon mems...@videotron.ca wrote:
I like that. I am not sure, but are the old *.pc realy needed? It adds a
little bit to existing complexity:
Just for compatibility with existing users.
For backward compatibility, if config file ask for old package,
On Thu, 8 Apr 2010 14:47:29 -0500, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
These patches have also been uploaded to annarchy:
http://cgit.freedesktop.org/~yselkowitz/xproto/
Thanks. I've merged everything but the
Keith Packard wrote:
For people like me, who really can't rely on a distribution to be up to
date enough, I end up installing protocol headers. Of course, they go
stale if I don't keep on top of them, and so I get accidental version
skew. Reducing the number of packages I have to track from 20
On Wed, Apr 07, 2010 at 01:43:58AM -0700, Alan Coopersmith wrote:
Keith Packard wrote:
For people like me, who really can't rely on a distribution to be up to
date enough, I end up installing protocol headers. Of course, they go
stale if I don't keep on top of them, and so I get accidental
On Wed, Apr 07, 2010 at 08:14:18AM +0200, ext Keith Packard wrote:
In my ideal world, a user interested in trying out the latest driver
bits for their video card would have to download two modules, the
protocol headers and the X server/drivers. Just merging the protocol
headers together gets
On Wed, Apr 7, 2010 at 6:50 AM, Tiago Vignatti tiago.vigna...@nokia.com wrote:
On Wed, Apr 07, 2010 at 08:14:18AM +0200, ext Keith Packard wrote:
In my ideal world, a user interested in trying out the latest driver
bits for their video card would have to download two modules, the
protocol
On Tue, 2010-04-06 at 15:41 -0700, Keith Packard wrote:
Please let me know whether this seems like a good plan, and if so, I'll
move it into the /git/xorg tree and we can work on deprecating the
individual protocol packages.
Seems like a reasonable plan to me.
Implementation seems a little
On Wed, 2010-04-07 at 10:02 -0400, Gaetan Nadon wrote:
On Tue, 2010-04-06 at 18:43 -0700, Keith Packard wrote:
The goal is to reduce the number of packages required to build the X
server or drivers from git or from tarballs.
Have you considered using Automake nested packages feature?
On Wed, 07 Apr 2010 10:02:54 -0400, Gaetan Nadon mems...@videotron.ca wrote:
It may provide the best of both worlds, retaining the desired level of
granularity while distributing a small number of packages.
I don't want to deliver multiple small packages. I want to deliver the
protocol headers
On Wed, 07 Apr 2010 10:56:50 -0400, Adam Jackson a...@nwnk.net wrote:
Implementation seems a little immature. fontsproto, for example, is a
mess. About half the headers are actually function prototypes for
libXfont, which absolutely does not belong there. I'd really like to
see that
On Wed, 2010-04-07 at 11:12 -0700, Keith Packard wrote:
On Wed, 07 Apr 2010 10:56:50 -0400, Adam Jackson a...@nwnk.net wrote:
Implementation seems a little immature. fontsproto, for example, is a
mess. About half the headers are actually function prototypes for
libXfont, which
On Tue, 2010-04-06 at 15:41 -0700, Keith Packard wrote:
Testing and comments welcome.
There might be a few deprecated extensions in the tree
(http://cgit.freedesktop.org/~keithp/proto/tree/).
The build.sh script has been maintained and is up-to-date. Additions and
removals are submitted by
Am 07.04.2010 20:02, schrieb Keith Packard:
I don't want to deliver multiple small packages. I want to deliver the
protocol headers as a unit. Each one installs a couple of header files
and a protocol spec.
i like this idea for the protocol headers, they are only needed for
development
Ok, I've cleaned up the build process and removed the spurious
configure.ac/autogen.sh files. It now passes 'make distcheck' and I've
stuck a .tar.gz file in:
http://people.freedesktop.org/~keithp/proto-0.0.99.1.tar.gz
At this point, I'd like people to nominate subdirectories that should be
On Wed, 07 Apr 2010 17:09:18 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
- calibrateproto
- lg3dproto
- pmproto
- printproto
- trapproto
- xf86miscproto
- xf86rushproto
Doesn't appear to have broken my X server build at least :-)
I've pushed the tree with these removed.
On Wed, Apr 07, 2010 at 01:43:58AM -0700, Alan Coopersmith wrote:
But around 15 of those haven't really changed in years, beyond whot's recent
cleanup of moving the library headers out of the proto module so the proto
modules can change even less.
How many extensions are under regular active
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get merged in.
Here's the merged package:
git clone git://people.freedesktop.org/home/keithp/proto.git
Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get merged in.
Here's the merged package:
git clone git://people.freedesktop.org
On Wed, Apr 7, 2010 at 8:46 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get
Dave Airlie wrote:
On Wed, Apr 7, 2010 at 8:46 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub
On Tue, 06 Apr 2010 15:41:41 -0700, Keith Packard kei...@keithp.com wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get merged in.
Here's the merged
On Wed, Apr 7, 2010 at 8:46 AM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
Keith Packard wrote:
I've written some scripts that construct a merged proto package from the
existing proto packages. They're not fancy, but do preserve the entire
history of each sub package as they get
On Tue, 06 Apr 2010 15:46:28 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
So this still has each proto get released as individual tarballs, just merges
the git repo? What's the difference between this and the git super-module
Peter made?
No, the plan is to release a single
On Tue, 06 Apr 2010 16:32:18 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
How would updating different protocols work - if xrandr dri2 updates were
both in progress, then we couldn't have a stable version of either until both
were ready? Or would we just force protocol
Le 07/04/2010 00:41, Keith Packard a écrit :
Please let me know whether this seems like a good plan, and if so, I'll
move it into the /git/xorg tree and we can work on deprecating the
individual protocol packages.
We (in gentoo) have spent a lot of time trying to figure out which
protos each
87 matches
Mail list logo
