Bug 339021

For 0.6.0-0.1.XXX:

* Redundant BuildRequires
  - Some BuildRequires are redundant.
    * glib2-devel <- GConf2-devel requires this
    * gettext-devel - This doesn't seem to be needed. Mockbuild
                      succeeds without this.
      http://koji.fedoraproject.org/koji/taskinfo?taskID=202832

* Documents
  - "INSTALL" file should be removed. This is for people who
    want to compile and install this package by themselves and
    not needed for rpm users.
  - "AUTHORS" file is useless for this package...

removed the redundant BR & unneeded docs

http://izhar.fedorapeople.org/compizconfig-backend-gconf/compizconfig-backend-gconf-0.6.0-0.2.20071019git.fc8.src.rpm

Okay.

-------------------------------------------------------------------
   This package (compizconfig-backend-gconf) is APPROVED by me
-------------------------------------------------------------------

New Package CVS Request
=======================
Package Name: compizconfig-backend-gconf
Short Description: GConf backend for compizconfig
Owners: izhar
Branches: F-8 Devel
InitialCC: izhar
Cvsextras Commits: extras

cvs done.

Closing for now.

as ccsm is now in fedora 8 updates-testing it would be nice to push
compizconfig-backend-gconf there too, so one have the complete set of packages
to configure compiz with ccsm in fedora 8.

also i think compizconfig-backend-gconf needs the
compiz-gnome/compiz-fusion-gnome/compiz-fusion-extras-gnome gconf packages to
work. so maybe a dep on them would be ok?

From my testings so far, the gconf backend tends to crash the default compiz
installation, (the one loaded with 'glib gconf'). So far it serves nothing more
than a storage backend for libcompizconfig (which defaults uses flat .ini
format) and could not be used together with the current compiz configuration,
unless compiz is loaded with ccp instead of glib gconf. 

I've asked #compiz-fusion-dev and they replied that the gconf backend is only
working as a storage backend for 'compiz ccp' and not useable for 'compiz glib
gconf' ..

In your opinion, should i push this to stable eventhough that segfault issue
exist ?? (I don't feel like pushing it until it actually JustWorks).

(In reply to comment #8)
> (I don't feel like pushing it until it actually JustWorks).
Actually.

works OK here on fedora 8.

i grabbed compizconfig-backend-gconf from rawhide and ccsm from updates-testing.
in ccsm prefs i selected gconf-backend and disabled the plugin autoloading.
this fixed the issue with some plugins disabling themself and gtk-decorator not
showing the window border etc.

with this setup it works OK without any problems.


my installed components on fedora 8 are:
ccsm-0.6.0-3.fc8.noarch
compiz-0.6.2-3.fc8.x86_64
compizconfig-backend-gconf-0.6.0-1.fc9.x86_64
compizconfig-python-0.6.0-1.fc8.x86_64
compiz-fusion-0.6.0-5.fc8.x86_64
compiz-fusion-extras-0.6.0-1.fc8.x86_64
compiz-fusion-extras-gnome-0.6.0-1.fc8.x86_64
compiz-fusion-gnome-0.6.0-5.fc8.x86_64
compiz-gnome-0.6.2-3.fc8.x86_64
libcompizconfig-0.6.0-3.fc8.x86_64

@ Lars
are you running compiz using glib/gconf or compiz using ccp ? 

by "plugin autoloading" do you mean the option "Automatic plugin sorting" at  
Preferences > Plugin List ??

I tried these:
1. reset'ed my gconf configs @ /apps/compiz
2. loaded compiz using the desktop-effects menu (which runs compiz using glib/gconf)
3. opened ccsm, and switched the backend to gconf
4. enabled some plugins -> result -> compiz segfaults

When I disabled "Automatic plugin sorting",
- enabled manually plugins through the Plugin List -> it works
- however, we lots the ability to select plugins through the main UI, and also
lost the plugin dependency and conflicts check, user had to figure out which to
 enable, which not, and had to sort the plugin loading sequence by themselves.

is that what u meant?

@ Tasaka-san
if this package going to have the dependency to -gnome of compiz-fusion the
compiz packages, some users (though i think the possibility is, rare) might
install only compiz-fusion and not compiz-fusion-extras, 

a little confusion for me here,
should this package pull both compiz-fusion-gnome and compiz-fusion-extras-gnome
?? If i put a dependency like this, both compiz-fusion and compiz-fusion-extras
need to be pulled. If I put dependency to only compiz-fusion-gnome, users who
want to use compiz-fusion-extras had to pull the -gnome manually. 

If the first option is selected, if a new package of a different plugins set
appeared in the repo (eg: compiz-fusion-unsupported), should a dependency be
added in this package for the -gnome of the new package??.

Well,

(In reply to comment #11)
> @ Tasaka-san
> if this package going to have the dependency to -gnome of compiz-fusion the
> compiz packages, some users (though i think the possibility is, rare) might
> install only compiz-fusion and not compiz-fusion-extras, 
  I will leave it as how you judge.
  If we can install compizconfig-backend-gconf, compiz-fusion-gnome
  only and leave compiz-fusion-extras-gnome uninstalled, then
  this package should not require compiz-fusion-extras-gnome.

  One method is that
  - make compizconfig-backend-gconf require compiz-fusion-gnome only
  - create compizconfig-backend-gconf-extras subpackage with
    containing no files and make compizconfig-backend-gconf-extras
    require both compizconfig-backend-gconf ( =%{version}-%{release} )
    and compiz-fusion-extras-gnome

  ... if I understand what you mean.

> If the first option is selected, if a new package of a different plugins set
> appeared in the repo (eg: compiz-fusion-unsupported), should a dependency be
> added in this package for the -gnome of the new package??.

It depends on what you judge.
If you think that new different plugins should be installed
with compizconfig-backend-gconf by default, the new dependency
should be added.
If you think the new plugins are not needed for this package by
default, new dependency is not needed.

(In reply to comment #11)
> @ Lars
> are you running compiz using glib/gconf or compiz using ccp ? 

i'm using the gconf backend

> by "plugin autoloading" do you mean the option "Automatic plugin sorting" at  
> Preferences > Plugin List ??

yes

> I tried these:
> 1. reset'ed my gconf configs @ /apps/compiz
> 2. loaded compiz using the desktop-effects menu (which runs compiz using
glib/gconf)
> 3. opened ccsm, and switched the backend to gconf
> 4. enabled some plugins -> result -> compiz segfaults
> 
> When I disabled "Automatic plugin sorting",
> - enabled manually plugins through the Plugin List -> it works

i did exactly the same

> - however, we lots the ability to select plugins through the main UI, and also
> lost the plugin dependency and conflicts check, user had to figure out which to
>  enable, which not, and had to sort the plugin loading sequence by themselves.
> 
> is that what u meant?

yes, i too think that this plugin-autoload-workaround is only temporary,
but i'm glad i discovered it so it's at least working fine here.
maybe someone can fix this upstream?

By the way, currently what causes this bug still open?

i've moved the crash problem as another bug separate from this package review ..
#406771

closing this ..

Hi Mohd Izhar,

Is it ok for me to request a epel6 branch?

https://bugzilla.redhat.com/show_bug.cgi?id=677365

Thanks

Leigh

Package Change Request
======================
Package Name: compizconfig-backend-gconf
New Branches: el6
Owners: leigh123linux

Git done (by process-git-requests).