Hi, ----- On 25 Jul, 2017, at 17:27, Rainer Müller [email protected] wrote:
> On 2017-07-22 13:26, Zero King wrote: >> In [1], I patched MacPorts in an attempt to fix a bug (port(1) failed >> randomly on Travis). As it seems to be a Travis-specific bug, I plan to >> use a separate repository to generate MacPorts archives used in CI and >> keep the patch there. This way we can update the CI-specific archives >> without a new release in macports-base (e.g. when new releases of macOS >> become available on Travis). >> >> [1]: >> https://github.com/macports-staging/macports-base/commit/282e498ac51ba40bdfd43008ce430ca20a7d54ce#diff-d7db55f70d83fc9dba4ef14de9febe71 > > Should we keep a separate branch in the base repository for this? We > could cherry-pick such hotfixes to that branch (could also be restricted > to infrastructure team). I don't think we need a whole other repository > for this and we should keep everything in one organization. Exactly my thoughts as well. Having a separate branch allows us to quickly deploy fixes without the overhead of a separate repository not used for anything else. Ideally, we should set up the macports-base Travis CI to automatically build and publish the latest commit on that branch and the macports-ports CI to automatically use the latest archive from that branch. For example, we could upload a generated archive to Bintray and update a file that always contains the URL to the latest archive and just download that in the Travis CI job. > Besides that, I see no reason that this change could not go into regular > base with a comment explaining why it is necessary. Agree here, please commit the change in macports-base. > To debug the issue at hand, you could try to inject a > system "/bin/ls -laeO@ ${target_dir}" > right before the 'file delete' to find out if there is anything like an > immutable flag on this file or directory. This might also happen if our builds are run under a sandbox, which could denies deleting files in this location. -- Clemens Lang
