Ok, you were right. I didn't realize where the tarballs were stored. Thanks!

Now cfg-update recognizes the 128 or so files that need updating, but I get another problem... when I type 'y' indicating that I would like to update a particular file, cfg-update doesn't open xxdiff. Here's the output I get:

EDIT: SOLUTION
Turns out that it was one of the problems mentioned in the first troubleshooting section, about not being able to connect to x-server. It wasn't giving me any error that indicated that, but when I tried using xxdiff independently of cfg-update, the error became aparent. Whew!!

I've just discovered a little problem with etc-update. Since it sets an alias for emerge in /etc/profile, you won't be able to set enviromental variables for portage anymore.
Things like
USE="something" emerge or
ACCEPT_KEYWORDS="~x86"
won't work anymore (at least with cfg-update-1.5)

I've just discovered a little problem with etc-update. Since it sets an alias
for emerge in /etc/profile, you won't be able to set enviromental variables
for portage anymore.
Things like
USE="something" emerge or
ACCEPT_KEYWORDS="~x86"
won't work anymore (at least with cfg-update-1.5)

I have never noticed that... Thanks for telling me this!

You can temporarily switch off the alias by typing:

Code:

cfg-update --off
source /etc/profile

Then do your emerge with USE flags, and restore the alias afterwards with:

It's really a great job xentric, you've saved me!
My etc-config segfaulted and I wasn't able to update my conf files, but now...
Thanks a lot!_________________~ "Progress is merely a realisation of utopias" ~

Right! I don't know if I ever said this, but now that I got it working, I am very very happy with cfg-update. Updated those 120 or so config files in what seemed like no time at all.

So as for turning the /etc/profiles thing --on and --off... when should you have to do this? Only when you want to declare an ACCEPT_KEYWORDS= or a USE= on the command line during an emerge?? Could it have an effect on anything else??

Yes the problem is only when you are trying to set variables on the command line. I don't think it could have side effects on anything else...

Yes, the problem lies in the use of the alias. It doesn't handle variables
infront of a command. I have not yet encountered any other side-effects
and I don't expect them either.

I really want to thank you guys for the suggestions, support and bugreports!
I'm glad the script does what it was intended to do, making configuration
updates easy...

I do not have lot's of spare time, but I will keep fixing the bugs as soon as
you guys report them and I really hope that the script finally ends up in the
portage tree because updating the "updating-tool" is a pain right now._________________When all else fails, read the manual...
Registered Linux User #340626

I decided to try cfg-update 1.6 for the first time, and it is incredibly slow when it tried to create the index for the first time. It seems the problem is that grep is too slow. I adjusted the code like this:

Another whine. This ebuild is now spending quality time on "Converting old backups to new filename format....". No issues with that, but it is now searching my NFS mounted file systems that have a LOT of files... and it is of course not very fast. Not a very good impression for a first-time install.

I have changed the ebuild and conversion to the new format has to be done
manually now with the script provided in the ebuild... This way new installs and
already converted installs won't waste "quality time"

I don't know how many packages you have on your system, what filesystem you use or what
other factors can make the index-building so slow... The above is a test on my machine, a
Pentium3 850Mhz with Reiserfs. But I didn't notice significant speed changes on my old
Pentium1 233Mhz system.

I don't have time right now to test your patch, but if I look at your tests I think it will make
it into the next ebuild if it's faster on my machine too. Please remember that this is a small
script that has kinda grown out of proportion. It's a hack to make a safer etc-update, but
right now I have very limited time to spend on this project... sorry for that I'm doing what
I can to make it usable and keep it usable!_________________When all else fails, read the manual...
Registered Linux User #340626

Just a note: textutils is now part of coreutils, you should update the ebuild!_________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

Just a note: textutils is now part of coreutils, you should update the ebuild!

Thanks for reporting this. I have updated the ebuild but I have no way
of testing it because my Gentoo system died after loosing the /var partition.
Can someone please test if the new ebuild works without problems?
(see first post, the link to the ebuild points to the updated version)_________________When all else fails, read the manual...
Registered Linux User #340626

We can see that the environmental variable CONFIG_PROTECT is empty.
You can verify this with the 'env' command on the commandline.
As I recall correctly this value is set in /etc/make.globals, just check with
the following command:

As you can see the CONFIG_PROTECT variable is actually set in 3 different
locations on my system...
/etc/csh.env
/etc/make.globals
/etc/profile.env

Maybe your system is missing some of these files!? cfg-update will work
correctly but if that variable isn't set anywhere it probably means that
portage has no protected directories and instead of making a ._cfg0000_
file it will just overwrite the original file without a warning...

or will it be part of "sys-apps/portage", as "etc-update" is
currently?

And when will it be `emerge'able?_________________Your thread resolved? Putting [SOLVED] in its title helps all Gentooers. (Button "edit" , first post)
Prof. Jonathan LF King, Mathematics dept., University of Florida

I have no idea if it will be accepted as I don't get replies on my
mails from the devs... This is the way gentoo bugzilla works:

Quote:

Granted, plenty of ebuilds sit in there and never make it into the tree.
This is not the fault of bugzilla, however. It is more a problem with our
process. Ebuilds make it into the tree when a developer cares about them.
If no developer cares about them, they tend not to make it into the tree.
For right or wrong, that's how things work today.