I bumped a number of pieces of the v8 stack yesterday and this morning, including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0, and rebuilding ruby193-v8. Despite all the builds completing and the fact that I'm able to precompile the assets using the SCL and /usr/bin/ruby193-rake on a clean machine, asset precompilation is not working properly when run in mock. therubyracer is installer properly and the shared objects are accessible; the gem shows up in gem list. It seems like bundler_ext isn't properly activating the gem so the JS runtime doesn't get detected, but I'm not a bundler_ext expert so I'm not sure of host it's supposed to behave.
Here [1] is a an example of such a failure - let me know if you've got any clues
I thought win engines you did not want to pre-compile the assets?
– bk
···
On 10/24/2013 09:18 PM, Sam Kottler wrote:
> lzap, et al,
>
> I bumped a number of pieces of the v8 stack yesterday and this morning, including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0, and rebuilding ruby193-v8. Despite all the builds completing and the fact that I'm able to precompile the assets using the SCL and /usr/bin/ruby193-rake on a clean machine, asset precompilation is not working properly when run in mock. therubyracer is installer properly and the shared objects are accessible; the gem shows up in `gem list`. It seems like bundler_ext isn't properly activating the gem so the JS runtime doesn't get detected, but I'm not a bundler_ext expert so I'm not sure of host it's supposed to behave.
>
> Here [1] is a an example of such a failure - let me know if you've got any clues :-)
>
> Thanks!
>
> -Sam
>
> 1. http://koji.katello.org/koji/getfile?taskID=63529&name=build.log
>
All it really does is "require 'rubygemname'" for each one.
I am off for the rest of the day, more on Monday.
LZ
···
On Thu, Oct 24, 2013 at 09:18:35PM -0400, Sam Kottler wrote:
> lzap, et al,
>
> I bumped a number of pieces of the v8 stack yesterday and this morning, including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0, and rebuilding ruby193-v8. Despite all the builds completing and the fact that I'm able to precompile the assets using the SCL and /usr/bin/ruby193-rake on a clean machine, asset precompilation is not working properly when run in mock. therubyracer is installer properly and the shared objects are accessible; the gem shows up in `gem list`. It seems like bundler_ext isn't properly activating the gem so the JS runtime doesn't get detected, but I'm not a bundler_ext expert so I'm not sure of host it's supposed to behave.
>
> Here [1] is a an example of such a failure - let me know if you've got any clues :-)
>
> Thanks!
>
> -Sam
>
> 1. http://koji.katello.org/koji/getfile?taskID=63529&name=build.log
So after some time spent yesterday I think I found the bug. I am
currently working on patch for rubyracer that fixes the issue.
TL;DR - rubyracer requires libv8 which is some kind of weird rubygem
that wraps google v8 engine. It is meant for easy deployment with
Bundler, but in Fedora this is against policies. The patch removes this
dependency from gemspec, so Bundler/Bundler_ext no longer thinks it
should be there. In Fedora/RHEL we already have official libv8 (system)
library (and we also build rubyracer against it).
One line patch, two days of work for me (and week for Sam…)
LZ
···
On Thu, Oct 24, 2013 at 09:18:35PM -0400, Sam Kottler wrote:
> lzap, et al,
>
> I bumped a number of pieces of the v8 stack yesterday and this morning, including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0, and rebuilding ruby193-v8. Despite all the builds completing and the fact that I'm able to precompile the assets using the SCL and /usr/bin/ruby193-rake on a clean machine, asset precompilation is not working properly when run in mock. therubyracer is installer properly and the shared objects are accessible; the gem shows up in `gem list`. It seems like bundler_ext isn't properly activating the gem so the JS runtime doesn't get detected, but I'm not a bundler_ext expert so I'm not sure of host it's supposed to behave.
>
> Here [1] is a an example of such a failure - let me know if you've got any clues :-)
>
> Thanks!
>
> -Sam
>
> 1. http://koji.katello.org/koji/getfile?taskID=63529&name=build.log
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> From: "Bryan Kearney" <bryan.kearney@gmail.com>
> To: foreman-dev@googlegroups.com
> Sent: Friday, October 25, 2013 7:54:11 AM
> Subject: Re: [foreman-dev] bundler_ext, therubyracer, and the asset pipeline during package builds
>
> > lzap, et al,
> >
> > I bumped a number of pieces of the v8 stack yesterday and this morning,
> > including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0,
> > and rebuilding ruby193-v8. Despite all the builds completing and the fact
> > that I'm able to precompile the assets using the SCL and
> > /usr/bin/ruby193-rake on a clean machine, asset precompilation is not
> > working properly when run in mock. therubyracer is installer properly and
> > the shared objects are accessible; the gem shows up in gem list. It
> > seems like bundler_ext isn't properly activating the gem so the JS runtime
> > doesn't get detected, but I'm not a bundler_ext expert so I'm not sure of
> > host it's supposed to behave.
> >
> > Here [1] is a an example of such a failure - let me know if you've got any
> > clues
> >
> > Thanks!
> >
> > -Sam
> >
> > 1. http://koji.katello.org/koji/getfile?taskID=63529&name=build.log
> >
> I thought win engines you did not want to pre-compile the assets?
The error is happening with foreman core, not an engine.
···
----- Original Message -----
> On 10/24/2013 09:18 PM, Sam Kottler wrote:
> From: "Lukas Zapletal" <lzap@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Friday, October 25, 2013 8:24:15 AM
> Subject: [foreman-dev] Re: bundler_ext, therubyracer, and the asset pipeline during package builds
>
> I screwed up my snap-guest setup today, was fixing that and only had
> time to reproduce what you have:
>
> - fails in koji
> - does not build on my RHEL6 box
> (No Package found for rubygem(ancestry) >= 2.0.0)
You either didn't build the package with --define "scl ruby193" or your mock configuration isn't setup properly.
···
----- Original Message -----
One hint - the whole bundler_ext code is only this file:
All it really does is “require ‘rubygemname’” for each one.
I am off for the rest of the day, more on Monday.
LZ
On Thu, Oct 24, 2013 at 09:18:35PM -0400, Sam Kottler wrote:
lzap, et al,
I bumped a number of pieces of the v8 stack yesterday and this morning,
including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0,
and rebuilding ruby193-v8. Despite all the builds completing and the fact
that I’m able to precompile the assets using the SCL and
/usr/bin/ruby193-rake on a clean machine, asset precompilation is not
working properly when run in mock. therubyracer is installer properly and
the shared objects are accessible; the gem shows up in gem list. It
seems like bundler_ext isn’t properly activating the gem so the JS runtime
doesn’t get detected, but I’m not a bundler_ext expert so I’m not sure of
host it’s supposed to behave.
Here [1] is a an example of such a failure - let me know if you’ve got any
clues
I noticed that therubyracer is not able to load libv8 library for some
reason. Unfortunately Ruby only throws Could not find libv8 error and
does not specify the reason.
Apparently it is trying to load it, because we have not changed any
paths in the libv8 library (you only ripped off d8 binary and the gem
does not seem to be using that). Because when I try to downgrade libv8,
I get ABI error which is properly reported.
So it is weird, some kind of loading error between libv8 and rubyracer
which is not properly reported and we cannot do much about it, except
trial and error.
When I was googling around, it looks like people and companies (Heroku)
are no longer recommending therubyracer gem and recommend other
wrappers, e.g. nodejs. Since nodejs package is in EPEL, maybe we can try
to replace it.
I did some preliminary testing by removing therubyracer and v8 and
installing nodejs package from EPEL and foreman RPM builds well on
RHEL6. I assume the same for Fedoras.
Nodejs package also use v8 engine, but it's a command line application
and execjs framework integrates via IPC. Since we only use this during
build time, this is not an issue.
Historically, we only had issues with therubyracer and v8 integration in
Katello AFAIK. I am all for wiping that out of the table.
Ok, I spent another time with this, my initial thought that it is able
to build therubyracer against system library is - wrong. I mean, it can
be done, but it would need another set of patches for therubyracer.
So the current plan is simple - we need to introduce new gem libv8 which
therubyracer author created beginning this year. Sam already made some
builds, but the builds are missing --with-system-v8 option for rubygems.
With this option, gem is created in a way it loads system v8 library.
Currently it was trying to load vendored v8 library which was missing
from the gem (no directory vendor/v8/out - compare to the one generated
with pure rubygems or Bundler).
So it turns out what I expected - it's no bundler_ext issue. It's just a
packaging issue, complicated though. The new libv8 gem's loading is a
bit weird, but I am building it right now and I hope it will finally
work when it is installed with --with-system-v8 option.
LZ
···
On Fri, Nov 01, 2013 at 08:48:05AM +0100, Lukas Zapletal wrote:
> So after some time spent yesterday I think I found the bug. I am
> currently working on patch for rubyracer that fixes the issue.
>
> TL;DR - rubyracer requires libv8 which is some kind of weird rubygem
> that wraps google v8 engine. It is meant for easy deployment with
> Bundler, but in Fedora this is against policies. The patch removes this
> dependency from gemspec, so Bundler/Bundler_ext no longer thinks it
> should be there. In Fedora/RHEL we already have official libv8 (system)
> library (and we also build rubyracer against it).
>
> One line patch, two days of work for me (and week for Sam...)
>
> LZ
>
> On Thu, Oct 24, 2013 at 09:18:35PM -0400, Sam Kottler wrote:
> > lzap, et al,
> >
> > I bumped a number of pieces of the v8 stack yesterday and this morning, including adding rubygem-libv8, upgrading rubygem-therubyracer to 0.12.0, and rebuilding ruby193-v8. Despite all the builds completing and the fact that I'm able to precompile the assets using the SCL and /usr/bin/ruby193-rake on a clean machine, asset precompilation is not working properly when run in mock. therubyracer is installer properly and the shared objects are accessible; the gem shows up in `gem list`. It seems like bundler_ext isn't properly activating the gem so the JS runtime doesn't get detected, but I'm not a bundler_ext expert so I'm not sure of host it's supposed to behave.
> >
> > Here [1] is a an example of such a failure - let me know if you've got any clues :-)
> >
> > Thanks!
> >
> > -Sam
> >
> > 1. http://koji.katello.org/koji/getfile?taskID=63529&name=build.log
> >
> > --
> > You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> Later,
>
> Lukas "lzap" Zapletal
> irc: lzap #theforeman
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
There are no nodejs packages in the Debian/Ubuntu repos for any of the Deb
OSs we support. Are you offering to do the backport?
Greg
···
On 31 October 2013 08:46, Lukas Zapletal wrote:
When I was googling around, it looks like people and companies (Heroku)
are no longer recommending therubyracer gem and recommend other
wrappers, e.g. nodejs. Since nodejs package is in EPEL, maybe we can try
to replace it.
> From: "Greg Sutcliffe" <greg.sutcliffe@gmail.com>
> To: "Foreman ." <foreman-dev@googlegroups.com>
> Sent: Thursday, October 31, 2013 6:32:26 AM
> Subject: Re: [foreman-dev] Re: bundler_ext, therubyracer, and the asset pipeline during package builds
>
>
> > When I was googling around, it looks like people and companies (Heroku)
> > are no longer recommending therubyracer gem and recommend other
> > wrappers, e.g. nodejs. Since nodejs package is in EPEL, maybe we can try
> > to replace it.
> >
>
> There are no nodejs packages in the Debian/Ubuntu repos for any of the Deb
> OSs we support. Are you offering to do the backport?
It's in wheezy-backports so we can either tell people to get it from there or pull it from backports and put it on deb.theforeman.org. If it works well with wheezy I assume it should build fine on precise, but that's a prediction based solely in hand-waving.
-S
···
----- Original Message -----
> On 31 October 2013 08:46, Lukas Zapletal wrote:
