search

macaroni-os / mark-issues

Macaroni Automated Repositories Kit Issues
4 stars 1 forks source link

[bug] [metatools] Implement archive integrity checking for downloaded funtoo-{go,crate}-bundle deps #54

Open cuantar opened 2 months ago

cuantar commented 2 months ago

If a bad zip file for a Go package is downloaded, it will get stored and end up in every funtoo-go-bundle (we should change this name, btw) that is produced afterward. The solution was documented on the Funtoo Jira that is now gone: Figure out which file is broken, grep around in repo_tmp/stores/integrity for the name of the file, and remove the files referring to it in the integrity database. Then regenerate the package, and it should be okay.

cuantar commented 2 months ago

This problem may also affect the funtoo-crate-bundles for Rust packages that are downloaded as gzipped archives.

cuantar commented 2 months ago

Another fix for this that doesn't involve attempting to penetrate the unassailable-by-mere-human-minds BLOS:

Keep the trees inside a subdir (such as trees/dev, for a dev tree instance) by setting $HOME in the script that runs merge-kits (you'll need to copy or symlink your credentials and configs for metatools that are in $HOME into the subdir). It probably makes sense to share the stores dir between trees, if you have more than one; a symlink will work, but it must be in the same filesystem as the rest of repo_tmp ... unfortunately.

Then if you cd do the trees/dev/source-trees/kit-fixups subdir, you can run doit --pkg ... as during development, and you'll get a new repo_tmp in your actual $HOME.

The new repo_tmp will have re-downloaded all the source files and constructed a new bundle, so you can do something like rsync -av ~/repo_tmp/stores/* ~/trees/_shared/stores/ (change the second path to wherever your production stores dir lives).

It worked for me --- I can now emerge a package that was broken in my local tree by this bug.