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!
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
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
Please post direct links to SRPM and spec file.
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!
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
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
You need to install a desktop file, since this is a graphical application: http://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files
(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!
(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.
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! :)
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?
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> - 0.2-2 - remove the race conditions in the build system - Use macros in Source0 - Other changes ... * Fri Oct 26 2012 Gustav Gonzalez <xtingray> - 0.2-1 - Making of RPM 2.- You need BR desktop-file-utils
(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
(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> - 0.2-2 > - remove the race conditions in the build system > - Use macros in Source0 > - Other changes ... > > * Fri Oct 26 2012 Gustav Gonzalez <xtingray> - 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 :)
Putting on the KDE reviews tracker as there's no separate one for Qt-only stuff.
> ExcludeArch: ppc ppc64 rings a big alarm bell for me. How about you fix your code to be endianness-safe instead?
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 ;)
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!
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.
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.
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
(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.
(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.
(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
(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
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!
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!
Ignore the rpmlint warning and don't delete the files.
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.
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!
> %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.
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!
Use: %exclude %{_datadir}/%{name}/data/translations
> 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.
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. :)
Your first file list was too detailed, your second one was not detailed enough. :-)
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!
Can you try '%find_lang %{name} --with-qt --all-name'?
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!
By the way, my FAS username is: xtingray :)
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.
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
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 :)
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!
*** This bug has been marked as a duplicate of bug 906443 ***