Looking at the error message, I don't think this has anything to do
with supermin.

The error is:

/build/buildd/libguestfs-1.24.3/debian/build-ruby1.8/../../ruby/ext/guestfs/_guestfs.c:444:10: error: variable 'optargs_s' has initializer but incomplete type
   struct guestfs_internal_test_argv optargs_s = { .bitmask = 0 };
          ^
/build/buildd/libguestfs-1.24.3/debian/build-ruby1.8/../../ruby/ext/guestfs/_guestfs.c:444:10: error: unknown field 'bitmask' specified in initializer

I don't quite understand this error at the moment.  Does
src/guestfs.h declare 'struct guestfs_internal_test_argv'
and does this struct have a bitmask field?

Yes, you could be right about supermin.

The struct you mention does exist and it does have a bitmask:

struct guestfs_internal_test_argv {
  uint64_t bitmask;
# define GUESTFS_INTERNAL_TEST_OBOOL_BITMASK (UINT64_C(1)<<0)
  int obool;
# define GUESTFS_INTERNAL_TEST_OINT_BITMASK (UINT64_C(1)<<1)
  int oint;
# define GUESTFS_INTERNAL_TEST_OINT64_BITMASK (UINT64_C(1)<<2)
  int64_t oint64;
# define GUESTFS_INTERNAL_TEST_OSTRING_BITMASK (UINT64_C(1)<<3)
  const char *ostring;
# define GUESTFS_INTERNAL_TEST_OSTRINGLIST_BITMASK (UINT64_C(1)<<4)
  char *const *ostringlist;
};

The struct is inside this macro, which could cause problems if it isn't set correctly:

#if GUESTFS_PRIVATE
/* Symbols protected by GUESTFS_PRIVATE are NOT part of the public,                                                                                                                                         
 * stable API, and can change at any time!  We export them because                                                                                                                                          
 * they are used by some of the language bindings.                                                                                                                                                          
 */

I think this is an actual build bug.  Not quite sure why I haven't
seen it before, since I do build regularly on Ubuntu but there we go.

What is supposed to happen is that -DGUESTFS_PRIVATE=1 is passed
through when compiling the ruby bindings.  This happens because

ruby/ext/guestfs/extconf.rb.in
  generates (by ./configure):
ruby/ext/guestfs/extconf.rb
  which creates
ruby/ext/guestfs/Makefile
  containing CFLAGS = ... -DGUESTFS_PRIVATE=1

Something along that chain isn't working on Ubuntu 13.10 and/or with
newer Ruby.

I'm trying to reproduce this on my Ubuntu 13.10 server.

Can I ask:

 - Are you running this on plain Ubuntu 13.10 (or did you update packages
   from upcoming Ubuntu betas, and if so which ones?)

 - What version of Ruby, rake, etc packages do you have installed?

The Debian build rebuilds libguestfs a number of times for every
version of ruby and python.

I will also note that the failure happens while building the
ruby1.8 version of libguestfs.

IIRC there is a way to change the versions of ruby/python that
libguestfs is built for in debian/control.  You might try changing
that so that it doesn't build against versions that you don't
care about.

It looks like I accidentally pulled in a bunch of packages from the current Ubuntu beta (14.04 Trusty), including Ruby. Here the installed versions:

ruby1.8                                         1.8.7.358-8ubuntu3              
ruby1.8-dev                                     1.8.7.358-8ubuntu3              
ruby1.9.1                                       1.9.3.484-1ubuntu2              
ruby1.9.1-dev                                   1.9.3.484-1ubuntu2              
rake                                            10.0.4-1   

Are there other packages you want to know about?

I don't care about the Ruby bindings myself, but I want to get the package officially backported, so it may be important that multiple versions work.

I'd suggest disabling the Ruby 1.8 bindings (see debian/control).
I don't think anyone cares about such an old version of Ruby and
it has been out of support upstream for > 6 months.

The alternative is to dig into why it's actually failing
(see comment 4).

You could also try asking Hilko Bengen who is the *Debian* packager.

Created attachment 851887 [details]
An attempt to disable build of ruby 1.8 bindings in debian control file

With the patch above, I get the following failure:

make[1]: Entering directory `/home/vagrant/libguestfs/libguestfs-saucy'
mkdir -p debian/tmp/usr/lib/guestfs/supermin.d
install -m755 debian/build-default/appliance/make.sh \
		debian/tmp/usr/lib/guestfs
install -m644 debian/build-default/appliance/*list \
		debian/tmp/usr/lib/guestfs
install -m644 \
		debian/build-default/appliance/supermin.d/*.img* \
		debian/tmp/usr/lib/guestfs/supermin.d/
erlang-depends -perlang-guestfs
dh_install -X.la -X.so.owner -Xbindtests -X/usr/lib/go/ \
		--fail-missing
dh_install: ruby-guestfs missing files (usr/lib/*-*/ruby), aborting
make[1]: *** [override_dh_install] Error 2
make[1]: Leaving directory `/home/vagrant/libguestfs/libguestfs-saucy'
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

Do any of the libguestfs tools depend on ruby bindings? I'm most interested in virt-builder and guestfish. If not, I'll probably switch to disabling the ruby build entirely and see if I can grab Hilko Bengen's attention while I focus on the rest of the build.

(In reply to Daniel Lipsitt from comment #12)
> Do any of the libguestfs tools depend on ruby bindings? I'm most interested
> in virt-builder and guestfish. If not, I'll probably switch to disabling the
> ruby build entirely and see if I can grab Hilko Bengen's attention while I
> focus on the rest of the build.

No, you can safely disable Ruby bindings completely.

The older tools in the tools/ directory depend on the Perl bindings.

virt-builder, virt-sysprep, virt-resize and virt-sparsify depend
on the OCaml bindings.

guestfish and all the other virt-* tools only need C.

To do that, use:

./configure --disable-ruby

Hilko points out Debian bug 735756, which appears to be the same error and is fixed in 1:1.24.4-1.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735756

I'm attempting to get it imported, but am running into some trouble (https://bugs.launchpad.net/udd/+bug/1270991). I'll keep you posted.

Still trying to build a plain backport (which defaults to building ruby bindings). Now I get this error:

dh_install -X.la -X.so.owner -Xbindtests -X/usr/lib/go/ \
		--fail-missing
dh_install: ruby-guestfs missing files (usr/lib/*-*/ruby), aborting
make[1]: *** [override_dh_install] Error 2
make[1]: Leaving directory `/build/buildd/libguestfs-1.24.4'
make: *** [binary] Error 2
dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary gave error exit status 2

It looks as if the files are getting installed in
/usr/lib/ruby/vendor_ruby/<rubyversion>/<arch>-linux

This path is chosen by evaluating:

$ruby -rrbconfig -e "puts RbConfig::CONFIG['vendorlibdir']"

$ruby -rrbconfig -e "puts RbConfig::CONFIG['vendorarchdir']"

where $ruby is the particular ruby binary, eg. ruby1.8.

Thus no file will match /usr/lib/ruby/*-*

Ubuntu Saucy is no more supported upstream at this point; libguestfs builds fine on Ubuntu Trusty (the second LTS currently), which has Ruby 1.9.x.

My bet the issue was to the mix of Saucy and Trusty packages (older Ruby 1.8 with newer rake, maybe?).

Anyway, the problem does not happen with newer versions of libguestfs and/or Ruby and/or Ubuntu, so closing.  If you can reproduce it again, please reopen with updated details.