Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#76004 - [ruby-psych] Psych::BadAlias: Unknown alias: base

Attached to Project: Community Packages
Opened by Hamish Claxton (Verequies) - Sunday, 25 September 2022, 03:49 GMT
Task Type Bug Report
Category Packages: Testing
Status Assigned
Assigned To Andreas Schleifer (Segaja)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

All ruby packages up to date with testing.
I receive the following error:

'Psych::BadAlias: Unknown alias: base'

Previously working with the ruby package versions as attached.
It seems something broke during the stdlib restructuring.
This task depends upon

Comment by Andreas Schleifer (Segaja) - Sunday, 25 September 2022, 10:31 GMT
Hi, do you happen to have a small code example of how to reproduce the issue?
Comment by Hamish Claxton (Verequies) - Sunday, 25 September 2022, 21:18 GMT
I have just been testing by installing GitLab from source.
The attached script should replicate the issue (tested just before).
You can retest after the first time you run the script by running `bundle exec rake db:migrate RAILS_ENV=production` inside the GitLab folder.
Comment by Hamish Claxton (Verequies) - Tuesday, 27 September 2022, 00:04 GMT
Attaching an error log if it helps.
Generated with `bundle exec rake db:migrate RAILS_ENV=production --trace`
Comment by Andreas Schleifer (Segaja) - Wednesday, 28 September 2022, 17:45 GMT
After some research I found out that the stdlib gem versions shipped with ruby 3.0.4 use psych 3.3.2 and after my de-vendoring work the version 4.0.4 of ruby-psych is now "seen". This leads us to https://bugs.ruby-lang.org/issues/17866 . So far it seems https://rubygems.org/gems/settingslogic version 2.0.9 is not compatible with this breaking change of psych.

There is already work being done on the issue in the settingslogic repository: https://github.com/binarylogic/settingslogic/pull/86


I keep investigating but I fear all we can do is patch code or push upstream gem maintainers to fix the issues.
Comment by Hamish Claxton (Verequies) - Thursday, 29 September 2022, 02:32 GMT
Thanks for doing that research. Its noted on that repositories README that the repository has moved to https://github.com/settingslogic/settingslogic .
I was able to get GitLab to install successfully by editing the Gemfile, and changing the settingslogic dependency to use this pull request 'https://github.com/settingslogic/settingslogic/pull/22'.
Hopefully GitLab notices this soon and updates their dependencies.

So I guess in the end there is no issue with the ruby-psych gem and older gems just require updating to be compatible.
That being said, if Ruby 3.1 bundles Psych 4 should we not update Ruby to 3.1 as its currently sitting at 3.0.4?
Comment by Andreas Schleifer (Segaja) - Thursday, 29 September 2022, 07:05 GMT
Thanks for that hint. I subscribed now to some issues and PRs on the new repo aswell.

We plan to update to ruby 3.1 once the de-vendoring is fully done.
Comment by Andreas Schleifer (Segaja) - Saturday, 01 October 2022, 11:48 GMT
I found out that both the original repository for the gem and the fork of it have not seen any update for the past 8+ years.

I got in contact with a friend of mine who works as SRE at gitlab and forwarded him our issue and what impact it has for gitlab to be compatible to with 3.1 or more precise with psych > 4.0.0. He told me he will forward my concern and is confident there will be a solution soon.

Sadly this still means I can't push my 47 ruby packages changes i have waiting in [community-testing] to [community] as it would break gitlab.
Comment by Hamish Claxton (Verequies) - Sunday, 02 October 2022, 00:32 GMT
Thanks for doing that, hopefully we will see the solution shortly then.
Regarding your 47 ruby package updates. I think you should push them.
The GitLab packages in Arch Linux depend on Ruby 2.7 so it should be safe to update without any issue.
I install GitLab from source personally, so I use Ruby 3.0.4.

That being said, GitLab does work with Ruby 3.0.4 from my testing so you could remove the dependency on Ruby 2.7 by updating that package too.
You would just need to edit the Gemfile like so:
'sed -i "s/gem 'settingslogic', '~> 2.0.9'/gem 'settingslogic', git: 'https:\/\/github.com\/Verequies\/settingslogic'/" Gemfile'
'bundle lock --update=bundler-audit'

And everything should work with Ruby 3.0.4 and your package changes, and hopefully Ruby 3.1 when you update to that too.
As you can see from the repository I ended up forking the working pull request repository just in case the repository was deleted.

EDIT: Forgot to mention installing GitLab from source using the current community (non-testing) packages was broken to begin with as well.
Comment by Andreas Schleifer (Segaja) - Wednesday, 05 October 2022, 21:39 GMT
I moved all the ruby changes to [community]. Not sure when we want to close this bug ticket.
Comment by Hamish Claxton (Verequies) - Thursday, 06 October 2022, 00:32 GMT
Okay cool, well I think after the Arch Linux GitLab packages have been updated to use Ruby 3.0.4/3.1 and incorporate this workaround, this ticket can probably be closed.
Once updated, it would also leave just Redmine left to be switched to Ruby 3.0.4/3.1 - and from a quick look up online, it is already compatible.
That would mean the Ruby2.7 package could be removed as nothing depends on it?

Loading...