On 06/12/2013 03:25 PM, Christian Boltz wrote: > Hello, > > 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 >> `/home/abuild/rpmbuild/BUILDROOT/apparmor-2.8.1-147.1.x86_64/usr/incl >> 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 >> packages > > I have a BuildRequires: ruby-devel of course ;-) > okay thanks
>> 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). > yes > 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.) > okay yes > > 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 is wrong I'd like to have a day or two more to poke at why its using oldincludedir -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
