Bonjour,

Suite aux échanges sur irc, je vous propose le paquet (premier de deux) pour bumblebee afin de faire fonctionner Optimus sur notre chère Fedora.

N'hésitez pas à donner vos avis.

Résumé du test : Test OK.
Résumé de la description : Enable Nvidia Optimus (on demand) for laptops
URL Spec : http://downloads.aelys-info.net/fedora/16/sources/SPECS/bumblebee.spec
URL SRPM : http://downloads.aelys-info.net/fedora/16/sources/SRPMS/bumblebee-3.0-2.fc16.src.rpm
Description : Bumblebee is a effort to make Nvidia Optimus enabled laptops work in GNU/Linux systems. Such feature involves two graphics cards with two different power consumption profiles plugged in a layered way sharing a single frame buffer.
Tu peux virer les BuildRequires superflus suivants :
  • glib2 (déjà requis par glib2-devel et pkgconfig) ;
  • libX11 et libX11-devel (déjà requis par mesa-libGL-devel) ;
  • libbsd (déjà requis par libbsd-devel)
  • pkgconfig (déjà requis par systemd-units, mesa-libGL-devel, glib2-devel et libbsd-devel).
Plus généralement, si un paquet nécessite le paquet paquet-devel, il requerra nécessairement paquet.
Tu peux également retirer kernel-headers, il est requis par gcc qui fait partie des BuildRequires implicites :
http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

Est-ce le second paquet que tu as prévu de soumettre ?
Requires:       bumblebee-akmod-nvidia
Tire profit des macros fournies par rpm pour faciliter la maintenance de ton paquet ; par exemple :
  • %{name} correspond au nom du paquet, défini dans le champ « Name » de ton .spec ;
  • %{version} correspond à sa version.
Tu peux donc remplacer « bumblebee » et « 3.0 » par respectivement « %{name} » et « %{version} » autant que possible dans ton .spec, comme dans le champ « Source0 » :
Source0:        http://github.com/downloads/Bumblebee-Project/Bumblebee/%{name}-%{version}.tar.gz
En cas de mise à jour de Bumblebee, tu n'aurais qu'à modifier le champ « Version » au lieu de corriger toutes les occurrences de « 3.0 ».

Tu peux virer le nettoyage du BuildRoot dans %install (« rm -rf $RPM_BUILD_ROOT ») :
http://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag

Dans la section %files :
%files

%config(noreplace) %{_sysconfdir}/bash_completion.d/bumblebee
J'imagine que le premier fichier de la liste fournit le support de l'auto-complétion pour bash. La macro %config marque un fichier comme fichier de configuration, susceptible donc d'être modifié par l'utilisateur. « (noreplace) » permet d'éviter à rpm d'écraser ce fichier (et ses éventuelles modifications) en cas de mise à jour du paquet. Un fichier d'auto-complétion n'a pas vocation à être modifié, ça n'est même pas un fichier de conf. Tu peux donc virer %config(noreplace) devant son chemin. J'imagine que rpmlint t'a suggéré cette modification... À tort.
Je ne connais pas la fonction des fichiers %config suivants, mais je t'invite à réfléchir également à la pertinence de les marquer en %config.

Toujours dans %files :
%doc %{_datadir}/doc/bumblebee/RELEASE_NOTES_3_0
Remplace d'une part %{_datadir}/doc par %{_docdir}.
D'autre part, la macro %doc permet de marquer un fichier en tant que documentation ; de tels fichiers pourront être listés à partir de ton paquet grâce à l'option « -d » de rpm ; exemple :
$ rpm -qd gnome-shell
/usr/share/doc/gnome-shell-3.2.2.1/COPYING
/usr/share/doc/gnome-shell-3.2.2.1/README
/usr/share/man/man1/gnome-shell.1.gz
Tout fichier installé dans %{_mandir} ou %{_docdir} est automatiquement taggé comme documentation ; la macro %doc devant le chemin de RELEASE_NOTES_3_0 est donc inutile. Au passage, le chemin %{_docdir}/bumblebee/ ne me paraît pas très canonique, %{_docdir}/%{name}-%{version}/ est plus dans les usages Fedora. Vois si tu ne peux pas modifier le chemin d'installation de la doc. (en passant l'option --docdir=chemin dans ./configure si possible).

Je te suggère de jeter un œil à ceci pour le support SystemD :
https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Systemd
Fichiers mis à jour.

Par contre, comme tu me le dis, rpmlint me ressort des warnings.
[builder@spartacus SPECS]$ rpmlint ../RPMS/x86_64/bumblebee-3.0-1.fc16.x86_64.rpm 
bumblebee.x86_64: W: non-conffile-in-etc /etc/bash_completion.d/bumblebee
bumblebee.x86_64: W: no-manual-page-for-binary bumblebee-bugreport
Pour les autres fichiers de conf, ce sont bien des fichiers de configuration mais que l'utilisateur peut modifier, donc je vais laisser le tag %config(noreplace).

J'ai aussi enlevé le CONF_DRIVER=nouveau afin de laisser bumblebee faire une auto-détection en fonction du pilote installé.
Roultabie wrote: J'ai aussi enlevé le CONF_DRIVER=nouveau afin de laisser bumblebee faire une auto-détection en fonction du pilote installé.
N'oublie pas que le rpm est un binaire, donc déjà compilé. La compilation se fait sur les serveurs du projet et pour la plus part, des VMs.
La détection se fait via le daemon, une fois bumblebee installé. Donc pas de souci de ce côté là.

En fait, le CONF_DRIVER, ajoute nouveau dans le fichier de configuration.
Roultabie wrote:Fichiers mis à jour.

Par contre, comme tu me le dis, rpmlint me ressort des warnings.
[builder@spartacus SPECS]$ rpmlint ../RPMS/x86_64/bumblebee-3.0-1.fc16.x86_64.rpm 
bumblebee.x86_64: W: non-conffile-in-etc /etc/bash_completion.d/bumblebee
bumblebee.x86_64: W: no-manual-page-for-binary bumblebee-bugreport
rpmlint n'est pas un juge infaillible, il aide simplement à détecter de potentielles erreurs de packaging. Tu peux passer outre ses avertissements dès lors que tu peux montrer qu'il s'agit de faux-positifs ; ça n'ôtera rien à la qualité de ton paquet tant qu'il se conforme aux guidelines Fedora.
J'ai aussi enlevé le CONF_DRIVER=nouveau afin de laisser bumblebee faire une auto-détection en fonction du pilote installé.
L'auto-détection est faite à la compilation ou à l'exécution de bumblebee ?
L'auto détection est faite à l'exécution de bumblebee (voir mon message au dessus).
Roultabie wrote:L'auto détection est faite à l'exécution de bumblebee (voir mon message au dessus).
Nos messages se sont croisés, tu as anticipé ma question, de fait 🙂.
Par contre, même si ici on ne travaille pas avec le pilote propriétaire, il faut que je rende le tout compatible avec pour laisser le libre choix à l'utilisateur, car là il ne fonctionnera qu'avec nouveau.
Il reste encore des BuildRequires superflus (voir mon premier message).
Tu gagnerais à découper la ligne « %configure ... », ce sera plus lisible ainsi :
%configure \
  CONF_DRIVER_MODULE_NVIDIA=nvidia \
  CONF_LDPATH_NVIDIA=%{_libdir}/nvidia:/usr/lib32/nvidia \
  CONF_MODPATH_NVIDIA=%{_libdir}/xorg/modules/extensions/nvidia,%{_libdir}/xorg/modules \
  --docdir=%{_docdir}/%{name}-%{version}
Au passage, la valeur de CONF_LDPATH_NVIDIA me choque un peu : je doute que /usr/lib32/ soit un chemin standard de Fedora.

La création de l'utilisateur bumblebee est à revoir : http://fedoraproject.org/wiki/Packaging:UsersAndGroups
Oups, j'ai oublié de corriger ça l'autre soir. Corrections faites, liens mis à jour.

J'ai aussi enlevé le pilote par défaut et pointé les fichiers du pilote propriétaire, comme ça l'utilsateur final à le choix.

D'après mes premiers tests disponibles ici c'est un bon début !