Alexandre ZANNI

It's maybe confusing but `/home/noraj/.local/share/gem/ruby/3.0.0/` was on another machine (original post). On my previous message the user gem home is `/home/noraj/.gem/ruby/3.0.0/`. and you can see iodine is trying to load...

Also the C extension is built: ``` ➜ find /home/noraj/.gem/ruby/3.0.0 -iname 'iodine_ext*' /home/noraj/.gem/ruby/3.0.0/extensions/x86_64-linux/3.0.0/iodine-0.7.57/iodine/iodine_ext.so /home/noraj/.gem/ruby/3.0.0/gems/iodine-0.7.57/ext/iodine/iodine_ext.so ``` The require tries `gems/iodine-0.7.57/lib/iodine/iodine_ext` instead of `gems/iodine-0.7.57/ext/iodine/iodine_ext`

On asdf ruby 3.2 ``` ➜ find /home/noraj/.asdf/installs/ruby/3.2.0/ -iname 'iodine_ext*' /home/noraj/.asdf/installs/ruby/3.2.0/lib/ruby/gems/3.2.0/extensions/x86_64-linux/3.2.0/iodine-0.7.57/iodine/iodine_ext.so /home/noraj/.asdf/installs/ruby/3.2.0/lib/ruby/gems/3.2.0/gems/iodine-0.7.57/lib/iodine/iodine_ext.so ``` So in asdf ruby 3.2 tt's put in `lib` while in system ruby with user install 3.0...

Interestingly with asdf ruby 3.1.0 there is the extension on both lib and ext: ``` ➜ find /home/noraj/.asdf/installs/ruby/3.1.0/ -iname 'iodine_ext*' /home/noraj/.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/extensions/x86_64-linux/3.1.0/iodine-0.7.57/iodine/iodine_ext.so /home/noraj/.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/iodine-0.7.57/ext/iodine/iodine_ext.so /home/noraj/.asdf/installs/ruby/3.1.0/lib/ruby/gems/3.1.0/gems/iodine-0.7.57/lib/iodine/iodine_ext.so ```

Ruby source | Ruby version | ext build | work | install as --- | --- | --- | --- | --- ASDF | 3.2.0 | `lib` | ✅ |...

Ok found the issue, it related to ArchLinux build. There is a patch to disable to copy of the .so from `ext` to `lib`: https://gitlab.archlinux.org/archlinux/packaging/packages/rubygems/-/blob/main/rubygems_stop_so_duplication.patch?ref_type=heads Upstream issue https://bugs.archlinux.org/task/70959

[Porting themes to Plasma 6](https://develop.kde.org/docs/plasma/theme/theme-porting-to-plasma6/)

@solardiz What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen? Also, in the light of #4564 and #5255 and many others,...

@solardiz You mean that some major changes where not documented into [NEWS](https://github.com/openwall/john/blob/bleeding-jumbo/doc/NEWS)? How could I help?

Another bug already been fixed on bleeding jumbo ``` ➜ ssh2john ~/.ssh/id_ed25519_crack Traceback (most recent call last): File "/usr/bin/ssh2john", line 194, in read_private_key(filename) File "/usr/bin/ssh2john", line 154, in read_private_key saltstr...