- openSUSE Ruby

The great rubygem cleanup of 2023/2024
by Dan Čermák 17 Nov '23

17 Nov '23

Dear list, as indicated by $subject, I intend to start cleaning up our rubygem rpm packages. The development project devel:languages:ruby:extensions grew over the past decade into a huge mess with far too many outdated, no longer building, uninstallable and downright broken rpms. This causes a lot of strain on OBS as it rebuilds many unusable packages and for us to keep packages building for questionable benefit. We (=the ruby team, at this point that is darix and myself) cannot maintain the current state anymore. Therefore I plan to execute the following two phase plan. Phase I - December 2023 ----------------------- Delete all packages from d:l:r:e that are not linked into another project and that do not have a maintainer set (the project wide maintainer does not count). If you depend on a gem that is in d:l:r:e *only* and *not* in Factory, please take over maintenance of it and consider sending it to Factory. Phase II - January 2024 ----------------------- We will start deleting leaf packages in Factory that originate in d:l:r:e and have no package maintainer set. If you are depending on a rubygem being available as an rpm, then please take over maintenance for it. Otherwise there is a certain risk that it will be gone from Tumbleweed. Thank you for your understanding, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)

1 0

Re: Plan to delete vagrant & Virtualization:vagrant by the end of November
by Dan Čermák 15 Nov '23

15 Nov '23

Hi Dominique, Dominique Leuenberger <dimstar(a)opensuse.org> writes: > On Fri, 2023-11-03 at 11:07 +0100, Dan Čermák via openSUSE Factory > wrote: >> Dear all, >> >> due to Hashicorp changing the license of vagrant to the BUSL, we can >> no >> longer update vagrant in openSUSE. I don't have the cycles to >> maintain >> vagrant myself indefinitely and plan to send a delete request at the >> end >> of November to Factory. Once that goes in, I also plan to remove the >> Virtualization:vagrant project to reduce the number of rubygems we >> have >> in openSUSE. >> >> If you don't like this plan and decide to scream at me, please scream >> an >> actionable plan that involves you :-) > > > I like thet plan - BUT please first disarm the openQA tests for > vagrant. If we're already planning on dropping it, we should stop > testing it at least beforehand. This actually brings up another issue, we use vagrant to test our opensuse vagrant boxes. But without vagrant in the distro, we'll have a hard time testing the boxes. The only simple way that I see is to install vagrant from the upstream provided binary: https://developer.hashicorp.com/vagrant/install?product_intent=vagrant Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)

1 0

Plan to delete vagrant & Virtualization:vagrant by the end of November
by Dan Čermák 03 Nov '23

03 Nov '23

Dear all, due to Hashicorp changing the license of vagrant to the BUSL, we can no longer update vagrant in openSUSE. I don't have the cycles to maintain vagrant myself indefinitely and plan to send a delete request at the end of November to Factory. Once that goes in, I also plan to remove the Virtualization:vagrant project to reduce the number of rubygems we have in openSUSE. If you don't like this plan and decide to scream at me, please scream an actionable plan that involves you :-) Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)

1 0

Cleanup of devel:languages:ruby:extensions
by Dan Čermák 27 Aug '21

27 Aug '21

Hi list, I would like to run a bit of a cleanup in devel:languages:ruby:extensions and get rid of all the old and unmaintained gems that keep rotting in there. The following packages are either unresolvable or are consistently failing to build and haven't been touched for a few years (comments for some that I checked in more details are in parenthesis): - ruby-gnome2-all - rubygem-ar_fixtures - rubygem-aws (officially deprecated upstream) - rubygem-baretest - rubygem-bcodec - rubygem-bdb - rubygem-better_nested_set (maintainer MIA) - rubygem-bloomfilter - rubygem-bzip2-ruby (title says it's not compatible with Ruby 2.1) - rubygem-campaign_monitor - rubygem-campaign_monitor_party - rubygem-capybara-webkit (depends on qt4) - rubygem-capybara-webkit-0 (depends on qt4) - rubygem-cgi_multipart_eof_fix (upstream gone) - rubygem-chardet - rubygem-chef-solr - rubygem-compass-rails-1_0 - rubygem-couch_tomato (upstream gone) - rubygem-curb-0_7 - rubygem-dbd-mysql - rubygem-dbd-pg - rubygem-dep-selector-libgecode - rubygem-dep_selector-0_1 - rubygem-dep_selector - rubygem-dm-do-adapter - rubygem-dm-migrations - rubygem-dm-observer - rubygem-dm-oracle-adapter - rubygem-dm-sqlite-adapter - rubygem-dm-timestamps - rubygem-dm-transactions - rubygem-dm-validations - rubygem-dust - rubygem-dynamic_form - rubygem-dynect4r - rubygem-em-http-request-0_2 (this one is probably just incompatible with ruby 3.0) - rubygem-escape - rubygem-exception_notification-1_0 - rubygem-extjs-mvc - rubygem-ezcrypto - rubygem-fastri - rubygem-fastthread - rubygem-fusefs (ftbfs on TW due to stricter compiler policies, might be fixable) - rubygem-gemcutter - rubygem-git-gitlab - rubygem-grpc - rubygem-gtk2 (depends on rubygem-pango, which ftbfs) - rubygem-haml-4 - rubygem-has_alter_ego - rubygem-html5 - rubygem-htmldiff - rubygem-i18n-0_4 - rubygem-ini - rubygem-jabber4r - rubygem-johnson - rubygem-jrails - rubygem-kiwi_diff - rubygem-language_detector - rubygem-librex - rubygem-libxslt-ruby - rubygem-linecache - rubygem-linecache19 - rubygem-luck - rubygem-mailtrap - rubygem-memcached - rubygem-memprof - rubygem-merb-extjs-direct - rubygem-meta_programming - rubygem-metaid - rubygem-method_source-0_7 - rubygem-migration_test_helper - rubygem-mkrf - rubygem-mongo-dequeue (dead upstream) - rubygem-mutter - rubygem-mysql (C bindings don't work with MySQL any more) - rubygem-mysql2-0.4 (ftbfs, new version available as rubygem-msql2) - rubygem-mysqlplus - rubygem-neo4jr-simple - rubygem-neo4jr-social - rubygem-nokogiri-1_6 (newer version available) - rubygem-nokogiri-1_7 - rubygem-oci8 - rubygem-packet - rubygem-pango (appears to depend on an old pango) - rubygem-perftools.rb - rubygem-pidfile - rubygem-polkit - rubygem-polkit1 - rubygem-pr_geohash (maintainer MIA) - rubygem-prawn-flexible-table - rubygem-prawn-format - rubygem-prawn-js - rubygem-prawn-layout - rubygem-prawn-security - rubygem-public_suffix_service - rubygem-pygments.rb-0_3 - rubygem-pyu-ruby-sasl - rubygem-qtbindings (depends on qt4) - rubygem-rails-extjs-direct - rubygem-rbot - rbx-require-relative - rubygem-rcov_rails - rubygem-rdoc-data - rubygem-redgreen - rubygem-resource_controller - rubygem-rev - rubygem-rflickr - rubygem-ri_cal - rubygem-riakrest - rubygem-ruby-debug - rubygem-ruby-debug-base - rubygem-ruby-debug-base19 - rubygem-ruby-hmac - rubygem-ruby-openid-apps-discovery - rubygem-ruby-rpm - rubygem-ruby-shadow - rubygem-ruby-yadis - rubygem-ruby_core_source - rubygem-rubytorrent - rubygem-safemode-1.0 - rubygem-scrypt-1 - rubygem-selenium-rails - rubygem-sexp - rubygem-spawn - rubygem-starfish - rubygem-static_record_cache - rubygem-SystemTimer - rubygem-test-spec - rubygem-testunitxml - rubygem-therubyracer - rubygem-thor-0_15 - rubygem-thrift - rubygem-tidy - rubygem-timeline_fu - rubygem-tlattr_accessors - rubygem-tmail - rubygem-tokyocabinet - rubygem-tuple - rubygem-url_mount - rubygem-validatable - rubygem-vikinggem - rubygem-virtualbox - rubygem-vote_fu - rubygem-waxeye - rubygem-websocket-rack - rubygem-wirble - rubygem-wkhtmltopdf-binary - rubygem-zmq Unless anyone objects, I will delete these packages in two weeks. If you decide to save one of these, please reply to this email, so that I remove them from the kill-list. We also have quite a few uninstallable packages in the project, which are imho also not very useful. I would tackle these in the second kill round once we got the number of build failures down. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

2 3

Coordinate Rubygem updates
by Dan Čermák 22 Jan '21

22 Jan '21

Hi list, can we please in the future try to coordinate rubygem updates before a mass submission to Factory? Coolo's mass update from a few days ago that was immediately submitted to Factory broke vagrant's dependencies and was not realized after the fact. I would appreciate getting a heads up and more than a few hours to fix any issues that pop up. Thanks, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

1 0

Rubygem plugin changes with rubygems >= 3.2
by Dan Čermák 08 Jan '21

08 Jan '21

Hi list, rubygems changed how and where plugins are installed, mostly for speeding up the loading of the gems [1]. Plugins are now installed as %{name}_plugin.rb into %gem_base/plugins/. This is a problem, as our current ruby packaging does not account for that and this broke the build of yard[2]. Any ideas how this can be addressed? Fedora solved this problem when rebasing to ruby 3.0 rather easily: https://src.fedoraproject.org/rpms/ruby/pull-request/76#request_diff But we cannot use their fix as it is, because we autogenerate the file lists, so we'll have to add some version check to the generator? I am honestly not really familiar with the inner workings of our gem2rpm fork or where to add it. But I need to fix this, as rubygem-yard is now consistently failing to build (and I don't consider turning ruby 3.0 off as a good way how to address this). Cheers, Dan Footnotes: [1] https://github.com/rubygems/rubygems/pull/3108 [2] https://build.opensuse.org/package/live_build_log/devel:languages:ruby:exte… -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

2 1

[opensuse-ruby] Packaging OpenProject (a fork of Redmine/ChiliProject)
by Matthew Trescott 03 Aug '20

03 Aug '20

Hello all, I've been working for a while on packaging OpenProject (openproject.org), which is a very interesting fork of Redmine. I've been putting my packages here: https://build.opensuse.org/project/show/home:matthewtrescott:openproject As you can see, there are quite a lot of Ruby gem dependencies that I needed to package as well. Most of them were easy enough with gem2rpm though. I'd like to contribute my package to Factory eventually but there are so many packages... I just don't know where to begin. Should I start making OBS submitrequests to devel:languages:ruby:extensions for all those dependencies? I'm also not really sure where the main openproject package belongs—maybe devel:tools:scm? The potential sticky spot I can imagine with getting it accepted in Factory is the Node.js "dependency pack" (I archived the result of npm12 install). I think there is maybe a precompiled binary or two in there, which is not ideal. On the other hand, I can't imagine packaging all those dependencies just to be able to compile OpenProject's CSS and JavaScript. I was hoping to get some early feedback on these packages and suggestions for what I could improve. I know I still need to test certain things like memcached, remote databases, and non-standard sockets for Puma to listen on (currently I have a systemd socket unit with a hardcoded path). Thanks! Matthew Trescott -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

2 2

[opensuse-ruby] Duplicate packages rubygem-progressbar and rubygem-ruby-progressbar
by Dan Cermak 10 Sep '19

10 Sep '19

Hi list, when collecting the dependencies of rubocop for a submission to Factory, I've found out that we have a duplicate gem: ruby-progressbar exists as rubygem-progressbar and rubygem-ruby-progressbar. If I haven't messed up the repoquery, then the following packages depend on rubygem-ruby-progressbar: - rubygem-fuubar - rubygem-rubocop - rubygem-minitest-reporters - rubygem-rails_best_practices In contrast to rubygem-dister which appears to be the only package depending on rubygem-progressbar. I would therefore propose to patch rubygem-dister so that it's dependencies are correct and subsequently delete rubygem-progressbar. Any objections/suggestion/ideas? Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 247165, AG München) Managing Director: Felix Imendörffer

3 3

[opensuse-ruby] Ruby cleanup part 1
by Marcus Rückert 14 Feb '18

14 Feb '18

There is a lot of old and unused packages in Leap as well as in TW. As leap is close to a release i started the cleanup there. I wrote a script that based on the primaries.xml gave me a list of all rubygem-* packages which are not used by anything. Based on that list I created a bunch of delete requests. You can see the list with this commandline. osc rq list --non-interactive -t delete \ --target-package-filter='rubygem.*' \ openSUSE:Leap:15.0 If you want to keep any of the rubygem-* packages please comment in the request or here. Once we cleaned up Leap 15.0 we will clean up TW. With kind regards, darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

4 5

[opensuse-ruby] Dropping ruby 2.2 from DLR(E)?
by Marcus Rückert 07 Nov '17

07 Nov '17

any objections? 2.3 I just started checking if gitlab-ce works with it now. If it works ... we could drop that as well. I would keep 2.1 until SLE is EOL. If we dont want to delete the packages from DLR. i would at least disable them all for TW. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

1 0