>> Hi!
>>
>> I am on preliminary stable builds on debian stretch. After the last
>> update i am getting an r14-xdg-update error 9 on login. It complains
>> about permissions and tells to look at
>> r14-xdg-update-validation-test9.txt. There is one line in here
>> <Filename>kde-kchmviewer.desktop</Filename> No such file exist anywhere.
>> What i am supposed to do with this?
>
> In $HOME/.config/menus/applications-tdemenuedit.menu, there should be an
> entry like "<Filename>kde-kchmviewer", which is triggering that error. Why
> is there is not possible to say, there has been no change lately to justify
> such an error. Cheers
> Michele
After converting back to Trinity once more from KDE3 on my OpenSuSE Leap 15
system, I now have two accounts that are producing these entries. (The last
time I was running Trinity only one account was doing it.)
I don't quite understand what causes this, or what the fix is. Do I merely
remove the entries from $HOME/.config/menus/applications-tdemenuedit.menu?
What will prevent them from coming back?
By the way, the messages that appear at login time are seriously inadequate
from the standpoint of explaining what to do. The second message merely
refers to "applications-tdemenuedit.menu" with no information about its
location, and to the contents
of "/var/tmp/tdecache-$USER/r14-xdg-update-validation-test9.txt", with no
instructions that explain their relationship or what changes to make.
Leslie
As per ML communication:
```txt
>> Hi!
>>
>> I am on preliminary stable builds on debian stretch. After the last
>> update i am getting an r14-xdg-update error 9 on login. It complains
>> about permissions and tells to look at
>> r14-xdg-update-validation-test9.txt. There is one line in here
>> <Filename>kde-kchmviewer.desktop</Filename> No such file exist anywhere.
>> What i am supposed to do with this?
>
> In $HOME/.config/menus/applications-tdemenuedit.menu, there should be an
> entry like "<Filename>kde-kchmviewer", which is triggering that error. Why
> is there is not possible to say, there has been no change lately to justify
> such an error. Cheers
> Michele
After converting back to Trinity once more from KDE3 on my OpenSuSE Leap 15
system, I now have two accounts that are producing these entries. (The last
time I was running Trinity only one account was doing it.)
I don't quite understand what causes this, or what the fix is. Do I merely
remove the entries from $HOME/.config/menus/applications-tdemenuedit.menu?
What will prevent them from coming back?
By the way, the messages that appear at login time are seriously inadequate
from the standpoint of explaining what to do. The second message merely
refers to "applications-tdemenuedit.menu" with no information about its
location, and to the contents
of "/var/tmp/tdecache-$USER/r14-xdg-update-validation-test9.txt", with no
instructions that explain their relationship or what changes to make.
Leslie
```
I don't have kchmviewer installed but the reference (I use ack) I get with It, is from the kchmviewer package Itself.
When the last tdebase package was built and what commits were made on It just before?
I'll build kchmviewer later in the afternoon.
Hi Michele,
I don't have kchmviewer installed but the reference (I use ack) I get with It, is from the kchmviewer package Itself.
When the last tdebase package was built and what commits were made on It just before?
I'll build kchmviewer later in the afternoon.
Hi Greg,
nothing to do with kchmviewer specifically.
The problem is with the migration of a profile from KDE3 to TDE done by /opt/trinity/bin/starttde. Somehow Leslie seems to have issues
Hi Greg,
nothing to do with kchmviewer specifically.
The problem is with the migration of a profile from KDE3 to TDE done by /opt/trinity/bin/starttde. Somehow Leslie seems to have issues
Additional info: appartently the problem is related to a kde4 entry in PATH.
Again from mailing list:
>> I think that I've gotten to the root of this problem: an overlooked
>> reference to a kde library in my PATH environment variable. (Oops.)
>> Thanks for helping with this.
>>
>> Leslie
>
> So if the PATH is correct, the conversion from kde to tde works fine?
Well, those startup XDG messages are gone, anyway.
> And what was the problematic variable?
There was a reference to /usr/lib64/kde4 in $PATH.
Additional info: appartently the problem is related to a kde4 entry in PATH.
Again from mailing list:
```
>> I think that I've gotten to the root of this problem: an overlooked
>> reference to a kde library in my PATH environment variable. (Oops.)
>> Thanks for helping with this.
>>
>> Leslie
>
> So if the PATH is correct, the conversion from kde to tde works fine?
Well, those startup XDG messages are gone, anyway.
> And what was the problematic variable?
There was a reference to /usr/lib64/kde4 in $PATH.
```
Just ran into this myself. Even as an experienced TDE user it is difficult to
figure out what to do. You don't have copy/paste or screen grab at this
point so I took a photo (attached).
/var/tmp/tdecache-mgb/r14-xdg-update-validation-test9.txt did indeed contain: <Filename>kde-konsole.desktop</Filename>
After that it's pure guess work. grep -rl kde-konsole[.]desktop ~ found a
lot of hits, mostly in ancient year 2014 log files from an application I didn't
recognize. The most likely culprit was probably ~/.config/menus/applications-tdemenuedit.menu. There was already a similar tde-konsole line in that file so I simply removed the kde-konsole line.
NOTE: The grep -r also got a hit on RecentAppsStat in ~/.trinity/share/config/kickerrc but r14-xdg-update did not complain
about that.
It's hard to imagine how difficult it would be to improve this process but it would be great if somebody could figure out a way to do it.
Just ran into this myself. Even as an experienced TDE user it is difficult to
figure out what to do. You don't have copy/paste or screen grab at this
point so I took a photo (attached).
`/var/tmp/tdecache-mgb/r14-xdg-update-validation-test9.txt` did indeed contain:
`<Filename>kde-konsole.desktop</Filename>`
After that it's pure guess work. `grep -rl kde-konsole[.]desktop ~` found a
lot of hits, mostly in ancient year 2014 log files from an application I didn't
recognize. The most likely culprit was probably
`~/.config/menus/applications-tdemenuedit.menu`. There was already a similar
`tde-konsole` line in that file so I simply removed the `kde-konsole` line.
NOTE: The `grep -r` also got a hit on RecentAppsStat in
`~/.trinity/share/config/kickerrc` but `r14-xdg-update` did not complain
about that.
It's hard to imagine how difficult it would be to improve this process but it would be great if somebody could figure out a way to do it.
As per ML communication:
Hi Michele,
I don't have kchmviewer installed but the reference (I use ack) I get with It, is from the kchmviewer package Itself.
When the last tdebase package was built and what commits were made on It just before?
I'll build kchmviewer later in the afternoon.
Hi Greg,
nothing to do with kchmviewer specifically.
The problem is with the migration of a profile from KDE3 to TDE done by /opt/trinity/bin/starttde. Somehow Leslie seems to have issues
Attached menu files from Leslie.
Additional info: appartently the problem is related to a kde4 entry in PATH.
Again from mailing list:
Just ran into this myself. Even as an experienced TDE user it is difficult to
figure out what to do. You don't have copy/paste or screen grab at this
point so I took a photo (attached).
/var/tmp/tdecache-mgb/r14-xdg-update-validation-test9.txt
did indeed contain:<Filename>kde-konsole.desktop</Filename>
After that it's pure guess work.
grep -rl kde-konsole[.]desktop ~
found alot of hits, mostly in ancient year 2014 log files from an application I didn't
recognize. The most likely culprit was probably
~/.config/menus/applications-tdemenuedit.menu
. There was already a similartde-konsole
line in that file so I simply removed thekde-konsole
line.NOTE: The
grep -r
also got a hit on RecentAppsStat in~/.trinity/share/config/kickerrc
butr14-xdg-update
did not complainabout that.
It's hard to imagine how difficult it would be to improve this process but it would be great if somebody could figure out a way to do it.