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

WIP: Feature: creation of relocatable tarballs from installed packages #1013

Closed
wants to merge 193 commits into from

Conversation

gartung
Copy link
Member

@gartung gartung commented Jun 1, 2016

This extends #445 which allows the creation of binary tarballs from installed packages and the installation of those tarballs on other machine with the appropriate rewriting of rpaths with patchelf on linux or install_name_tool on macos.

hegner and others added 30 commits February 17, 2016 02:23
Add recursion and force-overwrite to create-tarball.
 o Add lazy policy for install
 o Use Stage class for download
 o Add meta-data
 o Improve logging
@gartung
Copy link
Member Author

gartung commented Jul 14, 2017

@mathstuf I added the gpg2 signing and verification as options.

@gartung
Copy link
Member Author

gartung commented Jul 14, 2017

@mathstuf
Should I include this file?
spack/opt/spack/gpg/pubring.kbx

@mathstuf
Copy link
Contributor

Hmm, there should probably be a .gitignore for that file. I'll make a PR.

As for signing, I think it shouldn't be an option. Packages should always be signed when created and there should be a (hidden?) option to skip verification of packages when installing them.

@mathstuf
Copy link
Contributor

Oh, that file is under opt. That entire directory should be ignored already.

@gartung
Copy link
Member Author

gartung commented Jul 14, 2017

I see that there is a keys directory in
spack/var/spack/gpg.mock/keys/external.key

Should I put my public key in
spack/var/spack/gpg/keys

@gartung
Copy link
Member Author

gartung commented Jul 14, 2017

Does the buildcache command need an upload subcommand? We usually do that by hand or with and external script.

…/spack/gpg and spack gpg init to add them as trusted keys.:
@gartung
Copy link
Member Author

gartung commented Jul 14, 2017

@mathstuf
Can spack/opt/spack/gpg/ be moved to another spack install? I want to preserve it to I don't have to keep adding public keys for every spack install where I have run "spack pgp create".

@mathstuf
Copy link
Contributor

Can spack/opt/spack/gpg/ be moved to another spack install?

Yes, that directory should be relocatable (it's just a spack-specific $HOME/.gnupg directory).

except fs.FetchError:
next
if install:
Gpg.trust(stage.save_filename)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should be a verification before this. Something like:

This package is signed by this key:

<key info>

Do you want to trust this key? [y/N] > 

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or this key was found on mirror <mirror name>.

@becker33
Copy link
Member

@gartung it looks to me like codecov is reporting coverage properly. I find the diff view in codecov is the easiest to interpret.

I would certainly like to see more tests for this feature, with the caveat that I have not yet reviewed it sufficiently to have any understanding of how difficult it will be to create those tests.

@adamjstewart
Copy link
Member

Another thing to clarify about the Codecov values is that they are the comparison of this branch with the current develop, not with develop at the time this PR branched off. If coverage has increased in develop since you branched off, it will show up in the diff here. So if you rebase on the tip of develop, you'll get a better idea at how the global coverage is being affected. With that said, the codecov/patch is probably accurate.

@gartung
Copy link
Member Author

gartung commented Jul 20, 2017

So the red in the diff view is code that is not covered by a test?

@adamjstewart
Copy link
Member

Well, the red in the "Files changed" view is lines that were removed, but if you install the Codecov extension, the red lines will be lines not covered by unit tests.

@becker33
Copy link
Member

The muted red/green background in the "diff" view is the changes to the code, but the bright red/green bar on the left is covered/not covered lines of code

@gartung
Copy link
Member Author

gartung commented Jul 21, 2017

I am going to resubmit once I get this code coverage thing figured out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.