Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Mick]

On Wednesday, 29 May 2019 23:23:58 BST Dale wrote:
> n952...@web.de wrote:
> > And, what are the consequences that I'm suffering, that I haven't done
> > that before, for over a year?> 
> >> Gesendet: Mittwoch, 29. Mai 2019 um 23:55 Uhr
> >> Von: n952...@web.de
> >> An: gentoo-user@lists.gentoo.org
> >> Betreff: updating /etc/package.accept_keywords
> >> 
> >> I have many files like ._cfg_package.accept_keywords.
> >> Is the right way to handle this to do something like:
> >> 
> >> sort -u ._cfg_package.accept_keywords >| package.accept_keywords
> 
> Look into etc-update, dispatch-conf and other commands that help with
> updating those.  I admit, I'm bad to let them sit to because I usually
> manually update important stuff.  I don't wait that long tho.  Keep in
> mind, there is a small chance that a bad config could result in
> something not working when you reboot or not being able to completely
> boot at all.  It depends on what files are not updated. 
> 
> Hope that helps.
> 
> Dale
> 
> :-)  :-) 

I always run etc-update or dispatch-conf to see what the changes in default 
config files may be and invariably accept or merge the changes with my version 
of the config files each time.  If I am in a rush and the changes are not 
trivial, I will leave this for a day in the near future and avoid restarting 
the service affected.  However, I would not leave a remote server in this 
state in case an unintended reboot causes some critical service to fail to 
restart, e.g. network, sshd, etc.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Dale]

Mick wrote:
> On Wednesday, 29 May 2019 23:23:58 BST Dale wrote:
>> n952...@web.de wrote:
>>> And, what are the consequences that I'm suffering, that I haven't done
>>> that before, for over a year?> 
 Gesendet: Mittwoch, 29. Mai 2019 um 23:55 Uhr
 Von: n952...@web.de
 An: gentoo-user@lists.gentoo.org
 Betreff: updating /etc/package.accept_keywords

 I have many files like ._cfg_package.accept_keywords.
 Is the right way to handle this to do something like:

 sort -u ._cfg_package.accept_keywords >| package.accept_keywords
>> Look into etc-update, dispatch-conf and other commands that help with
>> updating those.  I admit, I'm bad to let them sit to because I usually
>> manually update important stuff.  I don't wait that long tho.  Keep in
>> mind, there is a small chance that a bad config could result in
>> something not working when you reboot or not being able to completely
>> boot at all.  It depends on what files are not updated. 
>>
>> Hope that helps.
>>
>> Dale
>>
>> :-)  :-) 
> I always run etc-update or dispatch-conf to see what the changes in default 
> config files may be and invariably accept or merge the changes with my 
> version 
> of the config files each time.  If I am in a rush and the changes are not 
> trivial, I will leave this for a day in the near future and avoid restarting 
> the service affected.  However, I would not leave a remote server in this 
> state in case an unintended reboot causes some critical service to fail to 
> restart, e.g. network, sshd, etc.
>


This is good advice.  I sometimes look to see if there is anything
important to the changes.  Most of the time, it is mostly the date or
something at the top, sometimes it even detects that and just does it
itself.  Thing is, sometimes I just don't have time to wade through a
somewhat large file with a lot of changes that may not be important or
even worse, will change settings I made back to defaults that don't
work.  Some files I let sit until I can figure out if I need them
updated or not.  I'm fond of the zap new button. 

A prime example, KDE config files.  I have my desktop set up like I like
it.  If I update the config file, it usually sets it back to the
default.  That's one I like to spend time on if I update it.  Another is
my network configs.  Some settings are done differently and won't work
if I use the updated file or it resets to default. 

I use the dispatch one because it is better.  No matter what I attempt
tho, I can not figure out how to use that dang merge thing.  I wish
there was a GUI tool to do this.  Maybe that would help.  Of course,
someone will likely post that there is a GUI tool and then I'll wonder
how I missed it.  ROFL  You can bet I'd use it tho. 

On a remote server, yea, it is certainly best to finish the entire
update process before stopping.  That could be bad. 

Dale

:-)  :-) 

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Mick]

On Thursday, 30 May 2019 12:28:41 BST Dale wrote:

> I use the dispatch one because it is better.  No matter what I attempt
> tho, I can not figure out how to use that dang merge thing.  I wish
> there was a GUI tool to do this.  Maybe that would help.  Of course,
> someone will likely post that there is a GUI tool and then I'll wonder
> how I missed it.  ROFL  You can bet I'd use it tho. 

There's also cfg-update and there may be more tools to manage changes in 
config files following an update.

The merge function is particularly useful, because you can see where your 
edits are/not affected by any changes to the new config defaults and reject/
accept one change at a time.

You can define what tool will be used for diff-ing in the /etc/dispatch-
conf.conf file, or equivalent.  I use colordiff, but I supposed you could set 
up meld, kompare, or some other GUI file comparison application to be launched.

With colordiff once you press 'm' to merge changes, you get your existing 
config file shown on the left and the changed config on the right.  Pressing 
'l' retains your existing config, 'r' overwrites yours with the new defaults. 
When you finish it asks if you want to overwrite the existing config with the 
newly merged file.  Up until this moment you can choose to cancel all changes 
and the old config file will be retained as it was.

Overwriten config files are archived in /etc/config-archive, so you can always 
revert any changes you made by mistake.

HTH.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] updating portage, continued

[n952162]

Next comes this:

"The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by sys-devel/crossdev-20171230::gentoo
# required by @selected
# required by @world (argument)
=sys-apps/portage-2.3.67 ~amd64"


If I'm understanding correctly, accept_keywords allow experimental and 
development versions.  Why should I need that for something as basic as 
portage?  Is AMD not quite ready for primetime?  And, how does portage know?  
And what happens if I just ignore that?  What consequences can I expect?

Any thoughts appreciated.

Re: [gentoo-user] slot conflict when updating portage

[Rich Freeman]

On Wed, May 29, 2019 at 6:55 PM Neil Bothwick  wrote:
>
> On Thu, 30 May 2019 00:52:31 +0200, n952...@web.de wrote:
>
> > !!! Your current profile is deprecated and not supported anymore.
> > !!! Use eselect profile to update your profile.
> > !!! Please upgrade to the following profile if possible:
> >
> > default/linux/amd64/17.0/desktop
> >
> > You may use the following command to upgrade:
> >
> > eselect profile set default/linux/amd64/17.0/desktop
> >
> >
> >  * IMPORTANT: 6 news items need reading for repository 'gentoo'.
> >  * Use eselect news read to view new items.
> >
> >
> >  * IMPORTANT: 26 config files in '/etc/portage' need updating.
> >  * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
> >  * sections of the emerge man page to learn how to update config files.
>
> You should deal with these issues first. Ignoring news items, failing to
> update config files and running a deprecated profile are all good ways of
> making problems for yourself.

Agree in general, though I'd hold off on the profile upgrade until
everything is working unless there is no choice.

You should never just leave config files alone of course, and reading
news is just reading.

Unless a news item says otherwise, you're best off doing profile
changes on a completely clean and up-to-date system.  If you have some
ancient box that you haven't touched in five years there might need to
be some modifications to that, but unless you're an expert you should
simply avoid running ancient out-of-date Gentoo boxes because we
simply do not guarantee a clean upgrade path for these.  That doesn't
mean it can't be done, but it isn't necessarily point-and-click.

I wouldn't be surprised if these issues stem from keywording issues,
which is probably why all those files in /etc/portage need updating.
They're probably a mess with redundant autounmask entries.  There
might be some keyword mixing issues - you can get that to work but of
course that isn't a well-supported config, especially if you're doing
it with something like portage.

