Troubleshooting cfg-update..

[xentric]

Now looking at my /var/log/kdm.log I see

Code: Select all

AUDIT: Thu Jan 20 10:35:53 2005: 8672 X: client 18 rejected from local host

Ok, try this:

- reboot the system
- log in X (with kdm or startx) as root
- open konsole..............................(maybe unnecessary)
- run "xhost +localhost"................(maybe unnecessary)
- log out
- log in X (with kdm or startx) as user
- open konsole..............................(maybe unnecessary)
- run "xhost +localhost"................(maybe unnecessary)
- try cfg-update again

[Mattwolf7]

Nope didn't work...

Same error in kdm.log except that it changed from 18 to 17.

Code: Select all

AUDIT: Fri Jan 21 20:06:26 2005: 9946 X: client 17 rejected from local host

Does anyone else have cfg-update working with KDM?

[xentric]

As root run:
$ rm -rf /tmp/*
$ rm -rf /tmp/.*
$ rm /root/.Xauthority

Run as the user who started X:
$ export DISPLAY=localhost:0.0
$ xhost +localhost

Su to root:
$ cfg-update -u

Does that work!?

EDIT: I have found another post about kdm and not being able to run xxdiff with su.
Read it and the posts that follow...
Re-check those files in /root, especially /root/.Xdefaults

[tightcode]

Well it has been a while since my last post in this thread!
This is mixed suggestions to some users and small bugs for version 1.7/1.6 (report).
First of all though, to xentric: Good luck on your exams, I hope you get the First Officer position!

To people having trouble using xxdiff as root or with su/sudo, just:
emerge -pv sux

I think that has been suggested elsewhere in this thread. When I first installed cfg-update I tried without anything and had the same problems I have read here. I then remembered SuSE had a tool called sux which I thought was some SuSE proprietary tool, but no it is in portage and works exactly as expected. Save yourselves the troubles and headaches, emerge sux, and use it instead of su.

Now for the "bugs" of v.1.7/1.6:

Code: Select all

[...]
________________________________________________________________________________

You already have enabled the alias for emerge in /etc/profile !
________________________________________________________________________________

[...]
>>> app-portage/cfg-update-1.7 merged.

 app-portage/cfg-update
    selected: 1.6
   protected: 1.7
     omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.
[...]
>>> Unmerging app-portage/cfg-update-1.6...
No package files given... Grabbing a set.
 * Creating alias for emerge in /etc/profile...
________________________________________________________________________________

Succesfully disabled alias in /etc/profile !
Don't forget to type: source /etc/profile
________________________________________________________________________________

As you can see because of the order in the upgrade 1.7 doesn't touch the alias because it is there, but when 1.6 is removed it comments out the alias because it thinks it is being uninstalled. This is merely a minor annoyance that will only occur to people upgrading but it could cause further bug reports from people not understanding why their checksums weren't being updated since their update. This probably actually now that I think of it surely stems from 1.6 rather htan 1.7, but it may still exist in 1.7.

I reviewed the bug report about pre/postemerge actions and added a coment as well.

I invite everyone reading this to read both of the following bug reports and leave comments if they choose to:
Help cfg-update get into portage (after more than a year): Bug #32728
Remove the need for aliasing emerge: Bug #70704

Please help everyone by going to those two bug reports.

Cheers,

TightCode

[xentric]

To people having trouble using xxdiff as root or with su/sudo, just:
emerge -pv sux

I'll try this out myself, maybe it's easier to recommend this as the
default way to run cfg-update.

Now for the "bugs" of v.1.7/1.6:
As you can see because of the order in the upgrade 1.7 doesn't touch the alias because it is there, but when 1.6 is removed it comments out the alias because it thinks it is being uninstalled.

You are right, when upgrading to 1.7, version 1.6 is being removed after 1.7
is installed. I'll fix this ASAP.

I reviewed the bug report about pre/postemerge actions and added a coment as well.

Thanks for your help!

(I added the invitation to post comments to the cfg-update install page)

[tightcode]

Not a bug Just found this while browsing kde-apps and it "seems" like it has the necessary features to work with cfg-update. I haven't personally used it but perhaps it could be a contestant for one of the frontends that cfg-update could work with ?
It is called KDiff3.
http://kdiff3.sourceforge.net/
http://kdiff3.sourceforge.net/doc/screenshots.html

Hope that is of use to someone

Cheers,

TightCode

[xentric]

http://kdiff3.sourceforge.net/
http://kdiff3.sourceforge.net/doc/screenshots.html

Hope that is of use to someone

Thanks for your input!
I'm working on cfg-update v1.8 and have already included support for kdiff3
in the script and in the ebuild I still have some testing to do but it looks like
v1.8 will have three (or even more) USE flag configurable diff/merge tools.
Gtkdiff, tkdiff and tkdiffb are also "under investigation"...


USE="qt" will make xxdiff a dependency
USE="kde" will make kdiff3 a dependency
USE="gnome" will make meld a dependency
USE="-qt -kde -gnome" can be used for non-X systems

Would these 3 flags be good or are there better choices considering the usage
statistics below?

Code: Select all

Flag   Percent 
------+---------
gtk2   69.68% 
gtk    65.98% 
qt     55.94% 
kde    44.98%
tcltk  43.27%  
gnome  42.28% 

(based on 1405 registered systems and 1288 used USE-flags)
Source: http://www.gentoo-stats.org/index.php?c=usestats

Any suggestions about which flags can be used best!?
Any other requests!?

Edit: I will also look into 3-way merging options for diff/merge tools that support this.

[radfoj]

Hi,
becouse I wasnt delighted with etc-update I decided to try alternatives and found cfg-update. I want give it try so I followed neccessery steps from your original thread in Tips/Tricks and fly by comments here and there.
I wrote this line in my .bashrc, becouse I am lazy again and again typing "xhost +"

Code: Select all

alias su='su -l'

Becouse I havent anything in etc for updating, I tried only start xxdiff under root to be sure, it works.

My question is about this - I know also, that for cfg-update script it must be enabled alias in /etc/profile. I am emerging right now, becouse I changed some USEflags. But if I type during running emerge in second konsole tab for example "emerge -pv something", it build checksum again. IS IT SAFE?
And also I am using such commands often ... and building checksum take me much more that seconds ... so, have anybody some tip, how force it to be executed if really needed?

[xentric]

[quote="radfoj"]

Code: Select all

alias su='su -l'[/quote]You can also use "sux" if you cannot "su" to root... (emerge sux)

[quote]My question is about this - I know also, that for cfg-update script it must be enabled alias in /etc/profile.    I am emerging right now, becouse I changed some USEflags.  But if I type during running emerge in second konsole tab for example "emerge -pv something", it build checksum again. IS IT SAFE?[/quote]IT IS SAFE!!!  The worst thing that can happen is that cfg-update
says you have modified a particular config file, and thus forces you to manually
merge the differences while in fact it isn't modified at all and could have been
auto-updated... [i]this is fail-safe behaviour![/i]

[quote]And also I am using such commands often ...  and building checksum take me much more that seconds ... so, have anybody some tip, how force it to be executed if really needed?[/quote]Well, the thing is that you need to update the index after every emerge otherwise
you get false [modified file] readings!
So if you disable the alias, you'll see that the auto-update will let you merge
manually more often. It will never auto-update modified files though!!!

[count_zero]

I've just updated portage to 2.0.51.20-r5, which leaves two updateable files in /etc:

Code: Select all

-rw-r--r--   1 root    root     831 Apr 27 07:41 ._cfg0000_dispatch-conf.conf
-rw-r--r--   1 root    root     16K Apr 27 07:41 ._cfg0000_make.conf.example

But, when I try to run cfg-udate (version 1.7.1), it gives this output:

Code: Select all

neuromancer etc # cfg-update -u

No (._cfg????_*) files found...

It's always worked before. Is there a problem with the new portage version and cfg-update?

[xentric]

I've just updated portage to 2.0.51.20-r5...
It's always worked before. Is there a problem with the new portage version and cfg-update?

Yes, I have just fixed the problem because Harold told me that the new portage
version 2.0.51.20 doesn't use /etc/make.globals anymore but uses the profiles
from /usr/portage/profiles/ depending on the link /etc/make.profile
As a temporary fix you could replace the following line in the cfg-update script:
(just follow the link /usr/bin/cfg-update to find the script, or edit /usr/bin/cfg-update
itself if it isn't a link...)

Code: Select all

    $_ = `cat /etc/make.globals | grep CONFIG_PROTECT= 2>/dev/null`;

with:

Code: Select all

    $_ = `portageq config_protect 2>/dev/null`;    # query portage for the protected dirs

It's a simple fix, and it will be included in the new 1.7.1 version which will be added
to portage by truedfx as soon as all small issues and bugs are fixed by me (very soon!)

[count_zero]

I've just updated portage to 2.0.51.20-r5...
It's always worked before. Is there a problem with the new portage version and cfg-update?

Yes, I have just fixed the problem because Harold told me that the new portage
version 2.0.51.20 doesn't use /etc/make.globals anymore but uses the profiles
from /usr/portage/profiles/ depending on the link /etc/make.profile
As a temporary fix you could replace the following line in the cfg-update script:
(just follow the link /usr/bin/cfg-update to find the script, or edit /usr/bin/cfg-update
itself if it isn't a link...)

Code: Select all

    $_ = `cat /etc/make.globals | grep CONFIG_PROTECT= 2>/dev/null`;

with:

Code: Select all

    $_ = `portageq config_protect 2>/dev/null`;    # query portage for the protected dirs

It's a simple fix, and it will be included in the new 1.7.1 version which will be added
to portage by truedfx as soon as all small issues and bugs are fixed by me (very soon!)

That did it, thanks!:D
Excellent work, BTW. Congrats on getting it into portage.

[Zentoo]

Hi !

Thanx a lot for cfg-update ! I use it since several month rign now without problem but this morning, i notice a real strange issue. I don't know if we could tell that's a bug or not but i think it's fair to notice it.

My /var partition were almost full and i used eupdate, few seconds later, my box doesn't respond anymore...
So i've stop it and check with htop what's going on. In fact, if /var is full, the perl script start to use more and more memory until swap is used so much that my box start to freeze.

So i think that could be great to check if there is enough free space on /var before that happens because that could be really annoying in case of distant use by ssh... And it's always good to know that a partition is nearly full when u use a tool that need fs space instead have a so strange behaviour.

BTW, i really wonder what's is going on with perl to consume so much memory instead try to use disk space.

Hope that could help to build a rock solid cfg-update

[xentric]

Sure, I can build a diskspace check into the script, but I believe
that this is far beyond the scope of the script! Building this check
into cfg-update, so it refuses to run when there's not sufficient
diskspace, probably wouldn't solve the problem. I guess it would
lockup just as fast during the check itself if perl is causing this
excessive memory usage.

The sysadmin should check the system regularly to make sure
that there's enough diskspace, possibly with a cronjob that checks
it for you on a regular basis.

Was your computer swapping heavily right before it locked up?
Running out of memory and swapspace is usually the cause for a
lockup like that. Simply running out of space on /var should not
be a big problem. But you'd get some weird stuff like this.

But thanks for telling me. I'll keep my eyes open for bugs related
to this issue.

[tightcode]

It again has been a while since I have written here, my apologies.
I am glad to see this finally made portage after so much work trying to get it noticed on bugzilla!

After reading the changelog I realized why it is taking "SO LONG" to update on every emerge now.
As this has actually become annoying, I have pondered a solution.
In your emerge_with_indexing_for_cfg-update script, could you filter the flags being sent to emerge and not run the update if the flags contain for example:
--sync
-p

Neither of those modifies config files so neither should require running an update. I often run -pv to verify what needs what dependencies and to get other information. Having to wait so long for cfg-update's index on each one of those is becoming tedious. Could you perhaps build a check in as outlined above ? That would make a great improvement.

Noneoftheless, cfg-update is still wonderful, thanks for all the past improvements as well.

Cheers, TightCode

[xentric]

In your emerge_with_indexing_for_cfg-update script, could you filter the flags being sent to emerge and not run the update if the flags contain for example:
--sync
-p
Neither of those modifies config files so neither should require running an update.

You are right, there should be a filter for these flags... I'm not a bash/shellscript guru so if anyone has ideas on how to approach filtering on the emerge command flags it would be greatly appreciated!
Anyway, I'll keep my eyes and ears open while looking for a solution.

[tightcode]

I am not much of a bash guru either but I do write a considerable amount of PHP so here is my working solution:

Code: Select all

Modified "emerge_with_indexing_for_cfg-update" script, Updated because of pasting error 2005-09-22 03:11 GMT+1:
#!/bin/bash
# This is a bash wrapper for GD/tightcodes php script and the original wrapper to emerge
if [ -e "/usr/bin/php" ]; then                                  # If PHP is present be smart about indexing
        if [ -e "/usr/bin/emerge_with_indexing_for_cfg-update_phphelper" ]; then        # Verify first that the php script is present
                emerge_with_indexing_for_cfg-update_phphelper $*
        else                                                    # If php is present but the script isn't, warn the user as indexing isn't taking place
                echo -e ">>> \e[1mcfg-update:\e[0m \e[31mCouldn't find emerge_with_indexing_for_cfg-update_phphelper.\e[0m Please install it"
        fi
else if [ -e "/usr/bin/cfg-update" ]; then                      # PHP isn't present so default to old behaviour
        cfg-update --index
else                                                            # cfg-update appears to have been incorrectly uninstalled, leaving the alias
        echo -e ">>> \e[1mcfg-update:\e[0m \e[31mCouldn't find cfg-update.\e[0m If you meant to uninstall it, please disable the alias for emerge in /etc/profile !"
fi
fi
# Regardless of result, now run emerge.
emerge $*

That first checks if the user has PHP before using the smart indexing, then if the user does have PHP it checks to make sure they have the php helper script and only then, does it run the following:

(Because of the length, I have posted the php script at the following location:)
http://pub.sytes.net/emerge_with_indexi ... _phphelper updated: 2005-09-21 15:45 GMT+1

The basic functionality of that takes the blacklisted shortform flags and longform flags and searches through the ones used when calling emerge, if any match it doesn't re-index.
I define blacklisted flags as those, which when used, will not allow the merging of any packages, thus not requiring indexing. I probably didn't specify all of them but I was doing the list quickly. If you wish for additional ones to be added just let me know so I can keep the script updated in a central location.

To install it, place it in the /usr/bin directory with emerge_with_indexing_for_cfg-update. If you wish to rename it, remember to also rename the call in the updated version of emerge_with_indexing_for_cfg-update_phphelper included inside this post.

If anyone wishes to port that to bash or perl be my guest. As it stands it can be included with cfg-update as it is only run if the user has php and otherwise defaults to current functionality.
If for some reason you can't reach the script, send a private message my direction. If you have any comments which involve large pasting of the script do those via PM as well or by linking to the code in question to keep from polluting this thread please.

Feel free to send comments and suggestions.

Cheers, TightCode

[xentric]

Wow, that's a quick fix
I'm going to try to make this work in pure bash on sunday... until the next release users can use your php solution. Version 1.8.0 is almost done, I hope to include a pure bash solution in the next ebuild. If I can't get it to work with bash-only, I will try to port your solution to perl.

[tightcode]

Alright, just so you know I have that working on 3 machines right now and just copied it over as a drop in replacement. I don't think there is any harm in including it in the next release (until you have an alternate solution) because the file that replaces your bash file, which remains bash, keeps your functionality unless php and the php file are present. Also it ties the "look" and coloring of the messages in with the rest of the emerge messages clearly identifying what is saying what (you can duplicate this of course easily in your 100% bash or perl solution).

If you don't mind test to see if it works for you as all 3 of my machines have similar php configurations so it may not mean much that it works on all three. I wrote it in such a way as to hopefully have no possible problems due to version/configuration, but it doesn't hurt to check.

Cheers, Tightcode

Post Scriptum: If it works for you, feel free to repost it in the install thread. Not sure anyone really looks in this one

[xentric]

If it works for you, feel free to repost it in the install thread. Not sure anyone really looks in this one

I've added it to the install page. Thanks a lot!

[Anakha_]

I am not much of a bash guru either but I do write a considerable amount of PHP so here is my working solution:

Code: Select all

Modified "emerge_with_indexing_for_cfg-update" script, Updated because of pasting error 2005-09-22 03:11 GMT+1:
<snip>

The basic functionality of that takes the blacklisted shortform flags and longform flags and searches through the ones used when calling emerge, if any match it doesn't re-index.
I define blacklisted flags as those, which when used, will not allow the merging of any packages, thus not requiring indexing. <snip>

i notice you have the --columns option in there, which, strictly speaking, does allow merging packages if used by itself, so you may consider removing it.

nice work!

/wave

[stelica]

Here is a bash only solution I've haked for myself, since I am not a bloatHP fan

Code: Select all

#!/bin/bash
if [ -e "/usr/bin/cfg-update" ]; then  # test to see if /usr/bin/cfg-update exists and then update the index if necessary
        long_args=(help info metadata sync search changelog fetchonly fetch-all-uri pretend searchdesc version)
        short_args=(h s l f p S V)
        break=0
        for arg in $*; do
                # echo $arg
                if [ "${arg:0:1}" = "-" ]; then
                        if [ "${arg:1:1}" = '-' ]; then # long arg
                                for s in ${long_args[*]}; do
                                        if [ "$s" == "${arg:2}" ]; then
                                                break='1'
                                        fi
                                done
                        else # short arg
                                for ((i=1;i<${#arg};i++)); do
                                        for s in ${short_args[*]}; do
                                                if [ "$s" == "${arg:$i:1}" ]; then
                                                        break='1'
                                                fi
                                        done
                                done
                        fi
                fi
                if [ $break == '1' ]; then
                        break
                fi
        done
        if [ $break == '0' ]; then
                cfg-update --index
        else
                echo "cfg-update indexing skiped."
        fi

else  # warn the user that he/she still has an alias for emerge
    echo "*** cfg-update not found, disable the alias for emerge in /etc/profile !"
fi
emerge $* # run emerge whatever the case may be...

[xentric]

Here is a bash only solution I've haked for myself, since I am not a bloatHP fan

I've added this post to the installation post as an post-installation tip.
Thanks stelica!

Maybe I should mention that I'm almost finished with version 1.8.0 which
will hit the mirrors hopefully before the 31st of december...
I'm currently re-writing documentation and the manpage now (because I
completely changed the way updates are handled) and only have to write
a piece of code that will move the alias from /etc/profile to /root/.bash_profile.

The new version handles the index-checksum updating a bit smarter,
which probably means that these wrappers aren't necessary anymore.

And it will also support safe automatic 3-way merging of files that have been
updated before the current config file, the ._cfg0000_file and the backup of
the previous ._cfg0000_file (which is used as the ancestor/base file)...

However, I just got another idea...
Maybe I can extract the original config files from the ebuilds. That would mean
that we can do (automatic) 3-way merges on all modified files in the protected
directories
Hmmm... that would be a nice feature for version 1.8.1

I'm also planning to add support for updating remote machines in 1.8.1, so you
can maintain clusters of machines from a single location. (even if the remotes
have different configurations)

Well, won't bore you guys with my ramblings any longer... Thanks for your support!

[radfoj]

Hi,

thanks for new version, I am giving a try. In the first place I am missing /etc/cfg-update.conf. Do I have to create it by myself? And which syntax should I use?

Thanks

UPDATE - (just cosmetics)
This doesnt look good - the lines here and there.

Code: Select all

______________________________________________________________________

cfg-update 1.8.0 : Building checksum index...______________________________________________________________________

 (takes a few seconds)  done!
______________________________________________________________________

One up and one down is enough or not

[rickj]

My weekly update stalled with:

Code: Select all

triffid rick # emerge -Dua world

These are the packages that I would merge, in order:

Calculating world dependencies /
emerge: there are no ebuilds to satisfy ">=sys-apps/textutils-2.0".
(dependency required by "app-portage/cfg-update-1.6" [ebuild])

!!! Problem resolving dependencies for app-portage/cfg-update
!!! Depgraph creation failed.
triffid rick #  

Acccording to the post at
http://forums.gentoo.org/viewtopic-t-42 ... utils.html
textutils are replaced by coreutils. Unmerging textutils does not remove the bug.

Does anyone have any suggestions?