* [PATCH] libusb: Add comment to update nut when libusb is updated @ 2025-06-30 16:12 Adolf Belka 2025-07-01 7:52 ` Michael Tremer 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2025-06-30 16:12 UTC (permalink / raw) To: development; +Cc: Adolf Belka - libusb is a run time requirement for nut Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> --- lfs/libusb | 1 + 1 file changed, 1 insertion(+) diff --git a/lfs/libusb b/lfs/libusb index 4b12242d7..0ff89ff75 100644 --- a/lfs/libusb +++ b/lfs/libusb @@ -25,6 +25,7 @@ include Config VER = 1.0.29 +# Ship nut when libusb is updated THISAPP = libusb-$(VER) DL_FILE = $(THISAPP).tar.bz2 -- 2.50.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] libusb: Add comment to update nut when libusb is updated 2025-06-30 16:12 [PATCH] libusb: Add comment to update nut when libusb is updated Adolf Belka @ 2025-07-01 7:52 ` Michael Tremer 2025-07-01 9:19 ` Adolf Belka 0 siblings, 1 reply; 5+ messages in thread From: Michael Tremer @ 2025-07-01 7:52 UTC (permalink / raw) To: Adolf Belka; +Cc: development Hello Adolf, Could you tell us my about why this is necessary? The library should have a stable ABI so whenever they are being compiled independently from each other, they should still work. Best, -Michael > On 30 Jun 2025, at 17:12, Adolf Belka <adolf.belka@ipfire.org> wrote: > > - libusb is a run time requirement for nut > > Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> > --- > lfs/libusb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lfs/libusb b/lfs/libusb > index 4b12242d7..0ff89ff75 100644 > --- a/lfs/libusb > +++ b/lfs/libusb > @@ -25,6 +25,7 @@ > include Config > > VER = 1.0.29 > +# Ship nut when libusb is updated > > THISAPP = libusb-$(VER) > DL_FILE = $(THISAPP).tar.bz2 > -- > 2.50.0 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] libusb: Add comment to update nut when libusb is updated 2025-07-01 7:52 ` Michael Tremer @ 2025-07-01 9:19 ` Adolf Belka 2025-07-01 15:04 ` Adolf Belka 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2025-07-01 9:19 UTC (permalink / raw) To: Michael Tremer; +Cc: IPFire: Development-List Hi Michael, Earlier this year someone had a problem where nut wouldn't work because it was not linked to the correct libusb library and libusb had been updated in 2024. I thought that this had been a problem of a failure in a library link after an update because nut had not been shipped. Withy you asking the question I went back and looked at the failures that had been reported and recognised a problem I had seen before with nut. The problem, the user had was not due to a incorrectly linked library but due to a regression in nut where they ended up making the library requirement to libusb-1.0.so and not to libusb-1.0.so.0 or libusb-1.0.so.0.4.0 This issue of linking to libusb-1.0.so had been fixed in nut-2.7.4 but somewhere between there and nut-2.8.2 it came back. They have now fixed this again in the latest version which is in CU196 (nut-2.8.3) So the message is not required in the lfs file and my patch can be rejected. I obviously didn't read the details of the issue reported in the forum closely enough and missed that it was the direct .so file being required. Regards, Adolf. On 01/07/2025 09:52, Michael Tremer wrote: > Hello Adolf, > > Could you tell us my about why this is necessary? > > The library should have a stable ABI so whenever they are being compiled independently from each other, they should still work. > > Best, > -Michael > >> On 30 Jun 2025, at 17:12, Adolf Belka <adolf.belka@ipfire.org> wrote: >> >> - libusb is a run time requirement for nut >> >> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> >> --- >> lfs/libusb | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/lfs/libusb b/lfs/libusb >> index 4b12242d7..0ff89ff75 100644 >> --- a/lfs/libusb >> +++ b/lfs/libusb >> @@ -25,6 +25,7 @@ >> include Config >> >> VER = 1.0.29 >> +# Ship nut when libusb is updated >> >> THISAPP = libusb-$(VER) >> DL_FILE = $(THISAPP).tar.bz2 >> -- >> 2.50.0 >> >> > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] libusb: Add comment to update nut when libusb is updated 2025-07-01 9:19 ` Adolf Belka @ 2025-07-01 15:04 ` Adolf Belka 2025-07-02 10:46 ` Michael Tremer 0 siblings, 1 reply; 5+ messages in thread From: Adolf Belka @ 2025-07-01 15:04 UTC (permalink / raw) To: Michael Tremer; +Cc: IPFire: Development-List Hi Michael, I saw that my libusb patch with the comment has been merged. As I indicated below, I have realised that the problem I was looking at for a user was due to a different issue so that libusb patch with the addition of the comment can be rejected and reverted. Regards, Adolf. On 01/07/2025 11:19, Adolf Belka wrote: > Hi Michael, > > Earlier this year someone had a problem where nut wouldn't work because it was not linked to the correct libusb library and libusb had been updated in 2024. I thought that this had been a problem of a failure in a library link after an update because nut had not been shipped. > > Withy you asking the question I went back and looked at the failures that had been reported and recognised a problem I had seen before with nut. > > The problem, the user had was not due to a incorrectly linked library but due to a regression in nut where they ended up making the library requirement to libusb-1.0.so and not to libusb-1.0.so.0 or libusb-1.0.so.0.4.0 > > This issue of linking to libusb-1.0.so had been fixed in nut-2.7.4 but somewhere between there and nut-2.8.2 it came back. They have now fixed this again in the latest version which is in CU196 (nut-2.8.3) > > So the message is not required in the lfs file and my patch can be rejected. > > I obviously didn't read the details of the issue reported in the forum closely enough and missed that it was the direct .so file being required. > > Regards, > > Adolf. > > > On 01/07/2025 09:52, Michael Tremer wrote: >> Hello Adolf, >> >> Could you tell us my about why this is necessary? >> >> The library should have a stable ABI so whenever they are being compiled independently from each other, they should still work. >> >> Best, >> -Michael >> >>> On 30 Jun 2025, at 17:12, Adolf Belka <adolf.belka@ipfire.org> wrote: >>> >>> - libusb is a run time requirement for nut >>> >>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> >>> --- >>> lfs/libusb | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/lfs/libusb b/lfs/libusb >>> index 4b12242d7..0ff89ff75 100644 >>> --- a/lfs/libusb >>> +++ b/lfs/libusb >>> @@ -25,6 +25,7 @@ >>> include Config >>> >>> VER = 1.0.29 >>> +# Ship nut when libusb is updated >>> >>> THISAPP = libusb-$(VER) >>> DL_FILE = $(THISAPP).tar.bz2 >>> -- >>> 2.50.0 >>> >>> >> >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] libusb: Add comment to update nut when libusb is updated 2025-07-01 15:04 ` Adolf Belka @ 2025-07-02 10:46 ` Michael Tremer 0 siblings, 0 replies; 5+ messages in thread From: Michael Tremer @ 2025-07-02 10:46 UTC (permalink / raw) To: Adolf Belka; +Cc: IPFire: Development-List Thank you. I reverted the patch, but I did not push it yet, just because we don’t need to trigger a build for such a small change. -Michael > On 1 Jul 2025, at 16:04, Adolf Belka <adolf.belka@ipfire.org> wrote: > > Hi Michael, > > I saw that my libusb patch with the comment has been merged. > > As I indicated below, I have realised that the problem I was looking at for a user was due to a different issue so that libusb patch with the addition of the comment can be rejected and reverted. > > Regards, > > Adolf. > > On 01/07/2025 11:19, Adolf Belka wrote: >> Hi Michael, >> Earlier this year someone had a problem where nut wouldn't work because it was not linked to the correct libusb library and libusb had been updated in 2024. I thought that this had been a problem of a failure in a library link after an update because nut had not been shipped. >> Withy you asking the question I went back and looked at the failures that had been reported and recognised a problem I had seen before with nut. >> The problem, the user had was not due to a incorrectly linked library but due to a regression in nut where they ended up making the library requirement to libusb-1.0.so and not to libusb-1.0.so.0 or libusb-1.0.so.0.4.0 >> This issue of linking to libusb-1.0.so had been fixed in nut-2.7.4 but somewhere between there and nut-2.8.2 it came back. They have now fixed this again in the latest version which is in CU196 (nut-2.8.3) >> So the message is not required in the lfs file and my patch can be rejected. >> I obviously didn't read the details of the issue reported in the forum closely enough and missed that it was the direct .so file being required. >> Regards, >> Adolf. >> On 01/07/2025 09:52, Michael Tremer wrote: >>> Hello Adolf, >>> >>> Could you tell us my about why this is necessary? >>> >>> The library should have a stable ABI so whenever they are being compiled independently from each other, they should still work. >>> >>> Best, >>> -Michael >>> >>>> On 30 Jun 2025, at 17:12, Adolf Belka <adolf.belka@ipfire.org> wrote: >>>> >>>> - libusb is a run time requirement for nut >>>> >>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> >>>> --- >>>> lfs/libusb | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/lfs/libusb b/lfs/libusb >>>> index 4b12242d7..0ff89ff75 100644 >>>> --- a/lfs/libusb >>>> +++ b/lfs/libusb >>>> @@ -25,6 +25,7 @@ >>>> include Config >>>> >>>> VER = 1.0.29 >>>> +# Ship nut when libusb is updated >>>> >>>> THISAPP = libusb-$(VER) >>>> DL_FILE = $(THISAPP).tar.bz2 >>>> -- >>>> 2.50.0 >>>> >>>> >>> >>> > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-07-02 10:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-06-30 16:12 [PATCH] libusb: Add comment to update nut when libusb is updated Adolf Belka 2025-07-01 7:52 ` Michael Tremer 2025-07-01 9:19 ` Adolf Belka 2025-07-01 15:04 ` Adolf Belka 2025-07-02 10:46 ` Michael Tremer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox