Bug 1015868 - Review Request: python-qutepart - Source code text editor component based on Qt
Review Request: python-qutepart - Source code text editor component based on Qt
Status: CLOSED DUPLICATE of bug 1273601
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Julien Enselme
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-06 07:42 EDT by Yajo
Modified: 2015-10-20 14:48 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1273601 (view as bug list)
Environment:
Last Closed: 2015-10-20 14:46:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
projects.rg: fedora‑review?


Attachments (Terms of Use)

  None (edit)
Description Yajo 2013-10-06 07:42:27 EDT
First of all, sorry for using OBS. Please take it as just a way to upload the files. Package builds fine on Fedora, tested with mock.

Spec URL: https://build.opensuse.org/package/view_file/home:yajo:enki/python-qutepart/python-qutepart.spec?expand=1

SRPM URL: http://download.opensuse.org/repositories/home:/yajo:/enki/Fedora_19/src/python-qutepart-1.1.0-2.1.src.rpm

Description:
Qutepart uses Kate syntax highlighters (XML files), contains port from
Javascript to Python of Kate indenters (12% of the code base in version 1.0.0),
and doesn't contain Katepart code.

Nothing is wrong with Katepart. Qutepart has been created for possibility to
reuse highlighters and indenters in projects where KDE dependency is not
acceptable.

Notes:
I get this error from rpmlint:
python-qutepart.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so cParser.so()(64bit)

I have searched, but cannot understand this. I'd need a bit of help here (at least).

Thanks.
Comment 1 T.C. Hollingsworth 2013-10-16 23:51:33 EDT
(In reply to Yajo from comment #0)
> Notes:
> I get this error from rpmlint:
> python-qutepart.x86_64: W: private-shared-object-provides
> /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so
> cParser.so()(64bit)
> 
> I have searched, but cannot understand this. I'd need a bit of help here (at
> least).

RPM automatically adds virtual provides for shared object files, since most are used for libraries.  Unfortunately, these provides are bogus for stuff outside /usr/lib(64), and should be removed.  This has been fixed in Fedora 20+, but manual filitering is still required for Fedora <= 19 and EPEL.

This explains everything in detail:
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

To fix it in this case, just add this to the top of your spec file:
%global __provides_exclude_from ^%{python_sitearch}/.*\\.so$
Comment 2 T.C. Hollingsworth 2013-10-17 00:33:41 EDT
(In reply to Yajo from comment #0)
> First of all, sorry for using OBS. Please take it as just a way to upload
> the files. Package builds fine on Fedora, tested with mock.

We could care less which hosting provider you use to host your files, but the link to the spec file does need to be a plaintext version, not one that uses HTML and syntax highlighting.  Automated tools like fedora-review <https://fedorahosted.org/FedoraReview/> won't be able to read it otherwise.

Unfortunately, OBS seems to require a login to link to raw content, so you might need to use a different hosting provider unless you can resolve that somehow (or if I'm just an idiot and can't figure out OBS ;-).  If you do not have access to alternate hosting space, you can request access to fedorapeople.org by filing a ticket in the packager sponsors' trac instance:
https://fedorahosted.org/packager-sponsors/

I'd also add that anyone with a Fedora account can run scratch builds on our Koji buildsystem if they want to.  This explains how it's done:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate

Please note that you cannot link to scratch builds from reviews, since they're garbage collected regularly.  (This isn't the case for OBS, so SRPM links there ought to be fine.  The non-plaintext spec is still an issue though.)

Spec review:

> # Afectado por el bug https://github.com/hlamer/qutepart/issues/1 y no deja
> # construir. Volver a intentarlo en sucesivas versiones.

Please use English in spec comments.  (Just to be clear, this doesn't extend to the Spanish summary/description, which is done correctly. :-)

> License:        GPLv2

The README file indicates this is under the LGPLv2.  The original Kate sources are under LGPLv2+, however.  Please clarify this with upstream and correct the License field in your spec file.

> %description
> Qutepart uses Kate syntax highlighters (XML files), contains port from
> Javascript to Python of Kate indenters (12% of the code base in version 1.0.0),
> and doesn't contain Katepart code.

Grammar nit:
"contains port" -> "contains a port"

Also, the statistics of what is ported really isn't relevant to end users.  You can remove the stuff in parenthesis.

> Nothing is wrong with Katepart. Qutepart has been created for possibility to
> reuse highlighters and indenters in projects where KDE dependency is not
> acceptable.

More grammar nits:  "created for possibility to reuse highlighters and indenters" is a little awkward.  I'd suggest changing it to something like "created so other applications can reuse its highlighers and indenters".

"where KDE dependency" -> "where a KDE dependency"

> %build
> %{__python} setup.py build

This package contains binary Python extensions, so the distribution compiler flags need to be used.  For more information, see:
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

For Python packages, that ends up being something like:

CFLAGS="%{buildroot}" %{__python} setup.py build
Comment 3 Yajo 2013-10-25 16:26:46 EDT
Sorry for the delay.

(In reply to T.C. Hollingsworth from comment #1)
> To fix it in this case, just add this to the top of your spec file:
> %global __provides_exclude_from ^%{python_sitearch}/.*\\.so$

Thanks. Fixed. RPM autorequires are like black magic to me. Definitely I need a sponsor.


(In reply to T.C. Hollingsworth from comment #2)
> Unfortunately, OBS seems to require a login to link to raw content, so you
> might need to use a different hosting provider unless you can resolve that
> somehow (or if I'm just an idiot and can't figure out OBS ;-).

Thanks, someone told me some people did not like OBS-hosted packages. However you are right.


> I'd also add that anyone with a Fedora account can run scratch builds on our
> Koji buildsystem if they want to.  This explains how it's done:
> https://fedoraproject.org/wiki/
> Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.
> 29_and_set_up_your_certificate

I'd love it, but I hit bug #977632 when using fedora-packager-setup and another one when using https://koji.fedoraproject.org/koji/login, so I will use other method for now. Thanks, however.


> Please use English in spec comments.  (Just to be clear, this doesn't extend
> to the Spanish summary/description, which is done correctly. :-)

Ooops, that comment was deprecated however, since that bug was fixed.


> The README file indicates this is under the LGPLv2.  The original Kate
> sources are under LGPLv2+, however.  Please clarify this with upstream and
> correct the License field in your spec file.

Fixed. However Katepart is under LGPLv2:
https://projects.kde.org/projects/kde/applications/kate/repository/revisions/master/entry/part/README


> Grammar nit:
> "contains port" -> "contains a port"
> 
> You can remove the stuff in parenthesis.

Fixed all those.


> > %build
> > %{__python} setup.py build
> 
> This package contains binary Python extensions, so the distribution compiler
> flags need to be used.  For more information, see:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags
> 
> For Python packages, that ends up being something like:
> 
> CFLAGS="%{buildroot}" %{__python} setup.py build

Sorry for that. For what I readed, I think you meant CFLAGS="%{optflags}", and that's what I put. Correct me if I'm wrong.

Thank you very much. Here are the results:

Spec URL: https://doc-00-44-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/nd26e0pul92ha033si1t9q7mg31jip15/1382731200000/12408635912512098830/*/0B6L4jqW88ytdaDlxNUd2SVFYVjA?h=16653014193614665626&e=download

SRPM URL: http://download.opensuse.org/repositories/home:/yajo:/enki/Fedora_19/src/python-qutepart-1.1.0-2.1.src.rpm
Comment 4 T.C. Hollingsworth 2013-10-27 19:23:49 EDT
(In reply to Yajo from comment #3)
> Thanks. Fixed. RPM autorequires are like black magic to me. Definitely I
> need a sponsor.

They're not as complicated as they seem.  :-)

Every shared library on Unix-like operating systems contains a soname.  There are a couple of ways you can see this soname:

% readelf -a /usr/lib64/libogg.so.0.8.0 | grep SONAME 
 0x000000000000000e (SONAME)             Library soname: [libogg.so.0]

% objdump -p /usr/lib64/libogg.so.0.8.0 | grep SONAME 
  SONAME               libogg.so.0

Also, it's common practice for there to exist a symlink from the soname to the actual library file:

% ls -l /usr/lib64/libogg.so.0
lrwxrwxrwx. 1 root root 15 Apr 11  2013 /usr/lib64/libogg.so.0 -> libogg.so.0.8.0

Any program can link to a shared library under a particular soname and expect to continue to work as long as the library continues to provide that soname.  (Of course, bumping soname is a manual process, so it's possible for a library to break binary compatibility without bumping its soname, but that's considered very bad behavior.)

You can see what libraries a program is linked to with the `ldd` command:

% ldd /usr/bin/ogginfo 
        linux-vdso.so.1 =>  (0x00007fff2fb95000)
        libvorbis.so.0 => /lib64/libvorbis.so.0 (0x000000399b200000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003984e00000)
        libogg.so.0 => /lib64/libogg.so.0 (0x000000399b600000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003984a00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003984600000)

RPM runs something like `objdump` to get the soname a library uses and adds automatic Provides to the library package.  It also runs something like `ldd` on programs to figure out what libraries they use and adds automatic Requires to those packages, to eliminate the need for you to manually add those Requires on your own.

This also isn't limited to binary libraries.  Perl has its own magic, as do many other languages.

Anyway, RPM prior to the version included with Fedora 20 is dumb, and includes Provides even for shared object files that exist outside the standard linker path.  Python libraries are dlopen()ed by the Python interpreter, not linked, so their sonames have no meaning.  It's thus necessary to remove them.

You can do this by excluding all automatic provides found within a certain directory, as you did in your spec file, or by name, or with other less widely used mechanisms.  The page I linked to it goes into this in excessive detail, but it's not something you have to worry about very often, especially now that RPM is getting smarter about them.

> I'd love it, but I hit bug #977632 when using fedora-packager-setup and
> another one when using https://koji.fedoraproject.org/koji/login, so I will
> use other method for now. Thanks, however.

Looking at the `fedora-packager-setup` bug, it seems to be python-fedora's funny way of telling you that you entered your password wrong.  You really do need to get this working, otherwise you won't be able to push a real build when the time comes.  ;-)

If you continue to have trouble, you can contact Fedora Infrastructure for help either by e-mailing admin@fedoraproject.org or in #fedora-admin on IRC.

Please do get that working and link to a scratch build when you've got it figured out.

Logging into the koji web interface is known to be broken, but it's a low priority because pretty much the only thing you can do with it is cancel builds (you can't start them), and you can do that with the `koji cancel-task` command anyway, so nobody really cares.  :-/  Don't worry about it.
 
> Fixed. However Katepart is under LGPLv2:
> https://projects.kde.org/projects/kde/applications/kate/repository/revisions/
> master/entry/part/README

Ah, right you are.  Sorry for the confusion there.
 
> Sorry for that. For what I readed, I think you meant CFLAGS="%{optflags}",
> and that's what I put. Correct me if I'm wrong.

Yup.
 
> Thank you very much. Here are the results:
<snip>

Looking better now.  I'll proceed with the formal review shortly.

In the meantime, see if you can get going with koji.  Also, try giving a few other packages an informal review:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_packages

Package reviews are an important responsibility among maintainers, and we like to see some evidence that new packagers are capable of doing them.  ;-)
Comment 5 Yajo 2014-07-07 12:40:18 EDT
(In reply to T.C. Hollingsworth from comment #4)

First of all, and again, sorry for the delay, and thanks a *lot* about that sonames info.


> Looking at the `fedora-packager-setup` bug, it seems to be python-fedora's
> funny way of telling you that you entered your password wrong.  You really
> do need to get this working, otherwise you won't be able to push a real
> build when the time comes.  ;-)

Done! You were right, it was the password.


> Please do get that working and link to a scratch build when you've got it
> figured out.

Here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7113145

New SRPM: http://download.opensuse.org/repositories/home:/yajo:/enki/Fedora_20/src/python-qutepart-1.3.0-4.1.src.rpm

New SPEC (finally I got the raw link): https://build.opensuse.org/source/home:yajo:enki/python-qutepart/python-qutepart.spec?rev=810dacc2f3d56bd9a5862712d80efecb

> In the meantime, see if you can get going with koji.  Also, try giving a few
> other packages an informal review:
> https://fedoraproject.org/wiki/
> How_to_get_sponsored_into_the_packager_group#Reviewing_packages
> 
> Package reviews are an important responsibility among maintainers, and we
> like to see some evidence that new packagers are capable of doing them.  ;-)

