Darrell, all
I'm making an attempt at fixing k3b for gcc47. If anyone else has already done
this please stop me. It is part of bug 958.
--
David C. Rankin, J.D.,P.E.
Collation of TSAK/TDM related issues (there are overlaps in descriptions but that does not mean the same exact problem):
Bug reports involved:
928, kdm starts too early
925, [kdesktop] SAK driven secure dialog is not available for use
906, SAK realization is mostly buggy for KDM
898, tsak process taking 90-100% of CPU
894, TDM: Log file is never purged
884, tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'
667, kdm spawns kwin as root, keeps running after login
625, KDM is hard-coded to use /tmp rather than $TMP or $TMPDIR
==================================================
Direct TSAK issues:
* TSAK demands 90-100% CPU.
* High CPU consumption on wait SAK.
* TSAK/TDM performs no housekeeping to remove pipe/socket files:
1) During a reboot/halt (when TDM terminates)
2) X server restart (which TDM allows)
3) When a user disables TSAK in KControl (tdmrc:UseSAK=false)
* Restarting X server or TSAK ignores the tdmrc:UseSAK=false, using the existing
pipe/socket files instead and keeps running even when explicitly disabled in tdmrc.
* When building tdebase without TSAK support (-DBUILD_TSAK=OFF), and tdmrc:UseSAK=false,
TDM starts with the dialog to press Ctrl-Alt-Del. That should not happen.
* Disabling TSAK in tdmrc (UseSAK=false) does not work.
* Exit from wait dialog by Ctrl+Alt+Del does not work.
* Some people cannot obtain access to the TDM login dialog when pressing Ctrl-Alt-Del.
* TSAK ownership of /tmp/tdesocket-global is assigned to the system's primary login account.
Ownership of that directory is determined by the account UID listed in the tdmrc MinShowUID
key and then that account number is grabbed from /etc/passwd.
* xsession message of "[kdesktop] SAK driven secure dialog is not available for use (retcode %d)"
appears although TDM is not running when using startx.
==================================================
Related to TDM and TSAK:
* When starting X from startx (TDM is not running) the message
"tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'"
appears. There should be no tdmctl/TSAK related messages when using startx.
* Both calls to tdmctl in tdmtsak use the format "tdmctl list" yet there is no
"list" option in tdmctl --help. What is the "list" parameter supposed to do?
* TDM creates nominal profile directories in /tmp. All such directories use a numeric name string. TDM runs
as non-user, but should not be creating any profile directories. Not needed and the profile directories
are never purged. Never happened in KDE3.
==================================================
TDM specific:
* TDM starts too early
* TDM log files never purged.
* TDM spawns twin as root, keeps running after login
I hope this helps. :)
Darrell
All,
I'm trying to patch knemo to initialize with the Sys backend (as default) for
the package. You have the option to set Nettools or Sys (kernel) providing
network information to the monitor. Sys is much more efficient than Nettools,
but only works for kernels >= 2.6 (which is everybody now). I wouldn't care or
go to the effort is the Nettools backend still worked, but as of the Linux
3.0/3.1 kernels, (as well as later 2.6.X kernels) Nettools doesn't seem to work
forcing the user to find and set the obscure setting to Sys before the module
will work at all. I propose we make 'Sys' the default backend in TDE.
Hunting and picking through the code, I have found where the default values
are set for the backend as well as the colors for the plotter graph. There were
a couple of structs and constructors involved depending on how knemo was
launched. I have created a patch that does both (1) set the default backend to
sys and (2) change the graph colors a bit so it is readable regardless of
whether there is a dark/light background shown.
Here is the patch, look it over, engage in discourse and if the yays are
greater than the nays --> push it :) (works with gcc47 too :)
--
David C. Rankin, J.D.,P.E.
All,
I don't know if this is a focus problem, or a problem with ksnapshot itself.
But with ksnapshot configured to capture 'window under cursor' with no delay, if
the window is not the top window, ksnapshot will capture any overlying window
within the geometry of the window you are trying to capture. I've opened a
normal bug for it:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=966
I don't know if this is gcc47, a bug in the desktop when focus set to 'follow
mouse' or what. I have never seen this behavior before. Here are a couple of
screenshots:
http://www.3111skyline.com/dl/dt/trinity/ss/ksnapshot-win-under-cursor-bug.…http://www.3111skyline.com/dl/dt/trinity/ss/ksnapshot-win-under-cursor-bug2…
Also, if you notice, the right side of the window is not captured correctly
either. (possible libpng15 issue??)
Thoughts? tdegraphics build is:
cmake ${srcdir}/${pkgname#*-} \
-DCMAKE_CXX_FLAGS="-fpermissive" \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DCMAKE_INSTALL_PREFIX=${TDEDIR} \
-DWITH_T1LIB=ON \
-DWITH_LIBPAPER=ON \
-DWITH_TIFF=ON \
-DWITH_OPENEXR=ON \
-DWITH_PDF=ON \
-DBUILD_ALL=ON
(no patches)
Thoughts?
--
David C. Rankin, J.D.,P.E.
Darrell,
Here is a simple one for you. The 'tips' in konsole tips to set the prompt
incorrectly uses a 'close' instead of 'open' bracket following the 'e' and
incorrectly uses a ';' and omits the 'm' to terminate resetting the prompt
background and bold state. The tips contain 3 similar references in the form:
export PS1=$PS1"\[\e]0;\H:\w\a\]"
This is wrong. It should be:
export PS1=$PS1"\[\e[0m\H:\w\a\]"
Note the second bracket is backwards... should be
PS1=$PS1"\[\e[
^
Further, to properly reset the background and bold state of the prompt (and to
terminate non-printing characters) so that BASH can properly calculate prompt
length and spacing, you must use '\[\e0m' not \[\e]0; (note the semicolon) The
semicolon is used to separate the foreground/background colors not terminate the
reset... You can see the differences when you look at the bad/good prompts
stacked above/below each other:
export PS1=$PS1"\[\e]0;\H:\w\a\]"
export PS1=$PS1"\[\e[0m\H:\w\a\]"
I've included a patch that fixes the existing 3 prompt tips and I have
included 2 additional prompt tips as well.
Review, signoff and push. If you don't want the additional 2 tips, just trim
them from the patch. (I always like additional tips :)
(no I won't explain how I found this :)
--
David C. Rankin, J.D.,P.E.
I added tqca to the source tree. This module is from the original qca-1.0 sources with the TQt layer added. Adding the sources resolves bug report 817.
Building the package is much the same as with the original qca-1.0 package. The core of the configuration:
export PREFIX=/usr
export LIBDIR=/usr/lib${LIBDIRSUFFIX}
CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
./configure \
--prefix=${PREFIX} \
--qtdir=$QTDIR
make $NUMJOBS VERBOSE=1 || exit 1
make install INSTALL_ROOT=$PKG || exit 1
/usr/doc files:
COPYING INSTALL README TODO
I install TQt3 to /opt/trinity. I install both tqca and tqca-tls to /usr rather than /opt/trinity, but I don't think the installation location is critical.
I am building the package just before building tqca-tls.
I have no clue how to test the package after installation. Then again, I have no idea how to test tqca-tls either.
The tqca package requires about 5 seconds to build. Thus, troubleshooting should be a snap. For once. :)
Darrell
Hi all.
At the meeting we discussed that would be a good release official update
for 3.5.13 soon. In connection with the fact that 1 May it be just half a
year since the release of 3.5.13, it occurred to me that it could be a
nice term for the release official updates.
Therefore I would like to discuss with you:
__1__
Is this term too soon?
Can it be manageable?
Which patches to wait?
Already have poised:
+ patch to close #372
+ other patches from #675
+ workaround for #922
+ waiting for a patch for #258
+ considering revert patch for #394
I would like (but want to wait?)
+ fix SAK. Does anyone work on it? Or temporarily turn it off?
+ find a solution for #812
+ find a solution for #744, #615
__2__
Giving an update the new version number?
Apply here mentioned a few times R13.1 (or R13.1.0)?
They should be in this case, the patches in their own branch in GIT?
Change the version number in the names of all packages (some are otherwise
unchanged)?
Or just change the version number within kdelibs and file names leave them
unchanged?
Or simply release already prepared packages without changing the version
number?
What do you think?
I look forward to your comments
Slávek
--
This is my list of build issues. This is not a comprehensive project list. For example, I have not yet had to tackle gcc 4.7 issues.
There is a pattern to these bugs. I suspect once one bug is resolved, then similar bugs follow.
Blocker:
948 rosegarden: FTBFS when liblo is not installed
946 kstreamripper FTBFS
920 avahi-tqt FTBFS
872 tdesdk FTBFS Against TQt3
871 tdeadmin FTBFS Against TQt3
817 tqca: No tqca package exists for the new tqt3
790 kdemultimedia: audiofile.h configure errors
788 Kdemultimedia: Kaudiocreator won't build unless configure finds the cdda headers
597 tdebindings will not build without numerous patches
Critical:
942 k3b: Can't find the TQt version of the dbus-1.0 headers (install dbus-tqt to /usr)
913 Kerberos support does not exist with any cmake converted package
873 gwenview will not build libmng support
598 tdenetwork will not build on Slackware with wifi support
Major:
945 kpilot FTBFS: Can't find tqt headers
943 kmplayer: Can't find the TQt version of the dbus-1.0 headers (install dbus-tqt to /usr)
877 tdeutils: X11/extensions/extutil.h: present but cannot be compiled
818 amarok: Several build options missing with the cmake conversion
Normal:
950 rosegarden: Sym Links Incorrect
940 kile: Sym Links Incorrect
939 knights: Sym Links Incorrect
933 krusader: Sym Links Incorrect
932 tellico: Sym Links Incorrect
931 kmplayer: Sym Links Incorrect
930 kdiff3: Sym Links Incorrect
627 kspell Sym Link Incorrect
626 konversation Sym Links Incorrect
613 kipi-plugins Sym Links Incorrect
347 amarok Sym Links Incorrect
Minor:
947 kbarcode: unknown icon type
937 kradio: unknown icon type
935 krename: unknown icon type
934 krusader: unknown icon type
807 tdeaddons: unknown icon type
806 kipi-plugins: unknown icon type
805 tdeutils: unknown icon type
804 gwenview: unknown icon type
719 koffice: unknown icon types
Darrell
All,
I have written a brief draft document with some of the rationale behind
the TQt interface layer and the TQt conversion on the Wiki here:
http://trinitydesktop.org/wiki/bin/view/Developers/TQTRationale
Thank you to all who have (gently) reminded many times to get some kind of
rationale written up. The current document is not complete, and I welcome
questions and corrections on the provided Etherpad so that I may address
all concerns from the developers here on this matter.
If this works out, and I think it will, we will have features that no
other KDE 3.5.10 fork can ever attain. Please keep this in mind before
ripping into the implementation details; I took a significant risk in
doing this and I am already seeing benefits in the existence of a viable
TDE Qt4 theme engine alone--who knows what will happen now that Webkit and
other libraries are suddenly available for use in TDE!
Tim