Skip to content
This repository has been archived by the owner. It is now read-only.

10.11 [Tracking Issue] #40837

Closed
DomT4 opened this issue Jun 17, 2015 · 82 comments

Comments

Projects
None yet
@DomT4
Copy link
Contributor

commented Jun 17, 2015

This is essentially a triage of various issues and progress on them. Did the same thing for 10.10 last year and it worked relatively well at keeping everyone in the loop.

This thread will be comment-policed fairly hard; Please keep comments related to failures/issues/etc. If you can reproduce an issue providing a brew gist-logs FORMULA is preferred over a simple 👍 - Thanks!

New issues should still be filed as new issues. This is only a centralised tracking thread rather than a solve-everything-here thread.

Core Fixes:

  • Basic recognition of 10.11 was added to Homebrew - 62381a6
  • pkg-config files were added for 10.11 - 4a8fcd1
  • Better detection and warning of unsupported OS X versions was committed - baaa295.
  • Clang version update for 10.11 DP2 added in 11cf300.
  • Clang version recognition fixed in 0599646.
  • Clang version updated for 10.11 DP4 in df15afd.

Potential Issues:

  • Rootless: Bans writing to /System, /usr, /bin, /sbin - So far /usr/local isn't write-protected.
  • Permissions can wander off and prevent README overwriting - #41150.
  • System OpenSSL: Headers have seemingly been removed from the CLT and Xcode - #40519 (comment).

Formulae Issues Outstanding:

  • Pixman fails to build - #41056 - Can't find somewhere reliable to report upstream.
  • Python can fail to build core extension modules - #41085.
  • Google-sparsehash fails to build on DP2 - #41087 - Upstream report.
  • Fltk fails to build on DP3 - #41581.
  • Libgcrypt refuses to build - #41599 - Upstream report.
  • Phantomjs refuses to build - #42249 - The internal Qt fails to compile. Needs updating/patching upstream.
  • Clang-format - #42221 - You need to symlink /Applications/Xcode-beta.app/ to /Applications/Xcode.app/.
  • Ctail refuses to compile - #42400.
  • Cputhrottle dies horribly on finding Boost - #42394.
  • Ccze fails to compile - #42379.
  • Carthage fails to compile, looks like incompatibility with Xcode-Beta Swift - #42378.
  • Bup fails to compile - #42375.
  • Arabica fails to compile - #42369.
  • Postgresql fails to compile - #42223 - Can't find readline, needs investigating.
  • Libpeas fails to compile - #42685.
  • ios-class-guard breaks on trying to find OpenSSL, breaks if you force our OpenSSL - #42671.
  • Io fails to compile - #42670.
  • Idris fails to compile - #42669.
  • Gsoap fails to compile - #42502.

Formulae Fixed:

  • Qt fails to build - #40585, #42370 - A patch needs submitting to Qt's Gerrit for review. They aren't supporting it any more. We've backported a patch for 10.11.
  • Python & Python3 - #40516 - Tim patched python and python3's OpenSSL detection.
  • Git - #40519 - Misty fixed git to stop looking for OpenSSL headers when CommonCrypto is used.
  • GCC - #40650 - Patch submitted upstream applied in 3291699.
  • Pango can fail to build against the second Xcode beta - #41086. FIXED by the third DP, Xcode 7 Beta.
  • Qt5 refuses to build - #42014 - Should be fixed by d0020e7.
  • MongoDB fails to build - #40955 - Fixed upstream, merged into Homebrew. Should work fine now.
  • Rust refuses to build - #41598 - Upstream report. Fixed upstream, will be fixed here when #42642 is merged.
  • Zookeeper fails to compile with htonll problems - #42374. Fixed by e00142f.

@DomT4 DomT4 added the 10.11 label Jun 17, 2015

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2015

Rootless: Bans writing to /System, /usr, /bin, /sbin - So far /usr/local isn't write-protected.

Correct me if I'm wrong, but I believe this is an issue; if you have a /usr/local already created at the time you upgrade, you're ok, but with a clean install, one cannot create /usr/local.

