[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[buildroot at heine.tech]

From: Michael Nosthoff <buildroot@heine.tech>

* when kernel headers are <5.5 fall back to version 1.4.4
* set url to kernel.org as github is unmaintained and outdated

Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
---
 package/libgpiod/Config.in     | 2 +-
 package/libgpiod/libgpiod.hash | 3 ++-
 package/libgpiod/libgpiod.mk   | 7 ++++++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/package/libgpiod/Config.in b/package/libgpiod/Config.in
index 63a7cb6e78..293eef6c89 100644
--- a/package/libgpiod/Config.in
+++ b/package/libgpiod/Config.in
@@ -5,7 +5,7 @@ config BR2_PACKAGE_LIBGPIOD
 	  This is a C library that abstracts the GPIO character
 	  device operations on linux.
 
-	  https://github.com/brgl/libgpiod
+	  https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
 
 if BR2_PACKAGE_LIBGPIOD
 
diff --git a/package/libgpiod/libgpiod.hash b/package/libgpiod/libgpiod.hash
index f0009a7510..b05b4ae231 100644
--- a/package/libgpiod/libgpiod.hash
+++ b/package/libgpiod/libgpiod.hash
@@ -1,4 +1,5 @@
 # From https://www.kernel.org/pub/software/libs/libgpiod/sha256sums.asc
-sha256 21ae8fd1f8dafc2eb2ba50e652390cf533d21351419a7426255895cb52e21b1c  libgpiod-1.4.1.tar.xz
+sha256 f1cda2789e6a13a92aefc012a76e5a7cc57a1b402d66f71df8719ee314b67699  libgpiod-1.4.4.tar.xz
+sha256 62908023d59e8cbb9137ddd14deec50ced862d8f9b8749f288d3dbe7967151ef  libgpiod-1.6.tar.xz
 # Hash for license file
 sha256 ce64d5f7b49ea6d80fdb6d4cdee6839d1a94274f7493dc797c3b55b65ec8e9ed  COPYING
diff --git a/package/libgpiod/libgpiod.mk b/package/libgpiod/libgpiod.mk
index 2474ab90a2..d5b38a6149 100644
--- a/package/libgpiod/libgpiod.mk
+++ b/package/libgpiod/libgpiod.mk
@@ -4,7 +4,12 @@
 #
 ################################################################################
 
-LIBGPIOD_VERSION = 1.4.1
+# starting with 1.5 libgpiod depends on Headers >= 5.5
+ifeq ($(BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_5),y)
+LIBGPIOD_VERSION = 1.6
+else
+LIBGPIOD_VERSION = 1.4.4
+endif
 LIBGPIOD_SOURCE = libgpiod-$(LIBGPIOD_VERSION).tar.xz
 LIBGPIOD_SITE = https://www.kernel.org/pub/software/libs/libgpiod
 LIBGPIOD_LICENSE = LGPL-2.1+
-- 
2.25.1

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Thomas Petazzoni]

Hello Michael,

On Thu, 29 Oct 2020 12:06:33 +0100
Michael Nosthoff via buildroot <buildroot@busybox.net> wrote:

> -LIBGPIOD_VERSION = 1.4.1
> +# starting with 1.5 libgpiod depends on Headers >= 5.5
> +ifeq ($(BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_5),y)
> +LIBGPIOD_VERSION = 1.6
> +else
> +LIBGPIOD_VERSION = 1.4.4
> +endif

Hum, this is a bit annoying. And upstream is not willing to have proper
conditional logic to keep supporting kernels older than 5.5 ? 5.5 is
not that old, it seems odd to so quickly drop support. Even 5.4 is the
current LTS kernel !

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Michael Nosthoff]

Hi,
 
On Thursday, October 29, 2020 13:50 CET, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: 

> 
> Hum, this is a bit annoying. And upstream is not willing to have proper
> conditional logic to keep supporting kernels older than 5.5 ? 5.5 is
> not that old, it seems odd to so quickly drop support. Even 5.4 is the
> current LTS kernel !

At least that's how I interpret this comment in the NEWS for 1.5 [0]:

- added support for bias flags which are a new functionality first available in
  linux v5.5; subsequently the library now requires v5.5 kernel headers to
  build;

But maybe Bartosz can clarify on this, as he basically is the "upstream" :)


Regards,
Michael

[0] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/NEWS

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Thu, Oct 29, 2020 at 2:06 PM Michael Nosthoff <buildroot@heine.tech> wrote:
>
> Hi,
>
> On Thursday, October 29, 2020 13:50 CET, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> >
> > Hum, this is a bit annoying. And upstream is not willing to have proper
> > conditional logic to keep supporting kernels older than 5.5 ? 5.5 is
> > not that old, it seems odd to so quickly drop support. Even 5.4 is the
> > current LTS kernel !
>
> At least that's how I interpret this comment in the NEWS for 1.5 [0]:
>
> - added support for bias flags which are a new functionality first available in
>   linux v5.5; subsequently the library now requires v5.5 kernel headers to
>   build;
>
> But maybe Bartosz can clarify on this, as he basically is the "upstream" :)
>
>
> Regards,
> Michael
>
> [0] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/NEWS
>

Hi Thomas!

I don't want to have an ifdef hell in libgpiod depending on symbol
presence/kernel version. I much better prefer to support multiple
stable branches. v1.4.x will be supported for as long as linux v5.4 is
supported.

That being said: libgpiod only requires the v5.5 headers to build. It
will still work on older kernels unless someone uses features that
aren't supported.

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Thomas Petazzoni]

On Thu, 29 Oct 2020 14:06:45 +0100
"Michael Nosthoff" <buildroot@heine.tech> wrote:

> At least that's how I interpret this comment in the NEWS for 1.5 [0]:
> 
> - added support for bias flags which are a new functionality first available in
>   linux v5.5; subsequently the library now requires v5.5 kernel headers to
>   build;
> 
> But maybe Bartosz can clarify on this, as he basically is the "upstream" :)

Wow, actually things are even worse. The latest upstream commit goes
like this:

    treewide: make linux v5.10 a hard requirement for libgpiod
    
    The library now uses v2 of the GPIO uAPI. The new user interface is
    scheduled for release as part of linux v5.10. Linux v5.10-rc1 is now
    tagged so make v5.10 headers a requirement for the build and update
    all tests to check for the correct version.
    
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

So a userspace package requires a not-even released Linux kernel
version, without backward compatibility for older kernel versions. This
seems like a really really odd decision from upstream :-/

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Thu, Oct 29, 2020 at 2:13 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Thu, 29 Oct 2020 14:06:45 +0100
> "Michael Nosthoff" <buildroot@heine.tech> wrote:
>
> > At least that's how I interpret this comment in the NEWS for 1.5 [0]:
> >
> > - added support for bias flags which are a new functionality first available in
> >   linux v5.5; subsequently the library now requires v5.5 kernel headers to
> >   build;
> >
> > But maybe Bartosz can clarify on this, as he basically is the "upstream" :)
>
> Wow, actually things are even worse. The latest upstream commit goes
> like this:
>
>     treewide: make linux v5.10 a hard requirement for libgpiod
>
>     The library now uses v2 of the GPIO uAPI. The new user interface is
>     scheduled for release as part of linux v5.10. Linux v5.10-rc1 is now
>     tagged so make v5.10 headers a requirement for the build and update
>     all tests to check for the correct version.
>
>     Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> So a userspace package requires a not-even released Linux kernel
> version, without backward compatibility for older kernel versions. This
> seems like a really really odd decision from upstream :-/
>

Thomas,

This is the master branch - it's not meant for being deployed in
distros - this is what stable branches are for. We now have a new ABI
in linux and libgpiod has just started a new release cycle that will
break the API and ABI of the library - hence the version bump to v2.0
from v1.6 - in order to use new kernel features.

v2.0 of libgpiod will no longer support older kernels but I'll support
v1.6 indefinitely for older kernels and v1.4 as long as v5.4 is
supported.

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Michael Nosthoff]

Hi,
 
On Thursday, October 29, 2020 14:41 CET, Bartosz Golaszewski <brgl@bgdev.pl> wrote: 

> 
> v2.0 of libgpiod will no longer support older kernels but I'll support
> v1.6 indefinitely for older kernels and v1.4 as long as v5.4 is
> supported.

Will 1.4.x still work with 5.10 kernels? I guess the old API will just be deprecated for a while?

So I guess we have two possibilities going forward: 

- Use the version switch I proposed and even extend it when 2.0 and headers 5.10 are released
or
- Stay on the 1.4.x branch until linux 5.5 is the oldest supported version (if this is possible).

Regards,
Michael

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Thomas Petazzoni]

Hello,

On Fri, 30 Oct 2020 08:53:18 +0100
"Michael Nosthoff" <buildroot@heine.tech> wrote:

> Will 1.4.x still work with 5.10 kernels? I guess the old API will
> just be deprecated for a while?
> 
> So I guess we have two possibilities going forward: 
> 
> - Use the version switch I proposed and even extend it when 2.0 and
> headers 5.10 are released or
> - Stay on the 1.4.x branch until linux 5.5 is the oldest supported
> version (if this is possible).

What worries a bit with supporting both 1.4 and 1.6, and in the future
say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new
APIs. Applications may rely on such new APIs. When the kernel headers
are recent enough, a recent version of libgpiod will be used, and such
applications will build properly. But as soon as soon builds a system
with older kernel headers, libgpiod will downgrade to an older version,
providing potentially less APIs, and therefore breaking any application
using them.

