tde-devels

devels@trinitydesktop.org

2 participants
3811 discussions

Still having problems with get-update and the nightly builds
by Keith Daniels 31 Oct '13

31 Oct '13

I had to shut down because of storms and just got back online where I could test things again. I also accidentally deleted the previous email about the problem. duh... When I try to use "apt-get update" for the nightly build for Debian wheezy--it still gives me this error message: ----------------- Err http://ppa.quickbuild.pearsoncomputing.net wheezy/main Sources 404 Not Found Fetched 127 kB in 8s (14.9 kB/s) W: Failed to fetch http://ppa.quickbuild.pearsoncomuting .net/trinity/trinity-nightly-build/debian/dists/wheezy/main/source/Sources 404 Not Found ----------------- and dumps me out of apt-get. I did some checking, and the "mirrorservice.org" link (which is where "http://ppa.quickbuild.pearsoncomuting.net/trinity/" takes me): http://www.mirrorservice.org/sites/trinitydesktop .org/trinity/trinity-nightly-build-dependencies/ubuntu/dists /wheezy/main/source/Source Seems to be the link needed for Debian wheezy. Keith

2 2

Debian Nightly builds.
by Keith Daniels 30 Oct '13

30 Oct '13

I am trying to install and test the nightly build. I used these lines in my sources.list file: ----------------- deb http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity-nightly-build-de… main deb-src http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity-nightly-build-de… main ----------------- and yes the other two lines are in there as well but I get dumped out before apt-get runs them. When I run apt-get update, everything runs fine until I get to the deb-src line. At that point I get this error message: ----------------- Err http://ppa.quickbuild.pearsoncomputing.net wheezy/main Sources 404 Not found ----------------- and yes there is a space after .net above, which looks wrong to me. The error message immediately dumps me out of apt. Suggestions? Keith

2 4

Re: [trinity-devel] Can't compile gtk3-tqt-engine
by Darrell Anderson 30 Oct '13

30 Oct '13

>I can send you my build log when I am on a TDE machine. I need a sample build script more than a build log. >Anyhow have you tried to remove that /tde from the command line >and check if the package compiles? I have no idea how to do that because I don't from where this "/tde" is being defined. Darrell

1 0

Compiling qt4-tqt-theme-engine
by Darrell Anderson 30 Oct '13

30 Oct '13

Would somebody please post a build script for qt4-tqt-theme-engine? Thanks. :-) Darrell

2 1

Can't compile gtk3-tqt-engine
by Darrell Anderson 30 Oct '13

30 Oct '13

I need help compiling gtk3-tqt-engine. I run into the following error: gcc: error: /tde: No such file or directory Here are my configuration options: CFLAGS="$CPUOPT" \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} \ --mandir=${MANDIR} \ --with-qt-dir=${QTDIR} \ --with-qt-includes=${QT_INCLUDE_DIR} \ --with-qt-libraries=${QT_LIB_DIR} \ $DEBUG_AUTOTOOL_OPT || exit 1 Here is the build log: http://humanreadable.nfshost.com/misc/trinity-gtk3-tqt-engine- pre_R14.0.0-i486-14.0_32_git_2763_1-build.log The top of the build log shows the configuration variable assignments. I get the impression the build is looking for something like /opt/trinity/include/tde, which does not exist on my system, nor does /opt/trinity/include/trinity. Thanks much. :-) Darrell

2 1

Re: [trinity-devel] Fixed reaching fully activated state in screen saver
by Darrell Anderson 28 Oct '13

28 Oct '13

>As I now noticed a problem with the necessity of user input (for >interrupt the >screen saver) you reported also in the bug report 1615. It is >possible that >bug fixed in commit cbbc7ad0 could be related also with NFS on >/home? > >Can you try it? I created a test patch to restore autosupend in tdepowersave when $HOME is a network mount. I attached the patch to bug report 1623. After rebuilding tdelibs with the test patch, commit cbbc7ad0 does not resolve the problem of trying to autosuspend when $HOME is a network mount. Darrell

1 0

Re: [trinity-devel] Fixed reaching fully activated state in screen saver
by Darrell Anderson 28 Oct '13

28 Oct '13

