Brew: Warning: You are using macOS 10.9

[Eitot]

~ $ brew upgrade
Warning: You are using macOS 10.9.
We (and Apple) do not provide support for this old version.
You may encounter build failures or other breakages.
Please create pull-requests instead of filing issues.

I understand that Homebrew has formally ended support for 10.9 and that I should be aware of this when installing formulae. I want to take my chances, is it possible to suppress this message? I could not immediately find anything in man brew.

[MikeMcQuaid]

It is not currently, sorry but we may consider doing so in future.

[zmwangx]

See #1058.

[DomT4]

To be honest, I quite like the warning being so prominent because it _seems_ to reduce the level of expectation that we'll rush to fix things when people file Issues, and places the onus more on them helping us fix things rather than maintainer x finding time to spin up a Mavericks box, poke the issue, try to work on a fix, etc etc.

Diagnostic warnings & caveat messages have shown pretty thoroughly over time if you don't get in people's faces about it the vast majority won't notice or won't take the warning seriously.

[Eitot]

@DomT4: Do you believe that looking for (perhaps with a notice in the documentation) and setting an environment variable won’t have an appreciable impact? To be honest, if this isn’t addressed, I might just suppress it with a workaround myself. I don’t think that this would solve anything either.

I have no objections to the message in brew doctor and I understand that you ask of users to do this before filing a bug report anyway.

[DomT4]

Perhaps initially, but in 3/4/5/6 months when something breaks on Mavericks I'm not seriously expecting anyone to go to file an Issue and suddenly remember they set xyz ENV and we're unlikely to be able to commit much time towards fixing it ourselves. I can't even remember most of what I did last week 😄.

A lot of people don't really appreciate the diagnostic messages _(of which this is technically one)_ aren't there to annoy you particularly, they exist because we've identified a specific issue that we know causes users or us significant hassle.

Prior to that warning & Mike storming through the Issue tracker wielding a close hammer there were quite a few situations where someone reported a problem with a formula or Homebrew on 10.6/10.7 and the best response we could manage was a mildly exasperated shrug, so issues sat there ignored for months and months. I'm not convinced that's not a worse experience than living with the message.

I consider it genuinely useful to give people a heads-up on a regular basis that if things break we'll need help fixing them, or we might not be able to do so ourselves.

[MikeMcQuaid]

Let's leave this open for a bit and see how many people chime in. brew doctor will still whine at you regardless, we won't disable that.

[MikeMcQuaid]

CC @Alhadis as you're interested in this.

[zmwangx]

Perhaps initially, but in 3/4/5/6 months when something breaks on Mavericks I'm not seriously expecting anyone to go to file an Issue and suddenly remember they set xyz ENV and we're unlikely to be able to commit much time towards fixing it ourselves. I can't even remember most of what I did last week 😄.

I think we can make it very clear where the responsible env var is documented that users who set that are on their own and should not expect support from us. When people do whine and _demand_ a fix, we simply link to the docs and close. Set an abbreviation for that in your favorite text expansion tool.

I expect the percentage of users who actually whine out of those that feel the pain of constant warnings (and let's be honest, most people who are stuck on Mavericks won't and maybe can't upgrade just because you keep nagging) to be actually very low. We get nonsensical issues quite frequently, I don't mind closing a few more.

[jeroen]

I was a bit blown away by the unexpected end of Mavericks support as well.

Mavericks is still widely used for building software which is provided via installers and should work across different versions of OSX. It is also default osx image on Travis.

We target Mavericks on build servers for the R software, an open source data analysis language used by millions of students and researchers. The language has over 8000 contributed packages which get built on our Mavericks server, so that they can be used on any OS-X 10.9 or newer. We rely heavily on homebrew bottles for static linking packages which use external C/C++ libraries.

Is there any way we can provide some extended support for Mavericks ? Or at least keep serving bottles while they work?

[zmwangx]

I was a bit blown away by the unexpected end of Mavericks support as well.

Sorry, it might be unexpected to you, but we always supported three and only three latest versions, always.

EDIT: Always since we had the CI infrastructure to actually test things. Prior to that it was just firefighting.

[MikeMcQuaid]

Mavericks is still widely used for building software which is provided via installers and should work across different versions of OSX. It is also default osx image on Travis.

We target Mavericks on build servers for the R software, an open source data analysis language used by millions of students and researchers. The language has over 8000 contributed packages which get built on our Mavericks server, so that they can be used on any OS-X 10.9 or newer. We rely heavily on homebrew bottles for static linking packages which use external C/C++ libraries.

Is there any way we can provide some extended support for Mavericks ? Or at least keep serving bottles while they work?

If someone can provide us with the funding for an additional new, SSD Mac Mini we can continue bottling for Mavericks. Travis CI was notified in advance that this was coming so I'd suggest you consider taking it up with them. You can still build from source with Homebrew back to 10.5, we just can't support it and don't build binary packages.

[jeroen]

How much funding would you approx need?

[zmwangx]

@MikeMcQuaid Do you mean just "continue bottling" when things work, or properly support things? The latter would be a lot of work for little gain. (We have analytics to back up that claim.)

[MikeMcQuaid]

@zmwangx I mean "provide binary packages" alone.

@jeroenooms Probably around £1000 for the hardware plus travel costs to get it to the data centre which would be another £100-200. That's not to say we'd 100% support it if we raised that money but that's the sort of minimum ballpark figure, as you asked. It's also perhaps worth nothing that it's extremely likely that Travis CI will be dropping 10.9 support in the near future.

[MikeMcQuaid]

@jeroenooms Also worth noting here: Mavericks will not receive toolchain updates from Apple and is unlikely to receive any except the most severe security patches (and even that's not guaranteed). The only difference in hardware requirements are 800MB more disk space so, even if it's a pain, anyone who wants to upgrade from 10.9 (and even 10.8) to 10.11 is capable of doing so.

Even with that Mac Mini we would be unable to fix packages that upstream projects do not support Mavericks on and unable to block upgrades on needing Mavericks support. This means that, over time, Mavericks will become a worse and worse experience even if we tried our hardest to support it. OS X is simply not a platform where legacy support has been prioritised by Apple and very few open-source projects (us included) have the resources to step in where Apple has not.

[jeroen]

Yes I understand, it's sort of in "extended support" phase. Do you know if apple has any formal statements on if they will do security upgrades for mavericks? I can't find it anywhere.

I'll ask around if anyone wants to support this with $.

[zmwangx]

Do you know if apple has any formal statements on if they will do security upgrades for mavericks?

They don't. You watch for security updates in MAS, that's all.

[DomT4]

@jeroenooms Appreciate you asking about funding, FWIW.

We see a lot of people complaining we've dropped support for something or aren't doing enough of something, including some large, well-known companies but very few are willing to even contemplate financially supporting the project so we can better support their desired use case, so whatever happens, appreciate you asking about it.

[Alhadis]

Yeah, give me a job and an income, and I'll happily donate what I can afford to.

[DomT4]

Wasn't an intended dig at anyone, just a matter-of-fact statement that FOSS has a significant funding issue & Homebrew is very much part of that. Even things like GnuPG which had this huge publicity rush around funding a while back & fundraising drive is back down to a smaller level of donations again.

[hadley]

@DomT4 @MikeMcQuaid: we can definitely provide funding — can you please send me an email (in profile) to discuss details. We'll probably need a little paperwork (i.e. a one page invoice) but that's easier to discuss via email.

[MikeMcQuaid]

@hadley Just so we're all on the same page are you aware of https://blog.travis-ci.com/2016-09-15-new-default-osx-image-coming/ which states Travis CI will be removing their Mavericks support soon? With that in mind: would it still be useful for you for us to support it?

[jeroen]

@MikeMcQuaid yes we are aware of that. We need this mostly for the R project.

[hadley]

@MikeMcQuaid we absolutely recognise that this is a short term solution, but it'll get the R community through the next 6-12 months, and then hopefully it'll still be useful to you all after that 😄

[zmwangx]

@hadley @jeroenooms And I assume you do realize we can only bottle things when they work, and the support burden falls onto you when things break (and they won't block us from upgrades)?

It would also be nice if you could give us a list of formulae you need if this "deal" works out, because bottling is a slow process.

[MikeMcQuaid]

@jeroenooms I'm just checking you have additional hardware that you'll be able to use for the parts of the process not provided by Homebrew.

[jeroen]

@MikeMcQuaid I don't have any hardware. Can you create an invoice for the expenses (hardware, shipping, etc) that it will take to keep bottling mavericks for one more year and send it to Hadley?

[MikeMcQuaid]

@jeroenooms @hadley Sorry, I mean: you were saying "the language has over 8000 contributed packages which get built on our Mavericks server": is this one that's independent of Travis CI and Homebrew, currently, but just relies on our Mavericks bottles?

[jeroen]

Yes, it is independent of travis. We use static libraries from the homebrew bottles which get linked into our software on the mavericks build server.

[MikeMcQuaid]

@jeroenooms How many Homebrew packages are you reliant upon, out of interest?

[tdsmith]

A tangent, while y'all are on the line: I'd be interested in knowing if it's possible for Homebrew's R distribution to consume CRAN's OS X package binaries; IIRC the r-project.org distribution is whitelisted and calling install.packages from Homebrew's R distribution always builds from source. Where's a good place for that conversation?

[MikeMcQuaid]

@jeroenooms @hadley I've given some thought and done some calculations and I think we're going to have to pass on this. It'll rely on a bunch of time from me which I won't have in the nearish future unfortunately (it'll be pretty much a full weekend job on top of my current full-time employment and other commitments). I really appreciate the genuine offer of funding and I'm happy to provide advice on how you could achieve a similar result of build caching using bottles within your own server/build system. Again, my apologies.

[jeroen]

@MikeMcQuaid OK that is unfortunate. Can you point me in the right direction of how to bottle a formula and it's dependencies for hosting on e.g. github pages?

[MikeMcQuaid]

@jeroenooms If the bottles are primarily used on your internal build server your best bet is just to run brew bottle, cache the artifact somewhere and reinstall from that path. Our documentation is here: https://github.com/Homebrew/brew/blob/master/docs/Bottles.md and in man brew.

[jeroen]

I will have to build and host them from an external server which the R build servers can install them from. It's just a bit tricky to do this recursively for packages with many dependencies.

By the way, does bintray delete old bottles? Or can I keep using old bottles? For example this still seems to be alive:

• https://homebrew.bintray.com/bottles/imagemagick-6.9.5-9.mavericks.bottle.tar.gz

Maybe I can just keep using homebrew-core from a commit before last week and work from that as a temporary solution.

[MikeMcQuaid]

@jeroenooms This may also be useful: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/hooks/bottles.rb

By the way, does bintray delete old bottles? Or can I keep using old bottles? For example this still seems to be alive:

https://homebrew.bintray.com/bottles/imagemagick-6.9.5-9.mavericks.bottle.tar.gz
Maybe I can just keep using homebrew-core from a commit before last week and work from that as a temporary solution.

That will work but obviously you will not receive security updates for things like OpenSSL and that would be problematic. We don't plan to delete old bottles but if Bintray need to ever reclaim space then we will need to do so (but that's never happened).

[jeroen]

That will work but obviously you will not receive security updates for things like OpenSSL and that would be problematic. We don't plan to delete old bottles but if Bintray need to ever reclaim space then we will need to do so (but that's never happened).

That's fine for me as a stop gap measure right now. Is there a brew command to pin the homebrew-core tap to a certain commit back in time?

[MikeMcQuaid]

Is there a brew command to pin the homebrew-core tap to a certain commit back in time?

@jeroenooms There is not. Just treat it as a Git repository, don't run brew update and set HOMEBREW_NO_AUTO_UPDATE to any value in your environment.

That's fine for me as a stop gap measure right now.

If this is just for testing etc.: 🆒. If this is something you're considering for a sustained period of time and exposing to your users I strongly, strongly advise you to reconsider silently ignoring upstream security updates for a sustained period of time. If that's something you're set on I'm afraid I'm not willing to provide any more help to facilitate that.

My $0.02 would be to use the funds you would have paid Homebrew to pay someone else to update your build servers to 10.10 (or higher to avoid having the same problem next year) in the short term. Again, obviously that's up to you.

[jeroen]

We will upgrade build servers to Sierra for the next release of R in april. We cannot upgrade any sooner because R itself has been built with 10.9 so in the mean time, all contributed packages will need to target this version.

For critical formulas, like openssl, we can build the latest version from source. However for larger formulas with many dependencies (such as imagemagick) it would be nice if there is a way to grab the latest available binaries from homebrew.

[MikeMcQuaid]

For critical formulas, like openssl, we can build the latest version from source.

Ok, cool.

[pachamaltese]

could you find a new ssd imac?

[MikeMcQuaid]

We're going to keep this warning as-is as it reduces our support burden. Sorry!