WiringPi latest version is 2.44. Doing a manual git clone on git://git.drogon.net/wiringPi does retrieve the latest 2.44 version, however the buildroot packages retrieves 2.42, which does *NOT* work with newer kernels. Repeatable by doing: [buildroot@build buildroot]$ make wiringpi-source >>> wiringpi 2.44 Downloading Doing shallow clone Initialized empty Git repository in /home/buildroot/buildroot-2017.08/output/build/.wiringpi-2.44.tar.gz.DZuokV/wiringpi-2.44/.git/ remote: Counting objects: 383, done. remote: Compressing objects: 100% (333/333), done. remote: Total 383 (delta 210), reused 56 (delta 16) Receiving objects: 100% (383/383), 232.00 KiB, done. Resolving deltas: 100% (210/210), done. warning: Remote branch 2.44 not found in upstream origin, using HEAD instead Could not fetch special ref '2.44'; assuming it is not special. wiringpi-2.44.tar.gz: OK (sha256: 464c98ed54f5c0ad6611e270be3491c4598a32b7e86b208255862a301c564955)
WiringPi enables usage of GPIO pins, so I recon it is somewhat of an importance for embedded systems, the kind that's used with buildroot.
well, did you look at the build output ? Quoting your bug report: >>> wiringpi 2.44 Downloading So Buildroot is using wiringpi 2.44, as you request. The bump to 2.44 was done in March 2017, https://git.buildroot.org/buildroot/commit/package/wiringpi?id=76d36355de8c1957f08f6d5e68395cf6a1b69474, so it's part of the latest 2017.08 release.
Have a closer look at: warning: Remote branch 2.44 not found in upstream origin, using HEAD instead Could not fetch special ref '2.44'; assuming it is not special. It goes ahead to download 2.42 instead.
The problem seems to be a wrong tag in the original repository[1], buildroot checks out the 2.44 tag, same as commit [2], but the apparent version bump happens one commit [3] later (and gives the PiZero-W support)... But no changes regarding old/new kernels? Regards, Peter [1]https://git.drogon.net/?p=wiringPi;a=summary [2] https://git.drogon.net/?p=wiringPi;a=commitdiff;h=e8da87fbaced1edf75a5b37f78e8d4eb5ec0f18d [3] https://git.drogon.net/?p=wiringPi;a=commitdiff;h=96344ff7125182989f98d3be8d111952a8f74e15
Yes, I had some discussion with the bug reporter on IRC. Upstream tags 2.42 and 2.44 point to the exact same commit. There is only one commit *after* the 2.44 tag, and this commit mixes two things: - Updating the version to 2.44 in the VERSION file and elsewhere. Which obviously should have been done before the 2.44 tag is created. - Adding support for the RPi Zero W, which has nothing to do with supporting old or new kernels. Hence, there is nothing to fix in Buildroot. We can upgrade wiringpi to the latest version if we want to, but it's clearly not a bug.
(In reply to srg.venema from comment #3) > warning: Remote branch 2.44 not found in upstream origin, using HEAD instead I've sen that message with older versions of git. Basically, our wrapper uses: git clone --depth 1 -b ${ref} ${repo} However, in older versions of git, the -b option only expected a branch, not a tag. git-2.7.4 does accept either a tag or a branch for -b, while git-1.7.9.5 only accepts a branch with -b. What's more, as the message implies, if the branch is not found, then the HEAD if the default branch is used instead, a warning is printed, but this is not considered an error, which is clearly bad. :-( I don't know the exact version which started accepting a tag with -b. I'll research that, so we can decide if we want to support such an old git version, or if we start requiring something newer. Ergo, I'm reopenning, and assigning to me.
> I don't know the exact version which started accepting a tag with -b. So it was 1.8.0, released 2012-10-21, which added support for tags for git clone -b. So, git-1.7.x and before will not work with our current wrapper. Ubuntu 12.04 uses git-1.7.9.5. 12.04 was an LTS which supports ended last April, but there are older releases of other distros still supported today (e.g. RHEL), and those probably use even older git versions...
There is no WiringPi related bug here. Yann identified a Git downloader issue instead, so please open a separate bug to track this. Thanks!