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

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

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

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

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

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

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

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

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

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

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