>To test the problem, which was fixed, it is simple: >1) Make sure that you have enabled lock screen before suspend or >standby. >2) Set the screen saver run after a short time. >3) Once the screensaver is activated, press button to go into >suspend mode. Or >set in tdepowersave autosuspend for a short time => a little >longer than time >to activate screen saver. >4) Look, that nothing happens (for any length of time), until you >cause an >activity that will lead to stop screen saver. >5) Only after stopping screen saver follows immediately switch >into desired >suspend mode. I tested tdepowersave before applying the patch. In tdepowersave I set the screensaver to 1 minute and autosuspend to 2 minutes. Without the patch the following happens: * After 1 minute the screensaver starts. * After 2 minutes the suspend-to-ram 30 second timeout dialog does not appear. * Thereafter the laptop never automatically goes into suspend-to- ram mode by itself. * Any user action interrupts the screensaver. * The laptop then goes into suspend-to-ram mode and the suspend-to- ram 30 second timeout dialog never appears. With the patch: * After 1 minute the screensaver starts. * After 2 minutes the suspend-to-ram 30 second timeout dialog appears. * After 30 seconds the laptop automatically goes into suspend-to- ram mode by itself. * Upon restoring from suspend-to-ram, the screensaver lock dialog appears. Well done! Darrell

1 0

Re: [trinity-devel] Fixed reaching fully activated state in screen saver
by Darrell Anderson 28 Oct '13

28 Oct '13

>>As I now noticed a problem with the necessity of user input (for >>interrupt the >>screen saver) you reported also in the bug report 1615. It is >>possible that >>bug fixed in commit cbbc7ad0 could be related also with NFS on >>/home? >> >>Can you try it? > >To test, I believe we have to rebuild tdebase with commit cbbc7ad0 > >and rebuild tdelibs with commits 9d76cb9 reversed and possibly >ba6b2079 reversed. > >That is, to test whether commit cbbc7ad0 resolves the NFS problem >as well, we need to restore the ability to autosuspend in >tdepowersave when $HOME is an NFS mount. Currently that ability is > >disabled in tdepowersave through commit 9d76cb9. > >What do you think? > >If, after testing NFS $HOME with commit cbbc7ad0, bug report 1623 >still exists to address the NFS mount problem. The proposed >solution in 1623 is to study the KDE powerdevil code, which uses >upower. I tried for a few hours trying to rebuild packages with reversed patches, in the hopes of restoring autosuspend when $HOME is a network mount. I gave up as there are too many changes for my C++ skills to overcome. We can't test whether commit cbbc7ad0 resolves the problem until the autosuspend feature is restored to tdepowersave when $HOME is a network mount. I really want to see autosuspend work with tdepowersave when $HOME is a network mount. If you can restore autosuspend when $HOME is a network mount, then I'd be happy to retest tdepowersave with commit cbbc7ad0. Darrell

1 0

Compiling with gcc visibility enabled
by Darrell Anderson 27 Oct '13

27 Oct '13

All, Recently I stumbled across a bug with building tdeaddons. The resolution was to change in my build script --enable-gcc-hidden- visibility to --disable-gcc-hidden-visibility. We have bug report 1285 to address the problem of compiling with hidden symbol support but no work has proceeded with that report. Currently we have no dependable list of which packages to build with gcc visibility enabled. What is the safe/sane policy for our build scripts? Darrell

1 0

Re: [trinity-devel] Fixed reaching fully activated state in screen saver
by Darrell Anderson 27 Oct '13

27 Oct '13

>As I now noticed a problem with the necessity of user input (for >interrupt the >screen saver) you reported also in the bug report 1615. It is >possible that >bug fixed in commit cbbc7ad0 could be related also with NFS on >/home? > >Can you try it? To test, I believe we have to rebuild tdebase with commit cbbc7ad0 and rebuild tdelibs with commits 9d76cb9 reversed and possibly ba6b2079 reversed. That is, to test whether commit cbbc7ad0 resolves the NFS problem as well, we need to restore the ability to autosuspend in tdepowersave when $HOME is an NFS mount. Currently that ability is disabled in tdepowersave through commit 9d76cb9. What do you think? If, after testing NFS $HOME with commit cbbc7ad0, bug report 1623 still exists to address the NFS mount problem. The proposed solution in 1623 is to study the KDE powerdevil code, which uses upower. Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels