March 23, 2023

Maintaining my micromount database

These are notes for myself primarily. My micromount database is a ruby application that runs on a linux computer. The application uses a variety of ruby packages, including gtk3 and sqlite3.

I run Fedora, and ruby packages are always a problem. Do we get them from the Fedora package system, or via the ruby gem system?

Busted as of 8-4-2021

I haven't run the database for a while, have upgraded to the latest Fedora (which is Fedora 34 as of August, 2021) and I get the following when I try to start the application: 

Ignoring atk-3.4.3 because its extensions are not built. Try: gem pristine atk --version 3.4.3
Ignoring glib2-3.4.3 because its extensions are not built. Try: gem pristine glib2 --version 3.4.3
Ignoring sqlite3-1.4.2 because its extensions are not built. Try: gem pristine sqlite3 --version 1.4.2
I get a lot of other chatter too, but the crucial issue seems to be that it cannot find the sqlite3 package. Indeed, if I just fire up ruby and type "require sqlite3" I get the same errors. Fedora does offer a package "rubygem-sqlite3.x86_64". I install it using the command 
su
dnf install rubygem-sqlite3
But I continue to get the same error. I decide to take the hint given in the error and try: 
su
gem pristine atk --version 3.4.3
gem pristine glib2 --version 3.4.3
gem pristine sqlite3 --version 1.4.2
This does not work (it says if "Failed to find gems").

So I try doing it as a plain old user (myself) and it works: 

gem pristine atk --version 3.4.3
gem pristine glib2 --version 3.4.3
gem pristine sqlite3 --version 1.4.2
Who knows why this kind of crap is necessary. Python is not better with multiple versions of python and utter confusion about packages and python versions. There is only one answer. Shoot the developers! We don't want slick new versions that cause trouble, we want old crusty versions that work.

Here we go again 3-22-2023

This sort of thing makes me contemplate moving to Python. Or maybe just compiled C -- it honestly would be less work to maintain a compiled C application. Python has its own similar problems, but not as bad or as frequent as ruby.

As per notes above, the first thing is to do the following as user "tom": 

gem pristine atk --version 3.4.3
gem pristine glib2 --version 3.4.3
gem pristine sqlite3 --version 1.4.2
And that does it! Well, that was only 5 minutes of work -- there were a bunch of other frightening errors related to sqlite3, but they are apparently all fixed by doing the "gem pristine" thing.

Here we go again 5-30-2023

Pretty much the same game as before. The crucial gem is sqlite3. I'm not even sure what "atk" is. Attempting the "gem pristine glib2 --version 3.4.3" now blows up with a bunch of compile errors. This is clearly not my problem, and curiously it doesn't matter. I can now type "micros" and my application runs just fine. Perhaps there is an unnecessary dependency on glib2?

But I can't leave well enough alone. I do this: 

su
gem uninstall glib2
gem install glib2
The uninstall gets rid of 3.3.6, the install gives me 4.1.6. I get warned that atk and cairo depend on glib2. Note that there is confusion between packages installed by Fedora, gems installed by root, and gems installed by tom. I am still getting a warning about glib2-3.4.3, which apparently is installed by "tom". When I try (as tom) to uninstall glib2, I get the error "You don't have write permissions for the /usr/share/gems directory". This would seem to be a bug. I am feeling cranky, so I do this as "tom" 
rm -rf /home/tom/.gem
And now my database starts up just fine, and without warning. On with the show.

And again 7-20-2024

I swear, I am going to rewrite this whole thing in Python. Ruby, as much as I like it, is too unstable and flaky. Never mind rails, that nightmare was over years ago and I still feel the pain, but the ruby gem thing is now fundamentally broken. 
gem list --local
ERROR:  Loading command: list (LoadError)
libruby.so.3.2: cannot open shared object file: No such file or directory - /usr/local/lib64/gems/ruby/io-wait-0.3.1/io/wait.so
I get errors like this, all from libruby and unable to find various files. Or so it claims -- actually the files are all there in /usr/local.

I am running Fedora 40 and ruby 3.3.4. It looks like what is missing is libruby.so.3.2. My system has /usr/lib64/libruby.so.3.3 and 3.3.4.

So, I tried uninstalling and reinstalling "gem", now let's get more brutal. 

su
cd /usr/local/lib64
mv gems gems_BOGUS
This seems beneficial. I still get errors when I run "gem", but different more sensible errors.
Now I can run "gem update" (not as root) and get: 
mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.
Gem files will remain installed in /u1/home/tom/.local/share/gem/ruby/gems/strscan-3.1.0 for inspection.

Indeed, I do 

su
dnf install ruby-devel
After this I try "gem update" (not as root) once again. This looks better.

My guess is that the issue here is a possible 3 way confict between how gems may be installed. Once is via the fedora package system (bad, except for "gem" itself). The other is for gems installed as root (either do this always or install as a specific user always). The last is gems installed as a specific user. I will try to always install gems as user "tom".

I still cannot start "micros", but get more sensible errors (I think), such as: 

Ignoring atk-4.2.0 because its extensions are not built. Try: gem pristine atk --version 4.2.0
Ignoring bigdecimal-3.1.6 because its extensions are not built. Try: gem pristine bigdecimal --version 3.1.6
Ignoring date-3.3.4 because its extensions are not built. Try: gem pristine date --version 3.3.4
I try to do as it says, trying: 
gem pristine atk
gem pristine atk --version 4.2.0
gem install atk
The last of the above seems to work, although I still get complaints. Along the way, I get this notification -- which I will ignore since I installed "gem" from the fedora package system. 
A new release of RubyGems is available: 3.5.11 → 3.5.16!
Run `gem update --system 3.5.16` to update your installation.

A maze of twisty passages, all alike

I try a bunch of "gem update" commands, but it is not clear that this is converging. So I decide to again get brutal: 
cd /home/tom
mv .local .local_BOGUS
Again, things seem to be going nowhere. I can "gem install gtk3", but then when I try to run "micros", I still get (at the end of a long list of errors): 
in `require': cannot load such file -- gtk3 (LoadError)
So, this is all totally broken. Maybe I am forced to rewrite this code in Python.
I look at it, and it is "only" 2036 lines of Ruby. It only has 2 gem dependencies (gtk3 and sqlite3)

Before I resort to that, more brutality: 

su
cd /usr/local/share
mv gems gems_BOGUS
exit
gem list --no-version | xargs gem uninstall -aIx
This leads simply to more confusion and grief.
Feedback? Questions? Drop me a line!

Tom's Mineralogy Info / tom@mmto.org