Re: Patch 031 (was: Re: hurd-i386 updates)
On Mon, Jul 19, 2004 at 04:28:24AM +0200, Robert Millan wrote: > On Wed, Jul 14, 2004 at 12:16:20PM -0500, Branden Robinson wrote: > > > > Hmm, well, how about this? > > > > --- xc/programs/glxinfo/Imakefile~ 2004-07-14 12:03:14.0 -0500 > > +++ xc/programs/glxinfo/Imakefile 2004-07-14 12:12:57.0 -0500 > > @@ -15,6 +15,6 @@ > > > > #endif > > > > - SYS_LIBRARIES = MathLibrary -lstdc++ > > + SYS_LIBRARIES = MathLibrary > > > > -SimpleProgramTarget(glxinfo) > > +SimpleCplusplusProgramTarget(glxinfo) > > > > Seems to build something. Seems to work...but I'm GNU/Linux on PowerPC. > > Seems like it. As long g++ was used, it should be ok. > > I'll test this on GNU/kFreeBSD and commit. *dons part-time Debian GCC & Debian X committer hats together* This looks correct from past work on the NetBSD patches, and using g++ rather than -lstdc++ is *absolutely* the correct solution. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpkhfdRozg9G.pgp Description: PGP signature
Re: hurd-i386 updates
On Wed, Jul 14, 2004 at 11:57:42AM -0500, Branden Robinson wrote: > On Tue, Jul 13, 2004 at 02:47:46PM +0200, Robert Millan wrote: > > Actualy, my k*BSD.cf files only contain kernel stuff. The Glibc-based > > GNU/k*BSD ports use gnu.cf directly (as Glibc systems this works fine). > > > > Now that Michael has overhauled gnu.cf, my idea is to merge the (minor) > > k*BSD > > bits into a conditionalised section in gnu.cf, together with a bunch of > > conditionalised sections copied from linux.cf. This way we can get all > > Glibc-based ports to use the same base configuration. > > > > As for non-Glibc ports, we will have to split the Debian bits out of gnu.cf > > into, say, debian.cf. Then both gnu.cf and NetBSD.cf can use that. > > > > What do you people think? > > I say do what you like, but keep in mind 1) that we no longer really have a > relationship with XFree86 upstream, at least when it comes to Imakefiles > and 2) no one other than XFree86 appears to be interested in retraining > Imake as a build system. > > In other words, my ordinary caution about major overhauls in this part of > the tree is not engaged, but please don't spend time engineering a solution > for the ages, as the rest of the X community seems pretty interested in > making sure Imake doesn't live very much longer. > > (Of course, it often happens that deprecating things doesn't always > actually make them go away...) Agreed in general. Depending on how my work life goes and a few other things, I may not get around to doing serious revamping of the NetBSD branch until we've started to move to a saner build system anyway... but, on the whole, I think that splitting debian.cf from gnu.cf from linux.cf from NetBSD.cf is probably sane (albeit the latter may end up named something else just because it shares *almost* nothing with NetBSD-native configs; the NetBSD kernel stuff just ain't that exciting, and it still has a GNU userland, just not a GNU libc). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpjxqv0je9ew.pgp Description: PGP signature
Re: hurd-i386 updates
On Mon, Jul 12, 2004 at 08:40:25PM +0200, Robert Millan wrote: > On Mon, Jul 12, 2004 at 02:04:34AM +0200, Michael Banck wrote: > > Hello, > > > > I've brought the hurd-i386 port of xfree86 back on track. > > [...] > > > > In order to have a clear look at the differences between linux.cf and > > gnu.cf, I shuffled gnu.cf around and reformatted some parts, in order to > > sync the two and make the diff somewhat easy to read. > > Very nice! Now that gnu.cf is overhauled and the differences with linux.cf are > minimal, what would you think of merging linux.cf into it? > > We could have some #ifdef'ed snippets of kernel-specific macros in gnu.cf, > but most of it would be generic. This way we can get Debian GNU/Linux ports > to switch to gnu.cf and we don't need to maintain separate files. I would > also like to add the k*BSD definitions that used to be in k*BSD.cf and > included from gnu.cf (in my unmerged patches). > > I can add these to your patch, make sure that nothing breaks on GNU/Linux, > and commit it. Sounds ok to you? For the record (and not that I think this should stop anything), the NetBSD (Nienna) build is derived largely from gnu.cf, and thus may need to be redone after this. Conversely, I had to sort out a lot of the same things and figure out what was the same, or different, based on 'GNU userland' vs. 'GNU core' bits, and having gnu.cf and linux.cf sanely comparable makes sense. The one thing I'd wonder (and I *haven't* looked at whether this is sane) is whether it would be possible to split the 'Debian' pieces (what userland apps are available, where manpages belong, etc) from the 'core' pieces that are Linux/Hurd/NetBSD determined. Otherwise we end up duplicating a lot of info between the three... I think this was the general direction you were going anyway, but wanted to point out that Robert's k*BSD.cf (Glibc-based) and the Nienna set (NetBSD libc based) have some very different choices for certain options - and a huge set of similarities to the current GNU, Linux, etc, files as Debian patches them. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/kNetBSD(i386) porter : :' : `. `' http://nienna.lightbearer.com/ `- pgpW6zAp2nMup.pgp Description: PGP signature
Re: Fabio Massimo di Nitto release-managing XFree86 4.3.0-8
On Tue, Apr 06, 2004 at 04:29:39AM -0500, Branden Robinson wrote: > > Okay. Daniel supports you, Michel supports you, I support you, and no > one else has said anything. > > By unanimous consent of those who had the energy to grunt, the role is > yours. :) Ugggha. Sorry I've been moderately absent; it's my on-call week for work, and Murphy (as in the bastard with the law, not the machine) has been, well, a right bastard. No objections. May $DEITY have pity on your soul. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpozc9v84Xgf.pgp Description: PGP signature
Re: PROPOSAL: re-create branches/4.3.0/sid; release off branch instead of trunk
On Tue, Mar 09, 2004 at 10:49:11PM -0500, Branden Robinson wrote: > Hi guys, > > I'm a little frustrated with the rash of FTBFSes and other problems > (like the reopening of #215831) that I can't detect on my PowerPC, > because they occur in code architecture-specific to i386 or SPARC. > > I am consequently beginning to see the wisdom in doing what many other > projects (other than XFree86 itself) do: > > * Don't release off the trunk. > * Merge only known-working fixes onto a release branch. > * Tag releases from the branch, not the trunk. > > Comments? If I don't get any, I'll go ahead and do it, but don't let > that stop you from expressing your assent, if you feel it. :) Sounds good to me. And maybe someday soon, I can get the netbsd-i386 stuff back to building X (which I haven't tried since the 4.3.99 days). Gah. Would help if work didn't keep throwing heart-attack deadlines at me. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpOEbWFmhFk4.pgp Description: PGP signature
Re: partial license audit of XFree86 4.3.0
On Thu, Feb 05, 2004 at 01:03:00AM -0500, Branden Robinson wrote: > > 2) Copyright (c) 1993, 1994 Christopher G. Demetriou > > Affected files: > xc/programs/Xserver/hw/xfree86/etc/MTRR-Lynx.shar [8] > xc/programs/Xserver/hw/xfree86/loader/aout.h [9] [ snip ] > [8] Except Mr. Demetriou actually uses the 3-clause BSD license on this file: > > X * Copyright (c) 1993 Christopher G. Demetriou > X * All rights reserved. > X * > X * Redistribution and use in source and binary forms, with or without > X * modification, are permitted provided that the following conditions > X * are met: > X * 1. Redistributions of source code must retain the above copyright > X *notice, this list of conditions and the following disclaimer. > X * 2. Redistributions in binary form must reproduce the above copyright > X *notice, this list of conditions and the following disclaimer in the > X *documentation and/or other materials provided with the distribution. > X * 3. The name of the author may not be used to endorse or promote products > X *derived from this software without specific prior written permission > X * > X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > X * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > X * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > X * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > X * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > X * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > X * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > X * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > X * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > X * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > [9] This file says it is "Borrowed from NetBSD's exec_aout.h", so it may have > since been relicensed "upstream". Since CGD is a frequent contributor to NetBSD, and he's on my list of people I still need to ask about relicensing to 3-clause stuff for the NetBSD codebase, I could possibly raise the issue of the XFree86 license texts at the same time, if you wish. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU/NetBSD(i386) porter : :' : `. `' `- pgpFsMMcquseg.pgp Description: PGP signature
Bug#219551: Unicode xterms should do some kind of substitution for missing characters
On Fri, Nov 07, 2003 at 05:31:12PM +0800, Cameron Patrick wrote: > Package: xterm > Version: 4.3.0-0pre1v4 > > Many TrueType fonts don't have both a hyphen (0x2010) and a minus sign > (0x2212); however, groff (and thus man pages) differentiates between the > two in UTF-8 locales. This results in lots of man pages displaying ugly > boxes where hyphens should be in a uxterm, but displaying fine on a > 'normal' xterm where there is no distinction between the two characters. > > uxterm should display hyphens and minus signs as a simple ASCII "-" > (0x002D, "hyphen-minus") if the font does not contain the requested > character. > > In fact, it would probably be useful if xterm had some kind of more > general character substitution mechanism for this kind of problem. [ Disclaimer: I'm part of the XSF, but I don't generally deal with] [ [u]xterm So this is merely my opinion. ] It seems to me like this is an emminently *bad* slope to start down; the entire point of Unicode's distinguishing between the two is that they are, in fact, different. True, if one transliterates them back to ASCII, then they both end up being 0x002D, but it seems to me that the sanest assumption, if someone is running UTF-8, is that they actually want UTF-8. If the default Unicode fonts are incomplete enough that they lack this character, then that is probably worthy of a bug (and this one could just be reassigned), but I fail to see why the application should be expected to do something fundamentally antithetical to the user's stated request for UTF-8, simply because some fonts claiming to be intended for Unicode fail to provide a useful set of Unicode entries. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp4VjOJUL60j.pgp Description: PGP signature
Re: please build XFree86 4.3.0 for experimental
On Tue, Oct 07, 2003 at 05:27:05PM -0500, Branden Robinson wrote: > * mips successfully built 4.3.0-0pre1v1 but hasn't attempted > 4.3.0-0pre1v3. > * arm was holding off for a PCI handling fix that affectec RiscPC > machines; this fix is in 4.3.0-0pre1v3; please try to build it. > * mipsel has never tried to build XFree86 4.3.0 as far as I can tell. > * s390 has never tried to build XFree86 4.3.0 as far as I can tell. Not that it's crucial to the general archive, but: * netbsd-i386 has never tried to build XFree86 4.3.0 (unless someone else did it and never spoke up). This is due to a large set of things that, with any luck, will start to be resolved in the relatively near future (moving a build box into a colo where it can get sufficient bandwidth, having debpool available in a public enough fashion that I'm willing to use it for managing things, and the new job that will provide funds for #1 and caused delays in #2 slowing down enough to permit more Debian work again). And then I get to figure out how to make subversion do the Right Thing, which is something I should probably be figuring out anyway. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpImo9Ots0om.pgp Description: PGP signature
Re: please build XFree86 4.3.0 for experimental
On Tue, Oct 07, 2003 at 05:27:05PM -0500, Branden Robinson wrote: > * mips successfully built 4.3.0-0pre1v1 but hasn't attempted > 4.3.0-0pre1v3. > * arm was holding off for a PCI handling fix that affectec RiscPC > machines; this fix is in 4.3.0-0pre1v3; please try to build it. > * mipsel has never tried to build XFree86 4.3.0 as far as I can tell. > * s390 has never tried to build XFree86 4.3.0 as far as I can tell. Not that it's crucial to the general archive, but: * netbsd-i386 has never tried to build XFree86 4.3.0 (unless someone else did it and never spoke up). This is due to a large set of things that, with any luck, will start to be resolved in the relatively near future (moving a build box into a colo where it can get sufficient bandwidth, having debpool available in a public enough fashion that I'm willing to use it for managing things, and the new job that will provide funds for #1 and caused delays in #2 slowing down enough to permit more Debian work again). And then I get to figure out how to make subversion do the Right Thing, which is something I should probably be figuring out anyway. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp0.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 581 - trunk/debian
Well, mutt-utf8 + mlterm certainly agrees that it's valid UTF-8. Nice to know nothing else is mangling it on the way through. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpMlEgg0wtTZ.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 581 - trunk/debian
Well, mutt-utf8 + mlterm certainly agrees that it's valid UTF-8. Nice to know nothing else is mangling it on the way through. :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp0.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 358 - in branches/4.3.0/sid/debian: . scripts
On Tue, Aug 05, 2003 at 02:50:16AM -0500, Branden Robinson wrote: > On Sun, Aug 03, 2003 at 03:13:23AM +0200, Michel Dänzer wrote: > > On Sat, 2003-08-02 at 21:39, X Strike Force SVN Admin wrote: > > > > > > - tweak xlibmesa-dri's description to mention the Linux kernel > > > specifically (poor unloved Hurd and *BSD folks get no respect, I tell > > > you) > > > > IIRC the DRI in 4.3.0 works on FreeBSD though; current DRI CVS works on > > NetBSD as well, and AFAIK there are patches for OpenBSD. > > Ah, I see. Well, I'm not aware of an active Debian/FreeBSD port (just > NetBSD). I'm happy to mention it in the package description once these > packages actually build for Debian/FreeBSD. The only port on the > horizon at present is netbsd-i386. I believe Robert is focusing on freebsd-i386. The last I knew, it was not in as advanced a stage (though that could seesaw, given that netbsd-i386 is currently undergoing fun with licenses and switchnig to -current (aka pre-2.0) for reasons mostly involving POSIX thread support). This is, FWIW, why there hasn't been any visible work on the 4.3.0 packages from me, at least. However, the license foo is now at a pausing stage, so I'm looking to get back to hammering on the build area in the next couple of days. Bootstrapping back to where we were should go a hell of a lot faster, all things considered. :) Agreed, however, that it's probably best to wait until the X packages build for the port, since getting that to work is one of the more non-trivial tasks facing a new port :) -- Joel Baker <[EMAIL PROTECTED]> pgp0.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 358 - in branches/4.3.0/sid/debian: . scripts
On Tue, Aug 05, 2003 at 02:50:16AM -0500, Branden Robinson wrote: > On Sun, Aug 03, 2003 at 03:13:23AM +0200, Michel Dänzer wrote: > > On Sat, 2003-08-02 at 21:39, X Strike Force SVN Admin wrote: > > > > > > - tweak xlibmesa-dri's description to mention the Linux kernel > > > specifically (poor unloved Hurd and *BSD folks get no respect, I tell > > > you) > > > > IIRC the DRI in 4.3.0 works on FreeBSD though; current DRI CVS works on > > NetBSD as well, and AFAIK there are patches for OpenBSD. > > Ah, I see. Well, I'm not aware of an active Debian/FreeBSD port (just > NetBSD). I'm happy to mention it in the package description once these > packages actually build for Debian/FreeBSD. The only port on the > horizon at present is netbsd-i386. I believe Robert is focusing on freebsd-i386. The last I knew, it was not in as advanced a stage (though that could seesaw, given that netbsd-i386 is currently undergoing fun with licenses and switchnig to -current (aka pre-2.0) for reasons mostly involving POSIX thread support). This is, FWIW, why there hasn't been any visible work on the 4.3.0 packages from me, at least. However, the license foo is now at a pausing stage, so I'm looking to get back to hammering on the build area in the next couple of days. Bootstrapping back to where we were should go a hell of a lot faster, all things considered. :) Agreed, however, that it's probably best to wait until the X packages build for the port, since getting that to work is one of the more non-trivial tasks facing a new port :) -- Joel Baker <[EMAIL PROTECTED]> pgpjJgpHPMLT7.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 183 - in branches/4.3.0/sid/debian: . patches
On Fri, Jun 13, 2003 at 03:44:12AM +0200, Robert Millan wrote: > On Fri, Jun 13, 2003 at 09:27:31AM +0900, ISHIKAWA Mutsumi wrote: > > >>>>> In <[EMAIL PROTECTED]> > > >>>>> Robert Millan <[EMAIL PROTECTED]> wrote: > > > > >> btw, if someone is going to fix gnu.cf, please consider splitting it > > >> into a gnu-common.cf file so that it can be shared with gnu-freebsd.cf > > >> (see the header comments in patch #820) > > > > I just wrote same idea into my TODO list > > (xfree86/people/ishikaawa/TODO). > > > > I'm planning to work for this hack on this weekend :-) > > glad to hear that! > > after looking at your TODO, i have a pair of comments on your plan: > > - i think site.def is a more adequate place for debian-specific stuff > see what the upstream docs say about site.def (INSTALL-X.org, section 3.5) > - you're moving stuff into debian.cf that isn't actualy debian-specific. > when i said "gnu-common.cf" i meant stuff common to GNUish systems > (mostly related to Glibc and userland), but not debian-specific. [1] > > I think we should take care to do these modifications in a way that they are > acceptable for upstream. So if you split into gnu-common.cf the common > stuff that isn't debian-specific, and into debian.cf (or site.def) the > debian-specific stuff, we'd just have to send gnu-common.cf to upstream > and maintain debian.cf/site.def in debian. > > [1] as of now GNU/Hurd and GNU/*BSD only exist in Debian, but we can't > assume that for a configuration file. And the NetBSD one is *not* GNU-based, which is even more reason to split the Debian-specific bits into a different file from the GNU-specific bits. -- Joel Baker <[EMAIL PROTECTED]> pgpeU4hmexE5l.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 183 - in branches/4.3.0/sid/debian: . patches
On Fri, Jun 13, 2003 at 03:44:12AM +0200, Robert Millan wrote: > On Fri, Jun 13, 2003 at 09:27:31AM +0900, ISHIKAWA Mutsumi wrote: > > >>>>> In <[EMAIL PROTECTED]> > > >>>>> Robert Millan <[EMAIL PROTECTED]> wrote: > > > > >> btw, if someone is going to fix gnu.cf, please consider splitting it > > >> into a gnu-common.cf file so that it can be shared with gnu-freebsd.cf > > >> (see the header comments in patch #820) > > > > I just wrote same idea into my TODO list > > (xfree86/people/ishikaawa/TODO). > > > > I'm planning to work for this hack on this weekend :-) > > glad to hear that! > > after looking at your TODO, i have a pair of comments on your plan: > > - i think site.def is a more adequate place for debian-specific stuff > see what the upstream docs say about site.def (INSTALL-X.org, section 3.5) > - you're moving stuff into debian.cf that isn't actualy debian-specific. > when i said "gnu-common.cf" i meant stuff common to GNUish systems > (mostly related to Glibc and userland), but not debian-specific. [1] > > I think we should take care to do these modifications in a way that they are > acceptable for upstream. So if you split into gnu-common.cf the common > stuff that isn't debian-specific, and into debian.cf (or site.def) the > debian-specific stuff, we'd just have to send gnu-common.cf to upstream > and maintain debian.cf/site.def in debian. > > [1] as of now GNU/Hurd and GNU/*BSD only exist in Debian, but we can't > assume that for a configuration file. And the NetBSD one is *not* GNU-based, which is even more reason to split the Debian-specific bits into a different file from the GNU-specific bits. -- Joel Baker <[EMAIL PROTECTED]> pgp0.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 184 - people/daniel
On Thu, Jun 12, 2003 at 08:43:18AM -0500, X Strike Force SVN Admin wrote: > Author: daniel > Date: 2003-06-12 08:43:16 -0500 (Thu, 12 Jun 2003) > New Revision: 184 > > Modified: >people/daniel/STATUS > Log: > STATUS update; completely reformatted it to make it more readable at a glance, > and of course updated the statuses of various architectures. Most of them are > just waiting on rebuilds. > > > Modified: people/daniel/STATUS > == > --- people/daniel/STATUS 2003-06-12 13:21:25 UTC (rev 183) > +++ people/daniel/STATUS 2003-06-12 13:43:16 UTC (rev 184) > @@ -8,79 +8,51 @@ [ ... ] > +netbsd-i386: no idea. (fenton) Unrelated package problems have shown a critical breakage :/ (tcl8.4 simply won't function, at all, trying to use GNU pth instead of a native POSIX thread library; this prevents the building of a whole lot of the system, in one fashion or another). This has caused us to need to do a flag day on the repository, and start building a system based on -current (aka 1.7, or maybe 2.0, nobody's said yet), rather than 1.6. Getting back to "able to attempt building XFree86" is high on the priority list; it shouldn't take nearly as much as the first attempt did, since we can use the old package setup for bootstrapping. (We don't want to link against it, but it should, mostly, be able to run in the new build area). The last attempt at XFree86 did fail; my workstation is horked, right now, but I'll try to dig out the log and provide more details. -- Joel Baker <[EMAIL PROTECTED]> pgpK2bjZDhpxw.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 184 - people/daniel
On Thu, Jun 12, 2003 at 08:43:18AM -0500, X Strike Force SVN Admin wrote: > Author: daniel > Date: 2003-06-12 08:43:16 -0500 (Thu, 12 Jun 2003) > New Revision: 184 > > Modified: >people/daniel/STATUS > Log: > STATUS update; completely reformatted it to make it more readable at a glance, > and of course updated the statuses of various architectures. Most of them are > just waiting on rebuilds. > > > Modified: people/daniel/STATUS > == > --- people/daniel/STATUS 2003-06-12 13:21:25 UTC (rev 183) > +++ people/daniel/STATUS 2003-06-12 13:43:16 UTC (rev 184) > @@ -8,79 +8,51 @@ [ ... ] > +netbsd-i386: no idea. (fenton) Unrelated package problems have shown a critical breakage :/ (tcl8.4 simply won't function, at all, trying to use GNU pth instead of a native POSIX thread library; this prevents the building of a whole lot of the system, in one fashion or another). This has caused us to need to do a flag day on the repository, and start building a system based on -current (aka 1.7, or maybe 2.0, nobody's said yet), rather than 1.6. Getting back to "able to attempt building XFree86" is high on the priority list; it shouldn't take nearly as much as the first attempt did, since we can use the old package setup for bootstrapping. (We don't want to link against it, but it should, mostly, be able to run in the new build area). The last attempt at XFree86 did fail; my workstation is horked, right now, but I'll try to dig out the log and provide more details. -- Joel Baker <[EMAIL PROTECTED]> pgp0.pgp Description: PGP signature
Re: X Strike Force: let's work on xfree86/branches/4.3.0/sid
On Mon, May 26, 2003 at 12:15:05AM -0500, Branden Robinson wrote: > On Mon, May 26, 2003 at 09:56:16AM +1000, Daniel Stone wrote: > > > 3) Bug porters. > > I'd very much like to have port specialists as part of the "committing > team". NetBSD/i386 present and accounted for. First pass at 4.3.0 building in progress (from Daniel's latest sources, because I so don't want to try to fight with Subversion on NetBSD right now...) I know the keyboard input thing never got resolved in 4.2.x, but I'll have to build stuff to remember what I mean by "the keyboard input thing" (other than it's a module or program that the changelog indicates used to be for Suns, and was removed as obsolete, but which the NetBSD stuff wants to build for reasons not yet fathomed). More in-depth discussion will appear on debian-bsd or debian-x, depending on which audience seems most apropos (or, possibly, crossposted if it's really necessary). -- Joel Baker <[EMAIL PROTECTED]> pgpdBILltwXGY.pgp Description: PGP signature
Re: gnome-randr-applet and Xfree86 4.3.0 ...
On Thu, Apr 03, 2003 at 03:44:28PM +0200, Sven Luther wrote:
> On Thu, Apr 03, 2003 at 11:21:36PM +1000, Daniel Stone wrote:
> >
> > Porting - m68k, hppa, mips, mipsel, {free,net}bsd-*. Merging Michel
> > Daenzer's radeon-ddc patch - it doesn't apply at all cleanly.
>
> I think Mark (from upstream) will be looking at Michel's patches, and it
> will no more be needed at upstream. Why does Michel's patch not apply
> cleanly ? Because he diffed them against his DRI build or something such ?
>
> BTW, the *BSD ports should work relatively ok, should they not, many of
> the X upstream use *BSD as developpment plateform.
One would think so. One would be... er... not entirely correct.
More usefully, the *code* more or less builds just fine (mostly).
However, the assumptions made are based on a tightly-coupled-to-kernel,
specific-to-that-BSD userland, *not* on a Debian GNU-ish userland; changing
this involves quite a bit of hunting down arcane Imake information, and
a few minor patches to teach the system to know when to use which set of
values.
For NetBSD, 4.(er... 2? I think?) this has been done, and it more or less
works; I have running X stuff on my not-a-buildd box, inside the chroot.
I haven't even *tried* putting a console on it, and for all I know it may
blow up merrily at that point.
Unless someone else volunteers, I intend to work with Mr. Stone (and
whomever else may be necessary) to make sure that 4.3 doesn't regress on
this. Unfortunately, at the moment the port is having issues with some bits
of toolchain sanity that's filed upstream, and we can't do a whole lot
until that's fixed (or at least, doing it is relatively pointless, unless
it's a new patchset, since it won't produce useable results).
--
Joel Baker <[EMAIL PROTECTED]>
pgpHqsp50E2ro.pgp
Description: PGP signature
Re: geometry for ibook2
On Wed, Feb 26, 2003 at 04:54:01PM -0500, Branden Robinson wrote: > On Thu, Feb 20, 2003 at 02:12:36PM +0100, Eric Boese-Wolf wrote: > > I've written an geometry file for the apple ibook2. > > Included is the patch to the xkb directory of the actual > > xlibs package in sid. I hope it will be useful to a bunch > > of beginners. I'm not subscribed to the list, so If you > > like to hear from me, cc to me. > > Please file patches with the Debian BTS (in this case, against the > "xlibs" package), so that people lose track of them. ^-- don't Normally I wouldn't pick nits, but this one sort of changed the intent of the statement... -- Joel Baker <[EMAIL PROTECTED]> pgpbPgAbrAF9F.pgp Description: PGP signature
Re: geometry for ibook2
On Wed, Feb 26, 2003 at 04:54:01PM -0500, Branden Robinson wrote: > On Thu, Feb 20, 2003 at 02:12:36PM +0100, Eric Boese-Wolf wrote: > > I've written an geometry file for the apple ibook2. > > Included is the patch to the xkb directory of the actual > > xlibs package in sid. I hope it will be useful to a bunch > > of beginners. I'm not subscribed to the list, so If you > > like to hear from me, cc to me. > > Please file patches with the Debian BTS (in this case, against the > "xlibs" package), so that people lose track of them. ^-- don't Normally I wouldn't pick nits, but this one sort of changed the intent of the statement... -- Joel Baker <[EMAIL PROTECTED]> pgp0.pgp Description: PGP signature
Re: m68k buildd's without 1.5GB of free disk should not attempt xfree86
On Wed, Oct 09, 2002 at 08:56:47PM -0500, Branden Robinson wrote: > On Wed, Oct 09, 2002 at 11:29:49PM +0200, Michel D?nzer wrote: > > On Mit, 2002-10-09 at 19:25, Branden Robinson wrote: > > > A servers-only build compiles Xlibs because the X server needs the X11 > > > header files in the exports directory. Apparently Imake doesn't know > > > how to express "just export the headers, don't really compile the > > > library". > [...] > > What about using the system installed headers, like the DRI tree does? > > And have XFree86 Build-Depend on itself? No thanks! It's bad enough that freetype2 depends on xutils, and xfree86 depends on freetype2... (though one can at least work around it in ugly ways when bootstrapping a new port, by forcibly setting the freetype-build options to build it within xfree86 long enough to make xutils build, then rebuilding it correctly). Making X Build-Depend on itself would be... augh. I'd have to start pulling my hair out. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpqbKHpVfCGy.pgp Description: PGP signature
Bug#164026: Correction of 999_NetBSD.cf
My sincerest apologies - the formerly included 999_NetBSD.cf had one part of the patch out of order. I had already fixed it, but somehow it failed to make it into my local CVS before I sent the patches. Please find the corrected patch attached to this message, as '999_NetBSD.cf.corrected'. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ This is an omnibus patch to add support for Debian-specific values in the NetBSD.cf file. It requires that imake be patched to generate the proper values for NetBSDDistribution, before these will be used (provided as a separate patch). Origionally written by Joel Baker <[EMAIL PROTECTED]>. diff -ur xc-dist/config/cf/NetBSD.cf xc/config/cf/NetBSD.cf --- xc-dist/config/cf/NetBSD.cf 2002-10-09 03:55:29.0 + +++ xc/config/cf/NetBSD.cf 2002-10-09 03:58:09.0 + @@ -18,12 +18,109 @@ #define OSTeenyVersion DefaultOSTeenyVersion #endif +#ifndef NetBSDDistribution +#define NetBSDDistribution DefaultNetBSDDistribution +/* + Add "#define NetBSDDistribution NetBSD" to your site.def or host.def. + Currently only NetBSDDebian will be autodetected. + Valid values are: +NetBSDUnknown(0) +NetBSDNative (1) +NetBSDDebian (2) +*/ +#endif + +#ifndef NetBSDDistName +# define NetBSDDistName DefaultNetBSDDistName +#endif #ifndef OSVendor #defineOSVendorThe NetBSD Foundation, Inc. #endif + +#ifndef NetBSDBinUtilsMajorVersion +# define NetBSDBinUtilsMajorVersion DefaultNetBSDBinUtilsMajorVersion +#endif + XCOMM operating system: OSName (OSMajorVersion./**/OSMinorVersion./**/OSTeenyVersion) +/* Defines for Debian GNU/NetBSD */ + +#if NetBSDDistribution == NetBSDDebian +# ifndef DefaultGcc2OptimizeOpt +# define DefaultGcc2OptimizeOpt -O2 +# endif +# define DefaultGcc2AxpOpt DefaultGcc2OptimizeOpt +# define DefaultGcc2i386OptDefaultGcc2OptimizeOpt +# define DefaultGcc2PpcOpt DefaultGcc2OptimizeOpt +# define SystemManDirectory/usr/share/man +# define HasPamYES +# define HasTk YES +# define TkLibDir /usr/lib +# define TkIncDir /usr/include +# define TkLibName tk8.3 +# define XF86SetupUsesStaticTk NO +# define HasTclYES +# define TclLibDir /usr/lib +# define TclIncDir /usr/include +# define TclLibNametcl8.3 +# define XF86SetupUsesStaticTclNO +# define XAppLoadDir EtcX11Directory/app-defaults +# define XFileSearchPathDefault Concat4(EtcX11Directory/%L/%T/%N%C,%S:EtcX11Directory/%l/%T/%N%C,%S:EtcX11Directory/%T/%N%C,%S:EtcX11Directory/%L/%T/%N%S:EtcX11Directory/%l/%T/%N%S:EtcX11Directory/%T/%N%S):Concat4($(LIBDIR)/%L/%T/%N%C,%S:$(LIBDIR)/%l/%T/%N%C,%S:$(LIBDIR)/%T/%N%C,%S:$(LIBDIR)/%L/%T/%N%S:$(LIBDIR)/%l/%T/%N%S:$(LIBDIR)/%T/%N%S) +/* the relative symlink created by this rule causes problems for us */ +# if InstallAppDefFiles +# define InstallAppDefaultsLong(file,class) @@\ +InstallNamedTarget(install,file.ad,$(INSTAPPFLAGS),$(XAPPLOADDIR),class) +# else +# define InstallAppDefaultsLong(file,class) @@\ +InstallNamedTargetNoClobber(install,file.ad,$(INSTAPPFLAGS),$(XAPPLOADDIR),class) +# endif /* InstallAppDefFiles */ + +# define SharedLibXdmGreet NO +# define LinkGLToUsrIncludeNO +# define LinkGLToUsrLibNO +# define SharedLibFont NO +# define HasZlib YES +# define SharedLibGlu YES +# define NormalLibGlu YES +# define FSUseSyslog YES + +/* + * + */ +# define DebianMaintainer "[EMAIL PROTECTED]" +/* + * + */ + +# ifdef DebianMaintainer +# ifndef XFree86CustomVersion +#define XFree86CustomVersion "Debian" +# endif +# ifndef BuilderEMailAddr +#define BuilderEMailAddr "debian-x@lists.debian.org" +# endif +# define XFree86Devel YES +# define BuildAllSpecsDocsYES +# define InstallXinitConfig YES +# define InstallXdmConfig YES +# define InstallFSConfig YES +# define DebuggableLibraries YES +# define ForceNormalLib YES +# define BuildSpecsDocs YES +# define SpecsDocDirs CTEXT GL ICCCM X11 Xext Xv i18n xterm +# define BuildRmanNO +# define BuildHtmlManPagesNO +# define ProjectManSuffix x + +/* we build-depend on libfreetype6-dev (FreeType 2.x) */ +# define BuildFreetype2LibraryNO +# define HasFreetype2 YES +# define HasXdmAuth YES +# define HasLatex YES +# endif /* DebianMaintainer */ +#endif /* NetBSDDebian */ + /* * C library features */ @@ -83,8 +180,13 @@ #define HasUsableFileMmap YES +#if NetBSDDistribu
Re: m68k buildd's without 1.5GB of free disk should not attempt xfree86
On Wed, Oct 09, 2002 at 08:56:47PM -0500, Branden Robinson wrote: > On Wed, Oct 09, 2002 at 11:29:49PM +0200, Michel D?nzer wrote: > > On Mit, 2002-10-09 at 19:25, Branden Robinson wrote: > > > A servers-only build compiles Xlibs because the X server needs the X11 > > > header files in the exports directory. Apparently Imake doesn't know > > > how to express "just export the headers, don't really compile the > > > library". > [...] > > What about using the system installed headers, like the DRI tree does? > > And have XFree86 Build-Depend on itself? No thanks! It's bad enough that freetype2 depends on xutils, and xfree86 depends on freetype2... (though one can at least work around it in ugly ways when bootstrapping a new port, by forcibly setting the freetype-build options to build it within xfree86 long enough to make xutils build, then rebuilding it correctly). Making X Build-Depend on itself would be... augh. I'd have to start pulling my hair out. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg04116/pgp0.pgp Description: PGP signature
Bug#164026: Correction of 999_NetBSD.cf
My sincerest apologies - the formerly included 999_NetBSD.cf had one part of the patch out of order. I had already fixed it, but somehow it failed to make it into my local CVS before I sent the patches. Please find the corrected patch attached to this message, as '999_NetBSD.cf.corrected'. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ This is an omnibus patch to add support for Debian-specific values in the NetBSD.cf file. It requires that imake be patched to generate the proper values for NetBSDDistribution, before these will be used (provided as a separate patch). Origionally written by Joel Baker <[EMAIL PROTECTED]>. diff -ur xc-dist/config/cf/NetBSD.cf xc/config/cf/NetBSD.cf --- xc-dist/config/cf/NetBSD.cf 2002-10-09 03:55:29.0 + +++ xc/config/cf/NetBSD.cf 2002-10-09 03:58:09.0 + @@ -18,12 +18,109 @@ #define OSTeenyVersion DefaultOSTeenyVersion #endif +#ifndef NetBSDDistribution +#define NetBSDDistribution DefaultNetBSDDistribution +/* + Add "#define NetBSDDistribution NetBSD" to your site.def or host.def. + Currently only NetBSDDebian will be autodetected. + Valid values are: +NetBSDUnknown(0) +NetBSDNative (1) +NetBSDDebian (2) +*/ +#endif + +#ifndef NetBSDDistName +# define NetBSDDistName DefaultNetBSDDistName +#endif #ifndef OSVendor #defineOSVendorThe NetBSD Foundation, Inc. #endif + +#ifndef NetBSDBinUtilsMajorVersion +# define NetBSDBinUtilsMajorVersion DefaultNetBSDBinUtilsMajorVersion +#endif + XCOMM operating system: OSName (OSMajorVersion./**/OSMinorVersion./**/OSTeenyVersion) +/* Defines for Debian GNU/NetBSD */ + +#if NetBSDDistribution == NetBSDDebian +# ifndef DefaultGcc2OptimizeOpt +# define DefaultGcc2OptimizeOpt -O2 +# endif +# define DefaultGcc2AxpOpt DefaultGcc2OptimizeOpt +# define DefaultGcc2i386OptDefaultGcc2OptimizeOpt +# define DefaultGcc2PpcOpt DefaultGcc2OptimizeOpt +# define SystemManDirectory/usr/share/man +# define HasPamYES +# define HasTk YES +# define TkLibDir /usr/lib +# define TkIncDir /usr/include +# define TkLibName tk8.3 +# define XF86SetupUsesStaticTk NO +# define HasTclYES +# define TclLibDir /usr/lib +# define TclIncDir /usr/include +# define TclLibNametcl8.3 +# define XF86SetupUsesStaticTclNO +# define XAppLoadDir EtcX11Directory/app-defaults +# define XFileSearchPathDefault +Concat4(EtcX11Directory/%L/%T/%N%C,%S:EtcX11Directory/%l/%T/%N%C,%S:EtcX11Directory/%T/%N%C,%S:EtcX11Directory/%L/%T/%N%S:EtcX11Directory/%l/%T/%N%S:EtcX11Directory/%T/%N%S):Concat4($(LIBDIR)/%L/%T/%N%C,%S:$(LIBDIR)/%l/%T/%N%C,%S:$(LIBDIR)/%T/%N%C,%S:$(LIBDIR)/%L/%T/%N%S:$(LIBDIR)/%l/%T/%N%S:$(LIBDIR)/%T/%N%S) +/* the relative symlink created by this rule causes problems for us */ +# if InstallAppDefFiles +# define InstallAppDefaultsLong(file,class) @@\ +InstallNamedTarget(install,file.ad,$(INSTAPPFLAGS),$(XAPPLOADDIR),class) +# else +# define InstallAppDefaultsLong(file,class) @@\ +InstallNamedTargetNoClobber(install,file.ad,$(INSTAPPFLAGS),$(XAPPLOADDIR),class) +# endif /* InstallAppDefFiles */ + +# define SharedLibXdmGreet NO +# define LinkGLToUsrIncludeNO +# define LinkGLToUsrLibNO +# define SharedLibFont NO +# define HasZlib YES +# define SharedLibGlu YES +# define NormalLibGlu YES +# define FSUseSyslog YES + +/* + * + */ +# define DebianMaintainer "[EMAIL PROTECTED]" +/* + * + */ + +# ifdef DebianMaintainer +# ifndef XFree86CustomVersion +#define XFree86CustomVersion "Debian" +# endif +# ifndef BuilderEMailAddr +#define BuilderEMailAddr "[EMAIL PROTECTED]" +# endif +# define XFree86Devel YES +# define BuildAllSpecsDocsYES +# define InstallXinitConfig YES +# define InstallXdmConfig YES +# define InstallFSConfig YES +# define DebuggableLibraries YES +# define ForceNormalLib YES +# define BuildSpecsDocs YES +# define SpecsDocDirs CTEXT GL ICCCM X11 Xext Xv i18n xterm +# define BuildRmanNO +# define BuildHtmlManPagesNO +# define ProjectManSuffix x + +/* we build-depend on libfreetype6-dev (FreeType 2.x) */ +# define BuildFreetype2LibraryNO +# define HasFreetype2 YES +# define HasXdmAuth YES +# define HasLatex YES +# endif /* DebianMaintainer */ +#endif /* NetBSDDebian */ + /* * C library features */ @@ -83,8 +180,13 @@ #define HasUsableFileMmap YES +#if NetBSDDistribu
Bug#164026: NetBSD build patches
Package: xfree86
Version: 4.2.1-1
Severity: normal
I am attaching four patches to this bug; all four must be present in the
debian/patches/ directory to successfully build on a NetBSD platform. I
would like to request an assigned number-range (as with the other ports)
for these patches; for the moment, they're named under the 999 convention.
Note that the netbsd_no_SharedOldX patch must be applied *after* the C++
support patch for bsdLib.rules (bug #163892), as they both touch the same
file.
Note that patches for the required debian/* support files (such as
MANIFEST.netbsd-i386) will be submitted in a separate bug.
--
***
Joel Baker System Administrator - lightbearer.com
[EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
Patch to imake.c for Debian/NetBSD support by Joel Baker
<[EMAIL PROTECTED]>.
--- xc-dist/config/imake/imake.cSun Jan 27 23:07:23 2002
+++ xc/config/imake/imake.c Sun Jan 27 23:20:05 2002
@@ -950,6 +950,10 @@
fprintf (inFile, "%s\n", "#define LinuxWare 11");
fprintf (inFile, "%s\n", "#define LinuxYggdrasil 12");
+ fprintf (inFile, "%s\n", "#define NetBSDUnknown 0");
+ fprintf (inFile, "%s\n", "#define NetBSDNative1");
+ fprintf (inFile, "%s\n", "#define NetBSDDebian2");
+
if (lstat (yast, &sb) == 0) {
fprintf (inFile, "%s\n", "#define DefaultLinuxDistribution LinuxSuSE");
fprintf (inFile, "%s\n", "#define DefaultLinuxDistName SuSE");
@@ -963,6 +967,8 @@
if (lstat (debian, &sb) == 0) {
fprintf (inFile, "%s\n", "#define DefaultLinuxDistribution LinuxDebian");
fprintf (inFile, "%s\n", "#define DefaultLinuxDistName Debian");
+fprintf (inFile, "%s\n", "#define DefaultNetBSDDistribution NetBSDDebian");
+fprintf (inFile, "%s\n", "#define DefaultNetBSDDistName Debian");
/* You could also try to get the version of the Debian distrib by looking
* at the content of /etc/debian_version */
return;
@@ -971,6 +977,8 @@
fprintf (inFile, "%s\n", "#define DefaultLinuxDistribution LinuxUnknown");
fprintf (inFile, "%s\n", "#define DefaultLinuxDistName Unknown");
+ fprintf (inFile, "%s\n", "#define DefaultNetBSDDistribution NetBSDUnknown");
+ fprintf (inFile, "%s\n", "#define DefaultNetBSDDistName Unknown");
/* would like to know what version of the distribution it is */
}
This is an omnibus patch to add support for Debian-specific values in the
NetBSD.cf file. It requires that imake be patched to generate the proper
values for NetBSDDistribution, before these will be used (provided as a
separate patch).
Origionally written by Joel Baker <[EMAIL PROTECTED]>.
diff -ur xc-dist/config/cf/NetBSD.cf xc/config/cf/NetBSD.cf
--- xc-dist/config/cf/NetBSD.cf 2002-10-09 03:55:29.0 +
+++ xc/config/cf/NetBSD.cf 2002-10-09 03:58:09.0 +
@@ -18,12 +18,109 @@
#define OSTeenyVersion DefaultOSTeenyVersion
#endif
+#ifndef NetBSDDistribution
+#define NetBSDDistribution DefaultNetBSDDistribution
+/*
+ Add "#define NetBSDDistribution NetBSD" to your site.def or host.def.
+ Currently only NetBSDDebian will be autodetected.
+ Valid values are:
+NetBSDUnknown(0)
+NetBSDNative (1)
+NetBSDDebian (2)
+*/
+#endif
+
+#ifndef NetBSDDistName
+# define NetBSDDistName DefaultNetBSDDistName
+#endif
#ifndef OSVendor
#defineOSVendorThe NetBSD Foundation, Inc.
#endif
+
+#ifndef NetBSDBinUtilsMajorVersion
+# define NetBSDBinUtilsMajorVersion DefaultNetBSDBinUtilsMajorVersion
+#endif
+
XCOMM operating system: OSName
(OSMajorVersion./**/OSMinorVersion./**/OSTeenyVersion)
+/* Defines for Debian GNU/NetBSD */
+
+#if NetBSDDistribution == NetBSDDebian
+# ifndef DefaultGcc2OptimizeOpt
+# define DefaultGcc2OptimizeOpt -O2
+# endif
+# define DefaultGcc2AxpOpt DefaultGcc2OptimizeOpt
+# define DefaultGcc2i386OptDefaultGcc2OptimizeOpt
+# define DefaultGcc2PpcOpt DefaultGcc2OptimizeOpt
+# define SystemManDirectory/usr/share/man
+# define HasPamYES
+# define HasTk YES
+# define TkLibDir /usr/lib
+# define TkIncDir /usr/include
+# define TkLibName tk8.3
+# define XF86SetupUsesStaticTk NO
+# define HasTclYES
+# define TclLibDir /usr/lib
+# define TclIncDir /usr/include
+# define TclLibNametcl8.3
+# define XF86SetupUsesStaticTclNO
+# define XAppLoadDir EtcX11Directory/app-defaults
+# define XFileSearchPathDefault
Bug#164026: NetBSD build patches
Package: xfree86
Version: 4.2.1-1
Severity: normal
I am attaching four patches to this bug; all four must be present in the
debian/patches/ directory to successfully build on a NetBSD platform. I
would like to request an assigned number-range (as with the other ports)
for these patches; for the moment, they're named under the 999 convention.
Note that the netbsd_no_SharedOldX patch must be applied *after* the C++
support patch for bsdLib.rules (bug #163892), as they both touch the same
file.
Note that patches for the required debian/* support files (such as
MANIFEST.netbsd-i386) will be submitted in a separate bug.
--
***
Joel Baker System Administrator - lightbearer.com
[EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
Patch to imake.c for Debian/NetBSD support by Joel Baker
<[EMAIL PROTECTED]>.
--- xc-dist/config/imake/imake.cSun Jan 27 23:07:23 2002
+++ xc/config/imake/imake.c Sun Jan 27 23:20:05 2002
@@ -950,6 +950,10 @@
fprintf (inFile, "%s\n", "#define LinuxWare 11");
fprintf (inFile, "%s\n", "#define LinuxYggdrasil 12");
+ fprintf (inFile, "%s\n", "#define NetBSDUnknown 0");
+ fprintf (inFile, "%s\n", "#define NetBSDNative1");
+ fprintf (inFile, "%s\n", "#define NetBSDDebian2");
+
if (lstat (yast, &sb) == 0) {
fprintf (inFile, "%s\n", "#define DefaultLinuxDistribution LinuxSuSE");
fprintf (inFile, "%s\n", "#define DefaultLinuxDistName SuSE");
@@ -963,6 +967,8 @@
if (lstat (debian, &sb) == 0) {
fprintf (inFile, "%s\n", "#define DefaultLinuxDistribution LinuxDebian");
fprintf (inFile, "%s\n", "#define DefaultLinuxDistName Debian");
+fprintf (inFile, "%s\n", "#define DefaultNetBSDDistribution NetBSDDebian");
+fprintf (inFile, "%s\n", "#define DefaultNetBSDDistName Debian");
/* You could also try to get the version of the Debian distrib by looking
* at the content of /etc/debian_version */
return;
@@ -971,6 +977,8 @@
fprintf (inFile, "%s\n", "#define DefaultLinuxDistribution LinuxUnknown");
fprintf (inFile, "%s\n", "#define DefaultLinuxDistName Unknown");
+ fprintf (inFile, "%s\n", "#define DefaultNetBSDDistribution NetBSDUnknown");
+ fprintf (inFile, "%s\n", "#define DefaultNetBSDDistName Unknown");
/* would like to know what version of the distribution it is */
}
This is an omnibus patch to add support for Debian-specific values in the
NetBSD.cf file. It requires that imake be patched to generate the proper
values for NetBSDDistribution, before these will be used (provided as a
separate patch).
Origionally written by Joel Baker <[EMAIL PROTECTED]>.
diff -ur xc-dist/config/cf/NetBSD.cf xc/config/cf/NetBSD.cf
--- xc-dist/config/cf/NetBSD.cf 2002-10-09 03:55:29.0 +
+++ xc/config/cf/NetBSD.cf 2002-10-09 03:58:09.0 +
@@ -18,12 +18,109 @@
#define OSTeenyVersion DefaultOSTeenyVersion
#endif
+#ifndef NetBSDDistribution
+#define NetBSDDistribution DefaultNetBSDDistribution
+/*
+ Add "#define NetBSDDistribution NetBSD" to your site.def or host.def.
+ Currently only NetBSDDebian will be autodetected.
+ Valid values are:
+NetBSDUnknown(0)
+NetBSDNative (1)
+NetBSDDebian (2)
+*/
+#endif
+
+#ifndef NetBSDDistName
+# define NetBSDDistName DefaultNetBSDDistName
+#endif
#ifndef OSVendor
#defineOSVendorThe NetBSD Foundation, Inc.
#endif
+
+#ifndef NetBSDBinUtilsMajorVersion
+# define NetBSDBinUtilsMajorVersion DefaultNetBSDBinUtilsMajorVersion
+#endif
+
XCOMM operating system: OSName (OSMajorVersion./**/OSMinorVersion./**/OSTeenyVersion)
+/* Defines for Debian GNU/NetBSD */
+
+#if NetBSDDistribution == NetBSDDebian
+# ifndef DefaultGcc2OptimizeOpt
+# define DefaultGcc2OptimizeOpt -O2
+# endif
+# define DefaultGcc2AxpOpt DefaultGcc2OptimizeOpt
+# define DefaultGcc2i386OptDefaultGcc2OptimizeOpt
+# define DefaultGcc2PpcOpt DefaultGcc2OptimizeOpt
+# define SystemManDirectory/usr/share/man
+# define HasPamYES
+# define HasTk YES
+# define TkLibDir /usr/lib
+# define TkIncDir /usr/include
+# define TkLibName tk8.3
+# define XF86SetupUsesStaticTk NO
+# define HasTclYES
+# define TclLibDir /usr/lib
+# define TclIncDir /usr/include
+# define TclLibNametcl8.3
+# define XF86SetupUsesStaticTclNO
+# define XAppLoadDir EtcX11Directory/app-defaults
+# define XFileSearchPathDefault
Re: xfree86 4.2.1 on NetBSD/i386
On Tue, Oct 08, 2002 at 01:33:38PM -0600, Joel Baker wrote: > The good: The better: I now have patches (against 4.2.1-1) to get a clean build on netbsd-i386. Not yet tested extensively, but it *builds*. > The bad: That I need to arrange them into a sane set of patches and submit them, yet. And... 'build' != 'binary', which does not yet pass. However, it looks like the failing bit might have been resolved by -2, so I'll investigate that first. > The ugly: > > --- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.0 + > +++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.0 > + > @@ -197 +196,0 @@ > -etc/X11/xkb/symbols/alt Removed (obsolete, per Brandon) > @@ -353 +351,0 @@ > -usr/X11R6/bin/glxinfo Fixed (by fixing libGLU.so, by fixing C++ linking support on *BSD) > @@ -356,0 +355 @@ > +usr/X11R6/bin/kbd_mode Removed (obsolete) > @@ -838,2 +836,0 @@ > -usr/X11R6/include/X11/extensions/xf86rush.h > -usr/X11R6/include/X11/extensions/xf86rushstr.h Removed (Linux/i386 specific) > @@ -5543,2 +5539,0 @@ > -usr/X11R6/lib/libI810XvMC.a > -usr/X11R6/lib/libI810XvMC_pic.a Removed (Linux/i810 specific) > @@ -5547,2 +5541,0 @@ > -usr/X11R6/lib/libOSMesa.a > -usr/X11R6/lib/libOSMesa.so.3.3 Removed (Linux/DRI specific) > @@ -5593 +5585,0 @@ > -usr/X11R6/lib/libXxf86rush.a See above. > @@ -5602,0 +5595 @@ > +usr/X11R6/lib/liboldX.so.6.0 Removed (build only static, not shared, liboldX) > @@ -5608 +5600,0 @@ > -usr/X11R6/lib/libxrx.so.6.3 Fixed (yes, Virginia, NetBSD w/ ELF *does* support plugin modules) > @@ -5752,0 +5745 @@ > +usr/X11R6/man/man1/kbd_mode.1x See above. > @@ -5754 +5746,0 @@ > -usr/X11R6/man/man1/libxrx.1x See above. > @@ -7449 +7441 @@ > -var/lib/xkb/README > +var/db/xkb/README Fixed (VarDbDirectory, per Brandon) > MANIFEST check failed; please see debian/README Not anymore it doesn't. :) > DRI support is, of course, not relevant on the NetBSD kernel, and is not Patches will be submitted to the BTS tomorrow, barring sudden crisis in my life or other such catastrophe. Now, on to making it package correctly... -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ pgpM7MoS9arou.pgp Description: PGP signature
Re: xfree86 4.2.1 on NetBSD/i386
On Tue, Oct 08, 2002 at 01:33:38PM -0600, Joel Baker wrote: > The good: The better: I now have patches (against 4.2.1-1) to get a clean build on netbsd-i386. Not yet tested extensively, but it *builds*. > The bad: That I need to arrange them into a sane set of patches and submit them, yet. And... 'build' != 'binary', which does not yet pass. However, it looks like the failing bit might have been resolved by -2, so I'll investigate that first. > The ugly: > > --- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.0 + > +++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.0 > + > @@ -197 +196,0 @@ > -etc/X11/xkb/symbols/alt Removed (obsolete, per Brandon) > @@ -353 +351,0 @@ > -usr/X11R6/bin/glxinfo Fixed (by fixing libGLU.so, by fixing C++ linking support on *BSD) > @@ -356,0 +355 @@ > +usr/X11R6/bin/kbd_mode Removed (obsolete) > @@ -838,2 +836,0 @@ > -usr/X11R6/include/X11/extensions/xf86rush.h > -usr/X11R6/include/X11/extensions/xf86rushstr.h Removed (Linux/i386 specific) > @@ -5543,2 +5539,0 @@ > -usr/X11R6/lib/libI810XvMC.a > -usr/X11R6/lib/libI810XvMC_pic.a Removed (Linux/i810 specific) > @@ -5547,2 +5541,0 @@ > -usr/X11R6/lib/libOSMesa.a > -usr/X11R6/lib/libOSMesa.so.3.3 Removed (Linux/DRI specific) > @@ -5593 +5585,0 @@ > -usr/X11R6/lib/libXxf86rush.a See above. > @@ -5602,0 +5595 @@ > +usr/X11R6/lib/liboldX.so.6.0 Removed (build only static, not shared, liboldX) > @@ -5608 +5600,0 @@ > -usr/X11R6/lib/libxrx.so.6.3 Fixed (yes, Virginia, NetBSD w/ ELF *does* support plugin modules) > @@ -5752,0 +5745 @@ > +usr/X11R6/man/man1/kbd_mode.1x See above. > @@ -5754 +5746,0 @@ > -usr/X11R6/man/man1/libxrx.1x See above. > @@ -7449 +7441 @@ > -var/lib/xkb/README > +var/db/xkb/README Fixed (VarDbDirectory, per Brandon) > MANIFEST check failed; please see debian/README Not anymore it doesn't. :) > DRI support is, of course, not relevant on the NetBSD kernel, and is not Patches will be submitted to the BTS tomorrow, barring sudden crisis in my life or other such catastrophe. Now, on to making it package correctly... -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg04067/pgp0.pgp Description: PGP signature
Bug#163892: C++ support in libGLU (patch, upstream problem)
Package: xfree86 Version: 4.2.1-1 Severity: normal This patch defines a SharedDepCplusplusLibraryTarget for FreeBSD and NetBSD. While the ELF section in bsdLib.rules is noted as having been copied from the Linux version, this clearly predated the addition of C++ code and support, and the target appears to have never been added to the BSD ruleset, making it impossible to compile cleanly using GCC 3.x (libGLU is linked without a dependancy on libstdc++, and any attempt to compile a normal C program which calls libGLU will fail). Patch authored by Joel Baker <[EMAIL PROTECTED]>, based on the rules already present in lnxLib.rules. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ This patch defines a SharedDepCplusplusLibraryTarget for FreeBSD and NetBSD. While the ELF section in bsdLib.rules is noted as having been copied from the Linux version, this clearly predated the addition of C++ code and support, and the target appears to have never been added to the BSD ruleset, making it impossible to compile cleanly using GCC 3.x (libGLU is linked without a dependancy on libstdc++, and any attempt to compile a normal C program which calls libGLU will fail). Patch authored by Joel Baker <[EMAIL PROTECTED]>, based on the rules already present in lnxLib.rules. diff -ur xc-dist/config/cf/bsdLib.rules xc/config/cf/bsdLib.rules --- xc-dist/config/cf/bsdLib.rules 2002-01-17 23:29:05.0 + +++ xc/config/cf/bsdLib.rules 2002-10-09 01:26:13.0 + @@ -306,6 +306,34 @@ #endif /* SharedDepLibraryTarget */ +/* + * SharedDepCplusplusLibraryTarget - generate rules to create a shared library. + */ +#ifndef SharedDepCplusplusLibraryTarget +#define SharedDepCplusplusLibraryTarget(libname,rev,deplist,solist,down,up) @@\ +AllTarget(Concat(lib,libname.so.rev)) @@\ + @@\ +Concat(lib,libname.so.rev): deplist @@\ + $(RM) [EMAIL PROTECTED] @@\ + @SONAME=`echo $@ | sed 's/\.[^\.]*$$//'`; set -x; \ @@\ + (cd down; $(CXX) -o up/[EMAIL PROTECTED] $(SHLIBLDFLAGS) -Wl,-soname,$$SONAME solist $(REQUIREDLIBS) BaseShLibReqs); \ @@\ + $(RM) $$SONAME; $(LN) $@ $$SONAME; \@@\ + LinkBuildSonameLibrary($$SONAME)@@\ + $(RM) $@@@\ + $(MV) [EMAIL PROTECTED] $@ @@\ + $(RM) Concat(lib,libname.so)@@\ + $(LN) $@ Concat(lib,libname.so) @@\ + LinkBuildLibrary($@)@@\ + LinkBuildLibrary(Concat(lib,libname.so))@@\ + @@\ +clean:: @@\ + @SONAME=`echo Concat(lib,libname.so.rev) | sed 's/\.[^\.]*$$//'`; \ @@\ + set -x; $(RM) $$SONAME @@\ + $(RM) Concat(lib,libname.so)@@\ + $(RM) Concat(lib,libname.so.rev) + +#endif /* SharedDepCplusplusLibraryTarget */ + #ifndef SharedDepModuleTarget #define SharedDepModuleTarget(name,deps,solist) @@\ AllTarget(name) @@\
Re: xfree86 4.2.1 on NetBSD/i386
On Tue, Oct 08, 2002 at 08:07:39PM -0500, Branden Robinson wrote: > On Tue, Oct 08, 2002 at 04:45:18PM -0600, Joel Baker wrote: > > > > @@ -356,0 +355 @@ > > > > +usr/X11R6/bin/kbd_mode > > > > > > I used to see this on Sun machines. You sure it's necessary with modern > > > BSD kernels? > > > > I'm not sure it is. I mostly don't know where/how to check whether it is, > > or what it's supposed to do. > > It changes the tty keyboard reading mode, e.g., from "raw" to "cooked" > and vice versa. > > I think Linux doesn't have this because a keyboard state is specific to > each virtual terminal, so the kernel knows to put the keyboard state > back after the X server crashes and gives up its VT. > > On Sun boxen, you often had to telnet[1] into the box after X crashed and > run "kbd_mode -a". Ah. Yes, I remember doing that now. And I suspect it's obsolete on modern NetBSD, then, because it also has virtual terminals (albeit of a different sort, but the same concept) with which X interacts directly. Two different versions thereof, even. I'll see if I can convince it to stop building. > > > > @@ -5543,2 +5539,0 @@ > > > > -usr/X11R6/lib/libI810XvMC.a > > > > -usr/X11R6/lib/libI810XvMC_pic.a > > > > > > This is new to XFree86 4.2. My guess is that it does something to hook > > > into the (Linux) kernel to speak foul magic to the hardware. XvMC is > > > Mark Vojkovich's motion compensation interface on top of the XVideo (Xv) > > > extension. I'll cautiously assume that *BSD shouldn't be building this. > > > > We can always put it back in if someone can show that it should build/work > > on NetBSD platforms. However, at the moment, this is not listed as being > > supportd on the NetBSD arch page in XFree86 docs. Will yank it. > > I forgot to mention that you *should* have libXvMC. Just probably not > this I810 thing. Left those in; only the I810 files were removed from the MANIFEST. > > > Nobody who builds DRI builds the offscreen Mesa library. Michel Dänzer > > > understands better how this stuff works. (I.e., I don't know *why* it's > > > called the "offscreen" Mesa library, or why 3D-accelerated GL rendering > > > is considered "off-the-screen". Maybe it means the rendering isn't done > > > into the framebuffer, a.k.a. "screen"?) > > > > Er. Is that 'not building DRI implies not building libOSMesa' - IE, it > > should be removed for non-Linux platforms? > > Correct, as I understand it. Okay. Makes sense to me. > > > > @@ -5602,0 +5595 @@ > > > > +usr/X11R6/lib/liboldX.so.6.0 > > > > > > This goes in xlibs-dev.files. Already listed there. > > > > Huh. xlibs-dev.files (and all of the MANIFESTs) have a static library > > (/usr/X11R6/lib/liboldX.a) rather than a dynamic one. Maybe I need to tweak > > a suitable part of the system and tell it to build a static liboldX? > > Sorry, I failed to pay attention. Please don't ship a shared liboldX > unless for some insane reason you need it for binary compatiblity with > other BSDs. It would be preferable to turn of building of the shared > version. I'll see if I can figure out why it's doing so and whack it into a static instead. > > > > @@ -5608 +5600,0 @@ > > > > -usr/X11R6/lib/libxrx.so.6.3 > > > > > > Another extension no one uses. This is the Netscape Navigator plug in > > > that lets you render the X server inside a browser window or some lunacy > > > like that. I'm not sure there's a good reason it shouldn't build on > > > *BSD versus Linux, but on the other hand there's probably not a good > > > reason for *anyone* to build it. > > > > Hmmm. I'll look into it, but after I do other things, then; tentatively > > left in place, until I can figure out what is up with it on NetBSD. > > Maybe the Netscape plugin code is Linux-specific? I have no idea. I'm > sure no one cares about this thing. I'm sure, too, but *iff* it compiles, well, it would be nice to make it available. But low priority. :) > > Now, the explanation for glxinfo (and it probably has much deeper > > reprecussions): NetBSD includes bsdLib.rules, which does not have a number > > of things from lnxLib.rules (the thing which made me realize this matters > > is that it lacks SharedDepCplusplusLib, causing libGLU to be linked with > > 'gcc'
Bug#163892: C++ support in libGLU (patch, upstream problem)
Package: xfree86 Version: 4.2.1-1 Severity: normal This patch defines a SharedDepCplusplusLibraryTarget for FreeBSD and NetBSD. While the ELF section in bsdLib.rules is noted as having been copied from the Linux version, this clearly predated the addition of C++ code and support, and the target appears to have never been added to the BSD ruleset, making it impossible to compile cleanly using GCC 3.x (libGLU is linked without a dependancy on libstdc++, and any attempt to compile a normal C program which calls libGLU will fail). Patch authored by Joel Baker <[EMAIL PROTECTED]>, based on the rules already present in lnxLib.rules. -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ This patch defines a SharedDepCplusplusLibraryTarget for FreeBSD and NetBSD. While the ELF section in bsdLib.rules is noted as having been copied from the Linux version, this clearly predated the addition of C++ code and support, and the target appears to have never been added to the BSD ruleset, making it impossible to compile cleanly using GCC 3.x (libGLU is linked without a dependancy on libstdc++, and any attempt to compile a normal C program which calls libGLU will fail). Patch authored by Joel Baker <[EMAIL PROTECTED]>, based on the rules already present in lnxLib.rules. diff -ur xc-dist/config/cf/bsdLib.rules xc/config/cf/bsdLib.rules --- xc-dist/config/cf/bsdLib.rules 2002-01-17 23:29:05.0 + +++ xc/config/cf/bsdLib.rules 2002-10-09 01:26:13.0 + @@ -306,6 +306,34 @@ #endif /* SharedDepLibraryTarget */ +/* + * SharedDepCplusplusLibraryTarget - generate rules to create a shared library. + */ +#ifndef SharedDepCplusplusLibraryTarget +#define SharedDepCplusplusLibraryTarget(libname,rev,deplist,solist,down,up)@@\ +AllTarget(Concat(lib,libname.so.rev)) @@\ + @@\ +Concat(lib,libname.so.rev): deplist @@\ + $(RM) $@~ @@\ + @SONAME=`echo $@ | sed 's/\.[^\.]*$$//'`; set -x; \ @@\ + (cd down; $(CXX) -o up/$@~ $(SHLIBLDFLAGS) -Wl,-soname,$$SONAME solist +$(REQUIREDLIBS) BaseShLibReqs); \ @@\ + $(RM) $$SONAME; $(LN) $@ $$SONAME; \@@\ + LinkBuildSonameLibrary($$SONAME)@@\ + $(RM) $@@@\ + $(MV) $@~ $@@@\ + $(RM) Concat(lib,libname.so)@@\ + $(LN) $@ Concat(lib,libname.so) @@\ + LinkBuildLibrary($@)@@\ + LinkBuildLibrary(Concat(lib,libname.so))@@\ + @@\ +clean::@@\ + @SONAME=`echo Concat(lib,libname.so.rev) | sed 's/\.[^\.]*$$//'`; \ @@\ + set -x; $(RM) $$SONAME @@\ + $(RM) Concat(lib,libname.so)@@\ + $(RM) Concat(lib,libname.so.rev) + +#endif /* SharedDepCplusplusLibraryTarget */ + #ifndef SharedDepModuleTarget #define SharedDepModuleTarget(name,deps,solist)@@\ AllTarget(name)@@\
Re: xfree86 4.2.1 on NetBSD/i386
On Tue, Oct 08, 2002 at 08:07:39PM -0500, Branden Robinson wrote: > On Tue, Oct 08, 2002 at 04:45:18PM -0600, Joel Baker wrote: > > > > @@ -356,0 +355 @@ > > > > +usr/X11R6/bin/kbd_mode > > > > > > I used to see this on Sun machines. You sure it's necessary with modern > > > BSD kernels? > > > > I'm not sure it is. I mostly don't know where/how to check whether it is, > > or what it's supposed to do. > > It changes the tty keyboard reading mode, e.g., from "raw" to "cooked" > and vice versa. > > I think Linux doesn't have this because a keyboard state is specific to > each virtual terminal, so the kernel knows to put the keyboard state > back after the X server crashes and gives up its VT. > > On Sun boxen, you often had to telnet[1] into the box after X crashed and > run "kbd_mode -a". Ah. Yes, I remember doing that now. And I suspect it's obsolete on modern NetBSD, then, because it also has virtual terminals (albeit of a different sort, but the same concept) with which X interacts directly. Two different versions thereof, even. I'll see if I can convince it to stop building. > > > > @@ -5543,2 +5539,0 @@ > > > > -usr/X11R6/lib/libI810XvMC.a > > > > -usr/X11R6/lib/libI810XvMC_pic.a > > > > > > This is new to XFree86 4.2. My guess is that it does something to hook > > > into the (Linux) kernel to speak foul magic to the hardware. XvMC is > > > Mark Vojkovich's motion compensation interface on top of the XVideo (Xv) > > > extension. I'll cautiously assume that *BSD shouldn't be building this. > > > > We can always put it back in if someone can show that it should build/work > > on NetBSD platforms. However, at the moment, this is not listed as being > > supportd on the NetBSD arch page in XFree86 docs. Will yank it. > > I forgot to mention that you *should* have libXvMC. Just probably not > this I810 thing. Left those in; only the I810 files were removed from the MANIFEST. > > > Nobody who builds DRI builds the offscreen Mesa library. Michel Dänzer > > > understands better how this stuff works. (I.e., I don't know *why* it's > > > called the "offscreen" Mesa library, or why 3D-accelerated GL rendering > > > is considered "off-the-screen". Maybe it means the rendering isn't done > > > into the framebuffer, a.k.a. "screen"?) > > > > Er. Is that 'not building DRI implies not building libOSMesa' - IE, it > > should be removed for non-Linux platforms? > > Correct, as I understand it. Okay. Makes sense to me. > > > > @@ -5602,0 +5595 @@ > > > > +usr/X11R6/lib/liboldX.so.6.0 > > > > > > This goes in xlibs-dev.files. Already listed there. > > > > Huh. xlibs-dev.files (and all of the MANIFESTs) have a static library > > (/usr/X11R6/lib/liboldX.a) rather than a dynamic one. Maybe I need to tweak > > a suitable part of the system and tell it to build a static liboldX? > > Sorry, I failed to pay attention. Please don't ship a shared liboldX > unless for some insane reason you need it for binary compatiblity with > other BSDs. It would be preferable to turn of building of the shared > version. I'll see if I can figure out why it's doing so and whack it into a static instead. > > > > @@ -5608 +5600,0 @@ > > > > -usr/X11R6/lib/libxrx.so.6.3 > > > > > > Another extension no one uses. This is the Netscape Navigator plug in > > > that lets you render the X server inside a browser window or some lunacy > > > like that. I'm not sure there's a good reason it shouldn't build on > > > *BSD versus Linux, but on the other hand there's probably not a good > > > reason for *anyone* to build it. > > > > Hmmm. I'll look into it, but after I do other things, then; tentatively > > left in place, until I can figure out what is up with it on NetBSD. > > Maybe the Netscape plugin code is Linux-specific? I have no idea. I'm > sure no one cares about this thing. I'm sure, too, but *iff* it compiles, well, it would be nice to make it available. But low priority. :) > > Now, the explanation for glxinfo (and it probably has much deeper > > reprecussions): NetBSD includes bsdLib.rules, which does not have a number > > of things from lnxLib.rules (the thing which made me realize this matters > > is that it lacks SharedDepCplusplusLib, causing libGLU to be linked with > > 'gcc'
Re: xfree86 4.2.1 on NetBSD/i386
On Tue, Oct 08, 2002 at 05:04:18PM -0500, Branden Robinson wrote: > On Tue, Oct 08, 2002 at 01:33:38PM -0600, Joel Baker wrote: > > The good: > > > > After a bit of banging on things to force the circular dependancy path > > between freetype and xfree86, and cribbing from the patches written for > > 4.1.0, I'm close (very close) to having a set of patches to make xfree86 > > compile cleanly on the netbsd-i386 arch. > > Cool! > > > The bad: > > > > It requires some extensive patching. Some of this (strnlen portability > > in xserver-wrapper.c, etc) has already been filed; the rest is waiting > > on me getting the last bits hammered out. I've tried to make the patches > > something that would be acceptable to upstream, but I have no idea if > > they really will be. The most extensive, unsuprisingly, are to NetBSD.cf, > > and are largely cribbed from linux.cf; however, changes to imake and > > other things also need to happen. > > I gather that xc/config/cf/bsdLib.rules is going to be painful as well. So I'm finding out. Not sure whether to patch this extensively, or just generate a completely new file and patch NetBSD.cf to include that. Probably patch. > > The ugly: > > > > --- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.0 + > > +++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.0 > > + > > @@ -197 +196,0 @@ > > -etc/X11/xkb/symbols/alt > > Obsolete. See changelog. Okay. > > @@ -353 +351,0 @@ > > -usr/X11R6/bin/glxinfo > > I can't think of a reason this shouldn't be built. It should be > possible to build the GLX extension, and therefore this client, even > without DRI stuff. See below. > > @@ -356,0 +355 @@ > > +usr/X11R6/bin/kbd_mode > > I used to see this on Sun machines. You sure it's necessary with modern > BSD kernels? I'm not sure it is. I mostly don't know where/how to check whether it is, or what it's supposed to do. > > @@ -838,2 +836,0 @@ > > -usr/X11R6/include/X11/extensions/xf86rush.h > > -usr/X11R6/include/X11/extensions/xf86rushstr.h > > Looks okay. This is the never-used Voodoo Rush extension. It builds on > Linux/i386 but I've never heard of anyone using it for anything. Okay. I'll yank those then. > > @@ -5543,2 +5539,0 @@ > > -usr/X11R6/lib/libI810XvMC.a > > -usr/X11R6/lib/libI810XvMC_pic.a > > This is new to XFree86 4.2. My guess is that it does something to hook > into the (Linux) kernel to speak foul magic to the hardware. XvMC is > Mark Vojkovich's motion compensation interface on top of the XVideo (Xv) > extension. I'll cautiously assume that *BSD shouldn't be building this. We can always put it back in if someone can show that it should build/work on NetBSD platforms. However, at the moment, this is not listed as being supportd on the NetBSD arch page in XFree86 docs. Will yank it. > > @@ -5547,2 +5541,0 @@ > > -usr/X11R6/lib/libOSMesa.a > > -usr/X11R6/lib/libOSMesa.so.3.3 > > Nobody who builds DRI builds the offscreen Mesa library. Michel Dänzer > understands better how this stuff works. (I.e., I don't know *why* it's > called the "offscreen" Mesa library, or why 3D-accelerated GL rendering > is considered "off-the-screen". Maybe it means the rendering isn't done > into the framebuffer, a.k.a. "screen"?) Er. Is that 'not building DRI implies not building libOSMesa' - IE, it should be removed for non-Linux platforms? > > @@ -5593 +5585,0 @@ > > -usr/X11R6/lib/libXxf86rush.a > > Voodoo Rush extension; see above. Removed. > > @@ -5602,0 +5595 @@ > > +usr/X11R6/lib/liboldX.so.6.0 > > This goes in xlibs-dev.files. Already listed there. Huh. xlibs-dev.files (and all of the MANIFESTs) have a static library (/usr/X11R6/lib/liboldX.a) rather than a dynamic one. Maybe I need to tweak a suitable part of the system and tell it to build a static liboldX? > > @@ -5608 +5600,0 @@ > > -usr/X11R6/lib/libxrx.so.6.3 > > Another extension no one uses. This is the Netscape Navigator plug in > that lets you render the X server inside a browser window or some lunacy > like that. I'm not sure there's a good reason it shouldn't build on > *BSD versus Linux, but on the other hand there's probably not a good > reason for *anyone* to build it. Hmmm. I'll look into it, but after I do other things, then; tentatively left in place, until I can figure out what is up with it on NetBSD. > > @@ -5752,0 +5745 @@ > > +usr/X11R6/man/man1/kbd_mode
Re: xfree86 4.2.1 on NetBSD/i386
On Tue, Oct 08, 2002 at 05:04:18PM -0500, Branden Robinson wrote: > On Tue, Oct 08, 2002 at 01:33:38PM -0600, Joel Baker wrote: > > The good: > > > > After a bit of banging on things to force the circular dependancy path > > between freetype and xfree86, and cribbing from the patches written for > > 4.1.0, I'm close (very close) to having a set of patches to make xfree86 > > compile cleanly on the netbsd-i386 arch. > > Cool! > > > The bad: > > > > It requires some extensive patching. Some of this (strnlen portability > > in xserver-wrapper.c, etc) has already been filed; the rest is waiting > > on me getting the last bits hammered out. I've tried to make the patches > > something that would be acceptable to upstream, but I have no idea if > > they really will be. The most extensive, unsuprisingly, are to NetBSD.cf, > > and are largely cribbed from linux.cf; however, changes to imake and > > other things also need to happen. > > I gather that xc/config/cf/bsdLib.rules is going to be painful as well. So I'm finding out. Not sure whether to patch this extensively, or just generate a completely new file and patch NetBSD.cf to include that. Probably patch. > > The ugly: > > > > --- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.0 + > > +++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.0 > > + > > @@ -197 +196,0 @@ > > -etc/X11/xkb/symbols/alt > > Obsolete. See changelog. Okay. > > @@ -353 +351,0 @@ > > -usr/X11R6/bin/glxinfo > > I can't think of a reason this shouldn't be built. It should be > possible to build the GLX extension, and therefore this client, even > without DRI stuff. See below. > > @@ -356,0 +355 @@ > > +usr/X11R6/bin/kbd_mode > > I used to see this on Sun machines. You sure it's necessary with modern > BSD kernels? I'm not sure it is. I mostly don't know where/how to check whether it is, or what it's supposed to do. > > @@ -838,2 +836,0 @@ > > -usr/X11R6/include/X11/extensions/xf86rush.h > > -usr/X11R6/include/X11/extensions/xf86rushstr.h > > Looks okay. This is the never-used Voodoo Rush extension. It builds on > Linux/i386 but I've never heard of anyone using it for anything. Okay. I'll yank those then. > > @@ -5543,2 +5539,0 @@ > > -usr/X11R6/lib/libI810XvMC.a > > -usr/X11R6/lib/libI810XvMC_pic.a > > This is new to XFree86 4.2. My guess is that it does something to hook > into the (Linux) kernel to speak foul magic to the hardware. XvMC is > Mark Vojkovich's motion compensation interface on top of the XVideo (Xv) > extension. I'll cautiously assume that *BSD shouldn't be building this. We can always put it back in if someone can show that it should build/work on NetBSD platforms. However, at the moment, this is not listed as being supportd on the NetBSD arch page in XFree86 docs. Will yank it. > > @@ -5547,2 +5541,0 @@ > > -usr/X11R6/lib/libOSMesa.a > > -usr/X11R6/lib/libOSMesa.so.3.3 > > Nobody who builds DRI builds the offscreen Mesa library. Michel Dänzer > understands better how this stuff works. (I.e., I don't know *why* it's > called the "offscreen" Mesa library, or why 3D-accelerated GL rendering > is considered "off-the-screen". Maybe it means the rendering isn't done > into the framebuffer, a.k.a. "screen"?) Er. Is that 'not building DRI implies not building libOSMesa' - IE, it should be removed for non-Linux platforms? > > @@ -5593 +5585,0 @@ > > -usr/X11R6/lib/libXxf86rush.a > > Voodoo Rush extension; see above. Removed. > > @@ -5602,0 +5595 @@ > > +usr/X11R6/lib/liboldX.so.6.0 > > This goes in xlibs-dev.files. Already listed there. Huh. xlibs-dev.files (and all of the MANIFESTs) have a static library (/usr/X11R6/lib/liboldX.a) rather than a dynamic one. Maybe I need to tweak a suitable part of the system and tell it to build a static liboldX? > > @@ -5608 +5600,0 @@ > > -usr/X11R6/lib/libxrx.so.6.3 > > Another extension no one uses. This is the Netscape Navigator plug in > that lets you render the X server inside a browser window or some lunacy > like that. I'm not sure there's a good reason it shouldn't build on > *BSD versus Linux, but on the other hand there's probably not a good > reason for *anyone* to build it. Hmmm. I'll look into it, but after I do other things, then; tentatively left in place, until I can figure out what is up with it on NetBSD. > > @@ -5752,0 +5745 @@ > > +usr/X11R6/man/man1/kbd
xfree86 4.2.1 on NetBSD/i386
The good:
After a bit of banging on things to force the circular dependancy path
between freetype and xfree86, and cribbing from the patches written for
4.1.0, I'm close (very close) to having a set of patches to make xfree86
compile cleanly on the netbsd-i386 arch.
The bad:
It requires some extensive patching. Some of this (strnlen portability
in xserver-wrapper.c, etc) has already been filed; the rest is waiting
on me getting the last bits hammered out. I've tried to make the patches
something that would be acceptable to upstream, but I have no idea if
they really will be. The most extensive, unsuprisingly, are to NetBSD.cf,
and are largely cribbed from linux.cf; however, changes to imake and
other things also need to happen.
The ugly:
--- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.0 +
+++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.0
+
@@ -197 +196,0 @@
-etc/X11/xkb/symbols/alt
@@ -353 +351,0 @@
-usr/X11R6/bin/glxinfo
@@ -356,0 +355 @@
+usr/X11R6/bin/kbd_mode
@@ -838,2 +836,0 @@
-usr/X11R6/include/X11/extensions/xf86rush.h
-usr/X11R6/include/X11/extensions/xf86rushstr.h
@@ -5543,2 +5539,0 @@
-usr/X11R6/lib/libI810XvMC.a
-usr/X11R6/lib/libI810XvMC_pic.a
@@ -5547,2 +5541,0 @@
-usr/X11R6/lib/libOSMesa.a
-usr/X11R6/lib/libOSMesa.so.3.3
@@ -5593 +5585,0 @@
-usr/X11R6/lib/libXxf86rush.a
@@ -5602,0 +5595 @@
+usr/X11R6/lib/liboldX.so.6.0
@@ -5608 +5600,0 @@
-usr/X11R6/lib/libxrx.so.6.3
@@ -5752,0 +5745 @@
+usr/X11R6/man/man1/kbd_mode.1x
@@ -5754 +5746,0 @@
-usr/X11R6/man/man1/libxrx.1x
@@ -7449 +7441 @@
-var/lib/xkb/README
+var/db/xkb/README
MANIFEST check failed; please see debian/README
DRI support is, of course, not relevant on the NetBSD kernel, and is not
present (and the related files have been removed already); the same goes
for the video4linux drivers. libGL and company, which didn't compile under
4.1.0, now work (I think this is largely because the NetBSD port has
upgraded to version 1.6 in the meanwhile, and this is a major cleanup of
the NetBSD base system).
I have not yet looked into glxinfo to find out why it isn't building,
but it's on my list. I would appreciate hints on the following, though,
and whether I should expect them to build on NetBSD or remove them from
the MANIFEST:
* /etc/X11/xkb/symbols/alt (err...)
* kdb_mode (this used to be there, and was removed from most ports,
according to the old changelog?)
* xf86rush
* I810XvMC (Intel 810 board support?)
* OSMesa (OS-specific MESA libraries?)
* liboldX
* libxrx
I'm assuming that I can find a way to weak the /var/{lib,db}/xkb/README
location somewhere; I haven't dug into it yet.
--
***
Joel Baker System Administrator - lightbearer.com
[EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
pgpwUje5QCnny.pgp
Description: PGP signature
xfree86 4.2.1 on NetBSD/i386
The good:
After a bit of banging on things to force the circular dependancy path
between freetype and xfree86, and cribbing from the patches written for
4.1.0, I'm close (very close) to having a set of patches to make xfree86
compile cleanly on the netbsd-i386 arch.
The bad:
It requires some extensive patching. Some of this (strnlen portability
in xserver-wrapper.c, etc) has already been filed; the rest is waiting
on me getting the last bits hammered out. I've tried to make the patches
something that would be acceptable to upstream, but I have no idea if
they really will be. The most extensive, unsuprisingly, are to NetBSD.cf,
and are largely cribbed from linux.cf; however, changes to imake and
other things also need to happen.
The ugly:
--- debian/MANIFEST.netbsd-i386 2002-10-08 07:23:56.0 +
+++ debian/MANIFEST.netbsd-i386.new 2002-10-08 18:50:48.0
+
@@ -197 +196,0 @@
-etc/X11/xkb/symbols/alt
@@ -353 +351,0 @@
-usr/X11R6/bin/glxinfo
@@ -356,0 +355 @@
+usr/X11R6/bin/kbd_mode
@@ -838,2 +836,0 @@
-usr/X11R6/include/X11/extensions/xf86rush.h
-usr/X11R6/include/X11/extensions/xf86rushstr.h
@@ -5543,2 +5539,0 @@
-usr/X11R6/lib/libI810XvMC.a
-usr/X11R6/lib/libI810XvMC_pic.a
@@ -5547,2 +5541,0 @@
-usr/X11R6/lib/libOSMesa.a
-usr/X11R6/lib/libOSMesa.so.3.3
@@ -5593 +5585,0 @@
-usr/X11R6/lib/libXxf86rush.a
@@ -5602,0 +5595 @@
+usr/X11R6/lib/liboldX.so.6.0
@@ -5608 +5600,0 @@
-usr/X11R6/lib/libxrx.so.6.3
@@ -5752,0 +5745 @@
+usr/X11R6/man/man1/kbd_mode.1x
@@ -5754 +5746,0 @@
-usr/X11R6/man/man1/libxrx.1x
@@ -7449 +7441 @@
-var/lib/xkb/README
+var/db/xkb/README
MANIFEST check failed; please see debian/README
DRI support is, of course, not relevant on the NetBSD kernel, and is not
present (and the related files have been removed already); the same goes
for the video4linux drivers. libGL and company, which didn't compile under
4.1.0, now work (I think this is largely because the NetBSD port has
upgraded to version 1.6 in the meanwhile, and this is a major cleanup of
the NetBSD base system).
I have not yet looked into glxinfo to find out why it isn't building,
but it's on my list. I would appreciate hints on the following, though,
and whether I should expect them to build on NetBSD or remove them from
the MANIFEST:
* /etc/X11/xkb/symbols/alt (err...)
* kdb_mode (this used to be there, and was removed from most ports,
according to the old changelog?)
* xf86rush
* I810XvMC (Intel 810 board support?)
* OSMesa (OS-specific MESA libraries?)
* liboldX
* libxrx
I'm assuming that I can find a way to weak the /var/{lib,db}/xkb/README
location somewhere; I haven't dug into it yet.
--
***
Joel Baker System Administrator - lightbearer.com
[EMAIL PROTECTED] http://users.lightbearer.com/lucifer/
msg04036/pgp0.pgp
Description: PGP signature
