python@3.9: update wheel

[Rylan12]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

Update the wheel resource to the latest version. This pulls in the fix for the Big Sur issue reported in pypa/wheel#385. Since this solves an issue that's been causing problems for users, I've bumped the revision as well.

CC: @fxcoudert

[carlocab]

Is there something wrong with the Catalina and Mojave runners?

I've noticed tests on them queued for about three five hours now. (Look at all the older PRs.)

[Rylan12]

Yeah, all of our Catalina and Mojave (and some Big Sur) runners seem to be offline. I don't know much about how that setup works and the maintainers who do aren't available, so nothing to be done at the moment, unfortunately 🤷‍♂️.

[carlocab]

Oof. Hope it's nothing too difficult to fix.

[fxcoudert]

Weird 10.15 error:

Error: No available formula with the name "aptible".

[carlocab]

Similar error, on 10.15, from #66287:

==> brew uninstall --force lua lua@5.1 lua@5.3
Error: No available formula with the name "vv".
Error: Process completed with exit code 1.

Can't reproduce locally.

[Rylan12]

Rerunning... we'll see what happens 🤞

"Insanity is doing the same thing over and over again and expecting different results"

[Rylan12]

Okay, so the output looks like:

==> Running Formulae#formula!(python@3.9)
==> Determining dependencies...
==> brew fetch --retry gdbm openssl@1.1 pkg-config readline sqlite xz
==> Determining dependents...
==> brew uninstall --force gdbm openssl@1.1 pkg-config readline sqlite xz
Error: No available formula with the name "aptible".

It's supposed to look something like:

==> Running Formulae#formula!(python@3.9)
==> Determining dependencies...
==> brew fetch --retry gdbm openssl@1.1 pkg-config readline sqlite xz
==> Determining dependents...
==> Starting build of python@3.9
==> brew fetch --retry python@3.9 --build-bottle --force
==> brew install --only-dependencies --verbose --build-bottle python@3.9
==> brew install --verbose --build-bottle python@3.9
==> brew livecheck python@3.9 --full-name --debug
==> brew audit python@3.9 --online --git --skip-style
==> brew bottle --verbose --json python@3.9
==> brew bottle --merge --write --no-commit ./python@3.9--3.9.0_4.catalina.bottle.json
==> brew uninstall --force python@3.9
==> brew uninstall --force pkg-config
==> brew install --only-dependencies ./python@3.9--3.9.0_4.catalina.bottle.1.tar.gz
==> brew install ./python@3.9--3.9.0_4.catalina.bottle.1.tar.gz
==> brew linkage --test python@3.9
==> brew install --only-dependencies --include-test python@3.9
==> brew test --verbose python@3.9
[...]
==> brew uninstall --force gdbm openssl@1.1 readline sqlite xz

It appears that test-bot skips right from ==> Determining dependents... to the end ==> brew uninstall --force gdbm openssl@1.1 readline sqlite xz.

Looking at the test-bot code (which I'm not that familiar with), I know that the Formulae#setup_formulae_deps_instances method is run because the info_header "Determining dependents..." line is what outputs the ==> Determining dependents... line that we see.

The next expected piece of output is ==> Starting build of python@3.9 which is found [just after the setup_formulae_deps_instancesmethod is called](https://github.com/Homebrew/homebrew-test-bot/blob/ee79c03e4e1447a1f76d6d04bb81d3f2e408876f/lib/tests/formulae.rb#L611). Therefore, something seems to go wrong within thesetup_formulae_deps_instances` method and after line 300.

Just from glancing at the code, my guess is that this is the problem:

        dependents = with_env(HOMEBREW_STDERR: "1") do
          Utils.safe_popen_read("brew", "uses", "--include-build", "--include-test", *uses_args, formula_name)
               .split("\n")
        end

I'm thinking that the Utils.safe_popen_read line fails and the error isn't handled until several layers out (wherever the brew uninstall --force gdbm openssl@1.1 readline sqlite xz line is called)

Locally (11.0.1), brew uses --include-build --include-test --recursive python@3.9 works fine but brew ruby -e 'puts Utils.safe_popen_read("brew", "uses", "--include-build", "--include-test", "--recursive", "python@3.9")' fails with the following message:

$ brew ruby -e 'puts Utils.safe_popen_read("brew", "uses", "--include-build", "--include-test", "--recursive", "python@3.9")'
Traceback (most recent call last):
        1: from -e:1:in `<main>'
/usr/local/Homebrew/Library/Homebrew/utils/popen.rb:16:in `safe_popen_read': Failure while executing; `brew uses --include-build --include-test --recursive python@3.9` exited with 127. Here's the output: (ErrorDuringExecution)

aptible is a recursive dependent on python@3.9, so it seems reasonable that the issue is around this place.

Also, I checked that this does seem to explain the lua issues as well.

---

Edit: yes, this makes sense. The Formulae#formula! method has the following ensure clause:

      ensure
        cleanup_bottle_etc_var(formula) if args.cleanup?

        test "brew", "uninstall", "--force", *@unchanged_dependencies if @unchanged_dependencies.present?
      end

This is why brew uninstall --force gdbm openssl@1.1 readline sqlite xz is still being called after the error.

---

Edit 2:

Actually, the Utils.safe_popen_read line may not be the culprit. It's probably more likely that the Utils.safe_popen_read line runs successfully but some of the operations that are run on dependents fail. Probably this line (302):

dependents = dependents.map { |d| Formulary.factory(d) }

If d isn't a valid formula name, you'll get the error saying No available formula with the name "formula".

[carlocab]

One thing I noticed: aptible is a cask, which depends on a formula libu2f-host, which has an indirect build dependency on python@3.9 through json-c and cmake. This is probably why the error is

Error: No available formula with the name "aptible".

because there is no formula named aptible. However, we do have:

❯ brew uses --include-build --include-test --recursive python@3.9 | grep apt
apt-dater
aptible

I'm guessing this only happens with Homebrew portable-ruby, and not system ruby, which is why the error appears only on 10.15.

[Rylan12]

Ah, good find!

So I bet the call should be:

Utils.safe_popen_read("brew", "uses", "--include-build", "--include-test", "--formula", *uses_args, formula_name)

Edit: or, maybe it's a bug in brew uses

[carlocab]

Yea, one would have thought that brew uses would take a --formula flag, but it seems not.

[Rylan12]

Ah, nevermind. brew uses doesn't have a --formula option. Maybe it should

[Rylan12]

This is happening for me locally, though, without HOMEBREW_FORCE_VENDOR_RUBY being set. So why hasn't this been an issue before?

[carlocab]

Did you have it set before though? I've found that brew will continue to use portable-ruby even after unsetting it. And restarting my shell. 🤷

[Rylan12]

It's possible, but I don't remember ever setting it...

I started working on a patch to brew uses yesterday but some other plans (including sleep) got in the way so I never finished it. I'm taking another look at it now.

[carlocab]

brew config will tell you if you're using portable-ruby in the Homebrew Ruby entry.

Let me know if I can help in any way. I think brew test-bot may also need patching? (Depending on the patch you had in mind to brew uses, anyway.)

[Rylan12]

My brew config:

Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby

That doesn't seem like Homebrew's vendored ruby to me (although I'll be the first to admit that I don't truly understand the vendored ruby/gems/bundle stuff)

I opened two PRs that I think will solve the issue: Homebrew/brew#9437 and Homebrew/homebrew-test-bot#532

[carlocab]

That doesn't seem like Homebrew's vendored ruby to me

Ok, I agree. But that's confusing since this error only shows up on 10.15 and not 10.14 or 11.0, for me, at least. Though I suppose it could be related to the bug that forced vendored ruby on Catalina in the first place?

[fxcoudert]

It may be that I made a mistake while redeploying the CI nodes for Catalina: I am restarting them after untapping homebrew/casks. I hope this fixes it.

[fxcoudert]

Now that CI is back online, rebased and force-pushed. 🙄

[carlocab]

Success! 🎉 https://github.com/Homebrew/homebrew-core/pull/66287/checks?check_run_id=1506973765

[Rylan12]

Thanks, @fxcoudert and @carlocab!

[carlocab]

10.14:

Error: 15 failed steps!
brew test --retry --verbose cargo-edit
brew test --retry --verbose cucumber-cpp
brew test --retry --verbose glyr
brew test --retry --verbose hyperkit
brew linkage --test mapnik
brew install mariadb
brew install mariadb@10.1
brew install mariadb@10.2
brew install mariadb@10.3
brew install mariadb@10.4
brew test --retry --verbose mysql@5.6
brew test --retry --verbose mysql@5.7
brew test --retry --verbose pcl
brew install percona-server
brew test --retry --verbose pipgrip

[Rylan12]

I'm anticipating that there will be build failures. Unless we think any of them are extra-significant, I think we should push forward with this. It's blocking a few other PRs and I know that it's impacting users as well.

[Rylan12]

10.15:

Error: 13 failed steps!
brew test --retry --verbose cargo-edit
brew test --retry --verbose glyr
brew test --retry --verbose hyperkit
brew linkage --test mapnik
brew install mariadb
brew install mariadb@10.1
brew install mariadb@10.2
brew install mariadb@10.3
brew install mariadb@10.4
brew test --retry --verbose mysql@5.6
brew test --retry --verbose mysql@5.7
brew test --retry --verbose pcl
brew install percona-server

---

Looks like the 11.0 tests are only on the "s" formula dependencies, so there's still quite a ways to go. Unless there are objections, I'll aim to merge this later tonight (assuming I'm still awake when CI finished). If it doesn't get done tonight, maintainers can feel free to merge tomorrow before I'm around.

[fxcoudert]

@Rylan12 please open a PR about the 10.14 and 10.15 test and build failures, these need to be fixed. It can be done after this is merged, I agree, but it will need to be done. Otherwise we accumulate errors and end up paying the price later.

[Rylan12]

👍 agreed. Will do once I have the list from 11.0

[carlocab]

I've noticed from other PRs that Big Sur nodes relatively consistently 33% longer than Mojave nodes on identical CI runs. Seems to be roughly the case here too.

11.0

Error: 26 failed steps!
brew test --retry --verbose asuka
brew test --retry --verbose augustus
brew test --retry --verbose cargo-edit
brew test --retry --verbose corral
brew test --retry --verbose creduce
brew test --retry --verbose glyr
brew test --retry --verbose hyperkit
brew test --retry --verbose innotop
brew linkage --test mapnik
brew install mariadb
brew install mariadb@10.1
brew install mariadb@10.2
brew install mariadb@10.3
brew install mariadb@10.4
brew test --retry --verbose mysql@5.6
brew test --retry --verbose mysql@5.7
brew test --retry --verbose networkit
brew install --only-dependencies oclgrind
brew install oclgrind
brew test --retry --verbose odin
brew test --retry --verbose pcl
brew install percona-server
brew test --retry --verbose pipgrip
brew test --retry --verbose pony-stable
brew test --retry --verbose ponyc
brew test --retry --verbose root

A number of these are known to be broken on Big Sur (e.g. hyperkit, odin).

[Rylan12]

I've noticed from other PRs that Big Sur nodes relatively consistently 33% longer than Mojave nodes on identical CI runs. Seems to be roughly the case here too.

Huh, interesting. I don't think I know enough to judge whether this is an issue with our CI system or not...

---

I've opened an issue documenting the failures: #66450

[BrewTestBot]

@Rylan12 has triggered a merge.