On Wed, Jul 26, 2017 at 06:19:16PM +0200, Clemens Lang wrote:
Hi,----- On 25 Jul, 2017, at 17:27, Rainer Müller rai...@macports.org 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-d7db55f70d83fc9dba4ef14de9febe71Should 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.
I prefer using a separate repository (only containing .travis.yml and maybe patches, not MacPorts source) because I can update the binaries by creating a new release (tag) on the same commit (MacPorts version can be read from tag name) and keep the setup for ports CI away from macports-base (they aren't related in my opinion).
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.
From https://bintray.com/docs/terms_of_service.html: You may not, whether by yourself or anyone on your behalf, unless otherwise explicitly permitted under these Terms: (xxvii) in connection with Contributions, upload and/or store on the Site continuous integration artifacts or nightly builds, (i.e. you may only upload and store content in direct connection to official software releases). A tag counts as official software releases. But the latest commit doesn't.
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.
That change didn't work and I committed another fix (not verified yet): https://github.com/macports-staging/macports-base/commit/84b040fbcb1134e5cab1cc10cfc991c2d05c4824#diff-d7db55f70d83fc9dba4ef14de9febe71 Also, the other bug (Warning: Failed to copy com.apple.dt.Xcode.plist ... [1]) is not fixed. [1] https://travis-ci.org/macports/macports-ports/jobs/249233655
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
-- Best regards, Zero King
smime.p7s
Description: S/MIME cryptographic signature
