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
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 numb
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 w
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 n
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?
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 pa
6 matches
Mail list logo
