Formulae fail to build

[xu-cheng]

I have finished the massive bottle build. Below is the list of formulae fail to build.

• blucat
• cvs2svn
• dwarf
• file-roller
• fsw (test timeout)
• geocouch — Fold geocouch in to couchdb formula #475
• gexiv2
• henplus
• hqx
• juise
• kjell — kjell: fix sandbox violation #870
• libcanberra
• libmarisa
• libreadline-java
• mapserver
• mercury
• mikmod
• mmix
• ninja-ide
• ocamlsdl (build timeout like 12hrs)
• pg_top
• pillar
• pylucene
• recode
• sam2p
• sdf
• sile
• skytools
• slony
• snow
• soccerwindow2
• sproxy
• ssreflect
• suricata
• swatchbooker
• valkyrie
• vcodex
• vmalloc
• wartremover
• wsmancli — fails because its dependency openwsman is broken: wsmancli failed to build because of a broken/incomplete openwsman build/bottle legacy-homebrew#44047
• zint

Without an El Capitan bottle, but not necessarily broken:

• apt-cacher-ng — depends_on :osxfuse
• class-dump — MaximumMacOSRequirement => :mavericks
• ctunnel — depends_on :tuntap
• fastd — depends_on :tuntap
• horndis — depends_on UnsignedKextRequirement
• iodine — depends_on :tuntap
• ld64 — MaximumMacOSRequirement => :snow_leopard
• osxfuse — depends_on UnsignedKextRequirement
• peervpn — depends_on :tuntap
• shrewsoft-vpn-client — depends_on :tuntap
• tuntap — depends_on UnsignedKextRequirement
• vpnc — depends_on :tuntap

[MikeMcQuaid]

Failed to build on what platform/platforms? Do they have sandbox violations?

[DomT4]

I presume apt-cacher-ng was a 404, was being worked on here but hit other issues.

geocouch is likely to be this old bundle of fun, which is both a sandbox problem and a "Upstream like to break the checksum" problem.

[xu-cheng]

Failed to build on what platform/platforms?

Fail to build on El Capitan at least.

Do they have sandbox violations?

I don't know. Because the list is generated by subtraction. i.e. All the formulae without El Capitan bottles. (I have removed the formulae that explicitly not work on El Capitan, e.g. MaximumMacOSRequirement and UnsignedKextRequirement).

[DomT4]

I'd be tempted to get rid of geocouch FWIW. It has been broken for a fairly long time now and only a handful of users have noticed, and we've fixed the checksum before only for that to quickly break again. I'm unconvinced it's worth the effort to fix and likely keep having to fix, unless anyone really wants to.

[xu-cheng]

FYI, this is the script used to generate the list.

require "tap"
require "formula"
require "extend/ARGV"
tap = Tap.fetch(ARGV.named.first || "homebrew/core")
ff = tap.formula_files.map { |f| Formula[f] }
ff.reject! { |f| f.bottle_disabled? }
ff.reject! { |f| f.bottle_specification.collector.key? :el_capitan }
ff.reject! do |f|
  f.recursive_requirements.any? { |r| r.is_a?(UnsignedKextRequirement) || r.is_a?(MaximumMacOSRequirement) || r.is_a?(OsxfuseRequirement) || r.is_a?(TuntapRequirement) }
end
puts_columns ff.map(&:name)
puts ff.size / tap.formula_files.size.to_f

[ilovezfs]

apt-cacher-ng: osxfuse
ctunnel: tuntap
fastd: tuntap
iodine: tuntap
miredo: tuntap
peervpn: tuntap
shrewsoft-vpn-client: tuntap
vpnc: tuntap

So that subset is the unsigned kext requirement, too.

[ilovezfs]

This seems to fix fsw #367

[ilovezfs]

Not having any issue with zint. The developer does still appear to be actively working on the project but mostly on SourceForge now. @xu-cheng was there a specific failure?

[ilovezfs]

OK, zint issue reproduced: sandbox violation #386

Install the project...
/usr/local/Cellar/cmake/3.5.2/bin/cmake -P cmake_install.cmake
-- Install configuration: "Release"
-- Installing: /usr/local/Cellar/cmake/3.5.2/share/cmake/Modules/FindZint.cmake
CMake Error at cmake_install.cmake:39 (file):
  file INSTALL cannot copy file
  "/tmp/zint20160417-39600-b9whtp/zint-2.4.3/cmake/modules/FindZint.cmake" to
  "/usr/local/Cellar/cmake/3.5.2/share/cmake/Modules/FindZint.cmake".

[ilovezfs]

Seems there's no issue with suricata: #482

[ilovezfs]

valkyrie seems to need unistd.h #502

[ilovezfs]

ssreflect is superseded by https://github.com/math-comp/math-comp which has coq 8.5 support

[DomT4]

pg_top and sam2p were both more or less fine for me locally and on CI so not sure what happened with them. Added bottles and tests for those in #542, as well as fixing pillar and recode.

[ilovezfs]

Here's a fix for file-roller: #716

[ilovezfs]

Reported blucat issue upstream: ieee8023/blucat#2
Maybe it should get depends_on MaximumMacOSRequirement => :yosemite until the author responds?
#744
blucat fix merged: #746

[ilovezfs]

vcodex like ksh seems to have been subsumed by https://github.com/att/ast for which I've already requested a tag att/ast#3 but received no response. Since the underlying code is still the same old bits as always, maybe stable should be defined as a specific revision until someone upstream agrees to create a tag?

[apjanke]

wartremover: sandbox violation by sbt. #748.

Is it okay if I just edit your original issue description to add references to individual issues as appropriate? I'm going to run through a few more of these over the weekend.

vmalloc: broken download on server side: #749
vcodex: also broken download on server side: #749

swatchbooker: just needs external dependency pillow.

$ brew install -s swatchbooker
swatchbooker: Unsatisfied dependency: pillow
Homebrew does not provide Python dependencies; install with:
  pip install pillow
Error: An unsatisfied requirement failed this build.

[ilovezfs]

This fixes dwarf: #768

[ilovezfs]

It seems like although henplus actually builds fine, it's currently tag-less on GitHub. The download link in the formula doesn't appear to be published anywhere except in the formula, and is apparently the 2009-05-01 0.9.8 from Sourceforge (https://sourceforge.net/projects/henplus/files/henplus/).

However, upstream does still appear to be alive and latest commit was Feb 10, 2016 (https://github.com/neurolabs/henplus/commits/master). So maybe upstream needs to be pestered to create a new tag?
Requisite pestering commenced: neurolabs/henplus#41

[martinlschumann]

ocamlsdl now builds correctly: #809

[ilovezfs]

hqx just needs devil bottling re-enabled, so #839 is prerequisite~~, if anyone would like to look that over.~~

#839 is now merged, so hqx builds again.

[martinlschumann]

mapserver also builds correctly #811

[ilovezfs]

Problem with juise is a sandbox violation: #865 which needs review.

[ilovezfs]

kjell is also a sandbox violation: #870, which needs review

[ilovezfs]

libcanberra dies with "configure: error: Unable to find libltdl" unless it depends on libtool: #871

[apjanke]

Yeah, that solution seems to me like the Right Way to handle this.

Since I do have significant interest in Java, I'll pick that up and see if I can make it happen.

[DomT4]

I'm happy to help review proposed changes, but I am wary of making this... complicated. This will stick around permanently, so we need to keep in mind we're promising to look after it permanently, and if one of us gets whacked by a bus the others need to understand what the mechanism is doing and why.

[apjanke]

Seems kinda straightforward: Java doesn't respect the $HOME environment variable, but it does provide a System Properties hook to set its equivalent for all Java runs, and in turn a $_JAVA_OPTS hook to set System Properties, so we should repoint that along with $HOME whenever we do so for sandboxing or superenv purposes. And maybe pre-create the config dirs for well-known Java build tools for those that cannot auto-create their own dirs.

By creating a sandbox environment that can't use the user's actual home directory, I think we've already effectively signed up to do this permanently... :)

[DomT4]

We do want a lot of this to be retained though, and if we point it in the same place as we do $HOME it won't be. $HOME is discarded at the end of every build and test, but we don't want that system for Java.

We also can't (and IMO shouldn't) use the user's own $HOME directory, because Homebrew's writing outside of its prefix was always pretty much an accident that we couldn't prevent, and now we can prevent it we try to do so.

[MikeMcQuaid]

It still breaks a few things, which is why it's not the default yet. The intention is/was to make it the default as soon as possible, and consequently deprecate having to write it into every applicable formula manually.

Seems like a good approach 👍

[ilovezfs]

sdf looks like it's dead and superseded by http://www.rascal-mpl.org/ which we don't have yet. sdf does seem to build fine, though: #1038

[ilovezfs]

sile cannot be bottled presently due to LuaRocks requirements. There is a new version though: #1039

[ilovezfs]

skytools is a sandbox violation:

/bin/sh /usr/local/lib/postgresql/pgxs/src/makefiles/../../config/install-sh -c -d '/usr/local/share/postgresql/contrib'
mkdir: /usr/local/share/postgresql/contrib: Operation not permitted
make[2]: *** [installdirs-old-contrib] Error 1
make[1]: *** [install] Error 2
make: *** [sub-install] Error 2
==> Sandbox log
May 10 03:00:07 sandboxd[137]: mkdir(49045) deny file-write-create /usr/local/share/postgresql/contrib

[ilovezfs]

slony is also a sandbox violation:

/bin/sh /private/tmp/slony-20160510-51357-1nbbfrp/slony1-2.2.4/config/install-sh -c -m 755 slony1_funcs.2.2.4.so /usr/local/lib/postgresql/
cp: /usr/local/lib/postgresql//#inst.52720#: Operation not permitted
make[2]: *** [install] Error 1
make[1]: *** [install] Error 2
make: *** [install] Error 2
==> Sandbox log
May 10 03:02:54 sandboxd[137]: cp(52726) deny file-write-create /usr/local/lib/postgresql/#inst.52720#

[ilovezfs]

This fixes soccerwindow2: #1044

[ilovezfs]

This fixes ssreflect #1166

I figured it might be a good idea to get the ssreflect 1.5/Coq 8.4 series a working formula+bottle before replacing it outright with the mathcomp/ssreflect 1.6/Coq 8.5 new thing. The latter will depend on #1142 being merged first.

[MikeMcQuaid]

Boneyarding a bunch of these in #2194.

[ilovezfs]

@MikeMcQuaid not sure swatchbooker needs to go as @apjanke said "swatchbooker: just needs external dependency pillow," and pillow is vendored in several formulae in core currently so that should be trivial.

[MikeMcQuaid]

@ilovezfs I got it running locally but it has no installations and is a pretty terrible port so I'd rather we just killed it.

[ilovezfs]

@MikeMcQuaid In that case kill it with 🔥

[UniqMartin]

I updated the top comment with a second list of formulae that don't have an El Capitan bottle, but are not necessarily broken. I also included the reason for why they don't have a bottle. Not sure if this should be a separate issue, but I figured since this is all about completing our bottling, it fits. Generated with:

brew for-each-formula 'puts f.full_name if !f.tap? && f.bottle_defined? && !f.bottle_specification.collector.keys.include?(:el_capitan)'

[MikeMcQuaid]

🚢d.

[ilovezfs]

HOMEBREW_SANDBOX=1 for all!

[MikeMcQuaid]

@ilovezfs see Homebrew/brew#713 😉