Well this is truely bizaar
When I try to emsource -b --build-dep gnupg normally I get a
problem complaining that it can work out the sizeof(uint64_t).
Actually the problem is something to do with sys/types.h where
it defines mode_t.
So I came across a reference through google to odd behaviour
if I ran out of memory, and as the machine it is running on only
has 128MB usable memory (it actually has 256, but 128 of that is
taken up with screen buffer) I thought I would try adding some more
memory.
So I added some, and in the process forgot when I booted to use
an old kernel what had madwifi built for it, and so used one that had
no network connectivity.
It compiled cleanly, well nearly, it failed near the end with a problem
to do with udebs, but it got cleanly through the configure, and kept
going until it tried to so a dpkg-gencontrol on gpgv-udeb which is
"not in control".
So I built madwifi for the later kernel, just in case it was just the memory
increase that had cured things, but it still failed. So I stopped the
wifi connection and unloaded the madwifi modules, and it worked!!!
Still the same udeb problem, but the configure worked.
Does anyone have any idea why building this offline and building it
online should be different?
It would seem that there was a similar problem on ARM last year,
does anyone recall what was done to fix that?
David
Reply to: