[Pkg-raspi-maintainers] Bug#856413: gpiozero: please provide python module on all architectures
peter green
plugwash at p10link.net
Fri Jan 18 01:31:33 GMT 2019
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.
-------------- next part --------------
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 <plugwash at 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
More information about the Pkg-raspi-maintainers
mailing list