Adding rootless=0 to nvram boot-args is a workaround, but considering kext-dev-mode=1 wasn't advocated/adopted with 10.10, I think there's good reason to avoid this.

For whatever its worth, I've been using /Users/Shared/Developer/usr/local as my prefix for over a year now, and I have not found the old "if you don't use /usr/local, stuff will break" adage/warning to be true at all. There are some bottles that don't install, of course, but with HOMEBREW_BUILD_FROM_SOURCE set I have not had a single issue.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 19, 2015

Correct me if I'm wrong, but I believe this is an issue; if you have a /usr/local already created at the time you upgrade, you're ok, but with a clean install, one cannot create /usr/local.

It'll just require a chown, no?

For whatever its worth, I've been using /Users/Shared/Developer/usr/local as my prefix for over a year now, and I have not found the old "if you don't use /usr/local, stuff will break" adage/warning to be true at all.

You're not getting most binary packages which means stuff is much more likely to break.

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2015

It'll just require a chown, no?

chown... what? You can't chown /usr, and with sudo mkdir /usr/local it acts as though one's trying to to write to a read-only volume (which is, I believe, is basically how "rootless" is implemented).

You're not getting most binary packages which means stuff is much more likely to break.

If you mean I'm not getting the bottled binary packages, yes, those would break; but back in February, PRs #37059 - #37072 were the result of an experiment I did, attempting to install every homebrew formula in this custom directory. Essentially, these were the only ones that failed (for unrelated reasons). I may not have tested each package thoroughly, but I'd say (generally) it was a success.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 19, 2015

This doesn't match what I've seen; I've been installing Homebrew fine onto a clean 10.11 VM into /usr/local.

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2015

This doesn't match what I've seen; I've been installing Homebrew fine onto a clean 10.11 VM into /usr/local.

I'll double check.

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2015

This doesn't match what I've seen; I've been installing Homebrew fine onto a clean 10.11 VM into /usr/local.

@MikeMcQuaid Ok you're right, but I'm still (kind of) right-ish:

  1. If you upgrade a machine which has an existing /usr/local, the permissions are maintained, and it may or may not writable;
  2. I you do a completely clean install, Apple creates a /usr/local, and you can write to this directory (they haven't done that in a while!);
  3. I believe (?) if you upgrade a machine which does not have an existing /usr/local when you upgrade, Apple does not create this directory;
  4. If /usr/local is deleted (easily done), you cannot re-create it.

So... still a bit of an issue, I'd say ...?

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 19, 2015

I wouldn't necessarily rely on this behaviour remaining consistent to the actual release, based on past experience. I believe that we should still be able to create that directory somehow.

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2015

I wouldn't necessarily rely on this behaviour remaining consistent to the actual release, based on past experience. I believe that we should still be able to create that directory somehow.

I agree. If there isn't a way to re-create it in later betas, its probably time to raise a stink.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 19, 2015

Are you sure it's literally impossible for a sudod user to create those directories with the xattrs?

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2015

Quite — at least by any conventional, reasonable method I know of.

Tests-MacBook-Pro:~ test$ rm -rf /usr/local
Tests-MacBook-Pro:~ test$ mkdir /usr/local
mkdir: /usr/local: Operation not permitted
Tests-MacBook-Pro:~ test$ sudo mkdir -p /usr/local
mkdir: /usr/local: Operation not permitted
Tests-MacBook-Pro:~ test$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
==> This script will install:
/usr/local/bin/brew
/usr/local/Library/...
/usr/local/share/man/man1/brew.1

Press RETURN to continue or any other key to abort
==> /usr/bin/sudo /bin/mkdir /usr/local
mkdir: /usr/local: Operation not permitted
Failed during: /usr/bin/sudo /bin/mkdir /usr/local

The only feasible method I can think of is to do something like:

  • Gain sudoer privileges
  • `sudo nvram boot-args="rootless=0"
  • Write a LaunchAgent, and restart. The LauchAgent will:
    • create /usr/local and set the proper permissions
    • resent nvram boot-args
    • delete itself
    • restart again

But this method is also the basic rubric for installing nigh-undeleteable malware.

Also the following files exist:

/System/Library/Sandbox/rootless.compat
/System/Library/Sandbox/rootless.conf
/usr/libexec/rootless-init

But these are completely undocumented and how they work is anyone's guess, I think.

(My personal opinion: I understand why Apple implemented this for iOS, but rootless for OS X is a pretty half-baked idea. As I mention above the fact that one can turn it off and on at will makes it a great way to install malware which effectively cannot be removed, particularly if one can manage to overwrite Apple's Installer certificate.)

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2015

As regards re-creating /usr/local with rootless enabled, this persists with beta 2; I've taken the liberty of opening rdar://21542005 at bugreport.apple.com.

Contents (In case someone wants to recreate on OpenRadar or elsewhere):

10.11: Rootless — Inability to re-create /usr/local if deleted.

Summary:
With the default configuration (rootless=1), it is possible for the root user to delete or move /usr/local, but it is not possible for the root user to re-create /usr/local. Per the WWDC '15 presentation "Security and Your Apps", /usr/local is to be "available to developers" (http://f.cl.ly/items/362w042M1V2C2b273313/Screen%20Shot%202015-06-12%20at%2012.57.46%20AM.png); this is not necessarily the case presently.

This is a particularly impediment to homebrew (which I imagine is largely why access to this directory was promised in the first place); please see:
#40837 (comment) and linked issues.

If my understanding is correct, 10.11 SIP only allows an installer package signed by the Apple Software Update CA (and other Apple CAs [?]) to modify a "rootless" protected directory. Therefore, presently there appears to be no means to re-create the directory without reinstalling Essentials.pkg in its entirety. It would be great if another means were added to rectify such a situation, such as:

  • diskutil repairSomething /
  • A properly signed package (contents: an empty /usr/local) were kept somewhere on the system
  • Add some magic to mkdir.
  • ?

Steps to Reproduce:

  1. sudo rm -rf /usr/local.
  2. sudo mkdir /usr/local.

Expected Results:
Ambiguous (?)

Actual Results:
mkdir: /usr/local: Operation not permitted
No (apparent) means to recreate without a complete reinstall.

Version:
10.11 beta 1; 10.11 beta 2

Notes:
I'm filing this under "Classification: Security" because this is a bug caused by a Security framework, not because it is a "security issue". I would still, respectfully, consider this a "serious bug".

Configuration:
Occurs on 10.11 beta 1 or beta 2.
Does not occur with "rootless=0" or on previous systems.

I'll report back if I get any updates.

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 25, 2015

Thanks @geoff-codes. I wouldn't worry too much; I'd be very surprised if the current behaviour survives to GA.

@geoff-codes

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2015

I wouldn't worry too much; I'd be very surprised if the current behaviour survives to GA.

Yeah I've just been trying out more of an "if you see something, say something" approach these days 📥.
Can't hurt, anyway. 😉

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Jun 25, 2015

Yeah I've just been trying out more of an "if you see something, say something" approach these days .
Can't hurt, anyway.

Definitely. We always appreciate upstream bug reports about such things!

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2015

Everything with a * next to it has write access with sudo. Everything on the list without that star is blocked to everyone:

                /System
*               /System/Library/Caches
booter          /System/Library/CoreServices
                /System/Library/CoreServices/RawCamera.bundle
*               /System/Library/Extensions
                /System/Library/Extensions/*
UpdateSettings  /System/Library/LaunchDaemons/com.apple.UpdateSettings.plist
*               /System/Library/Speech
*               /System/Library/User Template
                /bin
dyld            /private/var/db/dyld
                /sbin
                /usr
*               /usr/libexec/cups
*               /usr/local
*               /usr/share/man
# symlinks
                /etc
                /tmp
                /var

Source.

I'm not quite sure why /tmp is on the list; I can seem to write to that without sudo just fine. /etc is protected and can't write without sudo, as is /var.

There's also a small exemption list that permits certain non-Apple binaries in /usr/bin and /usr/sbin.

@chdiza

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2015

If /etc can't be modified at all, how is one supposed to append a custom shell to /etc/shells? AFAIK the bash and zsh formulas will be dead without this ability.

@zmwangx

This comment has been minimized.

Copy link
Member

commented Jul 8, 2015

@chdiza Without a working system to test, I would guess that

# symlinks
                /etc
                /tmp
                /var

in #40837 (comment) really means that the symlinks themselves can't be modified. The directories /private/etc, /private/tmp and /private/var should remain writable (it would be insane otherwise, especially for /private/tmp).

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Jul 8, 2015

Yes. You can still seem to write files to /etc, /tmp and /var. It hasn't been explained what Apple means by symlinks in that document.

@chriskrycho

This comment has been minimized.

Copy link

commented Jul 11, 2015

FWIW, sudo chown -R $USER /usr/local made brew work properly again for me.

@zmwangx

This comment has been minimized.

Copy link
Member

commented Oct 1, 2015

living with the default permissions of /usr/local and accept that sudo is necessary to install stuff outside of a user's home directory;

Moot point. Homebrew trades sudoing over and over for sudoing once up front, during installation. It would be incredibly stupid if brew upgrade requires root permissions (after all these years), since I daresay a big chunk of users are constantly on the bleeding edge and upgrade daily, probably through automated jobs.

Rebooting a system twice from time to time.

Define "from time to time". You mean, after each system upgrade? Actually I don't understand "kept reverting to root ownership" mentioned above. The claim is not clear at all. Define "kept". Does that mean "after reboot"? Or "after toggling SIP"? At least I haven't seen that myself after a clean install of the final released build. Moreover, with SIP I can chmod on /usr/local without problem; no reboot required, let alone twice. Maybe I just haven't lived with it long enough, but I honestly don't think what hasn't happened today will magically happen tomorrow.

And isn't Homebrew mature enough to be a package manager for production environments?

No one stops you from running Homebrew from the root account "for production", as far as I could tell. The ownership will be root:admin rather than root:wheel, but I don't see how that's a big problem. Most things are not group writable anyway. The only caveat is that you have to keep using the root user to manage everything; not very different from apt.

How about having Homebrew installed in a user's home directory, but the Cellar in /usr/local?

Ridiculous.

@lifepillar

This comment has been minimized.

Copy link
Contributor

commented Oct 1, 2015

a big chunk of users are constantly on the bleeding edge and upgrade daily, probably through automated jobs.

Such users are likely clever enough to fix their automated jobs once and for all. It surely would be less of a hassle than having such jobs periodically fail because permissions are reset.

Define "from time to time". You mean, after each system upgrade?

According to the link above, yes. But OS X 10.11 might check permissions at other times as well (a hint is that the Repair Permissions function in Disk Utility is not needed any longer). However, /usr/local may not be affected.

Moreover, with SIP I can chmod on /usr/local without problem; no reboot required, let alone twice.

Ah, a clean install already has /usr/local and you may change permissions on it. So, Recovery Mode is only needed if, for some reason, such directory does not exist. The question remains, whether such permissions are reverted by OS X or not, and when.

No one stops you from running Homebrew from the root account "for production", as far as I could tell.

As long as the feature is not officially supported (last time I checked it wasn't), no thanks.

How about having Homebrew installed in a user's home directory, but the Cellar in /usr/local?
Ridiculous.

Reasonable, if Homebrew is owned by me and the formulas are installed with administrator privileges. Anyway, If OS X lets you change the rights on /usr/local without interfering, I have no problem in keeping things as they are. But if the system reverts the changes I make then the message is clear: this is not the way you should do it, like it or not.

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Oct 1, 2015

Some replies which hopefully help handle various points raised before this discussion takes over the thread:

  • At this time we aren't considering moving to another default prefix. /usr/local remains accessible to developers per Apple's own Keynote & everyone who writes into /usr/local and don't root "all the things" is going to deal with the same issues we are.
  • I'm personally very strongly against reversing our sudo issue. You're either going to be using sudo for every brew command that writes into the prefix, or you use sudo to fix permissions every now and again. There's also the previously made argument of arbitrary code installing with full root access.
  • What the situation is with SIP is unclear going forwards. Apple's public documentation and Keynote points on /usr/local are vague. It is implied that the permissions will be reset on updates (From 10.11 to 10.11.1 for example) but I haven't seen evidence of this yet. Likewise with Disk Utility resetting permissions on the directory. It's too early into the SIP timeline to make drastic decisions here.
  • There are some 2231 core formulae with bottles, 1566 of which are relocatable. Moving prefix would involve rebuilding 665+ binary packages which could take weeks if nobody submits a PR & we don't do any core changes in that time, and a lot longer if anyone does.
  • Every other tap in the Homebrew ecosystem would have to also migrate their bottles over if those bottles aren't relocatable.
  • We could migrate people's data over to the new prefix but things would still break. Some things hardcode their prefix and moving that causes failure.
  • A lot of automated scripts elsewhere would break. Bear in mind that Travis' OS X machines ship with Homebrew installed and using Homebrew for testing projects elsewhere is very common.

People can do what they like with their Homebrew installations, but we aren't going to rush a decision here and the plan for the foreseeable is to stay in /usr/local by default.

@zmwangx

This comment has been minimized.

Copy link
Member

commented Oct 1, 2015

@lifepillar
To avoid taking over the thread, I won't respond to every point raised, but just want to point out an obvious flaw in your argument: at one point you are worried about having to boot into recovery "from time to time", but then you answered yourself:

Ah, a clean install already has /usr/local and you may change permissions on it. So, Recovery Mode is only needed if, for some reason, such directory does not exist. The question remains, whether such permissions are reverted by OS X or not, and when.

Okay, I'll just assume for now that OS X reverts /usr/local's permissions without notice from time to time. But what won't ever happen is /usr/local being deleted once it's already there (without action on the user's part anyway). So where does that booting into recovery from time to time coming from?

@lifepillar

This comment has been minimized.

Copy link
Contributor

commented Oct 1, 2015

@zmwangx I have realized after your reply that Recovery Mode is necessary only under certain circumstances.

@Mikaela

This comment has been minimized.

Copy link
Contributor

commented Oct 2, 2015

living with the default permissions of /usr/local and accept that sudo is necessary to install stuff outside of a user's home directory;

👍. I am breaking the guidelines by doing this, because I have multi-user (family) systems and it's possible for someone else to need to install something. Currently Homebrew is assuming all systems are only single user which can cause trouble when it's not true.

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2015

brew should actually completely happily run under sudo if the executable is owned by root. We don't actively support the configuration, but we don't block it in the same way we do if the executable isn't owned by root.

@MStines007

This comment has been minimized.

Copy link

commented Oct 2, 2015

^^^ sudo brew update worked without issue, for me.

@cwonrails

This comment has been minimized.

Copy link

commented Oct 2, 2015

Speaking as someone who's been upgrading with every 10.11 beta and struggled endlessly with SIP, 👍 for @DomT4's comments above. For those seeking change, his conclusion warrants special attention:

People can do what they like with their Homebrew installations, but we aren't going to rush a decision here and the plan for the foreseeable is to stay in /usr/local by default.

As others have noted and many have experienced, Apple's implementation of and communication on SIP has been (at best) inconsistent. I can confirm that in my local environment (latest public beta) the permissions on /usr/local consistently reset of their own accord even when the user disables SIP and chowns the relevant directories. That does not, however, mean Homebrew should change default behaviors and environmental norms that users have internalized and relied upon for years. The onus is on Apple to align 10.11's real-world treatment of usr/local with the information presented at WWDC.

@ivan-leschinsky

This comment has been minimized.

Copy link

commented Oct 3, 2015

I found the answer to disable new security layer in the OS X 10.11.
In the recovery mode(reboot with Cmd+R) in the console:

csrutil disable

Then I can manage all system applications and files.
From here(last answer): https://apple.stackexchange.com/questions/101328/file-cant-be-moved-by-root-on-os-x/202969#202969?newreg=0b6a3e5858b5401bbe9e3040f9085f4c

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Oct 3, 2015

@ivan-leschinsky Please be aware Homebrew isn't recommending doing that for more than the length of time it takes to fix whatever permission issues you are seeing, unless you have other reasons to want full root access. We believe rootless is generally a good thing for the vast majority of users.

@ivan-leschinsky

This comment has been minimized.

Copy link

commented Oct 3, 2015

@DomT4 Got it. But disabling rootless doesn't helped me.

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Oct 3, 2015

@ivan-leschinsky What problems are you seeing?

@ivan-leschinsky

This comment has been minimized.

Copy link

commented Oct 3, 2015

@DomT4 I saw Operation not permitted error. But all is well now! Thanks 😄

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Oct 3, 2015

@ivan-leschinsky Glad to hear! Let us know if you hit any further issues :)

@apjanke

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2015

Looks like there's a mongoclient update; see #44724.

@magic890

This comment has been minimized.

Copy link

commented Oct 18, 2015

Have you solved this problem?
I'm using Homebrew 0.9.5 (git revision 51a477; last commit 2015-08-03) and I'm still getting this error:

brew update
Error: The /usr/local directory is not writable.
Even if this directory was writable when you installed Homebrew, other
software may change permissions on this directory. Some versions of the
"InstantOn" component of Airfoil are known to do this.

You should probably change the ownership and permissions of /usr/local
back to your user account.
  sudo chown -R $(whoami):admin /usr/local

Running brew upgrade I was able to update some formulas.

@bfontaine

This comment has been minimized.

Copy link
Member

commented Oct 18, 2015

@magic890 did you try running the suggested command?

@wspurgin

This comment has been minimized.

Copy link

commented Oct 18, 2015

System OpenSSL: Headers have seemingly been removed from the CLT and Xcode - #40519 (comment).

Haven't hit that issue just yet, but I ran across this interesting article that explains why they were removed

@magic890

This comment has been minimized.

Copy link

commented Oct 19, 2015

@bfontaine I ran brew doctor and tried to use sudo. Is that right?

@wspurgin

This comment has been minimized.

Copy link

commented Oct 20, 2015

@magic890 I think @bfontaine means have you used this command:
sudo chown -R $(whoami):admin /usr/local

I ran across the same issue you had, but the above command solved it for me.

@magic890

This comment has been minimized.

Copy link

commented Oct 22, 2015

Ok, now it is fixed. Thank you.

@MatthewHannigan

This comment has been minimized.

Copy link

commented Oct 24, 2015

You should use the -h option with chown, because you have to be careful in case the link points outside of /usr/local. And of course the link itself would not get changed, which might inhibit future homebrew operations.

I had a look at my /usr/local and there was a single link which linked outside;
/usr/local/Cellar/redo/0.11/lib/redo/sh -> /bin/sh

With El Capitan, chown'ing this results in Operation not permitted

In general, with almost any use of chown you want the -h flag. I would call it's normal behaviour a mis-design.

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Nov 26, 2015

Closing as most of the issues here are dealt with and fixed. The remaining ones are:

  • #44051 - Unrelated to OS X 10.11 specifically.
  • #44060 - Is a nasm bug.

Thanks for coming along for the ride all. 10.11 was less a nightmare than 10.10, so that's something 😸.

@DomT4 DomT4 closed this Nov 26, 2015

@MikeMcQuaid

This comment has been minimized.

Copy link
Member

commented Nov 27, 2015

Thanks for the great work here everyone (particularly @apjanke and @DomT4!)

@apjanke

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2015

You're welcome! Glad this went well.

@Homebrew Homebrew locked and limited conversation to collaborators Apr 9, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.