diff --git python-mtTkinter/python-mtTkinter.spec python-mtTkinter/python-mtTkinter.spec.tmp
index 689e81f175..c2d614778a 100644
--- python-mtTkinter/python-mtTkinter.spec
+++ python-mtTkinter/python-mtTkinter.spec.tmp
@@ -3,7 +3,7 @@
 Summary:   A thread-safe version of Tkinter
 Name:      python-mtTkinter
 Version:   0.4
-Release:   13%{?dist}
+Release:   14%{?dist}
 License:   LGPLv3+
 Source0:   http://tkinter.unpythonic.net/attach/mtTkinter/attachments/mtTkinter-%{version}.tar.gz
 Source1:   08-clock-bezier.py
@@ -11,29 +11,37 @@ Group:     Development/Languages
 URL:       http://tkinter.unpythonic.net/wiki/mtTkinter
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: python-devel >= 2.4
-Requires:  tkinter
 BuildArch: noarch
 
-%description
-Although Tkinter is technically thread-safe 
-(assuming Tk is built with --enable-threads), 
-practically speaking there are still problems when used in multithreaded 
-Python applications.  The problems stem from the fact that the _tkinter 
-module attempts to gain control of the main thread via a polling technique 
-when processing calls from other threads.  If it succeeds, all is well. 
-If it fails (i.e., after a timeout), the application receives an exception 
-with the message: "RuntimeError: main thread is not in main loop". 
-There is no way to tell when this might happen, so calling Tk routines 
-from multiple threads seems to be problematic at best.
-
-The mtTkinter module solves this problem by modifying some Tkinter 
-module definitions (in memory). The modified code intercepts 
-out-of-thread Tkinter calls and marshals them through a queue which 
-is read by an 'after' event running periodically in the main loop. 
-This is similar to the technique used in many other platforms 
-(e.g., .NET's InvokeRequired/Invoke mechanism). 
-The technique used in mtTkinter is exception-safe as well, 
-marshaling exceptions through a response queue back to the caller's thread. 
+%global _description\
+Although Tkinter is technically thread-safe\
+(assuming Tk is built with --enable-threads),\
+practically speaking there are still problems when used in multithreaded\
+Python applications.  The problems stem from the fact that the _tkinter\
+module attempts to gain control of the main thread via a polling technique\
+when processing calls from other threads.  If it succeeds, all is well.\
+If it fails (i.e., after a timeout), the application receives an exception\
+with the message: "RuntimeError: main thread is not in main loop".\
+There is no way to tell when this might happen, so calling Tk routines\
+from multiple threads seems to be problematic at best.\
+\
+The mtTkinter module solves this problem by modifying some Tkinter\
+module definitions (in memory). The modified code intercepts\
+out-of-thread Tkinter calls and marshals them through a queue which\
+is read by an 'after' event running periodically in the main loop.\
+This is similar to the technique used in many other platforms\
+(e.g., .NET's InvokeRequired/Invoke mechanism).\
+The technique used in mtTkinter is exception-safe as well,\
+marshaling exceptions through a response queue back to the caller's thread.
+
+%description %_description
+
+%package -n python2-mttkinter
+Summary: %summary
+Requires:  tkinter
+%{?python_provide:%python_provide python2-mttkinter}
+
+%description -n python2-mttkinter %_description
 
 %prep
 %setup -q -n mtTkinter-%{version}
@@ -50,12 +58,16 @@ install -pm 0644 %{SOURCE1} %{_builddir}/mtTkinter-%{version}/clock-bezier.py
 %clean
 rm -rf %{buildroot}
 
-%files 
+%files -n python2-mttkinter
 %defattr(-,root,root,-)
 %doc clock-bezier.py lgpl.txt gpl.txt
 %{python_sitelib}/mtTkinter.py*
 
 %changelog
+* Sat Aug 12 2017 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> - 0.4-14
+- Python 2 binary package renamed to python2-mttkinter
+  See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
+
 * Thu Jul 27 2017 Fedora Release Engineering <releng@fedoraproject.org> - 0.4-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild