Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-19 Thread Stuart Prescott

Control: clone 1055919 -1

Control: reassign -1 dh-python 5.20230130+deb12u1


Making a clone of this bug for dh-python to track it getting fixed 
there; MR to come.



Context:

On Thu, 16 Nov 2023 17:33:58 +1100 Stuart Prescott  
wrote:


> tldr: smells like a dh-python bug - I'll look at it more and reassign
> etc later.
>
>
> Staring at some build logs some more:
>
> * the dirs are generated always
> * they get copied from .../.pybuild to ../debian/$package/ always
> * they are supposed to get removed by dh_python3
> * that removal is not always working
>
> A common theme of the failures is that there are _two_
> /usr/lib/python3.11/dist-packages/.foo directories to remove and only
> one of them is being removed. For python-ansible-pygments, .pytest_cache
> was being removed by dh-python3 but .test-results was not.
>
> Adding in PYBUILD_VERBOSE=1 and some breakpoints into dh-python
> (specifically /usr/share/dh-python/dhpython/fs.py), I think there's a
> subtle bug about altering `dirs` while inside a loop from `os.walk`:
>
> for name in dirs:
> if name in ('test', 'tests') or name.startswith('.'):
> log.debug('removing dist-packages/%s', name)
> rmtree(join(root, name))
> dirs.remove(name)
>
> Removing `name` from `dirs` means that the next item is accidentally
> skipped. A classic "don't change the object you're iterating through
> while you are iterating through it" issue:
>
> In [1]: L = list(range(0, 10))
>
> In [2]: for i in L:
> ...: print(i)
> ...: L.remove(i)
> ...:
> 0
> 2
> 4
> 6
> 8
>
> Which item is not processed in the next iteration by dh_python3 now
> depends on the order in which `os.walk` lists the directories. That is
> presumably dependent on all manner of things (filesystem? collation?
> luck?). On the r-b setup and building by hand I get different results to
> within sbuild (and on the buildd).
>
> In sbuild on ext4, `find -type d` (I have memory that this reflects disk
> order?) has an order in
> ./debian/python3-ansible-pygments/usr/lib/python3.11/dist-packages of:
>
> .test-results ansible_pygments .pytest_cache
>
> while building by hand on tmpfs, I get
>
> ansible_pygments .test-results .pytest_cache
>
> For the former, accidentally skipping the directory after the one that
> gets removed isn't an issue, but for the latter it is.

--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-16 Thread Chris Lamb
Stuart Prescott wrote:

> I think there's a subtle bug about altering `dirs` while
> inside a loop from `os.walk`:

I'm quite impressed that you managed to hunt this down — that's very
nice work. :)

> Which item is not processed in the next iteration by dh_python3 now 
> depends on the order in which `os.walk` lists the directories. That is 
> presumably dependent on all manner of things (filesystem? collation? 
> luck?).

It will be dependent entirely on the filesystem being used because
`os.walk` merely passes on the underlying filesystem ordering. (The
same is true for GNU find as you later query.)

Entirely anecdotally, ext4 will be "more orderful", whilst btrfs,
possibly due to the way it rebalances its tree data structures, tends
to be less so. I raise it only because it can help explain why
different folks will get different results locally despite using the
same building tools. Building under tmpfs will have different
properties as well.

Anyway, thank you again. Once this is addressed in dh-python (even as
a proposed patch), I'll go through the last few months of bugs that
I've filed and see whether they can be closed.


Best wishes,

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



Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-15 Thread Stuart Prescott
tldr: smells like a dh-python bug - I'll look at it more and reassign 
etc later.



Staring at some build logs some more:

* the dirs are generated always
* they get copied from .../.pybuild to ../debian/$package/ always
* they are supposed to get removed by dh_python3
* that removal is not always working

A common theme of the failures is that there are _two_
/usr/lib/python3.11/dist-packages/.foo directories to remove and only 
one of them is being removed. For python-ansible-pygments, .pytest_cache 
was being removed by dh-python3 but .test-results was not.


Adding in PYBUILD_VERBOSE=1 and some breakpoints into dh-python 
(specifically /usr/share/dh-python/dhpython/fs.py), I think there's a 
subtle bug about altering `dirs` while inside a loop from `os.walk`:


for name in dirs:
if name in ('test', 'tests') or name.startswith('.'):
log.debug('removing dist-packages/%s', name)
rmtree(join(root, name))
dirs.remove(name)

Removing `name` from `dirs` means that the next item is accidentally 
skipped. A classic "don't change the object you're iterating through 
while you are iterating through it" issue:


In [1]: L = list(range(0, 10))

In [2]: for i in L:
...: print(i)
...: L.remove(i)
...:
0
2
4
6
8

Which item is not processed in the next iteration by dh_python3 now 
depends on the order in which `os.walk` lists the directories. That is 
presumably dependent on all manner of things (filesystem? collation? 
luck?). On the r-b setup and building by hand I get different results to 
within sbuild (and on the buildd).


In sbuild on ext4, `find -type d` (I have memory that this reflects disk 
order?) has an order in 
./debian/python3-ansible-pygments/usr/lib/python3.11/dist-packages of:


.test-results ansible_pygments .pytest_cache

while building by hand on tmpfs, I get

 ansible_pygments .test-results .pytest_cache

For the former, accidentally skipping the directory after the one that 
gets removed isn't an issue, but for the latter it is.




--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-15 Thread Holger Levsen
On Wed, Nov 15, 2023 at 01:31:26PM +, Chris Lamb wrote:
> I would be more than willing to conclude that this is an issue in
> tests.reproducible-builds.org setup. However, I am actually seeing
> these test files when I build locally as well — and my patch
> consequently fixes the "problem". Moreover, I am not using the same
> setup as tests.reproducible-builds.org at all. (Can you confirm whether
> you see them when building locally?)

tests.r-b.o is using pbuilder, while the buildds use sbuild. what do you use?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.)


signature.asc
Description: PGP signature


Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-15 Thread Chris Lamb
[[ looping reproducible-bui...@lists.alioth.debian.org in on this issue ]]

Stuart Prescott wrote:

> Is there something about the r-b setup that would cause these
> directories to be created and appear in the package?

Hm, you know, I think there must be. In fact, connecting a few dots in
my head, that now makes three recent reproducibility bugs that the
buildds are not, if you can excuse the expression, reproducing:

  1. https://bugs.debian.org/1055919 (this bug)
  2. https://bugs.debian.org/1053353
  3. https://bugs.debian.org/1000401

I would be more than willing to conclude that this is an issue in
tests.reproducible-builds.org setup. However, I am actually seeing
these test files when I build locally as well — and my patch
consequently fixes the "problem". Moreover, I am not using the same
setup as tests.reproducible-builds.org at all. (Can you confirm whether
you see them when building locally?)

I won't file any more until this has been more generally resolved.
Hopefully I haven't been filing similar issues recently (#1055920?)
and not realising it.

(Has a build-dependency changed and then the buildd chroots are out of
sync? Is that even possible? Am I?)


Regards,

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



Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-15 Thread Stuart Prescott

Hi Chris,


Whilst working on the Reproducible Builds effort [0], we noticed that



python-ansible-pygments could not be built reproducibly.







This is because the binary package included .pytest_cache and



.test-results directories. Patch attached that removes these after



running the tests.


I see those directories in the packages built on the r-b machines, but I don't 
see them in the package in the archive or when rebuilding the package locally. 
The files exist within the build tree but in /.pybuild/cpython3_3.11/build/ 
which does not get them installed.

Is there something about the r-b setup that would cause these directories to be 
created and appear in the package?

thanks
Stuart

$ apt download  -t sid python3-ansible-pygments

$ dpkg-deb --fsys-tarfile python3-ansible-pygments_0.1.1-6_all.deb | tar t
./
./usr/
./usr/lib/
./usr/lib/python3/
./usr/lib/python3/dist-packages/
./usr/lib/python3/dist-packages/ansible_pygments/
./usr/lib/python3/dist-packages/ansible_pygments/__init__.py
./usr/lib/python3/dist-packages/ansible_pygments/lexers.py
./usr/lib/python3/dist-packages/ansible_pygments/styles.py
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/METADATA
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/RECORD
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/WHEEL
./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/entry_points.txt
./usr/share/
./usr/share/doc/
./usr/share/doc/python3-ansible-pygments/
./usr/share/doc/python3-ansible-pygments/changelog.Debian.gz
./usr/share/doc/python3-ansible-pygments/copyright
./usr/share/doc/python3-ansible-pygments/examples/
./usr/share/doc/python3-ansible-pygments/examples/lexer_test.py

--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#1055919: python-ansible-pygments: please make the build reproducible

2023-11-14 Thread Chris Lamb
Source: python-ansible-pygments
Version: 0.1.1-6
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-ansible-pygments could not be built reproducibly.

This is because the binary package included .pytest_cache and
.test-results directories. Patch attached that removes these after
running the tests.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2023-11-14 09:25:37.237065158 +
--- b/debian/rules  2023-11-14 09:28:11.611381883 +
@@ -4,3 +4,6 @@
 
 %:
dh $@ --buildsystem=pybuild
+
+execute_after_dh_auto_test:
+   find .pybuild -type d \( -name .pytest_cache -or -name .test-results \) 
-print0 | xargs -0r rm -rfv