-- 
Rich

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Rich Freeman]

On Thu, May 30, 2019 at 7:58 AM Mick  wrote:
>
> There's also cfg-update and there may be more tools to manage changes in
> config files following an update.
>
> The merge function is particularly useful, because you can see where your
> edits are/not affected by any changes to the new config defaults and reject/
> accept one change at a time.

Yeah, I couldn't live without cfg-update, especially with the
auto-merging of changes.  The one caveat is that it isn't the
best-maintained piece of software out there.  I'm mostly nursing it
along.

It uses 3-way diffs, which means you're looking at the new file, the
last Gentoo-provided file, and your current file.  So, you can easily
see what changed upstream in the last update and focus on those
changes, vs the stuff that you added.

It can do automatic 3-way diffs.  This means that if you made a change
to line 500 of some config file from the upstream one, and in the new
version line 3 changes, then line 3 will get updated without any
intervention.  If on the other hand a line close to line 500 changes
then you'll be prompted to merge the changes.  This is of course
optional behavior, but 99% of the time it does the right thing, since
most use default configs with a few tweaks.  If you completely
scrapped the upstream config file and wrote your own this feature
won't be useful, but then again it won't touch the files anyway since
it will see that it changed.

It also tracks everything in RCS.  Not my favorite vcs but it works
well enough for what the tool itself does, and I just keep all of /etc
in git which is the history I'd look at.  I use etckeeper (in the
repo) for this - nothing too fancy - just some portage hooks to keep
git up to date for etc.

-- 
Rich

Re: [gentoo-user] Updating portage, continued

[Rich Freeman]

On Wed, May 29, 2019 at 6:37 PM  wrote:
>
> The next section of the response to my attempt to update portage is a long 
> list of packages, each terminated with a "(masked by: something or other)".
>
> What does that tell me.  If it's masked, it shouldn't be available, right?  
> But, I've got it:
>
> - virtual/perl-parent-0.234.0-r1::gentoo (masked by: package.mask)
>
> ls virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
> virtual/perl-parent/perl-parent-0.234.0-r1.ebuild
>
> Can I get rid of it?  Is perl-parent always masked?
>

I think one of the issues here is that you might be running a bit with
scissors.

It seems like you might be using package.keywords, and now you're
dealing with package masks.

Portage will let you override just about anything, but those default
behaviors all exist for a reason and you can easily end up painting
yourself into a corner.  Overriding keywords is something that isn't
too unsafe to do once you know what you're doing, but if you're doing
it a lot it can get out of hand (adding keywords for one package can
require 3 more, and if you keep that up it can really get out of
hand).  If you're overriding keywords frequently perhaps you should be
running the testing branch in the first place, etc.

Overriding masks is something that should only be done if you REALLY
know what you're doing.  If something is masked it might contain
security vulnerabilities, or it might be going away.  The consequences
of the former are obvious.  If it is going away then you're going to
be fighting to keep things working because the next step will be
removal and other packages will start being modified to not work with
the old approach.

Basically, any setting you put in /etc/portage is something you're
going to have to work to maintain, so you should be doing whatever you
can to minimize this.  By all means speak up on the list about "I'm
trying to accomplish this, and is there a better way to go about it?"
If you're creating a ton of entries in /etc/portage you might be
fighting the package manager more than necessary.  There is nothing
wrong with customizing things (that is basically what Gentoo is for),
but you definitely need to learn how to manage that so that you don't
make life hard on yourself.

-- 
Rich

Re: [gentoo-user] updating portage, continued

[Rich Freeman]

On Wed, May 29, 2019 at 6:27 PM  wrote:
>
> Next comes this:
>
> "The following keyword changes are necessary to proceed:
>  (see "package.accept_keywords" in the portage(5) man page for more details)
> # required by sys-devel/crossdev-20171230::gentoo
> # required by @selected
> # required by @world (argument)
> =sys-apps/portage-2.3.67 ~amd64"
>
>
> If I'm understanding correctly, accept_keywords allow experimental and 
> development versions.  Why should I need that for something as basic as 
> portage?  Is AMD not quite ready for primetime?  And, how does portage know?  
> And what happens if I just ignore that?  What consequences can I expect?
>

