Emerge operation for dev-java/java-config-2.0.33-r1 fails because of unavailability of jdk-defaults-nocona.conf. Build log attached Reproducible: Always Steps to Reproduce: 1.emerge dev-java/java-config-2.0.33-r1 2.emerge process fails at unavailability of jdk-defaults-nocona.conf 3. Actual Results: cp: cannot stat `config/jdk-defaults-nocona.conf': No such file or directory !!! ERROR: dev-java/java-config-2.0.33-r1 failed. Call stack: ebuild.sh, line 1615: Called dyn_install ebuild.sh, line 1061: Called qa_call 'src_install' ebuild.sh, line 44: Called src_install java-config-2.0.33-r1.ebuild, line 31: Called die !!! arch config not found !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/log/portage/dev-java:java-config-2.0.33-r1:20070531-055630.log'. Expected Results: java-config should be able to find arch config and emerge process end successfully.
Created attachment 120743 [details] Complete build log of the emerge process
Please post emerge --info. My bet is you defined ARCH in your make.conf, possibly told by that infamous ricer guide. portage: is it really useful that portage allows to override this variable? If yes, how bout it's put in info_vars file?
OK I've created pms bug 180419 about it.
Any variable that can be set by make.defaults acn also be set in make.conf, so we can't really prevent that without special hacks. If users are stupid enough to set $ARCH to an incorrect value in make.conf then IMHO they get what they deserve. As for info_vars, this is the first time I've heard about someone setting $ARCH in make.conf (assuming that's true), so unless this happens somewhat regulary I'd rather not spam --info output with it (as generally you can derive it from profile and $USE can also give an indication), and in doubt you can always ask for --verbose --info output.
(In reply to comment #2) > > portage: is it really useful that portage allows to override this variable? If > yes, how bout it's put in info_vars file? > Overriding it is useful for cross compiling. (In reply to comment #4) > As for info_vars, this is the first time I've heard about someone setting $ARCH > in make.conf (assuming that's true), so unless this happens somewhat regulary > I'd rather not spam --info output with it (as generally you can derive it from > profile and $USE can also give an indication), and in doubt you can always ask > for --verbose --info output. > This is not the first time we have had problems with this.
(In reply to comment #2) > My bet is you defined ARCH in your make.conf, possibly told by that infamous > ricer guide. > Yes that was the problem. Thanks for pointing and sorry for being stupid. I always thought that it was just a way to keep make.conf cleaner i.e. you declare a variable once and then use it in 2-3 lines (like cflags, cxxflags etc.). Never knew it could cause problems. I apologise once again for wasting gentoo dev's time.
