Re: cannot find -lfl
Suresh Chandra Mannava wrote (in a message from Friday 23) Dear Friends, I am encountering the following error while Installing the build of XFree86 TinyX. I cross compiled X with Abacus compiler (India build processor) make[3]: Entering directory `/home/suresh/xfree/build/programs/xgc' rm -f xgc /usr/abacus-linux-uclibc/bin/abacus-uclibc-gcc -o xgc -O2 -L../../exports/lib -L/usr/X11R6/lib dashlist.o planemask.o getfile.o tests.o text.o choice.o main.o interpret.o record.o testfrac.o gram.o lex.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXext -lX11 -lfl -L/usr/abacus-linux-uclibc/lib -lm /usr/abacusnewb/abacus-anurag-linux/bin/ld: cannot -lfl is the library containing some routines used by lexical analysers generated by flex, a lexical analyser generator. You should check you system to find what's the equivalent library name on the target system. If your target system doesn't provide it, you can probably cross-compile this library from flex sources first. http://www.gnu.org/software/flex/flex.html Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
I would like to join the developer's list.
Hello, I am a Linux developer and have actively been involved with the XFree X Windowing System. Would like to be a part of the developer's list and was wondering where the newsgroups and other conversations are actively taking place. Let me know what I can do for you. __ Brad Arant BARANT Technologies [EMAIL PROTECTED] (949) 305-2424 (949) 305-2425 Fax __ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debian
On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote: Marc Aurele La France wrote: This came up while helping some clueless Windows exile(e): So, how come Debian stable is still at XFree86 4.1? Because that is what they had in 'testing' when they released Debian 3.0r0 (woody) back in July 2002. Currently their 'testing' aka sarge has XFree86 4.2.1 Well, woody was frozen in early 2002, and scheduled to be released in april/may, but the actual release was delayed for putting up the security infrastructure needed to build security updates on all supported arches. plus patches (...-12.1) which is scheduled to be made their 'stable' release possibly in Feburary I believe. Err, i think that 4.3.0-1 will go into unstable soon, and will probably be the one which will go in the next debian release. Only sparc and s390 packages are missing, and sparc will be built soon. I don't know if we will wait for s390. Debian's Changelog for XFree86 4.2.1 http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.2.1-12.1/changelog Also of interest : http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml and particularly this NEWS item : [20 January] A link to the TODO file for upload of XFree86 4.3.0-1 to Debian unstable has been added to the links above. As of this writing, all that remains is completion of the patch audit. Nathanael Nerode has been helping out tremendously with this. When 4.3.0-1 is finally uploaded, be sure to include him in your thank-you it's-about-damn-time messages. I don't understand the Debian policy but it would be nice if at least 4.3.0 was included in their release of sarge as stable next month. A debian/sarge release next month would most assuredly be premature. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
previously cannot find -lfl now cannot find -ltermcap
Dear Friends, I build Xfree86 TinyX for new architecture Abacus, Now I am facing problem while installing(make install) I request your help on the following problem. privously 'make install' failed telling 'cannot find -lfl' I ported flex and cleared that problem Now install failed /usr/abacus-linux-uclibc/bin/abacus-uclibc-gcc -o xterm -O2 -L../../exports/lib -L/usr/X11R6/lib button.o charproc.o charsets.o cursor.o data.o doublechr.o fontutils.o input.o menu.o misc.o print.o ptydata.o screen.o scrollbar.o tabs.o util.o xstrings.o TekPrsTbl.o Tekproc.o VTPrsTbl.o main.o charclass.o precompose.o wcwidth.o xutf8.o -lXft -lfreetype -lXrender -lXrender -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXext -lX11 -L/usr/abacus-linux-uclibc/lib-ltermcap /usr/abacusnewb/abacus-anurag-linux/bin/ld: cannot find -ltermcap collect2: ld returned 1 exit status make[3]: *** [xterm] Error 1 I think termcap should be ported. I am using uClibc-0.9.19 I didn't faced any problem during compilation. why Xfree86 never prompted for this libraries while building? I like to know still how many libraries to be ported for proper install of TinyX. Regards, Suresh = --- Suresh Chandra Mannava. Research Scholar, V I T, India. mannavaatvit.ac.in Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: previously cannot find -lfl now cannot find -ltermcap
On Fri, 23 Jan 2004, [iso-8859-1] Suresh Chandra Mannava wrote: I think termcap should be ported. I am using uClibc-0.9.19 termcap (or ncurses) would be one of your system libraries, and is not part of XFree86. I didn't faced any problem during compilation. why Xfree86 never prompted for this libraries while building? I like to know still how many libraries to be ported for proper install of TinyX. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
congratulations!!!!!
CATEGORY B WINNER WINNING NOTICE! KP6821873DL It is our pleasure to inform you that you have emerged as a Category B winner of the Spanish International Lotto. CONGRATULATIONS! You are entitled to a prize sum of US$2,500,000.00. Reference number for your prize is KP7021993DL; ticket number A/04-5512. As a category B winner, you have been selected from a total number of 25,000 names drawn from Asia, Africa, Europe, Middle East and America. After the computer ballot of our International Promotions Program, only six winners emerged in the category and therefore both are to receive payouts of US$2,500,000.00 from the total US$15,000,000.00 for second category winners. To immediately collect your prize, please contact our Category B financial handlers with information below: Mr. Eduardo Sanchez Financial Director LINK FIANACE AND SECURITY S.L C/ PRINCIPE VEGARA 68 MADRID SPAIN TELEPHONE: 0034 -916-438874 FAX: 0034 916 -432623 Email:[EMAIL PROTECTED] Provide prize reference number-KP7021993DL and winning ticket number-A/04-5512 for confirmation. In your best interests, you must initiate contact within one week of receipt of this correspondence. Transatlantic Diplomatic Security Company Ltd will handle all matters with regards to claiming your prize. You are also advised to send a copy of this email, either by fax or email, to your financial handler Mr. Eduardo Sanchez, when contacting him. You are to keep all lottery information from the public as we will not entertain cases of multiple claims processing or compromise the privacy and security for all winners. Other necessary International Lotto Spain information are: Draw 1 number: 01-1238 Draw 2 number: 02-5643 International Lottery code no: IL55663 You may be required to provide any of the above information during the process of collecting your prize. We congratulate you once again and it is our hope that you participate in any of our international programs in the nearest future. Thank you. Sincerely, Gongalez Enriko Promotions Manager International Lotto Spain ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Mouse grabbing
Hello.
There is such task: I need to grab all mouse and keyboard events on some screen, do
something after each event, and generate that events back to applications.
I try to do it like follows:
At first I grab mouse, remove first event from the queue, (here I must do smth.),
ungrab the pointer (to simulate event), and simulate that event back to app. Than I
try to grab mouse again, but XGrabPointer says me that it already grabed.
This is the code:
#include X11/X.h
#include X11/Xlib.h
#include iostream
#include unistd.h
#include X11/extensions/XTest.h
#include vector
int Record()
{
Display* tmp_pDisplay=XOpenDisplay(0);
if (0 == tmp_pDisplay) return 0;
Window root=RootWindow(tmp_pDisplay,0);
if (GrabSuccess !=
XGrabPointer(tmp_pDisplay,root,false,ButtonPressMask|ButtonPressMask,
GrabModeSync,GrabModeAsync,None,None,CurrentTime))
{
std::coutcouldn't grab mouse\n;
exit(1);
}
XEvent Event;
XButtonEvent EButton;
static int count=0;
while (count++ 50)
{
XAllowEvents(tmp_pDisplay,SyncPointer,CurrentTime);
XWindowEvent(tmp_pDisplay,root,ButtonPressMask|ButtonReleaseMask,Event);
XUngrabPointer(tmp_pDisplay,CurrentTime);
switch (Event.type)
{
case ButtonPress:
EButton=Event.xbutton;
XTestFakeButtonEvent(tmp_pDisplay,EButton.button,true,CurrentTime);
std::coutButtonPress\tEButton.time'\n';
break;
case ButtonRelease:
EButton=Event.xbutton;
XTestFakeButtonEvent(tmp_pDisplay,EButton.button,false,CurrentTime);
std::coutButtonRelease\tEButton.time'\n';
break;
};
XFlush(tmp_pDisplay);
int Status1=XGrabPointer(tmp_pDisplay,root,false,ButtonPressMask|ButtonPressMask,
GrabModeSync,GrabModeAsync,None,None,CurrentTime);
if (Status1==AlreadyGrabbed)
{
std::coutAlready grabbed\n;
exit(1);
}
if (Status1!=GrabSuccess)
{
std::coutcan't grab mouse\n;
exit(1);
}
}
XUngrabPointer(tmp_pDisplay,CurrentTime);
XCloseDisplay(tmp_pDisplay);
}
int main()
{
Record();
return 0;
}
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Debian
On Fri, 23 Jan 2004, Sven Luther wrote: Anyway, what's this user's easiest path to 4.3? Install the experimental package (if he runs sarge or unstable already), if he runs woody, the best guess would be Michel Daenzer's dri-trunk packages : # Michel's DRI packages deb http://people.debian.org/~daenzer/dri-trunk ./ deb-src http://people.debian.org/~daenzer/dri-trunk ./ As backporting 4.3.0 to debian/woody needs that you already have a running 4.2.1 backport and some other dependency hell. Well, he has installed (and re-installed) from woody CDs. I've pointed him to Michel's deb's. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debian
Sven Luther wrote: On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote: I don't understand the Debian policy but it would be nice if at least 4.3.0 was included in their release of sarge as stable next month. A debian/sarge release next month would most assuredly be premature. My (limited) understanding is that there plan to release a new stable in 2004, with the goal of being sooner than later. Is this correct? What version of XFree86 will the new (future 2004) stable include 4.2.1 or 4.3.0? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debian
On Fri, Jan 23, 2004 at 10:51:24AM -0500, Michael Taylor wrote: Sven Luther wrote: On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote: I don't understand the Debian policy but it would be nice if at least 4.3.0 was included in their release of sarge as stable next month. A debian/sarge release next month would most assuredly be premature. My (limited) understanding is that there plan to release a new stable in 2004, with the goal of being sooner than later. Is this correct? Yeah, sure. What version of XFree86 will the new (future 2004) stable include 4.2.1 or 4.3.0? 4.3.0 naturally. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I would like to join the developer's list.
--- Brad Arant [EMAIL PROTECTED] wrote: Hello, I am a Linux developer and have actively been involved with the XFree X Windowing System. Would like to be a part of the developer's list and was wondering where the newsgroups and other conversations are actively taking place. devel (this list) is the main developers list for xfree86. other lists of interest to you may be: dri-devel (sourceforge) - development of open source 3D drivers mesa3d-devel (sourceforge) - development of open source openGL implementation and 3D drivers xserver (freedesktop) - discussion and development of alternative X server Let me know what I can do for you. feel free to work on whatever aspect interests you. Alex __ Brad Arant BARANT Technologies [EMAIL PROTECTED] (949) 305-2424 (949) 305-2425 Fax __ __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 10:28:27PM -0600, Ryan Underwood wrote: On Tue, Jan 20, 2004 at 10:53:06PM -0500, David Dawes wrote: Someone needs to track down the bug that causes a server crash and subsequent lockup if a dualhead config is used but mga_hal is not available (either not around or wasn't compiled with support for it). I thought I fixed it with a oneliner in that patch but it turns out that I was using the wrong config at the time to test it. Does your patch reduce the need for the mga_hal module for dual-headed configurations? That'd be nice. Yes, one goal is that I'm trying to eliminate the necessity of mga_hal at least on my G400MAX. The other is to optionally expose maven functionality in XFree86. This will be a configuration option so that we don't conflict with matroxfb maven usage. Sounds good. The mga_hal stuff made a mess of what was once a relatively clean driver. The workarounds needed for problems associated with using the mga_hal module made things even worse. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Wed, Jan 21, 2004 at 12:06:50PM +0600, Ivan Pascal wrote:
Hello,
Mark Vojkovich wrote:
On Mon, 19 Jan 2004, David Dawes wrote:
Tests for XChangeKeyboardControl
Test 9: FAIL
Test 10: FAIL
That has been showing up for a while. It should be followed up.
That's been showing up for a couple years. It's a regression.
I think the tests are incorrect. Both tests try to set keyboard LEDs (using
XChangeKeyboardControl) then read the LEDs state (XGetKeyboardControl) and
compare values. The difference between the tests is that the first one tries
to change some of LEDs (uses some mask) and the second one tries to set all
LEDs together (without specifying a particular LED number).
But some LEDs can be protected from their change by client application and
reflect keyboard state only.
The man about {Change|Get}KeyboardControl tells:
XChangeKeyboardControl - ...the state of that leds is changed, if possible..
XGetKeyboardControl - ...each bit set to 1 in led_mask indicates an LED that
is lit (Note if possible and an LED that is lit.)
I understand it as Get returns the actual state of LEDs, those that are not
protected and were changed by Change and those that are protected but are
switched on reflecting the keyboard state.
But the tests, obviously, are written in assumption that Get should return the
LED state exactly as it was written into keyboard by Change call. It means all
LEDs should be unprotected (it is not by default) or the keyboard control
structure keeps values written by XChangeKeyboardControl call(s) and at the
XGetKeyboardControl request just returns this record instead of real state
of LEDs.
Where does the LED state get resynced with the DDX? The only place that
I see the LED state synced with the DDX is at init time. If I disable
XKB, 'xset q' doesn't report changes to the real LED state.
Those tests work OK for me now if I disable XKB. I don't think it is
unreasonable to do the core protocol tests with XKB disabled.
BTW, the fix for this regression is very simple. We just have to remove
one line in dix/devices.c where the LEDs mask field of the keyboard controls
structure is being reloaded with the actual LEDs state. The tests will be
passed with success. But there will not be any way (in the core protocol)
to know the real state of LEDs.
It is being loaded with the XKB's LED state, isn't it?
Tests for XRebindKeysym
Test 1: FAIL
The XRebindKeysym failure goes away if XKB is disabled.
Yes, it's a XKB problem/feature.
It is a feature. :)
This problem can be fixed easy too with 'one word patch'. But there is one
unclear thing there.
The RebindKeysym mechanism allows to tie any string to a keysym or a combination
of keysym and a set of modifiers. The binding itself works well, the problem
is the modifiers set interpretation.
For example, we have a key with two keysyms [a A] and want to bind two different
strings to combiantions Alt+a and Alt+A. How should we specify the second
combination - Alt + 'A', Alt + Shift + 'a' or Alt + Shift + 'A'?
The core protocol's assumes the third variant, i.e. takes the keysym figured
out with taking in account the Shift modifier but also checks all modifiers
obtained from the key event.
But the XKB-aware XLookupString 'consumes' all modifiers used at the keysym
choosing and hide them from the routine that checks string_to_key bindins,
i.e. it expects that the combiantion is just Alt + 'A'.
BTW, this behavour can be swithed on/off with a special 'client side XKB' flag
but by default XLookupString 'eats' consumed modifiers.
Thus the problem is what modifiers set should the bindings check routine use.
Shoud it always be the original 'state' field from the key event or the
consumed modifiers may be removed from a consideration. If we require there
a full compatibility with the core protocol the answer is obvious. But some
calls in XKB-aware Xlib already have differences from core protocol ones.
And the first form of that combination seems to me more logical (IMHO,
of course).
Side note: I wonder if anybody (anything) uses this 'rebind keysym' feature
anywhere.
On the other hand the test itself could be changed. One way is to make it
XKB-aware and make it set the needed flag (that turns the XLookupString
behavior to the 'core protocol like' one). Another way is don't use the Shift
modifier (that can be 'eaten' under some circumstance) there. All other
modifiers (except Caps) would be interpreted equaly in both (with/without XKB)
cases.
That sounds reasonable to me. It would also be nice to add some XKB tests
to the test suite.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Wed, Jan 21, 2004 at 12:34:17PM +0100, Gian Filippo Pinzari wrote: David Dawes wrote: I don't have any objections to doing this on Linux. As I said, we already do it on a range of other platforms and I'm not sure why Linux is something of an exception in this regard. Does anyone have a good reason to not do this? In NX we use alternate versions of libX11, libXext and libXrender. This is done in a way that doesn't interfere with the existing X client environment, by setting LD_LIBRARY_PATH and, sometimes, LD_PRELOAD, before running the involved application. Probably the same applies to other systems built on top of X11. The use of -rpath is not going to compromise this possibility and I would consider this OK. Anyway, as a rule of thumb, I would prefer a system where the only libraries that are used are those listed in ld.so.conf. A specific application could still override the system settings. Such application might wish to do so in order to coexist with an alternate setup (think at two different versions of KDE or GNOME installed on the same computer). Having applications defaulting to a hardcoded library path could be a nightmare. I would really prefer to deal with a program failing with an unre- solved symbol instead of one dumping its core in the background for no apparent reason. So long as ld.so.conf overrides the rpath (does it?) then this won't matter. LD_LIBRARY_PATH and LD_PRELOAD won't work for setuid apps. I'd be happy to make the change for 4.4 if there is some concensus that it isn't a bad thing to do, and providing that ld.so.conf provides a mechanism for overriding the rpath. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Fri, Jan 23, 2004 at 05:43:02PM -0500, David Dawes wrote:
So long as ld.so.conf overrides the rpath (does it?) then this won't
matter. LD_LIBRARY_PATH and LD_PRELOAD won't work for setuid apps.
It doesn't.
Searching for libraries is done in glibc the following order:
DT_RPATH directories (provided DT_RUNPATH dynamic tag doesn't exist)
LD_LIBRARY_PATH env variable dirs
DT_RUNPATH directories
ld.so.cache directories (created by ldconfig which searches directories
mentioned in ld.so.conf and system dirs)
system dirs
Using -rpath on Linux is a bad idea for any directories which can be considered
standard (/lib{,64}, /usr/lib{,64}, /usr/X11R6/lib{,64} certainly should
be considered as standard), as it slows down program startup unnecessarily
(ld.so needs to search for each loaded library all DT_RPATH or DT_RUNPATH
dirs and up to 7 their subdirectories for processor features while without
-rpath it can pick up the right lib from the cache without any filesystem
searching) and (only with -rpath and not -rpath --enable-new-dtags) cannot
be overridden by environment.
Jakub
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Fri, Jan 23, 2004 at 10:16:08PM +0100, Jakub Jelinek wrote:
On Fri, Jan 23, 2004 at 05:43:02PM -0500, David Dawes wrote:
So long as ld.so.conf overrides the rpath (does it?) then this won't
matter. LD_LIBRARY_PATH and LD_PRELOAD won't work for setuid apps.
It doesn't.
Searching for libraries is done in glibc the following order:
DT_RPATH directories (provided DT_RUNPATH dynamic tag doesn't exist)
LD_LIBRARY_PATH env variable dirs
DT_RUNPATH directories
ld.so.cache directories (created by ldconfig which searches directories
mentioned in ld.so.conf and system dirs)
system dirs
Using -rpath on Linux is a bad idea for any directories which can be considered
standard (/lib{,64}, /usr/lib{,64}, /usr/X11R6/lib{,64} certainly should
be considered as standard), as it slows down program startup unnecessarily
(ld.so needs to search for each loaded library all DT_RPATH or DT_RUNPATH
dirs and up to 7 their subdirectories for processor features while without
-rpath it can pick up the right lib from the cache without any filesystem
searching) and (only with -rpath and not -rpath --enable-new-dtags) cannot
be overridden by environment.
That possibly means that we should be removing -rpath from other platforms
rather than adding it on Linux.
The only platform I've personally found it useful is SVR4 platforms
where there is no ld.so cache equivalent.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Files with wrong exec bits set
On Wed, Jan 21, 2004 at 09:23:46PM -0700, Marc Aurele La France wrote:
On Tue, 20 Jan 2004, David Dawes wrote:
On Mon, Jan 19, 2004 at 04:46:25PM +0900, Bang Jun-Young wrote:
There are a lot of source files that have wrong exec bits set in the
repository. Although this is not a problem for most of cases, it bothers
me (and possibly other subversion users as well) quite a lot when I
import xc into the subversion repository since subversion keeps track
of metadata changes as well as file content changes. Could anybody deal
with that? Those file include extras/ogl-sample/../*.{c,cc,h,gl},
Imakefile, GNUmakefile, Distfile, and etc.
I'll take a look at it.
The problem with this is that the permissions might be reset the next time
something is committed to the affected files. So, all committers would
need to re-checkout after the permission changes are made, or change the
permissions in their own copy.
This isn't a problem in my experience. The permissions are set based
on the initial commit/import, and not changed thereafter.
Anyway, I fixed all of the files that I think incorrectly had exec set.
If anyone finds others, let me know.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Files with wrong exec bits set
On Thu, Jan 22, 2004 at 07:43:13AM +0100, Matthieu Herrb wrote:
Marc Aurele La France wrote (in a message from Wednesday 21)
On Tue, 20 Jan 2004, David Dawes wrote:
On Mon, Jan 19, 2004 at 04:46:25PM +0900, Bang Jun-Young wrote:
There are a lot of source files that have wrong exec bits set in the
repository. Although this is not a problem for most of cases, it bothers
me (and possibly other subversion users as well) quite a lot when I
import xc into the subversion repository since subversion keeps track
of metadata changes as well as file content changes. Could anybody deal
with that? Those file include extras/ogl-sample/../*.{c,cc,h,gl},
Imakefile, GNUmakefile, Distfile, and etc.
I'll take a look at it.
The problem with this is that the permissions might be reset the next time
something is committed to the affected files. So, all committers would
need to re-checkout after the permission changes are made, or change the
permissions in their own copy.
Once we've make sure that nothing in the build process depends on
checked-out file being executable (ie shell scrips are executed as 'sh
script' by make), we can add a pre-commit check to avoid making such
mistakes in the future, and manually fix the modes in the repository.
Nothing in our build process should depend on this. If something does,
that part of the build process needs to be fixed.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: PFNGLXGETUSTPROC argument signed or unsigned?
On Thu, Jan 22, 2004 at 10:50:29PM -0800, Ian Romanick wrote: David Dawes wrote: What is the correct typedef for PFNGLXGETUSTPROC? glxclient.h has: typedef int (* PFNGLXGETUSTPROC) ( int64_t * ust ); and it is used as a signed quantity in glxcmds.c. But most drivers use uint64_t, and src/glx/mini/dri_util.h in the Mesa trunk uses unsigned: typedef int (* PFNGLXGETUSTPROC) ( uint64_t * ust ); That was my bad. It should be int64_t everywhere. It makes more sense for it to be unsigned, but the GLX_OML_sync_control spec has it as signed. http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_sync_control.txt Thanks for the clarification. I committed the relevant changes earlier today. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Concerned by Security?
Title: [EMAIL PROTECTED] [EMAIL PROTECTED] Saturday, 24 January 2004 ARE YOU CONCERNED ABOUT SECURITY? If you are like most people the answer is YES! It is impossible not to listen to a news article on security, threats and/or terrorism. Breach is a company soon to launch security testing, both electronically and physically; in doing so Phase 1 of Breachs website is up and all members of the public are invited free of charge to join and have their say on security, regardless of the area concerned. Please logon to http://www.breachmanagement.com and have your say If you wish to receive no more communication from Breach please email [EMAIL PROTECTED] with remove in the subject heading. Hope to see you online. PLEASE HELP US BY PASSING THIS URL ON
Re: -rpath not used under Linux
On Fri, Jan 23, 2004 at 08:23:38PM -0500, David Dawes wrote: [glibc search order] That possibly means that we should be removing -rpath from other platforms rather than adding it on Linux. No, please don't do that. On NetBSD you can't use LD_LIBRARY_PATH for setuid or setgid programs and /usr/X11R6/lib is not in the default search path. Bernd ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
