[AUR] Ruby, correction de paquet et questions

Mise à jour / Création /debug de paquetages
kissarch
newbie
Messages : 1
Inscription : dim. 30 mai 2021, 15:19

[AUR] Ruby, correction de paquet et questions

Message par kissarch »

Ce jour j'ai tenté d'installer un paquet depuis AUR : impossible: quelques fautes typographiques et des fichiers d'entête non trouvés !

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
Remplacement des typos avec un éditeur (nano, geany...):
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
et le "slash "manquant pour le bon chemin d'installation

Code : Tout sélectionner

 #-i "$pkgdir$_gemdir" \
  -i "$pkgdir/$_gemdir" \
Sans trop savoir pourquoi ni comment, on remplace "rvm" par "ruby"
(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
Relancement de makepkg

Code : Tout sélectionner

makepkg
Ça ne compilait pas en raison de fichiers d'entête en language C non trouvés...
correction de <st.h> à <ruby/st.h>
en effet, c'est dans

Code : Tout sélectionner

/usr/include/ruby
D'ailleurs c'est dans

Code : Tout sélectionner

/usr/include/ruby-3.0.0./ruby
pour ma version, passons...

En tous cas, <st.h> n'est pas dans

Code : Tout sélectionner

/usr/include
Donc on corrige
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>
et dans domain.c

Code : Tout sélectionner

$ nano .src/ruby-libvirt-0.7.1/ext/libvirt/domain.c
//#include <st.h>
#include <ruby/st.h>
(le reste pas besoin).

(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
Recherche des quelles options sont disponibles pour rake

Code : Tout sélectionner

$ rake --tasks
...
gem
package
...
On choisit package

Code : Tout sélectionner

$ rake package
Attendre, on obtient dans pkg

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
(là je ne sais plus si j'avais aussi exécuter rake gem, passons)

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
On modifie PKGBUILD pour que makepkg utilise le ruby-libvirt-0.7.1.tgz créé en local !
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)
On recrée la somme de contrôle

Code : Tout sélectionner

$ makepkg -G>>PKGBUILD
On relance

Code : Tout sélectionner

$ makepkg # or makepkg -f
Ouf, fini, nous avons notre paquet!
Eventuellement, installable par

Code : Tout sélectionner

$ sudo pacman -U ruby-libvirt-0.7.1-1-x86_64.pkg.tar.zst
Mais je n'aime pas ne pas passer par une base de données de paquet...

Par manie, pour tout revérifier, on refait ça avec cleanchrootmanager:

Code : Tout sélectionner

$ sudo ccm s
Ouf, fini, nous obtenons le même paquet, de même taille, et avec makepkg, et avec les bons réglages de ccm, il est dans notre dépôt local "custom" !

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
...
Hourra !

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.
...
J'ignore si c'est important...

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
}
Questions sur le PKGBUILD:
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 ? ...
Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10707
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [AUR] Ruby, correction de paquet et questions

Message par FoolEcho »

Salut,
kissarch a écrit : dim. 30 mai 2021, 16:48 Questions sur le PKGBUILD:
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 ? ...
Tes... questions ne sont pas très claires pour moi (la plupart ressemblent à des affirmations ou des réflexions) donc difficile d'y répondre (le PKGBUILD initial est ancien donc oui, sans aucun doute il y a des problèmes dans la forme et le fond, en disant ça j'ai rien dit...)...

J'ai surtout une observation à faire d'où découlent certainement toutes tes modifications : les dépôts officiels distinguent un paquet ruby (en version > 3.0) de ses prédécesseurs (ruby2.6 ; ruby 2.7). Dès lors... beaucoup de choses changent (un paquet dédié à gem en version 3 rubygems vs rubyX.Y pour les autres). A minima faudrait tester le PKGBUILD avec une version ruby 2 (mais dans tous les cas ça oblige à patcher les sources sans doute, soit dans le sens de la version 3 si compatible, soit dans celui de la version 2). Le meilleur choix ? Ben... tout dépend de la compatibilité...
«The following statement is not true. The previous statement is true.» :nage:
Répondre