Bug 195292 - (openbox) Review Request: Openbox
Review Request: Openbox
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Ricker
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT obconf
  Show dependency treegraph
 
Reported: 2006-06-14 14:06 EDT by Peter Gordon
Modified: 2014-09-12 09:47 EDT (History)
4 users (show)

See Also:
Fixed In Version: openbox-3.5.0-4.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-29 00:43:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Peter Gordon 2006-06-14 14:06:01 EDT
[ 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 14:11:52 EDT
------- Additional Comments From jtorresh@gmail.com  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@gmail.com  2006-06-12 22:12 EST -------
id also say a gdm entry is necassery.


------- Additional Comments From peter@thecodergeek.com  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@gmail.com  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@thecodergeek.com  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 16:20:20 EDT
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 17:05:31 EDT
(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 17:09:19 EDT
> 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 19:21:28 EDT
(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 19:26:01 EDT
(That should be "I posted an updated [...]".)
Comment 7 Chris Ricker 2006-06-19 09:37:52 EDT
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-19 21:30:43 EDT
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 13:36:54 EDT
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-20 23:13:51 EDT
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 16:24:16 EDT
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 18:30:17 EDT
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-26 22:24:15 EDT
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 01:49:04 EDT
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 00:43:15 EDT
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 06:32:37 EST
Please do not remove the FE-ACCEPT blocker.  Thanks.
Comment 17 Peter Gordon 2007-06-02 17:21:05 EDT
Package Change Request
======================
Package Name: openbox
Updated Fedora Owners: extras-orphan@fedoraproject.org


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 17:53:21 EDT
Orphaned.
Comment 19 Miroslav Lichvar 2007-06-13 04:06:54 EDT
Package Change Request
======================
Package Name: openbox
Updated Fedora Owners: mlichvar@redhat.com
Comment 20 Miroslav Lichvar 2012-02-21 03:53:15 EST
Package Change Request
======================
Package Name: openbox
New Branches: el6
Owners: mlichvar splinux
Comment 21 Jon Ciesla 2012-02-21 08:37:55 EST
Git done (by process-git-requests).
Comment 22 Fedora Update System 2012-02-23 14:12:59 EST
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 14:52:05 EDT
openbox-3.5.0-4.el6 has been pushed to the Fedora EPEL 6 stable repository.
Comment 24 Miroslav Lichvar 2014-09-12 06:58:48 EDT
Package Change Request
======================
Package Name: openbox
New Branches: el7
Owners: mlichvar
Comment 25 Jon Ciesla 2014-09-12 07:59:10 EDT
Git done (by process-git-requests).

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