Skip to content
Peter Scheibel edited this page Dec 14, 2023 · 21 revisions

Wednesday December 13th, 9am PT (UTC -8:00)

Attendees

  • Peter Scheibel (host)
  • Patrick Gartung
  • Gary Kedziora
  • Mark Krentel
  • Dom Heinzeller
  • Massimiliano Culpo
  • Pariksheet Nanda
  • Prentice Bisbal
  • Tammy Dahlgren
  • Walter Nissen
  • Yang Liu
  • Frank
  • IUCY
  • Jakov Petrina

Agenda

Q&A

  • Gary: have a shared filesystem; using a Spack env with a view
    • Started using it on a zen3 arch, built it on a sandybridge machine
    • setup-env.sh is failing
      • Note: spack is usable at this point, but there is a message about failing to load modules
    • Massimiliano: these architectures are strictly incompatible
    • Suggestion: create a new environment on the new system; reconcretize (spack will automatically detect the other arch and use that)
      • (in particular this should work because the user did not add any config related to targets, so Spack's default is to autodetect the arch wherever it is running and build with that)
  • Prentice: Many build issues: why is that?
    • Prentice: many externals listed: is that part of the issue?
      • For now tried stripping those out (except for openssl, mpi, etc)
    • Patrick: for seldom-maintained packages, or building on new systems, build errors can be frequent
    • Patrick: Must be careful of path to externals - some systems like RedHat that don't have the -devel package won't have the header files. Also some [spack] packages want python files in the root path, which with system packages may fail.
    • petsc couldn't find autotools, cmake etc.
      • Could be an issue with setting prefixes for externals
  • Yang: was able to run a spack command in one spack env but not another

Review permissions

  • Possible continuation from https://github.com/spack/spack/wiki/Telcon%3A-2023-12-06: Discussion of Package review / merge permissions

    • The last 20 minutes is reserved for this
  • Pariksheet:

    • Interested in path from [person who writes their own packages] to [reviewer]
    • There is a "role" in github for people who can add tags
      • Anyone can leave a review though
      • You might need "triage", but if you add yourself as a maintainer on a package (or someone else adds you) or if you submit a PR, then spackbot will invite you to this
    • According to https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews, anyone can review
    • Pariksheet: can this be documented?
      • Todd: yes - we can update the developer docs
    • Tammy: would a checklist for reviewing packages be useful?
      • Pariksheet: yes
    • We could update our contributing.md file
      • Todd: right now it's a link to the contribution docs
      • also it lives in .github
Clone this wiki locally