[apparmor] [patch] fix libapparmor ruby bindings for ruby 2.0
john.johansen at canonical.com
Thu Jun 13 00:06:26 UTC 2013
On 06/12/2013 03:25 PM, Christian Boltz wrote:
> Am Mittwoch, 12. Juni 2013 schrieb John Johansen:
>> On 06/05/2013 01:23 PM, Christian Boltz wrote:
>>> you might have noticed the discussion about the libapparmor ruby
>>> bindings build failures on openSUSE Factory, which is the first
>>> version with ruby 2.0.
>>> The problem was that DESTDIR was added to too many variables, which
>>> finally resulted in
>> NAK, at least until I understand what is going on better. Specifically
>> from the referenced bug we have
>> The error message is:
>> *** No rule to make target
>> ude/ruby-2.0.0/ruby.h', needed by `LibAppArmor_wrap.o'. Stop.
>> The bug is that it searches for ruby.h _inside the buildroot_, which
>> is obviously wrong.
> [end of quoting from the bugreport, and sorry for the linebreaks -
> KMail doesn't handle quoting of logs very well ;-) ]
> To make things clear: ruby.h is part of the ruby-devel package.
> Also note that the quoted error message is from the openSUSE build
> service, which means a fresh virtual machine for each build job.
> (No chroot etc. involved.)
>> But when building packages searching the build root is the correct
>> place to search as you may be building against a different version
>> than your system has installed.
> Well, we have up to 3 places:
> 1) the running system
> 2) a chroot that is used for building (with only the packages needed for
> build installed)
> 3) DESTDIR as target for "make install" - in other words: everything
> that will end up in the RPM/DEB package
> 1) is needed for obvious reasons ;-)
> 2) is optional, and not too different from 1) - from the compiler's POV,
> a chroot looks like the running system. The only difference is that with
> a chroot you can be quite sure not to break your system ;-) and you can
> control the list of installed packages easier.
> Instead of a chroot (as used by the openSUSE "build" script), you can
> also setup a virtual machine for each build (as done by the openSUSE
> build service)
> 3) is highly recommended because otherwise you could easily break your
> system with make install, and you would never know exactly if you found
> all files you need to package.
>> Some googling around using
>> extconf.rb header file ruby.h
>> I find that this error happens usually because of missing the ruby-dev
> I have a BuildRequires: ruby-devel of course ;-)
>> My guess is we need to add a dependency on a missing ruby-dev or
>> similar package so that we can pull the ruby.h into the build root.
> It looks like you confuse the build root (2) with DESTDIR (3).
> ruby-devel installs ruby.h in the build root (which can be 1) or 2) -
> but the (with Ruby 2.0) generated Makefile.rb searches for it inside
> 3) DESTDIR, which is just wrong. (Remember: DESTDIR contains what will
> end up in the RPM/DEB package.)
> The patch fixes this problem, but as I already said, I'm not sure if
> it's the best way to fix it. I'm not even sure if it's a bug in our
> extconf.rb, in swig or if mkmf from Ruby 2.0 is buggy ;-)
its not the extconf.rb, it could be swig but it doesn't look like it to
me. It does look like mkmf is generating a bad Makefile.
it shouldn't be used oldincludedir and you are right ruby.h in DESTDIR
I'd like to have a day or two more to poke at why its using oldincludedir
More information about the AppArmor