Bug 200139

For reference, here's my local package of this:
http://cachalot.mine.nu/5/SRPMS/luma-2.3-0.1.src.rpm

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
implementation

- Could %lang'ify translations, see my specfile

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

Next release:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3.0-2.src.rpm

Package build goes bonk on x86_64, install.py 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?

If you visit http://luma.sf.net you will see, that there was versions like
luma-2.2.1.

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.

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.

Next release:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-3.src.rpm

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 install.py, 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.

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.

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.

OK, you have right. Here the next release:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-4.src.rpm

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: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-5.src.rpm

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
source.

  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".

Next Release:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-6.src.rpm

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:

SHOULD Items:

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

Issues:

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 ?
    startApplication()
  File "/usr/bin/luma", line 44, in startApplication
    gui.loadPlugins(splash)
  File "/usr/share/luma/lib/base/gui/MainWin.py", line 186, in loadPlugins
    pluginObject = PluginLoader(self.checkToLoad())
  File "/usr/share/luma/lib/base/backend/PluginLoader.py", line 53, in __init__
    self.importPluginMetas(pluginsToLoad)
  File "/usr/share/luma/lib/base/backend/PluginLoader.py", line 84, in 
importPluginMetas
    for x in self.pluginDirList:
TypeError: iteration over non-sequence

Next release:

Next Release:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-7.src.rpm

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

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/libqimsw-multi.so:
  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/libqimsw-none.so:
  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/libqsimple.so:
  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/libqxim.so:
  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)

 

Can you upload the whole build log.

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

Created attachment 138594 [details]
build.log from mock on a x86_64 box

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. 

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

Hello kevin,

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

SMTP error from remote server after RCPT command:
host mail.tummy.com[66.35.36.132]:
554 <moutng.kundenserver.de[212.227.126.187]>: Client host rejected: IP address
is or has been used to send UCE.

Accoriding to comment #20 I have uploaded a new relase:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-7.src.rpm

Accoriding to comment #20 I have uploaded a new relase:

Spec URL: http://www.herr-schmitt.de/pub/luma/luma.spec
SRPM URL: http://www.herr-schmitt.de/pub/luma/luma-2.3-7.src.rpm

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?

I have sent a message to the author for clarification, but I think this messages
shodn't not harm the usage of luma.

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. 

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?