Re: using guix for ruby development

2018-02-16 Thread Marius Bakke 
Divan Santana  writes:

> Divan Santana  writes:
>
>> Hi all,
>>
>> So I'm *trying* to use guix on Parabola Linux to provide the rubies and
>> replace some other functionality of like chruby for instance.
>>
>> I'm a bit of a noob with guix and even ruby, so it's a bit of a
>> challenge.
>>
>> I've read through these nice notes[1] by Pjotr. The answers I'm looking
>> for, may well be in there but I might have missed it.
>>
>>   [1]:
>> - https://gitlab.com/pjotrp/guix-notes/blob/master/RUBY.org
>> - https://gitlab.com/pjotrp/guix-notes/blob/master/RUBYGEMS-Nokogiri.org
>>
>> I've also used the linked in script[2] which helps.
>>
>> [2]: https://gitlab.com/pjotrp/guix-notes/blob/master/scripts/ruby-guix-env
>>
>> Anyway the issue:
>>
>>   $ gem env
>>   RubyGems Environment:
>> - RUBYGEMS VERSION: 2.6.14
>> - RUBY VERSION: 2.4.3 (2017-12-14 patchlevel 205) [x86_64-linux]
>> - INSTALLATION DIRECTORY: 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0
>> - USER INSTALLATION DIRECTORY: /home/admin/.gem/ruby/2.4.0
>> - RUBY EXECUTABLE: 
>> /gnu/store/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/bin/ruby
>> - EXECUTABLE DIRECTORY: 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/bin
>> - SPEC CACHE DIRECTORY: 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/specs
>> - SYSTEM CONFIGURATION DIRECTORY: 
>> /gnu/store/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/etc
>> - RUBYGEMS PLATFORMS:
>>   - ruby
>>   - x86_64-linux
>> - GEM PATHS:
>>- /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0
>>- /home/admin/.guix-profile/lib/ruby/vendor_ruby
>>- /home/admin/.guix-profile/lib/ruby/gems/2.4.0/
>> - GEM CONFIGURATION:
>>- :update_sources => true
>>- :verbose => true
>>- :backtrace => false
>>- :bulk_threshold => 1000
>>- "gem" => "--no-rdoc"
>> - REMOTE SOURCES:
>>- https://rubygems.org/
>> - SHELL PATH:
>>- 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/bin
>>- /home/admin/src/ds-config/guile/scripts
>>- /home/admin/src/ds-config/bin
>>- /home/admin/.node_modules/node_modules/.bin
>>- /home/admin/.guix-profile/bin
>>- /home/admin/src/ds-config/guile/scripts
>>- /home/admin/src/ds-config/bin
>>- /home/admin/.node_modules/node_modules/.bin
>>- /home/admin/.guix-profile/bin
>>- /usr/local/sbin
>>- /usr/local/bin
>>- /usr/bin
>>- /usr/lib/jvm/default/bin
>>- /usr/bin/site_perl
>>- /usr/bin/vendor_perl
>>- /usr/bin/core_perl
>>
>> So I'm in a ruby project. I type `bundle install` to install the gems.
>>
>> It goes and fetches the missing gems and installs them in 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/
>>
>> That's great. I fire up the project[3] with:
>>
>>   [3]: https://gitlab.com/gitlab-com/gitlab-docs (using an older commit
>>   because ruby25 is not yet in guix repos.
>>
>>   $ bundle exec nanoc live
>>
>>   Captain! We’ve been hit!
>>
>>   LoadError: liblzma.so.5: cannot open shared object file: No such file or 
>> directory - 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/nokogiri-1.7.2/lib/nokogiri/nokogiri.so
>>
>>   $ ldd 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/nokogiri-1.7.2/lib/nokogiri/nokogiri.so
>>   linux-vdso.so.1 (0x76b1)
>>   libm.so.6 => /usr/lib/libm.so.6 (0x7f469080f000)
>>   libdl.so.2 => /usr/lib/libdl.so.2 (0x7f469060b000)
>>   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x7f46903e5000)
>>   libz.so.1 => /usr/lib/libz.so.1 (0x7f46901ce000)
>>   libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f468ffb)
>>   libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x7f468fd78000)
>>   libc.so.6 => /usr/lib/libc.so.6 (0x7f468f9c1000)
>>   /usr/lib64/ld-linux-x86-64.so.2 (0x7f4690f97000)
>>
>> Guessing the reason is because it seems to compile against the OS system
>> and not the "guix system". And that could cause problems?
>>
>> Other gems also are like this.
>>
>>   $ ldd 
>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/ffi-1.9.18/lib/ffi_c.so
>>   linux-vdso.so.1 (0x7ffd1bdf1000)
>>   libffi.so.6 => /usr/lib/libffi.so.6 (0x7f6af531e000)
>>   libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7f6af510)
>>   libdl.so.2 => /usr/lib/libdl.so.2 (0x7f6af4efc000)
>>   libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x7f6af4cc4000)
>>   libm.so.6 => /usr/lib/libm.so.6 (0x7f6af4978000)
>>   libc.so.6 => /usr/lib/libc.so.6 (0x7f6af45c1000)
>>   /usr/lib64/ld-linux-x86-64.so.2 (0x7f6af574c000)
>>

Re: How best to set host key in vm

2018-02-16 Thread Ludovic Courtès 
Hi George,

George myglc2 Clemmer  skribis:

> On 02/15/2018 at 14:51 Ludovic Courtès writes:

[...]

>> Perhaps ‘guix system vm-image’ could include a ‘--copy’ option that
>> would copy a file from the host into the image.  We’d have to be careful
>> with the implementation to make sure that it doesn’t end up in the host
>> store nor in the guest store.
>
> How about a '--copy-image=' option that copies the image out
> of the store? Then the ‘--copy’ could operate on  and fail
> if it isn't specified.

Yeah, perhaps we’d have to do something like that.

Ludo’.