ruby-sig October 2017

ruby-sig@lists.fedoraproject.org

8 participants
9 discussions

Ruby 2.2
by Vít Ondruch 25 Jan '22

25 Jan '22

Hi everybody, Since Ruby 2.2 is going to be released during Christmas and -preview1 release is imminent (this Wednesday?), it is probably time to start looking into its packaging. So here is the updated .spec file [1] and scratch build [2], which can be finally build on all platforms. Sorry, no Copr for you, since Ruby's build fails there due to old RHEL kernel :/. What has changed from packaging point of view? Luckily, not much, but here are a few bullets which comes to my mind: * RPM 4.12 introduces new %load function, which is used to load RPM macros during RPM build. This allowed to drop my custom RPM macro [3]. On the other hand, you'll be able to build the Ruby only on F21+ (luckily, you should be able to build SRPM everywhere). * The RubyGems filesystem was not explicit enough, so there might be something accidentally packages. This is now more explicit, so we should be safer. * Ruby now ships with MiniTest and Test::Unit. The very good news is that they are installed so far as a regular gems. This means that you have to always specify them in your Gemfile, if you are using Bundler, but this is generally step in good direction. I hope that upstream will not change their mind :) Due to this change, we have new subpackages rubygem-test-unit (and rubygem-power_assert, which is now Test::Unit's dependency). No more %{_bindir}/testrb (but nobody is using it these days anyway, right? ;) * Some prevailing test failures were resolved, some others introduced, but hopefully they'll get resolved prior stable release. Generally, I'd say that not much has changed since 2.1, which is good news. Please test the packaging if you can and let me know about any issues you encountered. Also, if you have any other suggestions about Ruby packaging in general, what we could improve etc, this is probably good time to share. It seems that OpenSUSE guys are improving their packaging, so you might want to get some inspiration there [4, 5, 6] ;) Vít [1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.2 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7578843 [3] http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.2&id=8… [4] https://build.opensuse.org/package/show/home:darix:ruby/ruby-common [5] https://build.opensuse.org/package/show/home:darix:ruby/ruby2.2 [6] https://github.com/openSUSE/gem2rpm/commits/master

4 18

Ruby 2.5
by Vít Ondruch 07 May '18

07 May '18

Hi all, Ruby 2.4 was released during Christmas and the upcoming Ruby 2.5 development is advancing, so I continue in the tradition and I got r58319 packaged for testing. The updated .spec file is available in dist-git private-ruby-2.5 branch and here is the scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=18952639 One thing I'd like to point out that upstream is working on gemification of StdLib. The question ATM is what the result will be. Hence, there is one big TODO in the .spec file [1]. The question if each of the gems should be unbundled or not. The future will tell hopefully. Vít [1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/ruby.spec?h=private-r…

3 27

Hey Ruby packagers: can you help with asciibinder and its dependencies?
by Matthew Miller 07 Feb '18

07 Feb '18

We're using a new system for http://docs.fedoraproject.org. It's in Ruby, and as per tradition requires a number of ruby gems not packaged in Fedora. The upstream is at https://github.com/redhataccess/ascii_binder, and it looks like we're missing diff_dirs, asciibinder-diagram, guard, guard-shell, guard-livereload, pandoc-ruby, sitemap_generator, and yajl-ruby. Plus something called "trollop" which needs to be a version in f27/rawhide but not yet in f26. Can you help? Running asciibinder locally is very convenient while writing or converting docs, and having it a `dnf install` away would be really nice.

5 21

Re: updating facter in rawhide
by James Hogarth 07 Nov '17

07 Nov '17

On 30 October 2017 at 11:50, Gaël Chamoulaud <gchamoul(a)redhat.com> wrote: > On 25/Oct/2017 15:22, James Hogarth wrote: >> On 13 October 2017 at 20:49, James Hogarth <james.hogarth(a)gmail.com> wrote: >> > >> > >> > On 4 October 2017 at 15:16, James Hogarth <james.hogarth(a)gmail.com> wrote: >> >> >> >> >> >> >> >> On 5 September 2017 at 08:15, James Hogarth <james.hogarth(a)gmail.com> >> >> wrote: >> >>> >> >>> >> >>> >> >>> On 5 Sep 2017 8:05 am, "Vít Ondruch" <vondruch(a)redhat.com> wrote: >> >>> >> >>> >> >>> >> >>> Dne 4.9.2017 v 14:58 James Hogarth napsal(a): >> >>> > >> >>> > I'm in two minds whether to suggest we leave facter as it is for >> >>> > F25-27 or whether to at least update those to 2.5.1 which won't have >> >>> > the drastic 3.0 changes. >> >>> >> >>> For me it is always clear. Keep the branched versions as they are unless >> >>> you have really good arguments for upgrade. >> >>> >> >>> >> >>> Usually I'd agree... but facter is way behind on bug fixes and hasn't >> >>> seen an update in two years... a full three fedora releases ago. >> >>> >> >>> A move to the most recent 2.X on the branches whilst 3.X is arranged in >> >>> rawhide has decent justification... but I'll wait on what to do with that >> >>> after a discussion with upstream. >> >>> >> >>> >> >>> > I've also not looked fully into the EPEL situation but from an initial >> >>> > cursory look of gemfiles I think the ruby versions there are out of >> >>> > their support matrix. >> >>> >> >>> Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old >> >>> and incompatible (mainly due to encoding support and character >> >>> handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends >> >>> to drop official support for older Rubies (without any real reason >> >>> except reducing the support matrix), but the code typically works >> >>> (although you might need to relax some dependencies). >> >>> >> >>> One thing to always consider is the dependency chain, including the >> >>> build dependencies ... >> >>> >> >>> >> >>> Yeah this is another package that's just going to be left at an old >> >>> version in EPEL6 I fear... I really wish we could link to Red Hat SCL >> >>> packages for these situations... but oh well. Since my only direction/goal I >> >>> this endeavour is the removal is the requirement of net-tools, and that's >> >>> only Fedora, I'm not going to worry about it for now. >> >>> >> >>> >> >> >> >> Hi guys, >> >> >> >> Here's a status update for this change. >> >> >> >> I have a Facter 3.9.0 package I'm happy with on initial testing. I'll be >> >> writing up a F28 self contained change shortly. I've tested puppet in F26 >> >> against this and it appears to behave correctly - would appreciate more eyes >> >> on it though. >> >> >> >> I'm having issues with cmake3 in EPEL7 not picking up the cmake files from >> >> the leatherman package preventing me from building there - so that will stay >> >> on 2.5.X for now, similar to F26 and F27 will be updated shortly staying >> >> within the 2.5.X series for compatibilty concerns. >> >> >> >> If you'd like to test the facter 3.9.0 packages this COPR can be used: >> >> >> >> https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/ >> >> >> >> We'll need to coordinate on the F28 package so puppet can depend on >> >> ruby-facter instead of facter ... I'll do a repoquery to see if I can locate >> >> any similar packages using the ruby bindings as well. >> >> >> >> Cheers, >> >> >> >> James >> >> >> > >> > To keep the ruby sig and relevant package owners/reviewers in the loop ... >> > the change for Facter3 in F28 has been approved. >> > >> > https://pagure.io/fesco/issue/1767#comment-472520 >> > >> > I'll get the boost-nowide review request in over the weekend, which will >> > unblock leatherman and cpp-hocon can then be submitted as well. >> > >> > The initial spec files that need a final tuning for submission, and which >> > were used for the COPR, can be found here: >> > >> > https://jhogarth.fedorapeople.org/facter3/ >> > >> > We've got plenty of time according to the schedule but it'd be nice to get >> > this resolved in rawhide sooner rather than later :) >> > >> > https://fedoraproject.org/wiki/Releases/28/Schedule >> > >> > James >> > >> >> Hi guys, >> >> Further update for this update ;) >> >> General stuff >> ------------------- >> >> The work of Denis Arnaud has got boost157 packaged as an option in >> EPEL (as of a few minutes or so when I approve the package review). >> >> The boost-nowide dependency has it's own review and has been tested in >> both F27 and F26 as well as with the boost157 package to build >> leatherman, and packages further down the tree. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1502584 >> >> The leatherman spec in my fedorapeople space was used to build the >> version in the COPR with cpp-hocon using that leatherman package to >> build and facter3 using that to build/run. >> >> https://jhogarth.fedorapeople.org/facter3/ >> >> https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/ >> >> I've not submitted the cpp-hocon review yet as it's dependent on the >> boost-nowide one anyway. >> >> Obviously as you can see in the COPR the new facter 3 builds fine in >> EPEL7 and Fedora with the boost157 package and these two dependencies >> in place. >> >> This is all fine for Fedora and puts us in a great place to get this >> all into place in plenty of time before F28 even branches. >> >> Note that although I've built facter3 in the COPR for EPEL7 (using >> that boost157 package) and facter itself works fine ... the older >> puppet in EPEL (3.6.2 in EPEL7) is not compatible with the more recent >> facter. >> >> I'm not sure exactly yet where the specific breakage happens and >> haven't had time to dig through all the old puppet release notes to >> see where the facter compatibility changes. >> >> Does the Ruby-SIG have any plans to get puppet updated in EPEL7? If so >> we can get the new facter there too ... if not we'll need to hold back >> and I'm not even sure if the 2.5.X releases of facter would be >> compatible. >> >> Specific questions to people >> -------------------------------------- >> >> Haikel, have you had time to review the changes to the leatherman spec >> and patches proposed to bring your review up to date? Do you have time >> to finish through on that review once the boost-nowide module is >> approved? >> >> Gaël, are you happy remaining POC or would you prefer I get any bug >> reports after we push facter3 out? > > Hi James, > > A big sorry about the slow reactivity from my part! > > I think I've been promoted to POC since the new fedora sources web application, > and I appreciate you request to take over it. > >> Vit, are you okay to adjust the puppet dependency in fedora to >> ruby-facter once we get the dependencies built or would you prefer I >> coordinate that change with the facter update as a Proven Packager? >> >> Thanks for all you help and time guys, >> >> James > > With Gratitude, > > Gaël Hey no worries and thanks :) FYI everything is aligned now so as soon as Haikel has done his leatherman build in rawhide I'll be building Facter 3 there.

1 1

Ruby 2.5 change proposal
by Vít Ondruch 06 Nov '17

06 Nov '17

Hi rubyists, Ruby 2.5.0.preview1 was released ~2 weeks ago, so it is right about the time to start with its preparation, so I put together change proposal for Ruby 2.5 in Fedora 26 [1]. Any feedback is welcome. If no feedback, I'll propose this change to package wrangler in a week or so ... Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_2.5

3 3

Re: updating facter in rawhide
by James Hogarth 25 Oct '17

25 Oct '17

Thanks for the reply. On 4 Sep 2017 1:38 pm, "Vít Ondruch" <vondruch(a)redhat.com> wrote: Hi James, Not an Puppet/Facter expert, so just a few comments ... Dne 4.9.2017 v 13:34 James Hogarth napsal(a): > Hi guys, > > I'm getting the infrastructure in place ready for the mass bug filing > and package updates for the removal of dependencies on net-tools in Fedora > > https://pagure.io/fesco/issue/1711 > > One of the more tricky packages is facter. > > Right now it's an old ruby package (2.4.3 when rubygems/github has it > at 2.5.1 in the ruby variety). > > The ruby version has the dependency on net-tools for ifconfig, but > this was removed in the 3.0+ releases when they ported it to c++11 > > From the documentation it appears that ruby applications/libraries > that use facter will still do so through the ruby binding just as they > always have ... and looking at the puppet package it explicitly states > that it works with facter greater than 2 and less than 4 ... > > The puppetlabs puppet-agent already uses facter 3.8.0 in the current > release. > > The 2.5.1 tag in github is especially weird as it's not listed as a > facter release here: > > https://docs.puppet.com/facter/ It seems that there was 2.4 release followed by 3.0 release and since that point, the 2.x branch was not refreshed. Probably some tooling issue on puppet side ... It's rather odd. I plan on engaging with them directly to get an accurate answer. They don't ship the 2.X facter in their current puppet repos but there's clearly been releases since 2.4 on the 2.X line. > > That even says 2.4 is now EOL, and has been since December last year. Where? On the page I linked it states: Note: Facter versions prior to 3.0 will go end of life December 31, 2016. Please update if you haven’t already. Also interestingly there's no reference to any facter 2.x after 2.4 in facter documentation... release notes after 2.4 go to 3.0 https://docs.puppet.com/facter/3.8/release_notes.html I'll definitely contact upstream to get a clear answer on this and include it in the facter F28 change. > > The tricky bits for the facter update are that it now has dependencies > on https://github.com/puppetlabs/leatherman > and https://github.com/puppetlabs/cpp-hocon > > There's already a package review request for leatherman which I plan > to take over, and I've got a shared library version of cpp-hocon ready > for review (depends on leatherman) which facter3 is working with in my > local testing. > > The key bits I wanted to liaise with the ruby SIG for was the F28 > change I'm putting together to get this update in place. > > Although the application moves from ruby to c++ the ruby bindings will > still be important and relevant to the SIG. So is there some "preview" package of updated Facter? I'm literally in the middle of getting it clean etc. There's some stuff we'll need to get aligned in the spec for leatherman for instance. Working on this stuff in my evenings, lunches and commutes so it's not fast going but I think F28 is reasonable as a goal for the change. I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes. I expect an answer from upstream about the status of 2.x will help with that. I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix. I'll also include those factors in the change when I write it. I'll try and get initial test packages into COPR this week for feedback. James

2 13

A macro to build rpms/ruby without systemtap dependency
by Jun Aruga 17 Oct '17

17 Oct '17

Hello, I am working for ruby module. https://src.fedoraproject.org/modules/ruby I want a macro definition to build the ruby without systemtap rpm (+ dtrace command), such as below macro. %global with_rubypick 1 Because it is uncertainly when systemtap module will be prepared or not right now. Is it possible to update ruby.spec for that? Jun

3 6

Anyone have contacts at rubygems.org?
by Bryan Kearney 06 Oct '17

06 Oct '17

We have some gems that have been orphaned, and we would like to get "re-owned". Team members have reached out to rubygems mods but have not gotten any feedback. If you have a contact, or a suggestion on how best to approach this I would appreciate the feedback! thanks! -- bk

2 1

Fwd: [fesco] Issue #1771: Unresponsive maintainer: kanarip
by Vít Ondruch 02 Oct '17

02 Oct '17

Hi, Kanarip's packages were reassigned or orphaned. From those orphaned, I think these two should find new owner, since they are in dependency chain of some other packages: * rpms/rubygem-columnize needed by rubygem-byebug * rpms/rubygem-fattr needed by rubygem-session <= rubygem-rr Best, Vít -------- Přeposlaná zpráva -------- Předmět: [fesco] Issue #1771: Unresponsive maintainer: kanarip Datum: Sat, 30 Sep 2017 09:47:33 +0000 (UTC) Od: Till Maas <pagure(a)pagure.io> Adresa pro odpověď: reply+f99c300c5522427dece4b2dfa3b4762e6a1ba404ac95c7403fb1cd1651cccc383c190bb352ddd69c0de3c1e7ff028ffdbdf1580d2d8aa97c1dc927f2f802220b(a)pagure.io Komu: vondruch(a)redhat.com till added a new comment to an issue you are following: `` libkolabxml and libkolab went to @tpokorra and the other packages as follows: ``` Giving rpms/dh-make to sergiomb Giving rpms/facter to gchamoul Giving rpms/grib_api to jdekloe Giving rpms/jansson to jirka Giving rpms/libkolabxml to orphan Giving rpms/perl-GO-TermFinder to orphan Giving rpms/perl-Net-IMAP-Simple to orphan Giving rpms/perl-Net-IMAP-Simple-SSL to orphan Giving rpms/perl-Net-Telnet to orphan Giving rpms/perl-XML-FeedPP to orphan Giving rpms/perl-XML-TreePP to jehane Giving rpms/publican-genome to orphan Giving rpms/puppet to skottler Giving rpms/python-ldap to johnp Giving rpms/revisor to orphan Giving rpms/ris-linux to orphan Giving rpms/ruby to mmorsi Giving rpms/rubygem-arrayfields to orphan Giving rpms/rubygem-attributes to orphan Giving rpms/rubygem-builder to tdawson Giving rpms/rubygem-columnize to orphan Giving rpms/rubygem-cucumber to mmorsi Giving rpms/rubygem-facets to orphan Giving rpms/rubygem-fattr to orphan Giving rpms/rubygem-ferret to orphan Giving rpms/rubygem-gemcutter to orphan Giving rpms/rubygem-git to stevetraylen Giving rpms/rubygem-hawler to orphan Giving rpms/rubygem-highline to tdawson Giving rpms/rubygem-main to orphan Giving rpms/rubygem-markaby to orphan Giving rpms/rubygem-mocha to skottler Giving rpms/rubygem-pervasives to orphan Giving rpms/rubygem-picnic to orphan Giving rpms/rubygem-polyglot to vondruch Giving rpms/rubygem-rack to jaruga Giving rpms/rubygem-rake to vondruch Giving rpms/rubygem-restr to orphan Giving rpms/rubygem-reststop to orphan Giving rpms/rubygems to vondruch Giving rpms/rubygem-shoulda to tdawson Giving rpms/ruby-RRDtool to orphan Giving rpms/spin-kickstarts to vpavlin Giving rpms/sysklogd to orphan ``` `` To reply, visit the link below or just reply to this email https://pagure.io/fesco/issue/1771

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig October 2017