[FFe] Please update lg-gpio to 0.2.0.0

Test packages have been built and tested from ppa:waveform/lg at https://launchpad.net/~waveform/+archive/ubuntu/lg/+packages

Hi Dave,

I was trying to review this but I can't tell from the diff where it stands WRT feature freeze. Could you please add an upstream changelog, git log, or similar to this bug to help with the review?

Cheers!

Hi Iain,

Certainly! Unfortunately there's no "official" changelog in the upstream project, and the diff between 0.1.6.1 and 0.2.0.0 is quite large (although the vast majority is changes in the examples). However, I can point out the most important bits from the point of view of Ubuntu:

* First is https://github.com/joan2937/lg/commit/dcabc9bc0ff3d8722ff65ae723a52ca0be2d1354#diff-3bd384b90eee7a776c13f2b3c85d74430c3583020d902a4c080f2d3190fd41f7 which is the commit that officially adds support for setting GPIO pulls (an important, and quite basic, feature for working with GPIOs). In 0.1.6.1 this was previously patched in by me (badly) under gpiochip API1, but this version supports it "correctly" under gpiochip API2 (which isn't deprecated).

* Second (though considerably less important, and probably not FFe valid) is that this version basically reduces our delta to nil (there's one trivial patch left to force deb layout on the python packages, and that's it).

I'll try and summarise the back-story for why the gpiochip API2 change is vaguely important to us. There are three methods of accessing GPIO pins: bypass the kernel and bang on registers directly (baaaad), use the (deprecated) sysfs interface, or use the gpiochip interface (of which API1 is deprecated, and API2 is not).

Most traditional GPIO libraries (RPi.GPIO, RPIO, pigpio, etc. etc.) use some combination of the first two (bang on registers with a bit of sysfs sprinkled in). In kinetic we're attempting to move away from this by disabling the deprecated sysfs interface (about a decade after it was deprecated!), which will break these traditional libraries (this was done in the recently released 5.19 kernel).

The newer libraries (like lg-gpio here) talk to the gpiochip interface, but our current version 0.1.6.1 only talks to the (already deprecated, but not yet removed) gpiochip API1, whilst the proposed new version 0.2.0.0 talks to the (not deprecated) gpiochip API2. So, while this bump is not *strictly* required to maintain functionality (the old version will still work with gpiochip API1 in kinetic ... albeit with some patches for pull up/down functionality), I would be prefer to be on a fully supported API, and not relying on patches for basic functionality :)

I understand if that's not sufficient for FFe; as mentioned the current version will still work in Kinetic and it may well be the safer path to take, i.e. the older version is the one I've been working with throughout this cycle (though since 5.19 was released I've been spending time on 0.2.0.0 too).

The main thing I need to finish at this point is an RPi.GPIO-compatible "shim" to lg-gpio, but that's another story!

An upload of lg-gpio to kinetic-proposed has been rejected from the upload queue for the following reason: "If something is marginal as an FFe it's not a good SRU candidate :). That said, if you want to try and drive this as an SRU we can see if it can be made acceptable and fish it out of the -rejected queue.".

This bug was fixed in the package lg-gpio - 0.2.0.0-0ubuntu1

---------------
lg-gpio (0.2.0.0-0ubuntu1) lunar; urgency=medium

  * New upstream release (LP: #1992107)
  * Removed patches merged upstream:
    - d/p/add-bias.patch
    - d/p/fix-groff-warnings.patch
  * d/control: Fixed architecture for python3-rgpio package
  * d/copyright: Simplified licensing (everything in public-domain)
  * d/lib*.symbols: Added symbols definitions for liblgpio1 and librgpio1
  * d/rgpiod.postrm: Fixed error on removal of rgpiod group

 -- Dave Jones <email address hidden> Thu, 21 Jul 2022 13:16:04 +0100