Anyone else get this error "Error: invalid option: --with-passenger" - ruby-on-rails

Can not get NGINX to install with passenger
Following the steps you are supposed to...
brew install passenger
Then you run the following command...
brew install nginx --with-passenger
But I get:
Error: invalid option: --with-passenger
Could not find any resources about this online, so asking here.
$ brew install nginx --with-passenger
Usage: brew install [options] formula
Install formula.
formula is usually the name of the formula to install, but it can be specified
in several different ways.
-d, --debug If brewing fails, open an interactive
debugging session with access to IRB or a
shell inside the temporary build directory
--env If std is passed, use the standard build
environment instead of superenv.If super
is passed, use superenv even if the formula
specifies the standard build environment.
--ignore-dependencies Skip installing any dependencies of any
kind. If they are not already present, the
formula will probably fail to install.
--only-dependencies Install the dependencies with specified
options but do not install the specified
formula.
--cc Attempt to compile using provided
compiler. compiler should be the name
of the compiler's executable, for instance
gcc-7 for GCC 7. In order to use LLVM's
clang, use llvm_clang. To specify the
Apple-provided clang, use clang. This
parameter will only accept compilers that
are provided by Homebrew or bundled with
macOS. Please do not file issues if you
encounter errors while using this flag.
-s, --build-from-source Compile the specified formula from source
even if a bottle is provided. Dependencies
will still be installed from bottles if
they are available.
--force-bottle Install from a bottle if it exists for the
current or newest version of macOS, even if
it would not normally be used for
installation.
--include-test Install testing dependencies required to
run brew test.
--devel If formula defines it, install the
development version.
--HEAD If formula defines it, install the HEAD
version, aka. master, trunk, unstable.
--fetch-HEAD Fetch the upstream repository to detect if
the HEAD installation of the formula is
outdated. Otherwise, the repository's HEAD
will be checked for updates when a new
stable or development version has been
released.
--keep-tmp Don't delete the temporary files created
during installation.
--build-bottle Prepare the formula for eventual bottling
during installation.
-f, --force Install without checking for previously
installed keg-only or non-migrated
versions.
-v, --verbose Print the verification and postinstall
steps.
--display-times Print install times for each formula at the
end of the run.
-i, --interactive Download and patch formula, then open a
shell. This allows the user to run
./configure --help and otherwise
determine how to turn the software package
into a Homebrew package.
-g, --git Create a Git repository, useful for
creating patches to the software.
-h, --help Show this message.
Error: invalid option: --with-passenger
This is supposed to work... so yeah.

A late answer. Obviously the documentation on the passenger site is outdated at time of this writing.
According to phusion's github site
https://github.com/phusion/passenger/issues/2187#issue-416881033
the config option --nginx-with-passenger is not valid anymore.
Instead do:
brew install nginx passenger
Addendum:
When using google search for results currently the old page comes up at the top of the list. Here's the currently maintained page with the accurate information:
https://www.phusionpassenger.com/docs/advanced_guides/install_and_upgrade/nginx/install/oss/osx.html

Related

How do I resolve this conda-related brew doctor error?

I've read earlier threads with seemingly related errors, although I'm somewhat skittish about making changes based on what I see here and here, mainly because I'm afraid of breaking things.
I use conda to manage environments on my Mac but there are some packages that aren't available on conda-forge etc., which is why I've had to use Homebrew.
Running brew doctor gives me the errors below, even after brew update. I'm running zsh if it matters, and here's what my $PATH looks like. Any help would be much appreciated.
echo $PATH |tr : '\n'
/usr/local/anaconda3/bin
/usr/local/anaconda3/condabin
/usr/local/anaconda3/bin
/usr/local/anaconda3/bin
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
Here's what brew doctor yields:
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
/usr/local/anaconda3/bin/icu-config
/usr/local/anaconda3/bin/krb5-config
/usr/local/anaconda3/bin/freetype-config
/usr/local/anaconda3/bin/xslt-config
/usr/local/anaconda3/bin/libpng16-config
/usr/local/anaconda3/bin/python3.7-config
/usr/local/anaconda3/bin/libpng-config
/usr/local/anaconda3/bin/xml2-config
/usr/local/anaconda3/bin/python3.7m-config
/usr/local/anaconda3/bin/python3-config
/usr/local/anaconda3/bin/curl-config
/usr/local/anaconda3/bin/ncursesw6-config
/usr/local/anaconda3/bin/pcre-config
/usr/local/anaconda3/bin/nspr-config
/usr/local/anaconda3/bin/ncurses6-config
/usr/local/anaconda3/bin/nss-config
These messages are completely normal. They haven't caused any problems for me so far. I suggest you just ignore them. brew doctor is more of a verbose log than urgent issues with your environment.

There are older versions of Google Cloud Platform tools: Docker

After updating gcloud I get this warning, but how do I do it(Should I remove Docker)?
WARNING: There are older versions of Google Cloud Platform tools on your system PATH.
Please remove the following to avoid accidentally invoking these old tools:
/Applications/Docker.app/Contents/Resources/bin/kubectl
I have this in my .zshrc:
# The next line updates PATH for the Google Cloud SDK.
if [ -f '/Users/<NAME>/google-cloud-sdk/path.zsh.inc' ]; then source '/Users/<NAME>/google-cloud-sdk/path.zsh.inc'; fi
# The next line enables shell command completion for gcloud.
if [ -f '/Users/<NAME>/google-cloud-sdk/completion.zsh.inc' ]; then source '/Users/<NAME>/google-cloud-sdk/completion.zsh.inc'; fi
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
This happens because docker-for-mac installs a bin for kubectl, and gcloud-sdk also installs another bin with gcloud components install kubectl.
My recommendation is to uninstall kubectl as component from gcloud, overwrite the symlink from docker-for-mac, and only use the homebrew installed bin.
Try this commands:
gcloud components remove kubectl
brew install kubernetes-cli
brew link --overwrite kubernetes-cli
TLDR
/usr/local/bin/kubectl is a link installed by Docker: ls -l /usr/local/bin/kubectl => /usr/local/bin/kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl. Removing the link has no side effects and solves the conflict:
rm /usr/local/bin/kubectl
Justification
The conflict is with the Docker-provided version of kubectl so it makes sense to check what Docker docs have to say about it. https://docs.docker.com/desktop/kubernetes/#use-the-kubectl-command
Extract:
If you installed kubectl using Homebrew, or by some other method, and experience conflicts, remove /usr/local/bin/kubectl.
Here is my case you can refer to. After running gcloud components update, I got this warning:
WARNING: There are older versions of Google Cloud Platform tools on your system PATH.
Please remove the following to avoid accidentally invoking these old tools:
/usr/local/Cellar/kubernetes-cli/1.10.2/bin/kubectl
I check this tool using brew list
☁ issue [master] brew list
coreutils gdbm git-lfs icu4c kops kubectx libpng mtr openssl python#2 sqlite tree wxmac
erlang geoip git-redate jpeg kube-ps1 kubernetes-cli libtiff node pcre readline telnet watchman
After reading the doc. I decided to uninstall kubernetes-cli and its dependencies kops, kube-ps1, and kubectx to avoid the conflicts.
☁ issue [master] brew uninstall kops kube-ps1 kubectx
Uninstalling /usr/local/Cellar/kops/1.9.0... (5 files, 129.8MB)
Uninstalling /usr/local/Cellar/kube-ps1/0.6.0... (6 files, 29.0KB)
Uninstalling /usr/local/Cellar/kubectx/0.5.0... (12 files, 27.8KB)
☁ issue [master] brew uninstall kubernetes-cli
Uninstalling /usr/local/Cellar/kubernetes-cli/1.10.2... (178 files, 52.8MB)
☁ issue [master] gcloud components update
All components are up to date.
This warning is gone.
I just went into the Docker file's bin folder and moved the kubectl to the trash.
Do echo $PATH and check which folder takes precedence. In my case it is like .../Users/myname/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:.... Here the kubectl in gcloud is actually before the kubectl from Docker Desktop (which is in /usr/local/bin/kubectl) so there is no problem. If this is also your case you don't need to do anything.
Of course, if you want to completely remove confusion you can just delete the link /usr/local/bin/kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl, or rename it.
Update:
In the recent docker desktop releases they actually provided another link /usr/local/bin/kubectl.docker -> /Applications/Docker.app/Contents/Resources/bin/kubectl to differentiate it from other kubectl so it is not a bad idea to just simply delete the link /usr/local/bin/kubectl -> /Applications/Docker.app/Contents/Resources/bin/kubectl

asdf-erlang doesn't install man pages

I am using asdf + asdf-erlang as my version manager for Erlang. All seems to be working fine, except that typing erl -man mnesia results in No manual entry for mnesia.
I have installed all dependencies mentioned on the asdf-erlang github page. I have also installed xsltproc and fop. Unfortunately "man" folder located under ~/.asdf/installs/erlang/18.3/lib/erlang/erts-73/ is empty. I haven't found man pages being generated elsewhere.
I was trying to locate build log, but I was not successful with that either.
I am using 64bit Ubuntu 16.10 & 16.04.
OK. I finally managed to resolve the issue:
Go to https://www.erlang.org/downloads/ and download manpages for the version(s) of Erlang you have installed using asdf (so for 18.3 you're looking for: http://erlang.org/download/otp_doc_man_18.3.tar.gz)
Copy man folder with its content (extracted from the archive) to ~/.asdf/installs/erlang/<version>/lib/erlang/. After doing so, you should have .~/asdf/installs/erlang/<version>/lib/erlang/man containing man1, man3, man4, man6, man7 (and each of those folders should have some manpages in it).
Repeating steps above for all the versions installed using asdf, allows you to use manpages for specific version of Erlang you are using at the moment.
looks like erlang-manpages are not included in the asdf-erlang since you are using ubuntu i would suggest you add Erlang Solutions repository to your system, call the following commands:
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
sudo dpkg -i erlang-solutions_1.0_all.deb
sudo apt-get update
then install erlang-manpages:
sudo apt-get install erlang-manpages
you could also install erlang-doc — HTML/PDF documentation
sudo apt-get install erlang-doc
check this page for more information
The man path in #MaciekTalaska 's answer seems not correct, it does not work at all, for erlang 18.3.
After reading ASDF's activate script(), here's one statement:
_KERL_MANPATH_REMOVABLE="$HOME/.asdf/installs/erlang/18.3/lib/erlang/man:$HOME/.asdf/installs/erlang/18.3/man"
Therefore, you just need to:
Go to https://www.erlang.org/downloads/ and download manpages for the version(s) of Erlang you have installed using asdf (so for 18.3 you're looking for: http://erlang.org/download/otp_doc_man_18.3.tar.gz)
Copy man folder with its content (extracted from the archive) to $HOME/.asdf/installs/erlang/${version}, but not $HOME/.asdf/installs/erlang/${version}/lib/erlang/ (in fact, there isn't a folder named erlang under lib).

Modularizing and distributing bash script via Homebrew

Context
I have some functions defined in my ~/.bashrc which I'd like to turn into a Homebrew package. Currently, these functions act as custom commands on my command line:
# .bashrc
function foo() {
# do something interesting
}
# at terminal
$ foo
# => does the interesting thing
Approach
I've created a homebrew formula using brew create. My current approach is as follows:
Move the function definitions into a separate file, script, within a directory, brew-script
Make brew-script downloadable as a tarball, brew-script.tar.gz
Have my brew formula append text to the end of ~/.bash_profile to include script when terminal session starts
Concerns
Is modifying .bash_profile in a brew formula bad practice? (eg. when uninstalling with brew uninstall script, brew should somehow remove the text that was appended to .bash_profile... Parsing .bash_profile doesn't seem very fun.)
Is there a convention already established for including functions in bash scripts so that they are available from the command line?
Is it common to simply ask the user to add some text to their .bash_profile or .bashrc?
Desired result
Should be able to install cleanly with brew and then run foo as a command:
$ brew install script
$ foo
# => does the interesting thing
(Assume the brew formula is already installed locally. I'll worry about auditing and pushing the formula to homebrew later)
Refer https://github.com/Homebrew/homebrew/issues/50232 and https://github.com/Homebrew/homebrew/issues/50231.
I have a script that safely‡ modifies ~/.bash_profile as part of a homebrew install process. https://github.com/paul-hammant/homebrew-tap/blob/master/switchjdk.rb
‡ allegedly
Without using homebrew:
to put your bash scripts in some file such as bashrc or any other name works, then put the following line:
source "path/to/brew-script/script"
somewhere in your bash profile.
Then you just have to make sure you refresh or reload your bash profile by running . ~/.bash_profile or source ~/.bash_profile.
How homebrew installs work:
When you installed homebrew it added a line to your bash_profile that modifies your $PATH variable to include the path to the homebrew install repo, so that whenever brew installs something it becomes findable through your PATH.
If you use brew create you must have your script uploaded somewhere on the internet, because the argument brew install takes is a URL. I.e if I create my script at my_bash_function.tar.gz then I would do
brew create http://web.mit.edu/dianah13/www/my_bash_function.tar.gz
It also templates a pull request to include your package in homebrew's main repo.

Travis sudo is disabled

I want to use apt to install some packages for the test, however, it fails due to that the sudo is disabled. I found the following in the test output:
Sudo, the FireFox addon, setuid and setgid have been disabled.
It seems that the output comes from this line in travic-ci, but setting paranoid_mode to false in .travis.yml does not work.
How to enable sudo access?
PS: I am using private repo.
EDIT: The following .travis.yml will fail due to sudo: must be setuid root when running sudo apt-get update -qq
language: python
python:
- "3.4"
before_install:
- sudo apt-get update -qq
script:
- nosetests
Setting sudo: true and/or paranoid_mode: false does not work.
Sudo access is turned off on our Docker based architecture, which will be used in two contexts:
repositories opt in using sudo: false in their .travis.yml file (it additionally needs to be turned on on our side)
on our educational program (see http://education.travis-ci.com)
Builds running on our Docker based architecture currently cannot be allowed sudo access due to certain security concerns in the LXC/Docker layer. We hope this will be fixed in the near future, but unfortunately the issue is out of our own hands.
We are also working on improving the Firefox addon, which currently uses sudo itself, but shouldn't. We'll post on our blog once this has happened.
To extend the existing answer, if you put in .travis.yml:
sudo: required
Travis should switch your build to use their "standard infrastructure" (rather than their "container based infrastructure") and then you can use sudo.
References:
https://docs.travis-ci.com/user/workers/standard-infrastructure
https://docs.travis-ci.com/user/workers/container-based-infrastructure/
Nov 2018 Update
It seems that container-based infrastructure is getting deprecated. From the docs:
Container-based infrastructure is currently being deprecated. Please
use the fully-virtualized infrastrstructure via sudo: required
instead.
As explained in "Combining The Linux Infrastructures"
Going forward, we will slowly transition the container-based environment out, in favor of a build environment that is entirely virtual machine-based.
Folks using container-based infrastructures will be the only ones affected, and this transition will roll out slowly, depending on whether you specify sudo: false in your .travis.yml.
This is illustrated in Git 2.20 (Q4 2018), with:
Travis CI will soon deprecate the container-based infrastructure enabled by sudo: false in ce59dff (Git 2.8.0, Jan. 2016).
See commit 0f0c511 (01 Nov 2018) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 57f06d5, 13 Nov 2018)
travis-ci: install packages in 'ci/install-dependencies.sh'
Ever since we started using Travis CI, we specified the list of packages to install in '.travis.yml' via the APT addon.
While running our builds on Travis CI's container-based infrastructure we didn't have another choice, because that environment didn't support 'sudo', and thus we didn't have permission to install packages ourselves.
With the switch to the VM-based infrastructure in the previous patch we do get a working 'sudo', so we can install packages by running 'sudo apt-get -y install ...' as well.
Let's make use of this and install necessary packages in 'ci/install-dependencies.sh', so all the dependencies (i.e. both packages and "non-packages" (P4 and Git-LFS)) are handled in the same file.
Install gcc-8 only in the 'linux-gcc' build job; so far it has been unnecessarily installed in the 'linux-clang' build job as well.
Print the versions of P4 and Git-LFS conditionally, i.e. only when they have been installed; with this change even the static analysis and documentation build jobs start using 'ci/install-dependencies.sh'
to install packages, and neither of these two build jobs depend on and
thus install those.
This change will presumably be beneficial for the upcoming Azure Pipelines integration preliminary versions of that patch series run a couple of 'apt-get' commands to install the necessary packages before running 'ci/install-dependencies.sh', but with this patch it will be sufficient to run only 'ci/install-dependencies.sh'.

Resources