Skip to content

Reduce visibility of package_manager - #469

Merged
chanseokoh merged 2 commits into
masterfrom
reduce-visibility
Feb 19, 2020
Merged

Reduce visibility of package_manager#469
chanseokoh merged 2 commits into
masterfrom
reduce-visibility

Conversation

@chanseokoh

@chanseokoh chanseokoh commented Feb 19, 2020

Copy link
Copy Markdown
Member

Turns out this is unnecessary.

I have confirmed building and publishing all images by

  1. First building and uploading this PAR to a temporary bucket.
  2. Updating WORKSPACE to use the new PAR, which required updating the SHA of the binary.
  3. Build and publishing Distroless images on GCB (to my GCP project).

@googlebot googlebot added the cla: yes CLAs look good label Feb 19, 2020
@ianoc-stripe

Copy link
Copy Markdown

@chanseokoh Have you been making other changes to the GCP blob storage used here by chance? a bunch of our CI infra got taken out with 403's a an older version of this par. and sha 256 failures against master

@ianoc-stripe

Copy link
Copy Markdown

We use these utils to add back in packages that are missing in the distroless, like liblcms2-2 which causes some image handling in the jdk to blowup

@chanseokoh

chanseokoh commented Feb 19, 2020

Copy link
Copy Markdown
Member Author

@ianoc-stripe maybe try https://storage.googleapis.com/distroless/package_manager_tools/01579c3dd0f9b4397fe4f50769a9caea130b15e7/dpkg_parser.par Or just sync your distroless fork with the master.

But note that these binaries can be removed in the future.

@chanseokoh

Copy link
Copy Markdown
Member Author

Or just sync your distroless fork with the master.

Ah, yeah, this won't work for now, but it will start working again after merging #469 and fixing an intermediate inconsistency.

@ianoc-stripe

ianoc-stripe commented Feb 19, 2020

Copy link
Copy Markdown

Thanks for the quick reply!

For now i replaced the remote ref with the http_file and updated the sha to the right one, so its unblocked the ci flows.

wrt that the binaries can be removed, is this code we should fork/not depend on?

@chanseokoh

chanseokoh commented Feb 19, 2020

Copy link
Copy Markdown
Member Author

wrt that the binaries can be removed, is this code we should fork/not depend on?

In principle, any fork of the repo should build successfully. What happened is that, when I prepared #469, I replaced the current dpkg_parser.par binary in order to make the Travis builds to pass. This changed the SHA, but now I find that was a mistake. Once #469 is merged, a new dpkg_parser.par will be built. After that, I will fix master to use the new binary.

@ianoc-stripe

Copy link
Copy Markdown

Ah thats perfect, @chanseokoh . Thank you. I was just a little concerned if we were depending on something we shouldn't have been here. Appreciate the great work that goes into this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes CLAs look good

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants