Bug 209260

Just uploaded a -2 build of beryl-manager that fixes a pathless reference to 
pidof (not in normal users path) and adds gnome-window-manager and compiz to the
beryl-manager menu (tested it out, works great, only caveat is that when
changing from beryl to compiz, you need to switch from beryl/emerald to
beryl/gnome-window-decorator to compiz, or the window decorations in compiz get
tanked).

http://wilsonet.com/packages/beryl/beryl-manager.spec
http://wilsonet.com/packages/beryl/beryl-manager-0.1.0-2.fc6.src.rpm

Created attachment 137896 [details]
compiz integration

With this patch it can switch to gnome-window-decorator if compiz is selected

I needed to add this patch to make it build on FC5 :
http://gauret.free.fr/fichiers/rpms/fedora/xgl/beryl-manager-0.1.0-intltool.patch

Aurelien, can you double-check if that patch is still required for beryl-manager
0.1.1? I've just pushed out a 0.1.1 build, but don't have an FC5 machine handy
at the moment, nor the time to get one mocked up. :)

http://wilsonet.com/packages/beryl/beryl-manager-0.1.1-1.fc6.src.rpm

As for the compiz integration (comment #2), I believe we should have inherited
that same support by moving to 0.1.1 (will double-check when I have a chance).

Yes, it's still needed:
checking for intltool >= 0.35.0... 0.34.2 found
configure: error: Your intltool is too old.  You need intltool 0.35.0 or later.

It builds fine with intltool 0.34.2 and my patch however. Patch updated here:
http://gauret.free.fr/fichiers/rpms/fedora/xgl/beryl-manager-0.1.1-intltool.patch

From the current repo version, using beryl-manager to switch to compiz fails for
me. Could be a gnome-window-decorator bug since it seems the --replace switch is
not replacing emerald. 

Selecting compiz with COW breaks compiz such that it won't actually work again
until you reset the /apps/compiz/general/allscreens/options/active_plugins key
to default values. 

I've had these two problems on both intel and nvidia hardware. I'm not sure if
these are upstream bugs or FC6 specific ones. 

Unfortunately for me, beryl on my dual head nvidia box also seems to make many
windows just black (firefox particularly). One reason for me to use it is for
better xinerama support. I don't see this black window problem on my single head
nvidia box or my intel laptop. Is there a place to talk about problems with
these rpms on FC6?

They work well here, but I think there's still a few bugs to be ironed out. If I
set "beryl-manager" to load on login (Gnome 2.16, FC6, nVidia card) about half
the time I get windows that show their contents, but that are unresponsive and
the window borders flicker on and off. My CPU monitor applet shows 100% use.
Reloading the WM or doing ctrl + alt + F1 and then ctrl + alt + F7 hangs the
machine.

Latest build, uses upstream tarballs, since they finally started making them:

http://wilsonet.com/packages/beryl/beryl-manager-0.1.2-2.fc6.src.rpm

As for where to talk about problems with running the software, that would
probably be best to take upstream to http://forums.beryl-project.org/,
http://bugs.bery-project.org/ or #bery on irc.freenode.net, at least until such
time as these packages are actually part of Fedora Extras.

MUST items:
 * rpmlint is quiet
 * package is named well
 * spec file name is good
 * package meets Packaging Guidelines
 * package is licensed with a GPL open-source compatible license 
 * License field in spec file matches actual license
 * license file is included in %doc
 * md5sums are matching (50c0235d59369674827ceaec7d36e53b)
 * package successfully compiles on x86_64
 * BuildRequires listed well (mock builds succesfully)
 * spec file handles locales properly
 * no need to %post and %postun sections
 * not relocatable
 * package owns directories well
 * no duplicates in %files
 * every %files section includes %defattr
 * proper %clean section
 * macros used well

Package looks almost well.
I haven't checked the another beryl packages yet, but you
use Provides: beryl in beryl-core package and here you're using
Requires: beryl-core. Maybe Requires: beryl would be better?
And the another thing: if a normal user type `yum install beryl`,
he won't get working beryl environment. He'll get only a beryl-core
package which alone is useless. Maybe you should create dependencies
differently to make possibility to install all essential beryl packages
by simply typying `yum install beryl`? How do you think?

(In reply to comment #9)
> Package looks almost well.
> I haven't checked the another beryl packages yet, but you
> use Provides: beryl in beryl-core package and here you're using
> Requires: beryl-core. Maybe Requires: beryl would be better?

I'm thinking stick with beryl-core in the sub-packages, for the reason below...

> And the another thing: if a normal user type `yum install beryl`,
> he won't get working beryl environment. He'll get only a beryl-core
> package which alone is useless. Maybe you should create dependencies
> differently to make possibility to install all essential beryl packages
> by simply typying `yum install beryl`? How do you think?

I initially did Provides: beryl in beryl-core because it seemed right at the
time. It did cross my mind the other day to perhaps switch to a beryl
meta-package that Requires: all the beryl components. Only downside with that is
that it can suck in a fair amount of stuff now that people may not want if
they're running one desktop or another (i.e. kde vs. gnome, where aquamarine
Requires: some kde stuff, heliodor Requires: some gnome stuff). Could do three
meta-packages, beryl, which in turn Requires: beryl-kde and beryl-gnome, which
in turn Requires: packages appropriately for each DE.

Some scheme along these lines definitely seems better than beryl-core Provides:
beryl, which does indeed provide nothing of use in the case of a user yum
installing only beryl.

> I initially did Provides: beryl in beryl-core because it seemed right at the
> time. It did cross my mind the other day to perhaps switch to a beryl
> meta-package that Requires: all the beryl components. Only downside with that 
is
> that it can suck in a fair amount of stuff now that people may not want if
> they're running one desktop or another (i.e. kde vs. gnome, where aquamarine
> Requires: some kde stuff, heliodor Requires: some gnome stuff). Could do three
> meta-packages, beryl, which in turn Requires: beryl-kde and beryl-gnome, which
> in turn Requires: packages appropriately for each DE.

