The spec file differ from the one in SRPM.

Hi Aivar,

Welcome to Fedora!

As Sergey says, the copy of the spec here and the one in the SRPM differ. In general this is a bad idea, even though here the differences are minor/cosmetic:

$ diff thonny.spec thonny/thonny.spec 
11d10
< 
15d13
< 
31d28
< # In order to get rid of rpmlint warning

I took a quick look at the spec; it generally looks pretty reasonable. I have a few initial comments:

Source0:        https://pypi.python.org/packages/01/ad/b9ce07063b9d6b9c5f3835b0256775feacd75de44d86f813924ee96d3f16/thonny-2.1.12.tar.gz

You can replace the "2.1.12" here by the "%{version}" macro; this way whenever you bump the version of the package the Source URL will automatically be updated, too. (It's easy to forget otherwise to change the version in the URL).

Also, if possible, it's better to use the "files.pythonhosted.org" URLs for PyPI, as they lack the magic hashes and are generally simpler. e.g. something like the following, where %pypi_name is "thonny":

Source0:        https://files.pythonhosted.org/packages/source/t/%{pypi_name}/%{pypi_name}-%{version}.tar.gz

(See https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file for another example of this).

While it's certainly fine to have the man page and desktop file in the spec like this, if you are the upstream maintainer, is it possible to include them in the upstream releases in the future? Distributions other than Fedora would likely benefit from them.

You should also look into creating and shipping an AppData file for the package as described here: https://fedoraproject.org/wiki/Packaging:AppData.

Thanks a lot, Ben!

I added desktop file, man page and AppData file to the upstream sdist, changed the Source0 and added icon installation.

The result is here: 

* https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
* https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.14-1.fc26.src.rpm

PS. I tried also validating the AppData file in %install section ( https://bitbucket.org/plas/thonny-rpm/src/c15b8b97a1af5d58c28d695b51de57c2df609bb0/thonny.spec?fileviewer=file-view-default#thonny.spec-42 ), but then mock complained about not finding the screenshot files. Looks like it simply ran without internet access. Is it OK to leave the validation out?

> Is it OK to leave the validation out?

If you add --nonet to the appstream-util command, it should work when ran without internet access (as is the case when ran under mock). So, instead of:

> appstream-util validate-relax %{buildroot}/%{_datadir}/metainfo/org.thonny.Thonny.appdata.xml

You can do this instead, and then it should be able to validate.

appstream-util validate-relax --nonet %{buildroot}/%{_datadir}/metainfo/org.thonny.Thonny.appdata.xml

Thanks!

Here are the results with AppData validation included:

* https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
* https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.14-1.fc26.src.rpm
* https://copr.fedorainfracloud.org/coprs/aivarannamaa/thonny/

Ben, are you willing to sponsor the package or should I keep searching?

I made a small tweak in the upstream (removed StartupNotify from the desktop file). New state:

* https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
* https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.15-1.fc26.src.rpm
* https://copr.fedorainfracloud.org/coprs/aivarannamaa/thonny/

Please note that we don't sponsor packages, we sponsor people.  The sponsor is responsible for helping the packager get their package through the system and providing a direct contact point for questions when existing documentation or mailing lists aren't enough.

I am always willing to sponsor upstream developers who wish to include their software in Fedora, but I find it vastly preferable to work via public means of communication, particularly via IRC.  That way anyone who is available can help instead of everything relying on my response time (which can be variable).

So if you're on IRC, I'm tibbs in #fedora-devel on freenode.  Feel free to ping me.  And if you're not but this gets through a package review without you having picked up a sponsor, feel free to email me.

Note also that, sadly, I don't really have the time to do proper package review.  So someone else will need to do that.  I did have a quick look at the spec, though, and it certainly looks clean to me.

Thanks, Jason!

I'll contact you when the review gets done.

I can do a full review and I'm also willing to sponsor you.

I would very much like to include Thonny in the Fedora Python Classroom Lab.

From reading the spec, couple of nitpicks:

 * The reason to define and use the pypi_name macro does not apply here, since it equals the package name. I'd recommend getting rid of it and use %{name} everywhere.


 * I believe the -n option for %autosetup is not necessary, the used value is the default.

 * %{buildroot} already contains the trailing slash, so using %{buildroot}/ is not necessary and may eventually lead to trouble.

 * You can use desktop-file-install instead of install + desktop-file-validate.

 * Using %{python3_sitelib}/* in the %files section is very error prone. Instead, I recommend to go with something more specific, like %{python3_sitelib}/thonny (I haven't yet seen what the package installs exactly, so this might differ a bit, but a quick look at setup.py makes me think it should work here).

 * If more icon/logo resolutions are available, it would be a good idea to package them as well. (At least the ico file seems to have more resolution options).

Thanks, Miro!

I got rid of pypi_name, the -n option, extra slahs after buildroot (the slash after %{_datadir} is required, right?). I also introduced desktop-file-install. I also updated the version in changelog (forgot it last time).

With `%{python3_sitelib}/thonny` rpmbuild gave me:

Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/aivar/rpmbuild/BUILDROOT/thonny-2.1.15-1.fc26.x86_64
error: Installed (but unpackaged) file(s) found:
   /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/PKG-INFO
   /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/SOURCES.txt
   /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/dependency_links.txt
   /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/entry_points.txt
   /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/requires.txt
   /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/top_level.txt

I tried `%{python3_sitelib}/thonny*` instead, and it seemed to work fine. Should I keep this?

The changes are visible here: https://bitbucket.org/plas/thonny-rpm/commits/8e6565e3b387cde2402f296ea2f11d303582a724


I now noticed that I've forgotten a licensing issue. The toolbar icons are licensed with EPL, so I guess I need to change `License: MIT` to `License: MIT and EPL`. Am I right? But what should I then do with the EPL license text? (It is included in the upstream tarball in LICENSES/ECLIPSE-ICONS-LICENSE.txt) Currently my `%license LICENSE.txt` references the MIT license, which is the license for the code. I didn't find clear answers from https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios

(In reply to Aivar Annamaa from comment #10)
> Thanks, Miro!
> 
> I got rid of pypi_name, the -n option, extra slahs after buildroot (the
> slash after %{_datadir} is required, right?)

Yes. You can check with:

    $ rpm --eval '%{_datadir}'
    /usr/share

> I also introduced
> desktop-file-install. I also updated the version in changelog (forgot it
> last time).

Good catch


> With `%{python3_sitelib}/thonny` rpmbuild gave me:
> 
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /home/aivar/rpmbuild/BUILDROOT/thonny-2.1.15-1.fc26.x86_64
> error: Installed (but unpackaged) file(s) found:
>    /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/PKG-INFO
>    /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/SOURCES.txt
>   
> /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/
> dependency_links.txt
>   
> /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/entry_points.
> txt
>    /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/requires.txt
>   
> /usr/lib/python3.6/site-packages/thonny-2.1.15-py3.6.egg-info/top_level.txt
> 
> I tried `%{python3_sitelib}/thonny*` instead, and it seemed to work fine.
> Should I keep this?

Sorry about that, I forgot egg-info. Whether you go with thorny* or something more sophisticated is up to you. Thorny* will continue the build even if something like thorny_tests will get packaged by accident. I'd go with:

%{python3_sitelib}/%{name}/
%{python3_sitelib}/%{name}-%{version}-py%{python3_version}.egg-info/

Noticed the trailing slashes? I use them to make sure it's a directory.
Using %{name} here, spo others can copy paste form your spec with minimum effort.

However this works as well:


%{python3_sitelib}/thonny/
%{python3_sitelib}/thonny-*.egg-info

It's your call here.

> 
> The changes are visible here:
> https://bitbucket.org/plas/thonny-rpm/commits/
> 8e6565e3b387cde2402f296ea2f11d303582a724

I see "%autosetup %{name}-%{version}" - you should be able to go with just "%autosetup".

> I now noticed that I've forgotten a licensing issue. The toolbar icons are
> licensed with EPL, so I guess I need to change `License: MIT` to `License:
> MIT and EPL`. Am I right? But what should I then do with the EPL license
> text? (It is included in the upstream tarball in
> LICENSES/ECLIPSE-ICONS-LICENSE.txt) Currently my `%license LICENSE.txt`
> references the MIT license, which is the license for the code. I didn't find
> clear answers from
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/
> LicensingGuidelines#Multiple_Licensing_Scenarios

I haven't looked at the licenses yet, but if what you say is correect, than I'd go with the following (notice the comment):



# Code is MIT, icons are EPL
License: MIT and EPL

...


%license LICENSE.txt LICENSES/ECLIPSE-ICONS-LICENSE.txt

Thanks!

I updated the spec: https://bitbucket.org/plas/thonny-rpm/commits/d27b7445bae27bd3a72cb340fffe6c27d0bcd941

New state:

* https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
* https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.15-1.fc26.src.rpm
* https://copr.fedorainfracloud.org/coprs/aivarannamaa/thonny/monitor/

Is it OK, if I leave adding the additional icon resolutions to for the next upstream release?

(In reply to Aivar Annamaa from comment #12)
> Thanks!
> 
> I updated the spec:
> https://bitbucket.org/plas/thonny-rpm/commits/
> d27b7445bae27bd3a72cb340fffe6c27d0bcd941
> 
> New state:
> 
> * https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
> *
> https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.15-1.fc26.src.rpm
> * https://copr.fedorainfracloud.org/coprs/aivarannamaa/thonny/monitor/

Please always post links in the described form, there are automated tools that expect it that way:

Spec URL: https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
SRPM URL: https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.15-1.fc26.src.rpm


> Is it OK, if I leave adding the additional icon resolutions to for the next
> upstream release?

Sure.

Will do a formal review now.

In the meantime, could you please review some package(s) to show your ability to do so? (It would help me to sponsor you.)

There is a list of Python related review requests at https://fedoraproject.org/wiki/SIGs/Python#Review_Python_packages

Please indicate in the review that you are not yet sponsored.

See the review process explained here: https://fedoraproject.org/wiki/Package_Review_Process

Ask me here, or via e-mail, or find me as mhroncok at #fedora-python or #fedora-devel freenode IRC channels, if you have questions.

About the icon(s), you should update the icon cache, see https://fedoraproject.org/wiki/Packaging:Scriptlets#Icon_Cache

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

Not approved yet.

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


Issues:
=======
- gtk-update-icon-cache is not invoked in %postun and %posttrans if package
  contains icons.
  Note: icons in thonny
  See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache
- update-desktop-database is not invoked in %post and %postun if package
  contains desktop file(s) with a MimeType: entry.
  Note: desktop file(s) with MimeType entry in thonny
  See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-
  database
- the package should require hicolor-icon-theme, because it installs to
  directories owned by that package
- I see some tests in git. Can you execute them in the %check section please?

===== 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]: License field in the package spec file matches the actual license.
[x]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[!]: Package must own all directories that it creates.
     Note: Directories without known owners:
     /usr/share/icons/hicolor/256x256/apps,
     /usr/share/icons/hicolor/256x256, /usr/share/icons/hicolor
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: 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]: 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 20480 bytes in 3 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: No rpmlint messages.
[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 does not own files or directories owned by other packages.
[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]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or
     desktop-file-validate if there is such a file.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[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.
[x]: Package meets the Packaging Guidelines::Python
[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).
[x]: Package functions as described.
[x]: Latest version is packaged.
[-]: 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.
[!]: %check is present and all tests pass.
[?]: Packages should try to preserve timestamps of original installed
     files.
[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]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

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


Rpmlint
-------
Checking: thonny-2.1.15-1.fc28.noarch.rpm
          thonny-2.1.15-1.fc28.src.rpm
2 packages and 0 specfiles checked; 0 errors, 0 warnings.




Rpmlint (installed packages)
----------------------------
thonny.noarch: W: invalid-url URL: http://thonny.org <urlopen error [Errno -2] Name or service not known>
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

(Bogus, I don't have interwebs in mock)



Requires
--------
thonny (rpmlib, GLIBC filtered):
    /usr/bin/python3
    python(abi)
    python3
    python3-jedi
    python3-pip
    python3-tkinter



Provides
--------
thonny:
    application()
    application(org.thonny.Thonny.desktop)
    metainfo()
    metainfo(org.thonny.Thonny.appdata.xml)
    mimehandler(text/x-python)
    python3.6dist(thonny)
    python3dist(thonny)
    thonny



Source checksums
----------------
https://files.pythonhosted.org/packages/source/t/thonny/thonny-2.1.15.tar.gz :
  CHECKSUM(SHA256) this package     : 808f8069dd0e897b539e86e7ed5d43a6a8095aa3e4b71c288fce4ca1eba6c990
  CHECKSUM(SHA256) upstream package : 808f8069dd0e897b539e86e7ed5d43a6a8095aa3e4b71c288fce4ca1eba6c990

Thanks for the review! I'll fix the issues soon.

About doing my own review -- am I supposed to just show my ability to review or should I be really helpful?

I looked through the Python review requests which don't have a reviewer assigned yet. In all cases either somebody is already actively commenting the request or the submitter is really inactive (no responses for long time).

Is it of any use if I provide a second review for a request which already has a review or where someone has already promised to give a review?

I found an interesting package without review (python-asttokens, https://bugzilla.redhat.com/show_bug.cgi?id=1510188), but looks like it's already (close to be?) included in the Fedora repo. Does it make sense if I write a review for it?

Miro, I think I have fixed all the items you brought up, except %check:

Spec URL: https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
SRPM URL: https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.16-1.fc27.src.rpm

Changes:
* https://bitbucket.org/plas/thonny-rpm/commits/066a4208f320c561f4983864e8eedb5abdeca048
* https://bitbucket.org/plas/thonny-rpm/commits/0e84d4abb4eb98a7464335978d43f5afe6ab11a1


About %check:

Several of my tests are creating a Tkinter window. When I tried running the tests with

%check 
py.test-3 --pyargs thonny

then those tests failed because Tkinter couldn't access the display. I suppose this is because of the restricted build environment and there is nothing to do about it. When I install the package and run `py.test-3 --pyargs thonny` manually in Terminal, then all tests pass.

I hope it's OK to omit the %check for now. I'll try to organize my tests better in future versions so that the package builder can run at least those tests which doesn't use Tkinter.

PS. Did I understand correctly that %check is run only at package building time, not when user installs the package?

(In reply to Aivar Annamaa from comment #17)
> Thanks for the review! I'll fix the issues soon.
> 
> About doing my own review -- am I supposed to just show my ability to review
> or should I be really helpful?

I need the first, however the second is more important. Preferably you do both.

> I looked through the Python review requests which don't have a reviewer
> assigned yet. In all cases either somebody is already actively commenting
> the request or the submitter is really inactive (no responses for long time).
> 
> Is it of any use if I provide a second review for a request which already
> has a review or where someone has already promised to give a review?

That would satisfy my request but would only generate unnecessary noise and would not be helpful to others, so probably don't do it.

> I found an interesting package without review (python-asttokens,
> https://bugzilla.redhat.com/show_bug.cgi?id=1510188), but looks like it's
> already (close to be?) included in the Fedora repo. Does it make sense if I
> write a review for it?

Actually the review there happened: https://bugzilla.redhat.com/show_bug.cgi?id=1510188#c1 it was just extraordinary sloppy (please don't do that kind of reviews once you are sponsored.)

So we seem to have a problem that there is nothing to review :)

Here are the options I see:

 * skim trough other review requests, not just python related
 * ask on python-devel mailing list if someone is not working on a package
 * wait until something shows up

(In reply to Aivar Annamaa from comment #18)
> Miro, I think I have fixed all the items you brought up, except %check:

Great!

> About %check:
> 
> Several of my tests are creating a Tkinter window. When I tried running the
> tests with
> 
> %check 
> py.test-3 --pyargs thonny
> 
> then those tests failed because Tkinter couldn't access the display. I
> suppose this is because of the restricted build environment and there is
> nothing to do about it.

You might want to look at Xvfb. This seams relevant https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/N7OW5LPNJUGFHATFTNHJZC7W4V772H4O/

> When I install the package and run `py.test-3
> --pyargs thonny` manually in Terminal, then all tests pass.

When I do that, it collects 0 tests. What is the exact step by step guide?

> I hope it's OK to omit the %check for now. I'll try to organize my tests
> better in future versions so that the package builder can run at least those
> tests which doesn't use Tkinter.

Sure thing. I'd sugest marking the test with some kind of marker https://docs.pytest.org/en/latest/mark.html

> PS. Did I understand correctly that %check is run only at package building
> time, not when user installs the package?

Exactly.

(In reply to Miro Hrončok from comment #20)

> You might want to look at Xvfb. This seams relevant
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> thread/N7OW5LPNJUGFHATFTNHJZC7W4V772H4O/

Thanks! This did the trick:

%check
xvfb-run py.test-3 --pyargs thonny

Spec URL: https://bitbucket.org/plas/thonny-rpm/downloads/thonny.spec
SRPM URL: https://bitbucket.org/plas/thonny-rpm/downloads/thonny-2.1.16-1.fc27.src.rpm

Changes: https://bitbucket.org/plas/thonny-rpm/commits/a4c59df9bcd2a9f1defbe1a22cc5e52bddff7c8f


> > When I install the package and run `py.test-3
> > --pyargs thonny` manually in Terminal, then all tests pass.
> 
> When I do that, it collects 0 tests. What is the exact step by step guide?

1) sudo dnf install RPMS/noarch/thonny-2.1.16-1.fc27.noarch.rpm
2) py.test-3 --pyargs thonny

Did you try it with package version 2.1.16? The older stdists didn't include the tests yet.

(In reply to Aivar Annamaa from comment #21)
> (In reply to Miro Hrončok from comment #20)
> 
> > You might want to look at Xvfb. This seams relevant
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> > thread/N7OW5LPNJUGFHATFTNHJZC7W4V772H4O/
> 
> Thanks! This did the trick:
> 
> %check
> xvfb-run py.test-3 --pyargs thonny

Awesome!

> > > When I install the package and run `py.test-3
> > > --pyargs thonny` manually in Terminal, then all tests pass.
> > 
> > When I do that, it collects 0 tests. What is the exact step by step guide?
> 
> 1) sudo dnf install RPMS/noarch/thonny-2.1.16-1.fc27.noarch.rpm
> 2) py.test-3 --pyargs thonny
> 
> Did you try it with package version 2.1.16? The older stdists didn't include
> the tests yet.

Oh, ok, with 2.1.16 it really collects and work.

I declare this package preliminarily approved. Good work.

I've sponsored Aivar Annamaa. Package APPROVED.

Aivar, thank you for contributing to Fedora. Let me know if you need any help.

Thanks, Miro!

I'll continue the publishing process in couple of days.

(fedrepo-req-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/thonny

(fedrepo-req-admin):  Welcome to the Fedora package maintainers!

thonny-2.1.16-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-554c1f6747

thonny-2.1.16-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-554c1f6747

thonny-2.1.16-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.