On Mon, 20 Oct 2003 05:00:21 +1000
Chris Ison <[EMAIL PROTECTED]> wrote:
> make[5]: Leaving directory
> `/usr/src/dri-cvs/new/xc/xc/lib/freetype2/freetype/internal'
> make[4]: Leaving directory
> `/usr/src/dri-cvs/new/xc/xc/lib/freetype2/freetype'
> make[3]: Leaving directory `/usr/src/dri-cvs/new
make[5]: Leaving directory
`/usr/src/dri-cvs/new/xc/xc/lib/freetype2/freetype/internal'
make[4]: Leaving directory
`/usr/src/dri-cvs/new/xc/xc/lib/freetype2/freetype'
make[3]: Leaving directory `/usr/src/dri-cvs/new/xc/xc/lib/freetype2'
cleaning in lib/expat...
make: *** expat: No such file or dire
On Tue, Oct 07, 2003 at 12:23:16PM +0100, José Fonseca wrote:
> On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
> > Hi all,
> >
> > I'm happy to report that I found a solution to the merge problems Eric
> > and I were seeing. I believe the problem had to do with vendor branches.
> >
Michel Dänzer wrote:
On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote:
Hmm. These problems only arise because of the way the merge was done? Why
not just document the right way to do the merge?
I think tagging the branch point is a good idea regardless.
I agree. Documenting both the right way
On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote:
>
> Hmm. These problems only arise because of the way the merge was done? Why
> not just document the right way to do the merge?
I think tagging the branch point is a good idea regardless.
--
Earthling Michel Dänzer \ Debian (powerpc), X
> > Hmm. These problems only arise because of the way the merge was done? Why
> > not just document the right way to do the merge?
>
I'd agree with Keith the proper way to merge needs documenting, CVS vendor
import is what is needed, the XFree CVS is vendor imported into our DRI
tree, the chang
On Tue, 07 Oct 2003 12:32:45 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> José Fonseca wrote:
> > On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
> >
> >>Hi all,
> >>
> >>I'm happy to report that I found a solution to the merge problems Eric
> >>and I were seeing. I believe th
José Fonseca wrote:
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are created automatically when sources are imported using
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
> Hi all,
>
> I'm happy to report that I found a solution to the merge problems Eric
> and I were seeing. I believe the problem had to do with vendor branches.
> They are created automatically when sources are imported using cvs
> impo
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are created automatically when sources are imported using cvs
import. Many files from XFree86 had a vendor branch (e.g. revisions
1.1.1.x) wi
Eric and I had problems with merging the trunk into branches. We get
inexplicable conflicts in files that were never touched on the branch. I
found a CVS bug report that describes more or less the problem we're
seeing:
http://www.geocrawler.com/archives/3/383/1999/8/50/2524697/
It's quite old and
On Sat, 2003-09-20 at 17:27, José Fonseca wrote:
>
> PS: The command to fix that would be (assuming one has sed version 4.0
> or greater):
>
> find . -name Repository | xargs sed -i -e 's:^xc/::'
^^
's:^xc/xc:xc:' would be idempotent.
--
On Sat, Sep 20, 2003 at 02:41:20PM +0200, Michel Dänzer wrote:
> On Fri, 2003-09-19 at 12:13, José Fonseca wrote:
> >
> > BTW, a pet peeve of mine is the double 'xc/xc' in the main CVS module.
> > If viable, when transitioning leave only one 'xc', and take way the
> > orfan 'xc/t' dir too.
>
> Th
On Fri, 2003-09-19 at 12:13, José Fonseca wrote:
>
> BTW, a pet peeve of mine is the double 'xc/xc' in the main CVS module.
> If viable, when transitioning leave only one 'xc', and take way the
> orfan 'xc/t' dir too.
This could be done by moving the repository files accordingly, but the
CVS/Repo
I'm going to add a new module to the CVS, named 'moin', to version the
DRI costumizations made to MoinMoin Wiki. But there is no interest in
moving it to freedesktop.org -- it'll remain at SF as long as the
webpages also do.
There is no point either to move the 'faq' module, as the DRI Developers
Okay there is one in my a/c on freedesktop.org with Sep 12 00:20 on it,
but I'm sure it is from the backup server not the primary.. so it is
probably missing 24 hrs of commits.. the history file in CVSROOT is
probably the best place to start...
god knows how long it will be until sf update the t
VTK compilation:
Building executable /opt/VTK/V4.0/VTK/bin/vtk...
/usr/X11R6/lib/libGL.so: undefined reference to `glXGetContextReadDrawable'
collect2: ld returned 1 exit status
V4.0/VTK> l /usr/X11R6/lib/libGL.so.1.2
-rwxr-xr-x1 root root 609431 Sep 7 22:33
/usr/X11R6/lib/libGL.s
On Wed, Sep 03, 2003 at 09:20:37AM +0100, Keith Whitwell wrote:
> Larry McVoy wrote:
> >Over time we have a plan to make this go away. The main reason that
> >there have been license issues is that we had a goal to give the latest
> >and greatest out for free, that's how we could help open source
Larry McVoy wrote:
From: Linus Torvalds <[EMAIL PROTECTED]>
To: Jon Smirl <[EMAIL PROTECTED]>
Subject: Re: Sourceforge CVS, was Re: [Dri-devel] radeon error
On Tue, 2 Sep 2003, Jon Smirl wrote:
Having used CVS and BitKeeper, BitKeeper is way better.
I will just add a big "Amen, Brother!" to that.
> From: Linus Torvalds <[EMAIL PROTECTED]>
> To: Jon Smirl <[EMAIL PROTECTED]>
> Subject: Re: Sourceforge CVS, was Re: [Dri-devel] radeon error
>
> On Tue, 2 Sep 2003, Jon Smirl wrote:
> > Having used CVS and BitKeeper, BitKeeper is way better.
>
> I will just add a big "Amen, Brother!" to that.
On Mon, 2003-09-01 at 01:09, Steven Newbury wrote:
> It seems the /tmp filesystem is full on the CVS server.
>
> [EMAIL PROTECTED] dri-trunk]$ cvs update -dP
> cannot mkdir /tmp/cvs-serv6716/lib/lbxutil
> No space left on device
We can't do anything about it, please submit an sf.net support reque
It seems the /tmp filesystem is full on the CVS server.
[EMAIL PROTECTED] dri-trunk]$ cvs update -dP
cannot mkdir /tmp/cvs-serv6716/lib/lbxutil
No space left on device
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
h
On Wed, Jul 02, 2003 at 05:28:05PM +0100, Alan Hourihane wrote:
> On Tue, Jul 01, 2003 at 10:30:48PM +0200, Felix Kühling wrote:
> > Hi,
> >
> > I've been wondering about keywords in Imakefiles that look like CVS
> > keywords. Examples from xc/programs/Imakefile:
> >
> > XCOMM $Xorg: Imakefile,v
On Tue, Jul 01, 2003 at 10:30:48PM +0200, Felix Kühling wrote:
> Hi,
>
> I've been wondering about keywords in Imakefiles that look like CVS
> keywords. Examples from xc/programs/Imakefile:
>
> XCOMM $Xorg: Imakefile,v 1.4 2000/08/17 19:47:01 cpqbld Exp $
>
> XCOMM $XFree86: xc/programs/Imakefil
Felix Kühling wrote:
Hi,
I've been wondering about keywords in Imakefiles that look like CVS
keywords. Examples from xc/programs/Imakefile:
XCOMM $Xorg: Imakefile,v 1.4 2000/08/17 19:47:01 cpqbld Exp $
XCOMM $XFree86: xc/programs/Imakefile,v 3.53 2002/11/20 04:43:50 dawes Exp $
Of course they ar
Hi,
I've been wondering about keywords in Imakefiles that look like CVS
keywords. Examples from xc/programs/Imakefile:
XCOMM $Xorg: Imakefile,v 1.4 2000/08/17 19:47:01 cpqbld Exp $
XCOMM $XFree86: xc/programs/Imakefile,v 3.53 2002/11/20 04:43:50 dawes Exp $
Of course they are not documented in
José Fonseca wrote:
Thanks for everybody that confirmed the problem. I've reverted all my
changes in the trunk, so starting from today the snapshots should no
longer have this problem. This, of course, if the anonymous CVS
repository doesn't get delayed again...
FYI, I've just checked it out and it
I'm not sure it's your work. I saw the bug in Xfree86 CVS from a
couple weeks ago, so unless the trees were synced recently, it might be
something else.
Alex
--- José Fonseca <[EMAIL PROTECTED]> wrote:
> Thanks for everybody that confirmed the problem. I've reverted all my
> changes in the trunk
Thanks for everybody that confirmed the problem. I've reverted all my
changes in the trunk, so starting from today the snapshots should no
longer have this problem. This, of course, if the anonymous CVS
repository doesn't get delayed again...
I moved by changes into a new branch (newdrm-0-0-1-bran
I'm experiencing the same.
On Wed, 2003-06-18 at 16:16, Alex Deucher wrote:
> For what it's worth I'm seeing the same behavior on my m6 using Xfree86
> CVS from a couple weeks ago. I have to rmmod radeon to and restart X
> to get 3D to work. same messages in my log file.
>
> Alex
>
>
On Wed, Jun 18, 2003 at 10:54:02AM +, Martin Spott wrote:
> Jos? Fonseca <[EMAIL PROTECTED]> wrote:
>
> > I'm going to see if I can reproduce the problem and solve it.
>
> I'd like to help if anyone suggests how to do so,
Sure, Martin. I didn't asked more of you since there have been some
in
Am Mittwoch, 18. Juni 2003 01:37 schrieb José Fonseca:
> Roland,
>
> On Tue, Jun 17, 2003 at 11:15:02PM +0200, Roland Scheidegger wrote:
> > >FWIW, I get that now always when I start the X server, then shut down
> > >the X server and start it again. DRI will never work again, unless I
> > >rmmod th
For what it's worth I'm seeing the same behavior on my m6 using Xfree86
CVS from a couple weeks ago. I have to rmmod radeon to and restart X
to get 3D to work. same messages in my log file.
Alex
---
José Fonseca wrote:
>>(II) RADEON(0): [drm] created "radeon" driver at busi
Jos? Fonseca <[EMAIL PROTECTED]> wrote:
> I'm going to see if I can reproduce the problem and solve it.
I'd like to help if anyone suggests how to do so,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
---
Roland,
On Tue, Jun 17, 2003 at 11:15:02PM +0200, Roland Scheidegger wrote:
> >FWIW, I get that now always when I start the X server, then shut down
> >the X server and start it again. DRI will never work again, unless I
> >rmmod the radeon module manually before I restart the X server. Sounds
>
Roland Scheidegger wrote:
José Fonseca wrote:
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7
(II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000
(II) RADEON(0): [drm] framebuffer handle = 0xd800
(II) RADEON(0
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> FWIW, I get that now always when I start the X server, then shut down
> the X server and start it again. DRI will never work again, unless I
> rmmod the radeon module manually before I restart the X server. Sounds
> like some initialization thing.
José Fonseca wrote:
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7
(II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000
(II) RADEON(0): [drm] framebuffer handle = 0xd800
(II) RADEON(0): [drm] added 1 reserved c
On Mon, Jun 16, 2003 at 03:47:10PM +0200, Martin Spott wrote:
> I've attached the DRM patch I'm talking about the whole time. You might
> compare it with yours to see, if my CVS tree is missing some part. The patch
> applies against stock 2.4.20 kernel DRM.
Stupid - sorry for my mistake. This doe
On Mon, Jun 16, 2003 at 02:31:45PM +0100, José Fonseca wrote:
> On Mon, Jun 16, 2003 at 01:48:35PM +0200, Martin Spott wrote:
> > (II) RADEON(0): Direct rendering disabled
>
> This can't be. This log can't possible match the other one you gave me.
> In the /var/log/messages it showed the agp buff
On Mon, Jun 16, 2003 at 02:30:51PM +0200, Martin Spott wrote:
> On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote:
>
> > And everything else looks normal - the AGP seems to be alive and
> > kicking. Do you still get "direct rendering: No" in glxinfo or "AGP not
> > available" in /var/lo
On Mon, Jun 16, 2003 at 01:48:35PM +0200, Martin Spott wrote:
> On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote:
>
> > And everything else looks normal - the AGP seems to be alive and
> > kicking. Do you still get "direct rendering: No" in glxinfo or "AGP not
> > available" in /var/lo
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote:
> And everything else looks normal - the AGP seems to be alive and
> kicking. Do you still get "direct rendering: No" in glxinfo or "AGP not
> available" in /var/log/messages ?
As I already said: Yes.
Now I rebuilt the kernel modules f
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote:
> And everything else looks normal - the AGP seems to be alive and
> kicking. Do you still get "direct rendering: No" in glxinfo or "AGP not
> available" in /var/log/messages ?
Yep:
1.) /var/log/XFree86.0.log tells me
(II) RADEON(0):
Martin,
On Mon, Jun 16, 2003 at 11:43:45AM +0200, Martin Spott wrote:
> Hello Jose
> (I don't know how to type the accent on my keyboard),
:) Don't worry about that!
>
> On Sun, Jun 15, 2003 at 09:21:18PM +0200, Martin Spott wrote:
>
> > I'll redo the debug output on monday - just to make sh
Hello Jose (I don't know how to type the accent on my keyboard),
On Sun, Jun 15, 2003 at 09:21:18PM +0200, Martin Spott wrote:
> I'll redo the debug output on monday - just to make shure I did not make any
> mistake. I'm doing this with an OEM Radeon9100. Unfortunately I gave away my
> Radeon7500
On Sun, Jun 15, 2003 at 07:47:35PM +0100, José Fonseca wrote:
> Something fishy is going on here. My debug statements never appear in
> your log and I've just retested on my test box with the latest CVS and
> everything works as expected with the radeon driver:
[...]
> Martin, are you're sure you'
On Fri, Jun 13, 2003 at 01:53:19PM +0200, Martin Spott wrote:
> > Content-Disposition: attachment; filename="drm_agp-debug2.diff"
>
> I applied both of Jose's patches and loaded the 'radeon' module with
> drm_opts=debug as suggested my Michel. I attached the compressed debug
> output from loading
Martin Spott <[EMAIL PROTECTED]> wrote:
> I applied both of Jose's patches and loaded the 'radeon' module with
> drm_opts=debug as suggested my Michel. I attached the compressed debug
> output from loading the module until X server startup that I found in
> /var/log/messages.
BTW, I forgot to men
> Content-Disposition: attachment; filename="drm_agp-debug2.diff"
I applied both of Jose's patches and loaded the 'radeon' module with
drm_opts=debug as suggested my Michel. I attached the compressed debug
output from loading the module until X server startup that I found in
/var/log/messages.
If
On Thu, Jun 12, 2003 at 12:19:17PM +0200, Michel Dänzer wrote:
> On Thu, 2003-06-12 at 08:42, Martin Spott wrote:
> > I applied your patch but I did not notice where the expected debug output
> > should appear. Should it show up on STDERR, in the syslog, in XFree ?
>
> Wherever kernel output goes
On Thu, Jun 12, 2003 at 08:42:03AM +0200, Martin Spott wrote:
> Hello Jose,
>
> > Since it's easy for you to rebuild the kernel module, try the attached
> > patch which adds a debug output line. That line should appear, and both
> > pointers should be non-NULL.
>
> I applied your patch but I did
On Thu, 2003-06-12 at 08:42, Martin Spott wrote:
>
> > Since it's easy for you to rebuild the kernel module, try the attached
> > patch which adds a debug output line. That line should appear, and both
> > pointers should be non-NULL.
>
> I applied your patch but I did not notice where the expect
Hello Jose,
> Since it's easy for you to rebuild the kernel module, try the attached
> patch which adds a debug output line. That line should appear, and both
> pointers should be non-NULL.
I applied your patch but I did not notice where the expected debug output
should appear. Should it show up
On Wed, Jun 11, 2003 at 08:44:31PM +0200, Martin Spott wrote:
> On Wed, Jun 11, 2003 at 07:25:06PM +0100, José Fonseca wrote:
>
> > How can't see how the above two logs match. Which driver version are you
> > using, the latest?
>
> The base I'm running tests on is the XFree86-4.3.0 update to SuSE
On Wed, Jun 11, 2003 at 07:25:06PM +0100, José Fonseca wrote:
> How can't see how the above two logs match. Which driver version are you
> using, the latest?
The base I'm running tests on is the XFree86-4.3.0 update to SuSE-8.1
(which I have a backup of ;-)
Then I'm running 'make World' in a co
Hi,
I have a working version of xdriinfo (the tool that dumps the drivers'
configuration information) that I'd like to commit somewhere in the
config-0-0-1-branch. I suppose xc/programs/... would be the right place.
It's just that this would be the only thing in xc/programs besides the
XServer (al
Jonathan Warren wrote:
I just purchased an ati 8500dv and would like to get the dir project
and the gatos project running on my system. I am trying to identify
what I need to do to make everything work together.
AFAIK you can't have Gatos- and DRI-drivers at the same time. Both
projects use diffe
I just purchased an ati 8500dv and would like to get the dir project and the gatos
project running on my system. I am trying to identify what I need to do to make
everything work together.
I have read through the CVS documentation I can find and have pulled the src from cvs
using the following
On Sun, Mar 02, 2003 at 08:20:52PM +, Keith Whitwell wrote:
> Philip Brown wrote:
> > The one nasty that I do see coming up, and I dont see an easy patch for,
> > is DRM_MALLOC()/DRM_FREE()
> >
> > Solaris requires knowing the size of the kernel mem you are freeing :-/
>
> You could always ad
Philip Brown wrote:
On Sun, Mar 02, 2003 at 11:46:52AM +, Keith Whitwell wrote:
Philip Brown wrote:
For example, I'd like to submit a patch set to fix the issue where
there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is
only one syntax for it:
_DRM_LOCK_IS_HELD(dev->lock
On Sun, Mar 02, 2003 at 11:46:52AM +, Keith Whitwell wrote:
> Philip Brown wrote:
> > For example, I'd like to submit a patch set to fix the issue where
> > there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is
> > only one syntax for it:
> >
> > _DRM_LOCK_IS_HELD(dev->loc
Philip Brown wrote:
If I were to spend the time to put together some portability patches
[for the kernel layer], would someone with cvs access volunteer interest to
review and put them in? I can potentially see a bunch of little ones
coming up, so rather than post every single one individually to
If I were to spend the time to put together some portability patches
[for the kernel layer], would someone with cvs access volunteer interest to
review and put them in? I can potentially see a bunch of little ones
coming up, so rather than post every single one individually to the list, I
thought
>
> Right. locators.h is generated by config(8), which is not used by lkms.
> I wasn't sure what the 'right way' to fix this was, and keep forgetting to ask
> a smart NetBSD person. touching locators.h in
> xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel works for the moment.
>
> touchi
Quoth Adam K Kirchhoff:
>
>Hey guys,
>
> I got the server to build, but when I go to build the drm module,
>I'm getting further errors:
>
>[ root@sorrow - /home/adamk/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm
>/kernel/radeon ]: make
>cc -O2 -I. -I.. -ffreestanding -Werror -
: Erik Reid <[EMAIL PROTECTED]>
> To: Adam K Kirchhoff <[EMAIL PROTECTED]>
> Cc: Eric Anholt <[EMAIL PROTECTED]>
> Subject: Re: [Dri-devel] CVS branches.
>
> Quoth Adam K Kirchhoff:
> >
> >Errr, FYI, I pulled the bsd-4-0-0-branch on my NetBSD machine (whic
7: extensions/XKBfile.h: No such file or directory
*** Error code 1
On 12 Feb 2003, Eric Anholt wrote:
> Date: 12 Feb 2003 17:10:48 -0800
> From: Eric Anholt <[EMAIL PROTECTED]>
> To: Adam K Kirchhoff <[EMAIL PROTECTED]>
> Cc: DRI <[EMAIL PROTECTED]>
> Subject: Re: [D
On Wed, 2003-02-12 at 04:23, Adam K Kirchhoff wrote:
> Hey folks,
>
> I'm trying to find out the branch to use for NetBSD. I know that
> Eric Anholt posted it here in the not-too-distant past, but I can't seem
> to find the e-mail from him anywhere (and the search mechanism on
> sourceforge
Adam K Kirchhoff wrote:
Hey folks,
I'm trying to find out the branch to use for NetBSD. I know that
Eric Anholt posted it here in the not-too-distant past, but I can't seem
to find the e-mail from him anywhere (and the search mechanism on
sourceforge doesn't seem to be working).
Also, would i
Hey folks,
I'm trying to find out the branch to use for NetBSD. I know that
Eric Anholt posted it here in the not-too-distant past, but I can't seem
to find the e-mail from him anywhere (and the search mechanism on
sourceforge doesn't seem to be working).
Also, would it be possi
cvs server: [11:27:06] waiting for anoncvs_dri's lock in
/cvsroot/dri/xc/xc/extras/freetype2/builds/win32/devel
What do you get?
-Dieter
---
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the hi
Ian Romanick wrote:
Keith Whitwell wrote:
This just started happening. Anyone else seeing the same thing?
[keithw@rover xc-trunk]$ cvs update
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages
if any)
I have se
Keith Whitwell wrote:
This just started happening. Anyone else seeing the same thing?
[keithw@rover xc-trunk]$ cvs update
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages if
any)
I have seen that from time to ti
This just started happening. Anyone else seeing the same thing?
[keithw@rover xc-trunk]$ cvs update
ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages if any)
Keith
--
Title: RE: [Dri-devel] CVS issue - unresolved symbols from GLcore?
> I did notice that rendering has
> slowed down on the r200 driver by a magnitude of about 5
> times. This of
> course isn't a very accurate measure purely based of glxgears
> frame rates,
> but i
On Wed, 27 Nov 2002, Brian Paul wrote:
> Brian Paul wrote:
> > D. Hageman wrote:
> >
> >> Is anyone else experiencing unresolved symbols from GLcore from CVS?
> >>
> >> It seems that it can't resolve fabsf and xf86strncat (or some variant
> >> of).
> >> I unfortunately trashed my logs when I re
Brian Paul wrote:
D. Hageman wrote:
Is anyone else experiencing unresolved symbols from GLcore from CVS?
It seems that it can't resolve fabsf and xf86strncat (or some variant
of).
I unfortunately trashed my logs when I reverted back to my previous
build of XFree86. I will try again today so
D. Hageman wrote:
Is anyone else experiencing unresolved symbols from GLcore from CVS?
It seems that it can't resolve fabsf and xf86strncat (or some variant of).
I unfortunately trashed my logs when I reverted back to my previous build
of XFree86. I will try again today sometime to see if I
I get these, too. This is from my /var/log/gdm/:0.log:
Symbol fabsf from module /usr/X11R6-DRI/lib/modules/extensions/libGLcore.a is
unresolved!
Symbol fabsf from module /usr/X11R6-DRI/lib/modules/extensions/libGLcore.a is
unresolved!
Symbol fabsf from module /usr/X11R6-DRI/lib/modules/extension
Am Mittwoch, 27. November 2002 08:27 schrieb D. Hageman:
> Is anyone else experiencing unresolved symbols from GLcore from CVS?
>
> It seems that it can't resolve fabsf and xf86strncat (or some variant of).
This should be fixed for some days by Brian.
> I unfortunately trashed my logs when I reve
Is anyone else experiencing unresolved symbols from GLcore from CVS?
It seems that it can't resolve fabsf and xf86strncat (or some variant of).
I unfortunately trashed my logs when I reverted back to my previous build
of XFree86. I will try again today sometime to see if I can make it go
..
David Dawes wrote:
On Fri, Nov 22, 2002 at 04:55:55PM -0700, Brian Paul wrote:
David,
I think this is a CVS problem that we've seen before.
After merging from the DRI trunk and checking in the changes to the mesa-41
branch I'm finding that a number of files in xc/programs/Xserver/hw/xfree86
dr
On Fri, Nov 22, 2002 at 04:55:55PM -0700, Brian Paul wrote:
>
>David,
>
>I think this is a CVS problem that we've seen before.
>
>After merging from the DRI trunk and checking in the changes to the mesa-41
>branch I'm finding that a number of files in xc/programs/Xserver/hw/xfree86
>drivers/geode a
David,
I think this is a CVS problem that we've seen before.
After merging from the DRI trunk and checking in the changes to the mesa-41
branch I'm finding that a number of files in xc/programs/Xserver/hw/xfree86
drivers/geode aren't getting updated correctly.
Basically, committing changes to t
Alan Hourihane wrote:
On Tue, Oct 22, 2002 at 12:21:00 -0700, Ian Romanick wrote:
Current CVS will not build. It dies trying to link
../../../../extras/freetype2/src/base/ftbase.c to lib/font/FreeType/module/.
I know that some merging is under way from XFree86 CVS. Could that effort
finish to
On Tue, Oct 22, 2002 at 12:21:00 -0700, Ian Romanick wrote:
> Current CVS will not build. It dies trying to link
> ../../../../extras/freetype2/src/base/ftbase.c to lib/font/FreeType/module/.
> I know that some merging is under way from XFree86 CVS. Could that effort
> finish to a point where DRI
Current CVS will not build. It dies trying to link
../../../../extras/freetype2/src/base/ftbase.c to lib/font/FreeType/module/.
I know that some merging is under way from XFree86 CVS. Could that effort
finish to a point where DRI CVS will at least build? :)
--
Smile! http://antwrp.gsfc.nasa.go
Hi,
I can't make any cvs updates or checkouts. It hangs up with messages
like this one:
cvs server: [12:29:45] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/lib/GLw
If I understand the numbers correctly then there is a lock which is over
12 hours old. That's a bit confusing, I completed
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Michal Kozlowski wrote:
> > On Thu, 11 Jul 2002, Stefan Lange wrote:
> >
> >
> >>compiling from cvs shouldn't be a problem, I just followed the DRI
> >>Compilation Guide from the website and everything went fine (you might
> >>have to compile the
On Thu, 18 Apr 2002, David Bronaugh wrote:
> Is the mach64 code based on X 4.2.0? Is it based on X CVS?
>
> I'd like to know so I can build it properly here, and not bork up.
>
> David Bronaugh
>
It's based on 4.2.0. The branchpoint for mach64-0-0-3-branch was shortly
after the initial Mesa
Is the mach64 code based on X 4.2.0? Is it based on X CVS?
I'd like to know so I can build it properly here, and not bork up.
David Bronaugh
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Ian Romanick wrote:
>
> I'm having some really weird problems with a CVS build on Red Hat 7.2.
> Everything works fine on 7.1, but on 7.2 sawfish seg faults in
> Fstructure_define. Has anyone seen this before?
Nope. Are you sure you built correctly?
Keith
I'm having some really weird problems with a CVS build on Red Hat 7.2.
Everything works fine on 7.1, but on 7.2 sawfish seg faults in
Fstructure_define. Has anyone seen this before?
--
Tell that to the Marines!
___
Dri-devel mailing list
[EMAIL PROTE
On 2002.02.27 01:23 Leif Delgass wrote:
> On Tue, 26 Feb 2002, José Fonseca wrote:
>
> > It's done. At least, the trivial changes are made. There is still
> problems
> > in the DDX due to changes in the XFree 4.2.0 tree, and in the Mesa 3D
> > driver.
>
> I thought there were only mininal change
On Tue, 26 Feb 2002, José Fonseca wrote:
> It's done. At least, the trivial changes are made. There is still problems
> in the DDX due to changes in the XFree 4.2.0 tree, and in the Mesa 3D
> driver.
I thought there were only mininal changes to the mach64 (ati) DDX driver
4.2.0. I didn't run
It's done. At least, the trivial changes are made. There is still problems
in the DDX due to changes in the XFree 4.2.0 tree, and in the Mesa 3D
driver.
On 2002.02.26 21:01 Leif Delgass wrote:
> On Tue, 26 Feb 2002, José Fonseca wrote:
>
> > Leif,
> >
> > On 2002.02.26 19:35 Leif Delgass wrote
On Tue, 26 Feb 2002, José Fonseca wrote:
> Leif,
>
> On 2002.02.26 19:35 Leif Delgass wrote:
> > So the mach64-0-0-3-branch is the DRI trunk with the new mahc64 dirs and
> > files added and changes from mach64-0-0-2-branch manually merged, right?
> >
>
> For now it's just equal to the trunk. B
Leif,
On 2002.02.26 19:35 Leif Delgass wrote:
> So the mach64-0-0-3-branch is the DRI trunk with the new mahc64 dirs and
> files added and changes from mach64-0-0-2-branch manually merged, right?
>
For now it's just equal to the trunk. But my local copy is as you
described.
> Is the branch up
So the mach64-0-0-3-branch is the DRI trunk with the new mahc64 dirs and
files added and changes from mach64-0-0-2-branch manually merged, right?
Is the branch up to date with your working tree or do you still have local
changes? I'd like to hack on this too, but I don't want to get in your
way
1 - 100 of 121 matches
Mail list logo
