Hi Duncan,
I feel your sentiment and I know how to bisect. I just don't have big can of time lying around in storage and I hate to mess up my daily work laptop. I could however create a testaccount with the offending configuration and leave my normal account as it is now I think of it.
I still have the old homedir, so who knows what Xmass holidays will bring?
Thx for thinking along with this! I do have a synaptics touchpad and configuring it does ring a bell...
Regards,
Martin
On Fri, Nov 20, 2015 at 5:19 AM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
Martin van Es posted on Thu, 19 Nov 2015 15:09:52 +0100 as excerpted:
> I just discovered that a newly created account doesn't suffer from this
> warning. So what option in my carefully crafted (kde) configuration
> could be responsible for plasma/kde not being able to initialize shared
> memory?
While I see you've solved the problem with a variant of what I was about
to suggest, and I've not the /foggiest/ what might be causing it, when I
have such a problem here with no real idea of where it might be, I use a
"bisect" process to find the problem. If you're familiar with git
bisect, it's doing the same thing in a git context, except automating it.
The idea with a bisect is to repeatedly "bisect" or split the problem
space roughly in half, testing an often arbitrarily chosen half at each
step to see if the problem remains in that half, or if it's in the other
one, then repeating the bisect on the half now known to be the problem.
Which is more or less what you did, by recreating your home dir and only
copying back documents, .config, .local, and .kde, except you stopped at
the first bisect step instead of recursing down into what was left to
trace the problem further.
Personally, I customize so heavily, and am curious enough about what
might be causing my problem, that I'd never be satisfied with the single
step. I'd recurse bisect down until I found the individual file, then,
assuming it's a text-based config file as kde files tend to be, I'd
switch to a text editor and continue recurse-bisecting down to the
individual configuration section within the file, and then probably down
to the individual configuration line, to find the specific setting
causing the problem.
That way, the next time it or something similar, happened, I'd have a
pretty good idea of where to look first, and would either try flipping
that specific setting in the GUI, or simply try removing that file, as a
quick test to see if I was on the right track, before reverting to bisect
mode if it turned out to be a different problem this time.
If you're up for it, I'd love to see you continue that bisect,
particularly now that you know it's not in the big locations so there's
far less to bisect down now, just because I'm curious about what could
possibly trigger such an error, as well as confirming or disproving
whether my initial guess that it might not be shm related after all, vs.
yours that it was.
Plus, knowing what it was might help me better help the next person
(which for all I know might be me), and until we know what was causing
it, there's no indication whether it might be a bigger problem and the
list is about to get inundated with people asking about it...
FWIW, the other conceivable thing I know of that it /might/ be, and that
was definitely shm-based, would be a likely older synaptics driver
touchpad device configuration tool, as I know they did in fact use shm
some time ago, but AFAIK, that's deprecated usage now, and even then, it
was primarily used when tweaking the initial configuration to get the
settings just right for a specific hardware installation and individual
user, and wasn't necessary once a user had appropriate settings to put in
the permanent config. Which might explain why you had forgotten about
it, if you'd experimented with it some years ago and had long since
gotten the settings you wanted, or even switched to non-touchpad hardware
and don't even use the thing any more.
As that was not kde specific it wouldn't have used the kde dir for its
settings, and that usage probably predates the XDG standardization
on .config and .local, so those settings would likely be in some other
dot-file directly in your home dir, and thus not copied when you copied
only the docs and .kde, .local, and .config dirs from your old home dir.
So if an old synaptics or touchpad config possibly using shm rings a
bell, that's where I'd look next. Other than that, I'd certainly be
bisecting here, as I literally have no other ideas, but would certainly
be in hot pursuit of the problem and its location using bisect, once I
knew for sure it was definitely within my specific user config.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
If 'but' was any useful, it would be a logic operator
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
