tde-devels

devels@trinitydesktop.org

3 participants
3807 discussions

tdebase FTBFS git hash 888a696a
by François Andriot 18 Aug '13

18 Aug '13

Hello, a typo in git hash 888a696a <http://www.trinitydesktop.org/patches/1376773191:888a696a3d1c31bbd32c75f80a…> is causing FTBFS in kcontrol/tdm/tdm-shut.cpp, because invalid syntax. diff --git a/kcontrol/tdm/tdm-shut.cpp b/kcontrol/tdm/tdm-shut.cpp index 2d8a565..5b295b5 100644 --- a/kcontrol/tdm/tdm-shut.cpp +++ b/kcontrol/tdm/tdm-shut.cpp @@ -1,4 +1,4 @@ -/* This file is part of the KDE Display Manager Configuration package +*/ This file is part of the KDE Display Manager Configuration package Copyright (C) 1997-1998 Thomas Tanghus (tanghus(a)earthling.net) This program is free software; you can redistribute it and/or Please fix it, Thanks Francois

2 3

Re: [trinity-devel] Tim: How to troubleshoot kdialog passive popups
by Darrell Anderson 18 Aug '13

18 Aug '13

>> Tim, >> >> A small problem that has bugged me for a while. On my HTPC I use >> kdialog passive popups to remind me when a TV recording starts or >> stops. This is helpful to me when I run XBMC because I run XBMC in >> full screen. >> >> Originally when I built my HTPC I used KDE 3.5.10. The popups >> always appeared in front of XBMC, which satisfied my intent. >> >> Through the past many months I updated the HTPC: the operating >> system from Slackware 12.2 to 14.0, KDE 3.5.10 to Trinity GIT, >> Nvidia proprietary drivers, and XBMC from 9.01 to 10.1. >> >> The popups no longer appear in front of XBMC. When I toggle XBMC >> from full screen to windowed mode I can see the kdialog popups, but >> not when XBMC is in full mode. The popups appear in front of other >> apps. >> >> This is not a killer problem. :-) I realize there are several >> variables at play, but I don't know how the kdialog mechanism >> works. I'd appreciate ideas for determining whether Trinity (twin?) >> or kdialog is the culprit. >> >Any chance XBMC is now using an override redirect window? If so, >nothing would be able to pop up over the XBMC window. > >If XBMC is still using a traditional managed window, then my first >suspect would be twin's focus stealing prevention. > >I hope this helps! This is interesting. The kdialog passive popups are once again appearing on top of xbmc. Same xbmc package as I had before so something else changed in Trinity within the past 4 months, or possibly in my configurations, although with the htpc I seldom tinker with that. I wonder what fixed the problem.... Oh well, nice to see thenm working again! :-) Darrell

1 0

Re: [trinity-devel] /tmp/tdesocket-global
by Darrell Anderson 17 Aug '13

17 Aug '13

>I believe that this is exactly what I pointed out earlier: >http://trinity-devel.pearsoncomputing.net/?0::11083 Yes. I remember. The culprit is the desktop lock process. When I reboot my systems my shutdown scripts remove garbage and spurious files and cleans /tmp. When I then first log into Trinity /tmp/tdesocket-global does not yet exist. Invoking the desktop lock creates /tmp/tdesocket- global. I understand a process like TDM using /tmp/tdesocket-global, but seems to me user-spawned processes such as desktop locking should use $TDEHOME/socket-`uname -n`. Bug report 1633 filed. Darrell

1 0

/tmp/tdesocket-global
by Darrell Anderson 17 Aug '13

17 Aug '13

We raised this observation in past discussions and bug reports. I am not using TDM. I start X from the command line with startx. Yet I see /tmp/tdesocket-global being created with the login user having full ownership to the directory. The logged-in user can view the contents of the directory, which is always empty. Why is the /tmp/tdeglobal-socket directory being created when TDM is not being used? What global socket connections are required when Trinity is run without TDM or in run level 3? Darrell

2 1

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 17 Aug '13

17 Aug '13

>> Here is propoused patch which checks if demangle.h is present. >> >Darrell, I have demangle.h on my system, so it's up to you to test >it. Actually anybody can test --- just temporarily rename or move /usr/include/demangle.h. :-) Darrell