This strategy of not supporting older kernels in newer versions of
libgpiod also means that libgpiod should not introduce any new public
API... Otherwise the maintenance burden that libgpiod avoids by not
supporting older kernels is a maintenance burden that will fall on the
shoulders of users of libgpiod, who will have to make conditional
switches depending on whether libgpiod 1.4, 1.6 or 2.0 is used.

I am still highly doubtful of the strategy chosen by upstream libgpiod
here.

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Fri, Oct 30, 2020 at 9:19 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Fri, 30 Oct 2020 08:53:18 +0100
> "Michael Nosthoff" <buildroot@heine.tech> wrote:
>
> > Will 1.4.x still work with 5.10 kernels? I guess the old API will
> > just be deprecated for a while?
> >
> > So I guess we have two possibilities going forward:
> >
> > - Use the version switch I proposed and even extend it when 2.0 and
> > headers 5.10 are released or
> > - Stay on the 1.4.x branch until linux 5.5 is the oldest supported
> > version (if this is possible).
>
> What worries a bit with supporting both 1.4 and 1.6, and in the future
> say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new
> APIs. Applications may rely on such new APIs. When the kernel headers
> are recent enough, a recent version of libgpiod will be used, and such
> applications will build properly. But as soon as soon builds a system
> with older kernel headers, libgpiod will downgrade to an older version,
> providing potentially less APIs, and therefore breaking any application
> using them.
>

In yocto this can be handled by providing multiple versions of a
package and then making any recipes that need it depend on at-least
certain version of it - is buildroot capable of doing something like
this?

> This strategy of not supporting older kernels in newer versions of
> libgpiod also means that libgpiod should not introduce any new public
> API... Otherwise the maintenance burden that libgpiod avoids by not
> supporting older kernels is a maintenance burden that will fall on the
> shoulders of users of libgpiod, who will have to make conditional
> switches depending on whether libgpiod 1.4, 1.6 or 2.0 is used.
>

I don't entirely agree. v1.6 is backward compatible with v1.4 (API-
and ABI-wise) - programs linked against v1.4 will work with v1.6. v1.6
will still work with older kernels (granted it's built with v5.5
headers) but any operations that require new kernel features will
simply fail at the kernel level. If users don't use these new
features, the library works the same.

The whole goal of developing a new major release (v2.0) is to rework
the public API entirely and also use uAPI v2. Otherwise it would be
impossible to support new kernel features. This kind of API breakage
has been done by many projects: look at gtk2 & gtk3, gstreamer0 and
gstreamer1, python2 and python3 and probably many others. And libgpiod
is a rather small library with not many reverse dependencies so far.

Libgpiod v2.0 will use the new kernel uAPI and thus require at least
the kernel version where this uAPI first appeared. Just like libgpiod
v1.x won't work with kernels pre v4.6, libgpiod v2.x won't work with
kernels pre v5.10. I don't see how that's a problem.

> I am still highly doubtful of the strategy chosen by upstream libgpiod
> here.
>

I think you're overestimating the impact here. For now the master
branch moves forward towards a stable v2.0 API. Users are definitely
not encouraged to use it ATM. v1.4 and v1.6 are the currently
supported stable branches. v1.4 builds and works with linux v4.6. v1.6
builds with linux v5.5 but still works with v4.6 unless the user calls
new functions (set_config, bias flags, etc.) where it will fail at
run-time but older user programs can still link against it.

Let me know if I'm missing something but I really prefer to avoid an
ifdef hell and QA mess with supporting earlier kernels with v2.0.

Best regards,
Bartosz Golaszewski

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Thomas Petazzoni]

Hello Bartosz,

On Fri, 30 Oct 2020 09:42:01 +0100
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> > What worries a bit with supporting both 1.4 and 1.6, and in the future
> > say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new
> > APIs. Applications may rely on such new APIs. When the kernel headers
> > are recent enough, a recent version of libgpiod will be used, and such
> > applications will build properly. But as soon as soon builds a system
> > with older kernel headers, libgpiod will downgrade to an older version,
> > providing potentially less APIs, and therefore breaking any application
> > using them.
> 
> In yocto this can be handled by providing multiple versions of a
> package and then making any recipes that need it depend on at-least
> certain version of it - is buildroot capable of doing something like
> this?

No, what we typically do is have separate packages for libraries which
have major versions with significantly different APIs.

