Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Tue, 14 Mar 2006, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). Please expand on this statement. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Thu, 16 Mar 2006, Marc Aurele La France wrote: On Tue, 14 Mar 2006, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). Please expand on this statement. It overrode a definition in ptyx.h, moving the definition inline into main.c, rather than refining it in xterm.h as a fallback for a configure script test. (main.c has too many special cases) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Thu, 16 Mar 2006, Thomas Dickey wrote: On Thu, 16 Mar 2006, Marc Aurele La France wrote: On Tue, 14 Mar 2006, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). Please expand on this statement. It overrode a definition in ptyx.h, moving the definition inline into main.c, rather than refining it in xterm.h as a fallback for a configure script test. That's irrelevent. My fix holds whether xterm is built through imake or through autowhatchamecallsit. (main.c has too many special cases) Indeed... Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Thu, 16 Mar 2006, Marc Aurele La France wrote: main.c, rather than refining it in xterm.h as a fallback for a configure script test. That's irrelevent. My fix holds whether xterm is built through imake or no, it is relevant. I considered a change like that some time ago, decided that it was too ugly to bother with, and that it would be better to do it properly sometime, leaving the warning as a reminder than cover it up. regards. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Thu, 16 Mar 2006, Thomas Dickey wrote: On Thu, 16 Mar 2006, Marc Aurele La France wrote: main.c, rather than refining it in xterm.h as a fallback for a configure script test. That's irrelevent. My fix holds whether xterm is built through imake or no, it is relevant. I considered a change like that some time ago, decided that it was too ugly to bother with, and that it would be better to do it properly sometime, leaving the warning as a reminder than cover it up. I agree my fix is a coverup, but, as I see it, this has gone on for waaayyy too long. xterm's tty handling needs a major rewrite, perhaps along the lines of OpenSSH's, and I just don't see that happening any time soon. So perhaps, a post-it on your refrigerator would be more productive than reminding everybody else. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Tue, 14 Mar 2006, David Dawes wrote: On Tue, Mar 14, 2006 at 06:49:49PM -0500, Thomas Dickey wrote: than those addressed by the fix for lastlog(). That was using the configure script of course. Perhaps having the particular -D's set by imake would help focus the discussion. gcc -c -O2 -fno-strength-reduce -fno-strict-aliasing -DNO_ASM -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I. -I../../exports/include -I../../exports/include -I../../exports/include/freetype2 -I../../exports/include -Dsun -DSVR4 -D__EXTENSIONS__ -Di386 -D__i386 -D__i386__-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/usr/X11R6 -DUTMP -DUSE_TTY_GROUP -DOSMAJORVERSION=5 -DOSMINORVERSION=9 main.c thanks -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Sun, Mar 12, 2006 at 05:28:02PM -0800, Thomas Dickey wrote: CVSROOT: /home/x-cvs Module name: xc Changes by:[EMAIL PROTECTED] 06/03/12 17:28:02 Log message: 241. Xterm patch #210 (Thomas Dickey). This reinstates the following warnings on Solaris 9: xterm.h:243: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:41: warning: previous declaration of `errno' main.c:452: warning: redundant redeclaration of `ptsname' in same scope /usr/include/stdlib.h:170: warning: previous declaration of `ptsname' main.c:2818: warning: unsigned int format, long unsigned int arg (arg 5) and adds this one: main.c:2586: warning: `pty_search' defined but not used David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Tue, 14 Mar 2006, David Dawes wrote: On Sun, Mar 12, 2006 at 05:28:02PM -0800, Thomas Dickey wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 06/03/12 17:28:02 Log message: 241. Xterm patch #210 (Thomas Dickey). This reinstates the following warnings on Solaris 9: xterm.h:243: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:41: warning: previous declaration of `errno' I test-built on Solaris 8, 9 and 10 without seeing any warnings other than those addressed by the fix for lastlog(). That was using the configure script of course. Perhaps having the particular -D's set by imake would help focus the discussion. main.c:452: warning: redundant redeclaration of `ptsname' in same scope /usr/include/stdlib.h:170: warning: previous declaration of `ptsname' main.c:2818: warning: unsigned int format, long unsigned int arg (arg 5) and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Tue, Mar 14, 2006 at 06:49:49PM -0500, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: On Sun, Mar 12, 2006 at 05:28:02PM -0800, Thomas Dickey wrote: CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 06/03/12 17:28:02 Log message: 241. Xterm patch #210 (Thomas Dickey). This reinstates the following warnings on Solaris 9: xterm.h:243: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:41: warning: previous declaration of `errno' I test-built on Solaris 8, 9 and 10 without seeing any warnings other than those addressed by the fix for lastlog(). That was using the configure script of course. Perhaps having the particular -D's set by imake would help focus the discussion. gcc -c -O2 -fno-strength-reduce -fno-strict-aliasing -DNO_ASM -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I. -I../../exports/include -I../../exports/include -I../../exports/include/freetype2 -I../../exports/include -Dsun -DSVR4 -D__EXTENSIONS__ -Di386 -D__i386 -D__i386__-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/usr/X11R6 -DUTMP -DUSE_TTY_GROUP -DOSMAJORVERSION=5 -DOSMINORVERSION=9 main.c main.c:452: warning: redundant redeclaration of `ptsname' in same scope /usr/include/stdlib.h:170: warning: previous declaration of `ptsname' main.c:2818: warning: unsigned int format, long unsigned int arg (arg 5) and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 06/01/24 20:32:10 Log message: 187. Add two new functions that can be used to scroll the content of an Xaw viewport from outside the viewportWidgetClass (Bugzilla #1648, Alexander Pohoyda). 186. Fix i18n for Xaw's tip widget (Bugzilla #1647, Alexander Pohoyda). 185. Fix a performance issue with Xaw's Tree widget caused by useless relayouts (Bugzilla #1645, Alexander Pohoyda). 184. Add some XChar2b string manipulation functions to Xt (Bugzilla #1646, Alexander Pohoyda). Modified files: xc/lib/Xaw/: Label.c Label.h LabelP.h Simple.c Simple.h SimpleP.h Tip.c Tree.c TreeP.h Viewport.c Viewport.h xc/lib/Xt/: Functions.c Intrinsic.h Xt-def.cpp jump_funcs xc/programs/Xserver/hw/xfree86/: CHANGELOG libXaw and libXt minor revision numbers should be incremented when adding functions. -- Matthieu Herrb ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jan 25, 2006 at 04:41:10PM +0100, Matthieu Herrb wrote: CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 06/01/24 20:32:10 Log message: 187. Add two new functions that can be used to scroll the content of an Xaw viewport from outside the viewportWidgetClass (Bugzilla #1648, Alexander Pohoyda). 186. Fix i18n for Xaw's tip widget (Bugzilla #1647, Alexander Pohoyda). 185. Fix a performance issue with Xaw's Tree widget caused by useless relayouts (Bugzilla #1645, Alexander Pohoyda). 184. Add some XChar2b string manipulation functions to Xt (Bugzilla #1646, Alexander Pohoyda). Modified files: xc/lib/Xaw/: Label.c Label.h LabelP.h Simple.c Simple.h SimpleP.h Tip.c Tree.c TreeP.h Viewport.c Viewport.h xc/lib/Xt/: Functions.c Intrinsic.h Xt-def.cpp jump_funcs xc/programs/Xserver/hw/xfree86/: CHANGELOG libXaw and libXt minor revision numbers should be incremented when adding functions. http://bugs.xfree86.org/show_bug.cgi?id=1646#c2 David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
On Thu, Feb 19, 2004 at 11:20:50PM +0100, Roland Mainz wrote:
David Dawes wrote:
David Dawes wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
Log message:
799. Some more font path checks.
Modified files:
xc/lib/font/fontfile/:
dirfile.c encparse.c fontfile.c
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
Revision ChangesPath
3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
1.20 +7 -2 xc/lib/font/fontfile/encparse.c
3.22 +30 -11xc/lib/font/fontfile/fontfile.c
3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
David:
Somehow these changes broke Xprt's handing of printer builtin fonts
(e.g. font paths prefixed with PRINTER: which are enabled
dynamically on per-model-config basis).
Can you isolate which of the changes causes the problem by adding them
in one at a time?
Yes, it seems that my original observation was wrong. Not the
printer-builtin fonts are affected but parts of the font path are
dropped.
The following statement in xc/lib/font/fontfile/dirfile.c causes the
failure:
(from
http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95action=view)
-- snip --
+ }
+ if (!found_font) {
+ FontFileFreeDir (dir);
+ fclose(file);
+ return BadFontPath;
}
-- snip --
It seems that the change now makes it mandatory that the Xserver allows
to drop invalid font path elements... ;-/
I guess that's this change:
70. Changed behavior of fontfile: don't drop the entire directory if some
fonts cannot be rendered (Egbert Eich).
What exactly is it doing that breaks the printer fonts?
David
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote:
On Thu, Feb 19, 2004 at 11:20:50PM +0100, Roland Mainz wrote:
David Dawes wrote:
David Dawes wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
Log message:
799. Some more font path checks.
Modified files:
xc/lib/font/fontfile/:
dirfile.c encparse.c fontfile.c
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
Revision ChangesPath
3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
1.20 +7 -2 xc/lib/font/fontfile/encparse.c
3.22 +30 -11xc/lib/font/fontfile/fontfile.c
3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
David:
Somehow these changes broke Xprt's handing of printer builtin fonts
(e.g. font paths prefixed with PRINTER: which are enabled
dynamically on per-model-config basis).
Can you isolate which of the changes causes the problem by adding them
in one at a time?
Yes, it seems that my original observation was wrong. Not the
printer-builtin fonts are affected but parts of the font path are
dropped.
The following statement in xc/lib/font/fontfile/dirfile.c causes the
failure:
(from
http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95action=view)
-- snip --
+ }
+ if (!found_font) {
+ FontFileFreeDir (dir);
+ fclose(file);
+ return BadFontPath;
}
-- snip --
It seems that the change now makes it mandatory that the Xserver allows
to drop invalid font path elements... ;-/
I guess that's this change:
70. Changed behavior of fontfile: don't drop the entire directory if some
fonts cannot be rendered (Egbert Eich).
What exactly is it doing that breaks the printer fonts?
It seems that my original observation about missing printer buildin
fonts was wrong. The server refused to start and I thought that this was
caused by problems with the printer buildin fonts (note that I have
modified the font code in my own tree - if someone tries to start Xprt
with an invalid (or missing) configuration the server now refuses to
start (this is mainly to get rid of the myths about Xprint caused by
server misconfiguration)). After some more debugging I realised that the
dropping of font path elements isn't supported by my codebase (since I
am working on a X11R6.6-based tree which misses the code which can drop
parts of the font path without aborting the server startup) so the
server fails to start. My fault... ;-(
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote:
David Dawes wrote:
CVSROOT:/home/x-cvs
Module name:xc
Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
Log message:
799. Some more font path checks.
Modified files:
xc/lib/font/fontfile/:
dirfile.c encparse.c fontfile.c
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
Revision ChangesPath
3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
1.20 +7 -2 xc/lib/font/fontfile/encparse.c
3.22 +30 -11xc/lib/font/fontfile/fontfile.c
3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
David:
Somehow these changes broke Xprt's handing of printer builtin fonts
(e.g. font paths prefixed with PRINTER: which are enabled
dynamically on per-model-config basis).
Can you isolate which of the changes causes the problem by adding them
in one at a time?
Yes, it seems that my original observation was wrong. Not the
printer-builtin fonts are affected but parts of the font path are
dropped.
The following statement in xc/lib/font/fontfile/dirfile.c causes the
failure:
(from
http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95action=view)
-- snip --
+ }
+ if (!found_font) {
+ FontFileFreeDir (dir);
+ fclose(file);
+ return BadFontPath;
}
-- snip --
It seems that the change now makes it mandatory that the Xserver allows
to drop invalid font path elements... ;-/
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26 Log message: 799. Some more font path checks. Modified files: xc/lib/font/fontfile/: dirfile.c encparse.c fontfile.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.18 +17 -1 xc/lib/font/fontfile/dirfile.c 1.20 +7 -2 xc/lib/font/fontfile/encparse.c 3.22 +30 -11xc/lib/font/fontfile/fontfile.c 3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG David: Somehow these changes broke Xprt's handing of printer builtin fonts (e.g. font paths prefixed with PRINTER: which are enabled dynamically on per-model-config basis). Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
On Mon, Feb 16, 2004 at 01:41:30PM +0100, Roland Mainz wrote: David Dawes wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26 Log message: 799. Some more font path checks. Modified files: xc/lib/font/fontfile/: dirfile.c encparse.c fontfile.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.18 +17 -1 xc/lib/font/fontfile/dirfile.c 1.20 +7 -2 xc/lib/font/fontfile/encparse.c 3.22 +30 -11xc/lib/font/fontfile/fontfile.c 3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG David: Somehow these changes broke Xprt's handing of printer builtin fonts (e.g. font paths prefixed with PRINTER: which are enabled dynamically on per-model-config basis). Can you isolate which of the changes causes the problem by adding them in one at a time? David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Matthieu, The new file, prngc.c, uses sockaddr_storage. However, I know that at least Cygwin does not have sockaddr_storage. No alternative is provided and no conditional compilation is in effect to fall back to previous functionality when sockaddr_storage is not available. This breaks the build on Cygwin. What can be done to fix the build on platforms that do not have sockaddr_storage? I already tried using sockaddr instead, but that is missing fields that are contained in sockaddr_storage. Any other ideas? Harold Matthieu Herrb wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/16 22:48:34 Log message: 447. In xdm, use better pseudo-random number generators to generate magic cookies. Add support for EGD and other compatible entropy gathering daemons. (Oswald Buddenhagen from KDE, Matthieu Herrb). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/config/cf/: OpenBSD.cf X11.tmpl darwin.cf xc/programs/xdm/: Imakefile dm.c dm.h dm_auth.h genauth.c mitauth.c resource.c session.c xdm.man xdmauth.c Added files: xc/programs/xdm/: prngc.c Revision ChangesPath 3.2858+4 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.91 +2 -2 xc/config/cf/OpenBSD.cf 1.220 +7 -1 xc/config/cf/X11.tmpl 1.40 +2 -1 xc/config/cf/darwin.cf 3.58 +8 -3 xc/programs/xdm/Imakefile 3.23 +10 -2 xc/programs/xdm/dm.c 3.32 +6 -1 xc/programs/xdm/dm.h 1.3 +10 -2 xc/programs/xdm/dm_auth.h 3.18 +324 -137 xc/programs/xdm/genauth.c 1.6 +8 -2 xc/programs/xdm/mitauth.c 3.12 +20 -1 xc/programs/xdm/resource.c 3.35 +6 -2 xc/programs/xdm/session.c 3.25 +15 -1 xc/programs/xdm/xdm.man 1.6 +8 -2 xc/programs/xdm/xdmauth.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Thu, Jul 31, 2003 at 08:21:39PM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote: I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. If you decide to go this way, please let me know and I will be happy to prepare new diffs. I am going to do it this way. New diffs will be welcome -- thanks. This strategy will require some re-arrangements: instead of accessing a `hp/omnibook(us)', we'll need to do `hp(omnibook.us)' or whatever. Actually, we are trying to fit company/family/model/variant into 2-level structure file/section. If the existing 3-level structure is OK for company/family/model/variant, then a 2-level structure should be OK if family/model are combined into a single parameter. Currently the 'xfree86' rules file selects a geometry based solely on a 'model' name, so a single parameter is converted into a geometry description name. It's conceivable that 'layout' be added as an additional parameter to automatically select us vs intl variants. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: going back to 3.3. Unless someone comes up with a better solution, that's what I'm planning to do. OK, it seems to be the best solution in this situation. I dare to propose another solution, however: to delete the `geometry' directory and created a new one (named `geometry2` or `geom` or whatever) which will have companies as lowercased directories. Is there a reason why the extra geometry descriptions couldn't be added to the original 'hp' file instead of putting them in separate files in a subdirectory? XKB should allow multiple descriptions per file. Yes, that's right. This is not a limitaton of XKB. If you have a look into newly created geometry, you'll see that it already contains 3 sections, which are nested and re-used: 1. for the mouse stick 2. for the base frame and common buttons 3. for US keyboard layout. Some other geometries (like ibm/thinkpad) have also 4. for national layouts. I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. That's right, we can. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. OK, let's do it this way. Some brands just had luck to be created as directories in the first place. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes [EMAIL PROTECTED] writes: On Thu, Jul 31, 2003 at 07:15:43AM +0200, Alexander Pohoyda wrote: I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. OK, so if I understand you correctly, we can re-add the old 'hp' file, and add the omnibook descriptions to it. New descriptions for other vendor keyboards can be added to existing files rather than creating new directories. If you decide to go this way, please let me know and I will be happy to prepare new diffs. This strategy will require some re-arrangements: instead of accessing a `hp/omnibook(us)', we'll need to do `hp(omnibook.us)' or whatever. Actually, we are trying to fit company/family/model/variant into 2-level structure file/section. -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Think about it. Once you do the above, anytime you checkout the repository at any point in the past, suddenly it has changed from all former archives of the past. -- Todd Fries .. [EMAIL PROTECTED] Free Daemon Consulting, LLCLand: 405-748-4596 http://FreeDaemonConsulting.com Mobile: 405-203-6124 ..in support of free software solutions. Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, 30 Jul 2003, Harold L Hunt II wrote: Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. I fetch older versions all the time - on xfree86, I did that, for instance to narrow down the range of dates for a bug introduced into the mouse driver. Having a known working version of something lets you cut down on the effort to isolate a bug. (Moving forward doesn't use the archives for anything except an odd backup format). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Thomas E. Dickey wrote: On Wed, 30 Jul 2003, Harold L Hunt II wrote: Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. I fetch older versions all the time - on xfree86, I did that, for instance to narrow down the range of dates for a bug introduced into the mouse driver. Having a known working version of something lets you cut down on the effort to isolate a bug. (Moving forward doesn't use the archives for anything except an odd backup format). What's the problem here? Go look at HEAD! HEAD checks out just fine and has already had the hp file moved out of the way. Your argument is moot. The only problem is that the decision that was made and applied to HEAD has not been applied to xf-4_3-branch. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, My main question here is why does HEAD not have hp while xf-4_3-branch still does? I can checkout HEAD, but I cannot check out xf-4_3-branch because hp is in the way. Do the changes that you applied to HEAD need to be applied to xf-4_3-branch as well? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Daniel Stone writes: Yes, but what's the alternate solution? I really don't like the changed-case solution, as that sets a precedent of sorts. A note should be made somewhere of the moved files. One could name it hewlett-packard if lowercase is importand. KDE moves files around all the time. It's all you can do to work around the limitations of a fundamentally crippled system. Yes, but we don't. Due to the reason given above. The uppercase/lowercase issue doesn't justify breaking builds of checkouts of older versions. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, I don't see a way how you can work around this as there seems to be no way to exclude files from checkout/update. One could create an alias module in the CVS repositry which excludes the HP directory. Like xc-win -a !xc/programs/xkbcomp/geometry/HP xc Then doing a cvs checkout xc-win may work. However I suspect that a 'cvs update' will still fail as this doesn't know about the module concept. Does this mean I can only get HEAD and new branches from it? I just tried to get the xf-4_3-branch and it has the same problem as the xf-4_3_0_1 tag. I just did this: [EMAIL PROTECTED] ~/x-devel/4.3 $ export [EMAIL PROTECTED]:/cvs [EMAIL PROTECTED] ~/x-devel/4.3 $ export CVS_RSH=ssh [EMAIL PROTECTED] ~/x-devel/4.3 $ cvs -z3 checkout -r xf-4_3-branch xc cvs-checkout.log 21 I got: U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory Does that mean that xf-4_3-branch will never work for Cygwin and that there is nothing we can do to ever fix this? If so, that is really a bummer. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 09:28:10PM +1000, Daniel Stone wrote: On Wed, Jul 30, 2003 at 06:14:06AM -0500, Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. If anyone cared about it, they wouldn't still be using CVS, probably. :P What a ridiculous comment. Aside from this little problem, you can check out any any tagged release of XFree86 over the last 9 years. That you can do this is not an accident. (Versions before this were in a different respository.) This problem happened by going beyond CVS's limits. CVS works just fine (and predictably) providing its limits are understood and worked within. I'm not aware of a sufficiently free alternative that meets this minimum requirement. Yes, but what's the alternate solution? I really don't like the changed-case solution, as that sets a precedent of sorts. A note should be made somewhere of the moved files. In this case I think XKB is flexible enough to allow the issue to be avoided. I'm going to see if I can change our 'cvs' so that it won't allow the changed-case solution. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes wrote: On Wed, Jul 30, 2003 at 01:09:50PM -0400, Harold L Hunt II wrote: Egbert, I don't see a way how you can work around this as there seems to be no way to exclude files from checkout/update. One could create an alias module in the CVS repositry which excludes the HP directory. Like xc-win -a !xc/programs/xkbcomp/geometry/HP xc Then doing a cvs checkout xc-win may work. However I suspect that a 'cvs update' will still fail as this doesn't know about the module concept. Does this mean I can only get HEAD and new branches from it? I just tried to get the xf-4_3-branch and it has the same problem as the xf-4_3_0_1 tag. I just did this: [EMAIL PROTECTED] ~/x-devel/4.3 $ export [EMAIL PROTECTED]:/cvs [EMAIL PROTECTED] ~/x-devel/4.3 $ export CVS_RSH=ssh [EMAIL PROTECTED] ~/x-devel/4.3 $ cvs -z3 checkout -r xf-4_3-branch xc cvs-checkout.log 21 I got: U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory Does that mean that xf-4_3-branch will never work for Cygwin and that there is nothing we can do to ever fix this? If so, that is really a bummer. Be a little patient. This problem will be fixed, and in a way that minimises the impact on the history loss. David David, Okay. For now I checked out xf-4_3-branch on a linux machine, tarred it, copied it to my Cygwin machine, and untarred it. This gives me a working repository, but ideally we will eventually fix this or at least try to prevent it from happening too often in the future. Thanks to everyone for their help, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 07:38:30AM +0200, Alexander Pohoyda wrote: Egbert Eich wrote: CVSROOT: /home/x-cvs Module name: xc Changes by:[EMAIL PROTECTED] 03/06/20 06:15:33 Log message: - moving xkbcom/geometry/HP to xkbcom/geometry/hp doesn't seem to be possible as CVS doesn't allow a directory to have the same name as a deleted file. Added files: xc/programs/xkbcomp/geometry/HP/: Imakefile hp omnibook I have developed the omnibook geometry and I have a new geometry for the DELL Inspiron laptop. I'm not submitting the latter because I would not like to see a new directory DELL there. Why should some company names be capitalized and others not? Would it be possible to fix this issue on the repository side? I mean manually delete files `hp' and `dell' and create directories instead? As has already been discussed, deleting these files from the repository makes it impossible to check out previous releases in their correct form. [I thought I already sent the following, but I haven't seen it come through.] Since XFree86 is a cross platform project, I think we need to avoid conflicts that affect platforms with case-insensitive filesystems. Since CVS doesn't allow directories with the same name as files that have existed at any time, that means that we can't create directories like this. So far, the best solution I can see is to remove the 'HP' directory from the repository. That will only impact the history of the last few snapshots. I think that's preferable to affecting the history of releases going back to 3.3. Unless someone comes up with a better solution, that's what I'm planning to do. Is there a reason why the extra geometry descriptions couldn't be added to the original 'hp' file instead of putting them in separate files in a subdirectory? XKB should allow multiple descriptions per file. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes [EMAIL PROTECTED] writes: going back to 3.3. Unless someone comes up with a better solution, that's what I'm planning to do. OK, it seems to be the best solution in this situation. I dare to propose another solution, however: to delete the `geometry' directory and created a new one (named `geometry2` or `geom` or whatever) which will have companies as lowercased directories. Is there a reason why the extra geometry descriptions couldn't be added to the original 'hp' file instead of putting them in separate files in a subdirectory? XKB should allow multiple descriptions per file. Yes, that's right. This is not a limitaton of XKB. If you have a look into newly created geometry, you'll see that it already contains 3 sections, which are nested and re-used: 1. for the mouse stick 2. for the base frame and common buttons 3. for US keyboard layout. Some other geometries (like ibm/thinkpad) have also 4. for national layouts. I believe that this is a correct way to develop geometries for related keyboards and I think that it is logical to combine them into one file. Knowing all the problems now, I would still prefer this solution. I have already developed 4 geometry specifications and will continue to do so. I don't want to create problems, though :-) I'm open to suggestions. Thanks! -- Alexander Pohoyda [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, I cannot checkout xf-4_3_0_1 because of this whole hp/HP issue. The following is from my cvs checkout log: cvs server: Updating xc/programs/xkbcomp/geometry U xc/programs/xkbcomp/geometry/Imakefile U xc/programs/xkbcomp/geometry/README U xc/programs/xkbcomp/geometry/amiga U xc/programs/xkbcomp/geometry/ataritt U xc/programs/xkbcomp/geometry/dell U xc/programs/xkbcomp/geometry/everex U xc/programs/xkbcomp/geometry/fujitsu U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory I *can* checkout HEAD, so maybe the patch below needs to be applied to the xf-4_3_0_1 branch as well? Note, I do get an hp file when I checkout xf-4_3_0_1, but then it tries to download the HP directory and freaks out on Cygwin. Is this the way that all other platforms work due to cvs, or is this specific to my platform because you can't have two files with the same name but different case? Harold Egbert Eich wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/06/20 06:15:33 Log message: - moving xkbcom/geometry/HP to xkbcom/geometry/hp doesn't seem to be possible as CVS doesn't allow a directory to have the same name as a deleted file. Added files: xc/programs/xkbcomp/geometry/HP/: Imakefile hp omnibook ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jul 30, 2003 at 07:26:52AM +0200, Alexander Pohoyda wrote: Harold L Hunt II [EMAIL PROTECTED] writes: Note, I do get an hp file when I checkout xf-4_3_0_1, but then it tries to download the HP directory and freaks out on Cygwin. Is this the way that all other platforms work due to cvs, or is this specific to my platform because you can't have two files with the same name but different case? Yes, I think that this is a letter case problem. CVS on Cygwin does not see a difference in names, but feels a difference in object type (file vs. directory). Perforce on Windows has the same problems. Please manually delete `hp' file, and try `cvs update' again. Moving hp,v to hp.old,v on the server would also help a lot. Another sterling example of CVS's brokenness. :\ -- Daniel Stone [EMAIL PROTECTED] http://www.kde.org - http://www.debian.org - http://www.xwin.org Configurability is always the best choice when it's pretty simple to implement -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
Re: CVS Update: xc (branch: trunk)
Matthieu Herrb wrote (in a message from Thursday 3) CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 03/04/03 13:48:25 Log message: Document that mode switching functions are asynchronous and that XSetErrorHandler() and XSync() need to be used to get a synchronous like behaviour. (Bugzilla #22). This should read: Bugzilla #48. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
