Hi all,
those of you who have been here for a long time might recall that when I
joined the community I assumed that my tasks would be only two: backport
patches to the stable TDE series and work on translation. Over time, it
turned out that my tasks on the project would be bigger. However, work
on translations is still a postponed task.
Recently, I have devoted some time to the tasks that are essential to move
us forward with the work on translations. Therefore, I would like to
inform you about the results and related plans.
I apologize for long email.
1. Unnecessary updates of POT files during package build
I observed that during the DEB packages build, an attempt was made to
update POT files. However, this step makes no sense. Bundling usually
takes place in dedicated pure chroot. Therefore, the result of updating
POT files would be discarded anyway. So this is unnecessary work.
At the same time, the extractrc tool is used during the POT files update.
But this tool is part of the tdesdk-scripts-trinity package. Therefore,
when building other packages, it is usually not present. So updating POT
files during building could not work well.
That's why I already removed these unnecessary updates of POT files while
building DEB packages.
2. Do we still need to use the old modified version of xgettext?
I found out what the current status is and whether there are still reasons
to use the old modified version of xgettext (kde-xgettext). Patches for
the old version solve two things:
a) adding a way to enter plural forms of strings
b) adding a way to enter translation context
The current versions of gexttext already have both of these options, but
they seem to be implemented in a different way. Before we can start using
standard xgettext in TDE, we will need to add support for a new way of
plural forms of strings and translation contexts.
So far, we need to continue using an old modified version of kde-xgettext.
3. Can modern gettext replace the extractrc tool?
Modern versions of gettext can handle XML files. We use XML files
for 'kcfg', 'rc' and 'ui'. Using ITS support in gettext, there is a way
to define which texts are to be extracted for translations. I tested this
option, but I encountered some problems:
a) Tags are written in strings as html entities: < / > / &.
After extraction using xgettext, are left in this form. But the extractrc
tool convert them to the appropriate characters '<', '>', '&'. I did not
find a way to do this with xgettext and ITS.
b) XPath is used to determine which strings are to be extracted from XML
files. Files 'kcfg' use their own XML namespace and I did not find a way
how to enter XPath to work properly with ITS in xgettext.
That's why I decided it was better to continue using the extractrc tool.
4. How do we create and update POT files?
In order to provide strings for translation, we first need to create and
update POT files. The best place for these files is right in the source
code – in GIT. Therefore, these files need to be maintained independently
of the building binaries. Therefore, it is obvious that for this task it
is not a good time during the build binary packages, nor the usual use of
Automake or CMake.
Although the usual use of CMake with CMakeLists.txt for updating POT files
is not a good choice, using CMake as such seems to be a good idea. CMake
allows using the -P option to process a different file than the usual
CMakeLists.txt. In this case, it does not create build folder, it does
not create a cache - exactly as it suits us for our purpose.
I decided to use the name CMakeL10n.txt. I have prepared the CMake module
TDEL10n.cmake. This module provides functions for simplifing directories
handling – function tde_add_l10n_subdirectory as the equivalent for
add_subdirectory and function tde_auto_add_l10n_subdirectories as an
equivalent for tde_auto_add_subdirectories. And above all, the
tde_create_l10n_template macro that provides POT files generation.
This macro provides some benefits that seemed useful:
a) If resource files are processed – for example, *.ui, the work
file "rc.cpp" is commonly used to save extracted strings for translation.
This file is then processed by kde-xgettext. Links to the original
location of strings in the resulting POT file then refer to
this "rc.cpp", which is not very useful.
The tde_create_l10n_template macro performs additional processing by
replacing references to "rc.cpp" with references to the original resource
files. Therefore, the POT file does not refer to a non-existent "rc.cpp"
file, but to real locations in resource files.
b) When a new POT file is generated, a comparison is made with the
original POT file. If only the date of POT file generation is changed,
the original POT file will be left unchanged.
This prevents unnecessary POT file updates. This will allow to run a
regular update of POT files without causing unnecessary commits.
5. What's next?
For revisions and comments, I created a pull request containing a CMake
module TDEL10n.cmake:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake/pulls/2
...and pull requests with a demonstration of use CMakeL10n in two modules:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/1https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/19
After testing, we will need to add CMakeL10n.txt to generate POT files in
all other modules. Once we have automated updating of POT files,
translation work can begin!
6. How can users work on translations?
I will leave the answer to this question for later. Whoever was more
attentive could have noticed in several earlier commits that "something
is being prepared" :)
Cheers
--
Slávek
Hi Devs,
Before I file a bug on this I'd like to try to narrow it down a bit so
I'm looking for some pointers on how TDM works and where I might start
looking.
Since upgrading to Debian Stretch and TDE: R14.0.6, we're seeing an
issue where TDM won't start a new session for a display and has zombie
child process(es). This is with networked X-Terminals using XDMCP.
It's happening roughly every week or so (no fixed time of day) on a
system with around 30 users/terminals logging in and out.
It might happen after a user logs out or after the remote terminal is
reset or, according users rumour, after a kdesktoplock has been
unlocked; I'm failing to get real concrete info on that aspect (I'm sure
you know what users are like!).
Anyway, the terminal gets fired up/restarts X11 after a logout but
doesn't then get a response to its XDMCP requests and just sits there
showing a default X11 background (hence the grey-screen-of-death
moniker).
When TDM is in this state, doing "ps waux | grep tdm" shows:
root 18481 0.0 0.0 0 0 ? Z Feb19 0:00 [tdm] <defunct>
root 20178 0.0 0.0 0 0 ? Z Feb19 0:00 [tdm] <defunct>
root 25478 0.0 0.0 0 0 ? Z Feb19 0:00 [edm] <defunct>
These processes in pstree look like:
|-tdm(12251)-+-tdm(1004)---tdm_greet(1005)-+-krootimage(1009)
| | |-twin(1013)
| | `-{tdm_greet}(1020)
| |-tdm(1389)---tdm_greet(1390)-+-krootimage(1392)
| | `-{tdm_greet}(2309)
<snip>
| |-tdm(4546)---tdm_greet(4547)-+-krootimage(4549)
| | |-twin(4552)
| | `-{tdm_greet}(4556)
| |-tdm(4738)---starttde(21417)-+-ssh-agent(21539)
| | `-tdeinit_phase1(21613)---kwrapper(21614)
| |-tdm(18481)
| |-tdm(20178)
| |-tdm(20178)
| |-tdm(25478)
<snip>
|-tdmtsak(15721)
Doing an strace on the main TDM process, shows it doing a select on a
bunch of fds but nothing else.
If I restart tdm (/etc/init.d/tdm restart), it will start working again
and, mostly, preserve the live users sessions... but sometimes not and
everyone gets booted out :-(
Once restarted like this, some tdms have a parent of systemd and some
are children of the new? main tdm process:
systemd(1)-+-ModemManager(1591)-+-{gdbus}(1599)
| `-{gmain}(1595)
<snip>
|-tdm(16655)---starttde(6171)-+-ssh-agent(6293)
| `-tdeinit_phase1(6369)---kwrapper(6370)
|-tdm(29430)---starttde(26723)-+-ssh-agent(26845)
| `-tdeinit_phase1(26933)---kwrapper(26934)
|-tdm(32506)---starttde(21854)-+-ssh-agent(21976)
| `-tdeinit_phase1(22057)---kwrapper(22058)
|-tdm(32680)-+-tdm(424)---tdm_greet(429)-+-krootimage(1068)
| | |-twin(1071)
| | `-{tdm_greet}(1075)
| |-tdm(426)---starttde(7968)-+-ssh-agent(8092)
| | `-tdeinit_phase1(8229)---kwrapper(8231)
| |-tdm(428)---tdm_greet(431)-+-krootimage(1150)
| | |-twin(1155)
So... can anyone suggest where I should be looking to try an narrow
down the cause of this?
How does TDM know when a session ends and what stops it providing a new
one?
Should it have zombies hanging around? Should it reap it's zombie
children? I see there's a ReapChildren function in dm.c which seems
like it should get called when it gets a SIGCHLD. How could that not be
working?
Thanks in advance.
--
Regards,
Russell
--------------------------------------------------------------------
| Russell Brown | MAIL: russell(a)lls.com PHONE: 01780 471800 |
| Lady Lodge Systems | WWW Work: http://www.lls.com |
| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
--------------------------------------------------------------------
Is there a way to make reboots following updates not take over 2 minutes just to begin? I see this
somewhat often, but haven't been tracking with which versions. The one just done is 14.0.6~pre38 on
Buster.
What exactly is a "User Manager"?
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Hi,
I don't know how closely the devs watch the Bug list but I believe I've
fixed Bug 2998.
As this bug results in kdesktop/kdesktop_lock eating CPU and going
unresponsive; might I humbly request that the fix is incorporated in the
next possible/dev version.
As the code I posted on bugzilla used a crude fixed buffer, here's a
cleaned up version that uses malloc.
*** /tmp/tdebase-trinity-14.0.6~pre38/kdesktop/lock/main.cc Thu Feb 7 15:48:21 2019
--- /usr/tmp/tdebase-trinity-14.0.6~pre38/kdesktop/lock/main.cc Sun May 20 19:41:55 2018
***************
*** 325,336 ****
#endif
}
! char *locknameroot="kdesktop_lock_lockfile.";
! char *lockfilename = (char*)malloc(strlen(locknameroot) + strlen(getenv("DISPLAY")) + 1);
! strcpy(lockfilename,locknameroot);
! strcat(lockfilename,getenv("DISPLAY"));
!
! TDELockFile lock(locateLocal("tmp", lockfilename));
lock.setStaleTime(0);
TDELockFile::LockResult lockRet = lock.lock();
if (lockRet != TDELockFile::LockOK) {
--- 325,331 ----
#endif
}
! TDELockFile lock(locateLocal("tmp", "kdesktop_lock_lockfile"));
lock.setStaleTime(0);
TDELockFile::LockResult lockRet = lock.lock();
if (lockRet != TDELockFile::LockOK) {
--
Regards,
Russell
--------------------------------------------------------------------
| Russell Brown | MAIL: russell(a)lls.com PHONE: 01780 471800 |
| Lady Lodge Systems | WWW Work: http://www.lls.com |
| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
--------------------------------------------------------------------
Hi,
I see this as beta testing exercise, so here is what I did:
1. Long time ago I asked Michele to help me build local repository and build
system. This now works and I can build the packages from git repository,
which I checked out.
2. I then create a local repository and can use it from the local network
3. I had no problem installing, upgrading and testing - it is just great!
I just wanted to try installing TDE from scratch in clean chrooted
debootstrap from the repository I build last month, but I failed on few
metapackages. (This is perhaps related to a UL issue discussed few days
ago)
apt-get install tde-trinity
The following packages have unmet dependencies:
tde-trinity : Depends: tde-core-trinity (>= 4:14.0.0~) but it is not going
to be installed
Depends: desktop-base-trinity but it is not installable
E: Unable to correct problems, you have held broken packages.
Why I don't find desktop-base-trinity in stretch
$ grep desktop-base-trinity -r tde/1_git/tde-packaging/debian/stretch/ |
grep Package
but it is in
$ grep desktop-base -r tde/1_git/tde-packaging/ | grep Package
tde/1_git/tde-packaging/ubuntu/maverick/defaultsettings/desktop-base/debian/control:Package:
desktop-base-trinity
same for tde-core
$ grep tde-core -r tde/1_git/tde-packaging/ | grep Package
tde/1_git/tde-packaging/debian/squeeze/metapackages/meta-tde/debian/control:Package:
tde-core-trinity
tde/1_git/tde-packaging/debian/lenny/metapackages/meta-tde/debian/control:Package:
tde-core-trinity
Where do I log this bugzilla or gitea?
thanks
Hello to all programmers,
please give your attention and share your opinion to the proposed patch
for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Cheers
--
Slávek
Hi all!
Hope this helps others that try to get started with tdevelop:
As written some time ago I was not able to build any project with tdevelop due to a mismatch of "libtool": The one that is created ftom tdevelop does not match the one that is needed for devuan. I just found out, that is sufficient to replace "libtool" (that one that is created by configure) with a symlink to the installed libtool and the the project compiles perfect.
Now this is a dirty hack to get things working for all tde projects that are created by tdevelop:
cd /opt/trinity/share/apps/kdevappwizard/template-common
tar xzf admin.tar.gz
cat << XXX >> admin/configure.in.bot.end
rm libtool
ln -s $(which libtool) .
XXX
tar czf admin.tar.gz admin
rm -R admin
Now there is another "configure.in.bot.end" template for kde which is most likely to suffer from the same problem, but as I am not interested in kde I did not check.
Nik
--- /tmp/configure.in.bot.end 2019-02-03 14:02:56.102558045 +0100
+++ /opt/trinity/share/apps/kapptemplate/admin/configure.in.bot.end 2019-02-03 14:04:08.746918269 +0100
@@ -43,3 +43,11 @@
echo "Good - your configure finished. Start make now"
echo ""
fi
+
+rm libtool
+cat << XXX > libtool
+#!/bin/env libtool
+XXX
+chmod a+x libtool
+
+
--
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...