Also, a root file manager, if not a full root GUI session, is necessary
to compile programs and build RPMs from that, and that's also something
I do. *Again, **I'm requesting this bug be researched and fixed.*
-------- Forwarded Message --------
Subject: Re: [tde-devels] Re: Cannot talk to TDE Launcher #224 in TDE
14.1.3.
Date: Fri, 7 Mar 2025 01:40:28 -0800
From: Alec Destry <xode(a)techccu.com>
To: Dr. Nikolaus Klepp via tde-devels <devels(a)trinitydesktop.org>
"/...Don't open root file manager windows. It's a bad idea in the first
place to use a GUI filemanager as root. Can't tell you how often I've
seen users trashing their system that way.../and complaining that it's
what you do on M$ and the DE has to hande that..."
TDE has that capability installed and for good reason. This has nothing
to do with "M$" (Microsoft). *I'm requesting this bug be researched and
fixed.* There are times when the system needs custom configuration and
a root file manager is the way to do that, especially when you want to
be able to set up your system so it can be restored from scratch without
having to depend at all on the internet.
On 3/7/25 01:09, Dr. Nikolaus Klepp via tde-devels wrote:
> Anno domini 2025 Thu, 6 Mar 23:37:03 -0800
> Alec Destry via tde-devels scripsit:
>> About a week ago, I reported this bug in TDE 14.1.3 at
>> https://mirror.git.trinitydesktop.org/gitea/TDE/tde/issues/224 but, so
>> far, nothing has happened. Is that where bugs should be reported?
> Should be the right place :)
>
> Anyway, I just commented there: Don't open root file manager windows. It's a bad idea in the first place to use a GUI filemanager as root. Can't tell you how often I've seen users trashing their system that way ... and complaining that it's what you do on M$ and the DE has to hande that. But this is the unix way of livey: you are free to shoot yourself if you feel like it.
>
> Nik
>
>> ____________________________________________________
>> tde-devels mailing list --devels(a)trinitydesktop.org
>> To unsubscribe send an email todevels-leave(a)trinitydesktop.org
>> Web mail archive available athttps://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinityde…
On 26 July 2021, I reported that KDE 3.5.10 ark shows a messed up
timestamp when viewing a ZIP archive using the latest versions of
unzip. I've since installed TDE 14.1.3 and have found the same problem
exists with TDE ark as well (trinity-ark-14.1.3-1.oss156.x86_64.rpm).
Unzip (unzip-5.52-77.x86_64.rpm), some years ago, when listing files in
an archive, showed the timestamp for those files in the format of
MM-DD-YY. The latest versions of unzip (unzip-6.00-89.1.x86_64.rpm),
when listing files in an archive, shows the timestamp for those files in
the format of YYYY-MM-DD. This change in how unzip shows timestamps
caused KDE 3.5.10 ark, and is also causing TDE 14.1.3 ark, to show a
messed up timestamp when viewing a ZIP archive using the latest versions
of unzip.
Rolling back to the older version of unzip gets rid of the problem.
However, that could create other problems. Also, TDE ark
(trinity-ark-14.1.3-1.oss156.x86_64.rpm) has many advantages over KDE4
ark and later, one prime example being its TDE konqueror integration.
For these reasons, I'm requesting this bug be fixed.
Hi all!
Has anybody experience with using libtqt-perl? Somehow I cannot get any test program running:
$ perl /usr/share/doc/libtqt-perl/tutorials/t1/t1.perl
Cannot find blib even in /usr/share/doc/libtqt-perl/tutorials/t1/../../../../..
BEGIN failed--compilation aborted at ./t1.pl line 3.
Commenting out said line 3 and retrying:
--- No method to call for :
TQt::Application(ARRAY(0x560d6f75b3c8))
at ./t1.pl line 6.
Line 6 is:
my $a = TQt::Application(\@ARGV);
So checking perl TQt API:
$ pqtapi TQt|grep Application
$
... gives nothing.
Testing pqtsh:
$ pqtsh
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at /usr/lib/x86_64-linux-gnu/perl5/5.40/TQt/isa.pm line 48.
Compilation failed in require at /usr/bin/pqtsh line 15.
BEGIN failed--compilation aborted at /usr/bin/pqtsh line 15.
So .. what am I missing? Does this interface work at all? Or better asked, when was the last time somebody has last tested it or seen it working?
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
# zypper se -sx trinity-filesystem | grep files
i | trinity-filesystem | package | 14.1.3-1.osstw | noarch | (System Packages)
v | trinity-filesystem | package | 14.1.3-1.osstw | noarch | TDEnoarch
# rpm -e --nodeps trinity-filesystem
# rpm -qa | grep y-files
# rpm -ivh /var/cache/zypp/packages/TDEnoarch/trinity-filesystem-14.1.3-1.osstw.noarch.rpm
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:trinity-filesystem-14.1.3-1.osstw################################# [100%]
# zypper se -sx trinity-filesystem | grep files
i | trinity-filesystem | package | 14.1.3-1.osstw | noarch | (System Packages)
v | trinity-filesystem | package | 14.1.3-1.osstw | noarch | TDEnoarch
#
Whether installation by zypper or rpm, the above sequence of events
has been the state of affairs on multiple installations for more than
a month, perhaps more than four.
There's also this:
# grep y-files /var/log/zypp/history | tail -n3
2024-03-23 21:47:47|install|trinity-filesystem|14.1.1-1.osstw|noarch||TDEnoarch|98abd…
2024-05-19 02:27:49|install|trinity-filesystem|14.1.2-1.osstw|noarch||TDEnoarch|1326e…
2024-10-31 01:04:49|install|trinity-filesystem|14.1.3-1.osstw|noarch||TDEnoarch|79367…
The result should resemble approximately the following:
# zypper se -sx trinity-tdm | grep tdm
i | trinity-tdm | package | 14.1.3-1.osstw | x86_64 | TDE
#
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
# cat .xsess*
/etc/trinity/tdm/Xsession: line 46: /etc/X11/xdm/Xsession: No such file or directory
#
I upgraded as I had in the past from 15.5 to 15.6 long before 15.6 release. Most
of past times this worked fine, but apparently now something has changed in
openSUSE Leap X setup. I remember reading not terribly long ago in openSUSE
Factory mailing list that xdm was to be discontinued as a means to start every
primary DM, including TDM. Maybe that's the reason here? /etc/X11/xdm/ is now down
from 20 files and 2 directories to 2 files:
Xservers
xdm-config
# cat Xservers
# Xservers - local X-server list
#
# This file should contain an entry to start the server on the
# local display; if you have more than one display (not screen),
# you can add entries to the list (one per line).
# If you also have some X terminals connected which do not support XDMCP,
# you can add them here as well; you will want to leave those terminals
# on and connected to the network, else kdm will have a tougher time
# managing them. Each X terminal line should look like:
# XTerminalName:0 foreign
#
# use such a line to enable the console login option in the kdm menu
#:0 local@tty1 /usr/bin/X vt7
# "reserve" means that the X server gets only started on request (only kdm)
# -keeptty implies that controlling tty is not detached (breaks startx!)
:0 local /usr/bin/X -nolisten tcp -br vt7 -keeptty
ga88x:~/X11/xdm # cat xdm-config
!
! xdm-config: Configuration of the xdm
!
DisplayManager.errorLogFile: /var/log/xdm.errors
DisplayManager.pidFile: /run/xdm.pid
DisplayManager.authDir: /var/lib/xdm
DisplayManager.keyFile: /usr/etc/X11/xdm/xdm-keys
DisplayManager.servers: /etc/X11/xdm/Xservers
DisplayManager.accessFile: /usr/etc/X11/xdm/Xaccess
DisplayManager.willing: su nobody -c /usr/etc/X11/xdm/Xwilling
!
! ATTENTION: `authName' should be in general MIT-MAGIC-COOKIE-1
! For XDM-AUTHENTICATION-1 which is default for xterminals see
! manual page of xdm and the manual coming with the xterminal.
!
DisplayManager.*.authName: MIT-MAGIC-COOKIE-1
DisplayManager.*.authComplain: false
!
! All displays should use authorization, but we cannot be sure
! X terminals will be configured that way, so by default
! use authorization only for local displays :0, :1, etc.
!
DisplayManager._0.authorize: true
DisplayManager._1.authorize: true
DisplayManager._93.authorize: true
!
! The scripts handling the setup, the startup, the session its self,
! and the reset of an X session.
!
DisplayManager.*.setup: /usr/etc/X11/xdm/Xsetup
DisplayManager.*.chooser: /usr/etc/X11/xdm/RunChooser
DisplayManager.*.startup: /usr/etc/X11/xdm/Xstartup
DisplayManager.*.session: /usr/etc/X11/xdm/Xsession
DisplayManager.*.reset: /usr/etc/X11/xdm/Xreset
!
DisplayManager._0.terminateServer: true
DisplayManager._93.terminateServer: true
!
DisplayManager*resources: /usr/etc/X11/xdm/Xresources
DisplayManager.*.terminateServer: false
!
! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
!
DisplayManager.requestPort: 0
#
Copying Xsession from 15.6 doesn't help.
# startx /opt/trinity/bin/starttde
does produce an expected success mostly, but the xrandr script I keep in
/etc/X11/xinit/xinitrc.d/ to run on startup is ignored, so all is mousetype, and
relative screen positions don't get set where they belong. I'll try on another PC
with KDE3 on 16.0pre and TW to see how they work as time permits....
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
For every attempt to upgrade TDE to the latest release, full upgrade is blocked,
unless package rootcerts is first upgraded, a blocker to trinity-tdelibs. This is
an ancient problem that caused me to write a urpmipre script 3 years ago to
upgrade rootcerts (and a few other packages) before any process to upgrade TDE.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Just letting you all know the power is out where my servers are hosted and I dont know when the power will be back. Ill keep you updated when it’s back up
Get Outlook for iOS<https://aka.ms/o0ukef>
...how can I get the crash report to GITEA?
Also, when the crash notification screen appears, all of the window frames
and gadgets are gone and I'm unable to use the File Save dialog to save the
trace information because the file name field and buttons are off the bottom
of the display (see attached screen shots).
(I suspect that this crash happens because of the large number of tabs and
windows that Firefox is displaying.)
Leslie
--
Platform: Linux
Distribution: openSUSE Leap 15.6 - x86_64
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.1.3
tde-config: 1.0
