Bug 1360753 - python-lirc: Provide a Python 3 subpackage
Summary: python-lirc: Provide a Python 3 subpackage
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: python-lirc
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PYTHON3
TreeView+ depends on / blocked
 
Reported: 2016-07-27 11:59 UTC by Dominika Krejčí
Modified: 2016-09-16 08:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-16 08:40:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dominika Krejčí 2016-07-27 11:59:04 UTC
Upstream, this software supports Python 3. Please provide a Python 3
package for Fedora.


According to the Python packaging guidelines [0], software must be
packaged for Python 3 if upstream supports it.
The guidelines give detailed information on how to do this, and even
provide an example spec file [1].

The current best practice is to provide subpackages for the two Python
versions (called "Common SRPM" in the guidelines). Alternatively, if
nothing depends on your Python2 package, you can just switch to Python 3
entirely.

It's OK to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 24 as well.


If you need more instructions, a guide for porting Python-based RPMs is
available at [2].
If anything is unclear, or if you need any kind of assistance with the
porting, you can ask on IRC (#fedora-python on Freenode), or reply here.
We'll be happy to help!


[0] https://fedoraproject.org/wiki/Packaging:Python
[1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
[2] http://python-rpm-porting.readthedocs.io/

Comment 1 Dominika Krejčí 2016-08-25 12:39:11 UTC
Hi Jan,
how is it going? Do you need any help?

Comment 2 Jan ONDREJ 2016-08-26 05:30:29 UTC
Hello Dominika,

  what do you think, can I switch to a different version of python-lirc?
It has same name, but different source. Current package looks to be unsupported anymore. New implementation:

https://pypi.python.org/pypi/python-lirc/

And as 3rd implementation, I have my own, which does not require to be compiled, uses python-ctypes.

So what do you think, can I update python-lirc-0.0.5 to a different implementation python-lirc-1.2.3? I don't know, if they are compatible.

I waited so long, because both implementations was obsolete, long time unmaintained, but looks like python-lirc-1.2.3 is now maintained well.

Comment 3 Petr Viktorin (pviktori) 2016-08-26 09:21:29 UTC
Is the new implementation based on the old code, and does it keep the old API?
If yes, I think it's OK to treat it as a new version. If not, it would be more correct to submit it as a new package.

Comment 4 Jan ONDREJ 2016-08-26 10:54:37 UTC
All lirc implementations have similar syntax, because it's very simple and based on lirc library syntax.

But looks like they use different name, old one uses "import pylirc", new one "import lirc", what is a compatibility problem.

Then I can't do anything to fix this bug, only close this bug as can't fix
and obsolete/retire this package.

Any other ideas?

I am not interested to add a new package for python-lirc-1.2.3, any volunteer?

Comment 5 Petr Viktorin (pviktori) 2016-08-26 11:10:50 UTC
> Then I can't do anything to fix this bug, only close this bug as can't fix
and obsolete/retire this package.
> Any other ideas?

Instead of obsolete/retire, you should orphan it. If no one picks it up, it'll be retired automatically.

> I am not interested to add a new package for python-lirc-1.2.3, any volunteer?

Probably not here. But a part of the [orphaning procedure] is a mail to try and find other volunteers.

[orphaning procedure]: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Orphaning_Procedure

Comment 6 Fedora Admin XMLRPC Client 2016-09-16 08:39:07 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


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