GNU bug report logs - #71024
Update diffoscope to 268

Previous Next

Full log

Message #49 received at 71024 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
Cc: 71024 <at> debbugs.gnu.org
Subject: Re: bug#71024: Update diffoscope to 268
Date: Wed, 29 May 2024 21:02:32 -0400

Hi Vagrant,

Vagrant Cascadian <vagrant <at> reproducible-builds.org> writes:

> On 2024-05-25, Maxim Cournoyer wrote:
>> Vagrant Cascadian <vagrant <at> reproducible-builds.org> writes:
>>> On 2024-05-21, Maxim Cournoyer wrote:
>>>> Vagrant Cascadian <vagrant <at> reproducible-builds.org> writes:
>>>>> On 2024-05-20, Vagrant Cascadian wrote:
>>>>>> On 2024-05-20, Maxim Cournoyer wrote:
>>>>>>> vagrant <at> reproducible-builds.org writes:
>>>>>>>> From: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
>>>>>> Or fixing diffoscope to work with the older xz version in master
>>>>>> (5.2.x?) that guix is already using, which, now that I have spelled out
>>>>>> all of the above, seems possibly a much better idea!
> ...
>>> Well, version 268 was just released, which fixes the xz issue ... but
>>> introduces a test failure for 7z... which is worked around in the
>>> attached patch.
> ...
>>> +              (substitute* "tests/comparators/test_sevenz.py"
>>> +                ((", skip_unless_tool_is_at_least") ", skip_unless_tool_is_at_least, skip_unless_tool_is_at_most")
>>> +                (("@skip_unless_tool_is_at_least") "@skip_unless_tool_is_at_most(\"7z\", sevenz_version, \"63\")\n <at> skip_unless_tool_is_at_least"))))
>>
>> That would LGTM, if it didn't so severely bust our 80 maximum column
>> width convention :-).  Would you mind editing it into conformance?
>
> Oops. must not have guix linted that one!
>
>
> Well, again, upstream has fixed it even better:
>
>   https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/2a361d7dff135d3e832161f587a55a62fcbec9f2
>
> Tested fine for me building against that commit.
>
> So ... wait again till another release (and maybe find new breakage in
> the new release), or build against an untagged commit, or pull in a
> patch from the upstream commit? :)

If you want to get done with this, I'd recommend pulling a patch from
the upstream commit.  Then when we get to upgrading to the next release
we can drop such patch.

Hope that helps,

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.