Bundler is unable to solve deps for fresh checkout

Hey,

when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and
2.4.1), bundle install is not able to resolve dependencies and loops
forever. I am using latest stable bundler, tried also pre1 version.

Can someone confirm and provide a workaround? I think copying
Gemfile.lock from someone else should do it. Can someone attach a
pastebin me one? I currently have my workstation down (CPU in RMA) and
got clean setup.

If this is confirmed, it is quite an issue for newcomers. The second
command new developer is asked to execute fails hard. Any suggestions?

LZ

··· -- Later, Lukas @lzap Zapletal

What errors are you seeing. I've tried with ruby 2.2.2, and 2.3.1
bundler 1.15.4, everything worked fine.
What gem --version do you have?

Anything in bundler.d/Gemfile.local.rb that could be causing this?

– Ivan

··· On Thu, Sep 14, 2017 at 3:13 PM, Lukas Zapletal wrote: > Hey, > > when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and > 2.4.1), bundle install is not able to resolve dependencies and loops > forever. I am using latest stable bundler, tried also pre1 version. > > Can someone confirm and provide a workaround? I think copying > Gemfile.lock from someone else should do it. Can someone attach a > pastebin me one? I currently have my workstation down (CPU in RMA) and > got clean setup. > > If this is confirmed, it is quite an issue for newcomers. The second > command new developer is asked to execute fails hard. Any suggestions? > > LZ > > -- > Later, > Lukas @lzap Zapletal > > -- > 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/d/optout.

http://ci.theforeman.org/view/Release%20pipeline/job/release_tarballs

seems to have suffered from this today (Monday 1.15.4 tarballs were built
just fine)

Did you find any other way to fix this? Switching to 2.4 could be an
option, probably
putting a Gemfile.lock on every tagged release isn't a bad idea either.

··· On Thursday, September 14, 2017 at 3:13:29 PM UTC+2, Lukas Zapletal wrote: > > Hey, > > when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and > 2.4.1), bundle install is not able to resolve dependencies and loops > forever. I am using latest stable bundler, tried also pre1 version. > > Can someone confirm and provide a workaround? I think copying > Gemfile.lock from someone else should do it. Can someone attach a > pastebin me one? I currently have my workstation down (CPU in RMA) and > got clean setup. > > If this is confirmed, it is quite an issue for newcomers. The second > command new developer is asked to execute fails hard. Any suggestions? > > LZ > > -- > Later, > Lukas @lzap Zapletal >

The easiest way to get the recent Gemfile.lock is to look at the build
artifacts in jenkins jobs
(also useful when investigating sudden test failures):

http://ci.theforeman.org/job/test_develop/database=postgresql,ruby=2.4,slave=fast/

– Ivan

··· On Thu, Sep 14, 2017 at 3:34 PM, Ivan Necas wrote: > What errors are you seeing. I've tried with ruby 2.2.2, and 2.3.1 > bundler 1.15.4, everything worked fine. > What gem --version do you have? > > Anything in `bundler.d/Gemfile.local.rb` that could be causing this? > > -- Ivan > > On Thu, Sep 14, 2017 at 3:13 PM, Lukas Zapletal wrote: >> Hey, >> >> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and >> 2.4.1), bundle install is not able to resolve dependencies and loops >> forever. I am using latest stable bundler, tried also pre1 version. >> >> Can someone confirm and provide a workaround? I think copying >> Gemfile.lock from someone else should do it. Can someone attach a >> pastebin me one? I currently have my workstation down (CPU in RMA) and >> got clean setup. >> >> If this is confirmed, it is quite an issue for newcomers. The second >> command new developer is asked to execute fails hard. Any suggestions? >> >> LZ >> >> -- >> Later, >> Lukas @lzap Zapletal >> >> -- >> 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/d/optout.

I just upgraded, but I think putting Gemfile.lock (even an older one
from 1.14 stable branch) could work. Weird really.

··· On Wed, Sep 20, 2017 at 6:57 PM, Daniel Lobato wrote: > http://ci.theforeman.org/view/Release%20pipeline/job/release_tarballs > > seems to have suffered from this today (Monday 1.15.4 tarballs were built > just fine) > > Did you find any other way to fix this? Switching to 2.4 could be an option, > probably > putting a Gemfile.lock on every tagged release isn't a bad idea either. > > On Thursday, September 14, 2017 at 3:13:29 PM UTC+2, Lukas Zapletal wrote: >> >> Hey, >> >> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and >> 2.4.1), bundle install is not able to resolve dependencies and loops >> forever. I am using latest stable bundler, tried also pre1 version. >> >> Can someone confirm and provide a workaround? I think copying >> Gemfile.lock from someone else should do it. Can someone attach a >> pastebin me one? I currently have my workstation down (CPU in RMA) and >> got clean setup. >> >> If this is confirmed, it is quite an issue for newcomers. The second >> command new developer is asked to execute fails hard. Any suggestions? >> >> LZ >> >> -- >> Later, >> Lukas @lzap Zapletal > > > -- > 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/d/optout.


Later,
Lukas @lzap Zapletal

Currently at bundler-1.15.4. Tried both with 2.0.0 from RHEL7 and
latest stable Ruby.

[root@nuc foreman]# gem --version
2.0.14.1
[root@nuc foreman]# ruby --version
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

[root@nuc bubbles]# gem --version
2.6.13
[root@nuc bubbles]# ruby --version
ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]

This is Intel NUC with 8 GB RAM, bundler runs for about a minute
before it takes whole memory and start swapping. Then I leave it for
another 5 minutes before bringing it down.

··· On Thu, Sep 14, 2017 at 3:36 PM, Ivan Necas wrote: > The easiest way to get the recent Gemfile.lock is to look at the build > artifacts in jenkins jobs > (also useful when investigating sudden test failures): > > http://ci.theforeman.org/job/test_develop/database=postgresql,ruby=2.4,slave=fast/ > > -- Ivan > > On Thu, Sep 14, 2017 at 3:34 PM, Ivan Necas wrote: >> What errors are you seeing. I've tried with ruby 2.2.2, and 2.3.1 >> bundler 1.15.4, everything worked fine. >> What gem --version do you have? >> >> Anything in `bundler.d/Gemfile.local.rb` that could be causing this? >> >> -- Ivan >> >> On Thu, Sep 14, 2017 at 3:13 PM, Lukas Zapletal wrote: >>> Hey, >>> >>> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and >>> 2.4.1), bundle install is not able to resolve dependencies and loops >>> forever. I am using latest stable bundler, tried also pre1 version. >>> >>> Can someone confirm and provide a workaround? I think copying >>> Gemfile.lock from someone else should do it. Can someone attach a >>> pastebin me one? I currently have my workstation down (CPU in RMA) and >>> got clean setup. >>> >>> If this is confirmed, it is quite an issue for newcomers. The second >>> command new developer is asked to execute fails hard. Any suggestions? >>> >>> LZ >>> >>> -- >>> Later, >>> Lukas @lzap Zapletal >>> >>> -- >>> 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/d/optout. > > -- > 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/d/optout.


Later,
Lukas @lzap Zapletal

Eventually I changed the release_tarballs to Ruby 2.4 and it went
through.

··· On 09/21, Lukas Zapletal wrote: > I just upgraded, but I think putting Gemfile.lock (even an older one > from 1.14 stable branch) could work. Weird really. > > On Wed, Sep 20, 2017 at 6:57 PM, Daniel Lobato wrote: > > http://ci.theforeman.org/view/Release%20pipeline/job/release_tarballs > > > > seems to have suffered from this today (Monday 1.15.4 tarballs were built > > just fine) > > > > Did you find any other way to fix this? Switching to 2.4 could be an option, > > probably > > putting a Gemfile.lock on every tagged release isn't a bad idea either. > > > > On Thursday, September 14, 2017 at 3:13:29 PM UTC+2, Lukas Zapletal wrote: > >> > >> Hey, > >> > >> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and > >> 2.4.1), bundle install is not able to resolve dependencies and loops > >> forever. I am using latest stable bundler, tried also pre1 version. > >> > >> Can someone confirm and provide a workaround? I think copying > >> Gemfile.lock from someone else should do it. Can someone attach a > >> pastebin me one? I currently have my workstation down (CPU in RMA) and > >> got clean setup. > >> > >> If this is confirmed, it is quite an issue for newcomers. The second > >> command new developer is asked to execute fails hard. Any suggestions? > >> > >> LZ > >> > >> -- > >> Later, > >> Lukas @lzap Zapletal > > > > > > -- > > 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/d/optout. > > > > -- > Later, > Lukas @lzap Zapletal > > -- > 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/d/optout.


Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

I had all these same issues in a 16.04 Ubuntu LTS (on AWS) with Ruby 2.1
and 6.

There were a few hurdles after the upgrade/downgrade to 2.4 also.

I still have a JavaScript issue, as the pull downs don't render, so I am
rerunning tests.

I have modified Foreman to listen on all ports.

I have my history file from my install if you want to contact me directly.

··· On Thursday, September 21, 2017 at 12:41:00 AM UTC-7, Lukas Zapletal wrote: > > I just upgraded, but I think putting Gemfile.lock (even an older one > from 1.14 stable branch) could work. Weird really. > > On Wed, Sep 20, 2017 at 6:57 PM, Daniel Lobato > wrote: > > http://ci.theforeman.org/view/Release%20pipeline/job/release_tarballs > > > > seems to have suffered from this today (Monday 1.15.4 tarballs were > built > > just fine) > > > > Did you find any other way to fix this? Switching to 2.4 could be an > option, > > probably > > putting a Gemfile.lock on every tagged release isn't a bad idea either. > > > > On Thursday, September 14, 2017 at 3:13:29 PM UTC+2, Lukas Zapletal > wrote: > >> > >> Hey, > >> > >> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and > >> 2.4.1), bundle install is not able to resolve dependencies and loops > >> forever. I am using latest stable bundler, tried also pre1 version. > >> > >> Can someone confirm and provide a workaround? I think copying > >> Gemfile.lock from someone else should do it. Can someone attach a > >> pastebin me one? I currently have my workstation down (CPU in RMA) and > >> got clean setup. > >> > >> If this is confirmed, it is quite an issue for newcomers. The second > >> command new developer is asked to execute fails hard. Any suggestions? > >> > >> LZ > >> > >> -- > >> Later, > >> Lukas @lzap Zapletal > > > > > > -- > > 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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Later, > Lukas @lzap Zapletal >

Tried with rhel7 VM, same gem and ruby version as yours (2.0.0p648),
dependencies resolved just fine.
Failed later on installation of some gem (as it requires ruby 2.1+),
but the memory kept under 300MB
for all the time.

– Ivan

··· On Fri, Sep 15, 2017 at 9:08 AM, Lukas Zapletal wrote: > Currently at bundler-1.15.4. Tried both with 2.0.0 from RHEL7 and > latest stable Ruby. > > [root@nuc foreman]# gem --version > 2.0.14.1 > [root@nuc foreman]# ruby --version > ruby 2.0.0p648 (2015-12-16) [x86_64-linux] > > [root@nuc bubbles]# gem --version > 2.6.13 > [root@nuc bubbles]# ruby --version > ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux] > > This is Intel NUC with 8 GB RAM, bundler runs for about a minute > before it takes whole memory and start swapping. Then I leave it for > another 5 minutes before bringing it down. > > > On Thu, Sep 14, 2017 at 3:36 PM, Ivan Necas wrote: >> The easiest way to get the recent Gemfile.lock is to look at the build >> artifacts in jenkins jobs >> (also useful when investigating sudden test failures): >> >> http://ci.theforeman.org/job/test_develop/database=postgresql,ruby=2.4,slave=fast/ >> >> -- Ivan >> >> On Thu, Sep 14, 2017 at 3:34 PM, Ivan Necas wrote: >>> What errors are you seeing. I've tried with ruby 2.2.2, and 2.3.1 >>> bundler 1.15.4, everything worked fine. >>> What gem --version do you have? >>> >>> Anything in `bundler.d/Gemfile.local.rb` that could be causing this? >>> >>> -- Ivan >>> >>> On Thu, Sep 14, 2017 at 3:13 PM, Lukas Zapletal wrote: >>>> Hey, >>>> >>>> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and >>>> 2.4.1), bundle install is not able to resolve dependencies and loops >>>> forever. I am using latest stable bundler, tried also pre1 version. >>>> >>>> Can someone confirm and provide a workaround? I think copying >>>> Gemfile.lock from someone else should do it. Can someone attach a >>>> pastebin me one? I currently have my workstation down (CPU in RMA) and >>>> got clean setup. >>>> >>>> If this is confirmed, it is quite an issue for newcomers. The second >>>> command new developer is asked to execute fails hard. Any suggestions? >>>> >>>> LZ >>>> >>>> -- >>>> Later, >>>> Lukas @lzap Zapletal >>>> >>>> -- >>>> 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/d/optout. >> >> -- >> 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/d/optout. > > > > -- > Later, > Lukas @lzap Zapletal > > -- > 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/d/optout.

Weird, I think the problem was that I was using CenOS 7.0 or 7.1
without any updates applied.

Anyway I tried again with rbenv Ruby 2.4 and this time it worked, I
had to be setting the version incorrectly.

Thanks for help.

··· On Fri, Sep 15, 2017 at 12:20 PM, Ivan Necas wrote: > Tried with rhel7 VM, same gem and ruby version as yours (2.0.0p648), > dependencies resolved just fine. > Failed later on installation of some gem (as it requires ruby 2.1+), > but the memory kept under 300MB > for all the time. > > -- Ivan > > On Fri, Sep 15, 2017 at 9:08 AM, Lukas Zapletal wrote: >> Currently at bundler-1.15.4. Tried both with 2.0.0 from RHEL7 and >> latest stable Ruby. >> >> [root@nuc foreman]# gem --version >> 2.0.14.1 >> [root@nuc foreman]# ruby --version >> ruby 2.0.0p648 (2015-12-16) [x86_64-linux] >> >> [root@nuc bubbles]# gem --version >> 2.6.13 >> [root@nuc bubbles]# ruby --version >> ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux] >> >> This is Intel NUC with 8 GB RAM, bundler runs for about a minute >> before it takes whole memory and start swapping. Then I leave it for >> another 5 minutes before bringing it down. >> >> >> On Thu, Sep 14, 2017 at 3:36 PM, Ivan Necas wrote: >>> The easiest way to get the recent Gemfile.lock is to look at the build >>> artifacts in jenkins jobs >>> (also useful when investigating sudden test failures): >>> >>> http://ci.theforeman.org/job/test_develop/database=postgresql,ruby=2.4,slave=fast/ >>> >>> -- Ivan >>> >>> On Thu, Sep 14, 2017 at 3:34 PM, Ivan Necas wrote: >>>> What errors are you seeing. I've tried with ruby 2.2.2, and 2.3.1 >>>> bundler 1.15.4, everything worked fine. >>>> What gem --version do you have? >>>> >>>> Anything in `bundler.d/Gemfile.local.rb` that could be causing this? >>>> >>>> -- Ivan >>>> >>>> On Thu, Sep 14, 2017 at 3:13 PM, Lukas Zapletal wrote: >>>>> Hey, >>>>> >>>>> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and >>>>> 2.4.1), bundle install is not able to resolve dependencies and loops >>>>> forever. I am using latest stable bundler, tried also pre1 version. >>>>> >>>>> Can someone confirm and provide a workaround? I think copying >>>>> Gemfile.lock from someone else should do it. Can someone attach a >>>>> pastebin me one? I currently have my workstation down (CPU in RMA) and >>>>> got clean setup. >>>>> >>>>> If this is confirmed, it is quite an issue for newcomers. The second >>>>> command new developer is asked to execute fails hard. Any suggestions? >>>>> >>>>> LZ >>>>> >>>>> -- >>>>> Later, >>>>> Lukas @lzap Zapletal >>>>> >>>>> -- >>>>> 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/d/optout. >>> >>> -- >>> 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/d/optout. >> >> >> >> -- >> Later, >> Lukas @lzap Zapletal >> >> -- >> 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/d/optout. > > -- > 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/d/optout.


Later,
Lukas @lzap Zapletal