Bug 1936939 - osbs-client fails to build with Python 3.10: E subprocess.CalledProcessError: Command '['git', 'rev-parse', 'HEAD']' returned non-zero exit status 128.
Summary: osbs-client fails to build with Python 3.10: E subprocess.CalledProcessError:...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: osbs-client
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clement Verna
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
: 1968853 (view as bug list)
Depends On:
Blocks: F35FTBFS F35FailsToInstall F36FTBFS PYTHON3.10 F35BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2021-03-09 14:02 UTC by Tomáš Hrnčiar
Modified: 2021-08-30 21:40 UTC (History)
10 users (show)

Fixed In Version: osbs-client-1.11.0-2.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-30 21:40:51 UTC
Type: Bug


Attachments (Terms of Use)

Description Tomáš Hrnčiar 2021-03-09 14:02:48 UTC
osbs-client fails to build with Python 3.10.0a6.

=================================== FAILURES ===================================
______________________________ test_get_repo_info ______________________________

tmpdir = local('/tmp/pytest-of-mockbuild/pytest-0/test_get_repo_info0')

    def test_get_repo_info(tmpdir):
        repo_path = tmpdir.mkdir("repo").strpath
        with open(os.path.join(repo_path, REPO_CONTAINER_CONFIG), 'w') as f:
            f.write(dedent("""\
                compose:
                    modules:
                    - n:s:v
                """))
    
>       initialize_git_repo(repo_path, files=[REPO_CONTAINER_CONFIG])

tests/utils/test_utils.py:531: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/utils/test_utils.py:548: in initialize_git_repo
    first_commit_ref = subprocess.check_output(['git', 'rev-parse', 'HEAD'], cwd=rpath)
/usr/lib64/python3.10/subprocess.py:429: in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

input = None, capture_output = False, timeout = None, check = True
popenargs = (['git', 'rev-parse', 'HEAD'],)
kwargs = {'cwd': '/tmp/pytest-of-mockbuild/pytest-0/test_get_repo_info0/repo', 'stdout': -1}
process = <Popen: returncode: 128 args: ['git', 'rev-parse', 'HEAD']>
stdout = b'HEAD\n', stderr = None, retcode = 128

    def run(*popenargs,
            input=None, capture_output=False, timeout=None, check=False, **kwargs):
        """Run command with arguments and return a CompletedProcess instance.
    
        The returned instance will have attributes args, returncode, stdout and
        stderr. By default, stdout and stderr are not captured, and those attributes
        will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture them.
    
        If check is True and the exit code was non-zero, it raises a
        CalledProcessError. The CalledProcessError object will have the return code
        in the returncode attribute, and output & stderr attributes if those streams
        were captured.
    
        If timeout is given, and the process takes too long, a TimeoutExpired
        exception will be raised.
    
        There is an optional argument "input", allowing you to
        pass bytes or a string to the subprocess's stdin.  If you use this argument
        you may not also use the Popen constructor's "stdin" argument, as
        it will be used internally.
    
        By default, all communication is in bytes, and therefore any "input" should
        be bytes, and the stdout and stderr will be bytes. If in text mode, any
        "input" should be a string, and stdout and stderr will be strings decoded
        according to locale encoding, or by "encoding" if set. Text mode is
        triggered by setting any of text, encoding, errors or universal_newlines.
    
        The other arguments are the same as for the Popen constructor.
        """
        if input is not None:
            if kwargs.get('stdin') is not None:
                raise ValueError('stdin and input arguments may not both be used.')
            kwargs['stdin'] = PIPE
    
        if capture_output:
            if kwargs.get('stdout') is not None or kwargs.get('stderr') is not None:
                raise ValueError('stdout and stderr arguments may not be used '
                                 'with capture_output.')
            kwargs['stdout'] = PIPE
            kwargs['stderr'] = PIPE
    
        with Popen(*popenargs, **kwargs) as process:
            try:
                stdout, stderr = process.communicate(input, timeout=timeout)
            except TimeoutExpired as exc:
                process.kill()
                if _mswindows:
                    # Windows accumulates the output in a single blocking
                    # read() call run on child threads, with the timeout
                    # being done in a join() on those threads.  communicate()
                    # _after_ kill() is required to collect that and add it
                    # to the exception.
                    exc.stdout, exc.stderr = process.communicate()
                else:
                    # POSIX _communicate already populated the output so
                    # far into the TimeoutExpired exception.
                    process.wait()
                raise
            except:  # Including KeyboardInterrupt, communicate handled that.
                process.kill()
                # We don't call process.wait() as .__exit__ does that for us.
                raise
            retcode = process.poll()
            if check and retcode:
>               raise CalledProcessError(retcode, process.args,
                                         output=stdout, stderr=stderr)
E               subprocess.CalledProcessError: Command '['git', 'rev-parse', 'HEAD']' returned non-zero exit status 128.

/usr/lib64/python3.10/subprocess.py:533: CalledProcessError
----------------------------- Captured stdout call -----------------------------
Initialized empty Git repository in /tmp/pytest-of-mockbuild/pytest-0/test_get_repo_info0/repo/.git/
----------------------------- Captured stderr call -----------------------------
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint: 	git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint: 	git branch -m <name>
fatal: not in a git directory
Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <"ghost">) not allowed
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-rawhide-x86_64/02061057-osbs-client/

For all our attempts to build osbs-client with Python 3.10, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/osbs-client/

Testing and mass rebuild of packages is happening in copr. You can follow these instructions to test locally in mock if your package builds with Python 3.10:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/

Let us know here if you have any questions.

Python 3.10 will be included in Fedora 35. To make that update smoother, we're building Fedora packages with early pre-releases of Python 3.10.
A build failure prevents us from testing all dependent packages (transitive [Build]Requires), so if this package is required a lot, it's important for us to get it fixed soon.
We'd appreciate help from the people who know this package best, but if you don't want to work on this now, let us know so we can try to work around it on our side.

Comment 1 Miro Hrončok 2021-06-04 20:13:47 UTC
This is a mass-posted update. Sorry if it is not 100% accurate to this bugzilla.


The Python 3.10 rebuild is in progress in a Koji side tag. If you manage to fix the problem, please commit the fix in the rawhide branch, but don't build the package in regular rawhide.

You can either build the package in the side tag, with:

    $ fedpkg build --target=f35-python

Or you can the build and we will eventually build it for you.

Note that the rebuild is still in progress, so not all (build) dependencies of this package might be available right away.

Thanks.

See also https://fedoraproject.org/wiki/Changes/Python3.10

If you have general questions about the rebuild, please use this mailing list thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/G47SGOYIQLRDTWGOSLSWERZSSHXDEDH5/

Comment 2 Miro Hrončok 2021-06-07 22:58:31 UTC
The f35-python side tag has been merged to Rawhide. From now on, build as you would normally build.

Comment 3 Miro Hrončok 2021-06-08 11:19:07 UTC
*** Bug 1968853 has been marked as a duplicate of this bug. ***

Comment 4 Miro Hrončok 2021-06-15 20:26:08 UTC
Hello,

This is the first reminder (step 3 from https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs).

If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem.

Comment 5 Clement Verna 2021-06-25 12:10:08 UTC
I ll be offline for the next 2 weeks but will see if someone in Fedora Infra can look at this

Comment 6 Miro Hrončok 2021-07-07 11:23:58 UTC
Hello,

This is the second reminder (step 4 from https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs).

If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem.

Comment 7 Fedora Release Engineering 2021-07-11 04:22:40 UTC
Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 35.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2021-05-04).

A week before the mass branching of Fedora 36 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 34 will be
retired regardless of the status of this bug.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
[2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
[3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html

Comment 8 Ben Cotton 2021-08-10 12:54:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 9 Miro Hrončok 2021-08-23 11:30:45 UTC
Clement, what is the status here? Are you working on a fix? Is upstream notified?

Comment 10 Clement Verna 2021-08-24 15:34:26 UTC
Ha I started to look at it but got stuck and it fell of my radar. I ll contact upstream to see if they can have a look at it.

Comment 11 Clement Verna 2021-08-25 06:54:08 UTC
We have an upstream fix https://github.com/containerbuildsystem/osbs-client/pull/1030, I ll look at packaging it and rebuild the package

Comment 13 Fedora Update System 2021-08-25 09:26:13 UTC
FEDORA-2021-32fdb28f8e has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-32fdb28f8e

Comment 14 Miro Hrončok 2021-08-25 09:27:14 UTC
Nominating as FE as this package does not install without the fix.

Comment 15 Fedora Update System 2021-08-25 18:36:44 UTC
FEDORA-2021-32fdb28f8e has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-32fdb28f8e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-32fdb28f8e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Miro Hrončok 2021-08-25 22:54:16 UTC
Hello,

Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok).

All subpackages of a package against which this bug was filled are now installable or removed from Fedora 36.

Thanks for taking care of it!

Comment 17 Adam Williamson 2021-08-30 18:40:21 UTC
Discussed at 2021-08-30 blocker/FE review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021/fedora-blocker-review.2021-08-30-16.01.html . Accepted as a freeze exception issue as a fails-to-install bug, which we usually take as FEs to improve the upgrade experience during freeze unless there is some special consideration.

Comment 18 Fedora Update System 2021-08-30 21:40:51 UTC
FEDORA-2021-32fdb28f8e has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.