Mach XFree86 build error - preferred workaround?

[John Dalbec]

Thomas Vander Stichele wrote:

> On Thu, 2004-03-04 at 23:03, John Dalbec wrote:
> 
>>Building XFree86 fails with:
>>
>>egrep: /proc/stat: no such file or directory
> 
> 
> Can you check if proc gets mounted when you go inside the chroot ?
> (I still need a good clean solution for /proc and its contents; mounting
> it is bad, and not mounting it is bad too :))

Yes, it gets mounted when I do "mach chroot" and gets unmounted when I leave the 
chroot.  At least, if I unmount it from the chroot I get error messages when I 
leave the chroot complaining that it's not mounted.  Is mounting it during the 
actual build bad?  I don't see why any pre/post-install scripts would be running 
during the build.
> 
> 
>>This is the offending section of the .spec file:
>>
>>%if %{ParallelBuild}
>>numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 ))
>>[ "$numprocs" = "0" ] && numprocs=1
>>echo "PARALLEL MAKE ENABLED: numprocs=$numprocs"
>>%else
>>numprocs=1
>>%endif
> 
> 
> Hm, that looks wonky.  I wouldn't use code like this.

Well, Red Hat did.  This is the .spec from XFree86-4.1.0-50.src.rpm (RHL 7.2 
update).  I've added a security patch and renamed it to 
XFree86-4.1.0-51.legacy.src.rpm.  Maybe they just never bothered to fix it since 
it didn't break for them.

Actually it looks like numprocs isn't used except for debugging.  Instead the 
following line is preprocessed and inserted into a host.def file if parallel 
building is enabled.  I don't know why they set numprocs to be twice the number 
of processors.  This looks like the number of processes is equal to the number 
of processors.

#define ParallelMakeFlags       -j%(getconf _NPROCESSORS_ONLN)

> 
> Here's what mach uses to check number of cpu's:
>             if not os.environ.has_key('RPM_BUILD_NCPUS'):
>                nrcpus =
> os.popen('/usr/bin/getconf_NPROCESSORS_ONLN').read().rstrip()

I think you left out a space before the first _?  Unfortunately stracing getconf 
shows that it just reads this information from /proc/cpuinfo.  It looks like 
getconf returns 1 if it can't access /proc so maybe that's OK.  Don't you pass 
nrcpus to the rpmbuild command?  How can I access that from the .spec file?

>             else:
>                nrcpus = os.environ['RPM_BUILD_NCPUS']
> 
> also, I don't see the rest of the spec file, so not sure what you're
> trying to achieve there.  But, in general, a spec file should just do
> make %{_smp_flags}

Well, presumably their patch to the X11 sources to allow parallel makes is 
equally wonky.  They added the ParallelBuild flag to be able to turn off 
parallel building when that patch breaks.
> 
> 
>>Is there a mach-compatible way to accomplish the same thing?
>>
>>Should I add /proc/stat as a BuildRequires?

The last build failed (building Glide3) because it couldn't find X11/Xlib.h. 
Should I add XFree86-devel as a BuildRequires or should I try to fix the include 
paths?
> 
> 
> Ugh, no :) I don't think that would work, /proc is not a real
> filesystem.
> 
> 
>>I'm trying various workarounds to be able to access /proc/stat, but it doesn't 
>>help that the build is run as a non-root user.  My latest attempt is to add 
>>"none /proc proc defaults,user 0 0" to /etc/fstab and add the "mount" commands 
>>below:
>>
>>%if %{ParallelBuild}
>>[ -f /proc/stat ] || mount /proc || mount /proc -o remount || :
>>numprocs=$(( $(egrep -c ^cpu[0-9]+ /proc/stat || :) * 2 ))
>>[ "$numprocs" = "0" ] && numprocs=1
>>echo "PARALLEL MAKE ENABLED: numprocs=$numprocs"
>>%else
>>numprocs=1
>>%endif
> 
> 
> that's hacking around the actual problem.  Let's try to fix it in a
> clean way; no spec file should ever try to mount stuff.
> 
> 
>>The remount is because /etc/mtab seems to have mount entries for /proc already.
>>My workaround appears to have worked.  At least the scrolling is much faster 
>>now.
> 
> 
> What do you mean, scrolling is much faster ?

Sorry, I meant the spinner was spinning much faster.  I assume it changes once 
per line of output?
> 
>>Does mach require a terminal? 
> 
> 
> I'm pretty sure that the terminal inside the chroot is not set
> correctly, but I never figured out which I'm supposed to use anyway.  If
> anyone can tell me what TERM should be set to, feel free.  I don't think
> it's a big problem though atm.
> 
> 
>> I tried redirecting stdout and stderr and I still 
>>got status messages printed to the terminal.
> 
> 
> You did this from inside the chroot then ?

No, I did "nohup mach rebuild XFree86-4.1.0-51.legacy.src.rpm > build.log 2>&1 
&" and I still got Mach status messages printed to the terminal (SSH connection).

> 
> 
>>  I've closed my SSH window.  Will 
>>mach wait for TTY output all night instead of building the package?

It looks like the answer to this was no.  I don't see any stopped processes this 
morning.  Of course it didn't get very far.

> 
> 
> Can you give me some more background as to what exactly you're doing ?
> I'm getting the feeling you're using it differently than what I usually
> do.  That's not necessarily bad, I'm just not sure if you're using it in
> a way that I've actually made to work :)

My workstation is in my office.  The box where I'm building the packages is in 
another room with the A/C up too high for comfort.  I connect to the box with 
SSH and issue commands that way.  I'll go in and look at the console if I have 
to but I'm not going to stay there for long.
John
> 
> Thomas
> 
> 
> Dave/Dina : future TV today ! - http://www.davedina.org/
> <-*- thomas (dot) apestaart (dot) org -*->
> Welcome to Hits City, Jeff K - Population: you
> <-*- thomas (at) apestaart (dot) org -*->
> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
> 
> 
>