| Message ID | 20230208152541.136848-1-brgl@bgdev.pl |
|---|---|
| Headers | show |
| Series | libgpiod: add support for libgpiod v2 | expand |
Hi, Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > We've just tagged the release candidate for libgpiod v2. This is a major > release entirely overhauling the API in a backward incompatible way. Thanks for creating this! > While this is not the final release yet, it's not likely to change much so > I'd like to make it available in meta-openembedded to give it exposure to > some testing. When we do release v2.0, it'll be just a matter of bumping the > version. > > Currently no other package depends on libgpiod in meta-openembedded, so I'd > like to avoid having two packages (libgpiod and libgpiod2). Instead let's > provide recipes for both versions but keep them under the common libgpiod name > as it's unlikely anyone would need both versions in a single system. This is > after all a medium-sized project that shouldn't require too much work in order > to port a user to the new major release. Nevertheless there may be packages in other layers using it (meta-acpi, meta-intel-edison). I think there will be a period where both may need to coexist. > The first patch contains an update of libgpiod v1.6.x to the most recent > bug-fix release. > > The second contains the recipe for libgpiod v2.0-rc1 while also moving the > bitbake code around in order to factor out common elements. > > The third contains a recipe for the python bindings that are now in their own > project in meta-python. > > The new recipes provide the same functionality - including ptest for the C > library, tools and language bindings. > > Bartosz Golaszewski (3): > libgpiod: update to v1.6.4 > libgpiod: add a recipe for libgpiod v2.0-rc1 > python3-gpiod: new package > > ...-don-t-expect-automake-to-set-PYTHON.patch | 37 --------- > .../{files => libgpiod-1.6.4}/run-ptest | 0 > .../libgpiod/libgpiod-2.0-rc1/run-ptest | 24 ++++++ > .../recipes-support/libgpiod/libgpiod-src.inc | 1 + > meta-oe/recipes-support/libgpiod/libgpiod.inc | 61 ++++++++++++++ > .../libgpiod/libgpiod_1.6.3.bb | 82 ------------------- > .../libgpiod/libgpiod_1.6.4.bb | 37 +++++++++ > .../libgpiod/libgpiod_2.0-rc1.bb | 21 +++++ > .../packagegroups/packagegroup-meta-python.bb | 1 + > .../python/python3-gpiod/run-ptest | 15 ++++ > .../python/python3-gpiod_2.0-rc1.bb | 45 ++++++++++ > 11 files changed, 205 insertions(+), 119 deletions(-) > delete mode 100644 meta-oe/recipes-support/libgpiod/files/0001-build-don-t-expect-automake-to-set-PYTHON.patch > rename meta-oe/recipes-support/libgpiod/{files => libgpiod-1.6.4}/run-ptest (100%) > create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod-2.0-rc1/run-ptest > create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod-src.inc > create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod.inc > delete mode 100644 meta-oe/recipes-support/libgpiod/libgpiod_1.6.3.bb > create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod_1.6.4.bb > create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod_2.0-rc1.bb > create mode 100644 meta-python/recipes-devtools/python/python3-gpiod/run-ptest > create mode 100644 meta-python/recipes-devtools/python/python3-gpiod_2.0-rc1.bb > > > > >
On Thu, Feb 9, 2023 at 8:26 PM Ferry Toth <fntoth@gmail.com> wrote: > > Hi, > > Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > We've just tagged the release candidate for libgpiod v2. This is a major > > release entirely overhauling the API in a backward incompatible way. > > Thanks for creating this! > > > While this is not the final release yet, it's not likely to change much so > > I'd like to make it available in meta-openembedded to give it exposure to > > some testing. When we do release v2.0, it'll be just a matter of bumping the > > version. > > > > Currently no other package depends on libgpiod in meta-openembedded, so I'd > > like to avoid having two packages (libgpiod and libgpiod2). Instead let's > > provide recipes for both versions but keep them under the common libgpiod name > > as it's unlikely anyone would need both versions in a single system. This is > > after all a medium-sized project that shouldn't require too much work in order > > to port a user to the new major release. > > Nevertheless there may be packages in other layers using it (meta-acpi, > meta-intel-edison). I think there will be a period where both may need > to coexist. > Can those layers just set the PREFERRED_VERSION? Bart
Op 09-02-2023 om 20:57 schreef Bartosz Golaszewski: > On Thu, Feb 9, 2023 at 8:26 PM Ferry Toth <fntoth@gmail.com> wrote: >> >> Hi, >> >> Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>> >>> We've just tagged the release candidate for libgpiod v2. This is a major >>> release entirely overhauling the API in a backward incompatible way. >> >> Thanks for creating this! >> >>> While this is not the final release yet, it's not likely to change much so >>> I'd like to make it available in meta-openembedded to give it exposure to >>> some testing. When we do release v2.0, it'll be just a matter of bumping the >>> version. >>> >>> Currently no other package depends on libgpiod in meta-openembedded, so I'd >>> like to avoid having two packages (libgpiod and libgpiod2). Instead let's >>> provide recipes for both versions but keep them under the common libgpiod name >>> as it's unlikely anyone would need both versions in a single system. This is >>> after all a medium-sized project that shouldn't require too much work in order >>> to port a user to the new major release. >> >> Nevertheless there may be packages in other layers using it (meta-acpi, >> meta-intel-edison). I think there will be a period where both may need >> to coexist. >> > > Can those layers just set the PREFERRED_VERSION? Yes, but it doesn't the problem when one app needs v1 and the other needs v2. > Bart > > > > >
On Mon, Feb 13, 2023 at 11:15 PM Ferry Toth <fntoth@gmail.com> wrote: > > Op 09-02-2023 om 20:57 schreef Bartosz Golaszewski: > > On Thu, Feb 9, 2023 at 8:26 PM Ferry Toth <fntoth@gmail.com> wrote: > >> > >> Hi, > >> > >> Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: > >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >>> > >>> We've just tagged the release candidate for libgpiod v2. This is a major > >>> release entirely overhauling the API in a backward incompatible way. > >> > >> Thanks for creating this! > >> > >>> While this is not the final release yet, it's not likely to change much so > >>> I'd like to make it available in meta-openembedded to give it exposure to > >>> some testing. When we do release v2.0, it'll be just a matter of bumping the > >>> version. > >>> > >>> Currently no other package depends on libgpiod in meta-openembedded, so I'd > >>> like to avoid having two packages (libgpiod and libgpiod2). Instead let's > >>> provide recipes for both versions but keep them under the common libgpiod name > >>> as it's unlikely anyone would need both versions in a single system. This is > >>> after all a medium-sized project that shouldn't require too much work in order > >>> to port a user to the new major release. > >> > >> Nevertheless there may be packages in other layers using it (meta-acpi, > >> meta-intel-edison). I think there will be a period where both may need > >> to coexist. > >> > > > > Can those layers just set the PREFERRED_VERSION? > > Yes, but it doesn't the problem when one app needs v1 and the other > needs v2. > Yeah, this is what I'm trying to explain. How likely is it that the same system will use two versions of libgpiod at the same time? IMO highly unlikely because this is not gstreamer or some other huge project, it's a small-to-middle-sized library that's most likely ever only used by a single program or script on a given system. I'd prefer to not provide libgpiod and libgpiod2 packages but instead allow to alternate between them using PREFERRED_VERSION. If anyone complains, then we can rethink it. It's not like we're changing the default version in any of the stable branches anyway. Bart
Op 14-02-2023 om 15:05 schreef Bartosz Golaszewski: > On Mon, Feb 13, 2023 at 11:15 PM Ferry Toth <fntoth@gmail.com> wrote: >> >> Op 09-02-2023 om 20:57 schreef Bartosz Golaszewski: >>> On Thu, Feb 9, 2023 at 8:26 PM Ferry Toth <fntoth@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: >>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>>>> >>>>> We've just tagged the release candidate for libgpiod v2. This is a major >>>>> release entirely overhauling the API in a backward incompatible way. >>>> >>>> Thanks for creating this! >>>> >>>>> While this is not the final release yet, it's not likely to change much so >>>>> I'd like to make it available in meta-openembedded to give it exposure to >>>>> some testing. When we do release v2.0, it'll be just a matter of bumping the >>>>> version. >>>>> >>>>> Currently no other package depends on libgpiod in meta-openembedded, so I'd >>>>> like to avoid having two packages (libgpiod and libgpiod2). Instead let's >>>>> provide recipes for both versions but keep them under the common libgpiod name >>>>> as it's unlikely anyone would need both versions in a single system. This is >>>>> after all a medium-sized project that shouldn't require too much work in order >>>>> to port a user to the new major release. >>>> >>>> Nevertheless there may be packages in other layers using it (meta-acpi, >>>> meta-intel-edison). I think there will be a period where both may need >>>> to coexist. >>>> >>> >>> Can those layers just set the PREFERRED_VERSION? >> >> Yes, but it doesn't the problem when one app needs v1 and the other >> needs v2. >> > > Yeah, this is what I'm trying to explain. How likely is it that the > same system will use two versions of libgpiod at the same time? IMO > highly unlikely because this is not gstreamer or some other huge > project, it's a small-to-middle-sized library that's most likely ever > only used by a single program or script on a given system. > > I'd prefer to not provide libgpiod and libgpiod2 packages but instea > allow to alternate between them using PREFERRED_VERSION. If anyone > complains, then we can rethink it. libgpiod2 is in Ubuntu Kinetic and is a dependency of openocd (> 1,1) and eg25-amanager. Those packages will block libgpiod v2 from going in (that would be a pity) until they are ported, or until they are dropped (a pity to have your dependents dropped too). On a smaller scale, Intel Edison Arduino uses libgpiod in 2 apps. To port them I need to figure what changed and how to fix them. Try some example etc. because at this point in time there is not much example code. But installing libgpiod v2 breaks some systemd services because v1 gets uninstalled. Luckily in my case it does not break boot. > It's not like we're changing the default version in any of the stable > branches anyway. True. I just like libs to change version when they have compatibility breaks. But maybe that's just me. > Bart > > > > >
Hi Op 14-02-2023 om 19:10 schreef Bartosz Golaszewski: > On Tue, 14 Feb 2023 at 18:21, Ferry Toth <fntoth@gmail.com> wrote: >> Op 14-02-2023 om 15:05 schreef Bartosz Golaszewski: >>> On Mon, Feb 13, 2023 at 11:15 PM Ferry Toth <fntoth@gmail.com> wrote: >>>> Op 09-02-2023 om 20:57 schreef Bartosz Golaszewski: >>>>> On Thu, Feb 9, 2023 at 8:26 PM Ferry Toth <fntoth@gmail.com> wrote: >>>>>> Hi, >>>>>> >>>>>> Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: >>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>>>>>> >>>>>>> We've just tagged the release candidate for libgpiod v2. This is a major >>>>>>> release entirely overhauling the API in a backward incompatible way. >>>>>> Thanks for creating this! >>>>>> >>>>>>> While this is not the final release yet, it's not likely to change much so >>>>>>> I'd like to make it available in meta-openembedded to give it exposure to >>>>>>> some testing. When we do release v2.0, it'll be just a matter of bumping the >>>>>>> version. >>>>>>> >>>>>>> Currently no other package depends on libgpiod in meta-openembedded, so I'd >>>>>>> like to avoid having two packages (libgpiod and libgpiod2). Instead let's >>>>>>> provide recipes for both versions but keep them under the common libgpiod name >>>>>>> as it's unlikely anyone would need both versions in a single system. This is >>>>>>> after all a medium-sized project that shouldn't require too much work in order >>>>>>> to port a user to the new major release. >>>>>> Nevertheless there may be packages in other layers using it (meta-acpi, >>>>>> meta-intel-edison). I think there will be a period where both may need >>>>>> to coexist. >>>>>> >>>>> Can those layers just set the PREFERRED_VERSION? >>>> Yes, but it doesn't the problem when one app needs v1 and the other >>>> needs v2. >>>> >>> Yeah, this is what I'm trying to explain. How likely is it that the >>> same system will use two versions of libgpiod at the same time? IMO >>> highly unlikely because this is not gstreamer or some other huge >>> project, it's a small-to-middle-sized library that's most likely ever >>> only used by a single program or script on a given system. >>> >>> I'd prefer to not provide libgpiod and libgpiod2 packages but instea >>> allow to alternate between them using PREFERRED_VERSION. If anyone >>> complains, then we can rethink it. >> >> libgpiod2 is in Ubuntu Kinetic and is a dependency of openocd (> 1,1) >> and eg25-amanager. >> > Wait what? libgpiod v2 is not out yet, what's up with ubuntu? libgpiod2 (the package) is based on libgpiod 1.6.3 (the source) >> Those packages will block libgpiod v2 from going in (that would be a >> pity) until they are ported, or until they are dropped (a pity to have >> your dependents dropped too). >> >> On a smaller scale, Intel Edison Arduino uses libgpiod in 2 apps. To >> port them I need to figure what changed and how to fix them. Try some >> example etc. because at this point in time there is not much example >> code. But installing libgpiod v2 breaks some systemd services because v1 >> gets uninstalled. Luckily in my case it does not break boot. > I will be more than happy to assist with porting! In fact I will look > at porting openocd myself. Thanks, I start a new thread if I get stuck >>> It's not like we're changing the default version in any of the stable >>> branches anyway. >> True. I just like libs to change version when they have compatibility >> breaks. But maybe that's just me. >> > I don't really care what distros do. I maintain the meta-openembedded > recipe and only have interest in its versioning. Ubuntu can call it > libgpiod2137 for what I care. Of course. That was just an example, I didn't mean to hijack the discussion. I just seems libgpiod 1.6.3 and 2.0-rc1 can not currently coexist (i.e. the packages can not be installed simultaneously). Or I tried (to modify the recipe) and did something wrong. > Bart > >>> Bart >>> >>> >>> >>> >>>
On Tue, Feb 14, 2023 at 7:16 PM Ferry Toth <fntoth@gmail.com> wrote: > > Hi > > Op 14-02-2023 om 19:10 schreef Bartosz Golaszewski: > > On Tue, 14 Feb 2023 at 18:21, Ferry Toth <fntoth@gmail.com> wrote: > >> Op 14-02-2023 om 15:05 schreef Bartosz Golaszewski: > >>> On Mon, Feb 13, 2023 at 11:15 PM Ferry Toth <fntoth@gmail.com> wrote: > >>>> Op 09-02-2023 om 20:57 schreef Bartosz Golaszewski: > >>>>> On Thu, Feb 9, 2023 at 8:26 PM Ferry Toth <fntoth@gmail.com> wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Op 08-02-2023 om 16:25 schreef Bartosz Golaszewski: > >>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >>>>>>> > >>>>>>> We've just tagged the release candidate for libgpiod v2. This is a major > >>>>>>> release entirely overhauling the API in a backward incompatible way. > >>>>>> Thanks for creating this! > >>>>>> > >>>>>>> While this is not the final release yet, it's not likely to change much so > >>>>>>> I'd like to make it available in meta-openembedded to give it exposure to > >>>>>>> some testing. When we do release v2.0, it'll be just a matter of bumping the > >>>>>>> version. > >>>>>>> > >>>>>>> Currently no other package depends on libgpiod in meta-openembedded, so I'd > >>>>>>> like to avoid having two packages (libgpiod and libgpiod2). Instead let's > >>>>>>> provide recipes for both versions but keep them under the common libgpiod name > >>>>>>> as it's unlikely anyone would need both versions in a single system. This is > >>>>>>> after all a medium-sized project that shouldn't require too much work in order > >>>>>>> to port a user to the new major release. > >>>>>> Nevertheless there may be packages in other layers using it (meta-acpi, > >>>>>> meta-intel-edison). I think there will be a period where both may need > >>>>>> to coexist. > >>>>>> > >>>>> Can those layers just set the PREFERRED_VERSION? > >>>> Yes, but it doesn't the problem when one app needs v1 and the other > >>>> needs v2. > >>>> > >>> Yeah, this is what I'm trying to explain. How likely is it that the > >>> same system will use two versions of libgpiod at the same time? IMO > >>> highly unlikely because this is not gstreamer or some other huge > >>> project, it's a small-to-middle-sized library that's most likely ever > >>> only used by a single program or script on a given system. > >>> > >>> I'd prefer to not provide libgpiod and libgpiod2 packages but instea > >>> allow to alternate between them using PREFERRED_VERSION. If anyone > >>> complains, then we can rethink it. > >> > >> libgpiod2 is in Ubuntu Kinetic and is a dependency of openocd (> 1,1) > >> and eg25-amanager. > >> > > Wait what? libgpiod v2 is not out yet, what's up with ubuntu? > libgpiod2 (the package) is based on libgpiod 1.6.3 (the source) > >> Those packages will block libgpiod v2 from going in (that would be a > >> pity) until they are ported, or until they are dropped (a pity to have > >> your dependents dropped too). > >> > >> On a smaller scale, Intel Edison Arduino uses libgpiod in 2 apps. To > >> port them I need to figure what changed and how to fix them. Try some > >> example etc. because at this point in time there is not much example > >> code. But installing libgpiod v2 breaks some systemd services because v1 > >> gets uninstalled. Luckily in my case it does not break boot. > > I will be more than happy to assist with porting! In fact I will look > > at porting openocd myself. > Thanks, I start a new thread if I get stuck Feel free to post on the linux-gpio mailing list. > >>> It's not like we're changing the default version in any of the stable > >>> branches anyway. > >> True. I just like libs to change version when they have compatibility > >> breaks. But maybe that's just me. > >> > > I don't really care what distros do. I maintain the meta-openembedded > > recipe and only have interest in its versioning. Ubuntu can call it > > libgpiod2137 for what I care. > > Of course. That was just an example, I didn't mean to hijack the discussion. > > I just seems libgpiod 1.6.3 and 2.0-rc1 can not currently coexist (i.e. > the packages can not be installed simultaneously). Or I tried (to modify > the recipe) and did something wrong. > No, you're right. Shared objects have different ABI versions but other than that many files share names: the header, pkgconfig manpages etc. I have no intention of changing this honestly - better just port the apps. Bart
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> We've just tagged the release candidate for libgpiod v2. This is a major release entirely overhauling the API in a backward incompatible way. While this is not the final release yet, it's not likely to change much so I'd like to make it available in meta-openembedded to give it exposure to some testing. When we do release v2.0, it'll be just a matter of bumping the version. Currently no other package depends on libgpiod in meta-openembedded, so I'd like to avoid having two packages (libgpiod and libgpiod2). Instead let's provide recipes for both versions but keep them under the common libgpiod name as it's unlikely anyone would need both versions in a single system. This is after all a medium-sized project that shouldn't require too much work in order to port a user to the new major release. The first patch contains an update of libgpiod v1.6.x to the most recent bug-fix release. The second contains the recipe for libgpiod v2.0-rc1 while also moving the bitbake code around in order to factor out common elements. The third contains a recipe for the python bindings that are now in their own project in meta-python. The new recipes provide the same functionality - including ptest for the C library, tools and language bindings. Bartosz Golaszewski (3): libgpiod: update to v1.6.4 libgpiod: add a recipe for libgpiod v2.0-rc1 python3-gpiod: new package ...-don-t-expect-automake-to-set-PYTHON.patch | 37 --------- .../{files => libgpiod-1.6.4}/run-ptest | 0 .../libgpiod/libgpiod-2.0-rc1/run-ptest | 24 ++++++ .../recipes-support/libgpiod/libgpiod-src.inc | 1 + meta-oe/recipes-support/libgpiod/libgpiod.inc | 61 ++++++++++++++ .../libgpiod/libgpiod_1.6.3.bb | 82 ------------------- .../libgpiod/libgpiod_1.6.4.bb | 37 +++++++++ .../libgpiod/libgpiod_2.0-rc1.bb | 21 +++++ .../packagegroups/packagegroup-meta-python.bb | 1 + .../python/python3-gpiod/run-ptest | 15 ++++ .../python/python3-gpiod_2.0-rc1.bb | 45 ++++++++++ 11 files changed, 205 insertions(+), 119 deletions(-) delete mode 100644 meta-oe/recipes-support/libgpiod/files/0001-build-don-t-expect-automake-to-set-PYTHON.patch rename meta-oe/recipes-support/libgpiod/{files => libgpiod-1.6.4}/run-ptest (100%) create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod-2.0-rc1/run-ptest create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod-src.inc create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod.inc delete mode 100644 meta-oe/recipes-support/libgpiod/libgpiod_1.6.3.bb create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod_1.6.4.bb create mode 100644 meta-oe/recipes-support/libgpiod/libgpiod_2.0-rc1.bb create mode 100644 meta-python/recipes-devtools/python/python3-gpiod/run-ptest create mode 100644 meta-python/recipes-devtools/python/python3-gpiod_2.0-rc1.bb