Skip to content

meson dist crashes with git -C /sourcedir update-index failing read-only file system #13461

Closed

Description

@martinpitt

Describe the bug

My project runs tests in containers, which get the original source directory bind-mounted as a volume into the container's /source.

With Debian testing moving from meson 1.4.1 to 1.5.0, running the build now fails reliably in GitHub actions:

+ meson dist --no-test --allow-dirty
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mesonbuild/mesonmain.py", line 188, in run
    return options.run_func(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/mesonbuild/mdist.py", line 371, in run
    names = project.create_dist(archives)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/mesonbuild/mdist.py", line 200, in create_dist
    self.process_git_project(self.src_root, self.distdir)
  File "/usr/lib/python3/dist-packages/mesonbuild/mdist.py", line 161, in process_git_project
    if self.have_dirty_index():
       ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/mesonbuild/mdist.py", line 143, in have_dirty_index
    subprocess.check_call(['git', '-C', self.src_root, 'update-index', '-q', '--refresh'])
  File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['git', '-C', '/source', 'update-index', '-q', '--refresh']' returned non-zero exit status 128.

ERROR: Unhandled python exception

    This is a Meson bug and should be reported!

To Reproduce

I'm a bit confused by this. I can replicate this 100% in a "full" debug build with

git clone https://github.com/martinpitt/umockdev
cd umockdev
DEBUG=1 tests/run-apt docker.io/amd64/debian:testing

That fails. Enter the container with

podman start -l
podman exec -itl bash
su -s /bin/bash - build
cd /tmp/dbg
meson dist --no-test --allow-dirty

That reproduces it as well. I can also directly run the git command which explains the reason:

build@15f92f2cd7a5:/tmp/dbg$ git -C /source/ update-index --refresh
fatal: Unable to create '/source/.git/index.lock': Read-only file system

Yes, that's intended -- I do not want tests or anything in the build dir to change the source tree or git status.

However, about 3 minutes later running the exact same git or meson command started to succeed.

It should be possible to reproduce it in a stripped down version of the container invocation:

podman run -it --rm -v .:/source docker.io/amd64/debian:testing sh -exc 'apt update; apt install -y meson git valac libudev-dev libpcap-dev; meson setup /tmp/build /source; meson dist -C /tmp/build --no-test --allow-dirty'

but that works.

There seems to be something weird going on with git in the background, which sometimes seems to access the source directory in a writable manner.

That update-index command is apparently new -- can it be adjusted to tolerate failure, or not be done on read-only source dirs?

system parameters

  • Is this a cross build or just a plain native build (for the same computer)?: no
  • what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.): Debian testing
  • what Python version are you using: 3.12.4
  • what meson --version: 1.5.0
  • what ninja --version if it's a Ninja build: 1.12.1

Activity

  1. added this to the 1.5.1 milestone on Jul 22, 2024
  2. added a commit that references this issue on Jul 22, 2024
    174c313
  3. eli-schwartz commented on Jul 22, 2024

    @eli-schwartz
    Member

    That update-index command is apparently new -- can it be adjusted to tolerate failure, or not be done on read-only source dirs?

    Yes -- there's no reason we should care about its return value at all. The sole purpose of it is to make the next command more likely to return correct information. See above ^^

  4. martinpitt commented on Jul 22, 2024

    @martinpitt
    Author

    Thanks @eli-schwartz for the super-fast fix! 🌟

  5. added a commit that references this issue on Jul 22, 2024
    e9037e7
  6. added a commit that references this issue on Jul 25, 2024
    19d31ad
  7. added a commit that references this issue on Feb 19, 2025
    5a98448
  8. added a commit that references this issue on May 1, 2025
    729b602
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions