Bug#856413: gpiozero: please provide python module on all architectures

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero: please provide python module on all architectures

Simone Rossetto
Package: gpiozero
Severity: wishlist

Dear Maintainer,

could you please provide a mock implementation of gpiozero python module
on all Debian architectures?


Thanks
Simone



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (12, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Reply | Threaded
Open this post in threaded view
|

Bug#856413: [Pkg-raspi-maintainers] Bug#856413: gpiozero: please provide python module on all architectures

Michael Stapelberg-25
Can you explain the motivating use-case please?

On Tue, Feb 28, 2017 at 7:33 PM, Simone Rossetto <[hidden email]> wrote:
Package: gpiozero
Severity: wishlist

Dear Maintainer,

could you please provide a mock implementation of gpiozero python module
on all Debian architectures?


Thanks
Simone



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (12, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

_______________________________________________
Pkg-raspi-maintainers mailing list
[hidden email]
https://lists.alioth.debian.org/mailman/listinfo/pkg-raspi-maintainers



--
Best regards,
Michael
Reply | Threaded
Open this post in threaded view
|

Bug#856413: [Pkg-raspi-maintainers] Bug#856413: gpiozero: please provide python module on all architectures

Simone Rossetto
Hi Michael

> Can you explain the motivating use-case please?

A fake implementation on all architectures can be useful for testing
purpose without having to rely on an emulator.

Reply | Threaded
Open this post in threaded view
|

Bug#856413: [Pkg-raspi-maintainers] Bug#856413: Bug#856413: gpiozero: please provide python module on all architectures

Dominik George-2
In reply to this post by Michael Stapelberg-25
> Can you explain the motivating use-case please?

See https://lists.debian.org/debian-python/2017/02/msg00073.html .

-nik

--
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)

signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#856413: [Pkg-raspi-maintainers] Bug#856413: gpiozero: please provide python module on all architectures

Dominik George-2
In reply to this post by Simone Rossetto
> could you please provide a mock implementation of gpiozero python module
> on all Debian architectures?

To clarify that:

gpiozero already *has* a mock implementation.

This bug asks for enabling the build on all architectures so this mock
implementation becomes available on non-ARM platforms.

-nik

--
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)

signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero: please provide python module on all architectures

Nick Morrott
In reply to this post by Simone Rossetto
I'm currently packaging Mu [1] and its missing dependencies for
Debian, and the question of remote GPIO pin control has arisen.

  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901461

Mu declares gpiozero and pigpio as dependencies. gpiozero can be used
with pigpio on a remote system to control GPIO on a Raspberry Pi.

Making gpiozero available on all possible platforms (rather than just
arm*) is therefore instrumental in providing support for remote GPIO
control.

Please could you make gpiozero available for all arches?


(Note: as we don't yet have pigpio packaged in Debian I have created an RFP [2])

  [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908787


Many thanks,
Nick

Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero: please provide python module on all architectures

Ben Nuttall
Thanks Nick

Please could you make gpiozero available for all arches?

I don't believe any changes to the library would be required for this. The control file
already states "Architecture: all" [1]. Is that correct, or is there anything else required?

 
(Note: as we don't yet have pigpio packaged in Debian I have created an RFP [2])

  [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908787

I think the package you want is python3-pigpio, rather than pigpio.

pigpio is the C library which runs as a daemon on the Pi. It accepts remote commands
and executes them on the Pi. The Python client (the package would be python3-pigpio)
is pure Python and is what communicates with remote Pis.

However, both pigpio and python3-pigpio are contained within the same source repo
on GitHub. In Raspbian we have both of these packaged. x86/64 Debian users will have
no need for pigpio, but there's a use case for the Python client as it allows remote GPIO
(either behind gpiozero or directly). That's the functionality Mu depends on. For the sake
of completion (unrelated to Mu), it would be nice to see pigpio itself in Debian, for those
using vanilla Debian on the Pi.

Let me know what we can do to help!

Thanks

Ben
 

Many thanks,
Nick
Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero: please provide python module on all architectures

peter green-2
In reply to this post by Simone Rossetto
I have chatted with Dave Jones (waveform80) about getting gpiozero support on more architectures. It seems sensible that as part of doing this we also package pigpio to support remote gpio operations.

Dominik do you mind if I add myself to the uploaders for this package and work on updating it to the lastest upstream version opening up the architecture list?

One thing we need to look at is making sure pi-specific code that hits hardware directly doesn't run on anything other than Pis. Both in gpiozero and in pigpio. Obviously this is a potential issue now but the risk rises as we package more stuff. I spoke to Dave about this at Manchester raspberry jam and he told me he had improved the detection in gpiozero recently, but the version at https://github.com/rpi-distro/python-gpiozero still seems to have the same code.

Dave is there an "experimental" gpiozero repository somewhere I have failed to find?

I don't believe any changes to the library would be required for this. The
control file
already states "Architecture: all" [1]. Is that correct, or is there
anything else required?
The gpiozero packaging in Debian and the gpiozero packaging in the raspberry pi foundation repo seem to be unrelated. This bug report is discussing the former.

pigpio is the C library which runs as a daemon on the Pi. It accepts remote
commands
and executes them on the Pi. The Python client (the package would be
python3-pigpio)
is pure Python and is what communicates with remote Pis. 
However, both pigpio and python3-pigpio are contained within the same
source repo
on GitHub. In Raspbian we have both of these packaged.

No, you have them packaged in the rasperry pi foundation repo.

And looking at that packaging it's going to need some work before
it's something acceptable to upload to Debian.

Right now the python stuff is directed to it's own binary packages but
all the c stuff is stuffed into one binary package. I see several issues
with this package.

1. It contains not one but three shared libaries, none of which seem to have proper so-versioning
2. It seems to have a directory for some sort of scripts in /opt/pigpio/cgi, I don't think this compiles with the filesystem heirachy standard.

I will follow up these issues in more detail in another mail with a different recipient list (which will include https://bugs.debian.org/908787 but not https://bugs.debian.org/856413 )


Reply | Threaded
Open this post in threaded view
|

Bug#908787: gpiozero: please provide python module on all architectures

Jones, Dave
Sorry, this fell off my radar - my clone of the gpio-zero repo (https://github.com/waveform80/gpio-zero) has some extra branches on it but all the important bits (for this) are PRd under https://github.com/RPi-Distro/python-gpiozero/pull/665. However, for some reason that branch is currently failing the Travis tests - I've got a nasty feeling I managed to push from the wrong box! I'll try and sort that out tonight.

Dave.

On Thu, 18 Oct 2018 at 19:20, peter green <[hidden email]> wrote:
I have chatted with Dave Jones (waveform80) about getting gpiozero support on more architectures. It seems sensible that as part of doing this we also package pigpio to support remote gpio operations.

Dominik do you mind if I add myself to the uploaders for this package and work on updating it to the lastest upstream version opening up the architecture list?

One thing we need to look at is making sure pi-specific code that hits hardware directly doesn't run on anything other than Pis. Both in gpiozero and in pigpio. Obviously this is a potential issue now but the risk rises as we package more stuff. I spoke to Dave about this at Manchester raspberry jam and he told me he had improved the detection in gpiozero recently, but the version at https://github.com/rpi-distro/python-gpiozero still seems to have the same code.

Dave is there an "experimental" gpiozero repository somewhere I have failed to find?

I don't believe any changes to the library would be required for this. The
control file
already states "Architecture: all" [1]. Is that correct, or is there
anything else required?
The gpiozero packaging in Debian and the gpiozero packaging in the raspberry pi foundation repo seem to be unrelated. This bug report is discussing the former.

pigpio is the C library which runs as a daemon on the Pi. It accepts remote
commands
and executes them on the Pi. The Python client (the package would be
python3-pigpio)
is pure Python and is what communicates with remote Pis. 
However, both pigpio and python3-pigpio are contained within the same
source repo
on GitHub. In Raspbian we have both of these packaged.

No, you have them packaged in the rasperry pi foundation repo.

And looking at that packaging it's going to need some work before
it's something acceptable to upload to Debian.

Right now the python stuff is directed to it's own binary packages but
all the c stuff is stuffed into one binary package. I see several issues
with this package.

1. It contains not one but three shared libaries, none of which seem to have proper so-versioning
2. It seems to have a directory for some sort of scripts in /opt/pigpio/cgi, I don't think this compiles with the filesystem heirachy standard.

I will follow up these issues in more detail in another mail with a different recipient list (which will include https://bugs.debian.org/908787 but not https://bugs.debian.org/856413 )


Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero: please provide python module on all architectures

peter green-2
In reply to this post by Simone Rossetto
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.


gpiozero.debdiff (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero NMU uploaded to delayed/10

peter green-2
In reply to this post by Simone Rossetto
tags 856413 +pending
tags 919617 +patch +pending
tags 919620 +patch +pending
thanks

I have now prepared a NMU for gpiozero addressing bugs 856413, 919617 and 919620. I have uploaded this NMU to delayed/10. A debdiff is attatched to this mail.

Please tell me if you see any issues with this NMU so I can fix them. OTOH if you are happy with the NMU please tell me so I can remove the delay.

Reply | Threaded
Open this post in threaded view
|

Bug#856413: gpiozero NMU uploaded to delayed/10

peter green-2
In reply to this post by Simone Rossetto
tags 856413 +pending
tags 919617 +patch +pending
tags 919620 +patch +pending
thanks

I have now prepared a NMU for gpiozero addressing bugs 856413, 919617 and 919620.
I have uploaded this NMU to delayed/10. A debdiff is attatched to this mail
(really attatched this time, sorry).

Please tell me if you see any issues with this NMU so I can fix them. OTOH if you
are happy with the NMU please tell me so I can remove the delay.


gpiozero.debdiff (4K) Download Attachment