You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When importing SRPMs into git repositories, executable file permissions are not being preserved. This issue appears to occur in some, if not all, cases. The problem is likely related to an issue with billy.Filesystem or go-git, or possibly due to the interaction between the two.
This behavior is particularly problematic for packages like the kernel, which include multiple build scripts that are expected to have the execute bit set. Without the correct permissions, these scripts cannot be executed during the build process, leading to failures.
Steps to Reproduce:
Import an SRPM that contains executable scripts into a git repository using the SRPM import process.
Check out the resulting repository.
Attempt to build the package from the repository sources.
Observe that executable scripts lack the execute permission bit.
Example:
During the build process of the kernel package, the following error occurs due to missing execute permissions:
+ NAME=kernel
+ ./generate_all_configs.sh
/var/tmp/rpm-tmp.K4wDwX: line 238: ./generate_all_configs.sh: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.K4wDwX (%prep)
Macro expanded in comment on line 443: %{rpmversion}-%{pkgrelease}.tar.xz
Upon inspecting the permissions of the generate_all_configs.sh script in the checked-out repository, we can see that it is not marked as executable:
$ ls -l SOURCES/generate_all_configs.sh
-rw-r--r--. 1 user user 677 Dec 24 12:06 SOURCES/generate_all_configs.sh
Expected Behavior:
Executable files in the SRPM should retain their execute permissions when imported into the git repository. Scripts like generate_all_configs.sh should be marked as executable (-rwxr-xr-x), allowing them to run during the build process.
Actual Behavior:
Executable files lose their execute permissions during the import process, resulting in scripts that cannot be executed (-rw-r--r--), causing build failures.
Possible Causes:
The issue may stem from billy.Filesystem or go-git not preserving file permission metadata correctly during the import process.
There might be a misconfiguration or bug in the code that handles file system operations when importing SRPMs into git repositories.
The RPM unpacking process might correctly preserve permissions, but the subsequent addition of files to the git repository does not maintain these permissions -- we could just try and force chmod of the source file's perms.. need to debug.
The text was updated successfully, but these errors were encountered:
When importing SRPMs into git repositories, executable file permissions are not being preserved. This issue appears to occur in some, if not all, cases. The problem is likely related to an issue with
billy.Filesystem
orgo-git
, or possibly due to the interaction between the two.This behavior is particularly problematic for packages like the kernel, which include multiple build scripts that are expected to have the execute bit set. Without the correct permissions, these scripts cannot be executed during the build process, leading to failures.
Steps to Reproduce:
Example:
During the build process of the kernel package, the following error occurs due to missing execute permissions:
Upon inspecting the permissions of the
generate_all_configs.sh
script in the checked-out repository, we can see that it is not marked as executable:Expected Behavior:
Executable files in the SRPM should retain their execute permissions when imported into the git repository. Scripts like
generate_all_configs.sh
should be marked as executable (-rwxr-xr-x
), allowing them to run during the build process.Actual Behavior:
Executable files lose their execute permissions during the import process, resulting in scripts that cannot be executed (
-rw-r--r--
), causing build failures.Possible Causes:
billy.Filesystem
orgo-git
not preserving file permission metadata correctly during the import process.The text was updated successfully, but these errors were encountered: