pg gem fails to compile with chef 12.0

Just ran into this issue when my omnibus plugin for vagrant upgraded the chef-client from 11.16 to 12.0.
Fixed by pinning to last known 11.x version that worked.
config.omnibus.chef_version = '11.16.4'

Same issue here on 12.0.3:
  * chef_gem[pg] action install

    ================================================================================
    Error executing action `install` on resource 'chef_gem[pg]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '1'
    ---- Begin output of /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" ----
    STDOUT: Building native extensions.  This could take a while...
    STDERR: ERROR:  Error installing pg:
    	ERROR: Failed to build gem native extension.

        /opt/chef/embedded/bin/ruby -r ./siteconf20150108-10667-dr4hn.rb extconf.rb
    checking for pg_config... yes
    Using config values from /usr/bin/pg_config
    checking for libpq-fe.h... yes
    checking for libpq/libpq-fs.h... yes
    checking for pg_config_manual.h... yes
    checking for PQconnectdb() in -lpq... no
    checking for PQconnectdb() in -llibpq... no
    checking for PQconnectdb() in -lms/libpq... no
    Can't find the PostgreSQL client library (libpq)
    *** extconf.rb failed ***
    Could not create Makefile due to some reason, probably lack of necessary
    libraries and/or headers.  Check the mkmf.log file for more details.  You may
    need configuration options.

    Provided configuration options:
    	--with-opt-dir
    	--with-opt-include
    	--without-opt-include=${opt-dir}/include
    	--with-opt-lib
    	--without-opt-lib=${opt-dir}/lib
    	--with-make-prog
    	--without-make-prog
    	--srcdir=.
    	--curdir
    	--ruby=/opt/chef/embedded/bin/ruby
    	--with-pg
    	--without-pg
    	--enable-windows-cross
    	--disable-windows-cross
    	--with-pg-config
    	--without-pg-config
    	--with-pg_config
    	--without-pg_config
    	--with-pg-dir
    	--without-pg-dir
    	--with-pg-include
    	--without-pg-include=${pg-dir}/include
    	--with-pg-lib
    	--without-pg-lib=${pg-dir}/lib
    	--with-pqlib
    	--without-pqlib
    	--with-libpqlib
    	--without-libpqlib
    	--with-ms/libpqlib
    	--without-ms/libpqlib

    extconf failed, exit code 1

    Gem files will remain installed in /opt/chef/embedded/lib/ruby/gems/2.1.0/gems/pg-0.18.1 for inspection.
    Results logged to /opt/chef/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.18.1/gem_make.out
    ---- End output of /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" ----
    Ran /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" returned 1

This also currently affects the current chefdk (v0.3.5)

Tracking this. Labeled as blocked as this mainly appears to be related to ruby issues packaged with Chef omnibus and will likely be resolved in Chef 12 at some point.

Facing same issue on Suse Enterprise. Issue is not with OS and PostgreSQL.
rvmsudo gem install pg -- --with-pg-config=/usr/lib/postgresql93/bin/pg_config --with-pg-lib=/usr/include/pgsql/libpq/
Building native extensions with: '--with-pg-config=/usr/lib/postgresql93/bin/pg_config --with-pg-lib=/usr/include/pgsql/libpq/'
This could take a while...
/usr/local/rvm/rubies/ruby-2.1.2/lib/ruby/site_ruby/2.1.0/rubygems/ext/builder.rb:73: warning: Insecure world writable dir /usr/local/rvm/gems/ruby-2.1.2@cmaa-rails4/bin in PATH, mode 042777
ERROR:  Error installing pg:
ERROR: Failed to build gem native extension.
/usr/local/rvm/rubies/ruby-2.1.2/bin/ruby -r ./siteconf20150211-15891-1f05xb7.rb extconf.rb --with-pg-config=/usr/lib/postgresql93/bin/pg_config --with-pg-lib=/usr/include/pgsql/libpq/

Using config values from /usr/lib/postgresql93/bin/pg_config
extconf.rb:32: warning: Insecure world writable dir /usr/local/rvm/gems/ruby-2.1.2@cmaa-rails4/bin in PATH, mode 042777
checking for libpq-fe.h... yes
checking for libpq/libpq-fs.h... yes
checking for pg_config_manual.h... yes
checking for PQconnectdb() in -lpq... no
checking for PQconnectdb() in -llibpq... no
checking for PQconnectdb() in -lms/libpq... no
Can't find the PostgreSQL client library (libpq)
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/local/rvm/rubies/ruby-2.1.2/bin/ruby
--with-pg
--without-pg
--with-pg-config
--with-pg-dir
--without-pg-dir
--with-pg-include
--without-pg-include=${pg-dir}/include
--with-pg-lib=${pg-dir}/lib
--with-pqlib
--without-pqlib
--with-libpqlib
--without-libpqlib
--with-ms/libpqlib
--without-ms/libpqlib
extconf failed, exit code 1
Gem files will remain installed in<EMAIL_ADDRESS>for inspection.
Results logged to<EMAIL_ADDRESS>

@vajapravin are you even using Chef and/or the postgresql cookbook?  If you're looking for general support on installing the pg gem into rvm then you've come to the wrong place.  If you're using chef without omnibus and installing via rvm you also very definitely are not hitting this bug.
I can tell you that the pg gem is not finding the postgres client libraries, so you almost certainly do not have the libraries installed correctly on your OS and the issue is probably with the OS not having the correct packages, or else you need to look elsewhere to get support for the pg gem installing in SuSE.

This issue seems to have been fixed with the release of Chef 12.0.3. The test-kitchen suites are passing as a confirmation.

I'm still seeing this issue with this cookbook and the pg gem not finding libpq. It installs fine when it is the only thing in the run list, but adding any other cookbooks to the run list (which may trigger postgresql::ruby) causes the same failure.

@lamont-granquist - issue was with packages. was unable to found packages on suse. installed packages and it's gone. thx

For anyone that may find this issue later, I switched to using https://github.com/phlipper/chef-postgresql/, which appears to be actively developed at this time, and supports features that I needed, at least.

I'm still seeing the issue, two.
ubuntu 14.04 and 12.04
chef 12.0.3
postgresql cookbok 3.4.16
Recipe: postgresql::ruby
* chef_gem[pg] action install

  ================================================================================
  Error executing action `install` on resource 'chef_gem[pg]'
  ================================================================================

  Mixlib::ShellOut::ShellCommandFailed
  ------------------------------------
  Expected process to exit with [0], but received '1'
  ---- Begin output of /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" ----
  STDOUT: Building native extensions.  This could take a while...
  STDERR: ERROR:  Error installing pg:
  	ERROR: Failed to build gem native extension.

      /opt/chef/embedded/bin/ruby -r ./siteconf20150224-10329-1i77ti5.rb extconf.rb
  checking for pg_config... yes
  Using config values from /usr/bin/pg_config
  checking for libpq-fe.h... yes
  checking for libpq/libpq-fs.h... yes
  checking for pg_config_manual.h... yes
  checking for PQconnectdb() in -lpq... no
  checking for PQconnectdb() in -llibpq... no
  checking for PQconnectdb() in -lms/libpq... no
  Can't find the PostgreSQL client library (libpq)
  *** extconf.rb failed ***
  Could not create Makefile due to some reason, probably lack of necessary
  libraries and/or headers.  Check the mkmf.log file for more details.  You may
  need configuration options.

  Provided configuration options:
  	--with-opt-dir
  	--with-opt-include
  	--without-opt-include=${opt-dir}/include
  	--with-opt-lib
  	--without-opt-lib=${opt-dir}/lib
  	--with-make-prog
  	--without-make-prog
  	--srcdir=.
  	--curdir
  	--ruby=/opt/chef/embedded/bin/ruby
  	--with-pg
  	--without-pg
  	--enable-windows-cross
  	--disable-windows-cross
  	--with-pg-config
  	--without-pg-config
  	--with-pg_config
  	--without-pg_config
  	--with-pg-dir
  	--without-pg-dir
  	--with-pg-include
  	--without-pg-include=${pg-dir}/include
  	--with-pg-lib
  	--without-pg-lib=${pg-dir}/lib
  	--with-pqlib
  	--without-pqlib
  	--with-libpqlib
  	--without-libpqlib
  	--with-ms/libpqlib
  	--without-ms/libpqlib

  extconf failed, exit code 1

  Gem files will remain installed in /opt/chef/embedded/lib/ruby/gems/2.1.0/gems/pg-0.18.1 for inspection.
  Results logged to /opt/chef/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.18.1/gem_make.out
  ---- End output of /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" ----
  Ran /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" returned 1

  Cookbook Trace:
  ---------------
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:57:in `rescue in from_file'
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:23:in `from_file'
  /var/chef/cache/cookbooks/shipcloud_app/recipes/default.rb:112:in `from_file'

  Resource Declaration:
  ---------------------
  # In /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb

   57:     chef_gem "pg"
   58:   rescue Gem::Installer::ExtensionBuildError, Mixlib::ShellOut::ShellCommandFailed => e

  Compiled Resource:
  ------------------
  # Declared in /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:57:in `rescue in from_file'

  chef_gem("pg") do
    action :install
    retries 0
    retry_delay 2
    default_guard_interpreter :default
    package_name "pg"
    version "0.18.1"
    timeout 900
    gem_binary "/opt/chef/embedded/bin/gem"
    declared_type :chef_gem
    cookbook_name "postgresql"
    recipe_name "ruby"
  end

 [2015-02-24T14:30:25+00:00] WARN: Failed to properly build pg gem. Forcing properly linking and retrying (omnibus fix)
* execute[generate pg gem Makefile] action run
  - execute PATH=$PATH:/usr/pgsql-9.3/bin /opt/chef/embedded/bin/ruby extconf.rb
* execute[make pg gem lib] action run

  ================================================================================
  Error executing action `run` on resource 'execute[make pg gem lib]'
  ================================================================================

  Errno::ENOENT
  -------------
  No such file or directory - make

  Cookbook Trace:
  ---------------
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:101:in `rescue in rescue in from_file'
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:56:in `rescue in from_file'
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:23:in `from_file'
  /var/chef/cache/cookbooks/shipcloud_app/recipes/default.rb:112:in `from_file'

  Resource Declaration:
  ---------------------
  # In /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb

   96:     lib_maker = execute 'make pg gem lib' do
   97:       command 'make'
   98:       cwd ext_dir
   99:       action :nothing
  100:     end
  101:     lib_maker.run_action(:run)

  Compiled Resource:
  ------------------
  # Declared in /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:96:in `rescue in rescue in from_file'

  execute("make pg gem lib") do
    action [:nothing]
    retries 0
    retry_delay 2
    default_guard_interpreter :execute
    command "make"
    backup 5
    cwd "/opt/chef/embedded/lib/ruby/gems/2.1.0/gems/pg-0.18.1/ext"
    returns 0
    declared_type :execute
    cookbook_name "postgresql"
    recipe_name "ruby"
  end

================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/shipcloud_app/recipes/default.rb
================================================================================

Errno::ENOENT
-------------
execute[make pg gem lib] (postgresql::ruby line 96) had an error: Errno::ENOENT: No such file or directory - make

Cookbook Trace:
---------------
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:101:in `rescue in rescue in from_file'
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:56:in `rescue in from_file'
  /var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:23:in `from_file'
  /var/chef/cache/cookbooks/shipcloud_app/recipes/default.rb:112:in `from_file'

Relevant File Content:
----------------------
/var/chef/cache/cookbooks/postgresql/recipes/ruby.rb:

 94:      lib_builder.run_action(:run)
 95:
 96:      lib_maker = execute 'make pg gem lib' do
 97:        command 'make'
 98:        cwd ext_dir
 99:        action :nothing
100:      end
101>>     lib_maker.run_action(:run)
102:
103:      lib_installer = execute 'install pg gem lib' do
104:        command 'make install'
105:        cwd ext_dir
106:        action :nothing
107:      end
108:      lib_installer.run_action(:run)
109:
110:      spec_installer = execute 'install pg spec' do

Running handlers:
 [2015-02-24T14:30:30+00:00] ERROR: Running exception handlers
Running handlers complete
 [2015-02-24T14:30:30+00:00] ERROR: Exception handlers complete
 [2015-02-24T14:30:30+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out

/opt/chef/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.18.1/mkmf.log:
http://pastebin.com/dQMgyHGP

@sfroehler - gcc and g++ is installed?

@sfroehler You don't have build-essential installed. The gem isn't finding make!

gcc is installed, g++ not - and make is also missing. I don't know why i didn't see this early and I thought this was installed by the build-essentials cookbook.
When I install g++ and make via apt-get install it works. Not sure whats going wrong here, but it seems to be a different issue. Sorry for the confusion.

@mshappe yeah, I just realized that make is missing. But I have build-essential installed...not sure whats going wrong

@sfroehler have you set the compile_time attribute to true? https://github.com/opscode-cookbooks/build-essential#user-content-gems-with-c-extensions

@amdprophet  yes, I did. But still getting the same error. :confused:

This is actually also done in the ruby recipe: https://github.com/hw-cookbooks/postgresql/blob/develop/recipes/ruby.rb#L32

Hello, I'm still seeing this on chef 12.1.0, using the postgresql cookbook, and trying to bundle install pg under rbenv_ruby 2.1.5:
root@vultr:/home/git/gitlab/.bundle/ruby/2.1.0/gems/pg-0.15.1/ext# chef-solo --version
Chef: 12.1.0
I did remove the   CONFIG["LIBPATHENV"] = "LD_LIBRARY_PATH", but it did not help.
Here is my log:
root@vultr:/home/git/gitlab/.bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.15.1# cat mkmf.log
find_executable: checking for pg_config... -------------------- yes

--------------------

find_header: checking for libpq-fe.h... -------------------- yes

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby  -lpthread -ldl -lcrypt -lm   -lc"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5:   return 0;
6: }
/* end */

"gcc -E -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC  conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <libpq-fe.h>
/* end */

--------------------

find_header: checking for libpq/libpq-fs.h... -------------------- yes

"gcc -E -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC  conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <libpq/libpq-fs.h>
/* end */

--------------------

find_header: checking for pg_config_manual.h... -------------------- yes

"gcc -E -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC  conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <pg_config_manual.h>
/* end */

--------------------

have_library: checking for PQconnectdb() in -lpq... -------------------- no

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lpq  -lpthread -ldl -lcrypt -lm   -lc"
/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { void ((*volatile p)()); p = (void ((*)()))PQconnectdb; return 0; }
/* end */

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lpq  -lpthread -ldl -lcrypt -lm   -lc"
conftest.c: In function ‘t’:
conftest.c:15:1: error: too few arguments to function ‘PQconnectdb’
 int t(void) { PQconnectdb(); return 0; }
 ^
In file included from conftest.c:3:0:
/usr/include/postgresql/libpq-fe.h:250:16: note: declared here
 extern PGconn *PQconnectdb(const char *conninfo);
                ^
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { PQconnectdb(); return 0; }
/* end */

--------------------

have_library: checking for PQconnectdb() in -llibpq... -------------------- no

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -llibpq  -lpthread -ldl -lcrypt -lm   -lc"
/usr/bin/ld: cannot find -llibpq
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { void ((*volatile p)()); p = (void ((*)()))PQconnectdb; return 0; }
/* end */

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -llibpq  -lpthread -ldl -lcrypt -lm   -lc"
conftest.c: In function ‘t’:
conftest.c:15:1: error: too few arguments to function ‘PQconnectdb’
 int t(void) { PQconnectdb(); return 0; }
 ^
In file included from conftest.c:3:0:
/usr/include/postgresql/libpq-fe.h:250:16: note: declared here
 extern PGconn *PQconnectdb(const char *conninfo);
                ^
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { PQconnectdb(); return 0; }
/* end */

--------------------

have_library: checking for PQconnectdb() in -lms/libpq... -------------------- no

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lms/libpq  -lpthread -ldl -lcrypt -lm   -lc"
/usr/bin/ld: cannot find -lms/libpq
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { void ((*volatile p)()); p = (void ((*)()))PQconnectdb; return 0; }
/* end */

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib  -L/usr/lib -Wl,-rpath,/usr/lib     -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lms/libpq  -lpthread -ldl -lcrypt -lm   -lc"
conftest.c: In function ‘t’:
conftest.c:15:1: error: too few arguments to function ‘PQconnectdb’
 int t(void) { PQconnectdb(); return 0; }
 ^
In file included from conftest.c:3:0:
/usr/include/postgresql/libpq-fe.h:250:16: note: declared here
 extern PGconn *PQconnectdb(const char *conninfo);
                ^
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { PQconnectdb(); return 0; }
/* end */

--------------------

root@vultr:/home/git/gitlab/.bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.15.1#

:+1: same issue here:
Chef: 12.2.1
Ruby: 2.1.4p265
ubuntu@ip-10-178-187-234:~$ sudo cat /opt/chef/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.18.1/mkmf.log
find_executable: checking for pg_config... -------------------- yes

--------------------

find_header: checking for libpq-fe.h... -------------------- yes

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby  -lpthread -ldl -lcrypt -lm   -lc"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main(int argc, char **argv)
4: {
5:   return 0;
6: }
/* end */

"gcc -E -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC  conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <libpq-fe.h>
/* end */

--------------------

find_header: checking for libpq/libpq-fs.h... -------------------- yes

"gcc -E -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC  conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <libpq/libpq-fs.h>
/* end */

--------------------

find_header: checking for pg_config_manual.h... -------------------- yes

"gcc -E -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC  conftest.c -o conftest.i"
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <pg_config_manual.h>
/* end */

--------------------

have_library: checking for PQconnectdb() in -lpq... -------------------- no

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lpq  -lpthread -ldl -lcrypt -lm   -lc"
/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>/usr/lib/libpq.so: undefined reference to<EMAIL_ADDRESS>collect2: error: ld returned 1 exit status
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { void ((*volatile p)()); p = (void ((*)()))PQconnectdb; return 0; }
/* end */

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lpq  -lpthread -ldl -lcrypt -lm   -lc"
conftest.c: In function ‘t’:
conftest.c:15:1: error: too few arguments to function ‘PQconnectdb’
 int t(void) { PQconnectdb(); return 0; }
 ^
In file included from conftest.c:3:0:
/usr/include/postgresql/libpq-fe.h:250:16: note: declared here
 extern PGconn *PQconnectdb(const char *conninfo);
                ^
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { PQconnectdb(); return 0; }
/* end */

--------------------

have_library: checking for PQconnectdb() in -llibpq... -------------------- no

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -llibpq  -lpthread -ldl -lcrypt -lm   -lc"
/usr/bin/ld: cannot find -llibpq
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { void ((*volatile p)()); p = (void ((*)()))PQconnectdb; return 0; }
/* end */

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -llibpq  -lpthread -ldl -lcrypt -lm   -lc"
conftest.c: In function ‘t’:
conftest.c:15:1: error: too few arguments to function ‘PQconnectdb’
 int t(void) { PQconnectdb(); return 0; }
 ^
In file included from conftest.c:3:0:
/usr/include/postgresql/libpq-fe.h:250:16: note: declared here
 extern PGconn *PQconnectdb(const char *conninfo);
                ^
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { PQconnectdb(); return 0; }
/* end */

--------------------

have_library: checking for PQconnectdb() in -lms/libpq... -------------------- no

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lms/libpq  -lpthread -ldl -lcrypt -lm   -lc"
/usr/bin/ld: cannot find -lms/libpq
collect2: error: ld returned 1 exit status
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { void ((*volatile p)()); p = (void ((*)()))PQconnectdb; return 0; }
/* end */

"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/include/postgresql -I/opt/chef/embedded/include -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/lib -Wl,-R/usr/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib      -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lms/libpq  -lpthread -ldl -lcrypt -lm   -lc"
conftest.c: In function ‘t’:
conftest.c:15:1: error: too few arguments to function ‘PQconnectdb’
 int t(void) { PQconnectdb(); return 0; }
 ^
In file included from conftest.c:3:0:
/usr/include/postgresql/libpq-fe.h:250:16: note: declared here
 extern PGconn *PQconnectdb(const char *conninfo);
                ^
checked program was:
/* begin */
 1: #include "ruby.h"
 2:
 3: #include <libpq-fe.h>
 4:
 5: /*top*/
 6: extern int t(void);
 7: int main(int argc, char **argv)
 8: {
 9:   if (argc > 1000000) {
10:     printf("%p", &t);
11:   }
12:
13:   return 0;
14: }
15: int t(void) { PQconnectdb(); return 0; }
/* end */

--------------------

I'm still having problems with this on Chef 12.2.1 with the latest Postgres cookbook. Is there an accepted solution for this? Can't seem to find anything. Thanks!
Recipe: postgresql::ruby
  * chef_gem[pg] action install

    ================================================================================
    Error executing action `install` on resource 'chef_gem[pg]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '1'
    ---- Begin output of /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" ----
    STDOUT: Building native extensions.  This could take a while...
    STDERR: ERROR:  Error installing pg:
    	ERROR: Failed to build gem native extension.

        /opt/chef/embedded/bin/ruby -r ./siteconf20150507-20474-7wxod2.rb extconf.rb
    checking for pg_config... yes
    Using config values from /usr/bin/pg_config
    checking for libpq-fe.h... yes
    checking for libpq/libpq-fs.h... yes
    checking for pg_config_manual.h... yes
    checking for PQconnectdb() in -lpq... no
    checking for PQconnectdb() in -llibpq... no
    checking for PQconnectdb() in -lms/libpq... no
    Can't find the PostgreSQL client library (libpq)
    *** extconf.rb failed ***
    Could not create Makefile due to some reason, probably lack of necessary
    libraries and/or headers.  Check the mkmf.log file for more details.  You may
    need configuration options.

    Provided configuration options:
    	--with-opt-dir
    	--with-opt-include
    	--without-opt-include=${opt-dir}/include
    	--with-opt-lib
    	--without-opt-lib=${opt-dir}/lib
    	--with-make-prog
    	--without-make-prog
    	--srcdir=.
    	--curdir
    	--ruby=/opt/chef/embedded/bin/ruby
    	--with-pg
    	--without-pg
    	--enable-windows-cross
    	--disable-windows-cross
    	--with-pg-config
    	--without-pg-config
    	--with-pg_config
    	--without-pg_config
    	--with-pg-dir
    	--without-pg-dir
    	--with-pg-include
    	--without-pg-include=${pg-dir}/include
    	--with-pg-lib
    	--without-pg-lib=${pg-dir}/lib
    	--with-pqlib
    	--without-pqlib
    	--with-libpqlib
    	--without-libpqlib
    	--with-ms/libpqlib
    	--without-ms/libpqlib

    extconf failed, exit code 1

    Gem files will remain installed in /opt/chef/embedded/lib/ruby/gems/2.1.0/gems/pg-0.18.1 for inspection.
    Results logged to /opt/chef/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/pg-0.18.1/gem_make.out
    ---- End output of /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" ----
    Ran /opt/chef/embedded/bin/gem install pg -q --no-rdoc --no-ri -v "0.18.1" returned 1

    Cookbook Trace:
    ---------------
    /root/chef-solo/cookbooks-2/postgresql/recipes/ruby.rb:55:in `rescue in from_file'
    /root/chef-solo/cookbooks-2/postgresql/recipes/ruby.rb:21:in `from_file'
    /root/chef-solo/cookbooks-2/database/recipes/postgresql.rb:20:in `from_file'
    /root/chef-solo/cookbooks-3/sana-protocol-builder/recipes/default.rb:9:in `from_file'

    Resource Declaration:
    ---------------------
    # In /root/chef-solo/cookbooks-2/postgresql/recipes/ruby.rb

     55:     chef_gem "pg"
     56:   rescue Gem::Installer::ExtensionBuildError, Mixlib::ShellOut::ShellCommandFailed => e

    Compiled Resource:
    ------------------
    # Declared in /root/chef-solo/cookbooks-2/postgresql/recipes/ruby.rb:55:in `rescue in from_file'

    chef_gem("pg") do
      action :install
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      package_name "pg"
      version "0.18.1"
      timeout 900
      gem_binary "/opt/chef/embedded/bin/gem"
      declared_type :chef_gem
      cookbook_name :postgresql
      recipe_name "ruby"
    end

The solution is:
In the cookbook where you include the postgresql::ruby recipe add following at the top:
node.default['build-essential']['compile_time'] = true
include_recipe 'build-essential'

Also broken in ubuntu 14.04 pg-0.18.2 using chef client 12.3.0-1. Same output pretty much as @axos88 (minus his pg version).
I have tried everything in this thread and nothing helps. Any ideas?

FYI build-essential cookbook wasn't running at compile time for me either (chef 11.16.4 omnibus), but manually setting node['build-essential']['compile_time'] = true in my .kitchen.yml allowed the run the complete

Can this be re-opened @amdprophet ?

FYI I was working on spiking out a pg-chef-gem cookbook as an analog to the approach of the mysql2_chef_gem cookbook.
It's not yet working and I had to move on to something else for now, but I can't see why it shouldn't be possible, if someone wants to submit PRs. A custom postgresql is required for now, and can be found in the berksfile. test-kitchen suite should be functional.

Pls reopen. Same issue as @nlopes Debian 7 with ChefDK released .deb.
Also, hi @patcon

I'm seeing this issue with Ubuntu 14.04 and Chef Client 12.4.2, getting the same output as @sfroehler.
It's looking like no one really has a good answer to this?

Hit this with chefdk 7.0 / chef-solo 12.4.1. Reverted to chef-solo 11.14.2 for testing, deploying.

Yeah, hitting this too.  Maybe this hacky workaround will someone more capable a bit of insight.
agrant@vagrant:~$ chef-client -v
Chef: 12.4.3
Vagrant 1.7.4
Ubuntu 14.04 guest on Mac 10.9.5
workaround:
I've added build essential to my wrapper bemyerp-postgresql's metadata.rb
depends 'build-essential'  #this was added
depends 'postgresql'
Now, this is not the only cookbook to require build-essential in my build, so I found it odd that I would encounter this problem.  Apparently however, if my bemyerp-postgresql cookbooks recipe are first in the sequence, before other cookbooks using build-essential, then things are ok.  If other cookbooks using build_essential go first, then fail.
Could it be that postgresql's use of build_essential requires it to be 'just so'.  Which it gets if it goes first, but not if it some other cookbooks gets there first?

test-kitchen 1.4.2
chef-dk 0.8.0
hostbox: windows 7
guestbox: OEL 6.5
locked to omnibus version 12.3.0 (dsc resources fail nastily on 12.4+)
Running into this same issue on test kitchen when attempting to install berkflow 0.7.0
gem_package 'berkflow' do
  version '0.7.0'
  options('--no-document --no-user-install --install-dir /opt/chefdk/embedded/lib/ruby/gems/2.1.0')
  action :install
end

Attempted the fix mentioned above
fix = Chef::Util::FileEdit.new('/opt/chef/embedded/lib/ruby/2.1.0/x86_64-linux/rbconfig.rb')
fix.search_file_delete_line('^.*LIBPATHENV.*$')
fix.write_file

The error claims that a file was made at /opt/chefdk/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/ffi-1.9.10/gem_make.out but the only one on the system was /opt/chefdk/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/ffi-1.9.8/gem_make.out, contents are
/opt/chef/embedded/bin/ruby -r ./siteconf20150428-27228-1lwal9u.rb extconf.rb
checking for ffi_call() in -lffi... yes
checking for ffi_prep_closure()... yes
checking for ffi_raw_call()... yes
checking for ffi_prep_raw_closure()... yes
checking for rb_thread_blocking_region()... yes
checking for rb_thread_call_with_gvl()... yes
checking for rb_thread_call_without_gvl()... yes
checking for ffi_prep_cif_var()... yes
creating extconf.h
creating Makefile

make "DESTDIR=" clean

make "DESTDIR="
compiling StructByValue.c
compiling FunctionInfo.c
compiling Type.c
compiling ClosurePool.c
compiling Buffer.c
compiling LastError.c
compiling Variadic.c
compiling Platform.c
compiling LongDouble.c
compiling Types.c
compiling Pointer.c
compiling AbstractMemory.c
compiling Function.c
compiling StructByReference.c
compiling MemoryPointer.c
compiling MappedType.c
compiling StructLayout.c
compiling DynamicLibrary.c
compiling DataConverter.c
compiling Call.c
compiling ArrayType.c
compiling ffi.c
compiling Struct.c
compiling MethodHandle.c
compiling Thread.c
linking shared-object ffi_c.so

make "DESTDIR=" install
/usr/bin/install -c -m 0755 ffi_c.so ./.gem.20150428-27228-sdvhfc
installing default ffi_c libraries

If I manually install the berkflow gem with
chef gem install berkflow -v 0.7.0 --no-user-install

it works as expected.
On a side note, execute 'chef gem install berkflow -v 0.7.0 --no-user-install' places it on a strange path under root when I would expect it to be under /opt/chefdk/.../bin
I'm trying to make a pre-configured chef workstation with the gems my org adds in for our workflow

+1  Seeing this on mysql gem.
chef 12.3.0
trying the "fix" now.

Also hitting this on Ubuntu 14.04 w/ chef-client 12.3.0. Trying to install pg for an lwrp I wrote, have libpq-dev installed at the system level.

What's odd for me is it's failing running this
/opt/sensu/embedded/bin/ruby extconf.rb
It didn't even get to the part where it tried to compile it or at least didn't log it.
Running chef a second time works however.
I put ignore_failures true for the gem install just so jenkins would stop failing and the gem eventually gets installed but it's not a gem I need other that would be problematic.

Try setting node['apt']['compile_time_update'] = true. Build essential is required at compile time as part of the pg gem install process, but you need to manually make sure that apt-get update is running before that.
I seem to remember some reason this couldn't be done automatically, but maybe I'm wrong...

tried the compile time, didn't work.
tried downgrading chef, didn't work.
What's odd is it's not even getting to the point of compiling the gem it fails earlier than that.

Yeah, I've tried all the recommended work-around to no avail. For me, it can't find the libpq-dev dependency even though it is installed and the pg gem installs for the system ruby just fine. In my case since there doesn't seem to be a direct solution to this readily available I'm going to rewrite my lwrp to shell out to psql commands. It's going to be a bit of a PITA, but it's better than not working at all.

