12 Oct
2021
12 Oct
'21
9:21 p.m.
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/
12 Oct
12 Oct
9:29 p.m.
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
9:44 p.m.
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
13 Oct
13 Oct
2:25 p.m.
On Tue, 12 Oct 2021 14:44:52 -0700
William Morder via tde-users <users(a)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
2:33 p.m.
said E. Liddell:
| On Tue, 12 Oct 2021 14:44:52 -0700
|
| William Morder via tde-users <users(a)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/
4:41 p.m.
On Wed, 13 Oct 2021 14:33:37 +0000
dep <dep(a)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
4:46 p.m.
said E. Liddell:
| On Wed, 13 Oct 2021 14:33:37 +0000
|
| dep <dep(a)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/
6:07 p.m.
On Wed, 13 Oct 2021 16:46:20 +0000
dep <dep(a)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
9:02 p.m.
On 2021-10-13 13:07:13 E. Liddell wrote:
On Wed, 13 Oct 2021 16:46:20 +0000
dep <dep(a)drippingwithirony.com> wrote:
Filter to throw away comments first, then filter for what it should look for.
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
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
14 Oct
14 Oct
11:41 a.m.
On Wed, 13 Oct 2021 16:02:14 -0500
J Leslie Turriff <jlturriff(a)mail.com> wrote:
On 2021-10-13 13:07:13 E. Liddell wrote:
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 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.
15 Oct
15 Oct
4:46 a.m.
On 2021-10-14 06:41:30 E. Liddell wrote:
On Wed, 13 Oct 2021 16:02:14 -0500
J Leslie Turriff <jlturriff(a)mail.com> wrote:
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
On 2021-10-13 13:07:13 E. Liddell wrote:
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 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. 
13 Oct
13 Oct
7:10 p.m.
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
9:06 p.m.
On 2021-10-13 14:10:26 Stefan Krusche wrote:
Am Mittwoch, 13. Oktober 2021 schrieb dep:
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 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
5:02 p.m.
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
9:04 p.m.
On 2021-10-13 11:41:09 E. Liddell wrote:
On Wed, 13 Oct 2021 14:33:37 +0000
dep <dep(a)drippingwithirony.com> wrote:
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
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
9:29 p.m.
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
14 Oct
14 Oct
2:55 a.m.
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
3:56 a.m.
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/
12 Oct
12 Oct
11:14 p.m.
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(a)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(a)trinitydesktop.org
>
> To unsubscribe send an email to users-leave(a)trinitydesktop.org
>
> Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
1164
days inactive
1167
days old
18 comments
6 participants
participants (6)
-
dep -
E. Liddell -
J Leslie Turriff -
Mavridis Philippe -
Stefan Krusche -
William Morder