after every update of app-admin/sudo and the following cfg-update run, the permissions of /etc/sudoers have changed from 0440 to 0644 so that the next time sudo is used it refuses to run, complaining about wrong permissions. I've verified that the permission change doesn't come from the installation/update of the package, but indeed from cfg-update.

I'd say this is the reason. kdiff 3 creates a new file (/etc/sudoers.merge), which is then copied over.

Yes, and kdiff3 respects the umask 022 setting.
I guess I'll have to add some code that checks the file permissions before the update and duplicates that after the update._________________When all else fails, read the manual...
Registered Linux User #340626

I feel like being lazy so here's the conversation from irc. the short is I have tac: write errors in pkgcore that I'm told are cfg-update

Quote:

[22:52] <xenoterracide_> tac: write error
[22:53] <xenoterracide_> I noticed some other ones as well
[22:53] <xenoterracide_> but din't record them
[22:53] <xenoterracide_> ferringb: said tac had something to do with twisted way up there...
[22:53] <mjrosenb> having actual error messages usually helps
[22:54] <xenoterracide> mjrosenb: tac: write error is the actual message from my terminal
[22:54] <xenoterracide> I just know I saw another one that I didn't make note of
[22:56] <xenoterracide> TFKyle asked me to look for segfaults in dmesg
[22:57] <xenoterracide> conftest[29531]: segfault at 0804c000 eip b7ead87c esp bfe856b8 error 6
[22:57] <xenoterracide> I found that
[23:01] <ferringb> xenoterracide: it's not pkgcore... it's cfg-update
[23:01] <agaffney> xenoterracide: he was wrong about it being related to twisted
[23:01] <ferringb> tac is a format used by twisted, it's also a binary for reversing the lines of a file, gotten from coreutils
[23:01] <agaffney> he just didn't know what it was
[23:01] <agaffney> yes, that
[23:02] <xenoterracide> ferringb: yeah I know the second one
[23:02] <ferringb> xenoterracide: check your bashrc. they try to use old style bashrc hooking which is daft, since pre_pkg_setup has existed for literally ~2 years

I feel like being lazy so here's the conversation from irc. the short is I have tac: write errors in pkgcore that I'm told are cfg-update

Yes, cfg-update uses tac to find the last merged package in the Portage logfile /var/log/emerge.log
But cfg-update expects the format that portage uses to write information to this file...
So if you start using a drop-in replacement (pkgcore) for which cfg-update has no support, and pkgcore doesn't write to the emerge.log in the same format as portage did, then you may experience weird things.

I have never tested cfg-update with pkgcore.
I don't know how/where pkgcore stores it's MD5 checksums.
I don't know the format of the pkgcore emerge log, is it also /var/log/emerge.log?
I'm guessing that pkgcore uses /etc/portage/bashrc just like portage does (as the hook to cfg-update is stored there).

So please run "cfg-update --disable-portage-hook" to disable the hook that runs cfg-update --index during emerging with pkgcore.

You can probably continue to use cfg-update without index updates (during emerging).
It will still do automatic 3-way merges and manual merging, only the automatic replacing of unmodified files will not work anymore.
But you will need to specify the special option --ebuild everytime otherwise cfg-update will automatically try to re-enable the hook.
So you can only use it like this: "cfg-update --ebuild -l" and "cfg-update --ebuild -u"... until a new version of cfg-update supports pkgcore._________________When all else fails, read the manual...
Registered Linux User #340626

I can't answer the things you are unsure of. Try asking them on freenode #pkgcore the people their are always helpful. I think they said somewhere that pkgcore doesn't use /etc/portage/bashrc like portage does. Don't ask me how however. I'm just testing pkgcore. Thus far I like it better than paludis, (it was originally intended to be portage 3) but it may not be as far along yet. It's a fast install if you wanted to test it yourself._________________I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.

pkgcore doesn't use emerge.log yet... opening a bug about it as no (good) work around has been presented._________________I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.

******************************************************************************
NOTE TO ALL CFG-UPDATE USERS:

After 5 years I'm finally looking for someone capable of fully adopting cfg-update as I do not have the time to properly support it anymore. I will fix all remaining bugs in week 31 and write some documentation to enable someone else to continue developing it further...
By the way, all those years I have wondered how many people are actually using cfg-update. I still have no clue!

I would really, really, really appreciate it if all you guys out there would just send a shout to xentric@zeelandnet.nl with your name or nickname and your location, just for the fun of it and to get an idea what the minimal size of the userbase is.

Drop me an e-mail on the same address if you're interested in adopting cfg-update.

Does it mean that package is maintained despite note in package.mask (or rather from now)?

Yes, I unmasked it. In fact, ~arch will get an upgrade once they sync (just fixes to one or two outstanding bugs, and merging everything into the upstream repository and putting it on github).

So far the list of enhancements people seem to be interested in are support for beediff and earlier options to replace/delete. From looking at the code I think both will be simple to implement. I suspect I'll add them both in the next version to keep everybody from getting three updates in a week.

I also plan to stabilize new versions after 30 days, so you won't be stuck on ~arch.

What I don't know is how many people are using this package, but I'm happy to see a little activity here. Hopefully the mask didn't scare away too many before I got a chance to take over. Dispatch-conf has come a long way since 2008, but I still see this as more useful.

Does it mean that package is maintained despite note in package.mask (or rather from now)?

Yes, I unmasked it. In fact, ~arch will get an upgrade once they sync (just fixes to one or two outstanding bugs, and merging everything into the upstream repository and putting it on github).

So far the list of enhancements people seem to be interested in are support for beediff and earlier options to replace/delete. From looking at the code I think both will be simple to implement. I suspect I'll add them both in the next version to keep everybody from getting three updates in a week.

I also plan to stabilize new versions after 30 days, so you won't be stuck on ~arch.

What I don't know is how many people are using this package, but I'm happy to see a little activity here. Hopefully the mask didn't scare away too many before I got a chance to take over. Dispatch-conf has come a long way since 2008, but I still see this as more useful.

cfg-update just work for me (the only problem was the permission for sudoers but I use mainly su anyway) so I saw no point in troubleshooting. I'm installing after uninstall right now._________________I've probably left my head... somwhere. Please wait untill I find it.