Version: (using KDE 4.3.5) Installed from: openSUSE RPMs KDE hard-codes /tmp for temporary files. It should use TMPDIR environment variable if it defined (and not empty). KDE is one of the only applications which does not use the $TMPDIR environment variable for where to locate temporary data. Not everybody, or every distribution, or every environment uses /tmp - in some cases this is undesireable. Please use the $TMPDIR environment variable for kdecache-$USERNAME directories and others.
From startkde script: # Link "tmp" "socket" and "cache" resources to directory in /tmp # Creates: # - a directory /tmp/kde-$USER and links $KDEHOME/tmp-$HOSTNAME to it. # - a directory /tmp/ksocket-$USER and links $KDEHOME/socket-$HOSTNAME to it. # - a directory /var/tmp/kdecache-$USER and links $KDEHOME/cache-$HOSTNAME to it. # Note: temporary locations can be overriden through the KDETMP and KDEVARTMP # environment variables
Actually looking at the code for "lnusertemp", it looks both in KDETMP and TMPDIR, with TMPDIR taking precedence. Qt's QDir::tempPath() also checks TMPDIR, so I wonder where you see KDE not respecting that variable.
Sorry, KDETMP takes precedence over TMPDIR, so you might check if you have that variable defined to /tmp.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This is a side note. I am responding only because I was apparently added as a CC to this bug in Jan 2017 (as reporter of a related bug 375717). Alas, I cannot help with the Linux environment NEEDSINFO. However, I note that Mr. Feck's last post of 2010-02-11 "...so you might check if you have that variable defined to /tmp" presumptively also setting NEEDSINFO status, does *not* actually request an action on the part of the reporter nor a request to report back. "...you might check..." conveys a meaning of purely optional activity. There is no "call to action" language requesting an update of the bug report. The reporter "might" have checked his env vars and even fiddled them based on the bug updates but was under no call to action compulsion to report anything. I suggest that as https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging has guidelines for reporting bugs, there also needs to be a guideline for triage and developers in how to word NEEDSINFO requests to give reporters specific guidance motivation on what is needed and sample call to action language to actually update the bug report. R
I was requesting information with comment #2: "where [do] you see KDE not respecting that variable"
Mr. Feck, Respectfully, re-read your 2010-02-11 20:08:21 EST post. Expanding your own quote a bit we have "...so I wonder where you see KDE not respecting that variable." "I wonder..." is the governing subject-action phrase here. You wonder/muse/consider/ponder but have not asked action of anyone. Three minutes later at 20:11:51 EST you weaken it even further, effectively appending "...you might...". Pedantic about wording but I had to learn this the hard way in a previous life as an IT sales engineer when requesting information or action from busy, distracted customers or prospects. I and my company's offerings or installed product were some modest to very small fraction of their day job. I learned to structure requests as bite-size "executables" with context info, instruction, desired reportables and a call to action establishing roles/responsibilities. In this bug report context where the reporter will typically be busy, distracted and of modest technical literacy, a structured, firm NEEDSINFO template might be: ###### Please update this bug with: 1) <observation or value acquired through step-step-procedureA > 2) <observation or value acquired through step-step-procedureB > 3) dah, dah, dah Please post back to this bug if you need help with any of the bullet items. Regards. Super KDE Dev 42 ####### Starts with a strong call to action "Please update..." laying responsibility on the reporter or identified party, then a bullet list of "executables" resulting in reportable info, then an escape-help-retry path is offered if one of the executables stalls or fails. Roll your own. Regards, R
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!