Bug 871216

Summary: Review Request: tupi - 2D vector-based animation environment
Product: [Fedora] Fedora Reporter: Gustav Gonzalez <xtingray>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: rawhideCC: cwickert, davidjeremias82, echevemaster, jreznik, kevin, notting, package-review, rdieter, volker27
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: 2013-01-29 02:17:10 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 656997    

Description Gustav Gonzalez 2012-10-29 19:39:56 EDT
Hi, 

My name is Gustav Gonzalez and I'm the leader and current developer of the Tupi project. 
I really appreciate if you can check/review the SPEC file of my application:

http://www.maefloresta.com/portal/spec

I already tested it using Koji and the package building was pretty clean:
4633376 build (f17, tupi-0.2-1.fc17.src.rpm) completed successfully

Please, let me know what is the next step I should take to become an official Fedora package maintainer for Tupi.

Thank you!
Comment 1 Eduardo Echeverria 2012-10-30 01:01:01 EDT
Hi Gustav, I know your project and I'm pleased that you want to package Tupi for Fedora :)

I'm not a sponsor, but I can help you review your package

Initial Comments:
- Please put the specs in plain text somewhere on their website along with the resulting SRPM and publish the links here

- Please add in "blocks" field the tag FE-NEEDSPONSOR  
http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

- If you have no plans to build for EPEL5, please remove
* BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
* %defattr(-,root,root)

- I see your package does not generate any shared libraries, therefore should not use the scriptlet to call ldconfig 
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shared_libraries

- You can use $RPM_BUILD_ROOT instead of %{buildroot}. Both are acceptable, but just be consistent. 
Example:
Incorrect
make install DESTDIR=%{buildroot}
find $RPM_BUILD_ROOT -name \*.la | xargs rm -f

Correct:
make install DESTDIR=%{buildroot}
find %{buildroot} -name \*.la | xargs rm -f

Why you marked as a comment this line?
#make %{?_smp_mflags}
Is there any specific reason for not using it?

According to the project page_Tupi 0.2-git01 is the latest revision, please package this version and naming according to
http://fedoraproject.org/wiki/Packaging:NamingGuidelines
Regards
Comment 2 Eduardo Echeverria 2012-10-30 01:22:17 EDT
I forgot, please include a %doc section, and include files COPYING, README
https://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25files_section
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines
Comment 3 Volker Fröhlich 2012-10-31 17:52:20 EDT
Please post direct links to SRPM and spec file.
Comment 4 Gustav Gonzalez 2012-11-03 14:51:35 EDT
Hello guys! (Sorry for my delay)

I think the SPEC file is ready, but please, help me to ensure that everything is ok. 

http://www.maefloresta.com/fedora/tupi.spec
http://www.maefloresta.com/fedora/tupi-0.2-1.fc17.src.rpm

Thanks!
Comment 5 Volker Fröhlich 2012-11-03 15:27:44 EDT
Make the build verbose!

As you are one of the developers, please try to remove the race conditions in the build system, so multiple workers can be used.

Use name and version macros in Source0.

Every maintained release of Fedora has Qt > 4.7, therefore the version requirement should be removed.

%{_datadir}/man/man1 must be %{_datadir}/man/man1/*.1* or the likes. Otherwise you're owning the directory.

Change the permissions of source code files to 644; at least some have executable permissions. Same for COPYING and README.

The postal address of the FSF is wrong in /usr/share/tupi/data/*/license.html

Run rpmlint on your packages to see some of the things I pointed out.

Locales must be handled like this:
http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
Comment 6 Volker Fröhlich 2012-11-03 17:06:36 EDT
Tupi doesn't seem to build on PPC: http://ppc.koji.fedoraproject.org/koji/getfile?taskID=774499&name=build.log

If you're not interested or able to mend that, you'd do the PPC guys a favour, if you added

ExcludeArch:   ppc ppc64
Comment 7 Volker Fröhlich 2012-11-04 06:57:29 EST
You need to install a desktop file, since this is a graphical application: http://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files
Comment 8 Gustav Gonzalez 2012-11-12 10:01:14 EST
(In reply to comment #5)
> Make the build verbose!

I'm doing it now.
 
> As you are one of the developers, please try to remove the race conditions
> in the build system, so multiple workers can be used.

Done. Now it works!
 
> Use name and version macros in Source0.

Done.

> Every maintained release of Fedora has Qt > 4.7, therefore the version
> requirement should be removed.

Done.

> %{_datadir}/man/man1 must be %{_datadir}/man/man1/*.1* or the likes.
> Otherwise you're owning the directory.

Done.
 
> Change the permissions of source code files to 644; at least some have
> executable permissions. Same for COPYING and README.

Done.
 
> The postal address of the FSF is wrong in /usr/share/tupi/data/*/license.html

Fixed.

> Locales must be handled like this:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files

I already read the link, but I would like to see the RPM source of a Qt application (with .qm files) following this standard. 

I was looking for some of them to understand better what changes I have to do in my source code, but my search was unsuccessful. 

Thanks!
Comment 9 Gustav Gonzalez 2012-11-12 10:02:54 EST
(In reply to comment #7)
> You need to install a desktop file, since this is a graphical application:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files

Done.
Comment 10 Gustav Gonzalez 2012-11-12 10:20:31 EST
Ok, this is how the thing is going on for now:

[xtingray@katana SPECS]$ rpmlint tupi.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

[xtingray@katana SRPMS]$ rpmlint tupi-0.2-1.fc17.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[xtingray@katana RPMS]$ rpmlint x86_64/tupi-0.2-1.fc17.x86_64.rpm 
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupitwitter.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupianimation.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupigui.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupitimeline.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupicolorpalette.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiscenes.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupihelp.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupifwcore.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupifwgui.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupipen.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiplugincommon.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupimport.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupibase.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupinet.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupistore.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiexport.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupikinas.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupilibrary.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiexposure.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupi.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupipaintarea.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupidebug.so
tupi.x86_64: W: no-manual-page-for-binary tupi.bin
1 packages and 0 specfiles checked; 0 errors, 23 warnings.

PS:
- Why .so files should be part of the devel package? They are not required for development, they are libraries needed by the program.
- Should I create a manual page for the tupi.bin file? It seems to be unnecessary. 

Advises are very welcome. Thanks! :)
Comment 11 Volker Fröhlich 2012-11-12 13:16:12 EST
No, I don't consider a manpage necessary for a graphical application.

The .so warning is about the libraries being unversioned, much like development symlinks usually are. But those are just your private libs and not development symlinks. Since you don't install them in a place where ldd picks them up, this is fine.

Can you upload the newest spec and SRPM?
Comment 12 Eduardo Echeverria 2012-11-12 16:24:22 EST
Gustav, 

1.- Every time you make a change to the spec should increase the release number (in the spec) but not in the source tarball

This will leave the changelog and Release tag in this way

Release: 2%{?dist}

%changelog
* Mon Nov 12 2012 Gustav Gonzalez <xtingray@maefloresta.com> - 0.2-2
- remove the race conditions in the build system
- Use macros in Source0
- Other changes ...

* Fri Oct 26 2012 Gustav Gonzalez <xtingray@maefloresta.com> - 0.2-1
- Making of RPM

2.-  You need BR  desktop-file-utils
Comment 13 Gustav Gonzalez 2012-11-12 16:47:45 EST
(In reply to comment #11)

> Can you upload the newest spec and SRPM?

Same location :)

http://www.maefloresta.com/fedora/tupi.spec
http://www.maefloresta.com/fedora/tupi-0.2-1.fc17.src.rpm
Comment 14 Gustav Gonzalez 2012-11-12 16:54:21 EST
(In reply to comment #12)
> Gustav, 
> 
> 1.- Every time you make a change to the spec should increase the release
> number (in the spec) but not in the source tarball
> 
> This will leave the changelog and Release tag in this way
> 
> Release: 2%{?dist}
> 
> %changelog
> * Mon Nov 12 2012 Gustav Gonzalez <xtingray@maefloresta.com> - 0.2-2
> - remove the race conditions in the build system
> - Use macros in Source0
> - Other changes ...
> 
> * Fri Oct 26 2012 Gustav Gonzalez <xtingray@maefloresta.com> - 0.2-1
> - Making of RPM

I promise to start increasing the release number as soon as I understand 
the whole packaging process first (I'm pretty close!). Right now, it should
be the 0.2-80, but it wouldn't be fair understanding that I'm just learning :(

> 2.-  You need BR  desktop-file-utils

I will put it in spec file as soon as I get back to my computer. I'll let you know when the latest files are ready for revision :)
Comment 15 Kevin Kofler 2012-11-16 08:17:14 EST
Putting on the KDE reviews tracker as there's no separate one for Qt-only stuff.
Comment 16 Kevin Kofler 2012-11-16 08:19:20 EST
> ExcludeArch: ppc ppc64
rings a big alarm bell for me. How about you fix your code to be endianness-safe instead?
Comment 17 Gustav Gonzalez 2012-11-16 09:08:52 EST
Don't worry, this weekend I will focus on the error related to the compilation for ppc platforms. This fix requires some additional work but I will do it to remove the "ExcludeArch" line from the spec file.

When the thing is ready for testing, I'll post a message right here ;)
Comment 18 Gustav Gonzalez 2012-11-17 18:31:18 EST
Hi everyone!

This is the latest version of the files, please, test them and tell me if there's something to fix: 

http://www.maefloresta.com/fedora/tupi.spec
http://www.maefloresta.com/fedora/tupi-0.2-1.fc17.src.rpm

Thank you guys!
Comment 19 Gustav Gonzalez 2012-11-17 23:26:05 EST
Report of my tests:

SPECS]$ rpmlint tupi.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

SRPMS]$ rpmlint tupi-0.2-1.fc17.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

RPMS]$ rpmlint x86_64/tupi-0.2-1.fc17.x86_64.rpm 
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupitwitter.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupianimation.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupigui.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupitimeline.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupicolorpalette.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiscenes.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupihelp.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupifwcore.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupifwgui.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupipen.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiplugincommon.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupimport.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupibase.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupinet.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupistore.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiexport.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupikinas.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupilibrary.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupiexposure.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupi.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupipaintarea.so
tupi.x86_64: W: devel-file-in-non-devel-package /usr/lib64/tupi/libtupidebug.so
tupi.x86_64: W: no-manual-page-for-binary tupi.bin
1 packages and 0 specfiles checked; 0 errors, 23 warnings.
Comment 20 Volker Fröhlich 2012-11-18 02:56:32 EST
The build still isn't verbose enough. You should see the exact compiler command executed.

The language handling isn't complete. While you're generating a list of locale files in the install section, you're not actually using it in the files section.

I'd personally remove the .bin extension from the executable and thus the desktop file.

desktop-file-validate tupi.desktop
tupi.desktop: error: (will be fatal in the future): value "tupi.png" for key "Icon" in group "Desktop Entry" is an icon name with an extension, but there should be no extension as described in the Icon Theme Specification if the value is not an absolute path
tupi.desktop: warning: value "Application;Graphics;2DGraphics;RasterGraphics;" for key "Categories" in group "Desktop Entry" contains a deprecated value "Application"

Please bump the release number of the spec file on changes and try to write a meaningful changelog entry. This makes work easier for reviewers. It wont be release 80. The number is only relevant for versions you publish. So you'd be at 3 or 4 now.
Comment 21 Volker Fröhlich 2012-11-18 16:55:17 EST
I noticed the MIME types specified in the desktop file. Those are neither registered at IANA, nor are they defined. You should define them and then use the following scriptlet:

http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo
Comment 22 Gustav Gonzalez 2012-11-18 22:58:10 EST
(In reply to comment #20)
> The build still isn't verbose enough. You should see the exact compiler
> command executed.

The configure script has an option "--with-debug" which prints the whole information about the compilation process. Should I add it in the configure
line of the spec file?

> The language handling isn't complete. While you're generating a list of
> locale files in the install section, you're not actually using it in the
> files section.

Currently, the software use these files, which are installed by the 
"make install" command:

./share/tupi/data/translations/tupi_cs.qm
./share/tupi/data/translations/tupi_de.qm
./share/tupi/data/translations/tupi_da.qm
./share/tupi/data/translations/tupi_ru.qm
./share/tupi/data/translations/tupi_es.qm
./share/tupi/data/translations/tupi_gl.qm
./share/tupi/data/translations/tupi_pt.qm
./share/tupi/data/translations/tupi_ca.qm
./share/tupi/data/translations/tupi_it.qm

From the software I load the localization calling using these lines:

 QTranslator *translator = new QTranslator;
 translator->load(kAppProp->shareDir() + "data/translations/" + "tupi_" + locale + ".qm");
 application.installTranslator(translator);

I still don't get the relationship between this and the spec file. Should I change my code or what I have to do?

> I'd personally remove the .bin extension from the executable and thus the
> desktop file.

  There's a bash script called tupi, which defines the program variables 
  first and then it calls the tupi.bin binary. How I should deal with this?

> desktop-file-validate tupi.desktop
> tupi.desktop: error: (will be fatal in the future): value "tupi.png" for key
> "Icon" in group "Desktop Entry" is an icon name with an extension, but there
> should be no extension as described in the Icon Theme Specification if the
> value is not an absolute path
> tupi.desktop: warning: value
> "Application;Graphics;2DGraphics;RasterGraphics;" for key "Categories" in
> group "Desktop Entry" contains a deprecated value "Application"

  This error is already fixed.
 
> Please bump the release number of the spec file on changes and try to write
> a meaningful changelog entry. This makes work easier for reviewers. It wont
> be release 80. The number is only relevant for versions you publish. So
> you'd be at 3 or 4 now.

  Ok. I will extend the changelog entry.
Comment 23 Gustav Gonzalez 2012-11-18 23:07:30 EST
(In reply to comment #21)
> I noticed the MIME types specified in the desktop file. Those are neither
> registered at IANA, nor are they defined. You should define them and then
> use the following scriptlet:
> 
> http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#mimeinfo

Quoting from the link:

Use this when a package drops an XML file in %{_datadir}/mime/packages.

%post
/usr/bin/update-mime-database %{_datadir}/mime &> /dev/null || :

%postun
/usr/bin/update-mime-database %{_datadir}/mime &> /dev/null || :

Question: Should I install a "XML file" with the MIME information in the path
%{_datadir}/mime/packages, right? I was looking for an example unsuccessfully, could you show me the structure of one of those?

Thanks.
Comment 24 Eduardo Echeverria 2012-11-18 23:11:07 EST
(In reply to comment #22)
> (In reply to comment #20)

> I still don't get the relationship between this and the spec file. Should I
> change my code or what I have to do?

Gustav:
No, you do not have to change anything in your code, you just have to install the language files with:

%files -f %{name}.lang
instead of 

%files 
http://fedoraproject.org/wiki/PackagingDrafts/find_lang
Comment 25 Eduardo Echeverria 2012-11-18 23:38:27 EST
(In reply to comment #23)
> (In reply to comment #21)
> Question: Should I install a "XML file" with the MIME information in the path
> %{_datadir}/mime/packages, right? I was looking for an example
> unsuccessfully, could you show me the structure of one of those?
> 
> Thanks.

You can take a look at this link
http://freedesktop.org/wiki/Specifications/AddingMIMETutor
Comment 26 Gustav Gonzalez 2012-11-24 20:15:53 EST
Hi!

These are the latest versions of the SPEC/SRPM files. I hope all the errors were fixed, but please check the files again and tell me if I forgot to correct something:

http://www.maefloresta.com/fedora/tupi.spec
http://www.maefloresta.com/fedora/tupi-0.2-3.fc17.src.rpm

Thank you!
Comment 27 Gustav Gonzalez 2012-11-28 09:56:07 EST
Please! I need some help with this issue...

When I run the rpmlint command for the RPM file, I got many messages like this:

tupi-debuginfo.x86_64: W: hidden-file-or-dir /usr/src/debug/tupi-0.2/src/shell/.moc

But if I add this line to the SPEC file:
find ./ -type d \( -name ".obj" -o -name ".moc" \) -print0 | xargs -0 /bin/rm -rf

The rpmlint command prints "0" errors (which is good), but I got a lot of messages like this while the rpmbuild command is running:

cpio: tupi-0.2/src/components/animation/.moc/moc_tupanimationarea.cpp: Cannot stat: No such file or directory

I have been trying to put the "find" line in several places of the SPEC	file
with no	luck.

How do I deal with the .moc directories	created	by the Qt compilation process?
Any hint?

Thanks!
Comment 28 Volker Fröhlich 2012-11-28 10:00:46 EST
Ignore the rpmlint warning and don't delete the files.
Comment 29 Kevin Kofler 2012-11-28 12:37:11 EST
Yes, those files are automatically generated during build. And the fact that they have hidden names is not an issue, that rpmlint warning is not a real issue.
Comment 30 Gustav Gonzalez 2012-11-28 23:08:43 EST
I did undo the changes in the SPEC file and rebuilt the SRPM again:

http://www.maefloresta.com/fedora/tupi.spec
http://www.maefloresta.com/fedora/tupi-0.2-3.fc17.src.rpm

If there's something missing yet, please, let me know.

Thank you!
Comment 31 Michael Schwendt 2012-12-05 17:48:14 EST
> %dir %_datadir/%{name}/data/
> %dir %_datadir/%{name}/data/cs/
> %dir %_datadir/%{name}/data/da/
> %dir %_datadir/%{name}/data/de/
> %dir %_datadir/%{name}/data/en/
> %dir %_datadir/%{name}/data/es/
> %dir %_datadir/%{name}/data/gl/
> %dir %_datadir/%{name}/data/pt/
> %dir %_datadir/%{name}/data/ru/
> %{_datadir}/%{name}/data/*/gpl.css
> %{_datadir}/%{name}/data/*/*.xml
> %{_datadir}/%{name}/data/*/*.html
> 
> %dir %_datadir/%{name}/data/palettes/
> %{_datadir}/%{name}/data/palettes/*.tpal
> 
> %dir %_datadir/%{name}/data/help/
> %dir %_datadir/%{name}/data/help/css/  
> %{_datadir}/%{name}/data/help/css/tupi.ini
> 
> %dir %_datadir/%{name}/data/help/en/  
> %dir %_datadir/%{name}/data/help/es/  
> %dir %_datadir/%{name}/data/help/ru/
> %dir %_datadir/%{name}/data/help/examples/  
> %{_datadir}/%{name}/data/help/examples/example.*
> 
> %dir %_datadir/%{name}/data/help/gl/  
> 
> %dir %_datadir/%{name}/data/help/images/
> %{_datadir}/%{name}/data/help/images/*.png
> %{_datadir}/%{name}/data/help/*/*.html
> %{_datadir}/%{name}/data/help/*/*.xml
> %{_datadir}/%{name}/data/help/*/*.css
> %{_datadir}/%{name}/data/help/*/images/*.png
> 
> %dir %_datadir/%{name}/data/help/to_translate/
> %_datadir/%{name}/data/help/to_translate/*
> 
> %dir %_datadir/%{name}/data/help/README/
> %{_datadir}/%{name}/data/help/README/*
> 
> %dir %_datadir/%{name}/data/storyboard/
> %{_datadir}/%{name}/data/storyboard/tupi.css
> 
> %dir %_datadir/%{name}/data/translations/
> %{_datadir}/%{name}/data/translations/*.ts
> 
> %dir %_datadir/%{name}/themes/
> %dir %_datadir/%{name}/themes/default/
> %dir %_datadir/%{name}/themes/default/cursors/
> %dir %_datadir/%{name}/themes/default/icons/
> %dir %_datadir/%{name}/themes/default/images/
> %_datadir/%{name}/themes/*/*/*.png
> 
> %dir %_libdir/%{name}/
> %{_libdir}/%{name}/*

As can be concluded from this overly complex %files section, you are probably not aware of the much easier notation to include entire trees of files/directories.

The entry

  %{_datadir}/%{name}/

and also

  %{_datadir}/%{name}

(without the trailing slash) would include a directory %{_datadir}/%{name}/ and everything in it. Implicitly creating %dir entries for any directories and avoiding "unowned" directories, too:
https://fedoraproject.org/wiki/Packaging:UnownedDirectories

Listing each and every directory and file(s) as you did could become burdensome to maintain, if the installation layout changes even slightly. Listing individual files (without a '*' wildcard) typically is only beneficial if you want the rpmbuild to fail if a specific file is not found in the buildroot. 

> %dir %_libdir/%{name}/
> %{_libdir}/%{name}/*

In the same way, this can be simplified to just

  %{_libdir}/%{name}/

and will achieve the same.
Comment 32 Gustav Gonzalez 2012-12-07 19:53:25 EST
I simplified the files list. The only lines I left were these:

%{_libdir}/%{name}
%{_bindir}/%{name}
%{_bindir}/%{name}.bin
%{_datadir}/applications/tupi.desktop
%{_datadir}/man/man1/*.1*
%{_datadir}/mime/packages/tupi.xml
%{_datadir}/pixmaps/%{name}.png
%{_datadir}/%{name}

But now I got these warnings when I build the RPM file:

warning: File listed twice: /usr/share/tupi/data/translations/tupi_ca.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_cs.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_da.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_de.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_es.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_gl.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_it.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_pt.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_ru.qm

Is this a critical error? I was checking and there's no double copy or anything weird about those files. How do I fix this?

Thanks!
Comment 33 Eduardo Echeverria 2012-12-07 20:24:55 EST
Use:

%exclude %{_datadir}/%{name}/data/translations
Comment 34 Kevin Kofler 2012-12-07 21:30:06 EST
> But now I got these warnings when I build the RPM file:
>
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_ca.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_cs.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_da.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_de.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_es.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_gl.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_it.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_pt.qm
> warning: File listed twice: /usr/share/tupi/data/translations/tupi_ru.qm

That's because those files are already listed in tupi.lang (found by %find_lang) (and that's how it should be).

> Use:
>
> %exclude %{_datadir}/%{name}/data/translations

No, that won't work as expected, because we actually want those files packaged. You cannot use %exclude in this case.

You will have to use a more detailed file list.
Comment 35 Gustav Gonzalez 2012-12-08 09:01:08 EST
That's funny... if you read the post of Michael Schwendt (2 comments above), you'll find that he is asking me to simplify the list :P

I will try to create a no-so-long / no-so-short %files section.

When I have the thing ready, I'll let you know. :)
Comment 36 Kevin Kofler 2012-12-08 13:41:12 EST
Your first file list was too detailed, your second one was not detailed enough. :-)
Comment 37 Gustav Gonzalez 2012-12-23 14:27:21 EST
Ok, after a lot of tries I have discovered why I got these messages:

warning: File listed twice: /usr/share/tupi/data/translations/tupi_ca.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_cs.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_da.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_de.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_es.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_gl.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_it.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_pt.qm
warning: File listed twice: /usr/share/tupi/data/translations/tupi_ru.qm

If I comment these lines in the SPEC file: 

%find_lang %{name} --with-qt
%files -f %{name}.lang

Then I can use a very short %files section with NO warnings:

%{_libdir}/%{name}
%{_bindir}/%{name}
%{_bindir}/%{name}.bin
%{_datadir}/applications/tupi.desktop
%{_datadir}/man/man1/*.1*
%{_datadir}/mime/packages/tupi.xml
%{_datadir}/pixmaps/%{name}.png
%{_datadir}/%{name}

Of course, the "lang" lines are needed, so, what should I do in this case?

Thanks!
Comment 38 Christoph Wickert 2013-01-02 18:18:09 EST
Can you try '%find_lang %{name} --with-qt --all-name'?
Comment 39 Gustav Gonzalez 2013-01-04 22:36:43 EST
I tried it, but it didn't work. Anyway, I made some changes in the SPEC file and finally I could generate the installers without those warning messages.

These are the files:
http://www.maefloresta.com/fedora/tupi.spec
http://www.maefloresta.com/fedora/tupi-0.2-4.fc17.src.rpm

Please, check them and tell me if something is missing. Thank you!
Comment 40 Gustav Gonzalez 2013-01-05 11:44:16 EST
By the way, my FAS username is: xtingray :)
Comment 41 David Vásquez 2013-01-28 20:22:24 EST
Hola Eduardo, te escribo en español porque se que tu lo hablas, he logrado empaquetar Tupi para Fedora 18, descargue el codigo fuente haciendo un clone git ( https://github.com/xtingray/tupi ), comprimi el contenido, lo subi al proyecto donde estoy (PostInstallerF), renombre algunas depedencias de compilacion, aplique un parche, y guala! Ahora Funciona correctamente, comparto el link, espero el paquete ya lo tengamos en los repositorios de Fedora, porque segun me comentaron por alli, tu te encargas del paquete para Fedora. Este es mi granito de Arena a este extraordinario programa. http://sourceforge.net/projects/postinstaller/files/srpm/tupi-0.2-1.fc18.src.rpm


David Va.
Comment 42 David Vásquez 2013-01-28 20:38:10 EST
Gustav Gonzalez, espero te sirva, dentro va el spec y el parche :) , creo que confundi tu nombre jeje http://sourceforge.net/projects/postinstaller/files/srpm/tupi-0.2-1.fc18.src.rpm
Comment 43 Gustav Gonzalez 2013-01-28 21:47:12 EST
Hola David,

Muchas gracias por tu colaboración. Esperemos que los expertos revisen tus archivos para verificar que el paquete cumpla con las especificaciones. Tu aporte es muy bienvenido a la causa :)
Comment 44 Gustav Gonzalez 2013-01-28 22:15:46 EST
Dear friends,

Unfortunately, I can't keep working on the Tupi package for Fedora due to my lack of free time. 
Right now, I need to focus on the project source code for the next release, so I really appreciate if someone else try to build the official rpm installer.

Thank you very much for your hints and support along this thread.

PS: Feel free to send me any feedback about bugs or compilation issues. Thank you guys!
Comment 45 Volker Fröhlich 2013-02-01 02:30:58 EST

*** This bug has been marked as a duplicate of bug 906443 ***