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 <[email protected]> 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.
