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
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 pac
On Wed, Apr 7, 2010 at 8:46 AM, Alan Coopersmith
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 t
Dave Airlie wrote:
> On Wed, Apr 7, 2010 at 8:46 AM, Alan Coopersmith
> 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
On Tue, 06 Apr 2010 15:41:41 -0700, 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.
>
&g
>> On Wed, Apr 7, 2010 at 8:46 AM, Alan Coopersmith
>> 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
On Tue, 06 Apr 2010 15:46:28 -0700, Alan Coopersmith
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 tarball. But, that doesn't
On Tue, 06 Apr 2010 16:32:18 -0700, Alan Coopersmith
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 development to live on branches
On Tue, 06 Apr 2010 16:47:37 -0700, Eric Anholt wrote:
> git clone git://people.freedesktop.org/~keithp/proto.git
>
> and it can now be cloned via anongit.
Thanks, Eric.
--
keith.pack...@intel.com
pgpSDjhx8iGd8.pgp
Description: PGP signature
___
x
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
On Wed, 07 Apr 2010 07:38:12 +0200, Rémi Cardona 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 don't see the advantage of merging them back.
For distros who have already done 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
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 accid
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
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?
It may provide the best of both worlds, retaining the des
On Wed, Apr 7, 2010 at 6:50 AM, Tiago Vignatti 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 headers and the X s
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" feat
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 end up installing protocol headers. Of course, they
> go stale if I d
On Wed, 07 Apr 2010 10:02:54 -0400, Gaetan Nadon 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 as a unit. Each on
On Wed, 07 Apr 2010 10:56:50 -0400, Adam Jackson 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 cleaned out once
On Wed, 2010-04-07 at 11:12 -0700, Keith Packard wrote:
> On Wed, 07 Apr 2010 10:56:50 -0400, Adam Jackson 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
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
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 and
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
rem
Keith Packard wrote:
> At this point, I'd like people to nominate subdirectories that should be
> removed;
These seem unnecessary for a modern server build:
- calibrateproto
- lg3dproto
- pmproto
- printproto
- trapproto
- xf86miscproto
- xf86rushproto
evieproto is questionable, since people kee
On Wed, 07 Apr 2010 17:09:18 -0700, Alan Coopersmith
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.
--
keith.pack...@int
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 ac
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
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
> >
On Thu, Apr 8, 2010 at 4:40 AM, Peter Hutterer 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
On Thu, 08 Apr 2010 02:33:22 -0500, "Yaakov (Cygwin/X)"
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
> compositeproto >= 0.4.2 (after
On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard wrote:
> On Thu, 08 Apr 2010 02:33:22 -0500, "Yaakov (Cygwin/X)"
> wrote:
>
>> 6) Please tell me you're not planning on releasing this package with the
>> name "proto". :-)
>
> Oh. Yeah, probably not the best name. 'xproto'? 'xprotocol'?
Well, consi
On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson wrote:
> On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard wrote:
> > On Thu, 08 Apr 2010 02:33:22 -0500, "Yaakov (Cygwin/X)"
> > wrote:
> >
> >> 6) Please tell me you're not planning on releasing this package with the
> >> name "proto". :-)
> >
> >
On Thu, 2010-04-08 at 10:17 -0700, Keith Packard wrote:
> On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson wrote:
> > On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard wrote:
> > > On Thu, 08 Apr 2010 02:33:22 -0500, "Yaakov (Cygwin/X)"
> > > wrote:
> > >
> > >> 6) Please tell me you're not planni
On Thu, Apr 8, 2010 at 11:24 AM, Gaetan Nadon wrote:
> On Thu, 2010-04-08 at 10:17 -0700, Keith Packard wrote:
>
> On Thu, 8 Apr 2010 09:12:39 -0700, Dan Nicholson
> wrote:
>> On Thu, Apr 8, 2010 at 9:01 AM, Keith Packard wrote:
>> > On Thu, 08 Apr 2010 02:33:22 -0500, "Yaakov (Cygwin/X)"
>> >
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 F
On Thu, 08 Apr 2010 16:24:44 -0400, James Cloos 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 eliminate the existing,
On Thu, 08 Apr 2010 16:24:44 -0400, James Cloos 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 move them forwa
On Thu, 08 Apr 2010 14:24:29 -0400, Gaetan Nadon 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, then old
> packag
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 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 don't see th
On Wed, Apr 07, 2010 at 07:03:56AM -0700, Dan Nicholson wrote:
> On Wed, Apr 7, 2010 at 6:50 AM, Tiago Vignatti
> 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
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 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?
what libr
On Thu, 2010-04-08 at 13:59 -0700, Keith Packard wrote:
> On Thu, 08 Apr 2010 14:24:29 -0400, Gaetan Nadon 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.
Please leave al
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 and/or
On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard 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 drivers, this
On Tue, Apr 13, 2010 at 1:41 AM, Keith Packard wrote:
> On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard 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 go
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
> con
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 bunc
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 beca
On Mon, Apr 12, 2010 at 10:41 PM, Keith Packard wrote:
> On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard 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 g
On Tue, Apr 13, 2010 at 3:36 AM, Luc Verhaegen 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' repository w
proto version gets bumped (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
On Tue, Apr 13, 2010 at 06:14:44AM -0700, Dan Nicholson wrote:
> On Tue, Apr 13, 2010 at 3:36 AM, Luc Verhaegen 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 separate
On Tue, Apr 13, 2010 at 06:21:01AM -0700, Dan Nicholson wrote:
> On Mon, Apr 12, 2010 at 9:58 PM, 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' reposito
On Fri, Apr 09, 2010 at 11:43:52AM +0200, Florian Mickler wrote:
> On Fri, 9 Apr 2010 09:45:01 +0200
> Luc Verhaegen 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 pac
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 ful
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
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),
I was
On Tue, Apr 13, 2010 at 8:36 PM, Luc Verhaegen 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' repository w
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
os to change heavily, then you
would have not a n:1 but again a n:m. And by merging the protos, you
increase the chance 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
On Tue, 13 Apr 2010 23:10:12 +0200
Florian Mickler 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 have to be backwards
On Tue, 13 Apr 2010 16:00:32 +0200
Luc Verhaegen 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 wrote:
> > >
> > > Looks like comments on the xproto package have tapered off; I'll give
> > > everyone another chance, but
On Tue, 13 Apr 2010 03:40:40 -0500, "Yaakov (Cygwin/X)"
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 may have to be along
> the li
On Tue, 13 Apr 2010 06:21:01 -0700, Dan Nicholson wrote:
> Keith, I just noticed that you moved the xproto.pc file from x11proto
> to the top-level. I think this is a bad idea unless you change all the
> libraries to not check for xproto (which they do now). This will cause
> people that don't kn
On Tue, Apr 13, 2010 at 06:05:49AM -0700, Dan Nicholson wrote:
> On Mon, Apr 12, 2010 at 10:41 PM, Keith Packard wrote:
> > On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard wrote:
> >
> >> Eric had an additional suggestion this afternoon -- would it be crazy to
> >> consider merging util/macros
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 curr
On Tue, Apr 13, 2010 at 4:20 PM, Peter Hutterer
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 wrote:
>> > On Mon, 12 Apr 2010 21:58:12 -0700, Keith Packard
>> > wrote:
>> >
>> >> Eric had an additional suggestion this
On Wed, Apr 14, 2010 at 08:29:35AM -0700, Dan Nicholson wrote:
> On Tue, Apr 13, 2010 at 4:20 PM, Peter Hutterer
> 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 wrote:
> >> > On Mon, 12 Apr 2010 21:58:12 -0700, Keith
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-alan.coopersm.
On Fri, Apr 16, 2010 at 8:19 AM, Alan Coopersmith
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 https://bugs.freedesktop.org/show_bug.cgi?id=27444
> fo
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
>>
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 platfor
On Fri, Apr 16, 2010 at 11:18 AM, Gaetan Nadon 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 #ifdefs, right?
>
> I
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: http://lists.x.org/mailman
Hi,
On Wed, Apr 07, 2010 at 11:02:47AM -0700, Keith Packard wrote:
> On Wed, 07 Apr 2010 10:02:54 -0400, Gaetan Nadon >
> 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
On Fri, 16 Apr 2010 22:45:02 +0200, 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?
I don't think the wire protocol is a place where we should be
encouraging a mix-n-match approach to development or release
On Sat, Apr 17, 2010 at 09:20:45PM -0700, Keith Packard wrote:
> On Fri, 16 Apr 2010 22:45:02 +0200, 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 where we shoul
From: Yaakov Selkowitz
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 protos
Bump version to 7.2-pre
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
On Thu, 8 Apr 2010 14:47:29 -0500, "Yaakov (Cygwin/X)"
wrote:
> From: Yaakov Selkowitz
>
> These patches have also been uploaded to annarchy:
> http://cgit.freedesktop.org/~yselkowitz/xproto/
Thanks. I've merged everything but the PACKAGE_VERSION change and pushed
that to my xproto repo now.
On Fri, 16 Apr 2010 21:57:47 +0200, 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 too hard to build pretty moot.
Not really; except for Gentoo, all these kinds of builds ever se
On Sun, Apr 18, 2010 at 2:17 PM, Keith Packard wrote:
> On Fri, 16 Apr 2010 21:57:47 +0200, 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 too hard to build pretty moot.
>
>
> From: Keith Packard
> Date: Sat, 17 Apr 2010 21:17:28 -0700
>
> On Fri, 16 Apr 2010 21:57:47 +0200, 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 too hard to build pr
On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis wrote:
> > From: Keith Packard
> > Date: Sat, 17 Apr 2010 21:17:28 -0700
> >
> > On Fri, 16 Apr 2010 21:57:47 +0200, wrote:
> >
> > > I don't see why other distributions can't provide something similar.
> > > Even without true live bulids, IMHO this
On Sun, Apr 18, 2010 at 12:21:21PM -0400, Joel Feiner wrote:
> On Sun, Apr 18, 2010 at 7:45 AM, Mark Kettenis wrote:
>
> > > From: Keith Packard
> > > Date: Sat, 17 Apr 2010 21:17:28 -0700
> > >
> > > On Fri, 16 Apr 2010 21:57:47 +0200, wrote:
> > >
> > > > I don't see why other distributions ca
On Sun, 18 Apr 2010 19:30:31 +0200
Dirk Wallenstein 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)
> - swap in and ou
On Mon, Apr 19, 2010 at 01:19:30PM +0200, Florian Mickler wrote:
> On Sun, 18 Apr 2010 19:30:31 +0200
> Dirk Wallenstein 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 modul
On Tue, 20 Apr 2010 15:54:43 +0200
Dirk Wallenstein wrote:
> On Mon, Apr 19, 2010 at 01:19:30PM +0200, Florian Mickler wrote:
> > On Sun, 18 Apr 2010 19:30:31 +0200
> > Dirk Wallenstein wrote:
> >
> > > A full-fledged meta-git repo management tool suite would be nice. Such
> > > an application
On 18 April 2010 17:21, Joel Feiner 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 later. You al
On Tue, Apr 20, 2010 at 09:16:22PM +0100, David Gerard wrote:
> On 18 April 2010 17:21, Joel Feiner 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 wo
On 20 April 2010 23:24, Peter Hutterer 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 is an a*se and a
On Tue, Apr 20, 2010 at 11:29:28PM +0100, David Gerard wrote:
> On 20 April 2010 23:24, Peter Hutterer 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 inst
On Die, 2010-04-20 at 21:16 +0100, David Gerard wrote:
> On 18 April 2010 17:21, Joel Feiner 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 (vi
Well, I don't want to challenge the tinderbox, I'm just pondering how
the whole module-set could be augmented by some functions that are
located a bit above git. And it needn't be full-fledged as I was saying.
I mean, ..., full-fledged would probably constitute of a pedestal with a
monitor, some bu
On Wed, 21 Apr 2010 13:37:51 +0200
Dirk Wallenstein wrote:
> Well, I don't want to challenge the tinderbox, I'm just pondering how
> the whole module-set could be augmented by some functions that are
> located a bit above git. And it needn't be full-fledged as I was saying.
> I mean, ..., full-fl
On Wed, Apr 21, 2010 at 02:18:11PM +0200, Florian Mickler wrote:
> and which automagically selects all necessary protocols, extensions,
> fonts, and whatnot to make it work with your selections and after that
> you just start building and it fetches everything and compiles and so
> on... it probabl
1 - 100 of 103 matches
Mail list logo
