Bug#951209: transition: libgusb

[Michal Čihař]

Hi

Simon McVittie píše v St 04. 03. 2020 v 11:43 +:
> On Wed, 12 Feb 2020 at 15:24:42 +0100, Laurent Bigonville wrote:
> > libgusb is carrying in debian a patch[0] to revert/fix an after the
> > fact
> > change that was done upstream in the versioning of the symbols.
> > 
> > I don't think we should/can carry this patch forever and due to the
> > fact
> > that the number of reverse-dependencies is quite limited, I was
> > planning
> > to simply drop it, but that would require to binNMU them to be
> > certain they are using the correct version of the symbol.
> 
> Is the maintainer of libgusb aware of this transition plan?

Yes, I approved the upload. Actually, the package is now looking for
new maintainer see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953092

> On Tue, 03 Mar 2020 at 20:19:12 +0100, Julien Cristau wrote:
> > IMO we should keep compatibility with the old version until the
> > next
> > upstream SONAME bump.  That might mean keeping this patch, or
> > something
> > different, if we can add properly versioned aliases for the
> > affected
> > symbols?
> 
> I've proposed 
> https://github.com/hughsie/libgusb/pull/33
>  upstream and
> https://salsa.debian.org/debian/libgusb/-/merge_requests/2
>  in Debian.
> 
> I would recommend waiting to see what upstream say about #33 before
> applying anything in Debian.

Makes sense to attempt to get in sync in upstream here.

Michal

Bug#951209: transition: libgusb

[Simon McVittie]

On Wed, 12 Feb 2020 at 15:24:42 +0100, Laurent Bigonville wrote:
> libgusb is carrying in debian a patch[0] to revert/fix an after the fact
> change that was done upstream in the versioning of the symbols.
> 
> I don't think we should/can carry this patch forever and due to the fact
> that the number of reverse-dependencies is quite limited, I was planning
> to simply drop it, but that would require to binNMU them to be
> certain they are using the correct version of the symbol.

Is the maintainer of libgusb aware of this transition plan?

Note that upstream broke the ABI *again* in 0.3.4. They tried to freeze
the ABI by introducing new checks, but the new checks accidentally dropped
a symbol (fix proposed in ).
If we want to do anything with the ABI, I think it would be a good idea
to base what we do on 0.3.4.

On Tue, 03 Mar 2020 at 20:19:12 +0100, Julien Cristau wrote:
> IMO we should keep compatibility with the old version until the next
> upstream SONAME bump.  That might mean keeping this patch, or something
> different, if we can add properly versioned aliases for the affected
> symbols?

I've proposed https://github.com/hughsie/libgusb/pull/33 upstream and
https://salsa.debian.org/debian/libgusb/-/merge_requests/2 in Debian.

I would recommend waiting to see what upstream say about #33 before
applying anything in Debian.

smcv

Bug#951209: transition: libgusb

[Laurent Bigonville]

On Tue, 3 Mar 2020 20:19:12 +0100 Julien Cristau  
wrote:

> On Wed, Feb 12, 2020 at 03:24:42PM +0100, Laurent Bigonville wrote:
> > libgusb is carrying in debian a patch[0] to revert/fix an after the 
fact

> > change that was done upstream in the versioning of the symbols.
> >
> > I don't think we should/can carry this patch forever and due to the 
fact
> > that the number of reverse-dependencies is quite limited, I was 
planning

> > to simply drop it, but that would require to binNMU them to be
> > certain they are using the correct version of the symbol.
> >
> IMO we should keep compatibility with the old version until the next
> upstream SONAME bump. That might mean keeping this patch, or something
> different, if we can add properly versioned aliases for the affected
> symbols?

I'm not exactly sure how to do that TBH

FTR, a more persistent link to the file was talking about in my initial 
mail 
https://salsa.debian.org/debian/libgusb/-/blob/80d3862872ff72b9cf10c90959973baf9755c7e9/debian/patches/revert-versioning.patch

Bug#951209: transition: libgusb

[Julien Cristau]

On Wed, Feb 12, 2020 at 03:24:42PM +0100, Laurent Bigonville wrote:
> libgusb is carrying in debian a patch[0] to revert/fix an after the fact
> change that was done upstream in the versioning of the symbols.
> 
> I don't think we should/can carry this patch forever and due to the fact
> that the number of reverse-dependencies is quite limited, I was planning
> to simply drop it, but that would require to binNMU them to be
> certain they are using the correct version of the symbol.
> 
IMO we should keep compatibility with the old version until the next
upstream SONAME bump.  That might mean keeping this patch, or something
different, if we can add properly versioned aliases for the affected
symbols?

Cheers,
Julien

Bug#951209: transition: libgusb

[Laurent Bigonville]

On Wed, 12 Feb 2020 15:24:42 +0100 Laurent Bigonville  
wrote:


> Could you please give me the greenlight to upload the new version of
> libgusb and then schedule a binNMU of fwupd (or all the rdeps if you
> prefere)
>

Any opinion on this?

Bug#951209: transition: libgusb

[Laurent Bigonville]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

libgusb is carrying in debian a patch[0] to revert/fix an after the fact
change that was done upstream in the versioning of the symbols.

I don't think we should/can carry this patch forever and due to the fact
that the number of reverse-dependencies is quite limited, I was planning
to simply drop it, but that would require to binNMU them to be
certain they are using the correct version of the symbol.

r-deps are:
  colord
  colorhug-client
  fwupd
  gnome-multi-writer
  simple-scan

I quickly tested and among of these, only fwupd seems impacted.

I updated the .symbols file of libgusb2 so the symbols affcted by this
version change will generate a dependency against the lastest version of
the library.

Could you please give me the greenlight to upload the new version of
libgusb and then schedule a binNMU of fwupd (or all the rdeps if you
prefere)

Kind regards,

Laurent Bigonville


[0] 
https://salsa.debian.org/debian/libgusb/blob/master/debian/patches/revert-versioning.patch

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy