[gentoo-user] Re: Rubygems and Rake problem

2021-01-27 Thread Hans de Graaff
On Wed, 27 Jan 2021 19:13:37 +0100, Bertram Scharpf wrote:

> after a long period with a lot of problems installing Ruby Gems and
> Gentoo packages containing Ruby Gems, I found the following solution: I
> added a line
> 
> s.executables = ["rake".freeze]
 
> What do you think? Maybe someone likes to confirm this.
> I will definitely not file any report or patch to neither the RubyGems
> nor the Rake project any more.

Could you file a but about this at https://bugs.gentoo.org/ including an 
example of the problem this is causing for you? As far as I'm aware this 
is not a known issue.

Hans




[gentoo-user] Re: dev-lang/ruby and dev-ruby/xmlrpc-0.3.0[ruby_targets_ruby25] error

2019-07-23 Thread Hans de Graaff
On Mon, 22 Jul 2019 05:12:55 -0500, Dale wrote:

> emerge: there are no ebuilds to satisfy
> ">=dev-ruby/xmlrpc-0.3.0[ruby_targets_ruby25]".
> (dependency required by "dev-lang/ruby-2.5.5::gentoo" [ebuild])

> Anyone have a clue on this?

An error on my part in preparing for a stable ruby:2.5. It was fixed 
yesterday: https://bugs.gentoo.org/690300

What happens is that RUBY_TARGETS would like to install ruby25 as well, 
but the corresponding ruby_targets_ruby25 USE flag is still masked in 
stable.

Hans




[gentoo-user] Re: Compiling ronn: Missing an already installed item

2017-10-01 Thread Hans de Graaff
On Sun, 01 Oct 2017 06:25:27 +0200, tuxic wrote:

 Compiling source in /var/tmp/portage/app-text/ronn-0.7.3-r3/work ...
>  * Running compile phase for all ...
> fatal: the 'hpricot' library is required (gem install hpricot)

The compile phase for all uses the currently eselected ruby. Perhaps you 
have a mismatch between your RUBY_TARGETS and the eselected version?

Hans




[gentoo-user] Re: Ruby - 3 versions - seriously????

2017-09-03 Thread Hans de Graaff
On Sat, 02 Sep 2017 22:57:12 +0200, Alan McKinnon wrote:

> OK, so disclaimer up front. I detest Ruby. I hate it with a passion.

Personally I find that passion is better reserved for positive things.

> You have to understand what Ruby is. It is not a language. It is 5
> languages. Like python27 and python3 are really different languages with
> much in common. The difference is the python devs have solid reasons for
> doing python3 and the transition has been mostly smooth. Each new minor
> version of ruby is a whole new language and the devs are OK with large
> breaking changes between minor version numbers.

I'm not sure this is fully fair to both ruby and python. Yes, there are 
incompatibilities between ruby versions, sometimes even large ones (1.8 
to 1.9 certainly had them), but recent versions haven't seen major 
changes and for the most part all ruby code in the gentoo repository 
works with all versions. To say that the python3 transition has been 
smooth probably doesn't do justice to the slow uptake.

> So why 3 rubys? Because they are 3 languages and you have packages that
> for whatever reason are tied to different rubys. Just pretend to
> yourself that they aren't really ruby22, ruby23 and ruby24 - they are
> php, perl and python (or whatever 3 language names you like that help
> you get past the 3 rubys! thing).

The situation with ruby really isn't different from python or perl at 
all. We also have multiple python versions in the tree just like with 
ruby. perl is not slotted but faces the same issues on each version (e.g. 
the "no . in INC path anymore" issue that made ruby 1.8 to 1.9 such a big 
deal).

> You probably need all 3. As housekeeping, you can put this in make.conf:
> RUBY_TARGETS="ruby22",
> and remove all ruby versions from world and let depclean, revdep-rebuild
> and emerge world take care of the details.

I find it very unlikely that you would *need* all three versions, unless 
you are doing ruby development and want to actively use all three. The 
RUBY_TARGETS="ruby22" advice matches the current default in the profile.

Until recently we had four different ruby versions, so we are already 
improving here. The end goal is to only have the two latest versions in 
the tree.

Hans




[gentoo-user] Re: Ruby - 3 versions - seriously????

2017-09-03 Thread Hans de Graaff
On Sat, 02 Sep 2017 21:33:31 +0800, Andrew Lowe wrote:

> Hi all,
>   I'm in the process of doing a world update and due to a failed 
compile,
> I have cause to look up through the list of stuff to compile/update.
> Imagine my surprise when I saw there were three versions of Ruby wanting
> to update:
> 
> [ebuild U  ] dev-lang/ruby-2.4.1-r4 [2.4.1-r3]
> [ebuild U  ] dev-lang/ruby-2.3.4-r4 [2.3.4-r3]
> [ebuild U  ] dev-lang/ruby-2.2.7-r4 [2.2.7-r3]

That is unusual unless you configured this yourself. Did you set 
RUBY_TARGETS in make.conf? Are you on stable or testing?

It would also be interesting to know what is pulling in these ruby 
versions.

>   I would prefer to get rid of Ruby, but, if memory serves me 
correctly,
> someone associated with the kernel decided it would be a good idea to
> use yet another language for something, obviously Python wasn't good
> enough

webkit-gtk and thin-provisioning-tools come to mind as pulling ruby for 
people that don't want it perse.

Hans




[gentoo-user] Re: ruby 22

2017-08-21 Thread Hans de Graaff
On Sun, 20 Aug 2017 08:26:49 -0600, Alec Ten Harmsel wrote:

> I don't believe that will be enough. You should update RUBY_TARGETS in
> /etc/portage/make.conf if you have it set. If you don't have it set and
> are still getting this error, that's a bug and should be filed on b.g.o.
> I have a custom RUBY_TARGETS as I do some ruby development, so I don't
> have a vanilla system to test this on.

I initially forgot to update the default RUBY_TARGETS specified in the 
profiles, so this may have caused some issues. That is fixed now.

> You shouldn't have to 'eselect ruby' either - portage will do this for
> you while updating.

The automatic eselect will only happen when ruby 2.1 is uninstalled. On a 
default system ruby 2.2 should already be installed for some time 
alongside with ruby 2.1. My recommendation is to switch explicitly to 
ruby 2.2 now (using eselect), and remove ruby 2.1 once all dependencies 
have been updated.

Hans




[gentoo-user] Re: Suggestion for freenode

2016-09-04 Thread Hans de Graaff
On Sat, 03 Sep 2016 21:41:51 -0700, Jigme Datse Yli-RAsku wrote:

> I like that.  Haven't got to even reaching the "dev in training" stage,
> but I'd like to have some place where I can ask general gentoo-dev
> questions.  I have a couple of projects which I'd like to get working
> with a simple "emerge".

#gentoo-dev-help is an existing channel specifically for getting help 
with writing ebuilds.

Hans




[gentoo-user] Re: incremental ZFS backups

2016-03-06 Thread Hans de Graaff
On Sat, 05 Mar 2016 01:23:08 +0100, lee wrote:

> I haven't found any documentation about how to deal with all the
> snapshots which would be created over time.  Can they be destroyed once
> the backup is finished?  A full backup took about 48 hours, so something
> faster is needed, and I don't want to end up with hundreds or thousands
> of snapshots by making new ones every day without being able to ever
> destroy them.

You might want to look at sys-fs/zfstools in my "graaff" overlay. It 
manages snapshots automatically. There are other similar tools as well.

> Basically, documentation says that such incremental backups are awesome
> because you get a 1:1 copy and only need to transfer what has changed
> after a previous backup as if you would use rsync, but that it's better
> than that and you can do it in like no time.  It doesn't really say how
> to actually do that and what to do with all the snapshots, though.

You can use "zfs send" and "zfs receive" for this. Once sent the snapshot 
can be deleted.

> I also can only guess that enabling compression on the target FS won't
> work unless compression is enabled at the source, though it would be
> rather useful to have the backups compressed while the source is not.
> You could do that with rsync, though, but I don't know how to access the
> snapshot for that.

zfs send and receive don't handle compression. You get and transmit the 
uncompressed data. So this works for any combination of compressions 
settings on the sending and receiving data sets.

Hans




[gentoo-user] Re: Ruby is infesting my machine

2015-07-03 Thread Hans de Graaff
On Fri, 03 Jul 2015 13:53:39 +0800, Andrew Lowe wrote:


   Does anyone know how I can prevent this infestation from 
happening?

It may not be possible since some packages require ruby to be present 
unconditionally, e.g. webkit-gtk has a built-time dependency on ruby, and 
the thin-provisioning-tools have a dependency on ruby with FEATURES=test. 
There are other packages with similar requirements.

Hans




[gentoo-user] Re: Software to keep track of stocks

2015-01-21 Thread Hans de Graaff
On Tue, 20 Jan 2015 18:20:18 -0700, Joseph wrote:

 I've tried to setup some stocks in GnuCash but it does not list TSX What
 alternatives are to keep track of stocks under Linux.

GnuCash uses Finance-Quote to get its stock quotes, and it looks like 
Finance-Quotes also includes a source for TSX stock. So it seems like 
things should work with GnuCash.

Hans




[gentoo-user] Re: etiquette for stabilization request

2014-11-02 Thread Hans de Graaff
On Sun, 02 Nov 2014 10:10:34 -0500, gottlieb wrote:

 I am running firefox-24.8.0, which is highest stable (highest testing is
 33.0).
 
 Several sites, in particular mail.google.com, report that This version
 of Firefox is no longer supported. Please upgrade to a supported
 browser.
 
 Does that warrant a stabilization request.  I have never filed one
 before and do not have a feeling of what is considered justification.  I
 should add that other than generating the above complaints, firefox is
 working fine (including with mail.google.com).

The stable request in this case is a bit hidden, and pending on mesa 
stabilization: https://bugs.gentoo.org/show_bug.cgi?id=525474

Hans




[gentoo-user] Re: Ansible, puppet and chef

2014-09-17 Thread Hans de Graaff
On Tue, 16 Sep 2014 22:43:18 +0200, Alan McKinnon wrote:

 Puppet seems to me a good product for a large site with 1000 hosts.
 Not so much for ~20 or so. Plus puppet's language and configs get large
 and hard to keep track of - lots and lots of directory trees with many
 things mentioning other things. (Nagios has the same problem if you
 start keeping host, services, groups and commands in many different
 files)

I'm using puppet for small installs ( 10 hosts) and am quite happy with 
it. It's wonderful to push some changes and have all these hosts 
configure themselves accordingly. Not to mention the joy of adding new 
hosts.

The configuration can get large, but then again, these are all things 
that you are already managing on the host. Better to do it all in one 
place, rather than on each individual host with all its associated 
inconsistencies.

Us being a ruby shop I never looked at ansible and I'm not even sure it 
existed when we choose puppet.

One thing you can do to make the deployment easier for smaller scale 
setups would be to use a masterless puppet. One less component to worry 
about. Just distribute the puppet repository and run puppet apply.

Hans




[gentoo-user] Re: Ruby is borked on my system

2014-06-27 Thread Hans de Graaff
On Thu, 26 Jun 2014 23:36:00 -0400, Ajai Khattri wrote:

 !!! All ebuilds that could satisfy
 virtual/rubygems[ruby_targets_ruby18]
 have been masked.

You still have packages on your system that have been installed with the 
ruby18 RUBY_TARGET. It's not immediately clear which package that is from 
the output, but I suspect dev-ruby/rubygems? Re-emerging the packages 
still installed for ruby18 should fix this.

Hans




[gentoo-user] Re: dev-ruby/json-1.8.0

2014-06-08 Thread Hans de Graaff
On Sat, 07 Jun 2014 17:20:22 -0700, walt wrote:

 On 06/07/2014 12:56 AM, Hans de Graaff wrote:

 For example, I (want to) use only ruby19:
 
 #grep RUBY /etc/portage/make.conf RUBY_TARGETS=ruby19

Yes, in hindsight I think that should have been the current default since 
ruby19 has the best overall coverage for packages. Once ruby20 has caught 
up I think we'll move to a default of RUBY_TARGETS=ruby20

 In spite of that, portage often insists on installing other versions of
 ruby, rdoc, rubygems, and you already know the others.

Partially this was because we tried to solve another issue when ruby20 
went stable. I removed those forced use flags for ruby20 last week, so 
this should no longer happen. We still need to come up with a good plan 
when the same issue will pop up for ruby21.

 AFAICT, the other versions of ruby are dragged in by old ruby packages
 that were installed before I started using RUBY_TARGETS (because I
 didn't yet know about RUBY_TARGETS),

Yes, these will still have other ruby targets recorded and thus also 
request them for their dependencies. emerge --newuse should be able to 
help here.

 I discovered all of this by grepping for ruby in /var/db/pkg but it took
 me a long time to get it sorted out, and I don't expect that a gentoo
 beginner could do it.  (OTOH maybe a gentoo beginner wouldn't care about
 installing multiple ruby versions :)

We try to keep the default settings so that someone who doesn't care or 
know about ruby should get a good experience. Moving from ruby18 to ruby19 
we did some things that could have been handled better (such as not 
mentioning that the new ruby must be eselected before making the switch), 
so hopefully we've learned from those when we do the next update.

Hans





[gentoo-user] Re: dev-ruby/json-1.8.0

2014-06-07 Thread Hans de Graaff
On Fri, 06 Jun 2014 15:47:38 -0700, walt wrote:

 Is all of the above familiar to you?  If not, you may need more help
 with managing multiple ruby versions.  I find it a large PITA and I
 could use more help myself :)

Could you explain what bothers you or where you would need help?

Hans




[gentoo-user] Re: rubygems-1.9.1 error

2014-03-25 Thread Hans de Graaff
On Mon, 24 Mar 2014 20:23:55 +, Mick wrote:

 I have been chasing my tail with ruby tonight.
 
 The masking of ruby18 meant that I had to unmerge a lot of ruby packages
 and then portage chose what to merge afresh. 

unmerge or depclean? unmerge is less safe and may leave your system in a 
bad state. emerge -N is a better way to handle this situation.

 
 /usr/lib64/ruby/1.9.1/rubygems.rb:30:in `require': cannot load such file
 -- rubygems/defaults (LoadError)

This file is part of rubygems, which in turn is a dependency of ruby 
itself. emerge rubygems manually first.

Kind regards,

Hans




[gentoo-user] Re: RUBY_TARGETS and eselect ruby

2014-03-05 Thread Hans de Graaff
On Fri, 21 Feb 2014 09:32:03 +, Svoop wrote:

 Hans de Graaff graaff at gentoo.org writes:
 Because we haven't gotten around to that yet. Also note that only a few
 packages currently have ruby21 support, so eselecting it right now is
 not very useful yet.
 We should be updating the ruby eselect module in the next week or so.
 
 Any news on this?
 
 Like Pavel the only related packages are rubygems, rake and friends
 since it's a pretty minimalistic box serving a Rails app which we are
 lifting to Ruby 2.1 next week.
 
 Support for ruby21 in eselect would be great, thanks a bunch!

eselect-ruby-20131227 has support for eselecting ruby21. It has been 
around since Jan 4th. Progress on ruby21 marking of packages has been 
slow but steady.

Hans




[gentoo-user] Re: RUBY_TARGETS and eselect ruby

2013-12-31 Thread Hans de Graaff
On Mon, 30 Dec 2013 18:25:38 +0400, Pavel Volkov wrote:

 I currently set my RUBY_TARGETS in make.conf to:
 RUBY_TARGETS=ruby20 ruby21
 
 World is updated.
 
 But ruby21 profile can't be selected with eselect:
 $ eselect ruby list Available Ruby profiles:
   [1]   ruby20 (with Rubygems) *
 
 If I remove ruby20 from RUBY_TARGETS, there would be no profiles left.

Because we haven't gotten around to that yet. Also note that only a few 
packages currently have ruby21 support, so eselecting it right now is not 
very useful yet.

We should be updating the ruby eselect module in the next week or so.

Hans




[gentoo-user] Re: Routine update wants to install 3 version of Ruby + 50 others

2013-12-11 Thread Hans de Graaff
On Tue, 10 Dec 2013 11:06:19 -0500, Michael Orlitzky wrote:

 On 12/10/2013 10:19 AM, Grant Edwards wrote:
 
 I understand that portage defaults to installing multiple versions (of
 Ruby, Python, and probably other stuff).  What I don't understand it
 _why_.  If none of the ebuilds specify q version, then they presumably
 will work with any availble version -- so why not just install one
 version?
 
 So why is the RUBY_TARGETS default the way it is? I can't speak for the
 Ruby team, but it was most likely chosen as the upgrade path that causes
 the least pain. It's not perfect, as you've seen, but different parts of
 the Ruby ecosystem move at a different pace, and you have to make them
 all place nice.

I can speak for the ruby team :-)  We have RUBY_TARGETS=ruby18 ruby19 
as the default because ruby18 used to be the default and recommended ruby 
and now ruby19 is. By adding both we can make the transformation mostly 
seamless. So why is ruby18 *still* there? Because, if we remove it, you 
must do an 'emerge --changed-use' run to forcefully uninstall all the 
ruby18 code. This is similar to the recent python3_2 to python3_3 
transition. I'm not a big fan of that approach, so instead we hoped to be 
able to just mask ruby18 given that it is no longer supported and just 
make it go away quietly, like we did with ree18 (Ruby Enterprise Edition).

If people here indicate that running 'emerge --changed-use' is no big 
deal and I'm making a mountain out of a molehill then we can reconsider 
that approach. We'll face the same situation soon with ruby19 and ruby20, 
so knowing what people prefer is helpful.

 During a transition period like this, various upstreams release a bunch
 of crap with circular or conflicting dependencies that happen to work on
 their machines because nobody is using a real package manager. The fact
 that it works as well as it does is a miracle. If you don't want all
 three versions of Ruby on your machine, try setting e.g.
 RUBY_TARGETS=ruby19. It probably won't work, but that's because some
 package has troublesome dependencies, not because we're handling it
 wrong.

It should work (I have some machines with that setting). Two things to 
keep in mind: you are now off the default settings, so you will need to 
manage new ruby targets yourself. You will also still get the ruby20 core 
installed for the moment due to weird dependency issues with some 
packages. This will get rectified when we add ruby20 to the default 
RUBY_TARGETS.

If you want just a single RUBY_TARGET then right now ruby19 is the one to 
use, judging by this graph: http://moving-innovations.com/~graaff/
targets.svg

Hans





[gentoo-user] Re: Routine update wants to install 3 version of Ruby + 50 others

2013-12-11 Thread Hans de Graaff
On Tue, 10 Dec 2013 15:19:56 +, Grant Edwards wrote:

 AFAICT, if you have a global tk USE flag, you can not have 1.8
 installed at the same time as 1.9 or 2.0.

It looks like ruby 1.8 wants tk built with the same threads setting, and 
ruby 1.9 and 2.0 (because their threads setting is now mandatory) require 
tk to have the threads USE flag. Your options are to either set the 
threads USE flag globally, or to set it only for ruby 1.8.

Hans




[gentoo-user] Re: Routine update wants to install 3 version of Ruby + 50 others

2013-12-10 Thread Hans de Graaff
On Mon, 09 Dec 2013 18:29:46 +, Grant Edwards wrote:

 My routine more-or-less weekly update suddenly decided that it needed to
 install 3 versions of Ruby along with ~50 other ruby-related packages. 
 This caused a bit of a problem, since those versions of Ruby can't
 coexist: (something to do with tk and threads).

There should not be a problem installing these versions at the same time, 
although perhaps with a specific combination of USE flags there might be 
issues. This should be fixable by specifying different USE flags for some 
of the packages.

 I've never had Ruby installed before, and after some digging around, I
 finally tracked it down to two things:
 
 gnome-terminal-nautilus-webkit-ruby
 multipath-tools-thin-provisioning-tools-ruby

At least for thin-provisioning-tools you could use the unstable revision 
that makes ruby an test-only dependency.

 I understand that sometimes a maintainer decides to add a feature that
 requires some new dependancies, but why three different versions of Ruby
 all of a sudden?

Because ruby18 and ruby19 are specified in the default RUBY_TARGETS as 
defined in the profile. And due to the way the dependencies are specified 
in both webkit and thin-provisioning-tools it will additionally try to 
pull in ruby20 first. Hence: three versions.

We intend to mask ruby18 shortly and at that time we will also add ruby20 
to the default RUBY_TARGETS. That still leaves two ruby versions, but we 
want to prepare for the new version as the old version is slowly being 
deprecated.

Hans




[gentoo-user] Re: USE ruby_targets_ruby20

2013-11-15 Thread Hans de Graaff
On Thu, 14 Nov 2013 15:57:40 -0800, Chris Stankevitz wrote:

 True or false: The correct way to appease portage's error message below
 is to add a bunch of ruby_targets_ruby20 use flags in
 /etc/portage/package.use

False. These packages should already have this use flag set by default in 
a vanilla Gentoo setup. Perhaps you masked something related to ruby 
already?

Hans




[gentoo-user] Re: Gentoo is so AWESOME

2013-08-01 Thread Hans de Graaff
On Tue, 30 Jul 2013 19:48:19 -0400, Michael Orlitzky wrote:

 I want to become a dev, what's my next step? There is none. Help out,
 and maybe someone will notice you? Ok, I'm on it. Been doing it for
 years, and I know several other people in the same situation. It doesn't
 work, and recruitment numbers are plummeting.
 
 There needs to be an explicit, documented process. And someone devoted
 full-time to mentoring new recruits. I can think of no better long-term
 investment of the foundation's money.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2 
documents this from the new developer perspective. Note how it says to 
contact the recruiters if you don't already have found a mentor yourself.

There is also http://www.gentoo.org/proj/en/devrel/recruiters/ which 
documents this from the inside, but when I wanted to become a developer I 
found that more useful documentation :-)

So it is explicitly documented. Perhaps not well enough? In that case, 
let us know what you miss.

Hans




[gentoo-user] Re: Gentoo is so AWESOME

2013-08-01 Thread Hans de Graaff
On Wed, 31 Jul 2013 14:34:41 -0400, Michael Orlitzky wrote:


 It seems a little rude to pop in, address them personally, and ask them
 each if they'd devote months of their time towards mentoring me. (Doing
 so can pressure someone into agreeing to something he doesn't want to
 do, or makes him reject you personally which many people find awkward.)

That doesn't sound rude to me at all. If you explain your interest and 
ask them if they know anyone that could be your mentor you can also avoid 
that pressure for the most part.

And we're not talking months here either. I've just finished mentoring 
someone, and it probably took ~15 hours spread over a couple of months. 
Compared to some of the other Gentoo work not a huge commitment, and one 
that pays itself back by seeing an otherwise derelict part of Gentoo 
being maintained again.

Hans




[gentoo-user] Re: rubinius fails to emerge with error about llvm-config

2012-08-20 Thread Hans de Graaff
On Sun, 19 Aug 2012 16:02:15 -0400, covici wrote:

 Hi.  In my update world of today, the system wanted to emerge rubinius
 -- for reasons known only to itself -- however it fails to emerge during
 its config phase with the following output:

 Any suggestions would be appreciated.

Check our bug database: https://bugs.gentoo.org/show_bug.cgi?id=417533

Hans





[gentoo-user] Re: Understanding new ruby dependencies

2012-05-23 Thread Hans de Graaff
On Tue, 22 May 2012 18:10:18 -0700, Chris Stankevitz wrote:

 On Tue, May 22, 2012 at 11:32 AM,  kwk...@hkbn.net wrote:
 No!  Don't do that!  Instead, you should add a line

 RUBY_TARGETS=ruby19

For now this should be

RUBY_TARGETS=ruby18 ruby19

We currently don't support running with ruby19 only. It might work, we 
just don't support it. :-)

 f) [your idea here]

f) It should just have worked.

I tried to be conservative and not add ruby19 in RUBY_TARGETS right away, 
but as you have noticed this causes problems for rdoc and friends. I'll 
add ruby19 to the default setting in the profile within a few days so 
that this problem goes away.

Kind regards,

Hans




[gentoo-user] Re: Understanding new ruby dependencies

2012-05-23 Thread Hans de Graaff
On Tue, 22 May 2012 23:35:21 -0700, Chris Stankevitz wrote:

 1. What on my system is insisting on make.conf RUBY 1.9 USE_EXPAND
 changes?  An emerge --tree is not giving me a clear answer (as it
 usually does).  The original post in this thread provides a pastebin
 link to back up this claim.

It is implicit. dev-lang/ruby:1.9 requires a new enough version of rdoc 
with this particular USE flag enabled.

 2. If the answer to (1) is the gentoo system itself, then why doesn't
 the gentoo system itself update the USE_EXPAND by adding a reference
 to ruby19?  It appears the gentoo system itself presently only enables
 the ruby18 USE_EXPAND.
   base $ find /usr/portage/profiles/ | xargs grep RUBY_TARGETS=
   /usr/portage/profiles/base/make.defaults:RUBY_TARGETS=ruby18

Right. We'll add ruby19 to that shortly. The reason we did not do that 
before was that we wanted to ease into ruby19, but there seem to be 
plenty of people that have a package depending on dev-lang/ruby on their 
system, so that plan didn't work very well.

 4. I run a stable system that is somehow insisting on ruby19.  This
 webpage http://www.gentoo.org/proj/en/prog_lang/ruby/index.xml  says
 ruby19 is not for use on production systems.  Why the disconnect?
 Perhaps the ruby page is just out of date.

Correct conclusion, and I've just updated it for the various ruby 
implementations.

 Thank you for listening to me list the issues I am ignorant on.  Now I'm
 going to add RUBY_TARGETS=ruby19 to my make.conf and hope things just
 work.

At this point I would recommend RUBY_TARGETS=ruby18 ruby19.

Kind regards,

Hans




[gentoo-user] Re: Understanding new ruby dependencies

2012-05-22 Thread Hans de Graaff
On Mon, 21 May 2012 20:52:01 -0700, Chris Stankevitz wrote:

 Question: Is is true that the RUBY dependencies listed in the above
 paste link are entirely due to adding documentation support
 (specifically rdoc)?  If so, can I tell portage to not install the rdoc
 stuff?  I have USE=-doc already.

Yes, this is true. We do this because normally ruby contains a copy of 
rdoc. We unbundle that and thus the external rdoc implementation is 
installed. You can control this with the rdoc USE flag on dev-lang/ruby, 
but note that not installing rdoc is probably considered broken by 
upstream.

Kind regards,

Hans




[gentoo-user] Re: RUBYOPT=-rauto_gem

2012-01-16 Thread Hans de Graaff
On Sun, 15 Jan 2012 14:24:30 -0800, Hilco Wijbenga wrote:

 If there is a requirement for this to be in the global environment, what
 is the consequence of unsetting RUBYOPT in my own .bashrc (or similar)?
 Is that safe? Or does that break something that I simply haven't
 noticed yet?

We don't support that setup, but you can always try. The only consequence 
should be that scripts won't find code installed by rubygems, unless you 
explicitly require 'rubygems' yourself.

The reason for this is partly history, and we can't really change it now 
without breaking a lot of stuff. It it also there to provide more choice, 
since you don't need to be explicit about this in your scripts. Finally, 
this is the default in ruby 1.9, even without RUBYOPT set, so we now have 
a matching situation between the different ruby versions.

Kind regards,

Hans




[gentoo-user] Re: RUBYOPT=-rauto_gem

2012-01-16 Thread Hans de Graaff
On Sun, 15 Jan 2012 22:21:30 -0800, Hilco Wijbenga wrote:

 On 15 January 2012 18:21, Michael Orlitzky mich...@orlitzky.com wrote:
 On 01/15/2012 05:24 PM, Hilco Wijbenga wrote:

 Hi all,

 The dev-ruby/rubygems ebuild adds -rauto_gem to the global RUBYOPT.
 This breaks my own scripts so I have removed it from /etc/env.d. So
 far, so good.

 Try asking on the -dev list, or filing a bug. They'll just close it if
 it's considered invalid.

Agree, if things are broken then please file a bug.

 We have too many open bugs already so I'll wait until (hopefully) I see
 a few more responses before I file a bug. That way there's less chance
 of an invalid bug and I may save some valuable dev time.

If you want to help us then open a bug so there can be a focused 
discussion, especially if things are broken. If you really want to help 
us then participate in the bugs and help us close them :-)

Kind regards,

Hans




[gentoo-user] Re: Unable to install the ffi gem.

2011-10-30 Thread Hans de Graaff
On Sat, 29 Oct 2011 16:36:31 +0530, Vishnupradeep wrote:

 Gem files will remain installed in
 /usr/lib64/ruby/gems/1.8/gems/ffi-1.0.9 for inspection.
 Results logged to
 /usr/lib64/ruby/gems/1.8/gems/ffi-1.0.9/ext/ffi_c/gem_make.out

The gem is broken. Install dev-ruby/ffi instead.

Hans




[gentoo-user] Re: XEmacs build hangs loading update-elc.el

2011-10-22 Thread Hans de Graaff
On Fri, 21 Oct 2011 09:23:38 -0400, Mike Edenfield wrote:

 I'm trying to build XEmacs on my laptop (Hardened ~amd64), and it
 appears to be stuck near the end trying to load and/or execute
 update-elc.el (it's been on this step for approaching 6 hours now).
 This happens every time I attempt to build xemacs (I've re-synched and
 restarted the build multiple times.)
 
 
  
 I thought it might be related to having PaX in my kernel, but when I
 switched softmode on, the build actually segfaults almost immedately!

https://bugs.gentoo.org/show_bug.cgi?id=75028

Hans




[gentoo-user] Re: IPv6 not ready here; Hmmm

2011-06-08 Thread Hans de Graaff
On Tue, 07 Jun 2011 20:27:45 -0500, Dale wrote:


  From there, there is a link to test whether the new IPv6 works on my
 system and between me and the reat of the world.  It appears I am not
 ready.  It complained about the DNS server for the most part.  Funny
 thing is, I use googles DNS servers.  8.8.8.8 and 8.8.4.4 are the
 settings. 

So you are explicitly using IPv4 addresses for your DNS. This is what the 
test complains about: to get full marks you need to connect to a DNS 
server via IPv6 as well. I'm not sure if Google provides public DNS via 
IPv6 yet.

 Should I have the USE flag ipv6 enabled or should I leave it off for
 now?  If so, anyone had any trouble with it or is this a trivial change?

You should leave this enabled unless you have a specific reason to turn 
it off.

Kind regards,

Hans




[gentoo-user] Re: installing ffi gem

2011-04-22 Thread Hans de Graaff
On Thu, 21 Apr 2011 23:12:51 -0700, kashani wrote:

 On 4/21/2011 9:54 PM, Hans de Graaff wrote:

 Please note that Gentoo also supports multiple ruby implementations out
 of the box (ruby 1.8, ruby enterprise edition, jruby currently stable,
 ruby 1.9 unfortunately still masked, rubinius forthcoming).
 
   It's not about which ruby you're installing on the system, really
 anything other than 1.8.7 as system Ruby is a pain in the ass at this
 point.

This is not about the system ruby, I agree that ruby 1.8.7 is currently 
the only sane choice for that.

   Using RVM I can have all version and implementations of Ruby and
 multiple gem sets per Ruby as well. That way I can work on
 ruby-1.8.7@rail2 app or switch to ruby-1.92@rails3 which keep the gems
 separate. Also I avoid breaking the system when doing wacky things in my
 dev environment.

The Gentoo setup can do this too. It install gems for all supported, 
desired, ruby implementations, and keeps separate gem hierarchies for 
each ruby implementation, so you can use different ruby implementations 
for different applications if you want.

This is all part of the ruby-ng.eclass, which all packages in testing 
use, and which is currently being pushed into stable.

Kind regards,

Hans




[gentoo-user] Re: installing ffi gem

2011-04-21 Thread Hans de Graaff
On Thu, 21 Apr 2011 17:33:05 -0700, kashani wrote:


 Install RVM, make it part of your shell, then install the ruby and gems
 of your choice. That way you leave the system Ruby alone and can develop
 with the versions you want. You can even do multiple versions of ruby
 and various gems for working on many different projects at once.

Please note that Gentoo also supports multiple ruby implementations out 
of the box (ruby 1.8, ruby enterprise edition, jruby currently stable, 
ruby 1.9 unfortunately still masked, rubinius forthcoming).

Kind regards,

Hans




[gentoo-user] Re: installing ffi gem

2011-04-21 Thread Hans de Graaff
On Fri, 22 Apr 2011 00:57:13 +0100, Matt Harrison wrote:

 I've just tried setting up a new development machine and I'm stuck
 installing the ffi gem for ruby.
 
 According to a bug I found (can't find it now I'm afraid) the gentoo
 devs do not support installing gems via the gem command and directed the
 user to use the dev-ruby/ffi package. Unfortnately, that package is
 absolutely ancient and unusable.

That is correct, we recommend to use our native Gentoo packages when 
present.

If you have a problem with a package, then please file a bug report at 
https://bugs.gentoo.org/  ffi-0.6.3-r1 should be usable.

 Anyway, I've got the ffi library install from portage, but when I try to
 `gem install ffi`, I get the output seen in the attachement.

Yes, you are trying to install a version of the ffi gem that is not 
compatible with your ruby version. ffi-0.6.3 is the latest version that 
reliably works with ruby 1.8. The ffi-1.x series never worked reliably 
with ruby 1.8, and the latest version have officially removed support for 
it and only work with ruby 1.9. This is also the reason that ffi-0.6.3 is 
the latest version in the tree.

Kind regards,

Hans




[gentoo-user] Re: Postgres gem not found by cron job

2010-08-13 Thread Hans de Graaff
On Wed, 11 Aug 2010 15:32:53 -0400, Michael Orlitzky wrote:

 Thanks for the tip. The cron environment was missing
 RUBYOPT=-rauto_gem -- adding it fixed the problem.
 
 Dark magic, whatever it does.

It ensures that installed gems are found automatically without
specifying this explicitly in your script. The other solution
is to require 'rubygems' first in your script.

Kind regards,

Hans




[gentoo-user] Re: [OT sphinx] Any users of sphinx here

2010-06-05 Thread Hans de Graaff
On Fri, 04 Jun 2010 17:52:05 -0500, Harry Putnam wrote:

 Googling lead to a tool called Sphinx that apparently is coupled with a
 data base tool like mysql.  It is advertised as the kind of search tool
 I'm after and has a perl front-end also available in portage
 (dev-perl/Sphinx-Search).
 
 The call it a `full text search engine', but never really say what that
 means.

It means that you can dump a lot of text documents into it (based on 
html pages, database records, actual documents, etc). sphinx efficiently 
indexes all the text in it, and then allows you to retrieve it again, 
supporting things that are useful for searching in text such as stemming.

It can use MySQL but this isn't needed to use it.

It should be able to help you with the task you want to solve, although 
I'm not familiar with the capabilities of the Sphinx-Search front-end/
binding.

Kind regards,

Hans




[gentoo-user] Re: killing gnome light - pathetic cry for help.

2008-03-04 Thread Hans de Graaff
On Mon, 25 Feb 2008 13:15:22 -0800, Michael Higgins wrote:

 I use Gnome ['gnome-light'] as my WM.
 
 For the past few months (many months) I've had the 'gnome-panel' lock up
 on me. Nothing is clearly causing this. Rebuilding has not seemed to
 help. Of course, what to rebuild? Everything?

I've seen this issue a few times and found that the esound daemon was to 
blame. Killing just that got things back in a workeable state again.

Kind regards,

Hans

-- 
gentoo-user@lists.gentoo.org mailing list



[gentoo-user] Re: [Fwd: Re: Gentoo Rules]

2007-12-15 Thread Hans de Graaff
On Fri, 14 Dec 2007 21:07:53 -0500, Randy Barlow wrote:

 7v5w7go9ub0o wrote:
 My concerns with this, other than my abilities, are:
 
 1. Showing proper respect to the guy who pioneered the effort to date,
 and who may simply be out of town. (This disrespect would be alleviated
 if there was an official policy encouraging volunteer ebuilds.)
 
 It's not disrespectful, IMO, to do something that you don't see getting
 done.  Especially since it's less work for another guy.  I wouldn't
 worry about that point.

As a developer I agree with that point. It's always better to get bug 
reports for version bumps or problems that have patches attached to them, 
or even a simple note saying that you copied the ebuild to the new 
version and things work fine.

 This can happen.  I've submitted ebuilds for backuppc-3.0.0, and so have
 many other people.  In fact, the bug for it has several ebuilds that
 have been submitted but haven't made it into the official tree.  I think
 that particular bug report might not be getting attention from the right
 people or something.  That doesn't mean it isn't worth doing though,
 because people can still use the ebuild from the bug report.  Ideally, a
 dev would see that, check it out for correctness, and add it to ~arch.

I guess you are talking about https://bugs.gentoo.org/show_bug.cgi?
id=141018 ? It's assigned to maintainer-needed (ie, it is in the tree, 
but currently no developer is maintaining it). The original maintainer 
recently retired, so it is now in some sort of limbo. In this case the 
fallback would be the backup herd (who are listed on the bug), but I know 
that these folks are understaffed. As you can tell from this we are 
always looking for more developers.

 Does anybody know how to call attention to a bug report that doesn't
 seem to have any devs paying attention to it?  I think BackupPC is a
 fine product, and would like to see it in the tree for others to use.
 I'm using my own ebuild successfully, as are many of the fine folks who
 have contributed on that bug report.  I'd just like my and others'
 efforts to be something that benefits more of the Gentoo community :)

A possible solution would be for you (or someone) to become a proxy 
maintainer, meaning that you'd get the bug reports and provide new 
ebuilds, and a developer (most likely someone from the backup herd) would 
review it and put it in the tree. 

Kind regards,

Hans

-- 
[EMAIL PROTECTED] mailing list



[gentoo-user] Re: Gentoo Rules

2007-12-15 Thread Hans de Graaff
On Fri, 14 Dec 2007 11:56:41 -0800, Grant wrote:

  Lately I've been shopping around for other distros as well as looking
  at *BSD.  Gentoo development seems to have slowed way down and I like
  things being improved as quickly as possible.  FreeBSD is supposed to
  be the closest relation, but even that won't do.  I don't think there
  is anything as satisfying as Gentoo out there.  The concept is second
  to none, the execution of that concept is fantastic, but it needs to
  keep moving forward.  What is the next step?  Or should we keep
  treading water?
 
  - Grant

 I love gentoo and can't settle for anything else.  What can I do to
 make sure development doesn't stop?
 
 Let me in on that.  What can I do too?

There are plenty of things that can be done, depending on what kind of 
skills you bring with you. And please note that those skills need not be 
technical in order to help out. Just some things off the top of my head:

* participate in the community (e.g. here or in the forums) to help 
others with Gentoo things
* participate on bugs.gentoo.org by adding relevant comments to bugs, 
trying to fix bugs, providing new ebuilds or patches (and bugday is a 
good way to get started with that: http://bugday.gentoo.org/)
* help out the documentation teams to maintain the current information or 
create new stuff and possible translate it
* help out with Gentoo artwork
* help out with the organization of Gentoo stuff such as events and PR
* becoming a developer: http://www.gentoo.org/proj/en/devrel/staffing-
needs/
* that one thing that you can do really well but that I forgot to list 
here

Feel free to drop me an email off-list if you'd like to discuss what you 
can do for Gentoo.

Kind regards,

Hans

-- 
[EMAIL PROTECTED] mailing list



[gentoo-user] Re: Gentoo Rules

2007-12-15 Thread Hans de Graaff
On Sat, 15 Dec 2007 01:05:08 +0100, b.n. wrote:

 Florian Philipp ha scritto:
 
 Other things to improve? A better documentation on USE-flags. In my
 opinion every maintainer should provide as much information as possible
 on what exactly a USE-flag changes. At the moment it's the
 administrator's responsibility to find this out. Not really a good idea
 on production systems if you ask me ...
 
 +1
 
 m.

Good news then as a scheme for this has been proposed and partially 
implemented: http://blog.cardoe.com/archives/2007/11/19/use-flag-metadata/

It was decided in the last council meeting to keep this scheme: http://
www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt

This only provides the information, it may take some time before user-
facing tools (such as euse) expose this information, and obviously 
developers need to add the information.

Kind regards,

Hans

-- 
[EMAIL PROTECTED] mailing list



[gentoo-user] Re: esound refuses to compile with docbook error even though -doc is specified

2007-12-02 Thread Hans de Graaff
On Sat, 01 Dec 2007 15:24:00 -0800, Justin Patrin wrote:

 # emerge -auv esound
 
 These are the packages that would be merged, in order:
 
 Calculating dependencies... done!
 [ebuild  N] media-sound/esound-0.2.38-r1  USE=alsa ipv6 tcpd -debug
 -doc 0 kB
 
 ...
 
 Making all in docs
 make[2]: Entering directory
 `/var/tmp/portage/media-sound/esound-0.2.38-r1/work/esound-0.2.38/docs'
 jw -f docbook -b html -o html ./esound.sgml Using catalogs:
 /etc/sgml/sgml-docbook-3.1.cat Using stylesheet:
 /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on:
 /var/tmp/portage/media-sound/esound-0.2.38-r1/work/esound-0.2.38/docs/./
esound.sgml
 jade:/usr/share/sgml/docbook/sgml-dtd-3.1/dbcent.mod:53:65:W: cannot
 generate system identifier for public text ISO 8879:1986//ENTITIES
 Added Math Symbols: Arrow Relations//EN
 jade:/usr/share/sgml/docbook/sgml-dtd-3.1/dbcent.mod:54:8:E: reference
 to entity ISOamsa for which no system identifier could be generated
 jade:/usr/share/sgml/docbook/sgml-dtd-3.1/dbcent.mod:52:0: entity was
 defined here
 
 
 This has been happening to me for quite some time, I haven't been able
 to finish updating gnome because of this.

As far as I can tell this particular problem can be fixed by re-emerging 
sgml-common.

Kind regards,

Hans

-- 
[EMAIL PROTECTED] mailing list



[gentoo-user] Re: emerge v gem for rails

2007-11-24 Thread Hans de Graaff
On Sat, 24 Nov 2007 05:30:14 +, Thufir wrote:

 I'm running into some error messages from rails when running script/
 generate controller foo and am wondering if it's related to package
 management, a mismatch between gems and emerge.  Do not use gems, use
 emerge?  The wiki is incorrect?

I'd consider the wiki in general to be a good first source of information 
but certainly not accurate. Usually this is because the page is created 
at some point but not properly maintained or reviewed. In this case the 
mention of Rails 1.1 and not Rails 1.2 is a dead giveaway that this page 
is outdated.

 The gentoo wiki, http://gentoo-wiki.com/HOWTO_RoR, says to:
 
  emerge -av sqlite3-ruby
  gem install sqlite3-ruby

You really don't want to do both of these. In fact, emerging the sqlite3-
ruby already installs the gem version, so running 'gem install sqlite3-
ruby' will at best have no effect and at worst confuse emerge at a later 
stage.

 So, it looks like the version of sqlite3-ruby installed matches the
 instructions at the wiki, but the version number doesn't seem to match
 what's available through gem; and the wiki specifically states to
 install the gem.

The wiki instructions are non-sense. I guess that this originates from 
the fact that we install some packages in site-ruby which means that gem 
dependencies don't always work, aka bug https://bugs.gentoo.org/
show_bug.cgi?id=196036

In this particular case the instruction is nonsense since portage already 
installs the gem.

 The error I'm running into may be totally unrelated to this.  It seems a
 bit odd to me that sqlite3-ruby must be emerged through portage and that
 gem must install it as well -- one or the other would seem to be
 sufficient.

Good thinking. :-)

Without showing us the error we can't help you with that, though.

Kind regards,

Hans

-- 
[EMAIL PROTECTED] mailing list