GHC 2017-09-21

2017-09-21 16:59:29, https://git.io/vdeSI in Homebrew/homebrew-core

No problem. @ilovezfs So currently the bot doesn't build 10.13 bottles by default? https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/9227/

2017-09-21 10:10:25, https://git.io/vdeeh in Linuxbrew/homebrew-core

Hmm, isn't GitHub now supposed to turn the link https://github.com/Linuxbrew/brew/blob/a04f14336a38d4ab0bec01686ae7f242d92a2eed/Library/Homebrew/formula_installer.rb#L424-L453 into an inline code snippet? Doesn't work cross repo?

Anyway, a copy of the snippet:

```rb
  def expand_requirements
    unsatisfied_reqs = Hash.new { |h, k| h[k] = [] }
    deps = []
    formulae = [formula]


    while f = formulae.pop
      runtime_requirements = runtime_requirements(f)
      f.recursive_requirements do |dependent, req|
        build = effective_build_options_for(dependent)
        install_bottle_for_dependent = install_bottle_for?(dependent, build)
        use_default_formula = install_bottle_for_dependent || build_bottle?
        req_dependency = req.to_dependency(use_default_formula: use_default_formula)


        if (req.optional? || req.recommended?) && build.without?(req)
          Requirement.prune
        elsif req.build? && install_bottle_for_dependent
          Requirement.prune
        elsif install_requirement_formula?(req_dependency, req, install_bottle_for_dependent)
          deps.unshift(req_dependency)
          formulae.unshift(req_dependency.to_formula)
          Requirement.prune
        elsif req.satisfied?
          Requirement.prune
        elsif !runtime_requirements.include?(req) && install_bottle_for_dependent
          Requirement.prune
        else
          unsatisfied_reqs[dependent] << req
        end
      end
    end
```

---

Test: https://github.com/Linuxbrew/homebrew-core/blob/59b343a86689531bc59702e376654821f766b1c8/Formula/glibc.rb#L16-L31

2017-09-21 10:06:17, https://git.io/vdeej in Linuxbrew/homebrew-core

@iMichka I finally looked into this and tracked down the root of the issue (almost). The key is the `gawk` formula.

Simple repro from a fresh Linuxbrew installation (basically you only need to install a single formula, `gawk`, from an old commit with outdated `glibc` and `gmp`:

```sh
# Inside homebrew/core
$ git checkout d5d8600
$ brew install gawk
...
$ git checkout master  # currently 31071ba
$ brew upgrade glibc
...
==> Installing dependencies for glibc: m4, gmp, mpfr
==> Installing glibc dependency: m4
==> Installing dependencies for m4: glibc
==> Installing m4 dependency: glibc
==> Installing dependencies for glibc: m4, gmp, mpfr
==> Installing glibc dependency: m4
...
```

There problem lies in `expand_requirements` in `formula_installer`: https://github.com/Linuxbrew/brew/blob/a04f14336a38d4ab0bec01686ae7f242d92a2eed/Library/Homebrew/formula_installer.rb#L424-L453

When `gawk` is not installed, system gawk satisfies the `GawkDependency` in `glibc.rc` and no extra dep is collected. When `gawk` is installed, though, the `GawkDependency` is still satisfied, but `req_dependency` becomes `gawk` rather than `nil`, and `install_requirement_formula?(req_dependency, req, install_bottle_for_dependent)` now returns `true` for whatever reason (I stopped my investigation there due to time constraint), pushing `gawk` back onto the deps stack. `gawk` then pulls in `gmp` resulting in the recursive deps situation.

I was never familiar with the requirements resolution part of brew and AFAIK it has always been a pain... Someone will need to take a look, but I bow out here :joy: I uninstalled gawk and called it a day. Honestly I have no idea what pulled in gawk in the past on my affected server.

2017-09-21 07:10:56, https://git.io/v5jMv in Homebrew/homebrew-core

> but if I'm not mistaken, El Cap's libSystem should have renameatx_np?

Nah, on second thought, `renameatx_np` was added for APFS, so it shouldn't be available at runtime on 10.11. I was getting my timeline mixed up. So this is probably just another one of those good old single SDK problems.

2017-09-21 07:04:32, https://git.io/v5jMf in Homebrew/homebrew-core

Looking closer at your issue, it has nothing to do with the patch I removed. The patch was for `MacOS.version < :yosemite`, and you're running El Cap. The patch was for missing `renameat` at compile time; your problem is missing `renameatx_np` at run time (but not compile time?). This smells like one of those weak linking issues to me, but if I'm not mistaken, El Cap's libSystem should have `renameatx_np`? I'm afraid I don't want to spin up a VM to test this at the moment.

Anyway, this is something to be reported upstream.

2017-09-21 06:57:11, https://git.io/v5ji0 in Homebrew/homebrew-core

Sorry, I removed the patches in adb4e37, and I'm afraid I don't understand "those patches were never actually added to a stable release". The issue was fixed upstream in https://github.com/coreutils/coreutils/commit/e3c51a3357cf9486040e94ee404d26af8ba7276a and it is certainly in the 8.28 tree; you can find `renameat.c` and `renameat.m4` in the release tarball.