As you can guess, I have very little free time, but I understand the importance, and I will do what I can.

Thanks a lot again!
Comment 6 Yajo 2014-08-10 04:52:11 EDT
(In reply to T.C. Hollingsworth from comment #4)
> In the meantime, see if you can get going with koji.  Also, try giving a few
> other packages an informal review:
> https://fedoraproject.org/wiki/
> How_to_get_sponsored_into_the_packager_group#Reviewing_packages
> 
> Package reviews are an important responsibility among maintainers, and we
> like to see some evidence that new packagers are capable of doing them.  ;-)

One review here: https://bugzilla.redhat.com/show_bug.cgi?id=1077301#c4
Comment 7 Fedora End Of Life 2015-01-09 17:19:47 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 9 Raphael Groner 2015-04-04 16:17:51 EDT
This is a short informal review of your spec file with all my comments as SHOULD only.

* Please use consistently the provided macros, also for the upstream project name. You can use the %{url} macro to shorten additional links.
> URL:            https://github.com/hlamer/qutepart
> Source0:        https://github.com/hlamer/qutepart/archive/v%{version}.tar.gz#/qutepart-%{version}.tar.gz> %prep
> %setup0 -q -n qutepart-%{version}
%global project qutepart
…
URL:            https://github.com/hlamer/%{project}
Source0:        %{url}/archive/v%{version}.tar.gz#/%{project}-%{version}.tar.gz
…
%prep
%setup0 -qn%{project}-%{version}

* As this package is related to python2, you should use also the respective macros to avoid any confusion. Python2 is still the default but will change in near future to Python3. What about use python3 today? If yes, please adjust BuildRequires, too.
https://fedoraproject.org/wiki/Packaging:Python#Macros
https://fedoraproject.org/wiki/Packaging:Python#Bytecompiling_with_the_correct_python_version
https://fedoraproject.org/wiki/Packaging:Python#BuildRequires
> %build
> CFLAGS="%{optflags}" %{__python} setup.py build
>
> %install
> %{__python} setup.py install --skip-build --root %{buildroot}
>
> %files
> %doc LICENSE README.md
> %{python_sitearch}/qutepart*
%build
CFLAGS="%{optflags}" %{__python2} setup.py build

%install
%{__python2} setup.py install --skip-build --root %{buildroot}

%files
%license LICENSE
%doc README.md
%{python2_sitearch}/%{project}*

* Please use the %license macro for the license text, see my correction above.
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

* Do you plan packages for EPEL or Fedora 20? If yes, that usage of %license macro will be problematic and needs some tweaking. Please let me know if you need further help.

I'll update the respective bug fields to keep this open as a review request, see comment #7.
Comment 10 Raphael Groner 2015-04-27 14:12:11 EDT
Any news here?
Comment 11 Yajo 2015-04-30 10:46:25 EDT
(In reply to Raphael Groner from comment #9)
> * Please use consistently the provided macros, also for the upstream project
> name. You can use the %{url} macro to shorten additional links.
> %global project qutepart
> …

Done.


> * As this package is related to python2, you should use also the respective
> macros to avoid any confusion. Python2 is still the default but will change
> in near future to Python3. What about use python3 today? If yes, please
> adjust BuildRequires, too.

Done.


> %license LICENSE
> * Please use the %license macro for the license text, see my correction
> above.
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
> 
> * Do you plan packages for EPEL or Fedora 20? If yes, that usage of %license
> macro will be problematic and needs some tweaking. Please let me know if you
> need further help.

AFAIK it only applies when upstream does not provide a LICENSE file. This is not the case.

BTW, the docs are contradictory. https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text says:

  "These prefixes are not valid in Fedora: %license and %readme."


> * Do you plan packages for EPEL or Fedora 20? If yes, that usage of %license macro will be problematic and needs some tweaking. Please let me know if you need further help.

I'm not planning those packages, but if somebody asks for it, I could try for EPEL. F20 is too close to death.

> I'll update the respective bug fields to keep this open as a review request, see comment #7.

Thank you very much.

SPEC URL: https://build.opensuse.org/source/home:yajo:enki/python-qutepart/python-qutepart.spec?rev=c390ab9e845d91b99b1d74e76ac3fbf7

SRPM URL: http://download.opensuse.org/repositories/home:/yajo:/enki/RHEL_7/src/python-qutepart-2.2.0-6.1.src.rpm

That one is for RHEL, but I think the SRPM will be the same. If not, I can put the URL to the Fedora one once OBS finises the job.
Comment 12 Raphael Groner 2015-04-30 14:19:57 EDT
The %license line is required for any new spec file. If there's no license text, request one from upstream or suggest a standard text for the license upstream is claiming.

Would you mind to rename the package to just "qutepart" and remove the python prefix from name? If so, you can get rid of the project macro and please use %{name} consistently, also for the %files section.

Really do not know why python is needed in the name cause the package installs a standalone application, not a library or the like. Are you planning to do a parallel python3 build where applicable (currently not possible for EPEL)?
https://fedoraproject.org/wiki/Packaging:Python#Avoiding_collisions_between_the_python_2_and_python_3_stacks

Original reviewer: Would you continue the official review or should I take over to finish with the official fedora-review run?
Comment 13 Raphael Groner 2015-05-01 05:14:20 EDT
Hmm. We have the problem that I can not sponsor you. This review can not continue without a sponsor. :(

Bug #177841 (FE-NEEDSPONSOR) says:
 Warren Togami 2006-05-04 15:42:33 CEST
People should not sit in NEED-SPONSOR status and just expect sponsorship.  The
best way to get sponsorship is to continue doing other work, like reviewing
other packages, giving helpful advice, or submitting more packages for review. 
Having approved packages is *NOT* the requirement for gaining cvsextras
sponsorship.  Instead demonstrating that you understand the packaging guidelines
and Fedora process to sponsor members is what is necessary to gain sponsorship.
Comment 14 Michael Schwendt 2015-05-01 05:22:13 EDT
bug 984560 buildrequires and requires bug 1015868 - that's the dependency!
Comment 15 Yajo 2015-05-02 07:45:47 EDT
(In reply to Raphael Groner from comment #12)
> The %license line is required for any new spec file.

OK, I'll do it but then please fix the docs. The contraiction I said in comment 11 is in https://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25files_prefixes


> If there's no license
> text, request one from upstream or suggest a standard text for the license
> upstream is claiming.
> 
> Would you mind to rename the package to just "qutepart" and remove the
> python prefix from name? If so, you can get rid of the project macro and
> please use %{name} consistently, also for the %files section.
> 
> Really do not know why python is needed in the name cause the package
> installs a standalone application, not a library or the like.

Sorry but did you actually review my package? It has an upstream LICENSE file and it IS a library, so the naming is correct according to https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29


> Are you
> planning to do a parallel python3 build where applicable (currently not
> possible for EPEL)?
> https://fedoraproject.org/wiki/Packaging:
> Python#Avoiding_collisions_between_the_python_2_and_python_3_stacks

Right now upstream only supports python 2.7.
https://github.com/hlamer/qutepart#building-and-installation-on-linux


(In reply to Raphael Groner from comment #13)
> Hmm. We have the problem that I can not sponsor you. This review can not
> continue without a sponsor. :(
> 
> Bug #177841 (FE-NEEDSPONSOR) says:
>  Warren Togami 2006-05-04 15:42:33 CEST
> People should not sit in NEED-SPONSOR status and just expect sponsorship. 
> The
> best way to get sponsorship is to continue doing other work, like reviewing
> other packages, giving helpful advice, or submitting more packages for
> review. 
> Having approved packages is *NOT* the requirement for gaining cvsextras
> sponsorship.  Instead demonstrating that you understand the packaging
> guidelines
> and Fedora process to sponsor members is what is necessary to gain
> sponsorship.

I understand that. See comment 6.

I have not much time from my daily job to review lots of packages. If an official packager wants to take this work and close these bugs by himself it's OK for me. It would be a bit frustrating not to become a packager, as I usually make packages for fedora that I'd like to share with others, but I prefer to actually see enki in the repos that to wait endlessly to have a packager badge in my sleeve.

(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #14)
> bug 984560 buildrequires and requires bug 1015868 - that's the dependency!

Indeed.
Comment 16 Raphael Groner 2015-05-02 08:29:06 EDT
Assigning back to the original review offer. Sorry, I did not want to offend anyone but help as far as I can.
Comment 17 Yajo 2015-05-04 03:18:14 EDT
(In reply to Raphael Groner from comment #16)
> Assigning back to the original review offer. Sorry, I did not want to offend
> anyone but help as far as I can.

Neither did I, I apologize for my tone back there. Thank you a lot for your help and interest :)
Comment 18 Yajo 2015-05-04 03:39:35 EDT
(In reply to Yajo from comment #15)
> (In reply to Raphael Groner from comment #12)
> > The %license line is required for any new spec file.
> 
> OK, I'll do it

Done now.

SPEC URL: https://build.opensuse.org/source/home:yajo:enki/python-qutepart/python-qutepart.spec?rev=78ed128a68ca953978631d377cd4e41e

SRPM URL: https://build.opensuse.org/package/binary/home:yajo:enki/python-qutepart?arch=i586&filename=python-qutepart-2.2.0-7.1.src.rpm&repository=Fedora_21
Comment 19 Raphael Groner 2015-05-06 06:44:15 EDT
Sorry, I missed the word "component" in the summary and commented wrongly. The python prefix seems to be right in the name.
Comment 20 Yajo 2015-05-06 07:45:34 EDT
(In reply to Raphael Groner from comment #19)
> Sorry, I missed the word "component" in the summary and commented wrongly.
> The python prefix seems to be right in the name.

It's the component that uses the Enki editor. The main goal is to package Enki for Fedora, but of course this must be done first.

I'll update the Enki bug ASAP too, it got updated recently.

Also, I'll try to take more seriously the task of reviewing others' jobs. I'll report here.

I sincerely thank your efforts.
Comment 21 Raphael Groner 2015-05-07 06:06:13 EDT
(In reply to Yajo from comment #20)
…
> It's the component that uses the Enki editor. The main goal is to package
> Enki for Fedora, but of course this must be done first.

We would appreciate a package for Enki. It looks very interesting to become the default text editor in the LXQt spin. Maybe you would like to join the LXQt SIG? Look into the wiki for more information.
https://fedoraproject.org/wiki/LXQt_SIG
(→ Suggested Applications)

> I'll update the Enki bug ASAP too, it got updated recently.
> 
> Also, I'll try to take more seriously the task of reviewing others' jobs.
> I'll report here.
> 
> I sincerely thank your efforts.

No problem. We all fall over bugs and do sometimes weird mistakes. :-)
Comment 22 Yajo 2015-05-07 12:03:22 EDT
(In reply to Raphael Groner from comment #21)
> We would appreciate a package for Enki. It looks very interesting to become
> the default text editor in the LXQt spin.

Nice to know. I've used it for awhile and it's a pretty good editor.


> Maybe you would like to join the
> LXQt SIG? Look into the wiki for more information.
> https://fedoraproject.org/wiki/LXQt_SIG
> (→ Suggested Applications)

Well, as I said before, I'm struggling to get time to do reviews. It's an interesting project but does not seem feasible for me right now.

Anyway I'll try to help in all I can, thanks for the invitation!


> No problem. We all fall over bugs and do sometimes weird mistakes. :-)

Thanks!

BTW, I published wrong URL:

SPEC URL: https://build.opensuse.org/source/home:yajo:enki/python-qutepart/python-qutepart.spec?rev=78ed128a68ca953978631d377cd4e41e

SRPM URL: http://download.opensuse.org/repositories/home:/yajo:/enki/Fedora_21/src/python-qutepart-2.2.0-7.1.src.rpm
Comment 23 Raphael Groner 2015-05-31 14:32:02 EDT
Is it possible to get it done with PyQt5 (package name for dependency: python-qt5) ?
Comment 24 Yajo 2015-06-02 03:14:23 EDT
Seems not possible for now, see upstream https://github.com/hlamer/qutepart/issues/21.
Comment 25 Raphael Groner 2015-06-28 11:20:34 EDT
Are you interested in a review swap?
Maybe bug #1225231 is for you.
Comment 26 Yajo 2015-06-29 03:11:41 EDT
OK thanks ;)
Comment 27 Yajo 2015-07-02 12:56:42 EDT
Informal review here: https://bugzilla.redhat.com/show_bug.cgi?id=1225231#c3
Comment 28 Raphael Groner 2015-07-21 12:11:31 EDT
Assigned reviewer seems to got lost. Should I take over?
Comment 29 Raphael Groner 2015-07-21 16:34:29 EDT
Package Review
==============

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


Issues:
=======
- Permissions on files are set properly.
  Note: See rpmlint output
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions
- In Fedora we have multiple python runtimes, one for each supported major
  release. At this point that's one for python2.x and one for python3.x.
  If a piece of software supports python3, it must be packaged for python3.
  If it supports python2 as well, it may be packaged for python2. If it
  supports only python2 then it must not be packaged for python3. 

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

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[!]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

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]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated". 72 files have unknown license. Detailed
     output of licensecheck in /home/builder/fedora-review/1015868-python-
     qutepart/licensecheck.txt
=> Okay, LICENSE file states LPGLv2+.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 files.
[?]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[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 %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[-]: 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
=> Please consider to build for Python3.
[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

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

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[?]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[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.
=> Maybe consider to execute the provided tests in subfolder.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[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)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

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

Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see
     attached diff).
     See: (this test has no URL)
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.


Rpmlint
-------
Checking: python-qutepart-2.2.0-7.1.x86_64.rpm
          python-qutepart-2.2.0-7.1.src.rpm
python-qutepart.x86_64: I: enchant-dictionary-not-found es
=> Ignore. https://fedorahosted.org/autoqa/ticket/239
python-qutepart.x86_64: W: incoherent-version-in-changelog 2.2.0-6 ['2.2.0-7.1', '2.2.0-7.1']
=> Please fix.
python-qutepart.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so 775
=> Please fix.
2 packages and 0 specfiles checked; 1 errors, 1 warnings.




Rpmlint (debuginfo)
-------------------
Checking: python-qutepart-debuginfo-2.2.0-7.1.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
python-qutepart.x86_64: W: incoherent-version-in-changelog 2.2.0-6 ['2.2.0-7.1', '2.2.0-7.1']
python-qutepart.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so 775
2 packages and 0 specfiles checked; 1 errors, 1 warnings.



Diff spec file in url and in SRPM
---------------------------------
--- /home/builder/fedora-review/1015868-python-qutepart/srpm/python-qutepart.spec	2015-07-21 22:10:35.504679649 +0200
+++ /home/builder/fedora-review/1015868-python-qutepart/srpm-unpacked/python-qutepart.spec	2015-05-04 09:36:23.000000000 +0200
@@ -3,5 +3,5 @@
 Name:           python-%{project}
 Version:        2.2.0
-Release:        6%{?dist}
+Release:        7.1
 Summary:        Code editor widget for PyQt
 Summary(es):    Componente de edición de código fuente para PyQt
@@ -91,3 +91,3 @@
 
 * Sun Sep 8 2013 Jairo Llopis <yajo.sk8@gmail.com>  1.1.0-1
-- Initial release.
\ Kein Zeilenumbruch am Dateiende.
+- Initial release.


Requires
--------
python-qutepart (rpmlib, GLIBC filtered):
    PyQt4
    libc.so.6()(64bit)
    libpcre.so.1()(64bit)
    libpthread.so.0()(64bit)
    libpython2.7.so.1.0()(64bit)
    pcre
    python(abi)
    python2
    rtld(GNU_HASH)



Provides
--------
python-qutepart:
    python-qutepart
    python-qutepart(x86-64)



Unversioned so-files
--------------------
python-qutepart: /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so

Source checksums
----------------
https://github.com/hlamer/qutepart/archive/v2.2.0.tar.gz#/qutepart-2.2.0.tar.gz :
  CHECKSUM(SHA256) this package     : ac2c6dbf67f71104901260ff81a73278ac3375ebe11f3824bbe89f02fbfe562a
  CHECKSUM(SHA256) upstream package : ac2c6dbf67f71104901260ff81a73278ac3375ebe11f3824bbe89f02fbfe562a


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -v -m fedora-rawhide-x86_64 -b 1015868
Buildroot used: fedora-rawhide-x86_64
Active plugins: Python, Generic, Shell-api, C/C++
Disabled plugins: Java, SugarActivity, fonts, Haskell, Ocaml, Perl, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
Comment 30 Yajo 2015-07-23 10:35:06 EDT
(In reply to Raphael Groner from comment #28)
> Assigned reviewer seems to got lost. Should I take over?

Please.


(In reply to Raphael Groner from comment #29)

> [!]: Spec file according to URL is the same as in SRPM.
>      Note: Spec file as given by url is not the same as in SRPM (see
>      attached diff).
>      See: (this test has no URL)

This must be OBS' fault. It tends to give their own versions. I tried koji, but no way to link to SPEC from there. Any other choice?


I'll continue ASAP with the rest of issues, please be patient. Thanks!
Comment 31 Raphael Groner 2015-07-23 10:54:41 EDT
(In reply to Yajo from comment #30)
…
> This must be OBS' fault. It tends to give their own versions. I tried koji,
> but no way to link to SPEC from there. Any other choice?

You can ask for user space at fedorapeople.org as we packagers use it commonly. I guess that is possibly only with a valid sponsorship.
https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org
Comment 32 Michael Schwendt 2015-08-18 08:54:53 EDT
> I guess that is possibly only with a valid sponsorship.

No, not required.

There is the option to file a "Initial package hosting request":
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Upload_Your_Package

| If you have not done anything with your account besides set it up
| and sign the CLA then you can request sufficient access to use
| fedorapeople space by visiting the sponsors trac instance and
| filing a ticket in the "Initial package hosting request" component. 

The page you've linked mentions it, too:
https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org
Comment 33 Yajo 2015-08-26 02:41:27 EDT
Can I link to a spec from copr?
Comment 34 Yajo 2015-08-26 03:32:06 EDT
(In reply to Raphael Groner from comment #29)
> ===== MUST items =====
> 
> C/C++:
> [!]: Development (unversioned) .so files in -devel subpackage, if present.
>      Note: Unversioned so-files in private %_libdir subdirectory (see
>      attachment). Verify they are not in ld path.

How to do this?

> Generic:
> Python:
> [!]: Package meets the Packaging Guidelines::Python
> => Please consider to build for Python3.

Seems not possible: https://github.com/hlamer/qutepart#building-and-installation-on-linux

> ===== SHOULD items =====
> 
> Generic:
> [?]: Package functions as described.

It does.

> [?]: Latest version is packaged.

I'll update ASAP to 2.2.2.

> [!]: %check is present and all tests pass.
> => Maybe consider to execute the provided tests in subfolder.

I added these lines:

%check
%{__python2} tests/run_all.py

Now, when building, I get this:

Ejecutando(%check): /bin/sh -e /var/tmp/rpm-tmp.WGauMV
+ umask 022
+ cd /home/yajo/rpmbuild/BUILD
+ cd qutepart-2.2.0
+ /usr/bin/python2 tests/run_all.py
run_all.py: cannot connect to X server 

Seems like I need an X server for testing. How to do that? For now, I removed %check.

> Rpmlint
> -------
> python-qutepart.x86_64: I: enchant-dictionary-not-found es
> => Ignore. https://fedorahosted.org/autoqa/ticket/239

I removed the Spanish translation. I guess it will be easier to maintain and understand for others.

> python-qutepart.x86_64: W: incoherent-version-in-changelog 2.2.0-6
> ['2.2.0-7.1', '2.2.0-7.1']

See comment #30.

> => Please fix.
> python-qutepart.x86_64: E: non-standard-executable-perm
> /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so 775
> => Please fix.

Fixed

> Diff spec file in url and in SRPM
> ---------------------------------
> [...]

Also see comment #30.

SPEC URL: https://doc-14-44-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/qc6jbhsdf33ma0e29lrdv0blr4i1e19m/1440568800000/12408635912512098830/*/0B6L4jqW88ytdWDZKanBRa0FEbEk?e=download

SRPM URL: https://doc-0s-44-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/abmvj2ng3qfbs27qet3p6rphcie4c1s3/1440568800000/12408635912512098830/*/0B6L4jqW88ytdMjhpWm5LMjQ2aGs?e=download
Comment 35 Jens Lody 2015-08-26 03:43:55 EDT
(In reply to Yajo from comment #33)
> Can I link to a spec from copr?

In recent copr you can click on Builds, then chose a build by clicking on the build id, then chose the appropriate dist git source, click on the tree-link, then chose the spec-file and use the link for plain view.
Comment 36 Yajo 2015-08-27 03:10:20 EDT
Oh sorry, seems like the link is down. I'll try with copr since it seems more easy.
Comment 39 Raphael Groner 2015-08-28 08:31:37 EDT
It's worth a try to make the tests work with success, so we could ensure some QA already in the build phase. Maybe take a look into my trojita.spec file [1] as a template how X could be faked in koji run with help from xvfb-run or call directly Xvfb. Another option is to patch the python test files to use python-xvfbwrapper [2] somehow to avoid the preassumption to have a running X, it would be cool if you poke upstream therefore. Please let me know if you need further help.
[1] http://pkgs.fedoraproject.org/cgit/trojita.git/tree/trojita.spec#n114
[2] https://github.com/cgoldberg/xvfbwrapper


> ===== MUST items =====
> 
> C/C++:
> [!]: Development (unversioned) .so files in -devel subpackage, if present.
>      Note: Unversioned so-files in private %_libdir subdirectory (see
>      attachment). Verify they are not in ld path.

> Unversioned so-files
> --------------------
> python-qutepart: /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so

This is CPython, fedora-review gets obviously confused and there's no -devel subpackage. We can ignore it.
Comment 40 Raphael Groner 2015-08-28 10:42:03 EDT
Package Review
==============

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


Issues:
=======
- Permissions on files are set properly.
  Note: See rpmlint output
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions
=> find %{buildroot}%{python2_sitearch} -name \*.so |xargs chmod 0644
- You can use %py2_build and %py2_install macros to apply all default flags and options
- Please consider to use the new and magic %python_provide macro.
https://fedoraproject.org/wiki/Packaging:Python#The_.25python_provide_macro


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

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
=> Ignore. CPython import bug.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

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]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated". 72 files have unknown license. Detailed
     output of licensecheck in /home/builder/fedora-review/1015868-python-
     qutepart/licensecheck.txt
=> Okay, LICENSE file states LPGLv2+.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
=> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10869494
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[!]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[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 %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Python eggs must not download any dependencies during the build
     process.
[x]: A package which is used by another package via an egg interface should
     provide egg info.
[!]: Package meets the Packaging Guidelines::Python
=> see Issues above.
[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

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

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
=> Trusting requester's answer. Please consider to execute upstream tests.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: 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.
=> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10869494
[!]: %check is present and all tests pass.
=> Please execute upstream tests, see above.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[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)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

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

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


Rpmlint
-------
Checking: python-qutepart-2.2.2-1.fc24.x86_64.rpm
          python-qutepart-2.2.2-1.fc24.src.rpm
python-qutepart.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so 775
=> Please fix. See above in Issues for a possible command added to %install.
2 packages and 0 specfiles checked; 1 errors, 0 warnings.




Rpmlint (debuginfo)
-------------------
Checking: python-qutepart-debuginfo-2.2.2-1.fc24.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
python-qutepart.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so 775
=> See above.
2 packages and 0 specfiles checked; 1 errors, 0 warnings.



Requires
--------
python-qutepart (rpmlib, GLIBC filtered):
    PyQt4
    libc.so.6()(64bit)
    libpcre.so.1()(64bit)
    libpthread.so.0()(64bit)
    libpython2.7.so.1.0()(64bit)
    pcre
    python(abi)
    python2
    rtld(GNU_HASH)



Provides
--------
python-qutepart:
    python-qutepart
    python-qutepart(x86-64)



Unversioned so-files
--------------------
python-qutepart: /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so

Source checksums
----------------
https://github.com/hlamer/qutepart/archive/v2.2.2.tar.gz#/qutepart-2.2.2.tar.gz :
  CHECKSUM(SHA256) this package     : e7b9c7096746a52cd3e6fdbe612b1e2c041d51e6946bd293cd3ac998d28461a6
  CHECKSUM(SHA256) upstream package : e7b9c7096746a52cd3e6fdbe612b1e2c041d51e6946bd293cd3ac998d28461a6


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -v -m fedora-rawhide-x86_64 -b 1015868
Buildroot used: fedora-rawhide-x86_64
Active plugins: Python, Generic, Shell-api, C/C++
Disabled plugins: Java, SugarActivity, fonts, Haskell, Ocaml, Perl, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
Comment 41 Raphael Groner 2015-09-17 10:58:21 EDT
Ping Yajo, are you still interested in this?

Enki could be very useful for LXQt, so I can take these both packages python-qutepart and Enki, if you run out of time.
Comment 42 Yajo 2015-09-18 05:20:41 EDT
(In reply to Raphael Groner from comment #41)
> Enki could be very useful for LXQt, so I can take these both packages
> python-qutepart and Enki, if you run out of time.

It's very sad because I'd love to become Fedora packager and maintain this, but I have no time for it.

Please take the package if you can. It's the best for everyone.

Thanks for your help! :)
Comment 43 Raphael Groner 2015-09-18 06:47:40 EDT
Yajo, you should do some package reviews or become a co-maintainer for any package. Both are the usual ways to get sponsored.
Comment 44 Yajo 2015-09-18 06:49:49 EDT
I'd like to co-maintain this one & enki when done.
Comment 45 Julien Enselme 2015-10-17 11:22:03 EDT
As Raphael requested, I am taking over the review so he can own the package once approved.

The package is almost good. I only see what Raphael pointed out in comment 40 to be corrected.


Issues
- Please use the new %py2_build macro to use the proper compiler flags.
- Please launch tests with the run_all.py script.
- Please fix permissions on installed so files.
- This package should also provide python2-qutepart. Please use %{?python_provide:%python_provide python2-%{pypi_name}} to achieve that.
- Please use the new %py2_build and %py2_install macros. You must also put the python2 version in a python2 subpackage. See: https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file


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

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


Issues:
=======
- Package installs properly.
  Note: Installation errors (see attachment)
  See: https://fedoraproject.org/wiki/Packaging:Guidelines
- Permissions on files are set properly.
  Note: See rpmlint output
  See: http://fedoraproject.org/wiki/Packaging/Guidelines#FilePermissions


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

C/C++:
[X]: Package does not contain kernel modules.
[X]: Package contains no static executables.
[-]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

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]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "LGPL (v2)", "LGPL (v2 or later)", "GPL (v2 or later)",
     "Unknown or generated", "MIT/X11 (BSD like)", "LGPL (v3 or later)",
     "BSD (3 clause)", "LGPL (v2.1 or later)". 383 files have unknown
     license. Detailed output of licensecheck in /tmp/1015868-python-
     qutepart/licensecheck.txt
[X]: License file installed when any subpackage combination is installed.
[!]: %build honors applicable compiler flags or justifies otherwise.
Please use the new %py2_build macro to use the proper compiler flags.

[X]: Package contains no bundled libraries without FPC exception.
[X]: Changelog in prescribed format.
[X]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[X]: Package uses nothing in %doc for runtime.
[X]: Package consistently uses macros (instead of hard-coded directory
     names).
[X]: Package is named according to the Package Naming Guidelines.
[X]: Package does not generate any conflict.
[X]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[X]: Requires correct, justified where necessary.
[X]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[-]: Useful -debuginfo package or justification otherwise.
[X]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 files.
[X]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[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 %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[X]: Python eggs must not download any dependencies during the build
     process.
[X]: A package which is used by another package via an egg interface should
     provide egg info.
[!]: Package meets the Packaging Guidelines::Python
Please use the new %py2_build and %py2_install macros. You must also put the python2 version in a python2 subpackage. See: https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file

[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

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

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[!]: Final provides and requires are sane (see attachments).
This package should also provide python2-qutepart. Please use %{?python_provide:%python_provide python2-%{pypi_name}} to achieve that.

[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in python-
     qutepart-debuginfo
[?]: Package functions as described.
[X]: Latest version is packaged.
[X]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: Package should compile and build into binary rpms on all supported
     architectures.
[!]: %check is present and all tests pass.
Please launch tests with the run_all.py script

[X]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[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)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

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

Generic:
[!]: Rpmlint is run on all installed packages.
     Note: Mock build failed
     See: http://fedoraproject.org/wiki/Packaging/Guidelines#rpmlint
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Installation errors
-------------------
INFO: mock.py version 1.2.13 starting (python version = 3.4.3)...
Start: init plugins
INFO: selinux enabled
Finish: init plugins
Start: run
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled dnf cache
Start: cleaning dnf metadata
Finish: cleaning dnf metadata
INFO: enabled ccache
Mock Version: 1.2.13
INFO: Mock Version: 1.2.13
Finish: chroot init
INFO: installing package(s): /tmp/1015868-python-qutepart/results/python-qutepart-2.2.2-1.fc24.x86_64.rpm /tmp/1015868-python-qutepart/results/python-qutepart-debuginfo-2.2.2-1.fc24.x86_64.rpm /tmp/1015868-python-qutepart/results/python-qutepart-debuginfo-2.2.2-1.fc24.x86_64.rpm
ERROR: Command failed. See logs for output.
 # /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 24 install /tmp/1015868-python-qutepart/results/python-qutepart-2.2.2-1.fc24.x86_64.rpm /tmp/1015868-python-qutepart/results/python-qutepart-debuginfo-2.2.2-1.fc24.x86_64.rpm /tmp/1015868-python-qutepart/results/python-qutepart-debuginfo-2.2.2-1.fc24.x86_64.rpm --setopt=tsflags=nocontexts


Rpmlint
-------
Checking: python-qutepart-2.2.2-1.fc24.x86_64.rpm
          python-qutepart-debuginfo-2.2.2-1.fc24.x86_64.rpm
          python-qutepart-2.2.2-1.fc24.src.rpm
python-qutepart.x86_64: E: non-standard-executable-perm /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so 775
3 packages and 0 specfiles checked; 1 errors, 0 warnings.




Requires
--------
python-qutepart (rpmlib, GLIBC filtered):
    PyQt4
    libc.so.6()(64bit)
    libpcre.so.1()(64bit)
    libpthread.so.0()(64bit)
    libpython2.7.so.1.0()(64bit)
    pcre
    python(abi)
    python2
    rtld(GNU_HASH)

python-qutepart-debuginfo (rpmlib, GLIBC filtered):



Provides
--------
python-qutepart:
    python-qutepart
    python-qutepart(x86-64)

python-qutepart-debuginfo:
    python-qutepart-debuginfo
    python-qutepart-debuginfo(x86-64)



Unversioned so-files
--------------------
python-qutepart: /usr/lib64/python2.7/site-packages/qutepart/syntax/cParser.so

Source checksums
----------------
https://github.com/hlamer/qutepart/archive/v2.2.2.tar.gz#/qutepart-2.2.2.tar.gz :
  CHECKSUM(SHA256) this package     : e7b9c7096746a52cd3e6fdbe612b1e2c041d51e6946bd293cd3ac998d28461a6
  CHECKSUM(SHA256) upstream package : e7b9c7096746a52cd3e6fdbe612b1e2c041d51e6946bd293cd3ac998d28461a6


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -m fedora-rawhide-x86_64 -b 1015868
Buildroot used: fedora-rawhide-x86_64
Active plugins: Python, Generic, Shell-api, C/C++
Disabled plugins: Java, SugarActivity, fonts, Haskell, Ocaml, Perl, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
Comment 46 Raphael Groner 2015-10-19 15:34:40 EDT
Upstream does not support yet python3, I've filed an issue.

Can we continue here with the review or should I open a new request and close this bug as duplicate?
Comment 47 Julien Enselme 2015-10-20 02:42:40 EDT
> Upstream does not support yet python3, I've filed an issue.

OK, not blocking anyway.

> Can we continue here with the review or should I open a new request and close this bug as duplicate?

Maybe you can open a new request to make the new review clearer.
Comment 48 Raphael Groner 2015-10-20 14:46:47 EDT
Review continues in new bug #1273601.

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

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