On Mon, May 13, 2013 13:43, Dale wrote: > J. Roeleveld wrote: >> I try to keep the USE-flags out of make.conf as much as possible. >> Some packages have "multislot" where I don't necessarily want it >> enabled. > > It turned into a USE flag nightmare so I used package.use. Sometimes it > just don't work out since a few packages gets into a world class > wrestling match. I usually try but don't sweat it.
My make.conf USE-variable is really small, it's all in package.use/... :) >> Well, after waiting for it to finish, I get this now: >> >> root@fireball / # genlop -c >> >> Currently merging 4 out of 4 >> >> * sys-devel/gcc-4.4.7 >> >> current merge time: 6 minutes and 57 seconds. >> ETA: 17 minutes and 2 seconds. >> >> Currently merging 4 out of 4 >> >> * sys-devel/gcc-4.4.7 >> >> current merge time: 6 minutes and 58 seconds. >> ETA: 17 minutes and 1 second. >> root@fireball / # >> >> So there it is compiling the same package version twice, again. Going >> to kill it since it will sit there and compile for hours if I don't. I >> also found out I am not the only one having issues doing a ctrl c to >> stop emerge too. They need some Raid on that problem. >> >> Open to new ideas. >> Just a quick question, are you certain it is doing both simultaneously? >> It could also be a bug in genlop? >> >> I always generate the binary packages, which means I don't actually need >> to keep older GCC-versions. I can always unpack the package using "tar" >> :) >> >> -- >> Joost >> >> >> > > I have it set to save a tarball here but I'd have to look up how to > rescue myself if I did screw up. To rescue yourself using a binpackage: # cd / # tar -xvjpf <...path-to-binpackage-including-package...> After that, I would suggest a "emerge -vek world" :) > To answer your question, I decided to > just let the stupid thing sit there and compile. After a while, I got > this: > > root@fireball / # genlop -c > > Currently merging 4 out of 4 > > * sys-devel/gcc-4.4.7 > > current merge time: 25 minutes and 17 seconds. > ETA: any time now. > root@fireball / # > > So, one of the compiles finished. That is a improvement at least. I > just checked again and it is finished with them all and I got this for > the end of emerge: > > Total: 4 packages (1 upgrade, 3 reinstalls), Size of downloads: 24 kB > > Would you like to merge these packages? [Yes/No] y <SNIPPED> > I'm going to say this tho, it did not have time to compile the last gcc > even tho I'm sure it did. Your mention of a genlop error may be right. > I bet genlop is reporting the wrong version on one of them somehow. I wonder if "genlop" is noticing there are 2 GCC-compiles running, but picks the most current version for both, rather then the correct version for each emerge? > To add this in case I didn't mention it. One time before, gcc compiled > for like 5 or 6 hours while I took a nap. I can compile LOo several > times in that time frame. Gcc never takes more than 30 minutes or so, > usually around 20 or so. That depends on the USE-flags, I think. GCC on my old system always took a while, new systems (with also new versions) seem to be a lot faster. Thing is, I tend to build packages for all the machines in a single VM and then install those when I have a current set. That VM tends to be started and then I just leave it till I come back from work the next day. > I have a 4 core CPU running at I think 3.2Ghz > and 16Gbs of ram with portages work directory on tmpfs. > > This is weird. May look into a genlop change, up to a unstable one or > back to a older version. See if that helps. Got to figure out how to > force a upgrade tho. ;-) > > Thanks. At least I seem to have a clean upgrade now. You might already had :) -- Joost
