Drop wiringPi? It's bit-rotting

[6by9]

Apologies if this ought to have been raised another way.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=292422
WiringPi is bit-rotting now that it's not being maintained by Gordon - http://wiringpi.com/wiringpi-deprecated/
Last released version was 2.52, but only as binary. The repos have 2.50, but that has no support for Pi4, CM4, or Pi400.

There is a fork at https://github.com/WiringPi/WiringPi/ that includes Pi4 support, but not CM4 or Pi400.
Options:

• redirect to that fork
• take a fork in-house
• drop the package totally. (Is there an easy way to see which packages list it as a dependency?)

Thoughts?

[fanoush]

Just to comment 'drop the package totally'. Debian dependencies are only top of the iceberg. It is often used for supporting raspberry in multiplatform software so people may be dragged into wiringpi issue as a source dependency, not because of debian package dependency or because they they would pick it as their preferred GPIO library for their own development.

I know about two totally random pieces of software I personally use - Espruino https://github.com/espruino/Espruino/blob/master/Makefile#L149 and xc3prog https://github.com/matrix-io/xc3sprog/search?q=wiringpi However this is just me, this query https://github.com/search?p=1&q=WiringPI&type=Repositories can tell something about the usage.

But true that despite wide usage it can still be dropped and people will build it from source with other software.

As for CM4 and Pi400 support I created issue WiringPi/WiringPi#88 and posted partial fix there and will make PR with full fix (missed one place where new device needs to be added). However when checking other PRs it looks like not many go through review and merge.

[Gadgetoid]

I put out a call for maintainers on the WiringPi fork relatively recently, since I'm not particularly invested in it personally and haven't had the time to keep on top of maintenance myself. Or even on top of that call for maintainers!

There seems to be a certain amount of interest in keeping WiringPi alive and the unnoficial Discord server has over 1k members. I would suggest establishing a maintanance team on our fork and making it the canonical WiringPi.

In the grand scheme of things, the purpose WiringPi originally served was to provide an Arduino-like C interface to Raspberry Pi's GPIO functions. It has some nice accomodations and features that make it really sticky, plus- as @fanoush suggests- fairly widespread adoption in projects. I think it's probably extended past this original purpose and has been seen as "the way to do C GPIO on Pi". In the past that was relatively true (the lesser known libbcm2835 notwithstanding), but - as mentioned in: WiringPi/WiringPi#80 - C-style memory bitbanging and/or filesystem based GPIO has been superceded by libgpiod which would be considered the official Linux cross-platform approach to dealing with GPIO interfaces.

Anyway. TLDR: I'm happy to establish maintainers on WiringPi, but I'm stretched too thin to maintain it myself. I think there's a strong case for switching to our fork, but I'm also cautious of the blowback this might have on Gordon. There's an equally strong case to let this die and push a more modern approach.

[XECDesign]

* drop the package totally. (Is there an easy way to see which packages list it as a dependency?)

$ apt rdepends wiringpi
wiringpi
Reverse Depends:
  Depends: matlab-rpi
  Depends: pytrack-gps
  Depends: pt-device-manager
  Depends: picap

I've left it in the repo for legacy applications and the plan was drop it after Buster if the situation doesn't improve.

[fanoush]

That WiringPi github repo now has Pi400 support, I'd vote for using it as source for updated deb (possibly after merging this so CM4 defaut pin numbering scheme is same as previous CMs). Here is diff from original 2.50 WiringPi/WiringPi@final_official_2.50...master , don't see anything bad there to break older stuff, just new devices and debian packaging fixes.

Also we got response from gordon which does not add anything new so I guess there is nothing to wait for?

EDIT: when checking opened pull requests there are definitely more worth of merging for updated version, this one is probably quite important.

[seamusdemora]

@6by9 - I agree with what you've said:

this ought to have been raised another way.

IMHO, Gordon did some very good work. He's moved on now, and he's tried to explain why in this post.

Now - perhaps the following ought to have been raised in another way, but here goes:

It seems a shame that an organization that benefits from sales (~£46M in 2019) of the Raspberry Pi cannot muster the resources to lend a hand to maintaining WiringPi. Some recent tests suggest that WiringPi is, by at least one measure, the highest-performing GPIO library for Raspberry Pi by almost an order of magnitude. From my shallow perspective, it's certainly the easiest to use.

That said, my vote is for your 2nd option: take a fork in-house - or find some way to support WiringPi.

[Gadgetoid]

To their credit @liffiton has kept on top of WiringPi fairly well, with the last commit being ~14 days ago.

There is a focus on bugfixes and hardware support to keep this library alive, forsaking new features both to keep the maintenance burden low and to prevent it from growing in future.

I would venture that it's a suitable source for new packages to be built from, but could benefit from continuous-integration, version tags and releases to better facilitate this.

Since we didn't have source for the final release of WiringPi, there has been a divergence of bug fixes/updates circa the Pi 4 launch and thus I can't promise there wont be regressions by switching to this version- but at least we're relatively well poised to handle them. I don't keep a super close eye on things, but I'm easy enough to poke.

[fanoush]

I can't promise there wont be regressions by switching to this version

See my previous post, there is a link to github diff between Gordon's source and current master, in 'files changed' it can be seen it is highly unlikely stuff got broken for older devices.

Raspberry Pi cannot muster the resources to lend a hand to maintaining WiringPi.

Well the WiringPi github repo is in pretty good shape already (IMO in better shape than the original source was), what is needed is building the packages from it and replacing the broken one in raspbian repos.

[seamusdemora]

Well the WiringPi github repo is in pretty good shape already (IMO in better shape than the original source was), what is needed is building the packages from it and replacing the broken one in raspbian repos.

By that I assume you're referring to the "patch" that's required for RPi 4?

You're probably correct in any case, but wouldn't that comment be more appropriate for the WiringPi repo?

[liffiton]

Yeah, @Gadgetoid and I have been keeping it alive in the Github WiringPi repo and patching it to support newer hardware with contributions and help from people like @fanoush.

It's not clear to me who is in charge of potentially updating the package in the Raspberry Pi distro, but I would be happy to work with them to get the packaging all cleaned up and new packages built.

[Gadgetoid]

It's not clear to me who is in charge of potentially updating the package in the Raspberry Pi distro, but I would be happy to work with them to get the packaging all cleaned up and new packages built.

Is this a Serge thing?

[6by9]

It's not clear to me who is in charge of potentially updating the package in the Raspberry Pi distro, but I would be happy to work with them to get the packaging all cleaned up and new packages built.

Is this a Serge thing?

Yes, it's down to Serge - @XECDesign
If there is an updated package that can be picked up, then I suspect he'd take it.

[XECDesign]

Package is no longer included in Bullseye.

@Gadgetoid if it's a package you'd like to pick up you can always upload it using the usual means or shoot me an email.

[mwallner]

Sorry for commenting on this already closed issue but fwiw : WiringPi is back in version 3 - with the goal of keeping legacy projects based on it alive on newer platforms and OS versions

[6by9]

I expect XECDesign's comment of #214 (comment) still applies.

If there is a Debian package that can be taken, then it can be considered for inclusion again.

[seamusdemora]

Given the incoherent stream of gobbledygook coming from the libgpiod bunch, I would say your comment to re-consider wiringPi for inclusion is a wise one.