It sounds wisely for me, I think it's a good solution.

Okay, just pushed a build of beryl-core for devel that creates a beryl package
that depends on beryl-gnome, beryl-kde and bdock, then beryl-gnome and beryl-kde
packages that depend on all their respective bits. Basically, yum install
beryl-gnome gives you everything but bdock and aquamarine, yum install beryl-kde
gives you everything but bdock and heliodor, and yum install beryl gives you the
kitchen sink.

Importing into CVS now, requesting branching momentarily.

After a little testing of this package I think that it should have its own
desktop file. It is tray application so user should have a possibility to
run it from menu.

Are the names of these po/mo files correct?
ar_AR, tr_TR, my_MY etc.

They are creating new directories under /usr/share/locale that no package own.

Hmmm... are you going to create a desktop file I mentioned above?

(In reply to comment #16)
> Hmmm... are you going to create a desktop file I mentioned above?

Whoops, yes, been meaning to address that, its still on my todo list. I need to dig up a high(er) resolution 
beryl icon and throw it in there. I'll see what I can do on that front tonight or tomorrow. I also still need to 
look into the po/mo files being created...

(In reply to comment #17)
> Whoops, yes, been meaning to address that, its still on my todo list. I need 
to dig up a high(er) resolution 
> beryl icon and throw it in there.

I found beryl .svg icon here: http://tinyurl.com/y6xg3e and it seems to me that
it may come in useful :)

(In reply to comment #17)
> I also still need to 
> look into the po/mo files being created...

I have checked it and I found that:
 * tr_TR is Turkish
 * gl_ES is Gallegan (Spain)
 * sk_SK is Slovakian
 * sv_FI is Swedish (Finland)

These languages dirs without doubt should be owned by another packages, but
(I checked it) they aren't. ar_AR is probably Arabic but no idea what my_MY is.

(In reply to comment #18)
> I have checked it and I found that:
>  * tr_TR is Turkish

tr_TR is for turkish but the translation catalogs for turkish is named tr and
installed under /usr/share/locale/tr/ which is owned by filesystem rpm.

I guess xx_XX should be renamed to xx and for other translation catalogs
directories should be owned. But I'm not sure about the standards of this naming
scheme as filesystem installs both fr and fr_FR directories (although on my
system only beryl/emerald packages consume the latter).

Just pushed a new beryl-manager build with a desktop file added, still need to
address the lang stuff. I noticed the same thing -- that some of the xx_XX ones
looked like they could simply be renamed to xx, but not sure what's up with the
others. Looks like I'll need to talk with the owner of filesystem and/or our
translation folks...

(In reply to comment #20)
> Just pushed a new beryl-manager build with a desktop file added, still need to
> address the lang stuff. I noticed the same thing -- that some of the xx_XX 
ones
> looked like they could simply be renamed to xx, but not sure what's up with 
the
> others.

It may be especially difficult with Swedish language, as there are Swedish
Finland and Swedish Sweden language. In fact, I don't think the Swedish Finland
is really needed ;)
In my opinion these languages need to be updated in filesystem package.

Is there any progress with language directories ownership?

Blah, sorry for the delayed response. I've been completely tied up with another
project (my "day job" deals mostly w/the rhel kernel, not fedora). I hope to be
able to look at this today, along with hopefully spinning 0.1.3 packages.

Okay, in the forthcoming 0.1.3 build, xy_XY translations have all been moved to
just xy, where they really ought to be. The remaining unowned translation
directories will be added to the filesystem package, once I've collected all of
them from all the latest beryl components.