I have put a significant amount of work into the QuickBuild system over
the past week in an attempt to stabilize it and increase performance.
While I am aware that there were some outages in random components (most
notably the PPA mirror redirects) while I was doing this, all issues
should be resolved at this point.
As of this writing four build machines are online, one for each
architecture. As we have reached the chiller fund goal (see prior
messages) the remaining x86/amd64 build machines will be brought back
online over the next couple weeks.
Please let me know what you think, and definitely let me know if anything
is still malfunctioning!
We have seen an error in Konqueror for the translation (french).
The expression "open in background tab" is not translate.
Tél. : 0659514624
Fresh clean build last night. I ran into two build failures with tdegames and tdeaddons:
/dev/shm/tdegames/kpat/freecell-solver/move.c:468: undefined reference to `convert_freecell_num'
/dev/shm/tdeaddons/atlantikdesigner/designer/designer.cpp:30:29: fatal error: atlantic/estate.h: No such file or directory
please can you test a set of patches from the bug report 2028? In my opinion,
the patches look good and I'm ready to push. Soon I make a test build on all
supported Debian and Ubuntu versions. So I would like if you can test some of
when I was preparing my small builder for 'R14 preliminary stable-builds'
alternative apt source, I did not plan other architectures than i386 and
amd64. But then I made a few tests to probe ways to also build both arm
architectures. The tests were successful, so they are now available all
architectures as on the build-farm.
Given that builds for other platforms are going pretty well, I tried one more
experiment. Because I have an older SGI Indy workstation, I tried on my small
builder to build packages in addition for MIPS architecture. And experiment
has succeeded. With little difficulty is now built 100% packages!
Graphics card on my SGI Indy hardware unfortunately only allows 8-bit color
depth, and as I found on this color depth many TDE application crashes - see
bug 2033. Attached screenshot is therefore from TightVNC server, where I set
a higher color depth. I note that this machine has only 64 MiB RAM, so it is
very slow. But it works!
Note: Packages for Wheezy on MIPS are available in my APT source. If someone
has a better hardware than my SGI Indy (about 1995), you can try it and let
know how it works for you :)
I tried to set the compositor to compton-tde and now instead of screensaver
Clock shows only black screen. In the test, the Clock is displayed correctly.
When I set the screensaver to Swarm, the bees appear, but background is not
erased - bees appears on the desktop background image. With screensaver
Science displays the background image, but it is not visible any further
activity. Some screensavers do not show problems - Fiberlamp, Galaxy.
Anyone notice the same behavior?
does anyone knows what would stop working if tdebindings is not installed?
And what would stop compiling is tdebindings is not available at compile time?
Just out of curiosity. I had a FTBFS yesterday night and this questions came to mind.
I've noticed that the new "compton" stuff (from tdebase package) does
not build on RHEL6 :
Linking C executable compton-tde
&& /usr/bin/cmake -E cmake_link_script
/usr/lib64/ccache/gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic -DNDEBUG -fvisibility=hidden -fvisibility-inlines-hidden
CMakeFiles/compton-tde.dir/opengl.c.o -o compton-tde -rdynamic -lm -lGL
-lconfig -lXinerama -lXrender -lX11 -lXrandr -lXfixes -lXdamage -lXfixes
-lXext -lXcomposite -lXdamage -lXext -lXcomposite
CMakeFiles/compton-tde.dir/compton.c.o: In function `parse_config':
undefined reference to `config_set_include_dir'
collect2: ld returned 1 exit status
make: *** [twin/compton-tde/compton-tde] Error 1
make: Leaving directory
make: *** [twin/compton-tde/CMakeFiles/compton-tde.dir/all] Error 2
make: Leaving directory
make: *** [all] Error 2
make: Leaving directory
The libconfig version is 1.3.2 .
There is no "config_set_include_dir" anywhere in /usr/include/* .
Please, either find a way to build on older distro, or make the whole
feature optional (with a cmake option).
I'm back - I hope. What started as a planned week "family trip" (not exactly
vacation -- 3 kids, car 16 hour road trip)( was actually great), but on return
left us a week behind in all other aspects of life, with a case scheduled for
4/21 multiple depos remaining, pre-trial, etc.. -- then my client had a stroke.
(enough said, but I'm just finally getting unburried in time for taxes :-)
Slavek, have you had a chance to look at bug 1998. I am stuck after
implementing the k4 multiseat patches in TDE, which compile beautifully and
appear to solve part of the problem with tde_dbus_hardwarecontrol, but I am lost
following the effects of the patch through the remainder of the code. (the
patches include a new tdebase/cmake/modules/FindSystemd.cmake, that makes
systemd available to cmake when found on the target system) I need help getting
this patch implemented. TDE is NOT enterprise ready without it. TDE must allow
user access to sound, user mount (cd/dvd/usb, etc..) via normal udev/polkit, and
must prevent the race conditions with tdehwlib/tdepowersave, etc. with the purse
systemd implementation. Right now it doesn't.
To be blunt, TDE is unusable on pure systemd distros like Arch due to these
problems and I can't release TDE to Arch as usable until we get some way of
solving this problem. Right now I can build and run TDE, but it takes ugly hacks
to provide user access to sound or cd/dvd/usb. (essentially add every user to
the audio, sys and disk groups just to get access which is a glaring no-no)
Additionally, you have to disable tdepowersave to prevent filling the logs with
hundreds-of-thousands of errors (per hour).
So far all examples that have been provided where TDE 'works' with systemd
have NOT been systemd implementations, but instead init-script implementations
of TDE that hand off control to systemd-sysvcompat, not true services where
'systemctl start tdm.service' is used to launch tde/tdm directly by systemd
itself. The init-script case is not systemd, but the compatibility mode for the
old init-script implementation. Many distros are working through the transition
and will be pure-systemd in the very near future (even Debian:
https://wiki.debian.org/systemd). So we need to get this fixed. Let's get a plan
together for testing/implementing the needed fix. I'm happy to do the work, but
it is not something I can do myself in any reasonable amount of time. I need
help finding/following all the needles through the TDE haystack. Let me know
when you have a bit of time to devote to the issue. All help is welcome.
David C. Rankin, J.D.,P.E.