1. In "display_test_output": when printing dependencies without
linkage, use "Dependencies with no linkage" string instead of "Possible
unnecessary dependencies" for consistency with "display_normal_output"
2. In "check_dylibs": keep track of and skip repetitive checking of
those dylibs that have been previously checked. This is applicable when
different executables/libraries are linked against the same libraries.
3. In "check_undeclared_deps": when there are missing libraries,
corresponding dependencies should be excluded from the list of
dependencies with no linkage.
This can't be tapped on vanilla Homebrew/brew because things like e.g.
`GlibcRequirement` are missing. We will put this back when the Linuxbrew
to Homebrew migration is complete.
Allow at `install` (or `install --only-dependencies`) time to specify
that test dependencies should be installed. This will allow simplifying
code in `brew test-bot`.
This could also be made an environment variable if desired by
maintainers.
If the underneath file system is a Network File System,
`brew cleanup` will fail to remove the lock files with following error
message:
Error: Bad file descriptor @ rb_file_flock - /path/to/the/lock_file
This commit fixes such issue and adds the corresponding test case.
This commit improves Homebrew’s extension detector in `cask/lib/hbc/download_strategy.rb` a bit
so that it won’t cross individual URL query param boundaries any
longer:
```
def ext
Pathname.new(@url).extname[/[^?&]+/]
end
```
Sometimes, `brew cask fetch`/`install` fails with an error message
similar to this:
```
==> Downloading https://w3g3a5v6.ssl.hwcdn.net/upload2/game/214692/735
Error: Download failed on Cask 'steamed-hams' with message: Operation
not supported @ rb_sysopen -
/Users/claudia/Documents/dev/brew/var/homebrew/locks/steamed-hams--1.0
.com&Expires=1520937180&Signature=CGmDulxL8pmutKTlCleNTUY%2FyO9Xyl5u9y
VZUE0uWrjadjuz67Jp7zx3H7NEOhSyOhu8nzicEHRBjr3uSoOJzwkLC8LBLKnz%2B2X%2B
iq5m6IdwSVFcLp2Q1Hr2kR7ETn3rF1DIq5o0lHCyzMmyNe5giEKJNW8WF0KXriULhzLTWL
SA3ZTLCIofAdRiiGje1kNYY3C0SBqymQB8CG3ONn5kj7CIGbxrDOq5xI2ZSJdIyPysSX7S
LvEDBw2KdR24q9t1wfjS9LUzelf5TWk6ojj8p9%2FHjl%2Fi%2FVCXNN4o1mW%2FMayy2t
TY1qcC%2FTmqI1ulZS8SNuaSgr9Iys9oDF1%2BPK%2B4Sg==&hwexp=1520937440&hwsi
g=55bc66884b925ef22f8673c33bfcc33b.incomplete.lock
```
To reproduce the issue, check out this branch and run the
`cask/download_strategy` test suite:
```
brew tests --only=cask/download_strategy
```
Or take a real-life example, which would be a Cask whose URL has
**1.** no `.` character anywhere in the URL path itself (outside of
the domain name), **and 2.** at least one query parameter with a `.`
character in it; **and 3.** other query parameters following that
with a combined length of more than 255 characters.
This combination may be uncommon but it exists, especially in
[URLs that change on every visit](1002d41242/doc/cask_language_reference/stanzas/url.md (urls-that-change-on-every-visit)),
for example
[`steamed-hams`](9d7df499cd/Casks/steamed-hams.rb)
from my `claui/cask-games` tap:
$ brew tap claui/cask-games
$ brew cask fetch steamed-hams
In a nutshell, **URL query strings sometimes look like a very long
file extension to Homebrew,** which it then proceeds to use as a file
name.
In `CurlDownloadStrategy`, Homebrew seems to apply a heuristic to the
cask URL in order to figure out a possibly meaningful file extension.
Sometimes this heuristic produces immensely long file extensions,
especially when there’s a query parameter with a `.` character in it
but not in the URL path itself (outside of the domain name).
Homebrew then believes that everything after the `.` is a file
extension. In one of the later steps, it tries to create a lock file
containing that extension, which fails because HFS+ cannot handle
files whose base file name has more than 255 characters.
One solution would be to improve Homebrew’s extension detector a bit
so that it won’t cross individual URL query param boundaries any
longer. This is done by adding `&` as a stop character:
```
def ext
Pathname.new(@url).extname[/[^?&]+/]
end
```
This appears to fix the issue for most (if not all) practical
purposes.
Format for oneline can be overridden in user's gitconfig. If that's the
case, last_revision_commit_of_file won't work properly, and because of
that last_revision_of_file won't work at all.
Here's what I was getting when running brew tests:
expected: "6bec2de"
got: "\e[33m6bec2dee633f\e[m"
I have abbrev length set to 12, and oneline formatting is more colorful.
So, instead of relying on overrideable format, it should rather specify
"--format=%h" to get only hash, and speciy --abbrev=7 to force abbrev
length to be 7
After this commit tests are passing for me.
