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

Bug 200139

Summary: Review Request: luma - A graphical tool for managing LDAP servers
Product: [Fedora] Fedora Reporter: Jochen Schmitt <jochen>
Component: Package ReviewAssignee: Kevin Fenzi <kevin>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jarod, j, packages
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-12 20:20:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 163779    
Description Flags
build.log from mock on a x86_64 box none

Description Jochen Schmitt 2006-07-25 17:37:18 UTC
Spec URL:

Luma - a graphical tool for accessing and managing LDAP 
server. It is written in Python, using PyQt and python-ldap. 
Plugin-support is included and useful widgets with LDAP-
functionality for easy creation of plugins are delivered.

Comment 1 Ville Skyttä 2006-07-25 20:34:24 UTC
For reference, here's my local package of this:

The above contains some improvements over your package but it is pretty much
untested and known to be not quite complete, so approach with care.  And I don't
have use for luma at the moment, so I'm not doing a full review.  But a quick
peek into the specfile differences tells me that:

- Possibly missing Requires on python-ldap, PyQt, maybe python-smbpasswd

- Odd placement of icon and icon caches not updated (does the menu entry
actually show an icon?), see my specfile for ideas for a more thorough

- Could %lang'ify translations, see my specfile

- Specfile comment says "Desktop entry for nvidia-settings"

Comment 2 Jochen Schmitt 2006-07-26 15:33:25 UTC
Next release:

Spec URL:

Comment 3 Jarod Wilson 2006-07-26 17:09:43 UTC
Package build goes bonk on x86_64, puts everything in /usr/lib/luma,
while the spec is looking for /usr/lib64/luma.

Also, why the %{ver} stuff? The upstream tarball is versioned simply 2.3, why
are you turning that into 2.3.0?

Comment 4 Jochen Schmitt 2006-07-26 17:28:39 UTC
If you visit you will see, that there was versions like

So the version 2.3 is the same as 2.3.0.

Therefore I use a three qualified versioning schema to be sure that the updating
will worked in the future.

Comment 5 Jarod Wilson 2006-07-26 17:41:37 UTC
Version 2.3.1 will already be rpm-newer than 2.3, there is no need to make it
into 2.3.0. Altering the upstream versioning is frowned upon, and altogether
unnecessary in this case.

Comment 6 Jochen Schmitt 2006-07-26 18:48:14 UTC
Next release:

Spec URL:

Comment 7 Jarod Wilson 2006-08-08 14:56:14 UTC
Sorry for the delay, been swamped with work... Finally poked at the -3 version a
bit, and got the following out of rpmlint:

$ rpmlint -i /build/RPMS/noarch/luma-2.3-3.fc5.noarch.rpm
E: luma only-non-binary-in-usr-lib
There are only non binary files in /usr/lib so they should be in /usr/share.

This would appear to require some hacking of, and I'm actually
wondering if maybe these bits should go in
/usr/lib/python2.x/site-packages/luma/ instead of /usr/lib/luma,
/usr/share/luma/ or /usr/share/luma/lib. But python packaging definitely isn't
my area of expertise, so that could be a bad idea. :) rpmlint seems to think
somewhere under /usr/share is the place to put things.

Comment 8 Jochen Schmitt 2006-08-08 19:04:39 UTC
I know this error message from rpmlint. But becouse other packages like yum does
it in the same way. I decide not to change the package.

Comment 9 Jarod Wilson 2006-08-08 21:17:43 UTC
Just because another package doesn't do the right thing doesn't make it okay
(and the bulk of yum is in /usr/lib/python2.x/site-packages/yum/, only
yum-plugins are in /usr/lib/ directly). I'll continue poking at the package for
other feedback, but the way I'm leaning is the same as the advice I've gotten
from other more experienced reviewers -- that this is a blocker.

Comment 10 Jochen Schmitt 2006-08-09 16:20:18 UTC
OK, you have right. Here the next release:

Spec URL:

Comment 11 Jochen Schmitt 2006-08-10 18:06:10 UTC
The new packaging guidelines for python packages says that *.pyo files should
include as normal files into the package.

Therefor I have changed the packages:

Spec URL:

Comment 12 Jason Tibbitts 2006-10-06 05:19:54 UTC
This builds fine in mock; rpmlint says:
  E: luma hardcoded-library-path in ${RPM_BUILD_ROOT}/usr/lib
which seems bogus as the spec is doing this to fix brokenness in the upstream

  W: luma mixed-use-of-spaces-and-tabs (spaces: line 63, tab: line 5)
Fix if you like.

The "Comment=" line in the .desktop file is ungrammatical; please consider
changing it to read "Tool for managing LDAP servers".

Please also consider s/server/servers/ in %description.

When you call desktop-file-install, the vendor should be "fedora", not "Fedora".

Comment 13 Jochen Schmitt 2006-10-09 18:50:13 UTC
Next Release:

Spec URL:

Comment 14 Kevin Fenzi 2006-10-14 18:16:44 UTC
OK - Spec file matches base package name.
See below - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (GPL)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
c1f3a8033a047a7046848833445ed496  luma-2.3.tar.bz2
c1f3a8033a047a7046848833445ed496  luma-2.3.tar.bz2.1
OK - BuildRequires correct
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Package is a GUI app and has a .desktop file
OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
OK - No rpmlint output.
OK - final provides and requires are sane:


OK - Should build in mock.
OK - Should build on all supported archs
OK - Should have dist tag
OK - Should package latest version


1. The lumadata, lumalib and plugins macros seem like overkill to me.
Not a blocker, but I would prefer if you remove them. It would make the spec
more readable, IMHO.

2. On installing and trying to run, I get:

Could not read logger settings file. Reason:
[Errno 2] No such file or directory: '/home/kevin/.luma/luma'
Traceback (most recent call last):
  File "/usr/bin/luma", line 71, in ?
  File "/usr/bin/luma", line 44, in startApplication
  File "/usr/share/luma/lib/base/gui/", line 186, in loadPlugins
    pluginObject = PluginLoader(self.checkToLoad())
  File "/usr/share/luma/lib/base/backend/", line 53, in __init__
  File "/usr/share/luma/lib/base/backend/", line 84, in 
    for x in self.pluginDirList:
TypeError: iteration over non-sequence

Comment 15 Jochen Schmitt 2006-10-15 19:06:43 UTC
Next release:

Next Release:

Spec URL:

To #1 I didn't change the rpm macros, becouse I thing it improve the ability to
changes the directories if necessary.

Comment 16 Kevin Fenzi 2006-10-15 23:01:18 UTC
Yeah, you will be maintaining it, so if you want to keep those macros it's up 
to you. :) However, lumalibs seems to be used in only 2 places and plugins 
never seems to be used. 

The patch seems to get it running, but it's still prints some errors/warnings 
(new ones):

Could not read logger settings file. Reason:
[Errno 2] No such file or directory: '/home/kevin/.luma/luma'
Conflict in /usr/lib/qt-3.3/plugins/inputmethods/
  Plugin uses incompatible Qt library!
  expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-
4.* full-config".
Conflict in /usr/lib/qt-3.3/plugins/inputmethods/
  Plugin uses incompatible Qt library!
  expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-
4.* full-config".
Conflict in /usr/lib/qt-3.3/plugins/inputmethods/
  Plugin uses incompatible Qt library!
  expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-
4.* full-config".
Conflict in /usr/lib/qt-3.3/plugins/inputmethods/
  Plugin uses incompatible Qt library!
  expected build key "x86_64 Linux g++-4.* full-config", got "i686 Linux g++-
4.* full-config".
Could not parse template file

Also, it doesn't build on x86_64. 

The end of the build.log gives: 
+ pushd /var/tmp/luma-2.3-7.fc6-root-mockbuild/lib
/var/tmp/rpm-tmp.24941: line 33: pushd: /var/tmp/luma-2.3-7.fc6-root-mockbuild/
lib: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.24941 (%install)


Comment 17 Jochen Schmitt 2006-10-16 15:57:51 UTC
Can you upload the whole build log.

Unfortunately, I haven't a 64 bit system, so I have no idea why the issue are

Comment 18 Kevin Fenzi 2006-10-16 17:33:03 UTC
Created attachment 138594 [details]
build.log from mock on a x86_64 box

Comment 19 Kevin Fenzi 2006-10-16 17:34:14 UTC
Attached the build.log from x86_64. 
I have a x86_64 test box that I would be happy to provide you an account on if 
you like. Just send me your ssh key in private email. 

Comment 20 Ville Skyttä 2006-10-16 17:47:06 UTC
The error in comment 16 looks odd to me (how does $RPM_BUILD_ROOT/%{_libdir} 
expand to /var/tmp/luma-2.3-7.fc6-root-mockbuild/lib ??? I 
get /var/tmp/luma-2.3-7.cmn6-root-scop//usr/lib64)

Anyway, this fixes it here on FC5 x86_64:

-pushd ${RPM_BUILD_ROOT}/%{_libdir}
+pushd ${RPM_BUILD_ROOT}%{_prefix}/lib

Comment 21 Jochen Schmitt 2006-10-16 19:10:42 UTC
Hello kevin,

When I try to send you a mail, I got a

SMTP error from remote server after RCPT command:
554 <[]>: Client host rejected: IP address
is or has been used to send UCE.

Comment 22 Jochen Schmitt 2006-10-16 19:14:56 UTC
Accoriding to comment #20 I have uploaded a new relase:

Spec URL:

Comment 23 Jochen Schmitt 2006-10-16 19:19:05 UTC
Accoriding to comment #20 I have uploaded a new relase:

Spec URL:

Comment 24 Kevin Fenzi 2006-10-16 20:35:30 UTC
In reply to comment #21: 

Sorry about that. Apparently we have gotten spams from that IP before. 
It should be unblocked now if you can resend... 

In reply to comment #22 (and #23): 

That does indeed get it building fine on x86_64. 

The first time I run it, I get: 

$ luma
Could not read logger settings file. Reason:
[Errno 2] No such file or directory: '/home/kevin/.luma/luma'
Could not parse template file

Then running again gets: 

$ luma
Could not parse template file

That doesn't seem related to your packaging however, it looks like a upstream 
problem with it not creating the template directory when it creates the others?

Do you agree that the "Could not parse template file" is nothing to worry about?

Comment 25 Jochen Schmitt 2006-10-17 14:19:10 UTC
I have sent a message to the author for clarification, but I think this messages
shodn't not harm the usage of luma.

Comment 26 Kevin Fenzi 2006-10-17 16:10:33 UTC
Yeah, I don't have a LDAP server handy here to fully test things, but the UI 
seems to work fine aside from the template warning. 

I don't see any further blockers here, so this package is APPROVED. 

Don't forget to close this bug NEXTRELEASE once it's been imported and built. 

Also, consider reviewing another package thats waiting to help spread the 
review load out. 

Comment 27 Kevin Fenzi 2006-11-12 01:43:03 UTC
Is there any reason this bug can't be closed now? 
Looks like it's been imported and owners.list updated... am I missing anything?