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 195292 (openbox) - Review Request: Openbox
Summary: Review Request: Openbox
Keywords:
Status: CLOSED ERRATA
Alias: openbox
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris Ricker
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT obconf
TreeView+ depends on / blocked
 
Reported: 2006-06-14 18:06 UTC by Peter Gordon
Modified: 2014-09-12 13:47 UTC (History)
4 users (show)

Fixed In Version: openbox-3.5.0-4.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-06-29 04:43:15 UTC
Type: ---
Embargoed:
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Peter Gordon 2006-06-14 18:06:01 UTC
[ Recreating this review request as Bugzilla's DB had hardware troubles which lost it. ]

I intend to unorphan and maintain Openbox in Fedora Extras. 

Spec URL: http://thecodergeek.com/downloads/fedora/openbox.spec
SRPM URL: http://thecodergeek.com/downloads/fedora/openbox-3.3-0.rc2.1.src.rpm

Description: Openbox is a window manager for X11 designed to be
standards-compliant while staying fast and highly configurable.

Comment 1 Peter Gordon 2006-06-14 18:11:52 UTC
------- Additional Comments From jtorresh  2006-06-12 19:55 EST -------
I don't know if this suggestion belongs in a package-review, but it'd be great
if you could include an openbox.desktop file to be installed in
/usr/share/xsessions (just like the fluxbox package does) so openbox can be
selected from the "Sessions" list in GDM, instead of having to edit who knows
what file by hand.

By the way, I'm glad you're going to unorphan this package. I love Openbox :)



------- Additional Comments From che666  2006-06-12 22:12 EST -------
id also say a gdm entry is necassery.


------- Additional Comments From peter  2006-06-12 23:31 EST
-------
Thanks. Added it in 3.3-0.rc2.2, as suggested.

Spec: http://thecodergeek.com/downloads/fedora/openbox.spec
SRPM: http://thecodergeek.com/downloads/fedora/openbox-3.3-0.rc2.2.src.rpm


------- Additional Comments From jtorresh  2006-06-13 00:53 EST -------
Hi,

I could be wrong but as far as I understand the NamingGuidelines, this package
should have a Release tag similar to "0.2.rc2" instead of "0.rc2.2".

The relevant part from the NamingGuidelines:

"Release Tag for Pre-Release Packages:
   0.%{X}.%{alphatag}
Where %{X} is the release number increment, and %{alphatag} is the string that
came from the version."

Please correct me if I'm mistaken.


------- Additional Comments From peter  2006-06-13 01:18 EST
-------
Jorge,

You are correct about that. I mistakenly thought otherwise; but I checked the
guidelines and that's what it should be. I've uploaded new sources to fix this:

Spec: http://thecodergeek.com/downloads/fedora/openbox.spec
SRPM: http://thecodergeek.com/downloads/fedora/openbox-3.3-0.3.rc2.src.rpm

Thanks.

Comment 2 Chris Ricker 2006-06-15 20:20:20 UTC
Musts:

- rpmlint has two complaints:

$ rpmlint SRPMS/openbox-3.3-0.3.rc2.src.rpm 
W: openbox strange-permission openbox.desktop 0775
$ rpmlint RPMS/i386/openbox-*
E: openbox script-without-shellbang /usr/share/xsessions/openbox.desktop

the SRPM one is valid -- openbox.desktop doesn't need be executable in the
source tree and doesn't appear to need to be executable even when installed (gdm
still works with that session with it set to 0644)

the script-without-shellbang appears to be bogus

+ package name is fine
+ spec file name is fine
+ package meets packaging guidelines
+ license is open source
+ license is correct
+ license is included
+ spec is English
+ spec is legible

it could be simpler if the conditionalized epoch stuff were left out for the
-devel package, if the version macroization were calmed down (the package
releases every two years, so updating versions isn't that big a deal ;-), and if
the x requires stuff weren't conditionalized since you'll have separate specs in
each branch anyway. Not a big deal though

+ source matches upstream

$ md5sum openbox-3.3-rc2.tar.gz ../SOURCES/openbox-3.3-rc2.tar.gz
1ff100d27cc1f47dadebb884a696dac3  openbox-3.3-rc2.tar.gz
1ff100d27cc1f47dadebb884a696dac3  ../SOURCES/openbox-3.3-rc2.tar.gz
$

+ package builds
+ no archs excluded
+ BuildRequires complete
+ locales dealt with
+ shared libraries dealt with

- package dir ownership is broken for the theme files:

/usr/share/themes/Allegro/openbox-3/bullet.xbm
/usr/share/themes/Allegro/openbox-3/themerc
/usr/share/themes/Artwiz/openbox-3/themerc
/usr/share/themes/Blah41/openbox-3/themerc
/usr/share/themes/Om4Ob/openbox-3/close.xbm
/usr/share/themes/Om4Ob/openbox-3/close_hover.xbm
/usr/share/themes/Om4Ob/openbox-3/desk.xbm
/usr/share/themes/Om4Ob/openbox-3/desk_hover.xbm
/usr/share/themes/Om4Ob/openbox-3/desk_toggled.xbm
/usr/share/themes/Om4Ob/openbox-3/iconify.xbm
/usr/share/themes/Om4Ob/openbox-3/iconify_hover.xbm
/usr/share/themes/Om4Ob/openbox-3/iconify_pressed.xbm
/usr/share/themes/Om4Ob/openbox-3/max.xbm
/usr/share/themes/Om4Ob/openbox-3/max_disabled.xbm
/usr/share/themes/Om4Ob/openbox-3/max_hover.xbm
/usr/share/themes/Om4Ob/openbox-3/max_pressed.xbm
/usr/share/themes/Om4Ob/openbox-3/max_toggled.xbm
/usr/share/themes/Om4Ob/openbox-3/shade.xbm
/usr/share/themes/Om4Ob/openbox-3/shade_disabled.xbm
/usr/share/themes/Om4Ob/openbox-3/shade_hover.xbm
/usr/share/themes/Om4Ob/openbox-3/shade_toggled.xbm
/usr/share/themes/Om4Ob/openbox-3/themerc
/usr/share/themes/TheBear/openbox-3/themerc

needs to own Allegro, Artwiz, etc and openbox-3 dirs

+ no duplicated files

- permissions need fixing for openbox.desktop in SRPM and possibly in RPM

+ %clean fine
+ macros fine
+ package is code
+ no large docs
+ no inappropriate %doc
+ headers in -devel
+ .pc in -devel
+ correct library split between base and -devel
+ devel require of base is correct
+ .la excluded
+ no Gnome desktop-file needed
+ doesn't incorrectly own dirs

Shoulds:

+ builds in mock
+ software works


Looks pretty good -- only changes required are fixing theme file directory
ownership and the permissions on the desktop file

Comment 3 Ville Skyttä 2006-06-15 21:05:31 UTC
(In reply to comment #2)
> the script-without-shellbang appears to be bogus

Nope, see "rpmlint -I script-without-shellbang"


Comment 4 Chris Ricker 2006-06-15 21:09:19 UTC
> Nope, see "rpmlint -I script-without-shellbang"

I'm not sure if the desktop files for gdm session selection need to be
executable or not. If they don't, it's right. If they do, it's bogus

Every one on the systems I looked at was executable, but they appear to still
work if made non-executable....

Comment 5 Peter Gordon 2006-06-18 23:21:28 UTC
(In reply to comment #2)
> $ rpmlint SRPMS/openbox-3.3-0.3.rc2.src.rpm 
> W: openbox strange-permission openbox.desktop 0775

I based the permissions on the fact that both the gnome.desktop (provided in the
Core gnome-session package) and fluxbox.desktop (from fluxbox in Extras) both
install it as world-executable. I've changed that in %install to 0644
tentatively; but is there some specific guidelines on this? A search on the Wiki
didn't return anything helpful.


> $ rpmlint RPMS/i386/openbox-*
> E: openbox script-without-shellbang /usr/share/xsessions/openbox.desktop

Making it non-executable appears to have quieted rpmlint.


> it could be simpler if the conditionalized epoch stuff were left out for the
> -devel package

Done. 


> if the version macroization were calmed down (the package
> releases every two years, so updating versions isn't that big a deal ;-)

Though I don't see anything particularly wrong with it, I'll see if I can clean
it up a little.


> and if
> the x requires stuff weren't conditionalized since you'll have separate specs in
> each branch anyway. Not a big deal though.

With all due respect, I like to keep the spec files between branches similar if
not the same, as it makes it simpler for me to maintain. Also, I wrote the spec
file thinking somewhat of portability to other RPM-driven distros too, and this
would help alleviate the dependencies there. Please let me know if this is
improper to do, and I'll unconditionalize the BR (using the xorg-x11-devel on
the FC-4 branch and the modular X.org stuff on FC-5 and higher).


> - package dir ownership is broken for the theme files:
> [...]
> needs to own Allegro, Artwiz, etc and openbox-3 dirs

My reasoning for this is that other packages might also use themes named
Allegro, Artwiz, etc.; so by only owning the openbox-3 directories within each,
other such packages could interact with this in a well-behaved manner. Or, is it
preferred to share the directory ownership between theme packages?


> Looks pretty good -- only changes required are fixing theme file directory
> ownership and the permissions on the desktop file

Thanks for your comments and advice.

I posted and updated package (3.3-0.4.rc2) with the permissions issue fixed.

SRPM: http://www.thecodergeek.com/downloads/fedora/openbox-3.3-0.4.rc2.src.rpm
Spec: http://www.thecodergeek.com/downloads/fedora/openbox.spec

Comment 6 Peter Gordon 2006-06-18 23:26:01 UTC
(That should be "I posted an updated [...]".)

Comment 7 Chris Ricker 2006-06-19 13:37:52 UTC
For the desktop file, I'd say make it non-executable until someone finds a
reason it has to be executable. I'll see if I can find more on that one

For the conditionalization, etc. that's personal taste -- whatever works best
for you as long as its consistent. Simpler's generally better, and worrying
about portability to other distros is generally more trouble than its worth, but
again that stuff is personal preference

For the dir ownership the problem is that currently no package owns those
directories. No ownership at all is a much bigger problem than multiple packages
owning them (though neither's ideal):

[kaboom@fc5test ~]$ rpm -qf /usr/share/themes/Allegro
/usr/share/themes/Allegro/openbox-3
file /usr/share/themes/Allegro is not owned by any package
file /usr/share/themes/Allegro/openbox-3 is not owned by any package
[kaboom@fc5test ~]$ 

That's the only must-fix left

Comment 8 Peter Gordon 2006-06-20 01:30:43 UTC
Now I see my mistake with regards to the theme ownership: I globbed the contents
of the directories, but not those directories themselves. Should I be owning the
entire theme folders (i.e., "%{_datadir}/themes/*/") or only the openbox-3
subdirectories in each? 

Comment 9 Chris Ricker 2006-06-20 17:36:54 UTC
Something has to own:

/usr/share/themes/Allegro
/usr/share/themes/Allegro/openbox-3

(and likewise for every other theme)

It should probably be your package, unless theres some reason it can't be.
Openbox 3 themes aren't compatible with styles for blackbox or its derivatives
so you can't share them....

Comment 10 Peter Gordon 2006-06-21 03:13:51 UTC
Thanks. I've posted 3.3-0.5.rc2 which owns the entire theme directories created. 

Spec: http://thecodergeek.com/downloads/fedora/openbox.spec
SRPM: http://thecodergeek.com/downloads/fedora/openbox-3.3-0.5.rc2.src.rpm

Comment 11 Chris Ricker 2006-06-22 20:24:16 UTC
sorry, it looks like there is one more Requires needed -- /usr/share/themes
winds up unowned unless you have redhat-artwork installed

Other than that, looks good

Comment 12 Peter Gordon 2006-06-24 22:30:17 UTC
Thanks. I added that as a Requires for 3.3-0.6.rc2, as suggested.

Spec: http://www.thecodergeek.com/downloads/fedora/openbox.spec
SRPM: http://www.thecodergeek.com/downloads/fedora/openbox-3.3-0.6.rc2.src.rpm

Comment 13 Chris Ricker 2006-06-27 02:24:15 UTC
I noticed one final unowned dir and then it should be good:

/usr/share/gnome/wm-properties

That one I think you should just own -- it looks like each wm that supports
Gnome puts files in there, and since none of the Gnome packages appear to create
it, each wm will have to own it....

I'll go ahead and approve, so just fix that before you build

Comment 14 Peter Gordon 2006-06-27 05:49:04 UTC
Thank you for the review, Chris. I've added that directory to the %files section
in 3.3-0.7.rc2, which is what I will commit to CVS.

Spec: http://thecodergeek.com/downloads/fedora/openbox.spec
SRPM: http://thecodergeek.com/downloads/fedora/openbox-3.3-0.7.rc2.src.rpm

Comment 15 Peter Gordon 2006-06-29 04:43:15 UTC
Imported, cleaned up a bit, and built for FC-4, FC-5 and devel. Thanks for your
time!

Comment 16 Christian Iseli 2006-12-31 11:32:37 UTC
Please do not remove the FE-ACCEPT blocker.  Thanks.


Comment 17 Peter Gordon 2007-06-02 21:21:05 UTC
Package Change Request
======================
Package Name: openbox
Updated Fedora Owners: extras-orphan


I'm orphaning openbox, obconf, and obmenu as I no longer use them and feel that
my time is better spent dedicated to my other packages. Thanks.

Comment 18 Tom "spot" Callaway 2007-06-04 21:53:21 UTC
Orphaned.

Comment 19 Miroslav Lichvar 2007-06-13 08:06:54 UTC
Package Change Request
======================
Package Name: openbox
Updated Fedora Owners: mlichvar

Comment 20 Miroslav Lichvar 2012-02-21 08:53:15 UTC
Package Change Request
======================
Package Name: openbox
New Branches: el6
Owners: mlichvar splinux

Comment 21 Gwyn Ciesla 2012-02-21 13:37:55 UTC
Git done (by process-git-requests).

Comment 22 Fedora Update System 2012-02-23 19:12:59 UTC
openbox-3.5.0-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/openbox-3.5.0-4.el6

Comment 23 Fedora Update System 2012-03-11 18:52:05 UTC
openbox-3.5.0-4.el6 has been pushed to the Fedora EPEL 6 stable repository.

Comment 24 Miroslav Lichvar 2014-09-12 10:58:48 UTC
Package Change Request
======================
Package Name: openbox
New Branches: el7
Owners: mlichvar

Comment 25 Gwyn Ciesla 2014-09-12 11:59:10 UTC
Git done (by process-git-requests).


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