[bug#76602] Reprotest fails to run due to missing execute bit

  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
  

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
  

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
  

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