Ah, just ran into this again yesterday when working on a new cookbook, and saw that I needed to set build-essentil['compile_time'' to true manually, even though it was supposedly in the postgresql::ruby recipe. But I did get it working. I seem to remember a related "normal" level attribute set in some other cookbook, so I'd recommend override, rather than the "default" level I suggested above.

I changed the order of the gem install and it's better.  I got the same
error on another gem ( zookeeper ) but that hasn't repeated.
What is the root cause of all this?  This isn't just a pg gem issue.
On Mon, Dec 7, 2015 at 3:19 PM, Patrick Connolly<EMAIL_ADDRESS>wrote:

Ah, just ran into this again yesterday when working on a new cookbook, and
saw that I needed to set build-essentil['compile_time'' to true manually,
even though it was supposedly in the postgresql::ruby recipe. But I did get
it working. I seem to remember a related "normal" level attribute set in
some other cookbook, so I'd recommend override, rather than the "default"
level I suggested above.
—
Reply to this email directly or view it on GitHub
https://github.com/hw-cookbooks/postgresql/issues/212#issuecomment-162648220
.

It has something to do with how the dependency paths for the omnibus components are set. I've lifted the solution from the postgres cookbook referenced above into my LWRP and it seems to work: https://github.com/hw-cookbooks/postgresql/blob/develop/recipes/ruby.rb#L32

What is the root cause of all this?

I think the mysql2_chef_gem cookbook has the proper future-oriented approach (see my comment above for link to abandonned WIP)

following up, in my case the problem was lack of memory.  I changed my resource to run
gem install --debug and saw the error about not being able to allocate memory.

I'm getting this. This is first time i'm trying to install mysql on ubuntu in vagrant environment using chef provisioner
Vagrant 1.8.5
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
Berks 4.3.5
depends 'apt', '~> 2.9'
depends 'firewall', '~> 2.4'
depends 'apache2', '~> 3.2.2'
depends 'mysql', '~> 8.0'
depends 'mysql2_chef_gem', '~> 1.0'
depends 'database', '~> 5.1'
"gcc -o conftest -I/opt/chef/embedded/include/ruby-2.1.0/x86_64-linux -I/opt/chef/embedded/include/ruby-2.1.0/ruby/backward -I/opt/chef/embedded/include/ruby-2.1.0 -I. -I/usr/local/include -I/opt/chef/embedded/include -O2 -O3 -g -pipe -I/opt/chef/embedded/include   -I/opt/chef/embedded/include -O2 -O3 -g -pipe -fPIC conftest.c  -L. -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L/usr/local/lib -Wl,-R/usr/local/lib -L/opt/chef/embedded/lib -Wl,-R/opt/chef/embedded/lib -L. -Wl,-rpath,/opt/chef/embedded/lib -fstack-protector -L/opt/chef/embedded/lib -rdynamic -Wl,-export-dynamic -L/opt/chef/embedded/lib  -Wl,-R/opt/chef/embedded/lib     -lnsl -lz -lm  -Wl,-R -Wl,/opt/chef/embedded/lib -L/opt/chef/embedded/lib -lruby -lmysqlclient -lnsl -lz -lm  -lpthread -lrt -ldl -lcrypt -lm   -lc"
/usr/bin/ld: cannot find -lmysqlclient
collect2: error: ld returned 1 exit status
Any solution?

You're in the wrong cookbook @ashwinrayaprolu1984 ;)
Just came across this mysql, so you'll want to drop a +1 here:
https://github.com/chef-cookbooks/mysql/issues/457

I saw this just now . Thanks for reply i had fixed it in meantime though.


First Ever Community Zoom Call 🎉

It's time to organise a Zoom meeting with all the folks who've been contributing already and also inviting others who may be interested - for everyone to get to know each other and for any questions to be answered.
The inhouse postdoc team may prepare a little Demo for the purpose and then we'll have some Q&A and networking.
Aida to prepare the HackMD, and the logistics (date, invites, etc).
Following the initial community call, we will decide on the frequency and logstics of subsequent calls.
✨

[ ] To send a Doodle Poll for mid October. @AidaMehonic


Temp block windows to unblock 2.2.1/1.3.5 releases

Signed-off-by: Peter Zhu<EMAIL_ADDRESS>Description
Temp block windows to unblock 2.2.1/1.3.5 releases
Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/2306#issuecomment-1228720499
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #2516 (9327b65) into main (7eced56) will increase coverage by 5.73%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #2516      +/-   ##
=============================================
+ Coverage     94.26%   100.00%   +5.73%
=============================================
  Files           213         6     -207
  Lines          4357       105    -4252
  Branches         10        19       +9
=============================================
- Hits           4107       105    -4002
+ Misses          244         0     -244
+ Partials          6         0       -6

Impacted Files
Coverage Δ

...rkflow/integ_test/service_opensearch_dashboards.py

...workflow/integ_test/integ_test_suite_opensearch.py

src/ci_workflow/ci_check_list_source.py

tests/jenkins/jobs/UploadToS3_Jenkinsfile

src/run_assemble.py

src/ci_workflow/ci_check_gradle_dependencies.py

src/test_workflow/test_args_path_validator.py

src/assemble_workflow/bundle.py

src/test_workflow/test_result/test_result.py

src/manifests_workflow/component_opensearch.py

... and 209 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


added a property for setting the amount of the vertex shadow attenuat…

Fixes #10913
Added an option to Globe (Globe.vertexShadowDarkness) for changing the amount of the terrain vertex shadow darkness when lighting is enabled (Globe.enableLighting). Similarly to ShadowMap.darkness parameter, a value near 0 makes the shadows darker, increasing it makes the shadows brighter. The default value is 0.3 (that was hard coded in Cesium).
Having the ability to change the terrain vertex shadow darkness allows to create more realistic shadows for cases, like the Moon, where there is no atmosphere and the light contribution from other sources (sun or earth) can be very small.
Here is a sandcastle example with default terrain vertex shadow darkness (current behaviour, advance the time in timeline till the terrain is fully shadowed)
sandcastle

here is a sandcastle example with the new parameter for changing the terrain vertex shadow darkness
sandcastle

The parameter can be dynamically changed, as visible in this example
sandcastle

Thanks for the pull request @calogeromauceri!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

@ggetz, @sanjeetsuhag thanks for your feedback. I just pushed the changes you suggested. Please let me know if anything else is needed

@sanjeetsuhag I just pushed the changes you suggested. Please let me know if anything else is needed


MRG: Brainvision events_from_annotations

Closes #6267
Closes #6276

Can you quickly say what's different relative to #6276?

It simplifies the function and addresses some of the issues it had. But again this is the same as having a huge dict with the equivalences and return it.

@massich do you have more commits to push? If not, I can try and set it non-WIP
@jona-sassenhagen okay for you as requested by @cbrnr not to drop any of the events? I agree that just doing 2001, 2002, ... for all non-stim, non-resp BV markers in a sorted list would work. In my mind that's the one last unresolved issue. I can push a commit for this, too, if we agree it's useful (or @massich can, but it's post-work-hours in Europe now).

Yes ok with me.

@jona-sassenhagen @cbrnr @massich can you look and make sure that you're happy with the docstring describing the behavior of this? I've also modified tests that hopefully verify it works according to the description.

The docstring looks good! If everything works as advertised, +1 for merge!

Just pushed a commit to shorten the docstring, but the changes are minor

@larsoner ok, I just saw what you did. The only fuzzy thing is why we need lambda on the default?
here https://github.com/mne-tools/mne-python/pull/6326/files#diff-3552c91528439a66cb184c8d9b9cfcb5R873
is it 'cos we need something that returns None once called? I find it more tricky  to read but I like it.

Shall we backport this one to 0.17? Will we be releasing the last 0.17.X?

Usually after releasing a new version we stop backporting things, so no probably not. FYI here is the CircleCI rendering
https://13163-1301584-gh.circle-artifacts.com/0/dev/generated/mne.events_from_annotations.html

is it 'cos we need something that returns None once called? I find it more tricky to read but I like it.

Yes it's because we need the () at the end, it just saves us from a conditional branch (the conditional is implicit in the get)

There is a merge conflict now, feel free to rebase

LGTM, thanks @massich

Ok, now my issue with this is the following:
Iif I

read BV files
write the raw obj to disk as in fif format
read this raw obj from disk
extract events from annotations

it doesn't use the BV parser for my BV events, because the class of the read object is no longer RawBrainVision.
That is very counterintuitive I think.
Suggestions?
@massich @drammock

then I don't see how we can "just make it work" out of the box.
you must accept to pass a specific parameter to the events_from_annotation
function.

you can see if you can make the 'auto' mode smarter...

We could at least allow passing 'bv' or 'brainvision' instead of 'auto' to mean "use Brainvision mode". Then events_from_annotaions(raw) will not work but at least events_from_annotations(raw, 'brainvision') will.

That might be good, but to me the main issue is that it will confuse many people (who don't know how the background on our classes) that retrieving the events from essentially one and the same data object yields different results.

the main issue is that it will confuse many people (who don't know how the background on our classes) that retrieving the events from essentially one and the same data object yields different results.

True. If that consistency is more important than having it work with no arg for RawBrainvision classes, then we should get rid of 'auto' and have people always do 'brainvision'. So we have to choose if the consistency or convenience is more important here. To me the convenience (and backward compat / deprecation since this was in 0.18) makes it worth keeping 'auto'.
And just to come back to what @agramfort mentioned, I don't see a way to easily have it work once you've save-loaded, unless we encode somewhere what the original type was. Candidates I can think of:

raw.info['description'], append something
Not great because users could use this field.
raw.annotations, add some annotation of the original type
Not great because then we're adding things that events_to_annotations will treat as events by default, users doing raw.set_annotations will lose this information, etc.

I can't immediately think of any other ways.

One very effortful way would be to have RawFIF objects created by saving a RawBrainVision object to also still belong to RawBrainvision ...
I'm really not sure what's the best solution here.
I think checking if all annotations conform to BV standards should work fairly well, and then a warning could recommend to use "bv" as the parser.
Generally, I think if all your events look like "Stimulus/S 1", "Stimulus/S20", then you probably want them mapped to 1, 20, ...

I think checking if all annotations conform to BV standards should work fairly well...
Generally, I think if all your events look like "Stimulus/S 1", "Stimulus/S20", then you probably want them mapped to 1, 20, ...

If a user adds a single annotation on their own, or simply concatenates two RawBrainvision instances (which adds BAD_boundary annots) then what they get will change. This is inconsistent just in a different way (that involves common user usage patterns).

and then a warning could recommend to use "bv" as the parser

This part seems reasonable. I'd propose:

Keep current 'auto' behavior class-based.
Add 'brainvision' as a mode.
If the mode is 'auto' and the input class RawFIF or RawArray and we find any markers that are BV-like, warn that they might want to use event_id='brainvision' instead of event_id='auto' (or use mode=None to avoid the warning)

If a user adds a single annotation on their own, or simply concatenates two RawBrainvision instances (which adds BAD_boundary annots) then what they get will change. This is inconsistent just in a different way (that involves common user usage patterns).

I don't understand what you mean. Still the sensible way would be to link "Stimulus/S 20" to 20, etc.
What you specifically suggested makes sense to me.
Not volunteering :)

I don't understand what you mean. Still the sensible way would be to link "Stimulus/S 20" to 20, etc.

You said "checking if all" above -- I took this to mean a conditional "all" like if all(bv_like(annot) for annot in annotations). "check if all" is too fragile for the reasons I mention above, you add a single annot on your own or just concat and the "check if all" will fail.
Did you mean "check if any"? This might also be okay, given that the BV events are pretty specifically formatted. The docstring (and behavior) would be updated to be something like:
        - **'auto' (default)**: prefer a raw-format-specific parser:
          - Brainvision: map ...

to

        - **'auto' (default)**: prefer a specific parser:
          - If any annotations are Brainvision-like (e.g., "Stimulus/S 20"): map...
          - Otherwise: Behaves like None.

The only way I can think of that this will break is if someone adds on their own a BV-like annotation to their raw instance. But because the BV built-in annotations are pretty specifically formatted, I think this is probably an okay risk.

Ah right. Well, I originally thought you could have something like, if more than 3 and more than 90% of events are matched by the BV parser ...
But "check if any" might be preferable, as otherwise in non-auto mode nothing is guaranteed either right?
Or stick to warnings to be on the safe side.

I slightly prefer the "any" route.
One other tricky part is if there is some BV user who adds their own (non-BV-like) annotations and does save-load round-trip and expects these to turn into events, 1) they will be surprised and 2) their code will not work the same way as in 0.18. But this is again a presumably pretty rare corner case.

I don't know, I would not expect a FIF file to be parsed like a BV file, even if we're just talking about events. I'd prefer events_from_annotations(raw, 'brainvision') to get back the desired events.

I don't know, I would not expect a FIF file to be parsed like a BV file, even if we're just talking about events.

I agree for FIF files from the Neuromag scanner, but not for BV files that we have read in write to FIF format (mostly) just because it's the only output format we support. The problematic case that @jona-sassenhagen brings up seems to show the problem, basically:
raw = read_raw_brainvision(...)
raw.save(fname)
raw_read = read_raw_fif(fname)
events_from_annotations(raw_read) != events_from_annotations(raw)

This behavior is not so good.
In my mind the question is how big is the risk that someone using a non-BV file will add a BV-like event? Given the specificity of the event naming I think it's pretty low and we should just go to a any-BV-like parsing method.

+1 for the approach of looking at the annotations, and printing a warning if any of them look like a BV-style annotation and mode != 'bv'
candidate for backport?

Yeah we'll want to backport. Sounds like people prefer to stick with the class-based check / my original 3-step proposal above.
@massich can you look?

smarter "auto" and/or "brainvision" explicit param, either are fine with me.
Basically the parsing of the brainvision annotations is doing some black
magic
that only MNE does AFAIK. We pay a price for too magic but sometimes you
just want things to work...

@larsoner yes I think your approach is fine, but why do you need two parameters mode and event_id? Currently, mne.events_from_annotations only has an event_id parameter, which should suffice to implement what you suggest. Let's not add a new mode parameter if we don't really need it.

sleeping over it. For the event_id='auto' as fif files don't have naturally
annotions we can then trigger
the check for brainvision style annotations (ie only do it for a RawFIF
instance)

let me rephrase based on @larsoner snippet:
raw = read_raw_brainvision(...)
raw.save(fname)
raw_read = read_raw_fif(fname)
events_from_annotations(raw_read, event_id='auto') != events_from_annotations(raw, event_id='auto')

and now we are proposing this:

def events_from_annotations(raw, event_id="auto",
                            regexp=r'^(?![Bb][Aa][Dd]|[Ee][Dd][Gg][Ee]).*$',
                            use_rounding=True, chunk_duration=None,
                            verbose=None):
...
    event_id = _check_event_id(event_id, raw)
...

def _check_event_id(event_id, raw):
    from mne.io.brainvision import _BVEventParser as bv_default
    from mne.io.brainvision import _check_raw_fif_from_original_bv as black_magic

    if event_id is None:
        return _DefaultEventParser()
    elif event_id == 'brainvision':
        return bv_default()
    elif event_id == 'auto':
        candidate = getattr(raw, '_get_auto_event_id', _DefaultEventParser)()

        if black_magic(raw) and candidate != bv_default:
            warn("you might want to try `event_id='brainvision'`)

        return candidate
    elif callable(event_id) or isinstance(event_id, dict):
        return event_id
    else:
        raise ValueError('Invalid input event_id')

So that this would happen:
raw = read_raw_brainvision(...)
events_when_raw_was_bv = events_from_annotations(raw)
raw.save(fname)
raw_read = read_raw_fif(fname)
events_from_annotations(raw_read, event_id='auto') != events_when_raw_was_bv
# you get a warining

events_from_annotations(raw_read, event_id='brainvision') == events_when_raw_was_bv

My opinion is that 'auto' is a bad idea. I think that events_from_annotations
requires event_id as much as requires raw. We cannot get away with
events_from_annotations(raw.annotations) because we need raw.sfreq. In the same
manner we cannot assign ids if we don't know them. I've never seen a problem with
a code like this:
from mne.io.brainvision import event_ids as bv_events
raw = read_raw_fif(fname_of_an_old_bv)
events, _ = events_from_annotations(raw, event_id=bv_events)

If you want to get brainvision events (or any other type) you need to pass a proper
event_id that translate to those. I don't see this as a complicate and obscure coding
pattern for newcomers (We have much worst).
Educating the users that you need event_id or you get  _DefaultEventParser which gives
you consecutive numeric ids for each description is not the end of the world. Otherwise,
we update _DefaultEventParser to behave like mne.io.brainvision.bv_events as it was
in 0.16 and _DefaultEventParser would start giving you ids starting at (3000).
I could see people arguing that using strings is better (maybe, I'm not sure. I like the idea of having to import the translator. I find it more explicit):
raw = read_raw_fif(fname_of_an_old_bv)
events, _ = events_from_annotations(raw, event_id='brainvision')

But I fear that if we start introspecting and guessing which was the original format
we are opening a can of worms.
At this point I would just make 'auto' behave like None and deprecate it (because we released in 0.18).
And if we want 'brainvision' and 'bla' to be shorthands to avoid the imports thats fine with me.

But I fear that if we start introspecting and guessing which was the original format we are opening a can of worms.

In prickle yes, but in practice BV stimulus events are extremely regular and specific, and everyone who uses events like "Stimulus/S100" will want it to be parsed to 100.

I've never seen a problem with a code like this:

Again, in principle yes, but right now a lot of people are working with mne.find_events still, some are making the transition right now, others might mostly use other formats than BV and so on.
It seems to me like the point of annotations is to make working with non-int events easier, but here we have something that the experimenter has programmed into their software as an int, is stored by BV as an int plus some predictable boiler plate, and is then universally parsed as an int. But we somehow make it hard to use? It's literally 8-bit integer codes!
To be frank, this should have been handled back when annotations were conceived ... I should have been more involved there, to represent BV. Now we will end up with a less than optimal solution either way.

At this point I would just make 'auto' behave like None and deprecate it (because we released in 0.18).

Ok, maybe? If we add big warning messages for every usage of events_from_annotations on RawBrainvision objs for a cycle or three, and tell every BV user to always use event_id='brain vision' in all BV-derived code.

def _check_event_id(event_id, raw):
    from mne.io.brainvision import _BVEventParser as bv_default

    if event_id is None:
        return getattr(raw, '_get_auto_event_id', _DefaultEventParser)()
    elif event_id == 'auto':
        warn("`event_id='auto'` is deprecated. Use  `event_id=None` instead",
              DeprecationWarning)
        return getattr(raw, '_get_auto_event_id', _DefaultEventParser)()
    elif event_id == 'brainvision':
        return bv_default()
    elif callable(event_id) or isinstance(event_id, dict):
        return event_id
    else:
        raise ValueError('Invalid input event_id')

elif event_id == 'auto':

-1 on this. I am with @jona-sassenhagen that this mode is useful for BV users and we can potentially extend it to others (e.g., CTF once it's done).
The proposal that @agramfort seems to support now is actually not the one above (about warning) but rather a modified version of the second proposal, which I think would be:

instance of RawBrainvision, use BV parser
instance of RawFIF with any BV-like event, use BV parser
(also probably want: instance of RawArray with any BV-like event, use BV parser)

I'm fine with this. It does not seem too fragile or risky, and simplifies things for BV users.
This can also be how we treat other readers. For example for the CTF annotations we are adding, if they end up having standard names -- instance of RawFIF/RawArray with CTF-like annotations, or RawCTF: use CTF event parsing. So it's a sustainable approach, too. (And in extreme corner cases where CTF and BV-like events are found, which should be pretty much never, we can raise an error or warn or something.)

To be frank, this should have been handled back when annotations were conceived ... I should have been more involved there, to represent BV. Now we will end up with a less than optimal solution either way.

It's not a problem of the annotation changes. Before 0.15 events_from_annotations was not general, had 'brainvision' logic embedded in it (which was not even complete. because if you had 'Foo/F100' and 'Bar/B100' both were mapped to 100). The only thing we did was make it explicit. You need to pass a dict, callable or anything that makes the events at your liking. What its true is that we changed the default from a half-implemented 'brainvision' specification to something that was giving incremental numbers. If we want to make the 'brainvision' specification the default just because this is the main use case for 99.99% of our users we can argue that. But again, the events_id would not be the same as in 0.15 because now we have a more complete implementation of the specification.
Despite having the opinion that:

'brainvision' is only 1 of our 15 readers and thats why it should not be the default. The default should be something really simple and let every reader expose something to translate.
I will stay out of the pull. I'll be +0 in making 'barinvision' the default of events_from_annotations.

@larsoner 	what are you -1 ? to the warning? we could keep both approaches:
def _check_event_id(event_id, raw):
    from mne.io.brainvision import _BVEventParser as bv_default

    if event_id is None or event_id='auto':
        return getattr(raw, '_get_auto_event_id', _DefaultEventParser)()
    elif event_id == 'brainvision':
        return bv_default()
    elif callable(event_id) or isinstance(event_id, dict):
        return event_id
    else:
        raise ValueError('Invalid input event_id')

This discussion shows that the underlying problem is really that we now have two things to represent discrete events - see #6018. Whatever we do here, it will never be perfect, because we decided to represent discrete events stored in files as annotations. Annotations contain everything you need, including string descriptions. I know that superficially it is easier to work with a NumPy array, but you could do everything with annotations. We'd only need to add support for annotations everywhere we currently accept events.

what are you -1 ? to the warning?

I am -1 to deprecating 'auto'. I am +1 to what @agramfort came around to, which is the proposal to check BV class, then check if RawFIF or RawArray with bv-like events. It seems cleanest to me.

We'd only need to add support for annotations everywhere we currently accept events.

Yes in this case the "only" includes critically mne.Epochs, and really we'd just end up with the same problem there (how to auto-create event_id to extract BV events). But let's keep discussion of this stuff contained to #6018 so we do not get derailed here.

Yes in this case the "only" includes critically mne.Epochs, and really we'd just end up with the same problem there (how to auto-create event_id to extract BV events). But let's keep discussion of this stuff contained to #6018 so we do not get derailed here.

Yes, let's discuss in #6018 - but in the case of Epochs and annotations, why would you need event IDs when the user would specify the string descriptions that should be used for epoch creation?

Yes, let's discuss in #6018 - but in the case of Epochs and annotations, why would you need event IDs when the user would specify the string descriptions that should be used for epoch creation?

raw = read_raw_brainvision(...)
raw.save(fname)
raw_read = read_raw_fif(fname)

events, event_id = events_from_annotations(raw)
# or any other of those:
#
# events, event_id = events_from_annotations(raw, event_id='auto')
# events, event_id = events_from_annotations(raw, event_id='brainvision')
# event_id = mne.io.brainvision.bla
# events, _ = events_from_annotations(raw, event_id=event_id)

epoch = Epochs(raw, events=events, event_id=event_id)

The thing is that until now Epochs require events and event_id to make the link.
Because all this events_from_annotations that takes and returns event_id is to call
Epochs.
I agree with @cbrnr that if this was possible, then there would be no discussion
raw = read_raw_brainvision(...)
raw.save(fname)
raw_read = read_raw_fif(fname)
my_descriptors = ['foo', 'bar']
epoch = Epochs(raw, my_descriptors)

The other thing that nobody mentioned is the elephant in the room: Why everything has to be fif. If I could save brainvision files I would have no trouble.
raw = read_raw_brainvision('name.vhdr')
raw.save('bla.vhdr')
raw2 = read_raw_brainvision('bla.vhdr')

and then suport read_raw:
raw = read_raw('name.vhdr')
raw.save('bla.vhdr')
raw2 = read_raw('bla.vhdr')

To me an image is an image, regardless of the format that once it was stored.

what I propose has minimal consequences on project API and makes it work
for Jona....

@agramfort there's a small PR comming with those changes. To discuss in concrete terms.

I’d think alex’ second proposal should work.
A BV writer I don’t like. .fif isn’t perfect, but a lot of work has gone into making it a standard. And you’ll save your epochs and Ica Objs as fif too.
More generally, instead of writing a raw BV using MNE, you could just stick to using the original raw file ...

Great thanks @massich

I agree with @cbrnr that if this was possible, then there would be no discussion

raw = read_raw_brainvision(...)
raw.save(fname)
raw_read = read_raw_fif(fname)
my_descriptors = ['foo', 'bar']
epoch = Epochs(raw, my_descriptors)

And why shouldn't this be possible? We could check whether the second argument is an nd-array and treat it as events or a string/list of strings and get the onsets from raw.annotations. Doesn't look too difficult, but maybe I'm missing something (because I've never really used Epochs).
Re the elephant, I agree that FIFF is not a universal format. Few tools outside of MNE can even read FIFF, so if I really want to store some data I go for something else, e.g. the BIDS-EEG supported formats EDF or BrainVision, or even EEGLAB, which is just a MAT file many tools can read. (For the sake of reproducibility, it's always best to only use the raw data, but I know that there are situations where you want to store some intermediate results to disk.)
Currently, MNE can't export any of these three formats for different reasons, so I've started to implement that in MNELAB. Currently, I can export to EEGLAB and EDF/BDF, and I will add BrainVision export based on the implementation by @palday soon. We could discuss if any of these formats might be suitable for direct integration into MNE.
Re read_raw, this discussion comes up regularly, e.g. #1930. I'd also be +1 for having a generic reader function, but it seems to be quite a lot of effort.

And why shouldn't this be possible? We could check whether the second argument is an nd-array and treat it as events or a string/list of strings and get the onsets from raw.annotations. Doesn't look too difficult, but maybe I'm missing something (because I've never really used Epochs).

that could work but a number of functions that take epochs as input will
use the epochs.events attribute. We need to be careful that certain epochs
will not work for certain functions. I am afraid of a rabbit hole here.

that could work but a number of functions that take epochs as input will
use the epochs.events attribute. We need to be careful that certain epochs
will not work for certain functions. I am afraid of a rabbit hole here.

But we could start with adding this feature while not touching the old behavior at all (i.e. leaving the events-based interface as default).

I'm in favor of all those things. But we need a discussion and a roadmap.

events_from_annotations is one more line of code and keeps the magic
level one step lower
but I am open to discussion to see what we can cook up

Re the elephant, I agree that FIFF is not a universal format. Few tools outside of MNE can even read FIFF, so if I really want to store some data I go for something else, e.g. the BIDS-EEG supported formats EDF or BrainVision, or even EEGLAB, which is just a MAT file many tools can read. (For the sake of reproducibility, it's always best to only use the raw data, but I know that there are situations where you want to store some intermediate results to disk.)

This has actually been a hug pain for me in the past too. None if my non-MNE-using colleagues can read those FIFF files, let alone know which software could potentially be used to open them.


[API] updateFeed documentation

Moving a feed to a different category via the updateFeed API endpoint does not seem to work for me.
This is how I try to move the feed "BlenderNation" with the id 3 to the category "Podcasts" with the id 2(so it definitely exists):
{"category":{"id":2},"title":"BlenderNationNewTitle"}

Updating the title works as expected. But the category stays the same. This is what is returned and is also reflected in the web UI:
Feed { id: 3, user_id: 1, title: "BlenderNationNewTitle", site_url: "https://www.blendernation.com", feed_url: "http://feeds.feedburner.com/Blendernation", rewrite_rules: "", scraper_rules: "", crawler: false, checked_at: "2020-04-26T00:24:04.500012+02:00", etag_header: "LA4mSPn737aKl/jlts0TcSMK59Y", last_modified_header: "Sat, 25 Apr 2020 22:07:54 GMT", parsing_error_count: 0, parsing_error_message: "", category: Category { id: 9, user_id: 1, title: "CG" }, icon: Some(FeedIcon { feed_id: 3, icon_id: 3 }) }

edit: running the official docker image version 2.0.21
edit2: okay, figured it out by reading the code.
The documentation is wrong or out of date. The docs state that the input for updating a feed should look like:
{
    "title": "New Feed Title",
    "category": {
        "id": 22
    }
}

When in reality the code looks like this
type feedModification struct {
	FeedURL      *string `json:"feed_url"`
	SiteURL      *string `json:"site_url"`
	Title        *string `json:"title"`
	ScraperRules *string `json:"scraper_rules"`
	RewriteRules *string `json:"rewrite_rules"`
	Crawler      *bool   `json:"crawler"`
	UserAgent    *string `json:"user_agent"`
	Username     *string `json:"username"`
	Password     *string `json:"password"`
	CategoryID   *int64  `json:"category_id"`
	Disabled     *bool   `json:"disabled"`
}

Thanks for reporting this. I updated the example in the docs.


Hyperparameters to reproduce the GCN performance on LBA

I'd like to know what batch size and the number of epochs were used to produce the result of GCN on LBA in the paper. In train_pdbbind.py, the batch size is set to 1 and the number of epochs is 100. However, the test RMSE I got using this setting more than ten times higher than the one reported in the paper.

Thanks for letting us know! Have you checked whether the units match?

Yes, I believe the units match. Would you please share the hyperparameters(batch size, number of epochs) used to produce the results in the paper?

Hi, please see the code in the examples folder (https://github.com/drorlab/atom3d/tree/master/examples/lba/gnn) for a reproducible training example using the LMDB format.


Incompatibility with express 5

Hi everyone,
this is just to leave a note to everyone who's looking for this info. At the current state this module is not compatible with express 5, because they changed the req.query object in a getter, so this library is not able to add page and limit to it.
Cheers.

PR welcome to fix

Hello @niftylettuce,
I would love to contribute here. Following is what I am thinking.
As req.query will be a getter from express 5 onwards, we will not be able to set anything in it. I will use req.paginate when we need to set page and limit after validation and sanitisation.
Please let me know if this approach seems good. I wanted to discuss first, before implementation as this might be a breaking change. Anyways, the package itself will become incompatible after express 5 release, so a breaking change might be the only way out. Please let me know your opinion.
Thanks,
Kedar Chandrayan

Hello @niftylettuce,
Please let me know if I can raise a PR using the above approach.
Thanks,
Kedar Chandrayan


[DEV-1672] Stay fast when excluded folders have cycles

Backstory
<EMAIL_ADDRESS>introduced an import cycle, https://github.com/axios/axios/issues/4463. Even though the cycle detector is configured not to ignore cycles in the node_modules, the presence of cycles makes the plugin slower.
It gets slower because the plugin has two steps. In the first step, it quickly checks whether any cycles are present, which takes a few milliseconds. In the second step, the plugin makes a much bigger effort to figure out the cycle's path, which takes a few seconds. The second step won't run unless the first step found anything. However, the first step might find cycles that the second step won't report.
Changes
This patch changes the way the cycle detecting plugin works. Right now, the plugin might quickly find a cycle and then spend a long time figuring its path only to reject it because we told the plugin to ignore cycles in that code area. With this patch applied, the plugin won't even look for cycles in the code areas we told it not to look at.
Testing
Without this patch, checking a project with<EMAIL_ADDRESS>installed would take 7s. With this patch applied, checking only takes 90ms as long as our code doesn't have any import cycles. However, if a cycle is introduced in our code, the processing time spikes back to 7s and the plugin reports the cycle as it should.

Silly me, a wrong repo.


Remove version: SMPlayer.SMPlayer version 21.1.0

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

Close with reason: Package still available.;


Runner classes

Instead of running pipelines explicitly, pipelines should be run when requesting a dataset/field. For this to happen, the Study object needs to have its own "Runner" object to determine how and where the processing pipelines are run (e.g. locally single/multi process or submitted to SLURM scheduler)

This has been implemented


Make it easier to build offline sites

How can we make it easier to generate offline sites?
Background: https://github.com/sourcethemes/academic-admin/issues/14#issuecomment-605617261
Possible solutions:

Add a package.json for building offline sites to the Kickstart repo

Could utilize Learna for conditional dependencies?

Have an additional repo just for offline assets. It could be packaged as a Hugo module so then users could simply install the Hugo module to install assets locally

Both these approaches may require a few tweaks in Academic's code to check for presence of these individual files as opposed to the current offline approach of requiring offline assets to be concatenated into a single CSS and JS files.
Documentation

Add a page to the docs dedicated to building offline sites: https://sourcethemes.com/academic/docs/offline-site/

i was thinking for this also for offline development
and the easier way could be a config flag, that chooses if to link to all external resources, or if to use a local offline version.
obvioulsy these local files have to be updated manually from time to time
for example these

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/academicons/1.8.6/css/academicons.min.css"
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.6.0/css/all.css"
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/fancybox/3.2.5/jquery.fancybox.min.css"
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.6/styles/github.min.css"
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.6/styles/dracula.min.css"
<link rel="stylesheet" href="//fonts.googleapis.com/css?family=Montserrat:400,700|Roboto:400,400italic,700|Roboto+Mono">

+1 for the font awesome... I ran into this today...
Is there anyway for a dev to locally store a google font? For instance if a dev has chosen to use a google font (or one provided via the google font API) then is there a way to cache that locally for an off line site?

I created a minor solution for a similar problem on kubernetes.io: https://github.com/kubernetes/website/pull/15257/commits
Essentially you can do stuff like:
{{/* Setting external resource based on whether hugo is running locally or public */}}
{{ if .Site.IsServer }}
#STUFF TO DO IF OFFLINE
{{ else }}
#STUFF TO DO IF ONLINE
{{ end }}

# Alternately you can do
{{ if not .Site.IsServer }}
#STUFF
{{ end }}

It's a good idea from a privacy perspective to always load content, including font stacks, from the same origin. Doing so eliminates the chance of an unreliable third-party causing SPOF (Single Point Of Failure) during page load as happens frequently with Google, Adobe, Cloudflare and others in China, SEA and likely the middle east and for all sorts of reasons one might not expect.
Offline publishing increases privacy both for publishers as well as end users in addition to providing a better user experience and improved auditability for better site security.

@ghost said, too many project are US Centric, such as S3, which is the backend of Github is based in US, often during COVID I had to use a VPN to being directly connected in US to be able to download and clone project which relay on github and S3. (I'm based in Bangkok which is SEA) without this VPN I always had timeout and/or downloading a 3 bites second.
Also by using "offline site" version of my site, I speed up by 200% the rendering and now this one could be cached entirely by CloudFlare which means my website is now available in 200 cities.
such as the update_academic.sh script, I think it could be easy to make a script to parse and download all these resources, of course I'm not a Windows user.

@gcushen at https://sourcethemes.com/academic/docs/offline-site/ it could be interesting to define what means

Add Font Awesome font assets to static/

since to make it work I had to copy webfonts in static/css/ instead of static
because with https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.11.2/css/all.min.css point to
../webfonts and not ../../webfonts

Closing due to little demand and the discussion going stale with no contributions.

Has this issue anything to do with this?


[canvaskit] font features stop working after Noto fallbacks are loaded

Font features stop working after Noto fallbacks are loaded.
Steps to Reproduce

In the engine repo open lib/web_ui/test/canvaskit/canvas_golden_test.dart and remove all skiaFontCollection.debugResetFallbackFonts() in the file.
Run felt test test/canvaskit/canvas_golden_test.dart.
Observe that the test failed the screenshot tests.

For example, the "old style figures" test should take the following screenshot:

Instead, if fails with:

This is because a previous test loads CJK Noto fonts. Commenting out the CJK tests causes the font features to start working again.

We're drowning in flutter triage bot traffic. Resetting the triage bot timer.