it seems that the stage3+ target of catalyst no longer supports setting chost via the spec file. i think the idea is that you shouldn't be changing the chost between stage2 and stage3. that's fine. the problem is that chosts that catalyst itself doesn't know about are no longer usable. you can inject your crazy chost name into stage1 and stage2 and they'll get used, but since the stage3 catalyst doesn't *preserve* the chost itself from the input stage (it always clobbers it with whatever value it has hardcoded in its arch modules), you end up changing chost values anyways. this system doesn't work. two possible ways out: - respect chost with stage3+ specs (again) and just warn about changing chosts (thus making it a user problem) - have catalyst detect the CHOST setting from the input stage and then use that instead of always clobbering with its own CHOST setting from the arch .py
find . -type f -exec grep -H -i chost {} \; ./targets/support/chroot-functions.sh: CHOST=$(portageq envvar CHOST) ... ./modules/stage1_target.py: self.valid_values=["chost"] ./modules/stage1_target.py: def override_chost(self): ./modules/stage1_target.py: if self.settings.has_key("chost"): ./modules/stage1_target.py: self.settings["CHOST"]=list_to_string(self.settings["chost"]) ./modules/stage2_target.py: self.valid_values=["chost"] ./modules/stage2_target.py: def override_chost(self): ./modules/stage2_target.py: if self.settings.has_key("chost"): ./modules/stage2_target.py: self.settings["CHOST"]=list_to_string(self.settings["chost"]) So it seems only stage1 and stage2 allow the definition of chost in the spec file (as you said) and that all other targets pick chost from the existing config - which seems to contradict your findings. We'll have to check why stage3+ are not using the existing CHOST definition (the one in the seed stage make.conf).
