Having run the little suggested program to clean up the pop-up errors at TDE start, a number of Very Bad Things have happened. First, my KMenu is *entirely* depopulated.
Second, I cannot send mail -- I'm sending this via a webapp. If I try to open, say, a file in KEdit, I get
Could not start process Unable to create io-slave: tdelauncher said: Unknown protocol 'file'.
And so on.
Anybody know how to undo whatever /opt/trinity/bin/r14-xdg-update hath wrought?
This kinda sucks.
dep Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
Judging from the errors I'd assume that the script messed up some files. Reinstalling the base (tdelibs/tdebase) packages will probably help. Technically it might be the .desktop files or (less likely) some library paths (a telling sign of which would be KPDF complaining about a missing part and showing just a blank window).
AFAIK r14-xdg-update is pretty safe to run, but if used improperly, it can indeed do some Very Bad Things. Do you use mixed packages, or are all of them from the same release? Asking because this is a very likely scenario where r14-xdg-update could screw up.
-- Mavridis Philippe
On Tuesday 12 October 2021 14:29:54 Mavridis Philippe wrote:
Judging from the errors I'd assume that the script messed up some files. Reinstalling the base (tdelibs/tdebase) packages will probably help. Technically it might be the .desktop files or (less likely) some library paths (a telling sign of which would be KPDF complaining about a missing part and showing just a blank window).
AFAIK r14-xdg-update is pretty safe to run, but if used improperly, it can indeed do some Very Bad Things. Do you use mixed packages, or are all of them from the same release? Asking because this is a very likely scenario where r14-xdg-update could screw up.
-- Mavridis Philippe
Search for the previous threads with that heading "r14-xdg" or "r14-xdg-update", because that sounds like it might be related.
If you recall, many of us on the list were getting an error message during boot-up sequence, and there were some other quirks that people described.
Kate (or somebody else?) posted something about a dirty "fix" under that heading. It might not be the solution to the problem, but it is somewhere to start looking.
Bill
On Tue, 12 Oct 2021 14:44:52 -0700 William Morder via tde-users users@trinitydesktop.org wrote:
Kate (or somebody else?) posted something about a dirty "fix" under that heading. It might not be the solution to the problem, but it is somewhere to start looking.
It may have been me. There are several nuclear options:
1. The values indicating when/whether the script has been run are stored as plain text in ~/.trinity/share/config/kdeglobals in the [R14 XDG Updates] section and can be mangled to show that the script has run successfully even if it hasn't.
2. Mangle the starttde shell script to comment out the line that runs r14-xdg-update .
3. Mangle the r14-xdg-update script itself to remove the problem test or turn the whole script into a no-op.
None of these is optimal, but any of them should stop the thing from harassing you if it's failing for a reason that can't be easily traced.
E. Liddell
said E. Liddell: | On Tue, 12 Oct 2021 14:44:52 -0700 | | William Morder via tde-users users@trinitydesktop.org wrote: | > Kate (or somebody else?) posted something about a dirty "fix" under | > that heading. It might not be the solution to the problem, but it is | > somewhere to start looking. | | It may have been me. There are several nuclear options: | | 1. The values indicating when/whether the script has been run are stored | as plain text in ~/.trinity/share/config/kdeglobals in the [R14 XDG | Updates] section and can be mangled to show that the script has run | successfully even if it hasn't. | | 2. Mangle the starttde shell script to comment out the line that runs | r14-xdg-update . | | 3. Mangle the r14-xdg-update script itself to remove the problem test or | turn the whole script into a no-op. | | None of these is optimal, but any of them should stop the thing from | harassing you if it's failing for a reason that can't be easily traced.
While it seems to have been resolved here, I do wonder why the R14 script exists to begin with. What does it give us that we need? -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Wed, 13 Oct 2021 14:33:37 +0000 dep dep@drippingwithirony.com wrote:
While it seems to have been resolved here, I do wonder why the R14 script exists to begin with. What does it give us that we need?
The general intent is to ensure better compliance with freedesktop.org's XDG specification (which is a living, and therefore chageable, document).
The substansive part of the script is mostly (90%+) k[de] -> t[de] renames.
Some of the tests are . . . not everything they could be, let's say.
Unless you've gone a long time between updates, very little of this script is likely to be applicable to your system.
E. Liddell
said E. Liddell: | On Wed, 13 Oct 2021 14:33:37 +0000 | | dep dep@drippingwithirony.com wrote: | > While it seems to have been resolved here, I do wonder why the R14 | > script exists to begin with. What does it give us that we need? | | The general intent is to ensure better compliance with freedesktop.org's | XDG specification (which is a living, and therefore chageable, | document). | | The substansive part of the script is mostly (90%+) k[de] -> t[de] | renames. | | Some of the tests are . . . not everything they could be, let's say. | | Unless you've gone a long time between updates, very little of this | script is likely to be applicable to your system.
The offending entry was, three times, kde-noatun. I keep my system up to date -- so why would it have been there? When was there a program by that name? There's surely no time, ever, when I would have that but no other kde- applications, so why would that one alone have survived in the menu file (though not in the menu)? -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
On Wed, 13 Oct 2021 16:46:20 +0000 dep dep@drippingwithirony.com wrote:
said E. Liddell: | On Wed, 13 Oct 2021 14:33:37 +0000
| Some of the tests are . . . not everything they could be, let's say. | | Unless you've gone a long time between updates, very little of this | script is likely to be applicable to your system.
The offending entry was, three times, kde-noatun. I keep my system up to date -- so why would it have been there? When was there a program by that name? There's surely no time, ever, when I would have that but no other kde- applications, so why would that one alone have survived in the menu file (though not in the menu)?
noatun is part of the multimedia package, and might have used kde-noatun as a .desktop file name at some point (likely the pre-14.0 days).
That being said, test 9 is a raw grep being performed on an XML file. This means that it could easily be latching onto something in a comment, because following the full XML spec for determining whether a given line is inside a comment or not using a simple text-matching tool is . . . well, let's say it isn't something I'd want to try, and I deal in regexes a fair amount in my day job. It really needs to be run through a full parser that constructs a DOM tree.
The command in test 9 (slightly modified to remove a variable) is: grep "<Filename>kde-" "~/.config/menus/applications-tdemenuedit.menu"
If that still shows any hits, it should be possible to sed them to death (or kedit them to death, if that's your preference).
E. Liddell
On 2021-10-13 13:07:13 E. Liddell wrote:
On Wed, 13 Oct 2021 16:46:20 +0000
dep dep@drippingwithirony.com wrote:
said E. Liddell: | On Wed, 13 Oct 2021 14:33:37 +0000 | | Some of the tests are . . . not everything they could be, let's say. | | Unless you've gone a long time between updates, very little of this | script is likely to be applicable to your system.
The offending entry was, three times, kde-noatun. I keep my system up to date -- so why would it have been there? When was there a program by that name? There's surely no time, ever, when I would have that but no other kde- applications, so why would that one alone have survived in the menu file (though not in the menu)?
noatun is part of the multimedia package, and might have used kde-noatun as a .desktop file name at some point (likely the pre-14.0 days).
That being said, test 9 is a raw grep being performed on an XML file. This means that it could easily be latching onto something in a comment, because following the full XML spec for determining whether a given line is inside a comment or not using a simple text-matching tool is . . . well, let's say it isn't something I'd want to try, and I deal in regexes a fair amount in my day job. It really needs to be run through a full parser that constructs a DOM tree.
Filter to throw away comments first, then filter for what it should look for.
The command in test 9 (slightly modified to remove a variable) is: grep "<Filename>kde-" "~/.config/menus/applications-tdemenuedit.menu"
If that still shows any hits, it should be possible to sed them to death (or kedit them to death, if that's your preference).
E. Liddell
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.3 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.10 tde-config: 1.0
On Wed, 13 Oct 2021 16:02:14 -0500 J Leslie Turriff jlturriff@mail.com wrote:
On 2021-10-13 13:07:13 E. Liddell wrote:
On Wed, 13 Oct 2021 16:46:20 +0000
That being said, test 9 is a raw grep being performed on an XML file. This means that it could easily be latching onto something in a comment, because following the full XML spec for determining whether a given line is inside a comment or not using a simple text-matching tool is . . . well, let's say it isn't something I'd want to try, and I deal in regexes a fair amount in my day job. It really needs to be run through a full parser that constructs a DOM tree.
Filter to throw away comments first, then filter for what it should look for.
Correctly throwing away comments isn't as simple as tossing away everything between a start marker and an end marker, though, because if the comment marker is inside a CDATA section, it doesn't actually affect whether or not the text is a comment. I suspect a comment marker found between quotes in a text-format attribute value doesn't count either, but I'd have to check the spec to be sure. And there may be more quirks that I've forgotten. (Oh, and you could *easily* embed the value the grep expression is looking for in the file without triggering the grep by using CDATA, now that I think about it.)
There's a reason that man perlfaq6 contains the following:
How do I match XML, HTML, or other nasty, ugly things with a regex? Do not use regexes. Use a module and forget about the regular expressions.
E. Liddell
On 2021-10-14 06:41:30 E. Liddell wrote:
On Wed, 13 Oct 2021 16:02:14 -0500
J Leslie Turriff jlturriff@mail.com wrote:
On 2021-10-13 13:07:13 E. Liddell wrote:
On Wed, 13 Oct 2021 16:46:20 +0000
That being said, test 9 is a raw grep being performed on an XML file. This means that it could easily be latching onto something in a comment, because following the full XML spec for determining whether a given line is inside a comment or not using a simple text-matching tool is . . . well, let's say it isn't something I'd want to try, and I deal in regexes a fair amount in my day job. It really needs to be run through a full parser that constructs a DOM tree.
Filter to throw away comments first, then filter for what it should look for.
Correctly throwing away comments isn't as simple as tossing away everything between a start marker and an end marker, though, because if the comment marker is inside a CDATA section, it doesn't actually affect whether or not the text is a comment. I suspect a comment marker found between quotes in a text-format attribute value doesn't count either, but I'd have to check the spec to be sure. And there may be more quirks that I've forgotten. (Oh, and you could *easily* embed the value the grep expression is looking for in the file without triggering the grep by using CDATA, now that I think about it.)
There's a reason that man perlfaq6 contains the following:
How do I match XML, HTML, or other nasty, ugly things with a regex? Do not use regexes. Use a module and forget about the regular expressions.
E. Liddell
Yeah. I know little about it, but IIRC, XML was supposed to make everything so much easier... :-D
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.3 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.10 tde-config: 1.0
Am Mittwoch, 13. Oktober 2021 schrieb dep:
The offending entry was, three times, kde-noatun. I keep my system up to date -- so why would it have been there? When was there a program by that name? There's surely no time, ever, when I would have that but no other kde- applications, so why would that one alone have survived in the menu file (though not in the menu)?
A probable cause is old config snippets in ~/.config/menus/applications-tdemenuedit.menu. I think I've been carrying this file from my first KDE install in about 2003/4.
I don't understand why you guys still try to find or discuss a solution when it is already there (and documented in this list). That is: just change the concerning lines in the file (~/.config/menus/applications-tdemenuedit.menu) or change the names of the files referred to in ~/.local/share/applications.
Over and out, cheers, Stefan
On 2021-10-13 14:10:26 Stefan Krusche wrote:
Am Mittwoch, 13. Oktober 2021 schrieb dep:
The offending entry was, three times, kde-noatun. I keep my system up to date -- so why would it have been there? When was there a program by that name? There's surely no time, ever, when I would have that but no other kde- applications, so why would that one alone have survived in the menu file (though not in the menu)?
A probable cause is old config snippets in ~/.config/menus/applications-tdemenuedit.menu. I think I've been carrying this file from my first KDE install in about 2003/4.
I don't understand why you guys still try to find or discuss a solution when it is already there (and documented in this list). That is: just change the concerning lines in the file (~/.config/menus/applications-tdemenuedit.menu) or change the names of the files referred to in ~/.local/share/applications.
Over and out, cheers, Stefan
We wouldn't mind so much if there was an easily-found description of the fix for this issue, instead of having to search through ancient history in this mailing list for obscure thread titles.
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.3 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.10 tde-config: 1.0
The general intent is to ensure better compliance with freedesktop.org's XDG specification (which is a living, and therefore chageable, document).
The substansive part of the script is mostly (90%+) k[de] -> t[de] renames.
AFAIK initially the script made some conversions, mainly for XDG compliance. Actually the script also ensures that some changes from the new releases have been applied correctly.
For example, there was the issue tdebase#1 (https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/issues/1) and some related and for the fix to work, Konqueror's icon cache (konq_history) had to be cleared. That is why it is a *bad idea* to force this to run manually. (I think the naming could be better for this script).
-- Philippe
On 2021-10-13 11:41:09 E. Liddell wrote:
On Wed, 13 Oct 2021 14:33:37 +0000
dep dep@drippingwithirony.com wrote:
While it seems to have been resolved here, I do wonder why the R14 script exists to begin with. What does it give us that we need?
The general intent is to ensure better compliance with freedesktop.org's XDG specification (which is a living, and therefore chageable, document).
The substansive part of the script is mostly (90%+) k[de] -> t[de] renames.
Some of the tests are . . . not everything they could be, let's say.
Unless you've gone a long time between updates, very little of this script is likely to be applicable to your system.
E. Liddell
I suppose this test is useful for people migrating from a different desktop to Trinity. Is there a way to run it conditioned on that circumstance only (e.g. test for an existing Trinity installation)?
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.3 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.10 tde-config: 1.0
As I mentioned already, the script ensures that changes between releases are applied correctly. It makes its tests only if a new Trinity release is installed. In other cases it silently quits. The condition for it to run is clear.
-- Philippe
On 2021-10-13 16:29:43 Mavridis Philippe wrote:
As I mentioned already, the script ensures that changes between releases are applied correctly. It makes its tests only if a new Trinity release is installed. In other cases it silently quits. The condition for it to run is clear.
-- Philippe
Another person pointed out that it seems to be failing while looking for references to KDE apps. If that's so, why would it run after upgrade from e.g. R14.0.10 to R14.0.11, which would already have been purged of such apps?
Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.3 x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.0.10 tde-config: 1.0
said J Leslie Turriff: | On 2021-10-13 16:29:43 Mavridis Philippe wrote: | > As I mentioned already, the script ensures that changes between | > releases are applied correctly. It makes its tests only if a new | > Trinity release is installed. In other cases it silently quits. The | > condition for it to run is clear. | > | > -- | > Philippe | | Another person pointed out that it seems to be failing while looking | for references to KDE apps. If that's so, why would it run after | upgrade from e.g. R14.0.10 to R14.0.11, which would already have been | purged of such apps?
Therein lies the rub. It is apparently possible for KDE- applications to *not* get purged from the menu configuration at upgrade. -- dep
Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
Again, apologies for top posting. The standalone ProtonMail webapp allows nothing else without an enormous amount of cutting and pasting.
Re. running KPDF:
It opens to a blank screen, but that's no surprise. If I try to ask it to load a file, I get this
[2021/10/12 19:11:36.745] [kpdf] ERROR: : couldn't create slave : Unable to create io-slave: tdelauncher said: Unknown protocol 'file'. [2021/10/12 19:11:36.745] [kpdf]
dep Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 12th, 2021 at 5:29 PM, Mavridis Philippe mavridisf@gmail.com wrote:
Judging from the errors I'd assume that the script messed up some files. Reinstalling the base (tdelibs/tdebase) packages will probably help. Technically it might be the .desktop files or (less likely) some library paths (a telling sign of which would be KPDF complaining about a missing part and showing just a blank window).
AFAIK r14-xdg-update is pretty safe to run, but if used improperly, it can indeed do some Very Bad Things. Do you use mixed packages, or are all of them from the same release? Asking because this is a very likely scenario where r14-xdg-update could screw up.
Mavridis Philippe
tde-users mailing list -- users@trinitydesktop.org
To unsubscribe send an email to users-leave@trinitydesktop.org
Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
-
dep -
E. Liddell -
J Leslie Turriff -
Mavridis Philippe -
Stefan Krusche -
William Morder