> I don't entirely agree. v1.6 is backward compatible with v1.4 (API-
> and ABI-wise) - programs linked against v1.4 will work with v1.6. v1.6
> will still work with older kernels (granted it's built with v5.5
> headers) but any operations that require new kernel features will
> simply fail at the kernel level. If users don't use these new
> features, the library works the same.
> 
> The whole goal of developing a new major release (v2.0) is to rework
> the public API entirely and also use uAPI v2. Otherwise it would be
> impossible to support new kernel features. This kind of API breakage
> has been done by many projects: look at gtk2 & gtk3, gstreamer0 and
> gstreamer1, python2 and python3 and probably many others. And libgpiod
> is a rather small library with not many reverse dependencies so far.
> 
> Libgpiod v2.0 will use the new kernel uAPI and thus require at least
> the kernel version where this uAPI first appeared. Just like libgpiod
> v1.x won't work with kernels pre v4.6, libgpiod v2.x won't work with
> kernels pre v5.10. I don't see how that's a problem.
> 
> > I am still highly doubtful of the strategy chosen by upstream libgpiod
> > here.
> >  
> 
> I think you're overestimating the impact here. For now the master
> branch moves forward towards a stable v2.0 API. Users are definitely
> not encouraged to use it ATM. v1.4 and v1.6 are the currently
> supported stable branches. v1.4 builds and works with linux v4.6. v1.6
> builds with linux v5.5 but still works with v4.6 unless the user calls
> new functions (set_config, bias flags, etc.) where it will fail at
> run-time but older user programs can still link against it.
> 
> Let me know if I'm missing something but I really prefer to avoid an
> ifdef hell and QA mess with supporting earlier kernels with v2.0.

I think as long as there's really a 1.x series that is entirely API
compatible, and then another 2.x series that is entirely API
compatible, but different than 1.x, then it's fine indeed.

We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are
guaranteed to offer the same API to users of the libraries.

And once libgpiod2 is out, we'll have a separate libgpiod2.mk.

Would that work ?

If so, then it's fine for me.

Thanks for explaining your strategy. It's great to have upstream
directly on-board in these discussions!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Fri, Oct 30, 2020 at 10:16 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Bartosz,
>
> On Fri, 30 Oct 2020 09:42:01 +0100
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > > What worries a bit with supporting both 1.4 and 1.6, and in the future
> > > say 1.4, 1.6 and 2.0 is that newer versions are likely to introduce new
> > > APIs. Applications may rely on such new APIs. When the kernel headers
> > > are recent enough, a recent version of libgpiod will be used, and such
> > > applications will build properly. But as soon as soon builds a system
> > > with older kernel headers, libgpiod will downgrade to an older version,
> > > providing potentially less APIs, and therefore breaking any application
> > > using them.
> >
> > In yocto this can be handled by providing multiple versions of a
> > package and then making any recipes that need it depend on at-least
> > certain version of it - is buildroot capable of doing something like
> > this?
>
> No, what we typically do is have separate packages for libraries which
> have major versions with significantly different APIs.
>
> > I don't entirely agree. v1.6 is backward compatible with v1.4 (API-
> > and ABI-wise) - programs linked against v1.4 will work with v1.6. v1.6
> > will still work with older kernels (granted it's built with v5.5
> > headers) but any operations that require new kernel features will
> > simply fail at the kernel level. If users don't use these new
> > features, the library works the same.
> >
> > The whole goal of developing a new major release (v2.0) is to rework
> > the public API entirely and also use uAPI v2. Otherwise it would be
> > impossible to support new kernel features. This kind of API breakage
> > has been done by many projects: look at gtk2 & gtk3, gstreamer0 and
> > gstreamer1, python2 and python3 and probably many others. And libgpiod
> > is a rather small library with not many reverse dependencies so far.
> >
> > Libgpiod v2.0 will use the new kernel uAPI and thus require at least
> > the kernel version where this uAPI first appeared. Just like libgpiod
> > v1.x won't work with kernels pre v4.6, libgpiod v2.x won't work with
> > kernels pre v5.10. I don't see how that's a problem.
> >
> > > I am still highly doubtful of the strategy chosen by upstream libgpiod
> > > here.
> > >
> >
> > I think you're overestimating the impact here. For now the master
> > branch moves forward towards a stable v2.0 API. Users are definitely
> > not encouraged to use it ATM. v1.4 and v1.6 are the currently
> > supported stable branches. v1.4 builds and works with linux v4.6. v1.6
> > builds with linux v5.5 but still works with v4.6 unless the user calls
> > new functions (set_config, bias flags, etc.) where it will fail at
> > run-time but older user programs can still link against it.
> >
> > Let me know if I'm missing something but I really prefer to avoid an
> > ifdef hell and QA mess with supporting earlier kernels with v2.0.
>
> I think as long as there's really a 1.x series that is entirely API
> compatible, and then another 2.x series that is entirely API
> compatible, but different than 1.x, then it's fine indeed.
>
> We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are
> guaranteed to offer the same API to users of the libraries.
>

Unless the users use symbols that only first appeared in v1.6. v1.4 is
compatible with v1.6 (v1.6 doesn't change/remove any symbols), not the
other way around (v1.6 added new symbols).

> And once libgpiod2 is out, we'll have a separate libgpiod2.mk.
>
> Would that work ?
>

I think so. Just please note that SONAME of libgpiod right now is
libgpiod.so.2 because of an ABI change early in the development. So
SONAME for libgpiod2 will actually be libgpiod.so.3 - nothing we can
do about it I'm afraid. I'll surely guarantee ABI and API stability
over all minor releases of v2.x series.

> If so, then it's fine for me.
>
> Thanks for explaining your strategy. It's great to have upstream
> directly on-board in these discussions!
>

Sure! One thing I forgot to mention: I actually consider writing a
compatibility layer for libgpiod - a one that would allow users to
link against the compatibility library as if they were using libgpiod
v1.x but it would actually translate the calls to libgpiod v2.x.
Something that libusb did.

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Thomas Petazzoni]

On Fri, 30 Oct 2020 10:25:37 +0100
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> > We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are
> > guaranteed to offer the same API to users of the libraries.
> >  
> 
> Unless the users use symbols that only first appeared in v1.6. v1.4 is
> compatible with v1.6 (v1.6 doesn't change/remove any symbols), not the
> other way around (v1.6 added new symbols).

Well, that is an issue. An application that builds with 1.6 may not
build with 1.4, so they are not compatible API-wise, and therefore
having libgpiod.mk fall back to 1.4 automatically when the kernel
headers are too old is going to potentially break applications that use
1.6-specific APIs.

> I think so. Just please note that SONAME of libgpiod right now is
> libgpiod.so.2 because of an ABI change early in the development. So
> SONAME for libgpiod2 will actually be libgpiod.so.3 - nothing we can
> do about it I'm afraid. I'll surely guarantee ABI and API stability
> over all minor releases of v2.x series.

That is fine.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Fri, Oct 30, 2020 at 10:34 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Fri, 30 Oct 2020 10:25:37 +0100
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > > We can use the 1.4/1.6 conditional in libgpiod.mk, as 1.4 and 1.6 are
> > > guaranteed to offer the same API to users of the libraries.
> > >
> >
> > Unless the users use symbols that only first appeared in v1.6. v1.4 is
> > compatible with v1.6 (v1.6 doesn't change/remove any symbols), not the
> > other way around (v1.6 added new symbols).
>
> Well, that is an issue. An application that builds with 1.6 may not
> build with 1.4, so they are not compatible API-wise, and therefore
> having libgpiod.mk fall back to 1.4 automatically when the kernel
> headers are too old is going to potentially break applications that use
> 1.6-specific APIs.
>

Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
scheme. Major releases break API. Minor releases don't break API but
(may) introduce new features. Bugfix releases don't change API. I
think this is the standard for most libraries. So far no buildroot
package even depends on libgpiod so this could only affect out-of-tree
users. I'm not sure what the policy here is @buildroot though.

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Thomas Petazzoni]

On Fri, 30 Oct 2020 11:16:04 +0100
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> > Well, that is an issue. An application that builds with 1.6 may not
> > build with 1.4, so they are not compatible API-wise, and therefore
> > having libgpiod.mk fall back to 1.4 automatically when the kernel
> > headers are too old is going to potentially break applications that use
> > 1.6-specific APIs.
> 
> Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
> scheme. Major releases break API. Minor releases don't break API but
> (may) introduce new features. Bugfix releases don't change API. I
> think this is the standard for most libraries. So far no buildroot
> package even depends on libgpiod so this could only affect out-of-tree
> users. I'm not sure what the policy here is @buildroot though.

This is perfectly OK. Where it clashes is when a new MAJOR.MINOR
release drops support for kernels older than 5.5, which is a
super-recent kernel version. This prevents from simply updating to the
latest 1.6 release in all situations, causing a compatibility problem
that is quite annoying to handle.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Fri, 30 Oct 2020 11:16:04 +0100
> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > > Well, that is an issue. An application that builds with 1.6 may not
> > > build with 1.4, so they are not compatible API-wise, and therefore
> > > having libgpiod.mk fall back to 1.4 automatically when the kernel
> > > headers are too old is going to potentially break applications that use
> > > 1.6-specific APIs.
> >
> > Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
> > scheme. Major releases break API. Minor releases don't break API but
> > (may) introduce new features. Bugfix releases don't change API. I
> > think this is the standard for most libraries. So far no buildroot
> > package even depends on libgpiod so this could only affect out-of-tree
> > users. I'm not sure what the policy here is @buildroot though.
>
> This is perfectly OK. Where it clashes is when a new MAJOR.MINOR
> release drops support for kernels older than 5.5, which is a
> super-recent kernel version. This prevents from simply updating to the
> latest 1.6 release in all situations, causing a compatibility problem
> that is quite annoying to handle.
>

In that case I would advise to keep v1.4 exclusively in buildroot -
just like we do in meta-openembedded.

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Arnout Vandecappelle]