3 7

Help handbook support for tdepowersave/kpowersave
by Darrell Anderson 17 Aug '13

17 Aug '13

In commit 071d5a84 I pushed a patch to restore the Help handbook for TDEPowersave. Apparently those files got lost in the shuffle when converting to cmake. I presume the same changes are needed for KPowersave, but I don't have a HAL based system to compile KPowersave. To somebody who does and is interested in restoring the Help handbook to KPowersave, you should be able to copy the patch, modify for naming differences, and then push to git. Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 16 Aug '13

16 Aug '13

>Sorry, I'm a little confused, so, slackware doesn't have libbfq at >all or just demangle.h is missing? I don't know about "libbfq," but I suspect you meant to type "libbfd." :-) Yes, libbfd is part of Slackware binutils. As I shared previously, demangle.h is not part of Slackware 14.0 or previous releases. The next official release, 14.1, WILL contain demangle.h in the binutils package. For my own personal usage, I rebuilt binutils for Slackware 14.0 to include demangle.h. Therefore, technically, I no longer need the tdelibs patch. I nonetheless can temporarily rename or delete demangle.h to simulate the non-existence of that file and to test any such patch. The tdelibs patch remains necessary because Slackware is not alone in excluding demangle.h from binutils. Search the dev mail list archives for a previous discussion about demangle.h and affected distros. When demangle.h is not installed, the recent tdeioslave backtrace support patch in tdelibs will not compile. The tdelibs patch, and the predessor patch for tdebase, only allows compiling the modules when demangle.h is not installed in the build environment. The patches have nothing to do with the actual bactrace support. Those folks who compile without those patches merely obtain the ability to compile without demangle.h. When compiled in that manner, those users do not have any ability to produce backtraces from the affected code. Only those folks who compile with demangle.h installed have the ability to produce backtraces from the affected code. >Anyway in a day or two I'll came with a normal patch to move all >that to >kdebug.cpp and provide WITH_LIBBFD for optional linkage... + some >additional backtrace features. I don't think WITH_LIBBFD is necessary. Only an option WITH_DEMANGLE is necessary, or, in my preliminary draft patch, WITH_TDEIOSLAVE_BACKTRACE. I derived my compile option name from the previous tdebase patch, which uses WITH_KDESKTOP_LOCK_BACKTRACE. The whole purpose of this discussion is only to patch tdelibs to compile when demangle.h is not installed. Nothing more. Seems the proposed changes to my preliminary draft patch from Slavek are all that is needed. :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 16 Aug '13

16 Aug '13

>I created a patch and am compiling as I write. Here is the patch. >Please review! Slavek, The patch did not cause any build failures. Hopefully the patch is actually correct too. Now to test the crash patch.... Darrell

4 6

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 16 Aug '13

16 Aug '13

>> For that purpose there is a NDEBUG deffinition used all over the >sources. > >Hmm, it starts to get complicated :) > >And if I want to backtrace handler, but I do not want NDEBUG >because it >enables additional debugging code, that I not want in this >situation? You two are now discussing things over my head! :-) Slavek, I basically copied your original patch and modified as necessary. You do what else is necessary to satisfy yourself and everybody else. That said, the next official version of Slackware will include demangle.h in binutils, although I know some other distros still do not. I am now rebuilding binutils that came with Slackware 14.0 so I can have demangle.h and creae useful backtraces. The tdelibs configuration patch is still needed, of course, for those distros that don't. Should the default be ON or OFF? I don't know. Seems we need the backtrace abilities only for debugging. So while we debug bug report 1627, having the backtrace is nice. Once Tim resolves the cause is the backtrace ability necessary thereafter? Probably not unless we again run into the same problem with a different cause. If the default is OFF then the developer support request in the bug report will be "Please rebuild tdelibs with - DWITH_TDEIOSLAVE_BACKTRACE=ON." Just my two cents. :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS
by Darrell Anderson 15 Aug '13

15 Aug '13

>Sorry about that guys, I only had a short time to work on the >crash bug >and therefore didn't add in the compile time checks/flags. Thanks >for cleaning this up! That's what janitors do.... :-) Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels