I can switch between being able/unable to reproduce this bug by just doing
git checkout 64/65, without touching any dependencies. git-bisect, with
test being running build 100 times, points me to the
commit 0c3c88fc930f3755e6f4fb0879783e2585863e85 as the first one after
which builds do not fail any
Маша Глухова wrote:
> It seems likely that one of the changes fixed this bug as a side effect,
> but I cannot yet tell which one.
My hunch is that its the libvirt 2.5.0-2 that was upload to unstable on 22nd
Feb. The timeline fits better and nothing has really changed in the guestfs
code... :)
R
I should add, I also had failures with diffoscope version 64 and older, but
no failures on newer versions. It seems likely that
one of the changes fixed this bug as a side effect, but I cannot yet tell
which one.
Hi.
I have built version 66 one hundred times in unstable.
The builds were made on 19 different autobuilders.
The number of failed builds has been zero.
(Previously it failed 10% of the time).
If you do not remember what kind of change may have fixed this,
then there must be some broken build-dep
On Mon, Dec 26, 2016 at 07:37:55PM +, Chris Lamb wrote:
> Santiago Vila wrote:
>
> > If I do "python3 -m pytest" afterwards this is what it's shown:
> […]
> > Note: This is still diffoscope_63 in stretch, not sure if I should
> > better try the version in unstable and forget completely about t
Santiago Vila wrote:
> If I do "python3 -m pytest" afterwards this is what it's shown:
[…]
> Note: This is still diffoscope_63 in stretch, not sure if I should
> better try the version in unstable and forget completely about this
> version.
Please do so; the icc tests were fixed later and there h
On Sat, 24 Dec 2016, Ximin Luo wrote:
> For all you people that already have single-CPU KVM VMs set up, can you
> please try to reduce your test cases that still reproduce the bug?
>
> For example, can you still reproduce it with `debian/rules clean build`? What
> about `python3 -m pytest`? The
Chris Lamb:
> Ximin Luo wrote:
>
>> I still haven't managed to reproduce this myself but I'll just note
>> for the record we have seen this on jenkins before
>
> My guess is that one of the third-party Python extension modules that
> we import does not correctly reference count Py_None. Someone d
Ximin Luo wrote:
> I still haven't managed to reproduce this myself but I'll just note
> for the record we have seen this on jenkins before
My guess is that one of the third-party Python extension modules that
we import does not correctly reference count Py_None. Someone did a
good writeup here:
I still haven't managed to reproduce this myself but I'll just note for the
record we have seen this on jenkins before:
https://jenkins.debian.net/job/reproducible_diffoscope_from_git_master/63/console
Santiago Vila:
> Package: src:diffoscope
> Version: 63
> Severity: serious
>
> Hello folks.
>
10 matches
Mail list logo
