Updating to GCC 3.4/4? Want to use 2006.1 profile? READ THIS

Message

billydv · Post by **billydv** » Mon Jul 09, 2007 6:46 pm

Okay Guenther, let me understand something, I see that the script, recompile-remaining-packages actually has the list in it, what if I was to delete a few of the entries, for a few games that require a yes or something, Will it mess up the script as the numbers will not be in order, or to more accurately say there would be missing numbers?

Moonlight-Flower · Post by **Moonlight-Flower** » Fri Oct 26, 2007 2:38 pm

I started using this script on someone's suggestion, since I was having trouble after the libexpat upgrade. The script runs fine until it tries to recompile xterm, whereupon it stops at a line running /bin/sh ./minstall.sh for a file called xterm.man. It just stops. No CPU usage, hard disk doesn't do anything, the rest of the computer is completely unaffected (I can open other programs, play games, listen to music).

If I cancel the script and run "emerge xterm" on its own, xterm emerges perfectly, without any problems.

Did I make some mistake running the script, or is there some strange glitch involved?

billydv · Post by **billydv** » Sat Oct 27, 2007 1:20 pm

Open the script and delete the line with xterm. Then running the script wont call xterm to emerge, you can also do this to delete anything you dont want reemerged like games that require a yes and an enter or other packages emerged with special instructions.

Guenther Brunthaler · Post by **Guenther Brunthaler** » Tue Oct 30, 2007 3:50 am

Hi billydv,

billydv wrote:if I was to delete a few of the entries, for a few games that require a yes or something, Will it mess up the script as the numbers will not be in order, or to more accurately say there would be missing numbers?

No, there should not be a problem if some numbers are missing.

The script just remembers the number of the last package which has successfully been compiled, and skips all entries with lower numbers when re-examining the list for the next time.

This means the only thing important is that the numbers are increasing, but the specific values are not important.

Guenther Brunthaler · Post by **Guenther Brunthaler** » Tue Oct 30, 2007 4:16 am

billydv wrote:Guenther, it would be great if you could modify the script to answer yes whenever something required input

Well, perhaps. But it's somewhat dangerous answering "yes" to unknown prompts.

Just imagine some module prompting

Code: Select all

Do you want to initialize a device for database extents now? yes
Shall I auto-detect a device of sufficient size? yes
Checking... /dev/hda is sufficient! Use it? yes
Are you sure (All Data on /dev/hda will be destroyed)? yes
Are you really sure? yes
This is your last chance to quit - are you REALLY really sure? yes

You wanted it so!

Initializing ... 10 % ... 20 % ... 30 % ...

Kernel Panic: Corrupted superblock on root device!

Besides, I have no idea how to detect whether an emerge requires input to be provided via stdin. At least not from a shell script like this. I suppose I would have to use something like expect for this - but that's TCL stuff (which I'm not experienced with).

Guenther Brunthaler · Post by **Guenther Brunthaler** » Tue Oct 30, 2007 4:35 am

billydv wrote:Heres my list, How long do you think this will take?

It may take days or week, depending how fast your system is.

In general, it is impossible to say. There are just too many factors involved: What processor do you have? How much free RAM? How fast is your disk? Are your filesystems heavily fragmented? Are you running other applications while recompiling?

I have about 1300 total packages installed, and it took about a week for my script to finish on my Athlon 1.3 GHz machine.

billydv · Post by **billydv** » Tue Oct 30, 2007 6:53 am

After having used your script several times, not only for reinstalling everything but if I have alot of packages that I want to reinstall I can be sure that a failed emerge wont stop it all, I simply add in the packages to generated script of yours, and its certainly simple enough to delete any package lines you dont want rememerged. All in all, great script,
BTW my athlon x2 4200 does approximately 2200 packages in 3 days or less.

Guenther Brunthaler · Post by **Guenther Brunthaler** » Tue Oct 30, 2007 5:10 pm

Hi billydv,

billydv wrote:I simply add in the packages to generated script of yours

Glad to see it is useful to you even beyond its primary purpose!

Actually, I have a modified version of the script which has additional command line options which allow to specify a list of packages, and the script uses them for the package list instead of obtaining it from "emerge -pe world".

Unfortunately the help text is not yet up to date, so I did not post it yet.

But I guess I'll fix the help text in the next couple of days and will then post a new version.

billydv wrote:BTW my athlon x2 4200 does approximately 2200 packages in 3 days or less.

Seems it's about time for me to consider purchasing a new box

But I'm still waiting for the quad-core prices to drop.

And I would also like to get a CPU with more than the usual 48 Bit virtual address space. After all, it's a 64 bit CPU and not a 48 bit CPU!

billydv · Post by **billydv** » Tue Oct 30, 2007 8:30 pm

