Re: Is xenocara broken, or am I?

On Sun, 6 Jun 2010 20:49:59 -0400 "STeve Andre'" <[email protected]> wrote:
>
> Having problems making X on an i386-current system where the kernel
> and userland compiled last night (June 5th 1600 EDT).
> 
> X however doesn't compile.  Thinking that I'd once again botched
> my tree I got a new xenocara from obsd.cec.mtu.edu, cleaned
> /usr/xobj and tried again with the results below.  I don't see any
> new extries in the -current faq, so I'm puzzled.
> 
> Cluesticks?
> 
> thanks, STeve Andre'
> 
> Making all in man
> sed -e 's/__vendorversion__/"libXaw 1.0.7" "X Version 11"/'
> < /usr/xenocara/lib/libXaw/man/Xaw.man > Xaw.3
> Making all in spec
> /usr/bin/groff -Tps -t -ms -dxV="libXaw
> 1.0.7" /usr/xenocara/lib/libXaw/spec/macros.t
> /usr/xenocara/lib/libXaw/spec/strings.mit
> /usr/xenocara/lib/libXaw/spec/strings.xaw
> /usr/xenocara/lib/libXaw/spec/TPage_Credits /usr/xenocara/lib/libXaw/spec/CH1
> /usr/xenocara/lib/libXaw/spec/CH2 /usr/xenocara/lib/libXaw/spec/CH3.intro
> /usr/xenocara/lib/libXaw/spec/Command /usr/xenocara/lib/libXaw/spec/Grip
> /usr/xenocara/lib/libXaw/spec/Label /usr/xenocara/lib/libXaw/spec/List
> /usr/xenocara/lib/libXaw/spec/Panner /usr/xenocara/lib/libXaw/spec/Repeater
> /usr/xenocara/lib/libXaw/spec/Scrollbar /usr/xenocara/lib/libXaw/spec/Simple
> /usr/xenocara/lib/libXaw/spec/StripChart /usr/xenocara/lib/libXaw/spec/Toggle
> /usr/xenocara/lib/libXaw/spec/CH4.intro
> /usr/xenocara/lib/libXaw/spec/SimpleMenu /usr/xenocara/lib/libXaw/spec/SmeBSB
> /usr/xenocara/lib/libXaw/spec/SmeLine /usr/xenocara/lib/libXaw/spec/Sme
> /usr/xenocara/lib/libXaw/spec/MenuButton
> /usr/xenocara/lib/libXaw/spec/CH5.intro
> /usr/xenocara/lib/libXaw/spec/TextActions
> /usr/xenocara/lib/libXaw/spec/TextFuncs
> /usr/xenocara/lib/libXaw/spec/AsciiText
> /usr/xenocara/lib/libXaw/spec/AsciiSource
> /usr/xenocara/lib/libXaw/spec/AsciiSink
> /usr/xenocara/lib/libXaw/spec/TextCustom /usr/xenocara/lib/libXaw/spec/Text
> /usr/xenocara/lib/libXaw/spec/TextSource
> /usr/xenocara/lib/libXaw/spec/TextSink /usr/xenocara/lib/libXaw/spec/CH6.intro
> /usr/xenocara/lib/libXaw/spec/Box /usr/xenocara/lib/libXaw/spec/Dialog
> /usr/xenocara/lib/libXaw/spec/Form /usr/xenocara/lib/libXaw/spec/Paned
> /usr/xenocara/lib/libXaw/spec/Porthole /usr/xenocara/lib/libXaw/spec/Tree
> /usr/xenocara/lib/libXaw/spec/Viewport /usr/xenocara/lib/libXaw/spec/CH7.intro
> /usr/xenocara/lib/libXaw/spec/Template
> 2> index.raw > widgets.ps
> /usr/xenocara/lib/libXaw/spec/strings.mit:10: no current hyphenation
> language *** Error code 1
> 
> Stop in /usr/xenocara/lib/libXaw/obj/spec (line 440 of Makefile).
> *** Error code 1
> 
> Stop in /usr/xenocara/lib/libXaw/obj (line 363 of Makefile).
> *** Error code 1
> 
> Stop in /usr/xenocara/lib/libXaw/obj (line 249 of Makefile).
> *** Error code 1
> 

Hi STeve,

There was recently a little bug that got backed out in the last 24 hours
or so that seems "possibly" related to the failure you posted. I am not
certain it is the cause of your woes, but I've cc'd Ingo so he knows.

> From: Ingo Schwarze <[email protected]>
> To: [email protected]
> Subject: CVS: cvs.openbsd.org: src
> Date: Sun, 6 Jun 2010 10:24:32 -0600 (MDT)
> 
> CVSROOT:	/cvs
> Module name:	src
> Changes by:	[email protected]	2010/06/06 10:24:32
> 
> Modified files:
> 	gnu/usr.bin/groff/tmac: troffrc 
> 
> Log message:
> Back out rev. 1.2 which breakes the .hw roff instruction,
> found the hard way by matthieu@ and krw@
> in /usr/xenocara/lib/libXaw/spec/strings.mit.
> 
> This needs to be done more carefully.  Sorry!

For my own sanity, is there any chance you have "MAN=PS" defined in
your /etc/mk.conf ?  --I don't understand why xenocara is building
postscript man pages?


You need to understand the work currently being done on ggc3->gcc4 and
mandoc touch just about everything in the tree. It's really difficult
work and I'm sure I don't understand the half of it.

We're at the time in the release cycle where heavy changed are being
made, and it's *REALLY* easy for a `cvs up` from a mirror to miss
important pieces, so the best answer is try to keep with just running
the snapshots.

Unless you're testing patches for someone, or you're actively working on
the code yourself, the best answer for running -current is using the
available snapshots. It's not only easier for you, but it's also easier
for the developers to track down issues since they know exactly what
went into the snap and have a better chance of replicating your problem.

	jcr

-- 
The OpenBSD Journal - http://www.undeadly.org