* Use `Tap#formula_dir` instead of `Tap#formula_files` to find formula
file to have better performance and avoid caching issue.
* Change the loader logic to search name -> search alias -> search old name.
This is more consistence with what we do when loading core formula
file.
ClosesHomebrew/homebrew#49484.
Signed-off-by: Xu Cheng <xucheng@me.com>
Fixes a regression introduced by Homebrew/homebrew#47950 in 9e3ee3e causing build
failures with the error
cabal: The file does not exist ''.
This will occur whenever the optional :flags key isn't in the options
hash passed to install_cabal_package.
ClosesHomebrew/homebrew#49425.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
When there are merge conflicts we fail pretty hard. This is still
possible after this commit but at least we've given Git enough pointers
to make it less likely.
ClosesHomebrew/homebrew#49299.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
To address issue Homebrew/homebrew#47346 (git-annex-webapp missing), we explicitly
enable the "webapp" flag for git-annex. This should prevent git-annex
from being built without the webapp and make the build fail if there is
e.g. a dependency issue.
ClosesHomebrew/homebrew#47950.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
The default max-backjumps can be too low, especially since
Language::Haskell::Cabal doesn't guarantee an LTS config.
In particular, this fixes a git-annex build failure in Homebrew/homebrew#47950ClosesHomebrew/homebrew#49158.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
FileUtils::fu_get_gid only started doing the conversion of the group
to_s automatically from OS X 10.6.8 (ruby-1.8.7-p358) forward.
OS X 10.6.7 (ruby-1.8.7-p174) would fail in brew's FileUtils::mktemp with the
error "Error: can't convert Fixnum into String."
FixesHomebrew/homebrew#49045FixesHomebrew/homebrew#49348ClosesHomebrew/homebrew#49369.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
The default HOMEBREW_LIBRARY_PATH should be
/usr/local/Library/Homebrew
not
/usr/local/Library/Homebrew/Homebrew
ClosesHomebrew/homebrew#49384.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Main reasons for boneyard:
* As this formula now stands, it fails to build (with a mysterious
error) against FFmpeg 3.0 (#49178);
* This is a GUI-only tool (look at its awkward test), so it doesn't
quite belong to core to begin with; and due to the build issue above,
work is needed if it is to be revived in homebrew/gui;
* There's not enough interest, seeing that we are two releases or half a
year behind, and no user even proposed a version bump;
* Upstream's preferred method of installation is the app bundle (which
seems to be a much more complete solution, given the app bundle's
size), distributed in binary disk images.
More discussions in Homebrew/homebrew#49178.
ClosesHomebrew/homebrew#49378.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
* Blocks writing of new files via accidental typos, etc, which the normal open("blah", "a") doesn't.
* Where files don't exist they should ideally be using `(buildpath/"dog").write` instead of open("blah", "a") already.
* It's a bit less cluttered looking if you need several writes to different files in the formula, IMO.
In theory, letting these be set once wasn't an awful idea because it allows
users choice on where Perl modules end up.
In reality, as we've moved closer to sandboxing and at the same time accepted more
perl binding options into formulae it has been exposed as something of a hellraiser.
It's not that uncommon for Perl users to set a custom `INSTALL_BASE` in the ENV which
means we end up with quite a few formula that fail hard with this sort of error:
```
Only one of PREFIX or INSTALL_BASE can be given. Not both.
```
The other common error, which we discovered via sandboxing, is that the Perl modules
end up outside Homebrew's control which means we don't automatically remove them
when the package is removed. Sandboxing blocks this, which means when we eventually
move to enable that by default for users as well as CI it'll quickly become a
prominent issue.
The recent updates to OSXFuse include two new elements that get flagged by
`brew doctor`. Adding them here so it's consistent with how we handle the rest
of OSXFuse.
ClosesHomebrew/homebrew#49372.
Boneyarding because:
1. Not compatible with FFmpeg 3.0 (#49178);
2. Not developed in the open, only release tarballs are available, so
tracking progress is hard;
3. Latest release is from April 2013;
4. Has to join a mailing list to report bugs, the archive of which was
last built in 2014.
In summary, there's no evidence that this library is not abandoned.
See also discussions in Homebrew/homebrew#49178.
ClosesHomebrew/homebrew#49268.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
Groups make it easier to get an overview of the coverage without having
to scan through a single very long list of files. They also display a
possibly helpful per-group coverage.
The project name is normally derived from the `root` directory which
happens to be `Library` in our case, thus make it explicitly `Homebrew`.
ClosesHomebrew/homebrew#49303.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
This should help to prevent situations where a user accidentally ends up
"stranded" in a branch indefinitely.
Additionally, the stash is never popped automatically at the end of a
successful update, but the stash-pop message is printed if something is
stashed.
When an interrupt occurs, the original behavior is still in place
(switch back to the old branch and revision, and pop the stash), though
this could be changed as well.
This commit modifies the behavior of both `brew update` and
"update-bash.sh" in the manner described above.
The idea for this approach is from Mike McQuaid.
Issue Homebrew/homebrew#48812ClosesHomebrew/homebrew#48993.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Check to see if `HEAD` is the same as what we have locally. If it is:
don't bother to `git fetch`.
ClosesHomebrew/homebrew#47888.
ClosesHomebrew/homebrew#49219.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
We haven't seen this for a fair while since Apple pushed further updates to the
SIP mechanism and believe it to be far less of an issue than it was previously.
If you encounter further failure, please file an Issue and we'll be happy to
help! At the moment though this advice is making people think there _will_ be an
issue at some point, which isn't generally proving the case.
