GNU bug report logs - #76602
Reprotest fails to run due to missing execute bit

Previous Next

To reply to this bug, email your comments to 76602 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
To: guix-patches <at> gnu.org
Cc: me <at> bonfacemunyoki.com, tanguy <at> bioneland.org, lars <at> 6xq.net,
 sharlatanus <at> gmail.com, jgart <at> dismail.de
Subject: Reprotest fails to run due to missing execute bit
Date: Wed, 26 Feb 2025 14:11:03 -0800

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

Reprotest fails to run correctly due to files that are not marked
executable:

reprotest --verbose --vary=-fileordering,-domain_host,-user_group,-time -c 'date > date' . date -- null
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus to increase this.
WARNING:reprotest:diffoscope not available, falling back to regular diff
INFO:reprotest:STARTING VIRTUAL SERVER ['/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/virt/autopkgtest-virt-null']
Traceback (most recent call last):
  File "/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/__init__.py", line 862, in run
    return 0 if check_func(*check_args) else 1
  File "/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/__init__.py", line 370, in check
    proc = test_args._replace(result_dir=result_dir).corun_builds(testbed_args)
  File "/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/__init__.py", line 114, in start
    next(cr)
  File "/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/__init__.py", line 322, in corun_builds
    with start_testbed(virtual_server_args, temp_dir, no_clean_on_error,
  File "/gnu/store/50047r6f9chb6dwd01f9hai90y9arwb4-python-3.10.7/lib/python3.10/contextlib.py", line 135, in __enter__
    return next(self.gen)
  File "/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/__init__.py", line 85, in start_testbed
    testbed.start()
  File "/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/lib/adt_testbed.py", line 134, in start
    self.sp = subprocess.Popen(self.vserver_argv,
  File "/gnu/store/50047r6f9chb6dwd01f9hai90y9arwb4-python-3.10.7/lib/python3.10/subprocess.py", line 969, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/gnu/store/50047r6f9chb6dwd01f9hai90y9arwb4-python-3.10.7/lib/python3.10/subprocess.py", line 1845, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
PermissionError: [Errno 13] Permission denied: '/gnu/store/7cglj9r39y4hfbwzd3rbh2rgl1yg343v-reprotest-0.7.28/lib/python3.10/site-packages/reprotest/virt/autopkgtest-virt-null'

The reprotest version 0.7.21 included in guix v1.4.0 did have these
files marked executable, but for some reason in recent versions (maybe
changes in pyproject-build-system?), they are shipped without the
execute bit set. I have not git bisected between all the versions of
guix to see exactly where it starts failing.

CCed members of the python team if they have ideas about changes in the
build system which might cause the issue.

The attached patch marks the necessary files are executable with an
added phase. Open to refactorring the patch, but my guile skills are
quite limited and this works!


live well,
  vagrant

[0001-gnu-reprotest-Add-phase-fixing-executable-bit-on-vir.patch (text/x-diff, inline)]

From 5ed6bdda83e9e06f5984faac3d347b91438e9b04 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
Date: Wed, 26 Feb 2025 11:49:48 -0800
Subject: [PATCH] gnu: reprotest: Add phase fixing executable bit on virt
 files.

* gnu/packages/diffoscope.scm (reprotest): Add 'make-virt-files-executable
phase.
---
 gnu/packages/diffoscope.scm | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gnu/packages/diffoscope.scm b/gnu/packages/diffoscope.scm
index d0e911363d..90be6e68ec 100644
--- a/gnu/packages/diffoscope.scm
+++ b/gnu/packages/diffoscope.scm
@@ -273,6 +273,13 @@ (define-public reprotest
       #:tests? #f
       #:phases
       #~(modify-phases %standard-phases
+          (add-after 'compress-documentation 'make-virt-files-executable
+            ;; The autopkgtest-virt- files need to be marked executable for
+            ;; reprotest to function correctly.
+            (lambda _
+              (for-each (lambda (file)
+                          (invoke "chmod" "+x" file))
+                        (find-files #$output "autopkgtest-virt-.*"))))
           (add-after 'install 'install-doc
             (lambda _
               (let* ((mandir1 (string-append

base-commit: 54ff5d33739ae95c19f4ed5bea38d2613f6f7d3c
-- 
2.39.5

[signature.asc (application/pgp-signature, inline)]

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

From: Lars-Dominik Braun <lars <at> 6xq.net>
To: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
Cc: me <at> bonfacemunyoki.com, jgart <at> dismail.de, tanguy <at> bioneland.org,
 sharlatanus <at> gmail.com, guix-patches <at> gnu.org
Subject: Re: Reprotest fails to run due to missing execute bit
Date: Fri, 28 Feb 2025 15:30:17 +0100

Hi,

> The reprotest version 0.7.21 included in guix v1.4.0 did have these
> files marked executable, but for some reason in recent versions (maybe
> changes in pyproject-build-system?), they are shipped without the
> execute bit set. I have not git bisected between all the versions of
> guix to see exactly where it starts failing.

my best guess is that the package previously used python-build-system
instead of pyproject-build-system. The latter basically builds a zip file
(wheel) of everything and extracts it to site-packages. Zip files don’t
include the +x bit and so it gets lost in the process.

I believe this is a bug in the package. It should either indirectly call
these files via the python3 executable or mark them as entry points[1],
so pyproject-build-system can put an executable into /bin.

[1] https://setuptools.pypa.io/en/latest/userguide/entry_point.html

> The attached patch marks the necessary files are executable with an
> added phase. Open to refactorring the patch, but my guile skills are
> quite limited and this works!

Perhaps (chmod file #o755) instead of (invoke …)? Otherwise should be
fine to get it working again.

Cheers,
Lars

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

From: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
To: Lars-Dominik Braun <lars <at> 6xq.net>
Cc: me <at> bonfacemunyoki.com, jgart <at> dismail.de, 76602 <at> debbugs.gnu.org,
 tanguy <at> bioneland.org, sharlatanus <at> gmail.com
Subject: Re: Reprotest fails to run due to missing execute bit
Date: Fri, 28 Feb 2025 13:50:23 -0800

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

On 2025-02-28, Lars-Dominik Braun wrote:
>> The reprotest version 0.7.21 included in guix v1.4.0 did have these
>> files marked executable, but for some reason in recent versions (maybe
>> changes in pyproject-build-system?), they are shipped without the
>> execute bit set. I have not git bisected between all the versions of
>> guix to see exactly where it starts failing.
>
> my best guess is that the package previously used python-build-system
> instead of pyproject-build-system. The latter basically builds a zip file
> (wheel) of everything and extracts it to site-packages. Zip files don’t
> include the +x bit and so it gets lost in the process.

Good hint! It was switched to pyproject-build-system in
d3bad46f990fbd884ca114dddd5af0eae434aecc ... and reverting that commit
does get it running again!

I have had a git bisect running in the background for days now to try
and identify the commit, as most of the builds fail, but can stop that
now! *sigh*


> I believe this is a bug in the package. It should either indirectly call
> these files via the python3 executable or mark them as entry points[1],
> so pyproject-build-system can put an executable into /bin.
>
> [1] https://setuptools.pypa.io/en/latest/userguide/entry_point.html

Will try to wrap my head around that and get it fixed upstream...


>> The attached patch marks the necessary files are executable with an
>> added phase. Open to refactorring the patch, but my guile skills are
>> quite limited and this works!
>
> Perhaps (chmod file #o755) instead of (invoke …)? Otherwise should be
> fine to get it working again.

Will try it! Thanks!


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #16 received at 76602-done <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> reproducible-builds.org>
To: Lars-Dominik Braun <lars <at> 6xq.net>
Cc: me <at> bonfacemunyoki.com, jgart <at> dismail.de, 76602-done <at> debbugs.gnu.org,
 tanguy <at> bioneland.org, sharlatanus <at> gmail.com
Subject: Re: Reprotest fails to run due to missing execute bit
Date: Sat, 01 Mar 2025 14:10:31 -0800

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

On 2025-02-28, Vagrant Cascadian wrote:
> On 2025-02-28, Lars-Dominik Braun wrote:
>>> The reprotest version 0.7.21 included in guix v1.4.0 did have these
>>> files marked executable, but for some reason in recent versions (maybe
>>> changes in pyproject-build-system?), they are shipped without the
>>> execute bit set. I have not git bisected between all the versions of
>>> guix to see exactly where it starts failing.
>>
>> my best guess is that the package previously used python-build-system
>> instead of pyproject-build-system. The latter basically builds a zip file
>> (wheel) of everything and extracts it to site-packages. Zip files don’t
>> include the +x bit and so it gets lost in the process.
>
> Good hint! It was switched to pyproject-build-system in
> d3bad46f990fbd884ca114dddd5af0eae434aecc ... and reverting that commit
> does get it running again!
>
> I have had a git bisect running in the background for days now to try
> and identify the commit, as most of the builds fail, but can stop that
> now! *sigh*
>
>
>> I believe this is a bug in the package. It should either indirectly call
>> these files via the python3 executable or mark them as entry points[1],
>> so pyproject-build-system can put an executable into /bin.
>>
>> [1] https://setuptools.pypa.io/en/latest/userguide/entry_point.html
>
> Will try to wrap my head around that and get it fixed upstream...

Still should do this at some point...


>>> The attached patch marks the necessary files are executable with an
>>> added phase. Open to refactorring the patch, but my guile skills are
>>> quite limited and this works!
>>
>> Perhaps (chmod file #o755) instead of (invoke …)? Otherwise should be
>> fine to get it working again.
>
> Will try it! Thanks!

Pushed as:

2558392803663f4381fa9c09a53d329b719152bd gnu: reprotest: Add phase fixing executable bit on virt files.

Thanks for your help!

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Previous Next

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