tags 856413 +patch
thanks

As part of preparing for opening up the architecture lists for gpiozero I 
researched what there is in the way of raspberry pi detection.

If no backend is explicitly specified gpiozero tries the following four 
backends in-order. 'rpigpio', 'rpio', 'pigpio', 'native'

'rpigpio' relies on the rpi.gpio library which is packaged in Debian but only 
for arm*, it has some attempt at rpi detection but it looks like it could 
suffer from false positives in some cases. I will file a bug report about that 
with rpigpio upstream.
'rpio' relies on the rpio library which is not Packaged in Debian, so it's 
unlikely it would get installed on non-pi hardware. It looks to be a basically 
dead project anyway. I will bring this up with upstream.
'pigpio' is a client-server set-up. If the server is running on something other 
than a Pi you probablly already have big problems whether gpiozero talks to it 
or not. In practice though the server is almost certain to bail out on anything 
other than a Pi running a foundation kernel because of the lack of the broadcom 
mailbox interface.

So that leaves the "native" backend. Since this is pure python and part of gpiozero it is 
likely to attempt to load on any system. I was struggling to trace through the code, so I decided 
to actually try running it on an x86-64 system. It failed with "unable to determine peripheral 
base". Searching the code found.

        try:
            with io.open('/proc/device-tree/soc/ranges', 'rb') as f:
                f.seek(4)
                return struct.unpack(nstr('>L'), f.read(4))[0]
        except IOError:
            with io.open('/proc/cpuinfo', 'r') as f:
                for line in f:
                    if line.startswith('Hardware'):
                        try:
                            return 
self.PERI_BASE_OFFSET[line.split(':')[1].strip()]
                        except KeyError:
                            raise IOError('unable to determine RPi revision')
        raise IOError('unable to determine peripheral base')

The second part of this code is reasonably robust. It will almost certainly 
produce an error unless one of the known raspberry pi SoC names shows up.

The first part is more concerning. It basically assumes that if it can read 
from a certain offset /proc/device-tree/soc/ranges that the device in question 
is a Pi. This is not a good assumption but it is far more likely to be a 
problem on other arm devices than it is other architectures.

Overall I think while there are improvements to Raspberry pi detection that can 
and should be made, opening up the architecture list will not significantly 
increase the risk. So such improvements should not be a blocker for doing so.

This brings us on to the next issue, package metadata.

I have kept the rpi.gpio dependencies, but architecture qualified them with a 
list of arm architectures. You may wish to downgrade these to a Recommends but 
I will leave that up to you.

I made python{3}-pigpio a recommends on non-arm architectures and a suggests on 
arm architectures since the main use of gpiozero on non-arm architectures is 
remote gpio control.

I was sucessfully able to use the python3-gpiozero package built with these 
changes in conjunction with python3-pigpio to remotely control the GPIO of a pi 
over the network.

While I was working on this I discovered that the rpi.gpio dependencies were 
bogus, they were depending on the -common package, not the actually python 
packages. So I fixed that at the same time as adding the architecture lists.

Debdiff attatched, no immediate intent to NMU.

diff -Nru gpiozero-1.4.1/debian/changelog gpiozero-1.4.1/debian/changelog
--- gpiozero-1.4.1/debian/changelog     2019-01-13 14:13:03.000000000 +0000
+++ gpiozero-1.4.1/debian/changelog     2019-01-17 15:34:15.000000000 +0000
@@ -1,3 +1,14 @@
+gpiozero (1.4.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Open up architecture list.
+  * Change nonsensical rpi.gpio-common dependency to 
python-rpi.gpio/python3-rpi.gpio
+    and limit it's architecture list to arm*
+  * Recommend python-pigpio/python3-pigpio on non-arm architectures.
+  * Suggest python-pigpio/python3-pigpio on arm architectures.
+
+ -- Peter Michael Green <plugw...@debian.org>  Thu, 17 Jan 2019 15:34:15 +0000
+
 gpiozero (1.4.1-1) unstable; urgency=medium
 
   * Move to Salsa.
diff -Nru gpiozero-1.4.1/debian/control gpiozero-1.4.1/debian/control
--- gpiozero-1.4.1/debian/control       2019-01-13 14:12:32.000000000 +0000
+++ gpiozero-1.4.1/debian/control       2019-01-17 15:34:15.000000000 +0000
@@ -21,11 +21,15 @@
 Vcs-Browser: https://salsa.debian.org/raspi-team/gpiozero
 
 Package: python-gpiozero
-Architecture: arm64 armel armhf
+Architecture: any
 Depends:
- rpi.gpio-common,
+ python-rpi.gpio [armel armhf arm64],
  ${misc:Depends},
  ${python:Depends},
+Recommends:
+ python-pigpio [!armel !armhf !arm64]
+Suggests:
+ python-pigpio [armel armhf arm64]
 Description: simple interface to everyday GPIO components used with Raspberry 
Pi (Python 2)
  gpiozero is an object-oriented wrapper around using various elelctronic
  components with the GPIO interface on the Raspoberry Pi. It allows
@@ -36,11 +40,15 @@
  This package contains the Python 2 module.
 
 Package: python3-gpiozero
-Architecture: arm64 armel armhf
+Architecture: any
 Depends:
- rpi.gpio-common,
+ python3-rpi.gpio [armel armhf arm64],
  ${misc:Depends},
  ${python3:Depends},
+Recommends:
+ python-pigpio [!armel !armhf !arm64]
+Suggests:
+ python-pigpio [armel armhf arm64]
 Description: simple interface to everyday GPIO components used with Raspberry 
Pi (Python 3)
  gpiozero is an object-oriented wrapper around using various elelctronic
  components with the GPIO interface on the Raspoberry Pi. It allows
diff -Nru gpiozero-1.4.1/debian/rules gpiozero-1.4.1/debian/rules
--- gpiozero-1.4.1/debian/rules 2018-06-12 12:22:48.000000000 +0000
+++ gpiozero-1.4.1/debian/rules 2019-01-17 15:34:15.000000000 +0000
@@ -7,3 +7,6 @@
 
 %:
        dh $@ --with python2,python3 --buildsystem=pybuild
+
+override_dh_auto_clean:
+       dh_auto_clean

Reply via email to