Bug 871092

Summary:	Review Request: updf - Application to write to PDF
Product:	[Fedora] Fedora	Reporter:	Antonio T. (sagitter) <anto.trande>
Component:	Package Review	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	anto.trande, christoph.wickert, ib54003, mario.blaettermann, notting, package-review
Target Milestone:	---
Target Release:	---
Hardware:	noarch
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-20 10:59:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Antonio T. (sagitter) 2012-10-29 15:28:30 UTC

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-1.fc17.src.rpm

Description: A tool to write and paint to an existing PDF file. 
uPdf can insert pages of another PDF, insert new pages, 
remove and extract pages, rotate pages, paste an image in 
the existing PDF, and much more.

Fedora Account System Username: sagitter

Comment 1 Benedikt Schäfer 2012-10-30 19:34:06 UTC

Hi Antonio,

the package doesnt build. 

You have to write the BuildRequires like that:
BuildRequires: pkgconfig, gettext, ..., ..., ...

also the 

Requires: pycairo, ..., ...

Note: I am not a packanger just on the way to become, so don't count on me to much ;)!

Comment 2 Mario Blättermann 2012-10-30 22:01:03 UTC

(In reply to comment #1) 
> You have to write the BuildRequires like that:
> BuildRequires: pkgconfig, gettext, ..., ..., ...
> 
> also the 
> 
> Requires: pycairo, ..., ...
> 
No, if we write one package name per line, it is better readable. Well, we are not forced by the packaging guidelines to do so, but this is widely used.

Comment 3 Antonio T. (sagitter) 2012-10-30 22:05:11 UTC

(In reply to comment #1)
> Hi Antonio,
> 
> the package doesnt build. 

Hi Benedikt.

Why you say that ?
What's  up ?

> 
> You have to write the BuildRequires like that:
> BuildRequires: pkgconfig, gettext, ..., ..., ...
> 
> also the 
> 
> Requires: pycairo, ..., ...
> 
> Note: I am not a packanger just on the way to become, so don't count on me
> to much ;)!

Instead I know that 'BuildRequires' entries (like 'Requires') must be listen one for line and where possible indicate in pkgconfig(?) form; for example: 

$ rpm -q --provides python-devel
config(python-devel) = 2.7.3-7.2.fc17
pkgconfig(python) = 2.7
pkgconfig(python-2.7) = 2.7
pkgconfig(python2) = 2.7    
python2-devel = 2.7.3-7.2.fc17
python-devel = 2.7.3-7.2.fc17
python-devel(x86-64) = 2.7.3-7.2.fc17

Comment 4 Christoph Wickert 2012-10-31 00:30:59 UTC

(In reply to comment #1)

> You have to write the BuildRequires like that:
> BuildRequires: pkgconfig, gettext, ..., ..., ...

It doesn't matter if one uses one line or several lines.

However there are at least two problems with this package. Benedikt, please look a little closer at the %files section, maybe you find them. ;)

(In reply to comment #3)
> Why you say that ?
> What's  up ?

Benedikt is right, it doesn't build in mock:

+ /usr/bin/python setup.py build
Traceback (most recent call last):
  File "setup.py", line 7, in <module>
    from DistUtilsExtra.command import *
ImportError: No module named DistUtilsExtra.command
Fehler beim Bauen des RPM:
Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.Y6MZro (%build)
    Fehler-Status beim Beenden von /var/tmp/rpm-tmp.Y6MZro (%build)
Child return code was: 1
EXCEPTION: Command failed. See logs for output.

=> add python-distutils-extra as BuildRequires.

> Instead I know that 'BuildRequires' entries (like 'Requires') must be listen
> one for line 

As I said, it doesn't matter. I prefer one per line, because this makes it easier to read in diffs later.

> and where possible indicate in pkgconfig(?) form.

This is not a must either, it has advantages and disadvantages:
Pro: works on different distributions, no matter how they name their packages.
Con: slower because rpm needs to process more dependencies and yum needs to download more metadata; does not work with old versions of rpm.

Comment 5 Antonio T. (sagitter) 2012-10-31 09:15:28 UTC

(In reply to comment #4)
> Benedikt is right, it doesn't build in mock:
> 
> + /usr/bin/python setup.py build
> Traceback (most recent call last):
>   File "setup.py", line 7, in <module>
>     from DistUtilsExtra.command import *
> ImportError: No module named DistUtilsExtra.command
> Fehler beim Bauen des RPM:
> Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.Y6MZro (%build)
>     Fehler-Status beim Beenden von /var/tmp/rpm-tmp.Y6MZro (%build)
> Child return code was: 1
> EXCEPTION: Command failed. See logs for output.
> 
> => add python-distutils-extra as BuildRequires.

Done.

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-1.fc17.src.rpm

Comment 6 Antonio T. (sagitter) 2012-10-31 09:58:19 UTC

(In reply to comment #4)
> (In reply to comment #1)
> 
> > You have to write the BuildRequires like that:
> > BuildRequires: pkgconfig, gettext, ..., ..., ...
> 
> It doesn't matter if one uses one line or several lines.
> 
> However there are at least two problems with this package. Benedikt, please
> look a little closer at the %files section, maybe you find them. ;)
> 

Maybe I'm able to find them :).

1) On the Packaging:Guidelines wiki I read:

>... desktop-file-install MUST be used if the package does not install the file or >there are changes desired to the .desktop file 

so maybe I must also add 'desktop-file-install' apart from 'desktop-file-check'.

2) I don't know if the %post %postun scriptlet are necessary in this case.

Comment 7 Benedikt Schäfer 2012-10-31 11:26:05 UTC

(In reply to comment #1)
> Hi Antonio,

> You have to write the BuildRequires like that:
> BuildRequires: pkgconfig, gettext, ..., ..., ...
> 
> also the 
> 
> Requires: pycairo, ..., ...
> 
> Note: I am not a packanger just on the way to become, so don't count on me
> to much ;)!

Sorry it was my mistake!

Comment 8 Benedikt Schäfer 2012-10-31 11:38:25 UTC

Package Review
==============

Key:
[x] = Pass
[!] = Fail
[-] = Not applicable
[?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
[!]: Package contains BR: python2-devel or python3-devel
See: http://fedoraproject.org/wiki/Packaging:Python#BuildRequires


===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[?]: %build honors applicable compiler flags or justifies otherwise.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package contains no bundled libraries.
[!]: Changelog in prescribed format.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Sources contain only permissible code or content.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install if there is
     such a file.
[?]: Development files must be in a -devel package
[x]: Package requires other packages for directories it uses.
[x]: Package uses nothing in %doc for runtime.
[?]: Package is not known to require ExcludeArch.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[?]: Package complies to the Packaging Guidelines
[x]: Spec file lacks Packager, Vendor, PreReq tags.
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[?]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "GPL (v3 or later)", "Unknown or generated". 2 files have unknown
     license. Detailed output of licensecheck in
     /home/makerpm/871092-updf/licensecheck.txt
[x]: Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: Package is named using only allowed ASCII characters.
[x]: Package is named according to the Package Naming Guidelines.
[?]: Package does not generate any conflict.
     Note: Package contains no Conflicts: tag(s)
[x]: Package do not use a name that already exist
[x]: Package obeys FHS, except libexecdir and /usr/target.
[?]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[ ]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Package installs properly.
[?]: Package is not relocatable.
[x]: Requires correct, justified where necessary.
[x]: CheckResultdir
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file is legible and written in American English.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: Package contains systemd file(s) if in need.
[x]: File names are valid UTF-8.
[-]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 40960 bytes in 3 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[!]: Package contains BR: python2-devel or python3-devel
[?]: Binary eggs must be removed in %prep
     Note: Cannot find sources under BUILD (using prebuilt sources?)
[?]: Python eggs must not download any dependencies during the build process.
[?]: A package which is used by another package via an egg interface should
     provide egg info.
[?]: Package meets the Packaging Guidelines::Python

===== SHOULD items =====

Generic:
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[!]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[?]: Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: The placement of pkgconfig(.pc) files are correct.
[x]: SourceX tarball generation or download is documented.
     Note: Package contains tarball without URL, check comments
[x]: SourceX / PatchY prefixed with %{name}.
[x]: SourceX is a working URL.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[?]: %check is present and all tests pass.
[ ]: Packages should try to preserve timestamps of original installed files.
[x]: Spec use %global instead of %define.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.


Rpmlint
-------
Checking: updf-0.0.2.4-1.fc18.src.rpm
          updf-0.0.2.4-1.fc18.noarch.rpm
updf.src: W: invalid-url Source0: updf-0.0.2.4.tar.gz
updf.noarch: W: no-manual-page-for-binary updf
2 packages and 0 specfiles checked; 0 errors, 2 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint updf
updf.noarch: W: no-manual-page-for-binary updf
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
# echo 'rpmlint-done:'



Requires
--------
updf-0.0.2.4-1.fc18.noarch.rpm (rpmlib, GLIBC filtered):
    
    /usr/bin/python
    poppler
    pycairo
    rubygem-gdk_pixbuf2



Provides
--------
updf-0.0.2.4-1.fc18.noarch.rpm:
    
    updf = 0.0.2.4-1.fc18



MD5-sum check
-------------


Generated by fedora-review 0.3.1 (b71abc1) last change: 2012-10-16
Buildroot used: fedora-18-x86_64
Command line :/usr/bin/fedora-review -b 871092




I think the %changelog isn't in the prescribed format:

%changelog
* Mon Oct 29 2012 Antonio Trande <sagitter> 0.0.2.4-1
- 0.0.2.4-1

in my opinion it should be:

%changelog
* Mon Oct 29 2012 Antonio Trande <sagitter> 0.0.2.4-1
- inital version


I don't know if in %files the %{python_sitelib} is a marco is it?
%{python_sitelib}/updf-*.egg-info


Note: I am not a packanger just on the way to become, its my first review!

Comment 9 Mario Blättermann 2012-10-31 12:15:34 UTC

Some (or maybe all?) source file headers contain the "newer versions" clause regarding the license, that's why the license is GPLv3+.


BuildRequires: pkgconfig(python2)
is a recursive requirement of pycairo, you can drop it.


BuildRequires: pkgconfig(pycairo)
BuildRequires: pkgconfig(poppler)
BuildRequires: pkgconfig(ruby-gdk-pixbuf2)

That's OK, and it makes sure that rpm will find the runtime dependencies due to system calls during the build. You can drop the following:

Requires: pycairo
Requires: poppler
Requires: rubygem-gdk_pixbuf2


%lang(ca) %{_datadir}/locale-langpack/ca/LC_MESSAGES/%{name}.mo
%lang(cs) %{_datadir}/locale-langpack/cs/LC_MESSAGES/%{name}.mo
%lang(de) %{_datadir}/locale-langpack/de/LC_MESSAGES/%{name}.mo
%lang(eo) %{_datadir}/locale-langpack/eo/LC_MESSAGES/%{name}.mo
%lang(es) %{_datadir}/locale-langpack/es/LC_MESSAGES/%{name}.mo
%lang(eu) %{_datadir}/locale-langpack/eu/LC_MESSAGES/%{name}.mo
%lang(sk) %{_datadir}/locale-langpack/sk/LC_MESSAGES/%{name}.mo
%lang(zh_CN) %{_datadir}/locale-langpack/zh_CN/LC_MESSAGES/%{name}.mo

Therefore we have the %find_lang macro:
http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files


python-setuptools-devel is virtually provided by python-setuptools. You can use the latter, because python-setuptools-devel doesn't really exist.


Please bump the release tag each time you change the package, even in the current state. Fill the %changelog with some useful info instead of repeating the version and release number.

Comment 10 Antonio T. (sagitter) 2012-10-31 14:46:04 UTC

(In reply to comment #9)
> 
> %lang(ca) %{_datadir}/locale-langpack/ca/LC_MESSAGES/%{name}.mo
> %lang(cs) %{_datadir}/locale-langpack/cs/LC_MESSAGES/%{name}.mo
> %lang(de) %{_datadir}/locale-langpack/de/LC_MESSAGES/%{name}.mo
> %lang(eo) %{_datadir}/locale-langpack/eo/LC_MESSAGES/%{name}.mo
> %lang(es) %{_datadir}/locale-langpack/es/LC_MESSAGES/%{name}.mo
> %lang(eu) %{_datadir}/locale-langpack/eu/LC_MESSAGES/%{name}.mo
> %lang(sk) %{_datadir}/locale-langpack/sk/LC_MESSAGES/%{name}.mo
> %lang(zh_CN) %{_datadir}/locale-langpack/zh_CN/LC_MESSAGES/%{name}.mo
> 
> Therefore we have the %find_lang macro:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files
> 

I tried to use this macro but I obtain:

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/de

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/de/LC_MESSAGES

copying build/locale-langpack/de/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-
langpack/de/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/eo

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/eo/LC_MESSAGES

copying build/locale-langpack/eo/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/eo/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/eu

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/eu/LC_MESSAGES

copying build/locale-langpack/eu/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/eu/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/cs

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/cs/LC_MESSAGES

copying build/locale-langpack/cs/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/cs/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/ca

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/ca/LC_MESSAGES

copying build/locale-langpack/ca/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/ca/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/zh_CN

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/zh_CN/LC_MESSAGES

copying build/locale-langpack/zh_CN/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/zh_CN/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/es

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/es/LC_MESSAGES

copying build/locale-langpack/es/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/es/LC_MESSAGES

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/sk

creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/sk/LC_MESSAGES

copying build/locale-langpack/sk/LC_MESSAGES/updf.mo -> /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/share/locale-langpack/sk/LC_MESSAGES
running install_egg_info

Creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/lib/python2.7/site-packages/

Writing /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/lib/python2.7/site-packages/updf-0.0.2.4-py2.7.egg-info
+ /usr/lib/rpm/find-lang.sh /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64 updf

No translations found for updf in /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64
error: Bad exit status from /var/tmp/rpm-tmp.2blK3U (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.2blK3U (%install)

Comment 11 Christoph Wickert 2012-11-01 20:00:39 UTC

(In reply to comment #5)
> Done.

Whenever you change something, please bump the release and add a changelog entry. We should be at 0.0.2.4-2 now.



(In reply to comment #6)
> 1) On the Packaging:Guidelines wiki I read:
> 
> >... desktop-file-install MUST be used if the package does not install the file 
> > or there are changes desired to the .desktop file 
>
> so maybe I must also add 'desktop-file-install' apart from
> 'desktop-file-check'.

No, one is enough, either desktop-file-install or desktop-file-check

> 2) I don't know if the %post %postun scriptlet are necessary in this case.

What should they be needed for? And this is not about the %files section either.

Mario already pointed out one of the problems with the %files section: You are hardcoding the languages. Whenever a new translation is added, the build will fail. %find_lang does not work because the locales are in /usr/share/locale-langpack. This is wrong. Can you try patching the package to use /usr/share/locale instead?

Hint: I had a similar problem and solved it with sed, see line 45-50 at 
http://pkgs.fedoraproject.org/cgit/rednotebook.git/tree/rednotebook.spec?id=de7097c1#n45

Comment 12 Mario Blättermann 2012-11-01 20:11:26 UTC

(In reply to comment #6)
> 2) I don't know if the %post %postun scriptlet are necessary in this case.

Normally, you have to update the desktop database only if the desktop file has a "MimeType" key:
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-database

Comment 13 Christoph Wickert 2012-11-01 21:22:03 UTC

Mario, we have two new packager candidates here, we should not make it too easy for them. ;)

Comment 14 Mario Blättermann 2012-11-01 21:47:37 UTC

(In reply to comment #13)
> Mario, we have two new packager candidates here, we should not make it too
> easy for them. ;)

OK, I will be silent from now on ;)

Comment 15 Antonio T. (sagitter) 2012-11-02 13:21:00 UTC

(In reply to comment #11)
> 
> Mario already pointed out one of the problems with the %files section: You
> are hardcoding the languages. Whenever a new translation is added, the build
> will fail. %find_lang does not work because the locales are in
> /usr/share/locale-langpack. This is wrong. Can you try patching the package
> to use /usr/share/locale instead?
> 
> Hint: I had a similar problem and solved it with sed, see line 45-50 at 
> http://pkgs.fedoraproject.org/cgit/rednotebook.git/tree/rednotebook.
> spec?id=de7097c1#n45

Ok. These lines:

# heavily borrowed from /usr/lib/rpm/find-lang.sh
#find %{buildroot} -type f -o -type l|sort|sed '
#s:'"%{buildroot}"'::
#s:\(.*/i18n/\)\([^/_]\+\)\(.*\.mo$\):%lang(\2) \1\2\3:
#s:^\([^%].*\)::
#/^$/d' > %{name}.lang

are very similar to ones on /usr/lib/rpm/find-lang.sh, so do I need to use them to find all *.mo files and write %{name}.lang. The issue is how to do that.
  
Maybe do I need of a .sh file ? Or does exist another way ?

Comment 16 Antonio T. (sagitter) 2012-11-02 14:45:14 UTC

(In reply to comment #15)
> (In reply to comment #11)
> > 
> > Mario already pointed out one of the problems with the %files section: You
> > are hardcoding the languages. Whenever a new translation is added, the build
> > will fail. %find_lang does not work because the locales are in
> > /usr/share/locale-langpack. This is wrong. Can you try patching the package
> > to use /usr/share/locale instead?
> > 
> > Hint: I had a similar problem and solved it with sed, see line 45-50 at 
> > http://pkgs.fedoraproject.org/cgit/rednotebook.git/tree/rednotebook.
> > spec?id=de7097c1#n45
> 
> Ok. These lines:
> 
> # heavily borrowed from /usr/lib/rpm/find-lang.sh
> #find %{buildroot} -type f -o -type l|sort|sed '
> #s:'"%{buildroot}"'::
> #s:\(.*/i18n/\)\([^/_]\+\)\(.*\.mo$\):%lang(\2) \1\2\3:
> #s:^\([^%].*\)::
> #/^$/d' > %{name}.lang
> 

Could be right like that 

...
%install
%{__python} setup.py install --skip-build --root $RPM_BUILD_ROOT 

find $RPM_BUILD_ROOT -type f -o -type l|sort| \
           sed '
                 s:'"$RPM_BUILD_ROOT%{_datadir}"'::
                 s:\(.*/locale-langpack/\)\([^/_]\+\)\(.*\.mo$\):%lang(\2) \1\2\3:
                 s:^\([^%].*\)::
                 /^$/d' \
> %{name}.lang
%find_lang %{name}

... 
?

Comment 17 Antonio T. (sagitter) 2012-11-04 17:29:06 UTC

I have used

...
find $RPM_BUILD_ROOT -type f -o -type l| \
           sed '
                 s:'"$RPM_BUILD_ROOT"'::
                 s:\(.*%{_datadir}/locale/\)\([^/_]\+\)\(.*\.mo$\):%lang(\2) \1\2\3:
                 s:^\([^%].*\)::
                 /^$/d' > %{name}.lang
%find_lang %{name}
...

but I obtain

...
Creating /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/lib/python2.7/site-packages/
Writing /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64/usr/lib/python2.7/site-packages/updf-0.0.2.4-py2.7.egg-info
+ sed '
                 s:/home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64::
                 s:\(.*/usr/share/locale/\)\([^/_]\+\)\(.*\.mo$\):%lang(\2) \1\2\3:
                 s:^\([^%].*\)::
                 /^$/d'
+ find /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64 -type f -o -type l
+ /usr/lib/rpm/find-lang.sh /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64 updf
No translations found for updf in /home/sagitter/rpmbuild/BUILDROOT/updf-0.0.2.4-1.fc17.x86_64
error: Bad exit status from /var/tmp/rpm-tmp.TM38Ny (%install)

Where is my error ?

Comment 18 Antonio T. (sagitter) 2012-11-05 21:03:29 UTC

Ok, now it should be fine.
I have created a patch to fix all paths.

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-2.fc17.src.rpm

Comment 19 Antonio T. (sagitter) 2012-11-05 21:04:49 UTC

Ok, now it should be fine.
I have created a patch to fix all paths.

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-2.fc17.src.rpm

Comment 20 Antonio T. (sagitter) 2012-11-05 21:05:57 UTC

Ok, now it should be fine.
I have created a patch to fix all paths.

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-2.fc17.src.rpm

Comment 21 Michael Schwendt 2012-12-12 11:35:08 UTC

Veto!

That's the brief version of my comment. ;)

[...]

The longer version is: This package review has developed into a wrong direction. Even if there are "two new packager candidates", there are also "two sponsors", who should try to be more helpful.

Part of the initial guidance should have been to point at the ReviewGuidelines page - https://fedoraproject.org/wiki/Packaging:ReviewGuidelines - and to introduce the new packagers to "rpmlint", which is the first MUST on that list, and every packager ought to know it and use it instead of waiting for the reviewer to do that. Afterall, the packager should have access to the built rpms already whereas the reviewer would first need to download them or submit an own build job.

To the package submitter I recommend being explicit about changes to the src.rpm/spec and about any tasks that have been completed. For example, mention whether you've tried to install the package and whether you've been successful at running the software. The latter is a SHOULD item in the review guidelines.

[...]

The following suggestion is absolutely wrong:

> You can drop the following:
> 
> Requires: pycairo
> Requires: poppler
> Requires: rubygem-gdk_pixbuf2

As a new packager I would have asked the potential sponsor the "Why?" question.

Comment 22 Antonio T. (sagitter) 2012-12-12 15:31:16 UTC

Hi Michael.

(In reply to comment #21)
> Veto!
> 
> That's the brief version of my comment. ;)
> 
> [...]
> 
> The longer version is: This package review has developed into a wrong
> direction. Even if there are "two new packager candidates", there are also
> "two sponsors", who should try to be more helpful.
> 
> Part of the initial guidance should have been to point at the
> ReviewGuidelines page -
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines - and to introduce
> the new packagers to "rpmlint", which is the first MUST on that list, and
> every packager ought to know it and use it instead of waiting for the
> reviewer to do that. Afterall, the packager should have access to the built
> rpms already whereas the reviewer would first need to download them or
> submit an own build job.
> 
> To the package submitter I recommend being explicit about changes to the
> src.rpm/spec and about any tasks that have been completed. For example,
> mention whether you've tried to install the package and whether you've been
> successful at running the software. The latter is a SHOULD item in the
> review guidelines.
> 
> [...]

After very useful comment from Christoph, I tried to overcome the language path problem on this package. The only way that I have been able to do is by creating  a patch to treat these defects. As you can see, the patch changes all old paths (/usr/share/locale-langpack) to the right ones (/usr/share/locale).
Now the package is built fine (I think).  

> 
> The following suggestion is absolutely wrong:
> 
> > You can drop the following:
> > 
> > Requires: pycairo
> > Requires: poppler
> > Requires: rubygem-gdk_pixbuf2
> 
> As a new packager I would have asked the potential sponsor the "Why?"
> question.

I trusted blindly :)

Comment 23 Michael Schwendt 2012-12-12 19:34:51 UTC

Which is unfortunate, because reviewers make mistakes, and that would have been an opportunity to show that you know your stuff.

Without adding the needed run-time dependencies to the package, currently the program crashes early with a clear Python traceback. There are no automatic RPM dependencies for Python modules [yet], so you need to add them manually:

$ rpm -qpR ./rpmbuild/repodir/fedora-18-build/updf/0.0.2.4-2.fc17/noarch/updf-0.0.2.4-2.fc18.noarch.rpm
/usr/bin/python
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
$

As one can see, just /usr/bin/python is not sufficient for this program, because it contains import statements for several other modules. "pycairo" (for a direct "import cairo" in the source code) and "pygobject3" are just two that are missing, but may be installed already only because other packages depend on them. "numpy" is another crucial one.

Also not forget about users, who start with a minimal installation. Those actually file related bug reports from time to time.


> Requires: poppler

Not a Python package, so the sponsor should have asked you to explain why you added this.

> Requires: rubygem-gdk_pixbuf2

Same here. updf is written in Python. Why would it need a Ruby package?

Comment 24 Christoph Wickert 2012-12-12 20:17:24 UTC

(In reply to comment #21)
> The longer version is: This package review has developed into a wrong
> direction. Even if there are "two new packager candidates", there are also
> "two sponsors", who should try to be more helpful.

While I agree the review has gone south, I don't think this is the sponsors' fault. Other than the bad advice to remove the runtime Requires I see nothing wrong. On the contrary, there was a lot of helpful hints, but unfortunately the package submitter did not follow all of them (e.g. to increase the release with every new package).

I think the main problem is the software that is packaged here. IHMO it's not anywhere near inclusion in Fedora: It violates the FHS (at least at the beginning it was), hardcodes paths and has no proper build system. Not necessarily the easiest thing to package, especially for new contributors.

> Part of the initial guidance should have been to point at the
> ReviewGuidelines page -
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines

I *did* advise Benedikt to use the checklist. 

> - and to introduce the new packagers to "rpmlint"

We linked the Packaging Guidelines on various occasions and rpm is part of these guidelines. It was already used in this review, so I find it hard to believe our new contributors are not aware of it.


Anyway, I am too busy ATM to take care of this review or to sponsor Antonio. But I think he already learned a lot and the package has improved much. I'd appreciate if somebody else can take over and continue from here.

Comment 25 Michael Schwendt 2012-12-12 20:47:38 UTC

> We linked the Packaging Guidelines on various occasions and rpm[lint]
> is part of these guidelines.

Many other things are part of the guidelines but unrelated to this package.

Links into the main Packaging Guidelines page are something very different from the much more specific Review Guidelines page. That list contains individual MUST/SHOULD items. It's a list of _specific tasks_, with rpmlint being the first one as it catches many errors.

Sure, one can try to continue with "hidden hints" and silently expect a new packager to read the full guidelines and its subpages. Or abstain from giving hints (comment 13 and comment 14). That can get tedious for both parties involved. The package contributor is expected to have checked the package already anyway:

| https://fedoraproject.org/wiki/Package_Review_Process#Contributor
|
| As a Contributor, you should have already made a package
| which adheres to the Package Naming Guidelines and Packaging Guidelines.

If that lead to all new contributors submitting packages without errors, the review process would be very different or even non-existant.

> I *did* advise Benedikt to use the checklist. 

I refer to this ticket only where that hasn't happened. It may be that you guide Benedikt elsewhere, too, but the submitter in this ticket should become familiar with the Review Guidelines, too.

Comment 26 Antonio T. (sagitter) 2012-12-13 14:01:10 UTC

(In reply to comment #23)
> Which is unfortunate, because reviewers make mistakes, and that would have
> been an opportunity to show that you know your stuff.

Ok, I understood. I'll be more incisive in future.

> 
> Without adding the needed run-time dependencies to the package, currently
> the program crashes early with a clear Python traceback. There are no
> automatic RPM dependencies for Python modules [yet], so you need to add them
> manually:
> 
> $ rpm -qpR
> ./rpmbuild/repodir/fedora-18-build/updf/0.0.2.4-2.fc17/noarch/updf-0.0.2.4-2.
> fc18.noarch.rpm
> /usr/bin/python
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PartialHardlinkSets) <= 4.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(PayloadIsXz) <= 5.2-1
> $
> 

Ah, so there is another problem besides me. :)
How can I know all the right dependencies ?

> As one can see, just /usr/bin/python is not sufficient for this program,
> because it contains import statements for several other modules. "pycairo"
> (for a direct "import cairo" in the source code) and "pygobject3" are just
> two that are missing, but may be installed already only because other
> packages depend on them. "numpy" is another crucial one.
> 
> Also not forget about users, who start with a minimal installation. Those
> actually file related bug reports from time to time.
> 
> 
> > Requires: poppler
> 
> Not a Python package, so the sponsor should have asked you to explain why
> you added this.
> 
> > Requires: rubygem-gdk_pixbuf2
> 
> Same here. updf is written in Python. Why would it need a Ruby package?

All dependencies come from upstream but probably I have mixed some of them.

Required dependencies:

	gir1.2-gtk-3.0,
	gir1.2-gdkpixbuf-2.0,
	gir1.2-poppler-0.18,
	python-cairo

Comment 27 Antonio T. (sagitter) 2012-12-13 14:08:13 UTC

source(In reply to comment #24)
> (In reply to comment #21)
> > The longer version is: This package review has developed into a wrong
> > direction. Even if there are "two new packager candidates", there are also
> > "two sponsors", who should try to be more helpful.
> 
> (e.g. to
> increase the release with every new package).

I'm sorry. 
I'll do that.

> 
> I think the main problem is the software that is packaged here. IHMO it's
> not anywhere near inclusion in Fedora: It violates the FHS (at least at the
> beginning it was), hardcodes paths and has no proper build system. Not
> necessarily the easiest thing to package, especially for new contributors.

If you refer to the language hardcodes paths, the patch could be a solution. 
Or no ?

Comment 28 Antonio T. (sagitter) 2012-12-13 15:27:07 UTC

(In reply to comment #26)
> (In reply to comment #23)
> > 
> > > Requires: poppler
> > 
> > Not a Python package, so the sponsor should have asked you to explain why
> > you added this.
> > 
> > > Requires: rubygem-gdk_pixbuf2
> > 
> > Same here. updf is written in Python. Why would it need a Ruby package?
> 
> All dependencies come from upstream but probably I have mixed some of them.
> 
> Required dependencies:
> 
> 	gir1.2-gtk-3.0,
> 	gir1.2-gdkpixbuf-2.0,
> 	gir1.2-poppler-0.18,
> 	python-cairo

I think I have done a lot of confusion with these packages because there are different of package names between Debian and Fedora.

gir1.2-gdkpixbuf-2.0: GDK Pixbuf libraries - introspection GObject --> gdk-pixbuf2 on Fedora ? (no rubygem-gdk_pixbuf2, that's an my severe error)

gir1.2-poppler-0.18: rendering library for PDF based on Xpdf --> pypoppler on Fedora ?

Please, can anyone confirm me about this ?

Comment 29 Antonio T. (sagitter) 2012-12-13 17:25:57 UTC

Changelog updated and required packages added.
This time I have built updf on a fresh system by using mock (Fedora 16 i386).

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-6.fc17.src.rpm


$ rpmlint /var/lib/mock/fedora-18-i386/result/*.rpm
updf.noarch: W: no-manual-page-for-binary updf
updf.src: W: invalid-url Source0: updf-0.0.2.4.tar.gz
2 packages and 0 specfiles checked; 0 errors, 2 warnings.

Comment 30 Antonio T. (sagitter) 2012-12-13 17:28:34 UTC

source(In reply to comment #29)
> Changelog updated and required packages added.
> This time I have built updf on a fresh system by using mock (Fedora 16 i386).
> 
> Spec URL: http://sagitter.fedorapeople.org/updf.spec
> SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-6.fc17.src.rpm
> 
> 
> $ rpmlint /var/lib/mock/fedora-18-i386/result/*.rpm
> updf.noarch: W: no-manual-page-for-binary updf
> updf.src: W: invalid-url Source0: updf-0.0.2.4.tar.gz
> 2 packages and 0 specfiles checked; 0 errors, 2 warnings.


The link to src.rpm was wrong; sorry.

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-6.fc18.src.rpm

Comment 31 Michael Schwendt 2012-12-13 21:06:28 UTC

> How can I know all the right dependencies ?

Only by becoming intimately familiar with the software you want to package, by examining its Python source code, and by using Yum or repoquery to locate needed packages.

For example, you can use your favourite search tool to locate "import" statements. Then find out what packages include the needed Python modules.

The primary task would be to get the BuildRequires right, so the build doesn't fail and no features, which could be enabled, get disabled. The secondary (and somewhat less important) task would be to complete the run-time dependencies. To mark your package as depending on other packages.

> gir1.2-gdkpixbuf-2.0: GDK Pixbuf libraries - introspection GObject -->
> gdk-pixbuf2 on Fedora ? 

Reviewing Debian packages is outside the scope of this package review request. You would need to be familiar with the contents of those packages to tell whether they include Python stuff. What does "gdk-pixbuf2" include that would be needed?

$ rpm -qf /usr/lib64/girepository-1.0/GdkPixbuf-2.0.typelib 
gdk-pixbuf2-2.26.5-1.fc18.x86_64

Ah!

> gir1.2-poppler-0.18: rendering library for PDF based on Xpdf -->
> pypoppler on Fedora ?

pypoppler on Fedora only provides a Python module "poppler" (lower-case first letter!), but nothing to satisfy:

  updf.py:from gi.repository import Poppler, Gtk, Gdk, GObject, GdkPixbuf

$ rpm -qf /usr/lib64/girepository-1.0/Poppler-0.18.typelib 
poppler-glib-0.20.2-9.fc18.x86_64

Ah!

> BuildRequires: pycairo-devel
> BuildRequires: pygobject3-devel
> BuildRequires: gdk-pixbuf2-devel

Have you added these BuildRequires because building updf failed without them? Do these packages contain Python stuff needed to build updf? If in doubt, examine what's included in those packages.

If you follow
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
to step 2.1.8 you could submit a scratch build in the Fedora Build System.

Comment 32 Antonio T. (sagitter) 2012-12-14 13:50:10 UTC

(In reply to comment #31)
> > How can I know all the right dependencies ?
> 
> Only by becoming intimately familiar with the software you want to package,
> by examining its Python source code, and by using Yum or repoquery to locate
> needed packages.
> 
> For example, you can use your favourite search tool to locate "import"
> statements. Then find out what packages include the needed Python modules.

I thought that it was a task of upstream what of listing all right dependencies ...  

> The primary task would be to get the BuildRequires right, so the build
> doesn't fail and no features, which could be enabled, get disabled. The
> secondary (and somewhat less important) task would be to complete the
> run-time dependencies. To mark your package as depending on other packages.
> 
> > gir1.2-gdkpixbuf-2.0: GDK Pixbuf libraries - introspection GObject -->
> > gdk-pixbuf2 on Fedora ? 
> 
> Reviewing Debian packages is outside the scope of this package review
> request. You would need to be familiar with the contents of those packages
> to tell whether they include Python stuff. What does "gdk-pixbuf2" include
> that would be needed?
> 

Every 'import' statements indicate a python module (I think) so for example (related package names enclosed in parenthesis):

distutils (python-distutils-extra) - cmd.py (pypy-libs, python-libs)
                                        - os.py (python-libs)
                                        - glob.py (python-libs)
                                        - shlex.py (python-libs)
                                        - subprocess.py (python-libs)
                                        - shutil.py (python-libs)
                                        - polib.py (python-polib)
                                        - ConfigParser.py (python-libs)
                                        - codecs.py (python-libs)  
                                        - msgfmt -->

msgfmt.py -- sys.py (shedskin)
          - os.py (python-libs)
          - getopt (shedskin)
          - struct (shedskin, python-libs)
          - array (shedskin)

comun.py  -- os.py (python-libs)
          - locale.py (pypy-libs, python-libs)
          - gettext.py (python-libs)


and so on.
However, if it is a right procedure, the same '.py' file is provided as a part of more rpm packages and it is difficult to know which is the right one.  

> $ rpm -qf /usr/lib64/girepository-1.0/GdkPixbuf-2.0.typelib 
> gdk-pixbuf2-2.26.5-1.fc18.x86_64
> 
> Ah!
> 
> > gir1.2-poppler-0.18: rendering library for PDF based on Xpdf -->
> > pypoppler on Fedora ?
> 
> pypoppler on Fedora only provides a Python module "poppler" (lower-case
> first letter!), but nothing to satisfy:
> 
>   updf.py:from gi.repository import Poppler, Gtk, Gdk, GObject, GdkPixbuf
> 
> $ rpm -qf /usr/lib64/girepository-1.0/Poppler-0.18.typelib 
> poppler-glib-0.20.2-9.fc18.x86_64
> 
> Ah!
> 

:|


> > BuildRequires: pycairo-devel
> > BuildRequires: pygobject3-devel
> > BuildRequires: gdk-pixbuf2-devel
> 
> Have you added these BuildRequires because building updf failed without
> them? Do these packages contain Python stuff needed to build updf? If in
> doubt, examine what's included in those packages.

Maybe they are useless.

Comment 33 Michael Schwendt 2012-12-14 14:05:47 UTC

> I thought that it was a task of upstream what of listing all
> right dependencies ...  

Some do that, others don't do that.

Some add a good README with installation instructions. Others add build scripts that examine the build environment for everything that's needed.

Some add safety-checks to the executable, so it wouldn't crash at run-time. Others don't care whether a crash prints just a Python traceback or triggers something like ABRT in Fedora.

;-)

> msgfmt.py -- sys.py (shedskin)

Clearly, and not limited to this example, "import sys" is for the Python Standard Library, not shedskin. Most likely you forgot to consider the default search path for modules, which is not where shedskin stores its files, does it?

> However, if it is a right procedure, the same '.py' file is provided
> as a part of more rpm packages and it is difficult to know which is
> the right one.  

In standard search path for Python Modules? That would be a packaging bug.

Comment 34 Antonio T. (sagitter) 2012-12-14 14:20:35 UTC

(In reply to comment #33)
> Some do that, others don't do that.
> 

I have a tough nut to crack :)

> 
> > msgfmt.py -- sys.py (shedskin)
> 
> Clearly, and not limited to this example, "import sys" is for the Python
> Standard Library, not shedskin. Most likely you forgot to consider the
> default search path for modules, which is not where shedskin stores its
> files, does it?
> 
> > However, if it is a right procedure, the same '.py' file is provided
> > as a part of more rpm packages and it is difficult to know which is
> > the right one.  
> 
> In standard search path for Python Modules? That would be a packaging bug.

For example:

$ yum provides */sys.py
Plugin abilitati:langpacks, presto, refresh-packagekit
pyjamas-0.7-10.fc18.noarch : A python to Javascript compiler, Widget set, Framework and Toolkit
Repo         : fedora
Corrispondenza trovata in:
Nome file   : /usr/share/pyjamas/pyjs/src/pyjs/lib/sys.py



python3-postgresql-1.0.2-4.fc18.x86_64 : Connect to PostgreSQL with Python 3
Repo         : fedora
Corrispondenza trovata in:
Nome file   : /usr/lib64/python3.3/site-packages/postgresql/sys.py



shedskin-0.9-3.fc18.noarch : Python to C++ compiler
Repo         : fedora
Corrispondenza trovata in:
Nome file   : /usr/lib/python2.7/site-packages/shedskin/lib/sys.py


How can I know which is the right one ? :)

Comment 35 Michael Schwendt 2012-12-14 17:13:53 UTC

> yum provides */sys.py

Wrong query. :)

Basically, due to using the '*' wildcard, you here accept _any_ path. But a sys.py or sys.so in a location that is private to an arbitrary program does not matter at all here. Unless you tell Python to look for modules in that location. The paths you've found are not in Python's default list of module search paths:

$ python
...
>>> import sys
>>> print sys.path
['', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/PIL', '/usr/lib64/python2.7/site-packages/gst-0.10', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info']
>>> 


Btw, Python modules "sys", "os" and many others are well-known as being part of the Python Standard Library: http://docs.python.org/2/library/
You would not spend time on trying to search for them.

Comment 36 Antonio T. (sagitter) 2012-12-14 19:01:40 UTC

The requested packages should be

python-libs,
python-polib,
pycairo,
numpy,
librsvg2,
poppler-glib, 
gdk-pixbuf2, 
gtk2, 
gobject-introspection

Comment 37 Antonio T. (sagitter) 2012-12-14 20:26:51 UTC

source(In reply to comment #31)
> If you follow
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> to step 2.1.8 you could submit a scratch build in the Fedora Build System.

http://koji.fedoraproject.org/koji/taskinfo?taskID=4791786

Comment 38 Antonio T. (sagitter) 2012-12-17 12:39:40 UTC

(In reply to comment #37)
> source(In reply to comment #31)
> > If you follow
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> > to step 2.1.8 you could submit a scratch build in the Fedora Build System.
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4791786

Can I consider completed this package review ?
Are there additional comments ? 

:)

Comment 39 Michael Schwendt 2012-12-18 12:14:30 UTC

> Can I consider completed this package review ?

You could answer that yourself. ;-p
 -> https://fedoraproject.org/wiki/Package_Review_Process

Comment 40 Antonio T. (sagitter) 2012-12-30 17:25:20 UTC

Spec URL: http://sagitter.fedorapeople.org/updf.spec
SRPM URL: http://sagitter.fedorapeople.org/updf-0.0.2.4-6.fc18.src.rpm

Comment 41 Antonio T. (sagitter) 2013-01-20 10:59:42 UTC

uPdf's development seems idle.
I close this request for now.

Thank you all.