3 ms·

The Reproducible Builds project aims to make it possible to not need to trust your build machines, perhaps PyPI could use that approach. https://reproducible-b

by pabs3 4y ago

The Reproducible Builds project aims to make it possible to not need to trust your build machines, perhaps PyPI could use that approach. https://reproducible-builds.org/ https://reproducible-builds.org/

westurner 4y ago
"Did the tests pass" for that signed Reproducible build? Conda > Adding packages > Running unit tests: https://conda-forge.org/docs/maintainer/adding_pkgs.html#running-unit-tests https://conda-forge.org/docs/maintainer/adding_pkgs.html#run... From https://github.com/thonny/thonny/issues/2181 https://github.com/thonny/thonny/issues/2181 : > * https://conda-forge.org/docs/maintainer/updating_pkgs.html https://conda-forge.org/docs/maintainer/updating_pkgs.html > Pushing to regro-cf-autotick-bot branch¶ When a new version of a package is released on PyPI/CRAN/.., we have a bot that automatically creates version updates for the feedstock. In most cases you can simply merge this PR and it should include all changes. When certain things have changed upstream, e.g. the dependencies, you will still have to do changes to the created PR. As feedstock maintainer, you don’t have to create a new PR for that but can simply push to the branch the bot created. There are two alternatives […] nektos/act is one way to run a github-actions.yml build definition locally; without CI (e.g. GitLab Runner, which requires ~--privileged access to the docker/Podman socket) to check whether you get the exact same build artifacts as the CI build farm https://github.com/nektos/act https://github.com/nektos/act A Multi-stage Dockerfile has multiple FROM instructions: you can build 1) a container for running the build which has build essentials like a compiler (GCC, LLVM) and packaging tools and keys; and 2) COPY the build artifact (probably one or more signed software packages) --from the build stage container to a container which appropriately lacks a compiler for production. https://www.google.com/search?q=multi+stage+Dockerfile https://www.google.com/search?q=multi+stage+Dockerfile Are there guidelines for excluding entropy like the commit hash and build time so that the artifact hashes are exactly the same; are reproducible on my machine, too?

by pabs3 4y ago

westurner 4y ago

"Did the tests pass" for that signed Reproducible build? Conda > Adding packages > Running unit tests: https://conda-forge.org/docs/maintainer/adding_pkgs.html#running-unit-tests https://conda-forge.org/docs/maintainer/adding_pkgs.html#run... From https://github.com/thonny/thonny/issues/2181 https://github.com/thonny/thonny/issues/2181 : > * https://conda-forge.org/docs/maintainer/updating_pkgs.html https://conda-forge.org/docs/maintainer/updating_pkgs.html > Pushing to regro-cf-autotick-bot branch¶ When a new version of a package is released on PyPI/CRAN/.., we have a bot that automatically creates version updates for the feedstock. In most cases you can simply merge this PR and it should include all changes. When certain things have changed upstream, e.g. the dependencies, you will still have to do changes to the created PR. As feedstock maintainer, you don’t have to create a new PR for that but can simply push to the branch the bot created. There are two alternatives […] nektos/act is one way to run a github-actions.yml build definition locally; without CI (e.g. GitLab Runner, which requires ~--privileged access to the docker/Podman socket) to check whether you get the exact same build artifacts as the CI build farm https://github.com/nektos/act https://github.com/nektos/act A Multi-stage Dockerfile has multiple FROM instructions: you can build 1) a container for running the build which has build essentials like a compiler (GCC, LLVM) and packaging tools and keys; and 2) COPY the build artifact (probably one or more signed software packages) --from the build stage container to a container which appropriately lacks a compiler for production. https://www.google.com/search?q=multi+stage+Dockerfile https://www.google.com/search?q=multi+stage+Dockerfile Are there guidelines for excluding entropy like the commit hash and build time so that the artifact hashes are exactly the same; are reproducible on my machine, too?