[ANNOUNCE] libgpiod v1.6 released

[ANNOUNCE] libgpiod v1.6 released

[Bartosz Golaszewski]

I'm announcing the release of libgpiod v1.6. This is the last release
in the v1.x series. New, improved version of the GPIO uAPI is now in
linux-next queued for v5.10. It introduces many new features which we
won't be able to support with the current library API (and we also
have several reworks defined in TODO that'll also require breaking
compatibility) so my plans going forward are as follows:

1. Switch the major version of libgpiod API to 2 and start working on
the new API (preferably starting out by simply porting the current
library to v2 uAPI).
2. Indefinitely support v1.6.x branch with bug fixes.
3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
kernel as their LTS (this is because v1.4 is the last version to not
require v5.5 kernel headers to build).
4. (maybe) Create a compatibility layer between v1.x and v2.x once
v2.0 is out that will ease the switch to the new release.

There are no big new features in this release, mostly improvements and
bug-fixes. The details are in NEWS.

Grab tarballs from:
    https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/

Grab source from:
    git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git

Re: [ANNOUNCE] libgpiod v1.6 released

[Andy Shevchenko]

On Thu, Oct 1, 2020 at 3:20 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> I'm announcing the release of libgpiod v1.6. This is the last release
> in the v1.x series. New, improved version of the GPIO uAPI is now in
> linux-next queued for v5.10.

Good news!

> It introduces many new features which we
> won't be able to support with the current library API (and we also
> have several reworks defined in TODO that'll also require breaking
> compatibility) so my plans going forward are as follows:
>
> 1. Switch the major version of libgpiod API to 2 and start working on
> the new API (preferably starting out by simply porting the current
> library to v2 uAPI).
> 2. Indefinitely support v1.6.x branch with bug fixes.
> 3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
> kernel as their LTS (this is because v1.4 is the last version to not
> require v5.5 kernel headers to build).
> 4. (maybe) Create a compatibility layer between v1.x and v2.x once
> v2.0 is out that will ease the switch to the new release.

I'm wondering if you are planning to develop v2.x with possibility to
coexist with v1 on the same machine (like gtk2 / gtk3 and other
examples).

> There are no big new features in this release, mostly improvements and
> bug-fixes. The details are in NEWS.
>
> Grab tarballs from:
>     https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/
>
> Grab source from:
>     git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git



-- 
With Best Regards,
Andy Shevchenko

Re: [ANNOUNCE] libgpiod v1.6 released

[Bartosz Golaszewski]

On Thu, Oct 1, 2020 at 4:56 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>

[snip]

> >
> > 1. Switch the major version of libgpiod API to 2 and start working on
> > the new API (preferably starting out by simply porting the current
> > library to v2 uAPI).
> > 2. Indefinitely support v1.6.x branch with bug fixes.
> > 3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
> > kernel as their LTS (this is because v1.4 is the last version to not
> > require v5.5 kernel headers to build).
> > 4. (maybe) Create a compatibility layer between v1.x and v2.x once
> > v2.0 is out that will ease the switch to the new release.
>
> I'm wondering if you are planning to develop v2.x with possibility to
> coexist with v1 on the same machine (like gtk2 / gtk3 and other
> examples).
>

Personally I would prefer to avoid doing this. This isn't a very big
library so unlike gstreamer or gtk I think it won't take much to
switch to v2.0. If anything - I prefer a compatibility layer included
in the package where - if an option is passed to configure - the old
header would be installed alongside the v2.0 .so file + another .so
for translating the calls.

If you see a very good reason to make them both live together - let me know.

Bart

[snip]

Re: [ANNOUNCE] libgpiod v1.6 released

[Geert Uytterhoeven]

Hi Bartosz,

On Thu, Oct 1, 2020 at 2:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> I'm announcing the release of libgpiod v1.6. This is the last release
> in the v1.x series. New, improved version of the GPIO uAPI is now in
> linux-next queued for v5.10. It introduces many new features which we
> won't be able to support with the current library API (and we also
> have several reworks defined in TODO that'll also require breaking
> compatibility) so my plans going forward are as follows:

Nice!

> Grab source from:
>     git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git

Note that the first Google hit for "libgpiod v1.6" is your github mirror, which
has the latest code, but not the latest tags?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [ANNOUNCE] libgpiod v1.6 released

[Bartosz Golaszewski]

On Fri, Oct 2, 2020 at 11:07 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>

[snip]

>
> > Grab source from:
> >     git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git
>
> Note that the first Google hit for "libgpiod v1.6" is your github mirror, which
> has the latest code, but not the latest tags?
>

Ugh github has better SEO than kernel.org. Yeah I don't push tags
there - I'm using this repo for backup mostly and for my development
branches. I think I'll just make it private - or maybe make this one
read-only and then create a new private one for my dev stuff.

Thanks for the heads up.

Bartosz

Re: [ANNOUNCE] libgpiod v1.6 released

[Andy Shevchenko]

On Fri, Oct 2, 2020 at 10:25 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Thu, Oct 1, 2020 at 4:56 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:

> > > 1. Switch the major version of libgpiod API to 2 and start working on
> > > the new API (preferably starting out by simply porting the current
> > > library to v2 uAPI).
> > > 2. Indefinitely support v1.6.x branch with bug fixes.
> > > 3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
> > > kernel as their LTS (this is because v1.4 is the last version to not
> > > require v5.5 kernel headers to build).
> > > 4. (maybe) Create a compatibility layer between v1.x and v2.x once
> > > v2.0 is out that will ease the switch to the new release.
> >
> > I'm wondering if you are planning to develop v2.x with possibility to
> > coexist with v1 on the same machine (like gtk2 / gtk3 and other
> > examples).
> >
>
> Personally I would prefer to avoid doing this. This isn't a very big
> library so unlike gstreamer or gtk I think it won't take much to
> switch to v2.0. If anything - I prefer a compatibility layer included
> in the package where - if an option is passed to configure - the old
> header would be installed alongside the v2.0 .so file + another .so
> for translating the calls.
>
> If you see a very good reason to make them both live together - let me know.

Aspects that come to my mind, that needs to be taken into account are
the following:
 - would ABI be kept on a library level (will binary built against v1
be capable to run on v2)?
 - would API be kept compatible (seems so according to Kent's patch)?

Main point that users that have compiled something for older kernel to
work should be able to run this on newer distribution environments
(like one, that would have only v2 of the library).

-- 
With Best Regards,
Andy Shevchenko

Re: [ANNOUNCE] libgpiod v1.6 released

[Bartosz Golaszewski]

On Fri, Oct 2, 2020 at 4:48 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Fri, Oct 2, 2020 at 10:25 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Thu, Oct 1, 2020 at 4:56 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
>
> > > > 1. Switch the major version of libgpiod API to 2 and start working on
> > > > the new API (preferably starting out by simply porting the current
> > > > library to v2 uAPI).
> > > > 2. Indefinitely support v1.6.x branch with bug fixes.
> > > > 3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
> > > > kernel as their LTS (this is because v1.4 is the last version to not
> > > > require v5.5 kernel headers to build).
> > > > 4. (maybe) Create a compatibility layer between v1.x and v2.x once
> > > > v2.0 is out that will ease the switch to the new release.
> > >
> > > I'm wondering if you are planning to develop v2.x with possibility to
> > > coexist with v1 on the same machine (like gtk2 / gtk3 and other
> > > examples).
> > >
> >
> > Personally I would prefer to avoid doing this. This isn't a very big
> > library so unlike gstreamer or gtk I think it won't take much to
> > switch to v2.0. If anything - I prefer a compatibility layer included
> > in the package where - if an option is passed to configure - the old
> > header would be installed alongside the v2.0 .so file + another .so
> > for translating the calls.
> >
> > If you see a very good reason to make them both live together - let me know.
>
> Aspects that come to my mind, that needs to be taken into account are
> the following:
>  - would ABI be kept on a library level (will binary built against v1
> be capable to run on v2)?

No, of course it won't be kept. This is the whole point of a new major release.

>  - would API be kept compatible (seems so according to Kent's patch)?
>

Same as above. The new major release will need a new API to support
new functionalities introduced by Kent.

> Main point that users that have compiled something for older kernel to
> work should be able to run this on newer distribution environments
> (like one, that would have only v2 of the library).
>

This has nothing to do with the kernel - nobody is changing the kernel
API v1 and it'll be supported by libgpiod v1.6.

In user-space, libraries only guarantee binary compatibility in
respect to the major ABI version. We've already changed the ABI in
libgpiod twice (it's at 2.x.y currently).

I personally don't care much about how desktop distros handle this -
I'm mostly interested in bespoke embedded distros built with yocto or
buildroot. I'm Cc'ing SZ Lin who maintains the libgpiod debian
package.

SZ Lin: libgpiod will get a new major release in the following months
- the API will become v2.x and ABI v3.x - do you think it's important
to make it possible for two major versions of libgpiod to live
together in a single system? I would like to avoid having to rename
everything and use libgpiod2.0 everywhere - this information is
already stored in the API version. Does debian support something like
yocto's virtual providers maybe? How do you see this for a desktop
distro.

Best regards,
Bartosz Golaszewski

RE: [ANNOUNCE] libgpiod v1.6 released

[SZ Lin (林上智)]

Hi,

<snip>

> I personally don't care much about how desktop distros handle this - I'm mostly
> interested in bespoke embedded distros built with yocto or buildroot. I'm Cc'ing
> SZ Lin who maintains the libgpiod debian package.

Nowadays, many embedded distros are derived from Debian, such as Raspberry Pi OS
(previously called Raspbian). Moreover, the meta-debian [1] provides the recipes for the
Poky build system to build images using Debian source packages within the Yocto project [2].

[1] https://github.com/meta-debian/meta-debian
[2] https://www.yoctoproject.org/learn-items/deby-reproducible-and-maintainable-embedded-linux-environment-with-poky/

> 
> SZ Lin: libgpiod will get a new major release in the following months
> - the API will become v2.x and ABI v3.x - do you think it's important to make it
> possible for two major versions of libgpiod to live together in a single system? I

It's possible, but I think it's *no strongly needed* and there are no other Debian 
packages depend on libgpiod, as shown below.

===
apt rdepends libgpiod2
libgpiod2
Reverse Depends:
  Depends: libgpiod-dev (= 1.5.2-1)
  Depends: python3-libgpiod (= 1.5.2-1)
  Depends: gpiod (>= 1.5.1)
===

All of the above binary packages are built from the same (libgpiod) source package.

> would like to avoid having to rename everything and use libgpiod2.0
> everywhere - this information is already stored in the API version. Does debian
> support something like yocto's virtual providers maybe? How do you see this for
> a desktop distro.

I'm not familiar with Yocto's mechanism, but in this case, the ABI changes seem that
are not backward-compatible; we normally require changing the SONAME of the library
and the shared library package name.

SZ

> 
> Best regards,
> Bartosz Golaszewski

Re: [ANNOUNCE] libgpiod v1.6 released

[Bartosz Golaszewski]

On Mon, Oct 12, 2020 at 5:18 PM SZ Lin (林上智) <SZ.Lin@moxa.com> wrote:
>
> Hi,
>
> <snip>
>
> > I personally don't care much about how desktop distros handle this - I'm mostly
> > interested in bespoke embedded distros built with yocto or buildroot. I'm Cc'ing
> > SZ Lin who maintains the libgpiod debian package.
>
> Nowadays, many embedded distros are derived from Debian, such as Raspberry Pi OS
> (previously called Raspbian). Moreover, the meta-debian [1] provides the recipes for the
> Poky build system to build images using Debian source packages within the Yocto project [2].
>
> [1] https://github.com/meta-debian/meta-debian
> [2] https://www.yoctoproject.org/learn-items/deby-reproducible-and-maintainable-embedded-linux-environment-with-poky/
>
> >
> > SZ Lin: libgpiod will get a new major release in the following months
> > - the API will become v2.x and ABI v3.x - do you think it's important to make it
> > possible for two major versions of libgpiod to live together in a single system? I
>
> It's possible, but I think it's *no strongly needed* and there are no other Debian
> packages depend on libgpiod, as shown below.
>
> ===
> apt rdepends libgpiod2
> libgpiod2
> Reverse Depends:
>   Depends: libgpiod-dev (= 1.5.2-1)
>   Depends: python3-libgpiod (= 1.5.2-1)
>   Depends: gpiod (>= 1.5.1)
> ===
>
> All of the above binary packages are built from the same (libgpiod) source package.
>
> > would like to avoid having to rename everything and use libgpiod2.0
> > everywhere - this information is already stored in the API version. Does debian
> > support something like yocto's virtual providers maybe? How do you see this for
> > a desktop distro.
>
> I'm not familiar with Yocto's mechanism, but in this case, the ABI changes seem that
> are not backward-compatible; we normally require changing the SONAME of the library
> and the shared library package name.
>

For the SONAME it's clear: current libgpiod.so.2 will become
libgpiod.so.3. For the library package name: this is already handled
by distros - for instance the package in debian is called libgpiod2. I
guess it will become libgpiod3 then. I think we're good in that regard
then.

Bartosz

RE: [ANNOUNCE] libgpiod v1.6 released

[SZ Lin (林上智)]

Hi,

> From: Bartosz Golaszewski <brgl@bgdev.pl>
> 
> On Mon, Oct 12, 2020 at 5:18 PM SZ Lin (林上智) <SZ.Lin@moxa.com> wrote:
> >
> > Hi,
> >
> > <snip>
> >
> > > I personally don't care much about how desktop distros handle this -
> > > I'm mostly interested in bespoke embedded distros built with yocto
> > > or buildroot. I'm Cc'ing SZ Lin who maintains the libgpiod debian package.
> >
> > Nowadays, many embedded distros are derived from Debian, such as
> > Raspberry Pi OS (previously called Raspbian). Moreover, the
> > meta-debian [1] provides the recipes for the Poky build system to build images
> using Debian source packages within the Yocto project [2].
> >
> > [1] https://github.com/meta-debian/meta-debian
> > [2]
> > https://www.yoctoproject.org/learn-items/deby-reproducible-and-maintai
> > nable-embedded-linux-environment-with-poky/
> >
> > >
> > > SZ Lin: libgpiod will get a new major release in the following
> > > months
> > > - the API will become v2.x and ABI v3.x - do you think it's
> > > important to make it possible for two major versions of libgpiod to
> > > live together in a single system? I
> >
> > It's possible, but I think it's *no strongly needed* and there are no
> > other Debian packages depend on libgpiod, as shown below.
> >
> > ===
> > apt rdepends libgpiod2
> > libgpiod2
> > Reverse Depends:
> >   Depends: libgpiod-dev (= 1.5.2-1)
> >   Depends: python3-libgpiod (= 1.5.2-1)
> >   Depends: gpiod (>= 1.5.1)
> > ===
> >
> > All of the above binary packages are built from the same (libgpiod) source
> package.
> >
> > > would like to avoid having to rename everything and use libgpiod2.0
> > > everywhere - this information is already stored in the API version.
> > > Does debian support something like yocto's virtual providers maybe?
> > > How do you see this for a desktop distro.
> >
> > I'm not familiar with Yocto's mechanism, but in this case, the ABI
> > changes seem that are not backward-compatible; we normally require
> > changing the SONAME of the library and the shared library package name.
> >
> 
> For the SONAME it's clear: current libgpiod.so.2 will become libgpiod.so.3. For
> the library package name: this is already handled by distros - for instance the
> package in debian is called libgpiod2. I guess it will become libgpiod3 then. I
> think we're good in that regard then.

Exactly, we're on the same page.

SZ

> 
> Bartosz