any interest in an official "meta-rubygems" layer?

any interest in an official "meta-rubygems" layer?

[Robert P. J. Day]

  since it appears that i will be diving head-first into messing with
ruby in some current YP builds, is there any interest in creating a
meta-rubygems layer to start collecting recipes based on what konrad
weihmann has done in his meta-sca layer here?

  https://github.com/priv-kweihmann/meta-sca

  i've been swapping emails with konrad over the last few days and,
first, it seems clear that it's not appropriate to start dumping
general ruby recipes into meta-sca as that layer is clearly defined as
being for "static code analysis and security hardening", so a new,
more general layer is obviously more appropriate.

  also, konrad focuses on using his own "rubygems.bbclass" class file:

https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass

to define recipes that pull from rubygems.org exclusively, and he
agrees that it would keep things simpler to stick with that model;
hence, the proposal of the layer name "meta-rubygems" and not just
"meta-ruby".

  konrad already offered to do the maintenance of such a new layer, as
long as there is standard infrastructure support for testing, that
sort of thing. and i'm sure that would make his meta-sca layer simpler
as all the more generic rubygems-based recipes could be moved into the
meta-rubygems layer, leaving his meta-sca layer to focus exclusively
on the code analysis and security recipes, however he wants to do
that.

  thoughts? it seems that a new layer could be populated almost
instantly with a large chunk of meta-sca, and we could take it from
there.

rday

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Jack Mitchell]

On 27/01/2021 06:33, Robert P. J. Day wrote:
> 
>   since it appears that i will be diving head-first into messing with
> ruby in some current YP builds, is there any interest in creating a
> meta-rubygems layer to start collecting recipes based on what konrad
> weihmann has done in his meta-sca layer here?
> 
>   https://github.com/priv-kweihmann/meta-sca
> 
>   i've been swapping emails with konrad over the last few days and,
> first, it seems clear that it's not appropriate to start dumping
> general ruby recipes into meta-sca as that layer is clearly defined as
> being for "static code analysis and security hardening", so a new,
> more general layer is obviously more appropriate.
> 
>   also, konrad focuses on using his own "rubygems.bbclass" class file:
> 
> https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass
> 
> to define recipes that pull from rubygems.org exclusively, and he
> agrees that it would keep things simpler to stick with that model;
> hence, the proposal of the layer name "meta-rubygems" and not just
> "meta-ruby".
> 
>   konrad already offered to do the maintenance of such a new layer, as
> long as there is standard infrastructure support for testing, that
> sort of thing. and i'm sure that would make his meta-sca layer simpler
> as all the more generic rubygems-based recipes could be moved into the
> meta-rubygems layer, leaving his meta-sca layer to focus exclusively
> on the code analysis and security recipes, however he wants to do
> that.
> 
>   thoughts? it seems that a new layer could be populated almost
> instantly with a large chunk of meta-sca, and we could take it from
> there.
> 
> rday
> 

Hi Robert,

This is something I would be interested in. I have a developed a much
more basic rubygems class privately which I had intended to opensource
and create a similar later, so it would be nice to have a central place
to contribute Ruby/RubyGems improvements. As you have found there are
many layers with spotty Ruby support and a particular copy of an old
class that is being banded about which is often insufficient.

Regards,
Jack.

-- 
Jack Mitchell, Consultant
https://www.tuxable.co.uk

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Robert P. J. Day]

On Wed, 27 Jan 2021, Jack Mitchell wrote:
... snip ...

> Hi Robert,
>
> This is something I would be interested in. I have a developed a
> much more basic rubygems class privately which I had intended to
> opensource and create a similar later, so it would be nice to have a
> central place to contribute Ruby/RubyGems improvements. As you have
> found there are many layers with spotty Ruby support and a
> particular copy of an old class that is being banded about which is
> often insufficient.

  cool ... care to share your rubygems.bbclass file? be great to
combine the best of both worlds.

rday

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Jack Mitchell]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On 27/01/2021 09:09, Robert P. J. Day wrote:
> On Wed, 27 Jan 2021, Jack Mitchell wrote:
> ... snip ...
> 
>> Hi Robert,
>>
>> This is something I would be interested in. I have a developed a
>> much more basic rubygems class privately which I had intended to
>> opensource and create a similar later, so it would be nice to have a
>> central place to contribute Ruby/RubyGems improvements. As you have
>> found there are many layers with spotty Ruby support and a
>> particular copy of an old class that is being banded about which is
>> often insufficient.
> 
>   cool ... care to share your rubygems.bbclass file? be great to
> combine the best of both worlds.
> 
> rday
>

Please find attached, it's basically the old ruby class with only
support for pure RubyGems (i.e. no cross-compiling) with some influence
from the pypi class for grabbing and compiling a SRC_URI.

Cheers,
Jack.

-- 
Jack Mitchell, Consultant
https://www.tuxable.co.uk

[-- Attachment #2: rubygems.bbclass --]
[-- Type: text/plain, Size: 1833 bytes --]

def get_rubygemsversion(p):
    import re
    from os.path import isfile
    import subprocess
    found_version = "SOMETHING FAILED!"

    cmd = "%s/gem" % p

    if not isfile(cmd):
       return found_version

    version = subprocess.Popen([cmd, "env", "gemdir"], stdout=subprocess.PIPE).communicate()[0]

    r = re.compile(".*([0-9]+\.[0-9]+\.[0-9]+)$")
    m = r.match(version.decode("utf-8"))
    if m:
        found_version = m.group(1)

    return found_version

RUBY_GEM_VERSION ?= "${@get_rubygemsversion("${STAGING_BINDIR_NATIVE}")}"

def rubygems_gem(d):
    bpn = d.getVar('BPN')
    if bpn.startswith('ruby-'):
        return bpn[5:]
    return bpn

RUBYGEMS_GEM_NAME ?= "${@rubygems_gem(d)}"
RUBYGEMS_GEM_EXT ?= "gem"
RUBYGEMS_GEM ?= "${RUBYGEMS_GEM_NAME}-${PV}.${RUBYGEMS_GEM_EXT}"

def rubygems_src_uri(d):
    package = d.getVar('RUBYGEMS_GEM_NAME')
    package_ext = d.getVar('RUBYGEMS_GEM_EXT')
    pv = d.getVar('PV')
    return 'https://rubygems.org/downloads/%s-%s.%s' % (package, pv, package_ext)

RUBYGEMS_SRC_URI ?= "${@rubygems_src_uri(d)}"

HOMEPAGE ?= "https://rubygems.org/gems/${RUBYGEMS_GEM_NAME}"
SRC_URI += "${RUBYGEMS_SRC_URI}"
S = "${WORKDIR}/${RUBYGEMS_GEM_NAME}-${PV}"

DEPENDS += " \
    ruby-native \
"

RDEPENDS_${PN} += " \
    ruby \
"

rubygems_do_compile() {
	:
}

do_unpack[depends] += "ruby-native:do_populate_sysroot"

rubygems_do_unpack() {
	gem unpack --target ${WORKDIR} ${DL_DIR}/${RUBYGEMS_GEM}
}

RUBY_GEM_DIR="${libdir}/ruby/gems/${RUBY_GEM_VERSION}"
GEM_DEST="${D}/${RUBY_GEM_DIR}"

rubygems_do_install() {
    gem install --ignore-dependencies --local --env-shebang --install-dir ${GEM_DEST}/ ${DL_DIR}/${RUBYGEMS_GEM}
    rm -rf ${GEM_DEST}/cache
}

FILES_${PN}-doc = "${RUBY_GEM_DIR}/doc"
FILES_${PN} = "${RUBY_GEM_DIR}"

EXPORT_FUNCTIONS do_unpack do_compile do_install

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Robert P. J. Day]

  regarding the proposed "meta-rubygems" layer --- which sounds like
it's going to take off as it can be initialized quite a lot just from
konrad's existing meta-sca layer, what are the options for "official"
YP hosting?

  i notice that quite a number of layers live at git.yoctoproject.org
-- would this proposed layer even be eligible for that and, if so,
what are the benefits of living under the git.YP.org umbrella?

  if not there, then github would be the obvious alternative.
thoughts?

rday

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Armin Kuster]

On 1/27/21 12:04 PM, Robert P. J. Day wrote:
>   regarding the proposed "meta-rubygems" layer --- which sounds like
> it's going to take off as it can be initialized quite a lot just from
> konrad's existing meta-sca layer, what are the options for "official"
> YP hosting?
>
>   i notice that quite a number of layers live at git.yoctoproject.org
> -- would this proposed layer even be eligible for that and, if so,
> what are the benefits of living under the git.YP.org umbrella?
Are you a member of the Yocto Project?

regards,
Armin

>
>   if not there, then github would be the obvious alternative.
> thoughts?
>
> rday
>
> 
>

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Robert P. J. Day]

On Wed, 27 Jan 2021, Armin Kuster wrote:

>
>
> On 1/27/21 12:04 PM, Robert P. J. Day wrote:
> >   regarding the proposed "meta-rubygems" layer --- which sounds like
> > it's going to take off as it can be initialized quite a lot just from
> > konrad's existing meta-sca layer, what are the options for "official"
> > YP hosting?
> >
> >   i notice that quite a number of layers live at git.yoctoproject.org
> > -- would this proposed layer even be eligible for that and, if so,
> > what are the benefits of living under the git.YP.org umbrella?

> Are you a member of the Yocto Project?

  i personally am not, so i suspect github is the option.

rday

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Armin Kuster]

On 1/27/21 1:29 PM, Robert P. J. Day wrote:
> On Wed, 27 Jan 2021, Armin Kuster wrote:
>
>>
>> On 1/27/21 12:04 PM, Robert P. J. Day wrote:
>>>   regarding the proposed "meta-rubygems" layer --- which sounds like
>>> it's going to take off as it can be initialized quite a lot just from
>>> konrad's existing meta-sca layer, what are the options for "official"
>>> YP hosting?
>>>
>>>   i notice that quite a number of layers live at git.yoctoproject.org
>>> -- would this proposed layer even be eligible for that and, if so,
>>> what are the benefits of living under the git.YP.org umbrella?
>> Are you a member of the Yocto Project?
>   i personally am not, so i suspect github is the option.


Regardless of its home, there seems to be interest in such a layer.
There is nothing stopping you from registering in the layer in the layer
index and see where it goes from there.

Ruby was part of meta-openembedded. Maybe OE would want to host such a
layer or include it within meta-openembedded.


-armin
>
> rday

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Robert P. J. Day]

On Wed, 27 Jan 2021, akuster wrote:

> On 1/27/21 1:29 PM, Robert P. J. Day wrote:
> > On Wed, 27 Jan 2021, Armin Kuster wrote:
> >
> >>
> >> On 1/27/21 12:04 PM, Robert P. J. Day wrote:
> >>>   regarding the proposed "meta-rubygems" layer --- which sounds like
> >>> it's going to take off as it can be initialized quite a lot just from
> >>> konrad's existing meta-sca layer, what are the options for "official"
> >>> YP hosting?
> >>>
> >>>   i notice that quite a number of layers live at git.yoctoproject.org
> >>> -- would this proposed layer even be eligible for that and, if so,
> >>> what are the benefits of living under the git.YP.org umbrella?
> >> Are you a member of the Yocto Project?
> >   i personally am not, so i suspect github is the option.
>
> Regardless of its home, there seems to be interest in such a layer.
> There is nothing stopping you from registering in the layer in the
> layer index and see where it goes from there.
>
> Ruby was part of meta-openembedded. Maybe OE would want to host such
> a layer or include it within meta-openembedded.

  interesting idea, i hadn't considered that. in the meantime, i think
we'll ponder what the structure of the new layer will look like, and
put together a first pass.

rday

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Jack Mitchell]

On 27/01/2021 09:17, Jack Mitchell wrote:
> On 27/01/2021 09:09, Robert P. J. Day wrote:
>> On Wed, 27 Jan 2021, Jack Mitchell wrote:
>> ... snip ...
>>
>>> Hi Robert,
>>>
>>> This is something I would be interested in. I have a developed a
>>> much more basic rubygems class privately which I had intended to
>>> opensource and create a similar later, so it would be nice to have a
>>> central place to contribute Ruby/RubyGems improvements. As you have
>>> found there are many layers with spotty Ruby support and a
>>> particular copy of an old class that is being banded about which is
>>> often insufficient.
>>
>>   cool ... care to share your rubygems.bbclass file? be great to
>> combine the best of both worlds.
>>
>> rday
>>
> 
> Please find attached, it's basically the old ruby class with only
> support for pure RubyGems (i.e. no cross-compiling) with some influence
> from the pypi class for grabbing and compiling a SRC_URI.
> 
> Cheers,
> Jack.
> 
> 

and a short example of how it's used

> cat recipes-devtools/ruby/ruby-pqueue_2.1.0.bb

inherit rubygems

LICENSE = "BSD-2-Clause"
LIC_FILES_CHKSUM = "file://License.txt;md5=8f085d0bb9ef0d1705dc5fd61aaaffa1"

SRC_URI[sha256sum] =
"8b79d9baa303a9747e83877def5a698e0e61d145d4c4275487c79fb1642102a9"


-- 
Jack Mitchell, Consultant
https://www.tuxable.co.uk

Re: [yocto] any interest in an official "meta-rubygems" layer?

[Carsten Stelling]

>   since it appears that i will be diving head-first into messing with ruby in some
> current YP builds, is there any interest in creating a meta-rubygems layer to start
> collecting recipes based on what konrad weihmann has done in his meta-sca
> layer here?

We would also find an official layer for gems interesting. 
We are currently using the old ruby.bbclass from the meta-ruby layer 
from openemebedded to build the gems.
We are also particularly interested in gems that need cross compiling, e.g. ruby-pcap.
 
srp