Tim, Darrell, All,
After checking the screensaver settings in TDE, tdepowersave was launched and
never closed. I ended up NOT selecting any screensaver for autostart and closed
the dialog. Regardless, tdepowersave keeps churning away. Screenshot attached.
All of these reports are to capture first-looks/thoughts of R14 and the make a
record so they can be followed up on. These are small things. All in all, R14
without hal is working very well.
--
David C. Rankin, J.D.,P.E.
Tim, Darrell,
The syntax highlighting rules for kwrite/kate should be updated one last time
from kde.org before RC1 is frozen. Currently new version exist for:
C++11
CMake
CSS
POV-Ray
reStructuredText
Might as well be up-to-date for R14.
--
David C. Rankin, J.D.,P.E.
Tim, Darrell
I did a fresh install of Arch and loaded TDE. I simply used systemd to launch
tdm (e.g. systemctl enable tdm). Amazingly (and quite comforting) TDE fired up
on first boot without issue. But..., and there is always a but.... When I
attempt to login, I do ctrl+alt+del to get to the login prompt, I login, the
screen turns black like it is starting to launch tde -- but then goes right back
to the tdm [press ctrl+alt+del] screen.
What gives? Is this tsak run amuck? Checking .xsession-errors, there is only 1
error:
/opt/trinity/share/config/tdm/Xsession: line 62: exec: ck-launch-session: not found
The line complained of is:
case $session in
"")
exec xmessage -center -buttons OK:0 -default OK "Sorry,
$DESKTOP_SESSION is no valid session."
;;
failsafe)
exec ck-launch-session xterm -geometry 80x24-0-0
;;
custom)
exec ck-launch-session $HOME/.xsession
;;
default)
exec ck-launch-session /opt/trinity/bin/starttde
;;
*)
--> eval exec ck-launch-session "$session"
;;
esac
exec xmessage -center -buttons OK:0 -default OK "Sorry, cannot execute
$session. Check $DESKTOP_SESSION.desktop."
So apparently case is hitting its default '*' and attempting to execute:
eval exec ck-launch-session "$session"
and fails. The strange thing is that is doesn't execute the default) which
would starttde which I have verified is in place. Further, I can't start any
desktop from tdm. I installed fluxbox, and when I choose "Fluxbox" from the
greeter, the same thing happens -- what to check/do?
--
David C. Rankin, J.D.,P.E.
For the upcoming R14 release, test packages are available for installation and
testing. These packages are pre-RC1 R14 packages, but should be very close to
what will be announced as RC1 in the next few days.
You will first need to add the repository to your pacman.conf. To add the
repository, edit /etc/pacman.conf [as root] changing 'x86_64' to 'i686' as
necessary and add the following lines at the end:
[trinity]
SigLevel = Never
Server = http://trinity.ceux.org/r14/x86_64
'SigLevel = Never' is required because the packages are not yet built and
signed with a signing key.
I have worked to build "groups" into the tde packages so that install is
easily accomplished with:
pacman -Sy "group"
where "group" is one of:
tde-base : minimum possible install (up to tdebase)
tde-core : 'tde-base' + common additional packages
tde-dev : 'tde-core' + development bindings and packages
tde-extra : 'tde-core' + additional desktop features
tde-multimedia : 'tde-core' + all AV and CD/DVD apps (amarok, kaffeine, etc.)
tde-complete : 'tde-extra' + all building packages
Which will work wonderfully -- once it is complete (target R14). For now, the
group information is there, but which package is contained in which group is
still up in the air.
What I suggest for now is installing with pacman -Sy "group" and then compare
the installed packages to those available. Use 'pacman -Sl trinity' to get a
list of packages available and compare to 'pacman -Q | grep tde' after you
install a chosen group, then install any additional packages wanted with 'pacman
-Sy pkg1 pkg2 pkg3 pkg4 ....'
As the groups are currently set, use the following to install TDE (pacman will
handle any dependency packages):
pacman -Sy 'tde-core' # minimal install - no koffice
pacman -Sy 'tde-extra' # moderate install - with koffice
pacman -Sy 'tde-base' # almost all of TDE
You can view the contents of each group before installing with (for example):
pacman -Sl 'tde-base'
Remember, listing the contents of the group only lists packages designated as
part of that group and not all the dependencies that will be pulled in to
support that group. (i.e. if k3b is shown in a group, then k3b itself will pull
in (tdebase, tdelibs, tqtinterface, tqt3, etc.....) as individual dependencies.
The other groups 'dev', 'multimedia', and 'complete' don't really do much at the
moment.
"REMEMBER TO LOOK OVER THE INSTALL OUTPUT FOR optdepends()" The list of
optional additional packages you can install from the normal Arch repositories
to provide full function for the applications installed.
After installation, refer to the wiki
(https://wiki.archlinux.org/index.php/Trinity) to get TDE running. The wiki has
not been updated for systemd and I have not yet setup TDE under systemd, but I
do not think there will be many changes required. If you are using default
systemd booting to the graphical target, then twin/TDE should work fine serving
as the default desktop entry in the graphical.target.wants. If you are a systemd
guru, then report back with your experience and provide any additional
information you feel necessary.
These packages are testing packages for the upcoming R14 release built without
hal. That being said, there were built with the same PKGBUILDS (modified as
needed) as the final packages for 3.5.13-sru and previous working R14 builds
were built from. Please evaluate and report problems back here to the list. If
you confirm a bug, in the TDE code and not the way it was built, then please
open a bug with the trinity bug tracker:
http://bugs.pearsoncomputing.net/enter_bug.cgi
Enjoy.
--
David C. Rankin, J.D.,P.E.
All,
Calvin, a/k/a Mutant Turkey has generously agreed to host archlinux packages
for testing. Contact Calvin for repository information if you have an interest
installing tde on archlinux. The i686 repository is complete and the x86_64
repository will be available later tonight.
--
David C. Rankin, J.D.,P.E.
>>Look at the comments 1, 2 and 3 in the bug 1790. In principle:
>>adding of
>>folder sip4-tqt, respectively, python-tqt in the call
>configure.py
>>and create empty __ init__.py file.
>
>Thank you. Would you or somebody please post a simple listing of
>the final package contents?
Never mind. I think I got the kinks ironed out. sip4-tqt, python-
tqt, and python-trinity all now build. I'm now building
tdebindings. Thank you for the help.
Darrell
>Look at the comments 1, 2 and 3 in the bug 1790. In principle:
>adding of
>folder sip4-tqt, respectively, python-tqt in the call configure.py
>and create empty __ init__.py file.
Thank you. Would you or somebody please post a simple listing of
the final package contents?
Darrell
>sip4-tqt and python-tqt is now a need to build as a python
>modules. Look
>for information from François in bug 1790 and the build scripts in
>RedHat
>and Debian.
>
>http://bugs.pearsoncomputing.net/show_bug.cgi?id=1790
>http://git.trinitydesktop.org/cgit/tde-
>packaging/tree/debian/squeeze/dependencies/sip4-tqt/debian/rules
>http://git.trinitydesktop.org/cgit/tde-
>packaging/tree/debian/squeeze/dependencies/python-tqt/debian/rules
>
>Maybe it would be good to modify sip4-tqt and python-tqt to
>internally
>implement the installation as modules. Python but I'm not so
>buddy, to I
>dared to do it.
I don't understand what you mean by building as python modules, but
I'll look and try to update my build scripts.
Pretty much the entire tdebindings chain is affected.
Darrell
I am unable to build python-tqt. The failure:
Traceback (most recent call last):
File "configure.py", line 31, in <module>
from sip4_tqt import sipconfig
ImportError: No module named sip4_tqt
make: *** No targets specified and no makefile found. Stop.
I don't have anything in my sip4-tqt package named sip4_tqt.
Reversing commit bef77650 allows python-tqt to build.
What is the conflict?
Darrell
>Darrell spent some time to write about outstanding issues. Not
>many fortunately.
>
>What exactly is allowed on the source code after RC1 is tagged?
>Are we restricted to critical bug fixes and nominal patches, or we
>still have a good degree of freedom?
>Actually this is a question I have been asking myself for a
>while....
Good question. What does RC status mean?
>As Darrell said, I am working on bug 1825, which although not a
>blocker, messes up all documentation indexes, so IMO should be
>resolved before releasing R14 (even though technically a fix could
>be push even after RC1 is tagged).
I'm working hard on updating the handbook system. The handbook
system is an utter mess. No, an embarrasing mess, having been
ignored since about KDE 3.2.
I would like to see 1850 fixed for R14, although that has been
broken since KDE3 days.
There is a lot of handbook work to do for a long time. We have an
etherpad of most handbook issues:
http://trinity.etherpad.trinitydesktop.org/82
I have no illusions about fully mending the handbook system for
R14. R14 won't crash or disintegrate without additional handbook
attention, but I'd like to finish the foundation work and my list
in that respect shrinks daily.
We get only that one proverbial chance to release R14 as a polished
release.
Darrell