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 210087

Summary: Review Request: pekwm - Light weight window manager
Product: [Fedora] Fedora Reporter: Michael Rice <michael>
Component: Package ReviewAssignee: Patrice Dumas <pertusus>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: pertusus
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-18 01:47:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 163779    

Description Michael Rice 2006-10-09 22:03:50 UTC
Spec URL: http://errr.fluxbox-wiki.org/fedora_stuff/pekwm/1/pekwm.spec
SRPM URL: http://errr.fluxbox-wiki.org/fedora_stuff/pekwm/1/pekwm-0.1.5-1.fc5.src.rpm
Description: A lightweight window manager with tabs based on aewm++


This is missing a License I have notified upstream, its also migging a man page I also notified upstream of this too. Builds fine in mock, and rpmlint is happy.

Comment 1 Patrice Dumas 2006-10-10 16:20:38 UTC
There are some BR (BuildRequires) that may be missing:

libpng-devel libXinerama-devel libjpeg-devel 

Did you check the link flags in mock?

Why don't you enable pcre?

in files, you should have
%dir %{_datadir}/%{name}
otherwise the things within that dir are listed twice.

There is a dot missing in description.

Optionally you could shorten the summary by removing 'based on the 
aewm++ window manager'.

Are the
           --x-includes=%{_includedir} \
           --x-libraries=%{_libdir} \
really needed?

Could you expand a bit on            --sysconfdir=%{_datadir}
That seems a bit strange...

Comment 2 Michael Rice 2006-10-10 17:08:39 UTC
(In reply to comment #1)
> There are some BR (BuildRequires) that may be missing:
> 
> libpng-devel libXinerama-devel libjpeg-devel 
> 
> Did you check the link flags in mock?
> 
No, how do I check that? What I did was went to the src dir and did a grep for
includes. The one for xinerama came from X11/extensions/Xinerama.h so I did an
rpmquery -f on /usr/include/X11/extensions/Xinerama.h and found it was provided
by xorg-x11-proto-devel-7.0-6 
I guess I just over looked the jpeg and png header files.

> Why don't you enable pcre?
No reason, I guess I should build with all the options I guess?
 
> in files, you should have
> %dir %{_datadir}/%{name}
> otherwise the things within that dir are listed twice.

Ah ok, I wondered why that was happening

> Are the
>            --x-includes=%{_includedir} \
>            --x-libraries=%{_libdir} \
> really needed?

No I guess not, but thats how the fluxbox package is done so I followed suit.
 
> Could you expand a bit on            --sysconfdir=%{_datadir}
> That seems a bit strange...

Yes, before doing this it would put all these files into /etc/pekwm and they
really had no place there. rpmlint was complaining about it, and they seem to be
better placed in /usr/share/pekwm to me. 

Comment 3 Patrice Dumas 2006-10-10 20:52:15 UTC
(In reply to comment #2)

> No, how do I check that? What I did was went to the src dir and did a grep for
> includes. The one for xinerama came from X11/extensions/Xinerama.h so I did an
> rpmquery -f on /usr/include/X11/extensions/Xinerama.h and found it was provided
> by xorg-x11-proto-devel-7.0-6 
> I guess I just over looked the jpeg and png header files.

There is also the .so linked that are needed:
# rpm -qf /usr/lib/libXinerama.so
libXinerama-devel-1.0.1-2.1

> > Why don't you enable pcre?
> No reason, I guess I should build with all the options I guess?

Indeed. 

> No I guess not, but thats how the fluxbox package is done so I followed suit.

You can leave it if you prefer.

> > Could you expand a bit on            --sysconfdir=%{_datadir}
> > That seems a bit strange...
> 
> Yes, before doing this it would put all these files into /etc/pekwm and they
> really had no place there. rpmlint was complaining about it, and they seem to be
> better placed in /usr/share/pekwm to me. 

I've read a bit of doc, and it seems like the config files
are copied to the home as soon as possible. So it is not that 
important where the defaults are. The scripts would better be 
in /usr/share/pekwm or even in /usr/bin, but the 
config files may be in %_sysconfdir, in case the local sysadm wants to 
tailor the default config. In fluxbox it is in /usr/share, but I 
am not convinced it is right.

The theme is installed in /usr/share allready.

You can easily overwrite what is done by make in menu.in or 
config.in, by doing the sed which sets the path yourself. 

So my proposal is, keep sysconfdir as is, but move the 
scrips to %_bindir, and use sed yourself to regenerate menu from
data/menu.in.

A wild guess is that to put the scripts for example in %_bindir
you could just redefine scriptsdir on the make install command line.

Otherwise scripts use pkill from procps, and also there seems
to be a need for xprop, which is a virtual provides of 
xorg-x11-utils.

The default menu brings in a lot of dependencies. I am not convinced
what should be done there. Have a menu with wrong entries? Trim
it down and add requires? 

Would you feel like modifying fluxbox-xdg-menu, remove the footer
and header, change parseMenu to generate pekwm format, 
and remove the Submenus from Submenu = "Editors" to 
Submenu = "Development", and replace them by an entry like:
Entry = "" { Actions = "Dynamic %{bindir}/pekwm-xdg-menu" }?
This seems to be the best thing to do, currently it doesn't
really integrate with fedora.

Comment 4 Michael Rice 2006-10-14 14:03:02 UTC
(In reply to comment #3)
> 
> So my proposal is, keep sysconfdir as is, but move the 
> scrips to %_bindir, and use sed yourself to regenerate menu from
> data/menu.in.
When you say this do you mean to leave it like I have it now, or remove what I
have now and let this stuff be places in %{_sysconfdir} 

> 
> A wild guess is that to put the scripts for example in %_bindir
> you could just redefine scriptsdir on the make install command line.

This sounds fine to me, Ill see what I can do to get it like that.

 
> Otherwise scripts use pkill from procps, and also there seems
> to be a need for xprop, which is a virtual provides of 
> xorg-x11-utils.

Does there need to be a requires for this or are they pretty much a standard
tool to have on board?

 
> The default menu brings in a lot of dependencies. I am not convinced
> what should be done there. Have a menu with wrong entries? Trim
> it down and add requires? 
> 
> Would you feel like modifying fluxbox-xdg-menu, remove the footer
> and header, change parseMenu to generate pekwm format, 
> and remove the Submenus from Submenu = "Editors" to 
> Submenu = "Development", and replace them by an entry like:
> Entry = "" { Actions = "Dynamic %{bindir}/pekwm-xdg-menu" }?
> This seems to be the best thing to do, currently it doesn't
> really integrate with fedora.

Solved this. :)


Comment 5 Patrice Dumas 2006-10-14 16:27:19 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > 

> When you say this do you mean to leave it like I have it now, or remove what I
> have now and let this stuff be places in %{_sysconfdir} 

My proposal would be let this stuff be placed in %{_sysconfdir}.
and set scriptsdir=%{_bindir}.
And adjust paths.
 
> > Otherwise scripts use pkill from procps, and also there seems
> > to be a need for xprop, which is a virtual provides of 
> > xorg-x11-utils.
> 
> Does there need to be a requires for this or are they pretty much a standard
> tool to have on board?

They are standard, but I think we shouldn't assume anything,
especially for lightweight window managers, so requires should be 
the right ones.

> Solved this. :)

And that's great :) 



Comment 6 Michael Rice 2006-10-16 22:02:04 UTC
OK, I got another srpm ready today

http://errr.fluxbox-wiki.org/fedora_stuff/pekwm/3/pekwm-0.1.5-3.fc5.src.rpm
http://errr.fluxbox-wiki.org/fedora_stuff/pekwm/3/pekwm.spec

I get one error from rpmlint about the start file in /etc/pekwm being 755
What should I do on that??

Comment 7 Patrice Dumas 2006-10-17 20:13:40 UTC
The rpmlint error is ignorable. This executable in etc is 
something we want.

I still think that the summary would be better without
'based on the aewm++ window manager', but it is not a blocker.

The dot missing at the end of the %description is a blocker
(although one easy to fix).

Not a blocker, but I would have requires xprop and not xorg-x11-utils.
 
What about the procps Requires?

* rpmlint gives
E: pekwm executable-marked-as-config-file /etc/pekwm/start
which is ignorable.
* free software. License not included, should be asked upstream, 
  especially since in files it is referred to that file.
* name right
* follow guidelines
* spec legible
* build on x86
* buildrequires mostly right, missing pcre-devel
* sane provides:
Provides: config(pekwm) = 0.1.5-3
* files right except for an unowned directory
* source match upstream:
fe3e0d77250d27963991994f83ccb4ea  pekwm-0.1.5.tar.bz2

MUSTFIX:
unowned directory, must add
%dir %{_datadir}/%{name}/themes/

dot at end of %description

BR pcre-devel

SHOULDFIX:
handle properly UTF-8. I won't make it a bloker, but having a
graphical app which don't accept UTF8 accents in menu is not
right in fedora.

Comment 8 Michael Rice 2006-10-17 20:39:20 UTC
(In reply to comment #7)
> The rpmlint error is ignorable. This executable in etc is 
> something we want.
OK
> I still think that the summary would be better without
> 'based on the aewm++ window manager', but it is not a blocker.
Done

> Not a blocker, but I would have requires xprop and not xorg-x11-utils.
Done
  
> What about the procps Requires?
What do you mean here? 

> MUSTFIX:
> unowned directory, must add
> %dir %{_datadir}/%{name}/themes/
Done 

> dot at end of %description
Done 

> BR pcre-devel
Added
 
> SHOULDFIX:
> handle properly UTF-8. I won't make it a bloker, but having a
> graphical app which don't accept UTF8 accents in menu is not
> right in fedora.

I will ask upstream about plans for this.

Comment 9 Patrice Dumas 2006-10-17 20:44:50 UTC
(In reply to comment #8)
> (In reply to comment #7)

> > What about the procps Requires?
> What do you mean here? 

procps is required because of pkill used in some script.

Currently it is required by initscripts, but this may change,
and with initng I don't know if initscript will be required.

Comment 11 Patrice Dumas 2006-10-17 21:56:10 UTC
All the blocking item have been fixed, so this is

APPROVED

Comment 12 Michael Rice 2006-10-17 21:58:20 UTC
Patrice, I got a message from upstream, how would you feel about me adding this
to the package:

http://adresh.com/pekwm/dev_docs/html/faq/answers.html#FAQ-1546

Comment 13 Patrice Dumas 2006-10-17 22:08:29 UTC
I think it would be right to do what is said in the FAQ entry 
to have unicode support. 8 bit locales use should be very rare
in fedora.


It would have been even better to switch depending on the 
locale, but it is something that should be done upstream. Maybe 
worth asking upstream, too?



Comment 14 Patrice Dumas 2006-10-17 22:10:13 UTC
You can add it after importing to cvs.