-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224

...

I've noticed that the new "compton" stuff (from tdebase package) does not build on RHEL6 :

Linking C executable compton-tde cd "/dev/shm/BUILD.el6.x86_64/trinity-tdebase-14.0.0~pre1185+8083ca83/build/twin/compton-tde" && /usr/bin/cmake -E cmake_link_script CMakeFiles/compton-tde.dir/link.txt --verbose=1 /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 -DNDEBUG CMakeFiles/compton-tde.dir/c2.c.o CMakeFiles/compton-tde.dir/compton.c.o 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 -Wl,-rpath,:::::::::::::::::: CMakeFiles/compton-tde.dir/compton.c.o: In function `parse_config': /dev/shm/BUILD.el6.x86_64/trinity-tdebase-14.0.0~pre1185+8083ca83/twin/compton-tde/compton.c:5580: undefined reference to `config_set_include_dir' collect2: ld returned 1 exit status make[3]: *** [twin/compton-tde/compton-tde] Error 1 make[3]: Leaving directory `/dev/shm/BUILD.el6.x86_64/trinity-tdebase-14.0.0~pre1185+8083ca83/build' make[2]: *** [twin/compton-tde/CMakeFiles/compton-tde.dir/all] Error 2 make[2]: Leaving directory `/dev/shm/BUILD.el6.x86_64/trinity-tdebase-14.0.0~pre1185+8083ca83/build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/dev/shm/BUILD.el6.x86_64/trinity-tdebase-14.0.0~pre1185+8083ca83/build'

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).

More importantly, I thought we were in a feature freeze.

Darrell

I'm working on the FTBFS.

OK, here's my argument for letting compton-tde through. You can override me if you want. :-)

1.) kompmgr has a critical bug where, after a certain amount of time, popup menus will stop displaying. I have tried and tried to repair this, but have had no success in over 12 months of sporadic work. This bug alone means kompmgr should be marked for developers only in R14, but if that were done TDE would have no fully compatible compositors available for end users. I saw compton as a way out. ;-) 2.) compton-tde is pretty much feature-equivalent to kompmgr (it was derived from xcompmgr just like kompmgr was), but has a whole ton of bug fixes from a dedicated team working on it for over two years. 3.) kompmgr and compton-tde are both standalone binaries that do not interface with any TDE code (their "interfaces" are one configuration file and several Xorg atoms). After the FTBFS is repaired the effect of changing one out for the other (aside from the bug fixes and performance improvements in compton) should be minimal to nonexistent.

Let me know what you think!

Tim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224

...

More importantly, I thought we were in a feature freeze. Darrell

I would like to avoid one of those big discussions that sometimes get started, but I fully agree with Darrell. We set a freeze state to focus on the finalization of the 14.0.0 release, trying to avoid last minute major changes. The point is to avoid repeating the same pattern followed last year, where freeze state was declared in July and then renames, changes, additions .... were applied, basically resulting in a cancellation of the freeze state.

Cheers Michele

I can disable the compton-tde build if required (it's a one-line patch), this is not a problem. However, bear in mind that I did the because I don't want to release kompmgr with R14 due to its myriad user-visible problems. As a result, we would have *no* TDE-compatible compositor officially available if compton-tde is disabled, forcing users to either use kwin instead of twin or compile kompmgr/compton-tde manually if they want compositing. I personally see this kind of thing as something the distro maintainers would likely override (with a small distro-specific patch) for a better user experience regardless of what we choose. Remember as well that kompmgr always was alpha-level software, and that by switching to compton-tde we are keeping feature parity but gaining stability (I personally would rate compton-tde as beta quality with the possibility to go to stable class in the release after R14).

To avoid any long discussions, how about the main dev team (myself, Darrell, Slavek, and you) simply cast votes on this one-time override?

My vote: switch to compton-tde as the official compositor, but do not disable or delete the kompmgr sources until the next release after R14.

Tim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224

...

To avoid any long discussions, how about the main dev team (myself, Darrell, Slavek, and you) simply cast votes on this one-time override? My vote: switch to compton-tde as the official compositor, but do not disable or delete the kompmgr sources until the next release after R14.

Hi Tim, I understand the reasons why you added compton-tde.

I am not an expert on compositors. From a release point of view, I would prefer a more conservative approach, to avoid introducing potential new bugs just a few months before a major release that could affect TDE reviews in a negative way. We should consider releasing v14.0.0 using kompmgr as the official compositor, but keeping the compton-tde code in the repo and plan the switch for v14.1.0, so we will have enough time to test compton throughly.

I was hoping I could fix the menu disappearing bug in kompmgr, but I couldn't. After watching several users on R14 not know why their menus were randomly not appearing and hard rebooting off their computers (the logoff/reboot option is normally available from Kicker, which is a popup menu), I realized that this was a significant usability issue that should block the R14 release.

Anyhow, if you think that compton-tde is stable enough to be used as the official compositor, I will second your thoughts and agree with its inclusion, because you have already done a lot of work on it and because it is going to take at least 3 months before v14.0.0 is ready, so there is still time to fix eventual small problems. But if we start to see several new issues, we should consider reverting to kompmgr for v14.0.0, as said above.

Agreed.

On a side note, IMO between here and the v14.0.0 release date it would perhaps be better to discuss all together in advance if we have other major changes in mind.

Agreed again. I am just getting back into the swing of things here on the TDE project (life is finally allowing this!) and didn't think twice about the commit--all those years where TDE was primarily a one man show make it hard to break old habits. ;-) My apologies for introducing confusion.

Tim

Hi, there...

Now there are some more cmake/build related problems around the compton... First of all, now it requires libconfig, xinerama, xrandr and opengl as nonoptional dependencies. I insist that they should be build-time tweakable with common cmake flags. It seems that xrandr is not required at build time at all... xinerama and opengl may be easily tweaked... but I'm a bit concerned about the libconfig. Is there any way to config it without the lib and do we need this configuration file for TDE to operate fine? Secondly, it uses it's own CONFIG_* defines rather than tde's HAVE_*/WITH_*. Is there any reasons to keep CONFIG_-style options?

I'll try prepare some patches...

2014-04-06 1:05 GMT+04:00 Fat-Zer fatzer2@gmail.com:

I'll try prepare some patches...

Here is proposed patchset...