[davem@davemloft.net: Re: more on xserver-xfree86]
I think the patch for sparc to allow scanning the newer style PCI proc domain entries has broken 2.4's PCI scanning. - Forwarded message from David S. Miller [EMAIL PROTECTED] - From: David S. Miller [EMAIL PROTECTED] To: Ben Collins [EMAIL PROTECTED] Subject: Re: more on xserver-xfree86 X-Face: _;p5u5aPsO,_Vsx^v-pEq09'CU4Dc1$fQExov$62l60cgCc%FnIwD=.UF^a?5'9Kn[;[EMAIL PROTECTED]=?[:Ty?SD(R*-3ItVj:)dP X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on bristol.swissdisk.com X-Spam-Level: X-Spam-Status: No, hits=-3.4 required=4.9 tests=AWL,BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=2.64 On Tue, 7 Sep 2004 11:58:18 -0400 Ben Collins [EMAIL PROTECTED] wrote: On Tue, Sep 07, 2004 at 09:24:30AM -0700, David S. Miller wrote: Very strange, it doesn't crash with 2.6.x kernels but it does with 2.4.28, :-/ I wonder if the change to get the PCI domain scanning for 2.6 broke the 2.4 method. That sounds like a hot clue to me :) - End forwarded message - -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Bug#225526: Bug#246782: [davem@redhat.com: Fw: Re: Kernel 2.6.x breaks X on blade 100]
On Thu, Jun 03, 2004 at 11:13:32PM -0500, Branden Robinson wrote: On Fri, May 28, 2004 at 07:32:20AM -0400, Ben Collins wrote: A few weeks ago, I asked for an updated version of the other patch: * Apply patch by David S. Miller to implement XAA and Render support in the sunffb driver. - debian/patches/073_sunffb_xaa_render_fb_support.diff If you could get a version to me that will build I'd be happy to apply it. However, the missing symbols that are being complained have to do with DRI and drm, not XAA or Render. Since then, I haven't heard anything more. I'm working on an updated patch as we speak. How's this coming? I'm ready for it, and Fabio and I would both like to have it in 4.3.0.dfsg.1-5. I think it's ready. I'm going to let dave test the debs (since I don't have a sunffb card) before I let you guys have the patch. When's the latest you'll accept the patch? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Bug#245246: xserver-xfree86: xserver starts but suddenly dies before and windowmanager or similar starts
On Thu, Apr 29, 2004 at 11:57:42AM -0500, Branden Robinson wrote: tag 245246 - moreinfo tag 245246 + help thanks On Thu, Apr 29, 2004 at 03:24:31PM +0200, Joerg Friedrich wrote: Branden Robinson schrieb am Mittwoch, 28. April 2004 um 02:49:07 -0500: Does the X server stay up if you give it no clients to run? One way to test this is simply to run X as root. definitly X, I tried to run 'X' as root, the result is the same. Okay, it looks like the sunffb driver is definitely busted in testing and unstable. Is this minus the patches that I sent you? -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Bug#236705: xfree86: FTBFS on sparc; 073_sunffb_xaa_render_fb_support.diff broken
On Tue, Mar 16, 2004 at 07:02:55PM +, Colin Watson wrote: On Tue, Mar 09, 2004 at 02:30:50AM -0500, Branden Robinson wrote: On Sun, Mar 07, 2004 at 03:45:45PM -0500, Ben Collins wrote: Colin Watson wrote: The problem appears to be that the sunffb patch added in 4.3.0-3 declares and uses FFBDPMSSet, but doesn't actually provide a new function definition. This suggests that there may have been other problems in the patch as added to the package, too, so it should be replaced or reverted. Ben, ccing you because Branden says you submitted the patch. I might have missed a file that was needed. Can you get me the missing file(s) ASAP? Otherwise I'll have to back the patch out. Is it time now to back this out for the time being? KDE 3.2 builds are waiting for this, not to mention that XFree86 4.3 in sarge soon would be a Really Good Thing for our release timeline. Yeah, please do. I'll get you new patches asap. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Bug#236705: xfree86: FTBFS on sparc; 073_sunffb_xaa_render_fb_support.diff broken
The problem appears to be that the sunffb patch added in 4.3.0-3 declares and uses FFBDPMSSet, but doesn't actually provide a new function definition. This suggests that there may have been other problems in the patch as added to the package, too, so it should be replaced or reverted. Ben, ccing you because Branden says you submitted the patch. I might have missed a file that was needed. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Re: Why XFree86 4.2 Isn't in Woody
On Tue, Apr 16, 2002 at 07:01:06AM -0500, Branden Robinson wrote: A couple of people on a recent thread in debian-devel linked to a message I recently posted on Slashdot on this subject. I had thought about posting this information to Debian's lists as well, but at the time, didn't see a need. Thanks to that recent thread, now I see a need. :) What the fuck is going on! When in this insane world did Branden become the polite well mannered one, and I become the asshole! -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ATI Mach64 Problem
On Thu, Feb 14, 2002 at 06:25:03PM +0100, Eddie C. Dost wrote: On Thu, Feb 14, 2002 at 03:42:10PM +0100, Eddie C. Dost wrote: This second card works perfectly well. Any ideas anyone? Which Xs have you tried? 4.1.0 doesn't work, i.e. shows wrong endianess, 3.3.6 works ok, but the RedHat 3.3.6 I used does an mmap on /dev/fb, not /proc/bus/pci/XX/YY.Z All 3.3.x ones do that for ultrasparc. The current Debian packages use a new patch from Dave Miller that mmap's /proc/bus/pci/XX/YY.Z. Seems it doesn't work on your card (no idea why). -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux--WatchGuard.com \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Creator3D + X 4.1.0.1
On Sat, Oct 06, 2001 at 11:07:36PM -0500, Branden Robinson wrote: On Sat, Oct 06, 2001 at 06:04:58PM -0400, Ben Collins wrote: On Sat, Oct 06, 2001 at 05:28:52PM -0400, Christian Gils wrote: (EE) SUNFFB: Failed to load module dri (once-only module, 0) anyone have any ideas? Comment out the dri module in XF86Config-4, it will load automatically if needed. None of the other modules freak out like this AFAIK. Should this be considered a bug the module loader, or the module itself? Should this be reported upstream to XFree86 and/or David S. Miller? Module loader if you ask me. Sounds like it shouldn't try to load the module if it is already loaded, or it should freak out. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Creator3D + X 4.1.0.1
On Sun, Oct 07, 2001 at 06:51:07AM -0400, Joe Stevens wrote: Speaking of X 4.1 stuff, I recently tried to compile Xfree86 4.1 on my Blade 100, and it compiled without incident, but wouldn't run. (It ran fine after I manually installed the file XFree86 (ie, the X server) extracted from the Debian Woody Sparc package.) After some hunting on archives of this list, it seems a patch is necessary to get Xfree to compile on sparc. Does anyone happen to have this patch, or know where I couldn get it? apt-get source xfree86 You can find all the Debian patches there. -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Creator3D + X 4.1.0.1
On Sat, Oct 06, 2001 at 05:28:52PM -0400, Christian Gils wrote: anyone have any ideas? Comment out the dri module in XF86Config-4, it will load automatically if needed. Ben -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [Debian] How to configure a SPARC5 mouse ?
On Thu, Sep 06, 2001 at 01:24:50PM +0200, Marc Herren wrote: HI, Which are the correct settings to use a mouse under XFree 3.3 on a SPARC machine ? I'm using at the moment BusSystem and /dev/sunmouse which works, but quite often the X server crashes - sunMouseEnqueueEvent : unrecognized id xinit : connection to X server lost. I strongly suggest using XFree86 4.1.0. The old -xsun servers are old hacks. Ben -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: XFree86 4.1.0-1 in auric's incoming
On Sat, Jul 28, 2001 at 09:15:26PM -0500, Branden Robinson wrote: Uploaded for i386, ia64, and powerpc, with sparc on the way. It may take some time for it to be actually dinstalled, since the overrides file needs to be edited, and the FTP admins could reach on IRC seemed strangely hesitant to do so... At any rate, thanks to everyone who helped test the prereleases and get the packages ship-shape. Great work Branden. I'm grateful for the work on getting sparc in the best shape it's been in. Ben -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: XFree86 on mips cleanup patch
On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
Hi,
the attached patch removes some previous workarounds by adding proper
functions to compiler.h for mips(el). This obsoletes the disabling of
the ati driver on mips(351) and the int10 module(350) on mipsel as well
as the mem_barrier patch(353). I've also attached the newport range fix
for completeness - both are against pre5. So these should be the only
patches needed to get XFree86 going on mips/mipsel for now.
-- Guido
Are the below asm functions going to affect other architectures? I don't
see them wrapped in any sort of arch specific defines.
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+static __inline__ unsigned int
+xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
+{
+ unsigned long addr = ((unsigned long)base) + offset;
+ unsigned int ret;
+
+ __asm__ __volatile__(lw %0, 0(%1)
+ : =r (ret)
+ : r (addr));
+ return ret;
+}
+
+static __inline__ void
+xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset,
+ const unsigned int val)
+{
+ unsigned long addr = ((unsigned long)base) + offset;
+
+ __asm__ __volatile__(sw %0, 0(%1)
+ : /* No outputs */
+ : r (val), r (addr));
+}
+#endif
+__asm__ __volatile__(\
+ # prevent instructions being moved around\n\t \
+ .set\tnoreorder\n\t \
+ # 8 nops to fool the R4400 pipeline\n\t \
+ nop;nop;nop;nop;nop;nop;nop;nop\n\t \
+ .set\treorder \
+ : /* no output */ \
+ : /* no input */\
+ : memory)
+#define write_mem_barrier() mem_barrier()
--
---===-=-==-=---==-=--
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=--===-=-=-=-===-==---=--=---'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 on mips cleanup patch
On Wed, Jul 25, 2001 at 06:38:58PM -0400, Stephen Frost wrote: * Ben Collins ([EMAIL PROTECTED]) wrote: On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote: Hi, the attached patch removes some previous workarounds by adding proper functions to compiler.h for mips(el). This obsoletes the disabling of the ati driver on mips(351) and the int10 module(350) on mipsel as well as the mem_barrier patch(353). I've also attached the newport range fix for completeness - both are against pre5. So these should be the only patches needed to get XFree86 going on mips/mipsel for now. -- Guido Are the below asm functions going to affect other architectures? I don't see them wrapped in any sort of arch specific defines. +#endif /* !linux */ #endif /* __mips__ */ Ok, smack me with the blind stick. Sorry. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 on mips cleanup patch
On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
Hi,
the attached patch removes some previous workarounds by adding proper
functions to compiler.h for mips(el). This obsoletes the disabling of
the ati driver on mips(351) and the int10 module(350) on mipsel as well
as the mem_barrier patch(353). I've also attached the newport range fix
for completeness - both are against pre5. So these should be the only
patches needed to get XFree86 going on mips/mipsel for now.
-- Guido
Are the below asm functions going to affect other architectures? I don't
see them wrapped in any sort of arch specific defines.
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+static __inline__ unsigned int
+xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
+{
+ unsigned long addr = ((unsigned long)base) + offset;
+ unsigned int ret;
+
+ __asm__ __volatile__(lw %0, 0(%1)
+ : =r (ret)
+ : r (addr));
+ return ret;
+}
+
+static __inline__ void
+xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset,
+ const unsigned int val)
+{
+ unsigned long addr = ((unsigned long)base) + offset;
+
+ __asm__ __volatile__(sw %0, 0(%1)
+ : /* No outputs */
+ : r (val), r (addr));
+}
+#endif
+__asm__ __volatile__(\
+ # prevent instructions being moved around\n\t \
+ .set\tnoreorder\n\t \
+ # 8 nops to fool the R4400 pipeline\n\t \
+ nop;nop;nop;nop;nop;nop;nop;nop\n\t \
+ .set\treorder \
+ : /* no output */ \
+ : /* no input */\
+ : memory)
+#define write_mem_barrier() mem_barrier()
--
---===-=-==-=---==-=--
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=--===-=-=-=-===-==---=--=---'
Re: XFree86 on mips cleanup patch
On Wed, Jul 25, 2001 at 06:38:58PM -0400, Stephen Frost wrote: * Ben Collins ([EMAIL PROTECTED]) wrote: On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote: Hi, the attached patch removes some previous workarounds by adding proper functions to compiler.h for mips(el). This obsoletes the disabling of the ati driver on mips(351) and the int10 module(350) on mipsel as well as the mem_barrier patch(353). I've also attached the newport range fix for completeness - both are against pre5. So these should be the only patches needed to get XFree86 going on mips/mipsel for now. -- Guido Are the below asm functions going to affect other architectures? I don't see them wrapped in any sort of arch specific defines. +#endif /* !linux */ #endif /* __mips__ */ Ok, smack me with the blind stick. Sorry. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: XFree86 4.1.0-0pre1v5 now available; 4.1.0-1 imminent
On Tue, Jul 17, 2001 at 02:07:55AM -0500, Branden Robinson wrote: On Mon, Jul 16, 2001 at 10:52:12PM -0500, Christian T. Steigies wrote: On my i386 box ABS_WHEEL is define in /usr/include/linux/input.h ($Id: input.h,v 1.18 2000/07/25 21:36:56 vojtech Exp $). On m68k its not ($Id: input.h,v 1.13 2000/05/29 10:54:53 vojtech Exp $) m68k: libc6-dev 2.2.3-5 i386: libc6-dev 2.2.3-6 Soo... its a bug in libc6 and xfree should build-depend on libc6-dev (= 2.2.3-6) maybe (failed to build on m68k, -7 is building)? Or do you need a special build-depends on kernel-header-2.4.x? I might have installed newer header on my i386 box already. Hrm, bah. Yeah, I guess the versioned Build-Dep on libc6 is the way to go. I doubt that is going to help. AFAIK, m68k still uses 2.2.x kernel headers to build glibc. Thus, you need another work around. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: XFree86 Rel. 4.1 Keyboard Configuration (SPARC)
On Tue, Jul 10, 2001 at 03:50:32PM -0500, Branden Robinson wrote: On Mon, Jul 09, 2001 at 04:27:17PM +0200, Guenter Millahn wrote: Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbRules sun Option XkbModel type5_unix Option XkbLayout en_US Option XkbKeymap type5_unix EndSection This is very close to what I need to support Sun keyboards properly. If someone can find a configuration that works and uses only: XkbRules XkbModel XkbLayout Probably just use what's above minus the XkbKeymap option. I need to install a window manager on my u30 to see, but I'll let you know. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 Rel. 4.1 Keyboard Configuration (SPARC)
On Tue, Jul 10, 2001 at 03:50:32PM -0500, Branden Robinson wrote: On Mon, Jul 09, 2001 at 04:27:17PM +0200, Guenter Millahn wrote: Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbRules sun Option XkbModel type5_unix Option XkbLayout en_US Option XkbKeymap type5_unix EndSection This is very close to what I need to support Sun keyboards properly. If someone can find a configuration that works and uses only: XkbRules XkbModel XkbLayout Probably just use what's above minus the XkbKeymap option. I need to install a window manager on my u30 to see, but I'll let you know. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Debian X FAQ updated
+bits-per-pixel; the number of bits per pixel for a given color depth is an +usually an issue for only the author of a hardware driver to worry about. You have an extra an at the end of that first line above. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: results using xfree86 4.1.0-0pre1v1 on sparc
On Thu, Jun 14, 2001 at 12:34:45PM -0400, Adam Di Carlo wrote: Branden Robinson [EMAIL PROTECTED] writes: Was left with both InputDevice Configured Mouse InputDevice Generic Mouse in XF86Config-4. That caused crashes. You don't have /dev/input? No. Should I ? Maybe that's a makedev bug... No, sunmouse is not part of the input core. You need to use /dev/sunmouse (devfs or not), and set the mouse type to BusMouse. This needs to be an option on sparc, Branden. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: results using xfree86 4.1.0-0pre1v1 on sparc
On Thu, Jun 14, 2001 at 12:34:45PM -0400, Adam Di Carlo wrote: Branden Robinson [EMAIL PROTECTED] writes: Was left with both InputDevice Configured Mouse InputDevice Generic Mouse in XF86Config-4. That caused crashes. You don't have /dev/input? No. Should I ? Maybe that's a makedev bug... No, sunmouse is not part of the input core. You need to use /dev/sunmouse (devfs or not), and set the mouse type to BusMouse. This needs to be an option on sparc, Branden. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: STOP THE PRESSES Re: XFree86 4.0.2-12 release and architecture status
On Wed, Mar 28, 2001 at 11:52:51AM -0500, Branden Robinson wrote: 1) 4.0.2-12 for i386 is broken. Just building against libc6 2.2.2-2 is insufficient to avoid the gcc/binutils problem that BenC warned about in debian-devel. Installing gcc 2.95.3-9 makes things suitable for building on i386 now. I just did a test build of db2 and db3, and then linked to them with openldap2 and libnss-db. All went well, as expected. BTW, you might find it easier to use the [EMAIL PROTECTED] alias, rather than using the long list you have now :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: STOP THE PRESSES Re: XFree86 4.0.2-12 release and architecture status
On Wed, Mar 28, 2001 at 11:52:51AM -0500, Branden Robinson wrote: 1) 4.0.2-12 for i386 is broken. Just building against libc6 2.2.2-2 is insufficient to avoid the gcc/binutils problem that BenC warned about in debian-devel. Installing gcc 2.95.3-9 makes things suitable for building on i386 now. I just did a test build of db2 and db3, and then linked to them with openldap2 and libnss-db. All went well, as expected. BTW, you might find it easier to use the [EMAIL PROTECTED] alias, rather than using the long list you have now :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: STOP THE PRESSES Re: XFree86 4.0.2-12 release and architecture status
On Thu, Mar 29, 2001 at 11:34:48PM -0500, Branden Robinson wrote: On Wed, Mar 28, 2001 at 08:39:31PM -0500, Ben Collins wrote: On Wed, Mar 28, 2001 at 11:52:51AM -0500, Branden Robinson wrote: 1) 4.0.2-12 for i386 is broken. Just building against libc6 2.2.2-2 is insufficient to avoid the gcc/binutils problem that BenC warned about in debian-devel. Installing gcc 2.95.3-9 makes things suitable for building on i386 now. I just did a test build of db2 and db3, and then linked to them with openldap2 and libnss-db. All went well, as expected. So the version of libc6-dev I build against is irrelevant? As long as you have gcc 2.95.3-9 installed, yes. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Bug#90622: HELP WANTED: doogiebug strikes latest XFree86 packages
On Thu, Mar 22, 2001 at 12:48:16AM -0800, Mark Montague wrote: I saw and fixed something similar-- on looking with ldd, I found that it ld.so was finding /usr/lib/libc5-compat/libXmu.so.6 before /usr/X11R6/lib/libXmu.so.6. I don't know how /etc/ld.so.conf is built and maintained by dpkg, but for some reason, /usr/X11R6/lib was last in the search path. Moving it up to before /usr/lib/libc5-compat and running ldconfig fixed the problem for me, although strictly speaking, my problem came when I ran nethack (in text mode, no less) and it couldn't find an Xmu symbol, _XA_UTF8_STRING_. My xterm probably broke, too, though; I haven't run any real X programs since the update, since I both updated and ran since via ssh, but in testing, xterm breaks with the old ld.so.conf, and works with the new. I don't think this is the same problem. I've seen one particular linktime error with Xmu on sparc, and it contains no such libc5 libraries. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: XFree86 Version 4.0.2 (RC3)
On Thu, Dec 21, 2000 at 06:06:28PM -0500, Branden Robinson wrote: BenC said X4.0 requires glibc-2.2. Is that a real requiry or does this exist only because you need some libc to build X? If its the latter, I could downgrade my libc6 again and build RC4 with the proven version? I don't think there is anything in the X source tree that requires glibc 2.2. X is written to be portable as hell and in any case I don't think there's anything new in 2.2 that X really needs. I never said that X build-depends on glibc 2.2, I said X *depends* on it, because Branden is building X against glibc 2.2. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [oliver.poths@linsoft.de: XFree86 4.01]
On Wed, Dec 20, 2000 at 05:51:15PM +0100, Charl P. Botha wrote: On Wed, Dec 20, 2000 at 04:58:06PM +0100, Michel Dänzer wrote: "Charl P. Botha" wrote: On Wed, Dec 20, 2000 at 09:49:34AM -0500, Branden Robinson wrote: I couldn´t find a Debian-package for XFree86 4.01 neither for potato nor for woody. You should've searched a bit harder. The XFree86 packages are available on any woody mirror in /dists/woody/main/binary-i386/x11/. Not anymore. woody is now testing, and doesn't have the new X yet. (it doesn't build on m68k and arm) It's currently only in unstable aka sid (right?). Wrong. Woody, aka testing, has XFree86-4.0.1-11. No, it doesn't. X depedns on glibc 2.2 (which is not in woody because of m68k) and it also does not build on all of our supported archs (m68k and arm). So there is no way it can be in testing. -- ---===-=-==-=---==-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [oliver.poths@linsoft.de: XFree86 4.01]
On Wed, Dec 20, 2000 at 05:51:15PM +0100, Charl P. Botha wrote: On Wed, Dec 20, 2000 at 04:58:06PM +0100, Michel Dänzer wrote: Charl P. Botha wrote: On Wed, Dec 20, 2000 at 09:49:34AM -0500, Branden Robinson wrote: I couldn´t find a Debian-package for XFree86 4.01 neither for potato nor for woody. You should've searched a bit harder. The XFree86 packages are available on any woody mirror in /dists/woody/main/binary-i386/x11/. Not anymore. woody is now testing, and doesn't have the new X yet. (it doesn't build on m68k and arm) It's currently only in unstable aka sid (right?). Wrong. Woody, aka testing, has XFree86-4.0.1-11. No, it doesn't. X depedns on glibc 2.2 (which is not in woody because of m68k) and it also does not build on all of our supported archs (m68k and arm). So there is no way it can be in testing. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: m68k MANIFEST for xfree86_4.0.1-11
On Wed, Dec 13, 2000 at 03:46:49PM -0800, Seth Arnold wrote: * Christian T. Steigies [EMAIL PROTECTED] [001213 15:37]: Just for reference: Build needed 18:30:59 (so that Branden knows how long I need _at least_ to get a new MANIFEST). Could a cross-compile environment bring this down? Is there any *need* to compile these things on an m68k? I imagine those new g4s are a bit faster... :) I've been looking for an m68k emu capable of running Linux under my g4. If you know of one, I'de be very interested (with respect to getting glibc compiled done). Doesn't matter if it requires MacOS either, so long as it emulates a 68040 and runs Linux. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: m68k MANIFEST for xfree86_4.0.1-11
On Wed, Dec 13, 2000 at 03:46:49PM -0800, Seth Arnold wrote: * Christian T. Steigies [EMAIL PROTECTED] [001213 15:37]: Just for reference: Build needed 18:30:59 (so that Branden knows how long I need _at least_ to get a new MANIFEST). Could a cross-compile environment bring this down? Is there any *need* to compile these things on an m68k? I imagine those new g4s are a bit faster... :) I've been looking for an m68k emu capable of running Linux under my g4. If you know of one, I'de be very interested (with respect to getting glibc compiled done). Doesn't matter if it requires MacOS either, so long as it emulates a 68040 and runs Linux. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [kteague@sprocket.ddts.net: xserver-xsun drivers]
On Tue, Dec 12, 2000 at 09:02:07AM -0500, Clint Adams wrote: www.xfree86.org doesn't seem to say anything at all about Sun drivers. On a vaguely related note, is there a way other than gpm to get sunmouse support under X4? "Other" way? It's rather simple. Setup gpm to repeat as msc and set X up to use type "MouseSystems" on device /etc/gpmdata. Works perfectly for me. -- ---===-=-==-=---=--------=-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [bruce@perens.com: user not authorized to run the X server]
On Tue, Dec 12, 2000 at 11:45:10AM -0800, Bruce Perens wrote: From: Joshua Shagam [EMAIL PROTECTED] Hey Bruce, are you really such a newbie that you can't read the list archives? ;) Well, you read the archives with a web browser, and my web browser happens to run under the x server that I'm not authorized to run right now. You want me to use LYNX Eeewww! Actually, I read the archives about a week ago when this first popped up, and didn't find the answer. So, for the moment, I made XFree86 setuid-root and started it by hand, and then started the window manager and the panel. But since I'm demonstrating this system to two vice-presidents of HP in the near future, and I'm writing an article for ZDNet on why Free Software is so cool today, you folks could be nice and save me some searching. The selection has moved from /etc/X11/Xserver to /etc/X11/Xwrapper.config Edit that file, and all will be well. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [kteague@sprocket.ddts.net: xserver-xsun drivers]
On Tue, Dec 12, 2000 at 09:02:07AM -0500, Clint Adams wrote: www.xfree86.org doesn't seem to say anything at all about Sun drivers. On a vaguely related note, is there a way other than gpm to get sunmouse support under X4? Other way? It's rather simple. Setup gpm to repeat as msc and set X up to use type MouseSystems on device /etc/gpmdata. Works perfectly for me. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: [bruce@perens.com: user not authorized to run the X server]
On Tue, Dec 12, 2000 at 11:45:10AM -0800, Bruce Perens wrote: From: Joshua Shagam [EMAIL PROTECTED] Hey Bruce, are you really such a newbie that you can't read the list archives? ;) Well, you read the archives with a web browser, and my web browser happens to run under the x server that I'm not authorized to run right now. You want me to use LYNX Eeewww! Actually, I read the archives about a week ago when this first popped up, and didn't find the answer. So, for the moment, I made XFree86 setuid-root and started it by hand, and then started the window manager and the panel. But since I'm demonstrating this system to two vice-presidents of HP in the near future, and I'm writing an article for ZDNet on why Free Software is so cool today, you folks could be nice and save me some searching. The selection has moved from /etc/X11/Xserver to /etc/X11/Xwrapper.config Edit that file, and all will be well. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: locale names in glibc and XFree86
On Sun, Dec 10, 2000 at 05:20:00PM +0100, Juliusz Chroboczek wrote: BC It would be nice if Xlibs used the same format file (and even BC better if it could just symlink and use that exact file). Impossible for licencing reasons: we cannot use GPL'd code in XFree86 (and we support a number of systems that don't use glibc). I'm pretty sure I never said "code", I said format. Which simply means it can parse the same file, and in Debian (or other distributions) it means we can make X look at that file from glibc, as opposed to it's own list. This would mean it is always in sync with the system. There are no license conflicts with this approach. -- ---===-=-==-=---==-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: locale names in glibc and XFree86
On Sun, Dec 10, 2000 at 05:20:00PM +0100, Juliusz Chroboczek wrote: BC It would be nice if Xlibs used the same format file (and even BC better if it could just symlink and use that exact file). Impossible for licencing reasons: we cannot use GPL'd code in XFree86 (and we support a number of systems that don't use glibc). I'm pretty sure I never said code, I said format. Which simply means it can parse the same file, and in Debian (or other distributions) it means we can make X look at that file from glibc, as opposed to it's own list. This would mean it is always in sync with the system. There are no license conflicts with this approach. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: locale names in glibc and XFree86
Ben, can you point me to one so I can write up a patch and send it upstream before 4.0.2 is tagged? This is pretty important for people who are choosy about their locales. /etc/locale.alias It would be nice if Xlibs used the same format file (and even better if it could just symlink and use that exact file). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.1 on PowerPC status update #2
On Sat, Dec 09, 2000 at 07:00:13AM -0500, Branden Robinson wrote: However, unfortunately, some things in the XFree86 tree (the Wacom input module, at least) build differently on kernel 2.4 systems than they do on 2.2 systems. More to the point, building xf86Wacom.c flat out fails on 2.4 boxen. Would it solve the problem if you were using 2.4 kernel headers aswell as running a 2.4 kernel? If so, would that same build work on a 2.2 kernel? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: locale names in glibc and XFree86
Ben, can you point me to one so I can write up a patch and send it upstream before 4.0.2 is tagged? This is pretty important for people who are choosy about their locales. /etc/locale.alias It would be nice if Xlibs used the same format file (and even better if it could just symlink and use that exact file). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: xfree86 4.0.1-8 potato debs available
On Mon, Nov 27, 2000 at 03:18:10PM +0100, Charl P. Botha wrote: Branden's woody DEBs now build without modification on potato, so I don't even know if it's necessary to rebuild them anymore... In anycase, I have done so (lotsa cpu time available :) and these are available from: deb http://people.debian.org/%7Ecpbotha/ xf401_potato/i386/ deb http://people.debian.org/%7Ecpbotha/ xf401_potato/all/ So long as woody and potato's libc6 differ (which means forever :) you wont be able to install the woody deb's on potato. So keep up the builds :) Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Xfree86 4.0.1-2 built and uploaded for woody
Well, it's there. The ATI driver does not work. By this I mean if you try to use it, your machine will lock up and you will have to stop-a and reboot. So don't use it. The sunffb (create/elite) driver works for me. I assume the other sun* (tgx, cg*, etc..) servers work aswell. There are some other PCI drivers (r128, permedia, chips), but I have no idea how they are working. Branden, attached are four of the sparc specific files for the build. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' MANIFEST.sparc.bz2 Description: Binary data xserver-xfree86.docs.sparc.bz2 Description: Binary data xserver-xfree86.files.sparc.bz2 Description: Binary data xutils.docs.sparc.bz2 Description: Binary data
Re: SPARC patch set
On Wed, Oct 18, 2000 at 01:33:10AM -0500, Branden Robinson wrote: On Tue, Oct 17, 2000 at 09:57:01PM -0400, Ben Collins wrote: Well, here it is. This should unpack right into the source dir. It includes the sparc specific debhelper files, and the MANIFEST. It also has 4 patches in debian/patches/ 301 - SPARC PCI stuff 302 - minor fix (might be in v18?) 303 - Misc. fixes I found in RedHat's SRPM 204 - The libxrx fixup 302 is unnecessary. 303 is too miscellaneous for my purposes. But first and foremost, 301 doesn't apply very nicely. You can safely ignore 302 and 303... cat debian/stampdir/patches/301_sparc_pci_stuff.diff.log patching file programs/Xserver/hw/xfree86/common/compiler.h Hunk #1 succeeded at 631 with fuzz 1 (offset 155 lines). Hunk #2 succeeded at 1478 with fuzz 2. patching file programs/Xserver/hw/xfree86/common/xf86pciBus.c Hunk #3 succeeded at 1518 with fuzz 1 (offset 40 lines). Hunk #4 FAILED at 1598. 1 out of 4 hunks FAILED -- saving rejects to file programs/Xserver/hw/xfree86/common/xf86pciBus.c.rej patching file programs/Xserver/hw/xfree86/loader/xf86sym.c patching file programs/Xserver/hw/xfree86/os-support/bus/Pci.c Hunk #1 succeeded at 1049 with fuzz 1. Hunk #2 FAILED at 1149. 1 out of 2 hunks FAILED -- saving rejects to file programs/Xserver/hw/xfree86/os-support/bus/Pci.c.rej patching file programs/Xserver/hw/xfree86/os-support/bus/sparcPci.c patching file programs/Xserver/hw/xfree86/os-support/bus/xf86Pci.h patching file programs/Xserver/hw/xfree86/os-support/linux/lnxResource.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 4 out of 4 hunks ignored -- saving rejects to file programs/Xserver/hw/xfree86/os-support/linux/lnxResource.c.rej patching file programs/Xserver/hw/xfree86/os-support/linux/lnx_pci.c Hunk #1 FAILED at 28. 1 out of 1 hunk FAILED -- saving rejects to file programs/Xserver/hw/xfree86/os-support/linux/lnx_pci.c.rej patching file programs/Xserver/hw/xfree86/os-support/bus/Pci.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file programs/Xserver/hw/xfree86/os-support/bus/Pci.h.rej Hmm...I see some of Marc's(?) work was applied in CVS. Problem is, I'm not sure how this is going to affect the non-ati part of the stuff :/ More than likely, 303 can be left out with this, but I need to test if it actually works for SBUS. If it does, we are in the clear. If it doesn't, then I need to make a patch that backs out his stuff and applies my patch instead. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SPARC patch set
On Wed, Oct 18, 2000 at 01:33:10AM -0500, Branden Robinson wrote: On Tue, Oct 17, 2000 at 09:57:01PM -0400, Ben Collins wrote: Well, here it is. This should unpack right into the source dir. It includes the sparc specific debhelper files, and the MANIFEST. It also has 4 patches in debian/patches/ 301 - SPARC PCI stuff 302 - minor fix (might be in v18?) 303 - Misc. fixes I found in RedHat's SRPM 204 - The libxrx fixup 302 is unnecessary. 303 is too miscellaneous for my purposes. But first and foremost, 301 doesn't apply very nicely. You can safely ignore 302 and 303... cat debian/stampdir/patches/301_sparc_pci_stuff.diff.log patching file programs/Xserver/hw/xfree86/common/compiler.h Hunk #1 succeeded at 631 with fuzz 1 (offset 155 lines). Hunk #2 succeeded at 1478 with fuzz 2. patching file programs/Xserver/hw/xfree86/common/xf86pciBus.c Hunk #3 succeeded at 1518 with fuzz 1 (offset 40 lines). Hunk #4 FAILED at 1598. 1 out of 4 hunks FAILED -- saving rejects to file programs/Xserver/hw/xfree86/common/xf86pciBus.c.rej patching file programs/Xserver/hw/xfree86/loader/xf86sym.c patching file programs/Xserver/hw/xfree86/os-support/bus/Pci.c Hunk #1 succeeded at 1049 with fuzz 1. Hunk #2 FAILED at 1149. 1 out of 2 hunks FAILED -- saving rejects to file programs/Xserver/hw/xfree86/os-support/bus/Pci.c.rej patching file programs/Xserver/hw/xfree86/os-support/bus/sparcPci.c patching file programs/Xserver/hw/xfree86/os-support/bus/xf86Pci.h patching file programs/Xserver/hw/xfree86/os-support/linux/lnxResource.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 4 out of 4 hunks ignored -- saving rejects to file programs/Xserver/hw/xfree86/os-support/linux/lnxResource.c.rej patching file programs/Xserver/hw/xfree86/os-support/linux/lnx_pci.c Hunk #1 FAILED at 28. 1 out of 1 hunk FAILED -- saving rejects to file programs/Xserver/hw/xfree86/os-support/linux/lnx_pci.c.rej patching file programs/Xserver/hw/xfree86/os-support/bus/Pci.h Hunk #1 FAILED at 139. 1 out of 1 hunk FAILED -- saving rejects to file programs/Xserver/hw/xfree86/os-support/bus/Pci.h.rej Hmm...I see some of Marc's(?) work was applied in CVS. Problem is, I'm not sure how this is going to affect the non-ati part of the stuff :/ More than likely, 303 can be left out with this, but I need to test if it actually works for SBUS. If it does, we are in the clear. If it doesn't, then I need to make a patch that backs out his stuff and applies my patch instead. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
SPARC patch set
Well, here it is. This should unpack right into the source dir. It includes the sparc specific debhelper files, and the MANIFEST. It also has 4 patches in debian/patches/ 301 - SPARC PCI stuff 302 - minor fix (might be in v18?) 303 - Misc. fixes I found in RedHat's SRPM 204 - The libxrx fixup Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' xfree86-4.0.1-p2v17-sparc.tar.gz Description: Binary data
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: Hello, I cannot link any more against libX11.so: /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' this shows, even if I link a minimal c program. my versions: ii xlib6g 3.3.6-11 ii libc6 2.1.94-3 Any comments ? To compile against a library built under an old glibc, the library needs to be recompiled to the new libc. If this is true then there isn't any binary compatibility. The whole point of the symbols looking like the above is so that there can be multiple versions of them. Eg. Binary compatibility means you con run programs linked against older libraries. Guess what, X and the libX11 linked apps still work don't they? % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown 000913c8 T __chown@@GLIBC_2.1 000913c8 T chown@@GLIBC_2.1 00091454 T [EMAIL PROTECTED] % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 0004da48 T [EMAIL PROTECTED] 000481e0 T _IO_fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] 000481e0 T fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] So either something bad has happened with the glibc versioning upstream or glibc was built badly. No, this is inherent in versioned symbols. The old symbol is now "weak", which means it is there for using by old programs, but cannot be used when linking. A weak symbol keeps compatibility, which allowing the new strong symbol to be used for newly compiled applications. I think there's already a forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - right, Branden? If it's woody, then it's probably an upstream problem but X 3.3.6 _should not_ be upgraded (well not to fix this anyway, obviously there may be other reasons to upgrade). Yes it should, just to fix this. Versioned symbols and their solution for binary compatibility, ensured that everything will still run as it did before. It does not mean that things wont have to be rebuilt to allow linking. -- ---===-=-==-=---==-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dexter and devfs
On Mon, Oct 16, 2000 at 02:41:00AM -0500, Derek J Witt wrote: I also found this to work as well: === #!/bin/sh DEVFS=`grep devfs /proc/filesystems | cut -f2` [ $DEVFS = devfs ] echo You're using devfs. :-) Needs to be more complex: #!/bin/sh # They may have more than one mounted, but always use the first DEVFS=$(egrep ' devfs ' /proc/mounts | head -1 | cut -f2) # No, devfsd does not have to be running for this to work. The file exists # for devfsd's usage, and is the same test that devfsd uses to make sure # it is operating on a devfs mount (did I say devfs enough?). if [ $DEVFS != ] [ -f $DEVFS/.devfsd ]; then # we have devfs mounted, use it fi # ---end--- This makes sure they have it, and it is mounted. Note, if they have devfsd actually running, then they should be able to use the old devices, but that isn't guaranteed. Good thing about devfs, if the device exists, that driver is installed and working. So things like this are then possible: [ -f $DEVFS/misc/sunmouse ] ... # add sunmouse as an option [ -f $DEVFS/misc/psaux ] ... # add the ps/2 options Also, if only one option is present then you can either use it blindly, or be nice enough to ask the user about it or an other entry. Branden, let me take this time to point out that sunmouse means either BusMouse or PS/2 (I'm adding a patch so we can actually say SunMouse or Sun, but it all points to BusMouse, just like in 3.3.6). PS/2 is just like the one on your Ultra. BTW, did you get the ati driver working? :) Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libX11 is borked (or is it glibc ?)
On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote: Hello, I cannot link any more against libX11.so: /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0' this shows, even if I link a minimal c program. my versions: ii xlib6g 3.3.6-11 ii libc6 2.1.94-3 Any comments ? To compile against a library built under an old glibc, the library needs to be recompiled to the new libc. If this is true then there isn't any binary compatibility. The whole point of the symbols looking like the above is so that there can be multiple versions of them. Eg. Binary compatibility means you con run programs linked against older libraries. Guess what, X and the libX11 linked apps still work don't they? % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown 000913c8 T __chown@@GLIBC_2.1 000913c8 T chown@@GLIBC_2.1 00091454 T [EMAIL PROTECTED] % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen 0004b5c4 T _IO_file_fopen@@GLIBC_2.1 0004da48 T [EMAIL PROTECTED] 000481e0 T _IO_fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] 000481e0 T fopen@@GLIBC_2.1 0004a9a0 T [EMAIL PROTECTED] So either something bad has happened with the glibc versioning upstream or glibc was built badly. No, this is inherent in versioned symbols. The old symbol is now weak, which means it is there for using by old programs, but cannot be used when linking. A weak symbol keeps compatibility, which allowing the new strong symbol to be used for newly compiled applications. I think there's already a forthcoming X 3.3.6 upgrade which will be rebuilt against woody glibc - right, Branden? If it's woody, then it's probably an upstream problem but X 3.3.6 _should not_ be upgraded (well not to fix this anyway, obviously there may be other reasons to upgrade). Yes it should, just to fix this. Versioned symbols and their solution for binary compatibility, ensured that everything will still run as it did before. It does not mean that things wont have to be rebuilt to allow linking. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Xfree86 4.0.1-phase2v17 debs available for SPARC/UltraSPARC
I've finally got these compiled for Sparc. I haven't sent my patches to Branden yet, but will soon. This is in the middle of uploading. Check the .changes to make sure everything is there that you need. Yes, I built the _all.deb packages too, but that's just to avoid version mismatches with branden's stuff until I can get the patches to him, so he can put that ultrasparc to use and start doing builds himself :) A few caveats: * The ATI (Mach64) driver does not work. It wont crash your machine, but it wont properly detect your card either, so it just wont work. * The fbdev driver also does not work The SBUS drivers seem to work. I am running an Ultra30 dual head with a Creator 3D and an ELite 3D card installed. Works perfectly. When you setup your mouse, either use /dev/gpmdata (if you use gpm), or use /dev/sunmouse. No longer are SBUS cards held down by the obsolete Xsun servers and using the event driven proprietary mouse protocol. We now use XF86Config just like everyone else, with full integration! DRI appears to be working with the sunffb (Creator/Elite driver), if you have compiled DRI support for it under a recent 2.4.0test kernel (I'm using test9 from vger CVS). Quake-GL doesn't look right using glx though (lots of red), but I'm not a GLX expert. As for the keyboard. It sets up to use type5, edit /etc/X11/XF86Config-4 if you need a type# different than that, or a ps/2 (pc104) keyboard. A few warnings before I give out the URL: 1) DO NOT send bug reports directly to me or Branden (the Debian X maintainer). If you are lucky, it will simply get forwarded to a list. If you catch one of us on a bad day... To put it simply, most questions are in Branden's FAQ, or can be answered by ppl on the list who aren't as busy. 2) If you have SPARC specific questions, email to debian-sparc (or atleast Cc to it, and email debian-x, which I prefer). Not all sparc folks are on debian-x, so you might get some useless i386-centric reply if you don't follow this warning. 3) DO NOT email the debian-sparc list about X-only related questions (why does my program not compile against XF4?) 4) The dexter script (X setup) with these deb's is modified slightly from Branden's so it would list sunmouse and the Sun video driver modules. Do not email Branden if this is broken. Just chalk it up to bad luck/coding on my part, and try to fix things by hand. This is very beta packaging (which is why it isn't in woody). Now that you have read the warnings and caveats, you can scroll way down and get the URL. No this is not an apt'able setup. Figure out the dep's and stuff by hand, make good use of dpkg --force-depends to remove old packages so these can be installed, etc...(don't blame me. if this scares you, then don't use the packages, or setup an apt thingie of your own). Most importantly, if you screw up your system because you didn't know what you were doing, don't blame me :) Please let me know of success/failures concerning tgx/leo/cg3/cg6/cg14/bw2 drivers. http://auric.debian.org/~bcollins/xfree86-4/ -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How do you want non-i386 handled in dexter? (+ mouse types)
On Sat, Oct 14, 2000 at 02:23:49PM -0600, Joshua Shagam wrote: On Sat, Oct 14, 2000 at 09:03:20AM -0400, Ben Collins wrote: Obviously the server list in dexter needs to be different on non-i386, aswell as the generated keyboard lines (on sun there are two default possibilies, i386 and type5). How do you forsee this happening? There isn't a clean way right now, expect for outputting a complete list of servers for each arch (lots of duplication). I don't think it can be handled cleanly in shell, so will you change to perl (the var/string handling in shell loses in this case). Why not have dexter generate the list at runtime based on the files in /usr/X11R6/lib/modules/drivers? Sounds even better to me. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How do you want non-i386 handled in dexter? (+ mouse types)
Obviously the server list in dexter needs to be different on non-i386, aswell as the generated keyboard lines (on sun there are two default possibilies, i386 and type5). How do you forsee this happening? There isn't a clean way right now, expect for outputting a complete list of servers for each arch (lots of duplication). I don't think it can be handled cleanly in shell, so will you change to perl (the var/string handling in shell loses in this case). Also, sunmouse is an option. Problem is, xf4 currently has no idea what Sun type is. On top of that, I tried a ppc build, and it has no idea what a USB mouse is. Known problem? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: How do you want non-i386 handled in dexter? (+ mouse types)
On Sat, Oct 14, 2000 at 02:23:49PM -0600, Joshua Shagam wrote: On Sat, Oct 14, 2000 at 09:03:20AM -0400, Ben Collins wrote: Obviously the server list in dexter needs to be different on non-i386, aswell as the generated keyboard lines (on sun there are two default possibilies, i386 and type5). How do you forsee this happening? There isn't a clean way right now, expect for outputting a complete list of servers for each arch (lots of duplication). I don't think it can be handled cleanly in shell, so will you change to perl (the var/string handling in shell loses in this case). Why not have dexter generate the list at runtime based on the files in /usr/X11R6/lib/modules/drivers? Sounds even better to me. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: xserver-common should depend on dialog?
On Fri, Oct 13, 2000 at 02:21:28PM -0400, Adam McKenna wrote: Setting up xserver-xfree86 (4.0.1-0phase2v15) ... dexter: unknown X server (/usr/bin/dexter: dialog: command not found) detected! dpkg: error processing xserver-xfree86 (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: xserver-xfree86 E: Sub-process /usr/bin/dpkg returned an error code (1) IIRC, v16 fixes this. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xserver-common should depend on dialog?
On Fri, Oct 13, 2000 at 02:21:28PM -0400, Adam McKenna wrote: Setting up xserver-xfree86 (4.0.1-0phase2v15) ... dexter: unknown X server (/usr/bin/dexter: dialog: command not found) detected! dpkg: error processing xserver-xfree86 (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: xserver-xfree86 E: Sub-process /usr/bin/dpkg returned an error code (1) IIRC, v16 fixes this. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
xserver-xfree86.files.sparc
Generated, and attached. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' etc/X11/app-defaults/XF86Cfg usr/X11R6/bin/XFree86 usr/X11R6/bin/xf86cfg usr/X11R6/bin/xf86config usr/X11R6/lib/X11/Cards usr/X11R6/lib/X11/XF86Config.98 usr/X11R6/lib/X11/XF86Config.eg usr/X11R6/lib/modules/codeconv/libARABIC.a usr/X11R6/lib/modules/codeconv/libARMSCII8.a usr/X11R6/lib/modules/codeconv/libBIG5.a usr/X11R6/lib/modules/codeconv/libDOSENCODING.a usr/X11R6/lib/modules/codeconv/libGB2312.a usr/X11R6/lib/modules/codeconv/libGEORGIAN.a usr/X11R6/lib/modules/codeconv/libISO8859_1.a usr/X11R6/lib/modules/codeconv/libISO8859_10.a usr/X11R6/lib/modules/codeconv/libISO8859_11.a usr/X11R6/lib/modules/codeconv/libISO8859_14.a usr/X11R6/lib/modules/codeconv/libISO8859_15.a usr/X11R6/lib/modules/codeconv/libISO8859_2.a usr/X11R6/lib/modules/codeconv/libISO8859_3.a usr/X11R6/lib/modules/codeconv/libISO8859_4.a usr/X11R6/lib/modules/codeconv/libISO8859_5.a usr/X11R6/lib/modules/codeconv/libISO8859_6.a usr/X11R6/lib/modules/codeconv/libISO8859_7.a usr/X11R6/lib/modules/codeconv/libISO8859_8.a usr/X11R6/lib/modules/codeconv/libISO8859_9.a usr/X11R6/lib/modules/codeconv/libJISX0201.a usr/X11R6/lib/modules/codeconv/libJISX0208.a usr/X11R6/lib/modules/codeconv/libJISX0212.a usr/X11R6/lib/modules/codeconv/libKOI8.a usr/X11R6/lib/modules/codeconv/libKSC5601.a usr/X11R6/lib/modules/codeconv/libKSCJOHAB.a usr/X11R6/lib/modules/codeconv/libMULEENCODING.a usr/X11R6/lib/modules/codeconv/libTCVN.a usr/X11R6/lib/modules/codeconv/libVISCII.a usr/X11R6/lib/modules/dri/ffb_dri.so usr/X11R6/lib/modules/drivers/ati_drv.o usr/X11R6/lib/modules/drivers/fbdev_drv.o usr/X11R6/lib/modules/drivers/glint_drv.o usr/X11R6/lib/modules/drivers/linux/v4l_drv.o usr/X11R6/lib/modules/drivers/sunbw2_drv.o usr/X11R6/lib/modules/drivers/suncg14_drv.o usr/X11R6/lib/modules/drivers/suncg3_drv.o usr/X11R6/lib/modules/drivers/suncg6_drv.o usr/X11R6/lib/modules/drivers/sunffb_drv.o usr/X11R6/lib/modules/drivers/sunleo_drv.o usr/X11R6/lib/modules/drivers/sunleo_drv.o usr/X11R6/lib/modules/drivers/suntcx_drv.o usr/X11R6/lib/modules/extensions/libGLcore.a usr/X11R6/lib/modules/extensions/libdbe.a usr/X11R6/lib/modules/extensions/libdri.a usr/X11R6/lib/modules/extensions/libextmod.a usr/X11R6/lib/modules/extensions/libglx.a usr/X11R6/lib/modules/extensions/libpex5.a usr/X11R6/lib/modules/extensions/librecord.a usr/X11R6/lib/modules/extensions/libxie.a usr/X11R6/lib/modules/fonts/libbitmap.a usr/X11R6/lib/modules/fonts/libfreetype.a usr/X11R6/lib/modules/fonts/libspeedo.a usr/X11R6/lib/modules/fonts/libtype1.a usr/X11R6/lib/modules/fonts/libxtt.a usr/X11R6/lib/modules/input/dynapro_drv.o usr/X11R6/lib/modules/input/elo2300_drv.o usr/X11R6/lib/modules/input/elographics_drv.o usr/X11R6/lib/modules/input/magellan_drv.o usr/X11R6/lib/modules/input/microtouch_drv.o usr/X11R6/lib/modules/input/mouse_drv.o usr/X11R6/lib/modules/input/mutouch_drv.o usr/X11R6/lib/modules/input/spaceorb_drv.o usr/X11R6/lib/modules/input/void_drv.o usr/X11R6/lib/modules/input/wacom_drv.o usr/X11R6/lib/modules/libcfb.a usr/X11R6/lib/modules/libcfb16.a usr/X11R6/lib/modules/libcfb24.a usr/X11R6/lib/modules/libcfb32.a usr/X11R6/lib/modules/libddc.a usr/X11R6/lib/modules/libfb.a usr/X11R6/lib/modules/libi2c.a usr/X11R6/lib/modules/libint10.a usr/X11R6/lib/modules/libmfb.a usr/X11R6/lib/modules/libpcidata.a usr/X11R6/lib/modules/librac.a usr/X11R6/lib/modules/libramdac.a usr/X11R6/lib/modules/libscanpci.a usr/X11R6/lib/modules/libshadow.a usr/X11R6/lib/modules/libshadowfb.a usr/X11R6/lib/modules/libvbe.a usr/X11R6/lib/modules/libxaa.a usr/X11R6/lib/modules/libxf1bpp.a usr/X11R6/lib/modules/libxf24_32bpp.a usr/X11R6/lib/modules/libxf4bpp.a usr/X11R6/lib/modules/libxf8_16bpp.a usr/X11R6/lib/modules/libxf8_32bpp.a usr/X11R6/lib/modules/libxf8_32wid.a usr/X11R6/lib/modules/linux/libdrm.a usr/X11R6/lib/modules/linux/libfbdevhw.a usr/X11R6/man/man1/XFree86.1x usr/X11R6/man/man1/xf86cfg.1x usr/X11R6/man/man1/xf86config.1x usr/X11R6/man/man4/ati.4 usr/X11R6/man/man4/dynapro.4 usr/X11R6/man/man4/elographics.4 usr/X11R6/man/man4/fbdev.4 usr/X11R6/man/man4/fbdevhw.4 usr/X11R6/man/man4/glint.4 usr/X11R6/man/man4/keyboard.4 usr/X11R6/man/man4/microtouch.4 usr/X11R6/man/man4/mouse.4 usr/X11R6/man/man4/mutouch.4 usr/X11R6/man/man4/sunbw2.4 usr/X11R6/man/man4/suncg14.4 usr/X11R6/man/man4/suncg3.4 usr/X11R6/man/man4/suncg6.4 usr/X11R6/man/man4/sunffb.4 usr/X11R6/man/man4/sunleo.4 usr/X11R6/man/man4/suntcx.4 usr/X11R6/man/man4/v4l.4 usr/X11R6/man/man4/void.4 usr/X11R6/man/man4/wacom.4 usr/X11R6/man/man5/XF86Config.5x
More sparc xf4 files...
Noticed some more files that are needed... -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' debian/tmp/usr/X11R6/lib/X11/doc/DESIGN debian/tmp/usr/X11R6/lib/X11/doc/README.DGA debian/tmp/usr/X11R6/lib/X11/doc/README.DRI debian/tmp/usr/X11R6/lib/X11/doc/README.DRIcomp debian/tmp/usr/X11R6/lib/X11/doc/README.ati debian/tmp/usr/X11R6/lib/X11/doc/README.mouse debian/tmp/usr/X11R6/lib/X11/doc/Status debian/tmp/usr/X11R6/lib/X11/doc/html/XF86Config.5.html debian/tmp/usr/X11R6/lib/X11/doc/html/XFree86.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/apm.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/ati.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/chips.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/cirrus.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/cyrix.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/dynapro.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/elographics.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/fbdev.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/fbdevhw.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/glide.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/glint.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/i740.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/imstt.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/keyboard.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/mga.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/microtouch.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/mouse.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/mutouch.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/neomagic.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/nv.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/r128.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/rendition.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/s3virge.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/sis.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/tdfx.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/trident.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/tseng.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/v4l.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/vga.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/void.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/wacom.4.html debian/tmp/usr/X11R6/lib/X11/doc/html/xf86cfg.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/xf86config.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/atobm.1x.html debian/tmp/usr/X11R6/lib/X11/doc/html/fsinfo.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/fslsfonts.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/imake.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/lndir.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/makedepend.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/makeg.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/makepsres.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/makestrs.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/mkcfm.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/mkdirhier.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/pcitweak.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/pswrap.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/resize.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/revpath.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/rstart.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/rstartd.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/scanpci.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/sessreg.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/showfont.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/showrgb.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/xmkmf.1.html debian/tmp/usr/X11R6/lib/X11/doc/html/xon.1.html etc/X11/rstart/commands/@List etc/X11/rstart/commands/ListContexts etc/X11/rstart/commands/ListGenericCommands etc/X11/rstart/commands/x11r6/@List etc/X11/rstart/commands/x11r6/LoadMonitor etc/X11/rstart/commands/x11r6/Terminal etc/X11/rstart/config etc/X11/rstart/contexts/@List etc/X11/rstart/contexts/default etc/X11/rstart/contexts/x11r6 etc/X11/rstart/rstartd.real usr/X11R6/bin/atobm usr/X11R6/bin/fsinfo usr/X11R6/bin/fslsfonts usr/X11R6/bin/gccmakedep usr/X11R6/bin/imake usr/X11R6/bin/lndir usr/X11R6/bin/makedepend usr/X11R6/bin/makeg usr/X11R6/bin/makepsres usr/X11R6/bin/makestrs usr/X11R6/bin/mergelib usr/X11R6/bin/mkcfm usr/X11R6/bin/mkdirhier usr/X11R6/bin/mkhtmlindex usr/X11R6/bin/pcitweak usr/X11R6/bin/pswrap usr/X11R6/bin/resize usr/X11R6/bin/revpath usr/X11R6/bin/rstart usr/X11R6/bin/rstartd usr/X11R6/bin/scanpci usr/X11R6/bin/sessreg usr/X11R6/bin/showfont usr/X11R6/bin/showrgb usr/X11R6/bin/xmkmf usr/X11R6/bin/xon usr/X11R6/man/man1/atobm.1x usr/X11R6/man/man1/fsinfo.1x usr/X11R6/man/man1/fslsfonts.1x usr/X11R6/man/man1/imake.1x usr/X11R6/man/man1/lndir.1x usr/X11R6/man/man1/makedepend.1x usr/X11R6/man/man1/makeg.1x usr/X11R6/man/man1/makepsres.1x usr/X11R6/man/man1/makestrs.1x usr/X11R6/man/man1/mkcfm.1x usr/X11R6/man/man1/mkdirhier.1x usr/X11R6/man/man1/pcitweak.1x usr/X11R6/man/man1
new MANIFEST.sparc
This includes the libxrx files (which are now built using the patch I sent yesterday). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' MANIFEST.sparc.bz2 Description: Binary data
Re: Note about sparc...
On Tue, Oct 10, 2000 at 07:02:30PM -0400, Daniel Jacobowitz wrote: On Tue, Oct 10, 2000 at 06:14:11PM -0400, Ben Collins wrote: (Branden, let me know if you want me to just email debian-x) There is no libxrx compiled for sparc. I'm not even sure what this thing does, but it isn't there. So something needs to be done to make it installed only on a per-case basis. Seems like the best way is to put the files on the command line of the dh_* calls. I could swear I fixed this for all arches, not just powerpc... Branden? What ever happened to patch #204? It included this hunk: Whatever it was, it didn't apply cleanly it seems. I've attached a new one. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' --- xc/config/cf/linux.cf~ Tue Oct 10 21:47:10 2000 +++ xc/config/cf/linux.cf Tue Oct 10 21:59:23 2000 @@ -436,15 +436,16 @@ # define XF86OSCardDrivers v4l #endif +#if UseElfFormat +# define HasPlugin YES +# define VendorHasX11R6_3libXext YES /* XC or XFree86 = 3.3.1 */ +#endif + #ifdef i386Architecture # define OptimizedCDebugFlags DefaultGcc2i386Opt # define LinuxMachineDefines -D__i386__ # define ServerOSDefines XFree86ServerOSDefines -DDDXTIME -DPART_NET # define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines -# if UseElfFormat -# define HasPluginYES -# define VendorHasX11R6_3libXext YES /* XC or XFree86 = 3.3.1 */ -# endif #endif /* i386Architecture */ #ifdef s390Architecture @@ -474,10 +475,6 @@ # define LinuxMachineDefines -D__ia64__ # define ServerOSDefines XFree86ServerOSDefines -DDDXTIME -DPART_NET # define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines -D_XSERVER64 -#if UseElfFormat -# define HasPlugin YES -# define VendorHasX11R6_3libXext YES /* XC or XFree86 = 3.3.1 */ -#endif #endif /* ia64Architecture */ #ifdef Mc68020Architecture
Note about sparc...
(Branden, let me know if you want me to just email debian-x) There is no libxrx compiled for sparc. I'm not even sure what this thing does, but it isn't there. So something needs to be done to make it installed only on a per-case basis. Seems like the best way is to put the files on the command line of the dh_* calls. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: xlib6g and xlib6g-dev
On Fri, Sep 29, 2000 at 08:50:49AM -0500, Branden Robinson wrote: On Fri, Sep 29, 2000 at 08:04:28AM -0500, Eythan Weg wrote: I wonder whether the xlib6g libraries version 3.3.6-11 work with the new libdb2 and libc6 libraries. I currently use version 3.3.6-10 and have encountered problems with ghostscript stemming from the reference to undefined getpwnam_r@@GLIBC_2.0 by libXt. Ben Collins (new glibc and libdb2 maintainer) told me they would. Correction, I did not take over libdb2 :) -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: libdb.so.3 blues [was: package bug in xfree86-common (4.0.1-0phase2v10)]
On Tue, Sep 26, 2000 at 11:59:16PM -0500, Branden Robinson wrote: On Tue, Sep 26, 2000 at 05:34:31PM -0700, Simon deWeerdt wrote: Have a dependancy problem I can't satisfy. [...] Setting up xfree86-common (4.0.1-0phase2v10) ... perl: error while loading shared libraries: libdb.so.3: cannot open shared object file: No such file or directory [...] I can't find a deb for libdb3.0 in unstable If there is one in a maintainers directory I'll apt-get it. You've just seen the first in what will probably be a long line of bloody corpses generated by Ben Collins's glibc 2.1.94 upload. I am probably going to downgrade my build box to glibc 2.1.3-10 and stick with that. Progeny is about to enter freeze for our release and I'd like to delay a fork between Debian's X packages and Progeny's for as long as possible. You know, if you force X to use libdb2, it will work with 2.1.3 and 2.1.94. The easy (not sure how easy in terms of the X build) is to replace db.h with db2/db.h and -ldb with -ldb2. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Some patches for 4.0.1 from RedHat .src.rpm
Here's 6 patches. 4 are needed for sparc/sparc64 (ignore the ia64 in some, they still have sparc specific things in them), and 2 are security related. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' xfree86-patches.tar.bz2 Description: Binary data
Some patches for 4.0.1 from RedHat .src.rpm
Here's 6 patches. 4 are needed for sparc/sparc64 (ignore the ia64 in some, they still have sparc specific things in them), and 2 are security related. Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' xfree86-patches.tar.bz2
[dunham@cse.msu.edu: Re: XFree86, Debian, and patches]
Branden, hopefully this will fix our crashes with the Xsun* servers...
- Forwarded message from Steve Dunham [EMAIL PROTECTED] -
X-From_: [EMAIL PROTECTED] Wed Oct 13 09:31:24 1999
Delivered-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: XFree86, Debian, and patches
From: Steve Dunham [EMAIL PROTECTED]
Date: 13 Oct 1999 09:30:48 -0400
In-Reply-To: Branden Robinson's message of Sat, 9 Oct 1999 00:30:29 -0400
X-Mailer: Gnus v5.5/XEmacs 20.4 - Emerald
Branden Robinson [EMAIL PROTECTED] writes:
I have a whole *bunch* of patches to submit, and I fear some people might
get upset with me if I just spam the patches list with them.
For the Debian packages of 3.3.5 I finally completed the task of breaking
the monolithic .diff I inherited when I took over the package into chunks
that are more or less divided up by their function. Some of the
Alpha, SPARC, and 64-bit stuff is still a bit intermixed, though.
Here is a sparc patch to bring us in sync with RedHat's 3.3.5 package.
Attached below. I skimmed diffs from other parts of the tree and
didn't see anything else that looked significant.
Patch is not tested, but it is just a diff between Red Hat's tree and
our (3.3.5-1 tree). (I start a job in CA on Nov. 1, so I probably
can't find time to test.)
diff -bruN
xfree86-1-3.3.5/build-tree/xc/programs/Xserver/hw//sun/FFB/FFBfrect.c
rh/xc/programs/Xserver/hw/sun/FFB/FFBfrect.c
--- xfree86-1-3.3.5/build-tree/xc/programs/Xserver/hw//sun/FFB/FFBfrect.c
Sat Oct 2 15:28:22 1999
+++ rh/xc/programs/Xserver/hw/sun/FFB/FFBfrect.cSun Oct 3 21:42:54 1999
@@ -273,7 +273,6 @@
/* See if the aligned area is large enough for
* page fill to be worthwhile.
*/
- FFB_WRITE_DRAWOP(ffbPriv, ffb, FFB_DRAWOP_FASTFILL);
if(extra_work 0 ||
BOX_AREA(paligned_w, paligned_h)
ffp-pagefill_small_area) {
do_fastfill:
@@ -369,7 +368,7 @@
CreatorStipplePtr stipple,
unsigned int ppc, unsigned int ppc_mask)
{
- ppc |= FFB_PPC_APE_ENABLE | FFB_PPC_TBE_OPAQUE;
+ ppc |= FFB_PPC_APE_ENABLE | FFB_PPC_TBE_TRANSPARENT;
ppc_mask |= FFB_PPC_APE_MASK | FFB_PPC_TBE_MASK;
FFB_WRITE_PPC(ffbPriv, ffb, ppc, ppc_mask);
FFB_WRITE_ROP(ffbPriv, ffb, (FFB_ROP_EDIT_BIT|stipple-alu));
diff -bruN
xfree86-1-3.3.5/build-tree/xc/programs/Xserver/hw//sun/FFB/FFBsspans.c
rh/xc/programs/Xserver/hw/sun/FFB/FFBsspans.c
--- xfree86-1-3.3.5/build-tree/xc/programs/Xserver/hw//sun/FFB/FFBsspans.c
Sat Oct 2 15:28:22 1999
+++ rh/xc/programs/Xserver/hw/sun/FFB/FFBsspans.c Sun Oct 3 21:42:54 1999
@@ -80,28 +80,7 @@
return;
/* Get SFB ready. */
- {
- unsigned int ppc = FFB_PPC_FW_DISABLE | FFB_PPC_VCE_DISABLE |
FFB_PPC_APE_DISABLE | FFB_PPC_CS_VAR;
- unsigned int ppc_mask = FFB_PPC_FW_MASK | FFB_PPC_VCE_MASK |
FFB_PPC_APE_MASK | FFB_PPC_CS_MASK;
- unsigned int rop = FFB_ROP_EDIT_BIT | pGC-alu;
-
- if((ffbPriv-ppc_cache ppc_mask) != ppc ||
- ffbPriv-fbc_cache != FFB_FBC_DEFAULT ||
- ffbPriv-rop_cache != rop ||
- ffbPriv-pmask_cache != pGC-planemask) {
- ffbPriv-ppc_cache = ~ppc_mask;
- ffbPriv-ppc_cache |= ppc;
- ffbPriv-fbc_cache = FFB_FBC_DEFAULT;
- ffbPriv-rop_cache = rop;
- ffbPriv-pmask_cache = pGC-planemask;
- ffbPriv-rp_active = 1;
- FFBFifo(ffbPriv, 4);
- ffb-ppc = ppc;
- ffb-fbc = FFB_FBC_DEFAULT;
- ffb-rop = rop;
- ffb-pmask = pGC-planemask;
- }
- }
+ FFB_WRITE_ATTRIBUTES_SFB_VAR(ffbPriv, pGC-planemask, pGC-alu);
FFBWait(ffbPriv, ffb);
addrp = (char *) ffbPriv-fb;
diff -bruN
xfree86-1-3.3.5/build-tree/xc/programs/Xserver/hw//sun/FFB/FFBzeroarc.c
rh/xc/programs/Xserver/hw/sun/FFB/FFBzeroarc.c
--- xfree86-1-3.3.5/build-tree/xc/programs/Xserver/hw//sun/FFB/FFBzeroarc.c
Sat Oct 2 15:28:22 1999
+++ rh/xc/programs/Xserver/hw/sun/FFB/FFBzeroarc.c Sun Oct 3 21:42:54 1999
@@ -62,22 +62,22 @@
} DashInfo;
#define Pixelate(xval,yval,ext)\
-if ((xval) = (ext)-x1 \
-(xval) (ext)-x2 \
-(yval) = (ext)-y1 \
-(yval) (ext)-y2) { \
+if (((xval)+xoff) = (ext)-x1 \
+((xval)+xoff) (ext)-x2\
+((yval)+yoff) = (ext)-y1 \
+((yval)+yoff) (ext)-y2) {
Re: xfree86-1_3.3.4 now compiles on powerpc, mach64 mess fixed, patch included.
On Thu, Sep 23, 1999 at 02:17:43PM +0200, Sven LUTHER wrote: As I said before commenting that out will break sparc, please add #ifdef __sparc__ around the function instead. Huh ??? Ok, but it makes no sense to have regwbe for sparc in mach64im.c, and having regw,regr and regwbe for other archs in regmach64.h. NOt sure if it is the right place, since the functions will be copied over all files that includes regmach64.h, maybe they are not counted, because they are inlined function anyway. Anyway, i made a patch that lets me compile 3.3.5 on ppc, and should be ok for sparc also. Please check it, and if i made a mistake, correct it on the patch, instead of saying it don't compile on sparc and thus should be rejected. I understand that sparc is in stable and powerpc not, but that is not a constructive way of handling things. I never said it needed to be rejected, I just said add #if's around it, which was contructive and solved both problems. You cannot have it in regmach64.h even with the #if's around it for sparc, I tried it and it wont pick it up for some reason. Please just have it to where it stays in mach64im.c with #ifdef __sparc__ around it. Ben
Re: xfree86-1_3.3.4 now compiles on powerpc, mach64 mess fixed, patch included.
On Thu, Sep 23, 1999 at 02:40:34PM +0200, Sven LUTHER wrote: I never said it needed to be rejected, I just said add #if's around it, which was contructive and solved both problems. You cannot have it in regmach64.h even with the #if's around it for sparc, I tried it and it wont pick it up for some reason. Maybe it would be better to solve that problem. regmach64.h is included from mach64.h i think, into mach64im.c. The problem is that regmach64.h should be regmach64.c (as it was orignally coded) but for some reason it has been patched up this way. Atleast this is my take on it. With all the macros and defines across several includes, mac64im.c just wont pick it up for sparc. There is an #ifdef FBDEV around the whole regxxx stuff. Do you build an fbdev server on sparc or a normal one ? There should be no reason it don't works. No, it's a normal server. Also one question is what kind of stuff will be included in the upstream source ? Are you also a xfree member ? The sparc stuff is not from upstream, so I have no idea what they will do upstream and no I'm not and xfree member. Please just have it to where it stays in mach64im.c with #ifdef __sparc__ around it. If we cannot find another solution, i will do that. Thanks.
Re: xfree86-1_3.3.4 now compiles on powerpc, mach64 mess fixed, patch included.
On Thu, Sep 23, 1999 at 02:54:51PM +0200, Sven LUTHER wrote: On Thu, Sep 23, 1999 at 08:46:41AM -0400, Ben Collins wrote: On Thu, Sep 23, 1999 at 02:40:34PM +0200, Sven LUTHER wrote: I never said it needed to be rejected, I just said add #if's around it, which was contructive and solved both problems. You cannot have it in regmach64.h even with the #if's around it for sparc, I tried it and it wont pick it up for some reason. Maybe it would be better to solve that problem. regmach64.h is included from mach64.h i think, into mach64im.c. The problem is that regmach64.h should be regmach64.c (as it was orignally coded) but for some reason it has been patched up this way. Atleast this is my take on it. With all the macros and defines across several includes, mac64im.c just wont pick it up for sparc. There is an #ifdef FBDEV around the whole regxxx stuff. Do you build an fbdev server on sparc or a normal one ? There should be no reason it don't works. No, it's a normal server. Ok, that explains thing, since the regmach64.h stuff has a #ifdef FBDEV server around it. Could you please try the patch i sent to this list ? It should provide a solution for this. It is quite hacky yet, but i would like to know if it works. Basicaly i put a #elif defined (__sparc__) after the #ifdef FBDEV_server which contains a copy of the regwbe function. So it should also get included on the non fbdev sparc built. How about moving that whole function out of the FBDEV_server block and setup it up like: #if defined(FBDEV_server) || defined(__sparc__) . #endif This way it only needs to be listed once. I will write also to the Xfree list to see whåt is the common opinion on this stuff, and see to it that it is handled in a nice way. BTW, did you try the 3.9.x servers on sparc ? Not yet, I have been busy with a few other things. Ben
Re: xfree86-1_3.3.4 now compiles on powerpc, mach64 mess fixed, patch included.
On Wed, Sep 22, 1999 at 03:23:10PM +0200, Sven LUTHER wrote: On Tue, Sep 21, 1999 at 07:53:00PM +0200, Hartmut Koptein wrote: And another mistake in the patch, should have waited a bit more before posting, but since i was going away, i wanted to make things available. Anyway, the build process breaks again læter, didn't have time to check it out though. So the correct patch for the mach64 stuff follows. Could you try the 3.3.5 source that was installed yesterday? It built fine on sparc (which 3.3.4-2 didn't do). No, 3.3.5 is also broken: rm -f mach64im.o gcc -c -O2 -fsigned-char -I../../../../../programs/Xserver/hw/xfree86/common -I. Yes, Noticed that also, I have a patch and are compiling right no will upload everything tomorrow. ( notice that the patch is the part of the patch i posted previously, the one commenting out regwbe in mach64im.c) As I said before commenting that out will break sparc, please add #ifdef __sparc__ around the function instead. Ben
Re: xfree86-1_3.3.4 now compiles on powerpc, mach64 mess fixed, patch included.
On Tue, Sep 21, 1999 at 03:01:43PM +0200, Sven LUTHER wrote: On Thu, Sep 16, 1999 at 02:14:30PM +0200, Sven LUTHER wrote: On Thu, Sep 16, 1999 at 09:24:17AM +0200, Sven LUTHER wrote: Oops a little mistake came up because of the haste, correct patch is attached ... And another mistake in the patch, should have waited a bit more before posting, but since i was going away, i wanted to make things available. Anyway, the build process breaks again læter, didn't have time to check it out though. So the correct patch for the mach64 stuff follows. Could you try the 3.3.5 source that was installed yesterday? It built fine on sparc (which 3.3.4-2 didn't do). Ben
Re: final fixup for 3.3.5-1
On Sun, Sep 19, 1999 at 12:52:03AM -0400, Branden Robinson wrote:
On Thu, Sep 16, 1999 at 09:24:17AM +0200, Sven LUTHER wrote:
--- xc/programs/Xserver/hw/xfree86/accel/mach64/mach64im.c.orig Wed Sep
15 17:01:53 1999
+++ xc/programs/Xserver/hw/xfree86/accel/mach64/mach64im.c Wed Sep 15
17:03:55 1999
@@ -76,11 +76,12 @@
unsigned int integer;
unsigned char bytes[4];
};
-
+/* Also defined in regmach64.h ...
static __inline__ void regwbe(volatile unsigned long regindex, unsigned
long regdata)
{
*(unsigned long *)(mach64MemReg + regindex) = regdata;
}
+*/
static __inline__ unsigned int bit_reverse32(unsigned int bits)
{
I don't see the point of the above, regwbe is declared static anyway.
Get rid of the one in mach64im.c, but make the one in regmach64.h non-static
and also
usable when __sparc__ is defined.
I will apply this one as well.
Can someone tell me the whys and wherefores of inline versus
__inline__? The New Testament is silent on the subject. Is it a GNU
thing?
On SPARC, only __inline__ seems to be understood. I'm assuming the inline
alone
is probably supposed to be defined somewhere to what the compiler needs:
#define inline __inline__
Not sure why it works in some places, but not others.
Ben
Re: xfree86-1_3.3.4 now compiles on powerpc, mach64 mess fixed, patch included.
On Thu, Sep 16, 1999 at 09:24:17AM +0200, Sven LUTHER wrote: --- xc/programs/Xserver/hw/xfree68/mach64/Imakefile.orig Wed Sep 15 18:24:42 1999 +++ xc/programs/Xserver/hw/xfree68/mach64/Imakefile Wed Sep 15 18:25:04 1999 @@ -49,7 +49,7 @@ LinkSourceFile(mach64pntwn.c,../../xfree86/accel/mach64) LinkSourceFile(mach64seg.c,../../xfree86/accel/mach64) LinkSourceFile(mach64text.c,../../xfree86/accel/mach64) -LinkSourceFile(mach64util.c,../../xfree86/accel/mach64) +LinkSourceFile(mach64util.h,../../xfree86/accel/mach64) LinkSourceFile(mach64win.c,../../xfree86/accel/mach64) LinkSourceFile(regmach64.h,../../xfree86/accel/mach64) What happened to the patch in 3.3.4-1 that converted the whole mach64util.h file to mach64util.c? Ben
testing
Overfiend is ma hero