Although I have numerous boxes which I use to test various linux distros, the x2 4200's of which I have two are the best I have, they blow away even an fx57 that I also have. My next build will be an intel quad core and Im waiting for prices to drop on that too!!!

thekk · Post by **thekk** » Wed Feb 20, 2008 9:04 pm

Guenther Brunthaler wrote:If you just do a "emerge -e world", you will eventually find yourself with a recompiled system where about 75 packages have been linked against the old version of glibc ... see http://forums.gentoo.org/viewtopic.php? ... 09#3552919 for more of this.

So, if you want to be "100 % sure", "emerge -e world" won't provide you with what you want.

My script does the same as an "emerge -e world", only in the correct order for recompiling a system.

Also note that dispite of this, "emerge -e world" is neither flawed nor broken! It's just not intended to be used for recompiling the whole system, but for rebuilding a non-existent system from scratch. Which is not the same!

My script, in contrary, has been designed for recompiling your entire system.

So it does a similar, but not the same job.

I don't know if this has been suggested before in this thread, but I think it would be awesome if the ordering of the packages would end up in the default portage/emerge toolkit. Using your analogy before, it would probably require a new switch. Though I'm puzzled whether it would hurt to order the packages the right way when using the -e switch.

Phoenix591 · Post by **Phoenix591** » Sat Feb 23, 2008 12:07 am

why'd this 2 year old (ok, the last post was 4 months ago, but still) thread get dug up? (no resurrecting/posting in old, long silent threads) plz)

billydv · Post by **billydv** » Mon Jan 12, 2009 7:59 pm

Gunther, I love your script and have used it every few months to keep my system up to date but unfortunately your script no longer works. It says that it dies at line 352. Any chance for an update?

dalek · Post by **dalek** » Sat Apr 18, 2009 5:11 am

billydv wrote:Gunther, I love your script and have used it every few months to keep my system up to date but unfortunately your script no longer works. It says that it dies at line 352. Any chance for an update?

I to would like a update. Here is a work around, sort of. Run the script and when it generates this list of packages, contained in recompile-remaining-packages, then copy the list and create a package set. You know, the @set thingy. You will have to remove all the weird parts on each line which can take some time but it should work. Just emerge @<set name> and let it run.

I do wish this script could be updated tho. It comes in handy on occasion. I just wonder why portage doesn't use the same method?

billydv · Post by **billydv** » Mon Apr 20, 2009 4:54 pm

For whatever reason it once again works!! I love this script!!

dalek · Post by **dalek** » Mon Apr 20, 2009 5:17 pm

It is working here as well, so far anyway.

Code: Select all

root@smoker / # cat /root/.recompile-remaining-packages.state
1.13
i686-pc-linux-gnu-4.1.2
599 597 2
root@smoker / #

Maybe it doesn't need upgrading? There are about 800 packages on here.

billydv · Post by **billydv** » Mon Apr 20, 2009 7:16 pm

I have 2500 packages!!

dalek · Post by **dalek** » Mon Apr 20, 2009 8:26 pm

billydv wrote:I have 2500 packages!!

HOLY CRAP !!!

billydv · Post by **billydv** » Sat Sep 04, 2010 9:48 am

Just wanted to say that I used this script again this week and it still works great!!!!

Simba7 · Post by **Simba7** » Sat Nov 20, 2010 9:19 pm

Holy crap, Batman! Digging up a 4 year old thread?

Not to mention, who the hell uses the old 2006.1 profile anyway? I ditched that 3 1/2 years ago. Is there *ANY* benefit from using it vs. the latest ones? I don't see any on my end (besides willingly giving yourself a massive migraine).

dalek · Post by **dalek** » Sat Nov 20, 2010 10:40 pm

Simba7 wrote:Holy crap, Batman! Digging up a 4 year old thread?

Not to mention, who the hell uses the old 2006.1 profile anyway? I ditched that 3 1/2 years ago. Is there *ANY* benefit from using it vs. the latest ones? I don't see any on my end (besides willingly giving yourself a massive migraine).

I'm using the latest profile and the script still works. It's not about the profile, it's about the script. The person posted because they used the script and it worked so they posted that it worked.

billydv · Post by **billydv** » Sun Nov 21, 2010 9:30 am

Yes, Indeed the script still works. I just used it last week when I upgraded my box to a quad core amd with new c flags.

anonybosh · Post by **anonybosh** » Mon Feb 21, 2011 8:36 pm

I have used this script quite a few times to date, thanks Guenther!
However, I just noticed a bug:
When using color output (specifically when set globally in the make.conf: EMERGE_DEFAULT_OPTS=" --color y") the recompile-remaining-packages script that is generated includes the color codes around each package name. For some reason, the end of the color tag is interpreted as an 's', and so all package names become invalid when emerge is run.
An easy workaround is of course to just disable color output during the use of the base script.