On 30/10/2020 11:53, Bartosz Golaszewski wrote:
> On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>>
>> On Fri, 30 Oct 2020 11:16:04 +0100
>> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>>>> Well, that is an issue. An application that builds with 1.6 may not
>>>> build with 1.4, so they are not compatible API-wise, and therefore
>>>> having libgpiod.mk fall back to 1.4 automatically when the kernel
>>>> headers are too old is going to potentially break applications that use
>>>> 1.6-specific APIs.
>>>
>>> Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
>>> scheme. Major releases break API. Minor releases don't break API but
>>> (may) introduce new features. Bugfix releases don't change API. I
>>> think this is the standard for most libraries. So far no buildroot
>>> package even depends on libgpiod so this could only affect out-of-tree
>>> users. I'm not sure what the policy here is @buildroot though.
>>
>> This is perfectly OK. Where it clashes is when a new MAJOR.MINOR
>> release drops support for kernels older than 5.5, which is a
>> super-recent kernel version. This prevents from simply updating to the
>> latest 1.6 release in all situations, causing a compatibility problem
>> that is quite annoying to handle.
>>
> 
> In that case I would advise to keep v1.4 exclusively in buildroot -
> just like we do in meta-openembedded.

 But that brings us back to the other problem: any package that relies on the
new API in 1.6 can't be built.

 I think the only *real* solution for that is to introduce a libgpiod16 package
if people actually start to use the new APIs. But then we probably end up with
two copies of libgpiod (1.4 and 1.6) because some packages use don't require the
new APIs...

 So, this reliance on 5.5 kernel headers is really putting limitations to your
downstream users.


 Regards,
 Arnout

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Tue, Nov 3, 2020 at 9:25 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
>
> On 30/10/2020 11:53, Bartosz Golaszewski wrote:
> > On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> >>
> >> On Fri, 30 Oct 2020 11:16:04 +0100
> >> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>
> >>>> Well, that is an issue. An application that builds with 1.6 may not
> >>>> build with 1.4, so they are not compatible API-wise, and therefore
> >>>> having libgpiod.mk fall back to 1.4 automatically when the kernel
> >>>> headers are too old is going to potentially break applications that use
> >>>> 1.6-specific APIs.
> >>>
> >>> Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
> >>> scheme. Major releases break API. Minor releases don't break API but
> >>> (may) introduce new features. Bugfix releases don't change API. I
> >>> think this is the standard for most libraries. So far no buildroot
> >>> package even depends on libgpiod so this could only affect out-of-tree
> >>> users. I'm not sure what the policy here is @buildroot though.
> >>
> >> This is perfectly OK. Where it clashes is when a new MAJOR.MINOR
> >> release drops support for kernels older than 5.5, which is a
> >> super-recent kernel version. This prevents from simply updating to the
> >> latest 1.6 release in all situations, causing a compatibility problem
> >> that is quite annoying to handle.
> >>
> >
> > In that case I would advise to keep v1.4 exclusively in buildroot -
> > just like we do in meta-openembedded.
>
>  But that brings us back to the other problem: any package that relies on the
> new API in 1.6 can't be built.
>
>  I think the only *real* solution for that is to introduce a libgpiod16 package
> if people actually start to use the new APIs. But then we probably end up with
> two copies of libgpiod (1.4 and 1.6) because some packages use don't require the
> new APIs...
>
>  So, this reliance on 5.5 kernel headers is really putting limitations to your
> downstream users.
>

I understand. I will see about downgrading this requirement in the
v1.6.x branch then. Don't introduce this package split just yet.

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Tue, Nov 3, 2020 at 9:56 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Tue, Nov 3, 2020 at 9:25 PM Arnout Vandecappelle <arnout@mind.be> wrote:
> >
> >
> >
> > On 30/10/2020 11:53, Bartosz Golaszewski wrote:
> > > On Fri, Oct 30, 2020 at 11:41 AM Thomas Petazzoni
> > > <thomas.petazzoni@bootlin.com> wrote:
> > >>
> > >> On Fri, 30 Oct 2020 11:16:04 +0100
> > >> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >>
> > >>>> Well, that is an issue. An application that builds with 1.6 may not
> > >>>> build with 1.4, so they are not compatible API-wise, and therefore
> > >>>> having libgpiod.mk fall back to 1.4 automatically when the kernel
> > >>>> headers are too old is going to potentially break applications that use
> > >>>> 1.6-specific APIs.
> > >>>
> > >>> Versioning of libgpiod just follows the regular MAJOR.MINOR.BUGFIX
> > >>> scheme. Major releases break API. Minor releases don't break API but
> > >>> (may) introduce new features. Bugfix releases don't change API. I
> > >>> think this is the standard for most libraries. So far no buildroot
> > >>> package even depends on libgpiod so this could only affect out-of-tree
> > >>> users. I'm not sure what the policy here is @buildroot though.
> > >>
> > >> This is perfectly OK. Where it clashes is when a new MAJOR.MINOR
> > >> release drops support for kernels older than 5.5, which is a
> > >> super-recent kernel version. This prevents from simply updating to the
> > >> latest 1.6 release in all situations, causing a compatibility problem
> > >> that is quite annoying to handle.
> > >>
> > >
> > > In that case I would advise to keep v1.4 exclusively in buildroot -
> > > just like we do in meta-openembedded.
> >
> >  But that brings us back to the other problem: any package that relies on the
> > new API in 1.6 can't be built.
> >
> >  I think the only *real* solution for that is to introduce a libgpiod16 package
> > if people actually start to use the new APIs. But then we probably end up with
> > two copies of libgpiod (1.4 and 1.6) because some packages use don't require the
> > new APIs...
> >
> >  So, this reliance on 5.5 kernel headers is really putting limitations to your
> > downstream users.
> >
>
> I understand. I will see about downgrading this requirement in the
> v1.6.x branch then. Don't introduce this package split just yet.
>
> Bartosz

Thomas,

I made a new release that redefines needed symbols if building on
linux pre v5.5. I'm wondering though: what is the correct approach for
C libraries if certain kernel uAPI symbols are missing? Redefine them
or just live with ifdefs in the code?

Bartosz

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Nicolas Cavallari]

On 30/11/2020 21:31, Bartosz Golaszewski wrote:
> Thomas,
> 
> I made a new release that redefines needed symbols if building on
> linux pre v5.5. I'm wondering though: what is the correct approach for
> C libraries if certain kernel uAPI symbols are missing? Redefine them
> or just live with ifdefs in the code?

Include a copy of the latest uapi headers that you use directly in your 
source tree.

At least, this is what libnl, iproute2, iw, hostapd and wpa_supplicant do.

[Buildroot] [PATCH] package/libgpiod: bump version to 1.6

[Bartosz Golaszewski]

On Fri, Oct 30, 2020 at 8:53 AM Michael Nosthoff <buildroot@heine.tech> wrote:
>
> Hi,
>
> On Thursday, October 29, 2020 14:41 CET, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> >
> > v2.0 of libgpiod will no longer support older kernels but I'll support
> > v1.6 indefinitely for older kernels and v1.4 as long as v5.4 is
> > supported.
>
> Will 1.4.x still work with 5.10 kernels? I guess the old API will just be deprecated for a while?
>

Yes! Newer kernels won't break older versions of the library.

> So I guess we have two possibilities going forward:
>
> - Use the version switch I proposed and even extend it when 2.0 and headers 5.10 are released
> or
> - Stay on the 1.4.x branch until linux 5.5 is the oldest supported version (if this is possible).
>
> Regards,
> Michael
>

I'd say: stay on v1.4.x branch until the end of v5.4 LTS and then
introduce v2.0 as soon as it's available just like there's
gstreamer(0) and gstreamer1.0.

Bartosz

[Buildroot] [PATCH v2] package/libgpiod: bump version to 1.4.5

[Michael Nosthoff]

* add a comment about the kernel header dependencies when bumping
versions
* use two spaces in hash-file

Signed-off-by: Michael Nosthoff <buildroot@heine.tech>

---

v1 -> v2:
  * stay on the 1.4.x branch in all cases
  * further bump 1.4.4 to 1.4.5
---
 package/libgpiod/Config.in     | 2 +-
 package/libgpiod/libgpiod.hash | 4 ++--
 package/libgpiod/libgpiod.mk   | 4 +++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/package/libgpiod/Config.in b/package/libgpiod/Config.in
index 63a7cb6e78..293eef6c89 100644
--- a/package/libgpiod/Config.in
+++ b/package/libgpiod/Config.in
@@ -5,7 +5,7 @@ config BR2_PACKAGE_LIBGPIOD
 	  This is a C library that abstracts the GPIO character
 	  device operations on linux.
 
-	  https://github.com/brgl/libgpiod
+	  https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
 
 if BR2_PACKAGE_LIBGPIOD
 
diff --git a/package/libgpiod/libgpiod.hash b/package/libgpiod/libgpiod.hash
index f0009a7510..0ccb3bef5a 100644
--- a/package/libgpiod/libgpiod.hash
+++ b/package/libgpiod/libgpiod.hash
@@ -1,4 +1,4 @@
 # From https://www.kernel.org/pub/software/libs/libgpiod/sha256sums.asc
-sha256 21ae8fd1f8dafc2eb2ba50e652390cf533d21351419a7426255895cb52e21b1c  libgpiod-1.4.1.tar.xz
+sha256  af5950cefb157e34f8e1485b82ab98873d53eeff2d1166faec483b8ebc1a3cff  libgpiod-1.4.5.tar.xz
 # Hash for license file
-sha256 ce64d5f7b49ea6d80fdb6d4cdee6839d1a94274f7493dc797c3b55b65ec8e9ed  COPYING
+sha256  ce64d5f7b49ea6d80fdb6d4cdee6839d1a94274f7493dc797c3b55b65ec8e9ed  COPYING
diff --git a/package/libgpiod/libgpiod.mk b/package/libgpiod/libgpiod.mk
index 2474ab90a2..83d5abb002 100644
--- a/package/libgpiod/libgpiod.mk
+++ b/package/libgpiod/libgpiod.mk
@@ -4,7 +4,9 @@
 #
 ################################################################################
 
-LIBGPIOD_VERSION = 1.4.1
+# be careful when bumping versions, newer branches (e.g. >= 1.6)
+# depend on pretty recent kernel headers
+LIBGPIOD_VERSION = 1.4.5
 LIBGPIOD_SOURCE = libgpiod-$(LIBGPIOD_VERSION).tar.xz
 LIBGPIOD_SITE = https://www.kernel.org/pub/software/libs/libgpiod
 LIBGPIOD_LICENSE = LGPL-2.1+
-- 
2.25.1

[Buildroot] [PATCH v3] package/libgpiod: bump version to 1.4.5

[Michael Nosthoff]

* add a comment about the kernel header dependencies when bumping
versions
* set url to kernel.org as github is unmaintained and outdated
* use two spaces in hash-file

Signed-off-by: Michael Nosthoff <buildroot@heine.tech>

---
v2 -> v3:
  * use correct hash
  * add comment about url

v1 -> v2:
  * stay on the 1.4.x branch in all cases
  * further bump 1.4.4 to 1.4.5
---
 package/libgpiod/Config.in     | 2 +-
 package/libgpiod/libgpiod.hash | 4 ++--
 package/libgpiod/libgpiod.mk   | 4 +++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/package/libgpiod/Config.in b/package/libgpiod/Config.in
index 63a7cb6e78..293eef6c89 100644
--- a/package/libgpiod/Config.in
+++ b/package/libgpiod/Config.in
@@ -5,7 +5,7 @@ config BR2_PACKAGE_LIBGPIOD
 	  This is a C library that abstracts the GPIO character
 	  device operations on linux.
 
-	  https://github.com/brgl/libgpiod
+	  https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
 
 if BR2_PACKAGE_LIBGPIOD
 
diff --git a/package/libgpiod/libgpiod.hash b/package/libgpiod/libgpiod.hash
index f0009a7510..0ea15869b0 100644
--- a/package/libgpiod/libgpiod.hash
+++ b/package/libgpiod/libgpiod.hash
@@ -1,4 +1,4 @@
 # From https://www.kernel.org/pub/software/libs/libgpiod/sha256sums.asc
-sha256 21ae8fd1f8dafc2eb2ba50e652390cf533d21351419a7426255895cb52e21b1c  libgpiod-1.4.1.tar.xz
+sha256  a041b06907c956dd1c77836cccf4d392af29b9fe09c8ad18449a6da707b5ba2d  libgpiod-1.4.5.tar.xz
 # Hash for license file
-sha256 ce64d5f7b49ea6d80fdb6d4cdee6839d1a94274f7493dc797c3b55b65ec8e9ed  COPYING
+sha256  ce64d5f7b49ea6d80fdb6d4cdee6839d1a94274f7493dc797c3b55b65ec8e9ed  COPYING
diff --git a/package/libgpiod/libgpiod.mk b/package/libgpiod/libgpiod.mk
index 2474ab90a2..83d5abb002 100644
--- a/package/libgpiod/libgpiod.mk
+++ b/package/libgpiod/libgpiod.mk
@@ -4,7 +4,9 @@
 #
 ################################################################################
 
-LIBGPIOD_VERSION = 1.4.1
+# be careful when bumping versions, newer branches (e.g. >= 1.6)
+# depend on pretty recent kernel headers
+LIBGPIOD_VERSION = 1.4.5
 LIBGPIOD_SOURCE = libgpiod-$(LIBGPIOD_VERSION).tar.xz
 LIBGPIOD_SITE = https://www.kernel.org/pub/software/libs/libgpiod
 LIBGPIOD_LICENSE = LGPL-2.1+
-- 
2.25.1