Voici les corrections faites, si ça peut aider quelqu'un pour la méthode. Puis les questions...
Installation manuelle:
Code : Tout sélectionner
$ cd ~/.cache/yay/ruby-libvirt
$ nano PKGBUILD
le "r" manquant : "require rubygems"
Code : Tout sélectionner
#local _gemdir="$(ruby -rubygems -e 'puts Gem.default_dir')"
local _gemdir="$(ruby -rrubygems -e 'puts Gem.default_dir')"
# gives local _gemdir=/usr/lib/ruby/gems/3.0.0
Code : Tout sélectionner
#-i "$pkgdir$_gemdir" \
-i "$pkgdir/$_gemdir" \
(pour ne pas avoir à installer "rvm", qui d'ailleurs est en conflit avec "ruby")
Code : Tout sélectionner
#rvm use system 2>/dev/null || true
ruby use system 2>/dev/null || true
Code : Tout sélectionner
makepkg
correction de <st.h> à <ruby/st.h>
en effet, c'est dans
Code : Tout sélectionner
/usr/include/ruby
Code : Tout sélectionner
/usr/include/ruby-3.0.0./ruby
En tous cas, <st.h> n'est pas dans
Code : Tout sélectionner
/usr/include
dans common.c
Code : Tout sélectionner
$ nano src/ruby-libvirt-0.7.1/ext/libvirt/common.c
//#include <st.h>
#include <ruby/st.h>
Code : Tout sélectionner
$ nano .src/ruby-libvirt-0.7.1/ext/libvirt/domain.c
//#include <st.h>
#include <ruby/st.h>
(là étape utile ? vraiment pas sûr, parti du principe que ne recompilera pas libvirt.o si c'est déjà compilé)
(rake ou makepkg n'y toucheront pas si c'est compilé et à jour ?! Tentative...)
aller dans le répertoire ext/libvirt et utiliser make,
car la première exécution de yay ou makepkg a lancé rake qui a créé les Makefile
Code : Tout sélectionner
$ cd src/ruby-libvirt-0.7.1/ext/libvirt/
$ make
$ cd ../.. # returns to src/ruby-libvirt-0.7.1
Code : Tout sélectionner
$ rake --tasks
...
gem
package
...
Code : Tout sélectionner
$ rake package
Code : Tout sélectionner
$ ls src/ruby-libvirt-0.7.1/pkg
ruby-libvirt-0.7.1
ruby-libvirt-0.7.1.gem
ruby-libvirt-0.7.1.tgz
ruby-libvirt-0.7.1.zip
Enfin: nous avons les bonnes sources pour créer le paquet archlinux !
On copie ou déplace ruby-libvirt-0.7.1.tgz dans ~/.cache/yay/ruby-libvirt
Code : Tout sélectionner
$ cp ~/.cache/yay/ruby-libvirt/src/ruby-libvirt-0.7.1/pkg/ruby-libvirt-0.7.1.tgz ~/.cache/yay/ruby-libvirt
Et on efface ou remplace ou remplace la somme de contrôle, maintenant erronnée
Code : Tout sélectionner
#source=(http://libvirt.org/ruby/download/$pkgname-$pkgver.tgz)
source=(file://$pkgname-$pkgver.tgz) # we want to use the create one, not to redownload the "bad" one !
# sha256sums(blablabla)
Code : Tout sélectionner
$ makepkg -G>>PKGBUILD
Code : Tout sélectionner
$ makepkg # or makepkg -f
Eventuellement, installable par
Code : Tout sélectionner
$ sudo pacman -U ruby-libvirt-0.7.1-1-x86_64.pkg.tar.zst
Par manie, pour tout revérifier, on refait ça avec cleanchrootmanager:
Code : Tout sélectionner
$ sudo ccm s
On met à jour les dépôts pour que qu'il soit dans "custom" :
(c'est un paquet AUR donc là pas de pacman)
Code : Tout sélectionner
$ yay -Syy
$ yay ruby-libvirt
2 aur/ruby-libvirt 0.7.1-1 (+10 0.00)
Ruby bindings for libvirt.
1 custom/ruby-libvirt 0.7.1-1 (492.1 KiB 2.4 MiB)
Ruby bindings for libvirt
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 1
...
Au passage, nous avons un vrai paquet dans "custom", yay nous donne la taille, un précédent essai raté avait donner un paquet de 2.4 k, vide !
ccm a lancé namcap, qui répond:
Code : Tout sélectionner
...
ruby-libvirt W: ELF file ('usr/lib/ruby/gems/3.0.0/gems/ruby-libvirt-0.7.1/ext/libvirt/connect.o') lacks FULL RELRO, check LDFLAGS.
...
ruby-libvirt W: ELF file ('usr/lib/ruby/gems/3.0.0/gems/ruby-libvirt-0.7.1/ext/libvirt/connect.o') is unstripped.
...
ruby-libvirt W: ELF file ('usr/lib/ruby/gems/3.0.0/gems/ruby-libvirt-0.7.1/ext/libvirt/connect.o') lacks PIE.
...
Pas besoin d'aller plus loin, installer et voir si ça marche... installé ainsi, si ça ne marche pas, pacman ou yay permettrons de mettre à jour très facilement ou de désinstaller proprement... ce qui est leur but, et mérite de mettre le nez dans les PKGBUILD !
Observations sur le PKGBUILD:
Il semble que les typographies font que "gem install" ne trouve pas ruby-libvirt-1.7.0.gemdans /src/ruby-libvirt-1.7.0/pkg : et alors il le télécharge systématiquement en ligne: et donc le ruby-libvirt-1.7.0.gem contenant #include <st.h> est utilisé, il refuse d'installer et compiler car non trouvé...
Proposition:
et ça fait le boulot décrit ci-dessus, (sauf les typos et les messages de namcap pour relro, etc) : avant package, un prepare pour patcher les sources, car le problème de chemin vers<st.h> est peut-être spécifique à la distribution (?)
ou bien une directiver pour donner le bon chemin de <st.h> à rake ? pas trouvé comment !
et/ou éviter les messages de namcap:
Code : Tout sélectionner
prepare() {
cd $pkgname-$pkgver
# patches because error compiling !
sed -e 's|#include <st.h>|#include <ruby/st.h>|' \
-i ext/libvirt/common.c
sed -e 's|#include <st.h>|#include <ruby/st.h>|' \
-i ext/libvirt/domain.c
# untested : or there is a diff : use as a patch ? here:
#"https://build.opensuse.org/package/view_file/openSUSE:Factory/rubygem-ruby-libvirt/0001-Fix-include-of-st.h-to-ruby-st.h.patch"
#or -I /usr/include/ruby-3.0.0./ruby
# Modify le Rakefile ?
# seem unefficient to avoid namcap messages ! (retry)
#sed -e 's|extra=""|extra="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now,-z,pie,-I/usr/include/ruby"|' \
# or ??
#sed -e 's|extra=""|extra="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now,-z,pie,-D/usr/include/ruby"|' \
# -i Rakefile
}
Confusion : le répertoire de construction (build) de rake (ou gem ?) semble s'appeler pkg, mais est dans le sous-dossier src/$pkgname-$pkgver, à ne pas confondre avec le répertoire pkg d'installation en fakeroot avant création du paquet... passons...
Ici, utiliser le gem à téléchargé est inutile en raison de <st.h> ... ? Essayé mais ça refuse de l'installer pour cette raison... On aimerai que ça s'installe quand même via package(), puis patcher à ce moment là (la seule chose importante à corriger semblant être <st.h> pour <ruby/st.h> ... ?
Il semble difficile ou impossible d'utiliser le gem directement, car c'est une archive tar compressée, qui laisse 2 ou 3 archives tar compressées dans src : data.tar.gz, metadata.tar.gz, +/- checksums.yaml.gz...
Utiliser gem dans pacman (ou yay) est-elle une mauvaise idée ? On télécharge avec somme de contrôle des sources ou un paquet générique pour créer un paquet archlinux, et ça re-télécharger la même chose dans le sous-dossier pkg du dossier source ? La blague ? ...