This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 200139 - Review Request: luma - A graphical tool for managing LDAP servers
Review Request: luma - A graphical tool for managing LDAP servers
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2006-07-25 13:37 EDT by Jochen Schmitt
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-12 15:20:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
build.log from mock on a x86_64 box (9.06 KB, application/octet-stream)
2006-10-16 13:33 EDT, Kevin Fenzi
no flags Details

  None (edit)
Description Jochen Schmitt 2006-07-25 13:37:18 EDT
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 16:34:24 EDT
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 11:33:25 EDT
Next release:

Spec URL:

Comment 3 Jarod Wilson 2006-07-26 13:09:43 EDT
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 13:28:39 EDT
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 13:41:37 EDT
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 14:48:14 EDT
Next release:

Spec URL:
Comment 7 Jarod Wilson 2006-08-08 10:56:14 EDT
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 15:04:39 EDT
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 17:17:43 EDT
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 12:20:18 EDT
OK, you have right. Here the next release:

Spec URL:

Comment 11 Jochen Schmitt 2006-08-10 14:06:10 EDT
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 01:19:54 EDT
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 14:50:13 EDT
Next Release:

Spec URL:

Comment 14 Kevin Fenzi 2006-10-14 14:16:44 EDT
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 15:06:43 EDT
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 19:01:18 EDT
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 11:57:51 EDT
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 13:33:03 EDT
Created attachment 138594 [details]
build.log from mock on a x86_64 box
Comment 19 Kevin Fenzi 2006-10-16 13:34:14 EDT
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 13:47:06 EDT
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 15:10:42 EDT
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 15:14:56 EDT
Accoriding to comment #20 I have uploaded a new relase:

Spec URL:

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

Spec URL:
Comment 24 Kevin Fenzi 2006-10-16 16:35:30 EDT
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 10:19:10 EDT
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 12:10:33 EDT
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-11 20:43:03 EST
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?

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