On 14/05/17 15:56, Stuart Longland wrote: > On 14/05/17 14:23, Joshua Kinard wrote: >> On 05/13/2017 23:54, Stuart Longland wrote: >>> Hi all, >>> >>> I've decided to dust off the old Lemote Yeeloong that I have kicking >>> around for use as a throw-around netbook for on-the-road use. >>> >>> The aim is to have a machine that can do some basic web browsing (using >>> a decent browser, dillo won't cut it), image editing, and maybe some >>> amateur radio stuff (yes, done PSK31 with this beast before, operating >>> as VK4MM, so it does work).
Well, a progress update… I have stage 1 and 2 tarballs built. Yes, that's after nearly a fortnight of compiling… with me putting the build host into hibernate mode since the machine emulates a vacuum cleaner in more ways than one! It has just started the stage 3, then coughed up the following: > Total: 30 packages (28 new, 2 reinstalls), Size of downloads: 8974 KiB > > * Error: circular dependencies: > > (sys-libs/libcap-2.25:0/0::gentoo, ebuild scheduled for merge) depends on > (virtual/pam-0-r1:0/0::gentoo, ebuild scheduled for merge) (buildtime) > (sys-libs/pam-1.3.0:0/0::gentoo, ebuild scheduled for merge) (runtime) > (sys-libs/libcap-2.25:0/0::gentoo, ebuild scheduled for merge) (buildtime) > > It might be possible to break this cycle > by applying the following change: > - sys-libs/pam-1.3.0 (Change USE: -filecaps) > > Note that this change can be reverted, once the package has been installed. > > !!! catalyst: run script failed. > > > Traceback (most recent call last): > File "modules/generic_stage_target.py", line 1244, in run_local > "run script failed.",env=self.env) > File "/usr/lib64/catalyst/modules/catalyst_support.py", line 541, in cmd > raise CatalystError,myexc > CatalystError > None > > !!! catalyst: Stage build aborting due to error. Not sure if anyone else doing stage builds has struck that (haven't seen it on x86 and AMD64). I've just re-started Catalyst, hit ^Z at the appropriate point and chrooted in myself to temporarily merge sys-libs/pam (with USE=-filecaps as suggested) to see if I can work it past that first blocker. (You'd think portage would be smart enough to figure this out itself? Ahh well.) Seems strange though… maybe something is up with the n64 profiles, or maybe something got missed at stage 2. If that's all that goes wrong though, I should have shiny new experimental n64 little-endian stages for people in a week or so. I might also see what's up with SMP support on this VM so I can throw a bit more CPU muscle at the problem. Seems a waste to have 5 host CPU cores doing practically nothing and one getting flogged by a VM when the same host will churn out x86 and AMD64 stages within a day. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