I would not accept this change.

That version of crossdev is no longer in the repo, but it only depends
on >=sys-apps/portage-2.1.  Any stable version of portage should
satisfy that.  I'd need more output to figure out what is going on
there.

-- 
Rich

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Mick]

On Thursday, 30 May 2019 02:18:01 BST Dale wrote:

> I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
> 17.0 and wait until 17.1 is released. 
> 
> Dale
> 
> :-)  :-) 

The 17.1 profile does away with separate /lib directories as explained here:

https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout

From the relevant enews item:

===
2017-12-26-experimental-amd64-17-1-profiles
  Title Experimental amd64 17.1 profiles up for testing
  AuthorMichał Górny 
  Posted2017-12-26
  Revision  3

A new set of 17.1 amd64 profiles has been added to the Gentoo
repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require explicit migration as described below. They
are considered experimental at the moment, and have a fair risk
of breaking your system. We would therefore like to ask our users to
test them on their non-production ~amd64 systems.

In those profiles, the lib->lib64 compatibility symlink is removed.
The 'lib' directory becomes a separate directory, that is used
for cross-arch and native non-library packages (gcc, clang) and 32-bit
libraries on the multilib profile (for better compatibility with
prebuilt x86 packages).

Migration from both 13.0 and 17.0 profiles is supported. In case
of the former, please read the news item for 17.0 upgrade first
and enable gcc 6.4.0 or newer first as explained there.

The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:

1. Sync and upgrade your system to the newest package versions
   to reduce the risk of issues.

2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib'

3. Run 'unsymlink-lib --analyze' and check the output for obvious
   mistakes. If you need to perform any changes to the system, remember
   to run 'unsymlink-lib --analyze' again afterwards.

[past this point do not call emerge or modify /usr manually]

4. This is a very good time to make a backup.

5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
   what is going to happen.

6. Reboot your system and see if it still boots. Check if important
   programs work. In particular, check if e.g. 'emerge --info' works
   (but do not install anything). If you hit any serious problems,
   you can use 'unsymlink-lib --rollback' to revert the changes
   and return to step 3.

7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
   what is going to happen but note that you're going to see a very long
   list of files to remove.

8. Switch the profile, e.g.:

 eselect profile set --force default/linux/amd64/17.1/desktop

[at this point you can start using emerge again]

9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles,
   rebuild sys-devel/binutils and sys-libs/glibc afterwards.

10. If you are using a multilib profile, rebuild all 32-bit packages.
This can be done using:

  emerge -1v /lib32 /usr/lib32

Alternatively, if you are switching from one of the 13.0 profiles
you can rebuild all packages as detailed in the 17.0 news item.

11. Once the last 32-bit package is rebuilt, your package manager
should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
does not happen, remove them manually.

For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.

For more information on the layout, please see the wiki article
on AMD64 multilib layouts [2].

[1]:https://bugs.gentoo.org/506276
[2]:https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
==


BTW, the OP may want to read the enews item for upgrading to 17.0 profile 
first, just in case he needs to make any changes to his gcc and rebuild his 
toolchain:

==
2017-11-30-new-17-profiles
  Title New 17.0 profiles in the Gentoo repository
  AuthorAndreas K. Hüttel 
  Posted2017-11-30
  Revision  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo 
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked 
   and not supported for use as a system compiler anymore. Feel 
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, har

[gentoo-user] Re: upgrading (profiles, too)

[»Q«]

On Thu, 30 May 2019 15:38:34 +0100
Mick  wrote:

