Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 209260 - Review Request: beryl-manager - Beryl window decorator and theme management utility
Summary: Review Request: beryl-manager - Beryl window decorator and theme management ...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michał Bentkowski
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On: 209259
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-10-04 06:15 UTC by Jarod Wilson
Modified: 2007-11-30 22:11 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-21 21:05:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
compiz integration (deleted)
2006-10-06 06:22 UTC, Sertaç Ö. Yıldız
no flags Details | Diff

Description Jarod Wilson 2006-10-04 06:15:51 UTC
Spec URL: http://wilsonet.com/packages/beryl/beryl-manager.spec
SRPM URL: http://wilsonet.com/packages/beryl/beryl-manager-0.1.0-1.fc6.src.rpm
Description:
--
Beryl is a combined window manager and compositing
manager that runs on top of Xgl or AIGLX using OpenGL
to provide effects accelerated by a 3D graphics card
on the desktop. Beryl is a community-driven fork of
Compiz.

Beryl-manager is a tray application to keep beryl
up and running, switch window managers, decorators,
launch beryl-settings and the beryl theme tool.
--

NOTE: This package depends on beryl-core, under review here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209259.

Comment 1 Jarod Wilson 2006-10-05 19:06:35 UTC
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

Comment 2 Sertaç Ö. Yıldız 2006-10-06 06:22:49 UTC
Created attachment 137896 [details]
compiz integration

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

Comment 3 Aurelien Bompard 2006-10-09 00:15:35 UTC
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

Comment 4 Jarod Wilson 2006-10-26 15:44:48 UTC
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).

Comment 5 Aurelien Bompard 2006-10-27 10:40:19 UTC
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

Comment 6 Thomas J. Baker 2006-11-02 16:09:04 UTC
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?

Comment 7 Stewart Adam 2006-11-06 23:54:56 UTC
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.

Comment 8 Jarod Wilson 2006-11-14 19:02:17 UTC
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.

Comment 9 Michał Bentkowski 2006-11-14 21:43:25 UTC
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?

Comment 10 Jarod Wilson 2006-11-14 22:21:31 UTC
(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.

Comment 11 Michał Bentkowski 2006-11-14 23:04:48 UTC
> 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.

Comment 12 Jarod Wilson 2006-11-15 15:38:30 UTC
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.

Comment 13 Jarod Wilson 2006-11-15 21:05:51 UTC
Importing into CVS now, requesting branching momentarily.

Comment 14 Michał Bentkowski 2006-11-16 15:48:34 UTC
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.

Comment 15 Sertaç Ö. Yıldız 2006-11-17 11:57:32 UTC
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.


Comment 16 Michał Bentkowski 2006-11-21 21:11:32 UTC
Hmmm... are you going to create a desktop file I mentioned above?

Comment 17 Jarod Wilson 2006-11-22 03:04:51 UTC
(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...

Comment 18 Michał Bentkowski 2006-11-22 19:11:42 UTC
(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.

Comment 19 Sertaç Ö. Yıldız 2006-11-22 19:33:11 UTC
(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).

Comment 20 Jarod Wilson 2006-11-22 19:42:47 UTC
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...

Comment 21 Michał Bentkowski 2006-11-22 21:21:33 UTC
(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.

Comment 22 Michał Bentkowski 2006-11-28 23:02:37 UTC
Is there any progress with language directories ownership?

Comment 23 Jarod Wilson 2006-12-12 16:32:21 UTC
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.

Comment 24 Jarod Wilson 2006-12-13 15:51:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.