I was trying to update my box, and eselect-compiler failed because there were no profiles. Not liking re-emerging gcc, but willing to go forward, I tried - but eselect-compiler being a dep makes it tough to get past this... emerge -av --oneshot sys-devel/gcc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-admin/eselect-compiler-2.0.0_rc2-r1 USE="-hardened" 0 kB [2] [ebuild NS ] sys-devel/gcc-3.4.6-r1 USE="fortran gcj gtk -bootstrap -boundschecking -build -doc -hardened -ip28 -ip32r10k -multislot -nls -nocxx -nopie -nossp -objc -vanilla" 27,694 kB [2] Total size of downloads: 27,694 kB Portage overlays: [1] /home/mcumming/projects/overlay/experimental [2] /home/mcumming/projects/overlay/gentoo-x86 Would you like to merge these packages? [Yes/No] >>> Emerging (1 of 2) app-admin/eselect-compiler-2.0.0_rc2-r1 to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking eselect-compiler-2.0.0_rc2.tar.gz ;-) grep: //etc/eselect/compiler/*.conf: No such file or directory grep: //etc/eselect/compiler/*.conf: No such file or directory grep: //etc/eselect/compiler/*.conf: No such file or directory grep: //etc/eselect/compiler/*.conf: No such file or directory * We weren't able to find a valid eselect compiler profile for default. * Please do the following to re-emerge gcc, then retry emerging * eselect-compiler: * # emerge -v --oneshot sys-devel/gcc !!! ERROR: app-admin/eselect-compiler-2.0.0_rc2-r1 failed. Call stack: ebuild.sh, line 1561: Called dyn_setup ebuild.sh, line 668: Called pkg_setup eselect-compiler-2.0.0_rc2-r1.ebuild, line 32: Called die
I'd love this thing to go back to p.mask, would save tens of pointless bugs.
Masking it again solves nothing, other than preventing bugs being found. None of the bugs found since the unmasking would have been found if it had remained p.masked, since they obviously didn't trigger for few who were using it. Calling such bugs pointless is ridiculous, since without them how are the bugs to be found and fixed? After all it was p.masked for the best part of a year without any of them being raised. This is what unstable marking is for; essentially functional but may have bugs in certain circumstances, especially those unforseen by the author. This is undoubtedly more severe with the compiler wrapper than it is with a limited application, but how else is progress to be made? Unstable means it might not work. If you can't deal with the problems caused, raising a bug and falling back to stable is simple enough.
(In reply to comment #2) > Masking it again solves nothing, other than preventing bugs being found. Sure, but you usually unmask something that you are relatively sure wont screw a lot of users - especially something so critical in a distro like Gentoo. > None of the bugs found since the unmasking would have been found if it had remained > p.masked, since they obviously didn't trigger for few who were using it. Right, but on the other hand I would have thought it a given that something so critical was asked to be tested first before unmasking - then most of the severe bugs would have been discovered. I do not see any requests for testing after the initial announcement of development, or the actual unmasking of the beast. > Calling such bugs pointless is ridiculous, since without them how are the bugs > to be found and fixed? After all it was p.masked for the best part of a year > without any of them being raised. This is what unstable marking is for; > essentially functional but may have bugs in certain circumstances, especially > those unforseen by the author. This is undoubtedly more severe with the > compiler wrapper than it is with a limited application, but how else is > progress to be made? Unstable means it might not work. If you can't deal with > the problems caused, raising a bug and falling back to stable is simple enough. > Personally I think this whole thing is immature. No, it is not bad grapes, as if you check the older gcc-config's ChangeLog, it was for the last while handled all by Mike (one of the reasons I rather shutup about this whole thing, as nobody else in toolchain ever say anything, so now it seems like me whining when I try to confront anything about it). And I did admit from the start that it have some issues, and some thinko's on say x-compiling, etc, so really some much needed thinking, discussing, and redesign should have been done - I must say, I do not see much of that here. The thing though is that the 'unstable tree' should not be seen as a playground for developers. We have many users who run unstable, and will be put off if critical pieces starts breaking. Sure, its for things that developers expect to need more testing, but it should at least have been given more wider testing while package masked.
Well, to be honest I had a couple of issues with gcc-config, but while they were dealt with in a way that suited Mike, those resolutions didn't help me (in particular, lack of specs configuration in the config files, and more broadly the reliance on the shell environment for configuration rather than config files). The point is that gcc-config isn't going to satisfy everyone, and select-compiler won't either. Perhaps it would be a good idea to supply the compiler switcher via a virtual. That way Mike can continue with gcc-config the way he wants it, Jeremy can take eselect-compiler in the direction he wants to, and if any of us don't like either it's easy to supply our own. Obviously some agreement has to be reached for issues where ebuilds need to specify something about the compiler, but these aren't numerous (wine is the only package that isn't compatible with both that I can think of). I had assumed the various stakeholders had discussed the issues surrounding the compiler switcher. Certainly such a discussion would be useful if it hasn't occurred. Incidentally I'd like to know why the upstream '-V' and '-b' options are't used; they seem to be intended to support multiple versions and multiple targets.
recommendations? do i need to downgrade gcc-config? (shooting in the dark)
For users that fall upon this bug (which has hit me again on another box) - install the oldest copy of the eselect-compiler, which will give the same error and then *continue*; then run eslect compiler migrate. at that point you will have a working compiler again.
*** Bug 139830 has been marked as a duplicate of this bug. ***
This also causes bootstrapping to fail; raising severity in line with bug #139830: "bootstrapping non-root path fails in ~x86 with error from eselect-compiler build"
*** Bug 139963 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > For users that fall upon this bug (which has hit me again on another box) - > install the oldest copy of the eselect-compiler, which will give the same error > and then *continue*; then run eslect compiler migrate. at that point you will > have a working compiler again. > Sorry for this "unprofessional" question but...which is the oldest version and how do I specify that I want to install that one in the emerge command.
(In reply to comment #10) > Sorry for this "unprofessional" question but...which is the oldest version and > how do I specify that I want to install that one in the emerge command. emerge =app-admin/eselect-compiler-2.0.0_rc1-r6
The problem stays even if i emerge an earlier version of eselect-compiler. After issueing the "emerge =app-admin/eselect-compiler-2.0.0_rc1-r6" command the error message doesn't dissapear and he doesn't continue. >>> checking compiler-config-2.0.0_rc1.tar.gz ;-) grep: //etc/eselect/compiler/*.conf: No such file or directory grep: //etc/eselect/compiler/*.conf: No such file or directory grep: //etc/eselect/compiler/*.conf: No such file or directory grep: //etc/eselect/compiler/*.conf: No such file or directory * We weren't able to find a valid eselect compiler profile for sparc32. * Please do the following to re-emerge gcc, then retry emerging * eselect-compiler: * # emerge -v --oneshot sys-devel/gcc !!! ERROR: app-admin/eselect-compiler-2.0.0_rc1-r6 failed. Call stack: ebuild.sh, line 1561: Called dyn_setup ebuild.sh, line 668: Called pkg_setup eselect-compiler-2.0.0_rc1-r6.ebuild, line 36: Called die !!! Missing eselect-compiler profile for sparc32
Created attachment 91464 [details] Don't die on bootstrap; don't die if first-time eselect-compiler install You're right. It needs to be older than the versions currently in portage. Try this modified ebuild, which should deal with the first-time install problem and the bootstrap problem.
(In reply to comment #13) > Created an attachment (id=91464) [edit] > Don't die on bootstrap; don't die if first-time eselect-compiler install > > You're right. It needs to be older than the versions currently in portage. > > Try this modified ebuild, which should deal with the first-time install problem > and the bootstrap problem. > I think you left part of the new ebuild/patch out. Here is what happened for me: >>> Emerging (12 of 18) app-admin/eselect-compiler-2.0.0_rc2-r1 to /mnt/external/ >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking eselect-compiler-2.0.0_rc2.tar.gz ;-) >>> Unpacking source... >>> Unpacking eselect-compiler-2.0.0_rc2.tar.gz to /var/tmp/portage/eselect-compiler-2.0.0_rc2-r1/work * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/app-admin/eselect-compiler/files/eselect-compiler-2.0.0_rc2-bug135688.patch * ( eselect-compiler-2.0.0_rc2-bug135688.patch ) !!! ERROR: app-admin/eselect-compiler-2.0.0_rc2-r1 failed. Call stack: ebuild.sh, line 1545: Called dyn_unpack ebuild.sh, line 711: Called src_unpack eselect-compiler-2.0.0_rc2-r1.ebuild, line 131: Called epatch '/usr/local/portage/app-admin/eselect-compiler/files/eselect-compiler-2.0.0_rc2-bug135688.patch' eutils.eclass, line 192: Called die !!! Cannot find $EPATCH_SOURCE! !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/local/portage'
Actually, it did appear to work. I just didn't realize I needed to copy the file from portage into my overlay. Anyhow, eselect-compiler did install. I'll report if the compiler installs fine.
Bootstrapping a blank partition appears to have worked.
ok; I've committed this fix to eselect-compiler-2.0.0_rc2-r1 - decided against a rev-bump since the problem is with installing -r1 (those of you who put -r2 in overlay you can remove it - portage will ask to downgrade to -r1 but you can let that happen, it won't actually change anything). Leaving the bug open so Jeremy can decide whether the fix is actually what he wants or not.
Haha finally got it emerging. First i did a "emerge-webrsync" and then "emerge =eselect-compiler-2.0.0_rc1-r6", and it installed just fine. It still warns me about my profiles not existing tough, should i worry?
(In reply to comment #18) > should i worry? No :) If should have created profiles for your existing compilers when you emerge it (so that 'eselect compiler list' should show something). If not, try: # eselect compiler migrate
(In reply to comment #19) > No :) If should have created profiles for your existing compilers when you > emerge it (so that 'eselect compiler list' should show something). If not, > try: > > # eselect compiler migrate I was already ahead and issued the command "eselect compiler migrate" because at the end of the eselect-compiler merge he advised me to do this, which allowed me to SUCCESSFULLY upgrade the eselect-compiler from 2.0.0-rc1-r6 to 2.0.0-rc2-r1 and, more important, finally upgrade my gcc from 3.3 to 3.4.6. I'm now finishing the gentoo GCC upgrade guide and so far no more errors.
This is getting a problem on Gentoo/FreeBSD stage building, any news on this?
(In reply to comment #21) > This is getting a problem on Gentoo/FreeBSD stage building, any news on this? I committed a fix to the tree (see c#17) - didn't do a rev-bump on the understanding it only affects people doing new installs. Try re-emerging eselect-compiler and see if that's enough for you - if not, post back here of course.
That if condition there is not correct. It will only have selection.conf if eselect-compiler has been installed on the system before. Should we use IUSE=build instead? I forget which is the correct flag bootstrap/build.
eselect-compiler is dead for the time being
"and there was much rejoicing."