> On Thursday, 30 May 2019 02:18:01 BST Dale wrote:
> 
> > I haven't tested the 17.1 profile yet.  If you are unsure, I'd just
> > use 17.0 and wait until 17.1 is released.   
> 
> The 17.1 profile does away with separate /lib directories as
> explained here:
> 
> https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout

The 17.1 profiles are soon to be marked stable, so I went ahead and
migrated a little over a week ago, following the draft news item Michał
Górny recently posted to -dev.  FWIW, the migration seemed to go
smoothly and I haven't noticed anything breaking except
app-office/kmymoney won't build, apparently because the ebuild expects
something to be in /lib which isn't there any more.  But one dev said
it builds fine on his 17.1 test system, so I dunno.  I filed a bug,
.

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Neil Bothwick]

On Thu, 30 May 2019 08:20:49 -0400, Rich Freeman wrote:

> > There's also cfg-update and there may be more tools to manage changes
> > in config files following an update.
> >
> > The merge function is particularly useful, because you can see where
> > your edits are/not affected by any changes to the new config defaults
> > and reject/ accept one change at a time.  
> 
> Yeah, I couldn't live without cfg-update, especially with the
> auto-merging of changes.  The one caveat is that it isn't the
> best-maintained piece of software out there.  I'm mostly nursing it
> along.

conf-update works best for me. It also can use colordiff to highlight
changes and can be configured to auto-merge trivial changes.


-- 
Neil Bothwick

I believe the technical term is "Oops!"


pgpBReDcbww9A.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Neil Bothwick]

On Thu, 30 May 2019 06:28:41 -0500, Dale wrote:

> This is good advice.  I sometimes look to see if there is anything
> important to the changes.  Most of the time, it is mostly the date or
> something at the top, sometimes it even detects that and just does it
> itself.  Thing is, sometimes I just don't have time to wade through a
> somewhat large file with a lot of changes that may not be important or
> even worse, will change settings I made back to defaults that don't
> work.  Some files I let sit until I can figure out if I need them
> updated or not.  I'm fond of the zap new button. 

A tool that shows just the differences, like cfg-update or conf-update,
makes this easier.
 
> A prime example, KDE config files.  I have my desktop set up like I like
> it.  If I update the config file, it usually sets it back to the
> default.  That's one I like to spend time on if I update it.  Another is
> my network configs.  Some settings are done differently and won't work
> if I use the updated file or it resets to default. 

KDE config files shouldn't be in CONFIG_PROTECTed directories, it's
generally configured at user level.


-- 
Neil Bothwick

Octal: (n.) a base-8 counting system designed so that one hand may count
upon the fingers of the other. Thumbs are not used, and the index finger
is reserved for the 'carry.'


pgpTNgIRA3FAE.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] emerging older compilers

[karl]

Karl Hammar:
> For testing purposes, I would like to install older compilers,
> e.g. testing with older kernels.
> 
> I have tried to install e.g. gcc-5.4.0-r4, gcc-4.9.4, and
> gcc-3.4.6-r2.ebuild (package.unmask is upd. for theese), but it fails.

 I have found out that I can install thoose older comilers with:

FEATURES="-sandbox -usersandbox" emerge -aqv   =sys-devel/gcc-5.4.0-r4

# since ustat.h is no loger with (>=glibc 2.28) according to 
# 
https://sourceware.org/git/?p=glibc.git;a=commit;h=cf2478d53ad7071e84c724a986b56fe17f4f4ca7
echo =sys-devel/gcc-4.9.4 -sanitize >> /etc/portage/package.use/gcc
eselect gcc set 1
. /etc/profile
FEATURES="-sandbox -usersandbox" emerge -aqv   =sys-devel/gcc-4.9.4

gcc-3.4.6-r2 still doesn't install though.

Regards,
/Karl Hammar

Re: Aw: Re: [gentoo-user] upgrading (profiles, too)

[Dale]

Mick wrote:
> On Thursday, 30 May 2019 02:18:01 BST Dale wrote:
>
>> I haven't tested the 17.1 profile yet.  If you are unsure, I'd just use
>> 17.0 and wait until 17.1 is released. 
>>
>> Dale
>>
>> :-)  :-) 
> The 17.1 profile does away with separate /lib directories as explained here:
>
> https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
>
> <<>
>
> Switching the profile from 13.0 to 17.0 modifies the settings of 
> GCC 6 to generate PIE executables by default; thus, you need to do 
> the rebuilds even if you have already used GCC 6 beforehand.
> If you do not follow these steps you may get spurious build
> failures when the linker tries unsuccessfully to combine non-PIE
> and PIE code.
> =
>
> HTH.


Given that is going to involve quite a bit of changes, and it appears
the OP has a outdated system, going in steps may be a good idea.  At
least that way if something breaks, it may be easier to fix since the
steps are smaller. 

As usual tho, it depends.  It may be easy enough to go to 17.1 but then
again, it could create a mess.  I guess it is up to the OP which route
to go and how much compiling he wants to do. 

If I recall correctly, I did a merge -e world when I switched to 17.0. 
There are some things that I'd rather rebuild everything just to be
sure.  When it is winter time, why not, I need the heat anyway.  ;-) 

Dale

:-)  :-) 

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Håkon Alstadheim]

Den 29.05.2019 23:58, skrev n952...@web.de:

And, what are the consequences that I'm suffering, that I haven't done that 
before, for over a year?


Gesendet: Mittwoch, 29. Mai 2019 um 23:55 Uhr
Von: n952...@web.de
An: gentoo-user@lists.gentoo.org
Betreff: updating /etc/package.accept_keywords

I have many files like ._cfg_package.accept_keywords.
Is the right way to handle this to do something like:

sort -u ._cfg_package.accept_keywords >| package.accept_keywords


For package.accept_keywords specifically, it most likely means you have 
said yes to question to allowing unstable packages, and never actually 
allowed those. So I'd just remove them, and pay more attention on the 
next "emerge -u --autounmask-write @world". See emerge(1)


Apart from that, what the others said.

Re: [gentoo-user] Fw: updating /etc/package.accept_keywords

[Dale]

Neil Bothwick wrote:
> On Thu, 30 May 2019 06:28:41 -0500, Dale wrote:
>
>> This is good advice.  I sometimes look to see if there is anything
>> important to the changes.  Most of the time, it is mostly the date or
>> something at the top, sometimes it even detects that and just does it
>> itself.  Thing is, sometimes I just don't have time to wade through a
>> somewhat large file with a lot of changes that may not be important or
>> even worse, will change settings I made back to defaults that don't
>> work.  Some files I let sit until I can figure out if I need them
>> updated or not.  I'm fond of the zap new button. 
> A tool that shows just the differences, like cfg-update or conf-update,
> makes this easier.
>  

Installed both.  Couldn't figure out conf-update, sort of like
dispatch-conf.  I liked cfg-update but got lost.  It opened a window
that had these nifty arrows that moved things from one to the other.  I
prefer moving entries I want to keep to the new file and was able to
figure out how to do that.  Where I got lost, what do I do to save it
and tell it to use the new file?  I didn't see anything in the graphical
part and couldn't figure out how to view the new file before accepting
it when I got back to conf-update.  Other than that, I like the tool and
would like to use it. 


>> A prime example, KDE config files.  I have my desktop set up like I like
>> it.  If I update the config file, it usually sets it back to the
>> default.  That's one I like to spend time on if I update it.  Another is
>> my network configs.  Some settings are done differently and won't work
>> if I use the updated file or it resets to default. 
> KDE config files shouldn't be in CONFIG_PROTECTed directories, it's
> generally configured at user level.

It hasn't done it in a while but it used to clobber that thing on a
regular basis.  Either way, that and a couple other file taught me to be
careful with those updates. 

Dale

:-)  :-)