Skip to content
Todd Gamblin edited this page Aug 18, 2016 · 9 revisions

Participants

  1. Todd Gamblin (LLNL)
  2. Greg Becker (LLNL)
  3. Mario Melara (NERSC)
  4. Patrick Gartung (Fermi)
  5. Elizabeth Fischer (NASA)
  6. Ben Boeckel (Kitware)
  7. Joe Ciurej (LLNL)
  8. Robert French (ORNL)
  9. Peter Scheibel (LLNL)
  10. Greg Lee (LLNL)
  11. Matt Legendre (LLNL)
  12. Others (forgot to screenshot the webex).

News

  1. Spack is now PEP8 compliant.
  • Sorry this didn't happen sooner -- should've probably converted everything first then started checking.
  • Travis errors on PRs now meaningful again (after rebase)
    • no more need for "fix flake8 errors" commits
  • Flake check is also separate in Travis now thanks to @alalazo
    • can quickly see whether flake failed or something else.
  1. Faster virtuals #1015 now merged
  • Should make concretization much faster
  • Spack will load only as many package.py files as necessary for concretization.
    • no more need to scan all of them to determine virtual providers
    • this is now cached in ~/.spack/cache/providers
    • can clear this cache with spack purge --user-cache, spack purge -a (purges more stuff), or just remove the directory
  • Spack will still do a fast check of all package.py files to see which have been updated
    • requires one stat per file, much faster than loading.
  • various other optimizations in this PR
  1. Reviewed #1013 -- binary package caches
  • How to handle security issues?

    • checksumming every tarball for every DAG hash will become cumbersome to maintain
    • consider signing packages with GPG like Debian?
  • @gartung: RPM @Fermi uses checksums and a trusted server.

  • @benedikt: signing hashes makes a lot of sense

    • @tgamblin: if the key comes with spack, they'd have to hack GitHub and the mirror, which is acceptable level of security.
    • @benedikt: how to distribute the public key?
      1. possible issue: as number of people who can build binaries increases, may need to distribute many public keys.
      2. option to have a repo full of checksums on github as well would be good
    • @tgamblin to bounce these options off security folks at LLNL
    • @benedikt to bounce these options off security folks at CERN
  1. A number of spec-changing PRs will be merged this week.
  • Various issues related to stable hashing
    • @boeckel: Python may be seeding random number generator randomly now, may affect hashing (which may have caused this to bubble up) LWN article.
    • @scheibelp: deptype re-ordering seems to be frequent, so maybe an issues w/o RNG
  • lowercase architecture names
  1. @xrjc: New Python PR makes extension packages independent of user configuration.
  • Changes the way setup_py is called in Python packages
  • avoids using user distutils configuration
  • updated with PEP8 compliance now :)
  • Shouldn't change any hashes, just package.py files
  1. @xrjc: fetching from some LLNL buildings fails when using curl without a status bar.
  • @tgamblin: suggest overriding curl arguments with env var.
  • @mathstuf: look at curl config as well.
  1. @citibeth: curl cert checking adding zero security when we do have checksums.
  • only place where this should matter is fetch methods that don't checksum (git w/o commit, svn, etc.)
  • suggest smarter secure mode where we make sure we have either checksum or SSL
    • SSL probably less secure than checksum since if server is compromised, you don't have a hash from a second party.
Clone this wiki locally