Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2017-01-15 Thread Santiago Vila
Version: 67

Hi.

After building this version on stretch today 201 times, with different
autobuilders, the result was 200 successful builds and one sbuild hang.

Compared to the previous 10% failure rate, the sbuild hang is most
likely a completely different issue, so I hereby declare this bug as
"most probably fixed".

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds


Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2017-01-06 Thread Santiago Vila
On Fri, Jan 06, 2017 at 01:43:43PM +, Holger Levsen wrote:
> On Thu, Jan 05, 2017 at 11:36:17PM +0100, Santiago Vila wrote:
> > But let's see again when the package reaches testing.
> 
> you could build that package against testing today?! once or a hundred
> times ;)

Not trivially using sbuild and my current setup.

It would be like triggering from alioth.debian.org a build of
diffoscope 67 in a stretch chroot of reproducible-builds, for example.

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds


Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2017-01-06 Thread Holger Levsen
On Thu, Jan 05, 2017 at 11:36:17PM +0100, Santiago Vila wrote:
> But let's see again when the package reaches testing.

you could build that package against testing today?! once or a hundred
times ;)


-- 
cheers,
Holger


signature.asc
Description: Digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2017-01-05 Thread Santiago Vila
On Thu, 5 Jan 2017, Ximin Luo wrote:

> I've uploaded version 67 with that commit reverted:
> 
> https://people.debian.org/~infinity0/apt/pool/main/d/diffoscope/

Tried 100 times in sid. Built ok 100 times. This is also what happened
to version 66, so I'm not surprised.

But let's see again when the package reaches testing.

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds


Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2017-01-05 Thread Ximin Luo
Маша Глухова:
> 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 anymore. Manual testing confirms as much: I am
> able to reproduce the bug before, but not after, said commit.
> I am not sure what to make of it: the commit does not seem like it might
> cause significant change.
> I could also add that the bug does not seem to be connected with virual
> machines or number of CPUs. I reproduced it both on 1-CPU KVM/QEMU and real
> system (on two different computers with different numbers of CPUs).
> Hope that information would provide someone with some insight.

Santiago Vila:
> 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).

I've uploaded version 67 with that commit reverted:

https://people.debian.org/~infinity0/apt/pool/main/d/diffoscope/

Would be good if you people could test it to see if the test failures appear 
again.

I agree it's unlikely that this commit is the direct cause, but it's possible 
that it is interacting with some lower-level stuff that either hides or reveals 
the bad behaviour. So the bug is probably still present, just hidden. In which 
case we should still keep a record of it.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2016-12-27 Thread Chris Lamb
Маша Глухова 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... :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2016-12-26 Thread Маша Глухова
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.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2016-12-26 Thread Santiago Vila
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-depends in testing which
is fixed in unstable.

I guess the right thing to do would be to find which one, reassign
this bug, and then close it, but we should ensure that the
fixed build-dependency propagates to testing.

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds


Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2016-12-26 Thread Santiago Vila
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 this
> > version.
> 
> Please do so; the icc tests were fixed later and there have been quite
> a few other changes that makes focusing on stretch's version a poor
> return on time :)

Ok. I'm now building in unstable, many times. No failures so far.

Is it likely/possible that the changes between testing and unstable
have fixed this bug as a side effect?

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2016-12-26 Thread Chris Lamb
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 have been quite
a few other changes that makes focusing on stretch's version a poor
return on time :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#848403: diffoscope: FTBFS randomly (Fatal Python error: deallocating None)

2016-12-26 Thread Santiago Vila
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`? Then, does it reproduce when you start manually 
> disabling various tests? What about when running only 1 test case?

Building the package by hand makes three tests to fail.

If I do "python3 -m pytest" afterwards this is what it's shown:

= test session starts ==
platform linux -- Python 3.5.2+, pytest-3.0.5, py-1.4.31, pluggy-0.4.0
rootdir: /build/diffoscope-63, inifile: 
plugins: cov-2.4.0
collected 248 items

tests/test_difference.py ...
tests/test_main.py .
tests/comparators/test_binary.py ...
tests/comparators/test_bzip2.py ..
tests/comparators/test_cbfs.py ss
tests/comparators/test_cpio.py ..
tests/comparators/test_deb.py ...
tests/comparators/test_debian.py ...
tests/comparators/test_dex.py 
tests/comparators/test_directory.py 
tests/comparators/test_elf.py ..
tests/comparators/test_epub.py 
tests/comparators/test_fonts.py 
tests/comparators/test_fsimage.py .sss
tests/comparators/test_gettext.py .
tests/comparators/test_git.py ...
tests/comparators/test_gzip.py ...
tests/comparators/test_haskell.py s.s
tests/comparators/test_icc.py F.FF
tests/comparators/test_image.py 
tests/comparators/test_ipk.py .
tests/comparators/test_iso9660.py ...
tests/comparators/test_java.py 
tests/comparators/test_json.py .
tests/comparators/test_macho.py ..ss
tests/comparators/test_mono.py 
tests/comparators/test_pdf.py .
tests/comparators/test_png.py 
tests/comparators/test_ppu.py 
tests/comparators/test_ps.py .
tests/comparators/test_rlib.py 
tests/comparators/test_rpm.py ..
tests/comparators/test_sqlite.py 
tests/comparators/test_squashfs.py ...
tests/comparators/test_tar.py ...
tests/comparators/test_text.py ..
tests/comparators/test_utils.py .ss.
tests/comparators/test_xz.py ..
tests/comparators/test_zip.py ..

=== FAILURES ===
_ test_identification __

icc1 = < 
/build/diffoscope-63/tests/data/test1.icc>

def test_identification(icc1):
>   assert isinstance(icc1, IccFile)
E   assert False
E+  where False = isinstance(< 
/build/diffoscope-63/tests/data/test1.icc>, IccFile)

tests/comparators/test_icc.py:32: AssertionError
__ test_diff ___

differences = []

@skip_unless_tools_exist('cd-iccdump')
def test_diff(differences):
expected_diff = open(data('icc_expected_diff')).read()
>   assert differences[0].unified_diff == expected_diff
E   IndexError: list index out of range

tests/comparators/test_icc.py:45: IndexError
__ test_compare_non_existing ___

monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fc9dec67128>
icc1 = < 
/build/diffoscope-63/tests/data/test1.icc>

@skip_unless_tools_exist('cd-iccdump')
def test_compare_non_existing(monkeypatch, icc1):
monkeypatch.setattr(Config(), 'new_file', True)
difference = icc1.compare(NonExistingFile('/nonexisting', icc1))
assert difference.source2 == '/nonexisting'
>   assert len(difference.details) > 0
E   assert 0 > 0
E+  where 0 = len([])
E+where [] = .details

tests/comparators/test_icc.py:52: AssertionError
== 3 failed, 230 passed, 15 skipped in 52.10 seconds ===


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.

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds