GNU bug report logs - #34934
deeptools is not reproducible

Previous Next

Full log

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

From: T460s laptop <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34934 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#34934: deeptools is not reproducible
Date: Sat, 30 Mar 2019 11:03:41 -0400

[Message part 1 (text/plain, inline)]

Hello again!

Ludovic Courtès <ludo <at> gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> $ guix build --check -K deeptools
>
> Could you try:
>
>   guix build --check -K --no-grafts deeptools
>
> ?
>
> If deeptools is not reproducible, then it’ll leave a ‘-check’ output.

OK! The --no-grafts + --keep-failed combined did the trick, it now
produced the -check suffixed output.

There are differences regarding the number of links on many files; I'm
not sure this matters as it could be related to how the daemon optimizes
disk space in its store:

--8<---------------cut here---------------start------------->8---
--- /gnu/store/f3z6fczw70j6692ddy467pbagbjck009-deeptools-3.1.3
+++ /gnu/store/f3z6fczw70j6692ddy467pbagbjck009-deeptools-3.1.3-check
├── bin
│ │   --- /gnu/store/f3z6fczw70j6692ddy467pbagbjck009-deeptools-3.1.3/bin/.alignmentSieve-real
│ ├── +++ /gnu/store/f3z6fczw70j6692ddy467pbagbjck009-deeptools-3.1.3-check/bin/.alignmentSieve-real
│ │ ├── /gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin/stat {}
│ │ │ @@ -1,8 +1,8 @@
│ │ │  
│ │ │    Size: 289       	Blocks: 8          IO Block: 4096   regular file
│ │ │ -Links: 4
│ │ │ +Links: 1
│ │ │  Access: (0555/-r-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
│ │ │  
│ │ │  Modify: 1970-01-01 00:00:01.000000000 +0000
│ │ │  
│ │ │   Birth: -
--8<---------------cut here---------------end--------------->8---


There are also difference found using readelf, for example:
--8<---------------cut here---------------start------------->8---
│ │ │ │ ├── tree.cpython-37m-x86_64-linux-gnu.so
│ │ │ │ │ ├── /gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/readelf --wide --program-header {}
│ │ │ │ │ │ @@ -3,15 +3,15 @@
│ │ │ │ │ │  Entry point 0x35d0
│ │ │ │ │ │  There are 8 program headers, starting at offset 64
│ │ │ │ │ │  
│ │ │ │ │ │  Program Headers:
│ │ │ │ │ │    Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
│ │ │ │ │ │    LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x002a00 0x002a00 R   0x1000
│ │ │ │ │ │    LOAD           0x003000 0x0000000000003000 0x0000000000003000 0x00616d 0x00616d R E 0x1000
│ │ │ │ │ │ -  LOAD           0x00a000 0x000000000000a000 0x000000000000a000 0x002140 0x002140 R   0x1000
│ │ │ │ │ │ +  LOAD           0x00a000 0x000000000000a000 0x000000000000a000 0x002144 0x002144 R   0x1000
│ │ │ │ │ │    LOAD           0x00cd78 0x000000000000dd78 0x000000000000dd78 0x000908 0x000910 RW  0x1000
│ │ │ │ │ │    DYNAMIC        0x00cd90 0x000000000000dd90 0x000000000000dd90 0x000220 0x000220 RW  0x8
│ │ │ │ │ │    GNU_EH_FRAME   0x00a9a0 0x000000000000a9a0 0x000000000000a9a0 0x0002fc 0x0002fc R   0x4
│ │ │ │ │ │    GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
│ │ │ │ │ │    GNU_RELRO      0x00cd78 0x000000000000dd78 0x000000000000dd78 0x000288 0x000288 R   0x1
│ │ │ │ │ │  
│ │ │ │ │ │   Section to Segment mapping:
--8<---------------cut here---------------end--------------->8---

These seems to have to do with Cython files which might not have been
regenerated (packaged using pre-compiled binaries). I have a fix for
this which has been used ad-hoc in the 'bedtools' package. I'll try to move it into
the Python build system and see what it gives.

The full output is attached.

Maxim

[output.gz (application/octet-stream, attachment)]

Previous Next

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