Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better user feedback when Linux system package target is not available in the Docker registry #1368

Closed
rmartin16 opened this issue Jul 21, 2023 · 0 comments · Fixed by #1387
Labels
bug A crash or error in behavior. good first issue Is this your first time contributing? This could be a good place to start! linux The issue relates Linux support.

Comments

@rmartin16
Copy link
Member

rmartin16 commented Jul 21, 2023

Describe the bug

If a user targets a platform for which a suitable Docker image is not available, the user feedback doesn't really communicate that.

$ briefcase package --target fedora:37
Unable to find image 'fedora:37' locally
37: Pulling from library/fedora
docker: no matching manifest for linux/arm/v7 in the manifest list entries.
See 'docker run --help'.

Unable to determine if Docker is mapping users

While the above example is trying to pull an image for an architecture it doesn't provide, a simple misspelling creates the same situation.

briefcase package --target ubnutu
Unable to find image 'ubnutu:latest' locally
docker: Error response from daemon: pull access denied for ubnutu, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.

Unable to determine if Docker is mapping users

Steps to reproduce

Run briefcase package --target ubnutu

Expected behavior

I know the output explicitly says "unable to find image" but the "Unable to determine if Docker is mapping users" is in red and at least causes initial, if not entire, misdirection to the real problem.

Docker has different exit codes for when docker run fails versus when something inside a container goes wrong.

Therefore, I think we can catch and interpret these exit codes differently:

    125: docker run itself fails
    126: contained command cannot be invoked
    127: if contained command cannot be found
    128 + n Fatal error signal n:
        130 = (128+2) Container terminated by Control-C
        137 = (128+9) Container received a SIGKILL
        143 = (128+15) Container received a SIGTERM

In this way, we could detect 125 for any docker run call and output a more generic message about the target image.

Screenshots

No response

Environment

  • Operating System: pop os 22.04
  • Python version: 3.10.12
  • Software versions:
    • Briefcase: 0.3.16.dev19+g30ee4a80

Logs

briefcase.2023_07_21-11_31_11.package.log

Additional context

No response

@rmartin16 rmartin16 added bug A crash or error in behavior. linux The issue relates Linux support. labels Jul 21, 2023
@freakboy3742 freakboy3742 added the good first issue Is this your first time contributing? This could be a good place to start! label Jul 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A crash or error in behavior. good first issue Is this your first time contributing? This could be a good place to start! linux The issue relates Linux support.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants