Just some comments:

- The package should be named "python-rpi-gpio2" not "python-RPi-GPIO2" 
- There is a mismatch between the releases (upstream is 0.3.0a3, package is 0.3.0 but 0.3.0a3 is used).
- The source tarball contains tests. Run them in %check.
- %check is for running tests and not maintenance.
- Ship the examples as part of %doc or as a subpackage. The same applies for the documentation.
- %{python3_sitelib}/RPi/ should be renamed. Looks like that there could be a naming clash if python-rpi-gpio is installed as well.

Source0: https://github.com/underground-software/RPi.GPIO2/archive/v0.3.0a3.tar.gz

→

Source0: https://github.com/underground-software/RPi.GPIO2/archive/v%{version}a3/%{name}-%{version}a3.tar.gz

 -

Version: 0.3.0
Release: 1%{?dist}

→

Version: 0.3.0
Release: 1.a3%{?dist}

 - This is not needed for a noarch package:

# This package is pure python code so debuginfo is useless
%global debug_package %{nil}

Just move:

BuildArch: noarch

to the main package.

 - Do this at the end of install:

rm -rf %{buildroot}%{python3_sitelib}/examples
rm -rf %{buildroot}%{python3_sitelib}/tests

 - As far as I understand, it needs to run on RPi to do the tests.

 - Don't mix tabs and spaces

 - Won't there be an import clash? One is in sitelib, the other in sitearch, but if I import the package, which one will be loaded? Shouln't you change the name of derectories to GPIO2?

(In reply to Fabian Affolter from comment #1)
(In reply to Robert-André Mauchin 🐧 from comment #2)

> - The package should be named "python-rpi-gpio2" not "python-RPi-GPIO2" 

Package renamed.

> - There is a mismatch between the releases (upstream is 0.3.0a3, package is
> 0.3.0 but 0.3.0a3 is used).
> 
>  -
> 
> Version: 0.3.0
> Release: 1%{?dist}
> 
> →
> 
> Version: 0.3.0
> Release: 1.a3%{?dist}
I added the alpha version number to the Release


> - The source tarball contains tests. Run them in %check.
> 
>  - As far as I understand, it needs to run on RPi to do the tests.
Yes, the tests only run on the actual Raspberry Pi device since they rely on the data structures provided by libgpiod to represent the actual pins.
I was considering instrumenting the library to use a fake gpiod module that simulates the pin state in software,
but I don't much of a purpose to that other than getting the tests to run on hardware where the library has no use case. I opened an issue for it on the GitHub repo a while ago to track this behavior:
https://github.com/underground-software/RPi.GPIO2/issues/16

> - %check is for running tests and not maintenance.
> 
>  - Do this at the end of install:
> 
> rm -rf %{buildroot}%{python3_sitelib}/examples
> rm -rf %{buildroot}%{python3_sitelib}/tests
Got it. Moved the maintenance steps to the end of install.

>  - This is not needed for a noarch package:
> 
> # This package is pure python code so debuginfo is useless
> %global debug_package %{nil}
> 
> Just move:
> 
> BuildArch: noarch
> 
> to the main package.
Done.


> - Ship the examples as part of %doc or as a subpackage. The same applies for
> the documentation.
I included the examples as a -doc subpackage, but I have updated the other documentation files since the v0.3.0a3 release. I plan to make another upstream release soon, so I could add those files as an update to this package, or I could do the upstream release first.
The documentation is also available at http://rpi.gpio2.underground.software/



> Source0:
> https://github.com/underground-software/RPi.GPIO2/archive/v0.3.0a3.tar.gz
> 
> →
> 
> Source0:
> https://github.com/underground-software/RPi.GPIO2/archive/v%{version}a3/
> %{name}-%{version}a3.tar.gz
> 
Changed it to the following to reflect the current repo structure, but I could modify the release if that is necessary:
Source0: https://github.com/underground-software/%{pypi_name}/archive/v%{version}
a3.tar.gz


>  - Don't mix tabs and spaces
I'm not sure where I made this mistake. Did you spot this in the spec? The source files were linted with flake8 but I certainly may have missed something.


>  - Won't there be an import clash? One is in sitelib, the other in sitearch,
> but if I import the package, which one will be loaded? Shouln't you change
> the name of derectories to GPIO2?

> - %{python3_sitelib}/RPi/ should be renamed. Looks like that there could be
> a naming clash if python-rpi-gpio is installed as well.

Yes, there is a naming clash and this is intentional. python-rpi-gpio is completely broken and does not work on the latest releases of Fedora as it relies on non-mainline kernel functionality or access to /dev/mem, disallowed in Fedora. When one attempts to use python-rpi-gpio, e.g. by entering `>>> import RPi.GPIO` at the python REPL, the following error is shown:
Traceback (most recent call last):
  File "./callback.py", line 2, in <module>
    import RPi.GPIO as GPIO
  File "/usr/lib64/python3.7/site-packages/RPi/GPIO/__init__.py", line 23, in <module>
    from RPi._GPIO import *
RuntimeError: This module can only be run on a Raspberry Pi!

I propose that python-rpi-gpio be dropped from Fedora as it is broken on the Raspberry Pi, its only use case.

This was my original motivation to develop this library, to provide a working transparent drop-in replacement for the RPi.GPIO API to allow users to make use of the RPi.GPIO API as it is widely used in tutorials and higher-level libraries (e.g. gpiozero), and enable more functionality for users of the Raspberry Pi who wish to run Fedora as their OS.


Updated spec: https://raw.githubusercontent.com/underground-software/RPi.GPIO2/packaging2/packaging/python-RPi-GPIO2.spec
Updated koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=50280565

>>  - Don't mix tabs and spaces
> I'm not sure where I made this mistake. Did you spot this in the spec? The source files were linted with flake8 but I certainly may have missed something.


Yes in the SPEC, not the source code. There's a tab line 2:

%global pypi_name	RPi.GPIO2

> I propose that python-rpi-gpio be dropped from Fedora as it is broken on the Raspberry Pi, its only use case.


Please discuss this with the current maintainers of RPi.GPIO before any action. If they accept, and if the functionality are the same, add an Obsoletes/Provides for the old package.


 - please rename you SPEC python-rpi-gpio2 and also rename this bug as well.

 - fix the changelog entry to reflect the header:

* Wed Aug 19 2020 Joel Savitz <joelsavitz> - 0.3.0-1.a3

 - Please include the name in your archive:

Source0: https://github.com/underground-software/%{pypi_name}/archive/v%{version}a3/%{pypi_name}-%{version}a3.tar.gz



I won't approve the package until the name clash is resolved with the maintainers of the v1. Ark them to comment in this bug if they're okay with it.

(In reply to Robert-André Mauchin 🐧 from comment #4)
> >>  - Don't mix tabs and spaces
> > I'm not sure where I made this mistake. Did you spot this in the spec? The source files were linted with flake8 but I certainly may have missed something.
> 
> 
> Yes in the SPEC, not the source code. There's a tab line 2:
> 
> %global pypi_name	RPi.GPIO2
Fixed.


> 
> 
>  - please rename you SPEC python-rpi-gpio2 and also rename this bug as well.
Done.

> 
>  - fix the changelog entry to reflect the header:
> 
> * Wed Aug 19 2020 Joel Savitz <joelsavitz> - 0.3.0-1.a3
Done.

> 
>  - Please include the name in your archive:
> 
> Source0:
> https://github.com/underground-software/%{pypi_name}/archive/v%{version}a3/
> %{pypi_name}-%{version}a3.tar.gz
> 
Done.


> 
> > I propose that python-rpi-gpio be dropped from Fedora as it is broken on the Raspberry Pi, its only use case.
> 
> 
> Please discuss this with the current maintainers of RPi.GPIO before any
> action. If they accept, and if the functionality are the same, add an
> Obsoletes/Provides for the old package.

> 
> 
> I won't approve the package until the name clash is resolved with the
> maintainers of the v1. Ark them to comment in this bug if they're okay with
> it.
Will needinfo the maintainers. Kushal and Fabian, what do you think of my proposal to replace python-rpi-gpio with python-rpi-gpio2?

Updated spec: https://raw.githubusercontent.com/underground-software/RPi.GPIO2/packaging2/packaging/python-rpi-gpio2.spec
Updated koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=50339420

(In reply to Joel Savitz from comment #5)
> (In reply to Robert-André Mauchin 🐧 from comment #4)
> > 
> > I won't approve the package until the name clash is resolved with the
> > maintainers of the v1. Ark them to comment in this bug if they're okay with
> > it.
> Will needinfo the maintainers. Kushal and Fabian, what do you think of my
> proposal to replace python-rpi-gpio with python-rpi-gpio2?

I fine with dropping python-rpi-gpio but ultimately it's Kushal's call.

(In reply to Robert-André Mauchin 🐧 from comment #4)
> I won't approve the package until the name clash is resolved with the
> maintainers of the v1. Ark them to comment in this bug if they're okay with
> it.

I asked Kushal if he'd be OK with dropping the v1 via email in early September and he replied with his approval, but I have not been able to get ahold of him since.

Is there anything else I can do to move this process forward?

Any news on that? This package is very interesting.

What is it waiting for now? I made my own package and spec for it, used on my COPR [1].

Since upstream contains version RPi.GPIO2 in the name, I think it should be separate package anyway. According to comment #5, it was renamed and does not have to wait for original maintainer's approval. It just have to Conflicts: with it, because it provides python module of the same name. According to my tests, this is more useful than the old one, because it works on Fedora kernel.

Can we move to formal review, Robert?

1. https://copr.fedorainfracloud.org/coprs/pemensik/raspberry-pi/

(In reply to Petr Menšík from comment #9)
> What is it waiting for now? I made my own package and spec for it, used on
> my COPR [1].
> 
> Since upstream contains version RPi.GPIO2 in the name, I think it should be
> separate package anyway. According to comment #5, it was renamed and does
> not have to wait for original maintainer's approval. It just have to
> Conflicts: with it, because it provides python module of the same name.
> According to my tests, this is more useful than the old one, because it
> works on Fedora kernel.
> 
> Can we move to formal review, Robert?
> 
> 1. https://copr.fedorainfracloud.org/coprs/pemensik/raspberry-pi/

Hello Petr, thanks for doing a rebuild and helping push this along. I called it RPi.GPIO2 to distinguish it from the original implementation. At this point I'd be fine with whatever naming needs to be done in order to get this into Fedora.

I had briefly been in touch with Peter Robinson about this package and he suggested trying to get this functionality integrated with Ben Croston's original RPi.GPIO, but I have had no luck getting ahold of him via email. The advantage of obsoleting the broken RPi.GPIO package would be that the replacement would be fully transparent, but this package, with the '2', would still come up via a `dnf search RPi.GPIO`. However, due to the fact that the fedora RPi.GPIO package has been quietly broken for years at this point, I don't think many people were using it in the first place. Fedora was somewhat painful to use on the rpi3 in my experience, however usage on the rpi4 is much better and I think there is much more potential for Fedora on these newer models. Recently I tested this library on my rpi4B and besides a few needed tweaks to the tests it worked very well.

Anyway, I have been emailing Kushal every now and then since I saw comment 4, but I have not heard from him and I am not sure how to move this forward.