Activer le Multiarch sous debian

Qu’est ce que Multi-arch ?

Multi-arch vous permet d’installer des bibliothèque de paquets venant de différentes architectures sur un même système. C’est très utile dans beaucoup de cas, cela permet le plus souvent d’installer à la fois des logiciels 32 et 64 bits sur la même machine, tout en conservant une résolution des dépendances automatique correcte. Notez que cela ne permet pas d’installer simultanément plusieurs versions d’une même « application » dans de multiples architectures.

Concepts

Il y a une architecture dite architecture courante, et affichée par la commande dpkg --print-architecture. Elle est définie dans le paquet dpkg actuellement installé.

(Notez qu’ici « architecture » désigne une Interface Binaire-Programme (ABI, Application Binary Interface), et non une Architecture de Jeu d’Instruction (ISA, Instruction Set Architecture). Ainsi, par exemple, « armel » et « armhf » sont bien des « architectures » différentes car, bien qu’elles utilisent (presque) le même jeu d’instruction, elles se reposent sur des ABI différentes pour l’appel de fonctions depuis les bibliothèques.

Il est maintenant possible de se référer à un paquet via « paquet:architecture » à peu près partout où il était possible de le faire avant avec « paquet » — nous avons donc libc:i386 et libc:amd64 — malheureusement, les sémantiques comprises par dpkg et apt étant légèrement différentes, les résultats obtenus via ces deux interfaces peuvent être légèrement différents. Cependant, préciser l’architecture d’un paquet devrait toujours être sûr et sans ambigüité, quant au nom « paquet » sans précision, il se réfère au paquet dans l’architecture courante d’apt.

Les autres architectures disponibles sont visibles grâce à la commande dpkg --print-foreign-architectures. Dpkg gèrera les paquets de ces architectures ainsi que ceux de l’architecture de la machine.

Il y a un entête « Multi-Arch » inscrit dans les méta-données pour chaque paquet multi-architectures concerné.

Les paquets existants fonctionnent très bien dans un environnement multi-architectures, mais pour bénéficier d’une co-installation ou d’un arbre de dépendances multi-architectures, beaucoup de paquets ont besoin d’être rendus compatibles en multi-architectures.

  • Pour un paquet inchangé vous pouvez choisir quelle version d’architecture du paquet vous souhaitez installer (par exemple, « amd64 » ou « i386 »).
  • Si un paquet est étiqueté « Multi-Arch: foreign », alors il peut satisfaire la dépendance d’un paquet d’une architecture différente (par exemple, « make:amd64 » permettra de satisfaire une dépendance faite pour un paquet de n’importe quelle architecture).
  • Pour activer plus d’une version d’architecture d’un paquet en même temps (généralement les librairies et les paquets dev-) les fichiers ont besoin d’être déplacés pour ne pas avoir de conflit. Ces paquets sont eux aussi tagués « Multi-Arch: same ».

Des paquets étiquetés « Multi-Arch : allowed » existent aussi. Ils peuvent être traités à la fois comme « :same » ou comme « :foreign » en fonction des paquets dont ils dépendent.

Le plus souvent, les responsables des paquets travaillent sur leur distribution en commençant par installer les paquets les plus utiles pour la rendre multi-architectures. Voir multiarch spec et howto implementation pour avoir des détails sur le fonctionnement actuel et pour savoir comment mettre à jour les paquets et tirer avantage de cette fonctionnalité.

Continuer la lecture de « Activer le Multiarch sous debian »

Firmware manquant pendant l’installation de debian.

Le mot firmware, qui peut être traduit par le terme microcode (ou microprogramme), fait référence à un programme intégré qui contrôle des périphériques électroniques. Il n’y a pas de frontières précises entre microprogramme et programme dans la mesure où les deux termes recouvrent parfois des codes similaires. Habituellement, le terme microcode (firmware) désigne un programme qui se charge des opérations de bas niveau dans un périphérique, sans lesquels le périphérique ne pourrait fonctionner… (pour en savoir plus Wikipedia).

Microcodes, Périphériques et Pilotes

 

De nombreux périphériques ont besoin d’un microcode pour fonctionner. Historiquement, les microcodes étaient incorporés à la ROM ou à la mémoire flash des périphériques, mais, de plus en plus souvent, ils doivent être chargés dans le périphérique par le pilote au moment de leur mise en route. Certains de ces microcodes sont libres et open-source, mais d’autres non ce qui fait que vous devez ajouter les sources non-free et contrib à votre fichier /etc/apt/sources.list ; voir sources.list(5) et Debian archive basics (Debian Reference) pour des informations complémentaires.

Continuer la lecture de « Firmware manquant pendant l’installation de debian. »

Créez une clé bootable

    Merci a Tnut

Si vous êtes déjà sous GNU/Linux :

[Important]En root

A l’aide de fdisk, déterminez où se trouve votre clé USB :

fdisk -l

A l’aide de dd, créez votre clé bootable :

dd if=NuTyX_x86_64-saravane-14.11.iso of=/dev/sdX

La valeur sdX est donnée par la commande :

fdisk -l

Si vous êtes sous Windows :

Utilisez votre outils de gravure favori pour graver l’iso sur un CD-RW (si possible) …

Montage téléphone portable wikko riff comme une cléf usb

https://i1.wp.com/data.wikomobile.com/documents/images/FR/90b48ea6100488ebaf951b7a8226997a.jpg?w=840

   Il faudra commenter la règle correspondant au device Mediatek dans le fichier /lib/udev/rules.d/40-usb_modeswitch.rules :

ATTRidVendor== »0e8d », ATTRidProduct== »0002″, RUN+= »usb_modeswitch ’%b/%k’ »

Voir ici : https://bugs.debian.org/cgi-bin/bugrepo … bug=686840
Redémarrer, ensuite, ta machine.

Les rétroportages (dépôt « backports »)

    Le dépôt backports propose des paquets plus récents ou absents du dépôt principal. Ces paquets sont dérivés de la version de test et peuvent être installé sur une Debian stable.
Il servira à ceux qui ont absolument besoin d’une version plus récente d’un logiciel, mais ne veulent pas compromettre la stabilité générale de leur système en migrant vers testing.

Le principe est que ces paquets sont compilés sous jessie, cela évite de ramener des bibliothèques de testing pour les installer ce qui fait le gain dans la stabilité plutôt que de les prendre directement dans testing.

Continuer la lecture de « Les rétroportages (dépôt « backports ») »

Debian Testing : comment l’utiliser efficacement ?

La branche « Testing » de Debian représente la future version « Stable » en développement. C’est pour beaucoup un excellent choix : les logiciels y sont récents et elle est généralement très stable. Cependant, du fait qu’elle soit en développement, elle nécessite une certaine attention et certaines connaissances pour être appréciée et utilisée sereinement.

Être prévenu sur l’état des paquets qui seront installés/mis à jour

Avec Debian Testing les mises à jours sont quotidiennes, et même si les paquets sont restés quelques jours/semaines dans la branche « Unstable » (ou Sid) pour être testés avant d’être reversés dans Testing ils peuvent quand même parfois être bogués.
L’installation d’Apt-listbugs est donc recommandée. Il permet d’être prévenu sur l’état des paquets qui seront installés/mis à jour, en indiquant la nature, l’état, la gravité du bogue ainsi que les architectures concernés, le tout en anglais…

Quelques explications sur l’état des bogues :

- Done : le bogue a été corrigé.
- Fixed : le bogue a été corrigé pour une prochaine version (Pour Testing c’est en général la version qui va être installé).
- Pending : le bogue est en train d’être corrigé mais la version qui va être installé contient peut être encore le bogue. Il est donc sage de faire une vérification sur le site http://www.debian.org/Bugs/ armé du numéro du bogue.

Tout cela en gardant à l’esprit qu’un bogue ne touche pas forcement toutes les configurations matériels, inutile donc de tomber dans la paranoïa…


Le sources.list et le fichier de préférence des priorités

Il nous faut tout d’abord répondre à une question : quelle est la différence entre utiliser la branche « Testing » et son nom de code (actuellement Lenny) dans le sources.list ?
C’est simple, si on utilise « testing » dans le sources.list on restera toujours dans la branche « Testing » de Debian. Si par contre on utilise « lenny », lorsque Lenny deviendra la version « Stable » de Debian on passera donc de la version Testing à la version Stable.
Le branche « Testing » étant particulièrement instable les semaines suivants la sortie de la version Stable il est recommandé d’utiliser dans le sources.list le nom de code de la branche « Testing » (actuellement Lenny) et de faire le cas échéant une mise à niveau vers la nouvelle version Testing une fois l’ouragan passé (un délai d’environ 2 mois est généralement suffisant).

Continuer la lecture de « Debian Testing : comment l’utiliser efficacement ? »

Création de paquets DEB (méthode2 : devscripts)

    Cette fois ci, on va se simplifier la vie:

1/ Pour commencer, nous faisons un dossier avec le nom du paquet, par exemple pour playonlinux:
$ mkdir /home/sebastien/packaging/playonlinux
$ cd /home/sebastien/packaging/playonlinux

2/ On télécharge les sources debian du paquet:
$ apt-get source playonlinux

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Note : la maintenance du paquet de « playonlinux » est réalisée dans le système de suivi de versions « Svn » à l'adresse :
svn://anonscm.debian.org/pkg-games/packages/trunk/playonlinux/
Nécessité de prendre 3 211 ko dans les sources.
Réception de : 1 http://ftp.fr.debian.org/debian/ testing/contrib playonlinux 4.2.6-1 (dsc) [1 978 B]
Réception de : 2 http://ftp.fr.debian.org/debian/ testing/contrib playonlinux 4.2.6-1 (tar) [3 203 kB]
Réception de : 3 http://ftp.fr.debian.org/debian/ testing/contrib playonlinux 4.2.6-1 (diff) [6 684 B]
3 211 ko réceptionnés en 4s (780 ko/s)  
dpkg-source: info: extraction de playonlinux dans playonlinux-4.2.6
dpkg-source: info: extraction de playonlinux_4.2.6.orig.tar.gz
dpkg-source: info: extraction de playonlinux_4.2.6-1.debian.tar.xz
dpkg-source: info: mise en place de set_debian_env.diff
dpkg-source: info: mise en place de remove_binary_plugin.diff

3/ On télécharge en ROOT, les paquets nécessaire pour construire ce paquet:
# apt-get build-dep playonlinux

4/ On se remet en simple utilisateur, puis on rentre dans le dossier des sources debian:
$ cd '/home/sebastien/packaging/playonlinux/playonlinux-4.2.6'

5/ On va dans voir le fichier /debian/watch qui permet, si bien fait, de faire tout automatiquement avec la commande uscan. Les sources mises à jour seront automatiquement recherchées, téléchargées, et la commande uupdate sera exécutée.
$ uscan

playonlinux: Newer version (4.2.8) available on remote site:
  https://www.playonlinux.com/script_files/PlayOnLinux/4.2.8/PlayOnLinux_4.2.8.tar.gz
  (local version is 4.2.6)
Successfully downloaded updated package PlayOnLinux_4.2.8.tar.gz
Successfully symlinked ../PlayOnLinux_4.2.8.tar.gz to ../playonlinux_4.2.8.orig.tar.gz.
New Release will be 4.2.8-1.
-- Untarring the new sourcecode archive ../playonlinux_4.2.8.orig.tar.gz
Unpacking the debian/ directory from version 4.2.6-1 worked fine.
Remember: Your current directory is the OLD sourcearchive!
Do a "cd ../playonlinux-4.2.8" to see the new package

Si la commande uscan télécharge les sources mises à jour mais n’exécute pas la commande uupdate, vous devriez corriger le fichier debian/watch pour avoir debian uupdate après l’URL.

6/ Normalement tout a été fait si le fichier watch est bien fait, du coup reste plus qu’a fabriquer le deb:
$ cd '/home/sebastien/packaging/playonlinux/playonlinux-4.2.8'
$ debuild

dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: paquet source playonlinux
dpkg-buildpackage: version source 4.2.8-1
dpkg-buildpackage: distribution source UNRELEASED
dpkg-buildpackage: source changé par Sebastien CHAVAUX <sebastien@debianlinux.schavfr>
 dpkg-source --before-build playonlinux-4.2.8
dpkg-buildpackage: architecture hôte amd64
dpkg-source: info: mise en place de set_debian_env.diff
dpkg-source: info: mise en place de remove_binary_plugin.diff
 fakeroot debian/rules clean
dh clean --with python2
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b playonlinux-4.2.8
dpkg-source: info: utilisation du format source « 3.0 (quilt) »
dpkg-source: info: construction de playonlinux en utilisant le ./playonlinux_4.2.8.orig.tar.gz existant
dpkg-source: info: construction de playonlinux dans playonlinux_4.2.8-1.debian.tar.xz
dpkg-source: info: construction de playonlinux dans playonlinux_4.2.8-1.dsc
 debian/rules build
dh build --with python2
   dh_testdir
   dh_auto_configure
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/home/sebastien/packaging/playonlinux/playonlinux-4.2.8'
convert -monitor -resize 32x32 /home/sebastien/packaging/playonlinux/playonlinux-4.2.8/etc/playonlinux.png /home/sebastien/packaging/playonlinux/playonlinux-4.2.8/playonlinux.xpm
Load/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8/etc[playonlinux.png]: 0 of 128, 00% cLoad/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8/etc[playonlinux.png]: 1 of 128, 00% cLoad/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8/etc[playonlinux.png]: 2 of 128, 01% cLoad/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8/etc[playonlinux.png]: 3 of 128, 02% cLoad/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8/etc[playonlinux.png]: 4 of 128, 03% c......
Save/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8[playonlinux.xpm]: 30 of 32, 96% complSave/Image//home/sebastien/packaging/playonlinux/playonlinux-4.2.8[playonlinux.xpm]: 31 of 32, 100% complete
make[1]: Leaving directory '/home/sebastien/packaging/playonlinux/playonlinux-4.2.8'
   dh_auto_test
 fakeroot debian/rules binary
dh binary --with python2
   dh_testroot
   dh_prep
   dh_auto_install
   debian/rules override_dh_install
make[1]: Entering directory '/home/sebastien/packaging/playonlinux/playonlinux-4.2.8'
dh_install
chmod +x debian/playonlinux/usr/share/playonlinux/bash/startup_after_server
chmod +x debian/playonlinux/usr/share/playonlinux/bash/read_pc_cd
chmod +x debian/playonlinux/usr/share/playonlinux/bash/find_python
make[1]: Leaving directory '/home/sebastien/packaging/playonlinux/playonlinux-4.2.8'
   dh_installdocs
   dh_installchangelogs
   dh_installman
   dh_python2
W: dh_python2:479: Please add dh-python package to Build-Depends
   dh_installmenu
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_installdeb
   dh_gencontrol
dpkg-gencontrol: avertissement: champ Depends du paquet playonlinux : variable de substitution inconnue ${shlibs:Depends}
   dh_md5sums
   dh_builddeb
dpkg-deb : construction du paquet « playonlinux » dans « ../playonlinux_4.2.8-1_all.deb ».
 dpkg-genchanges  >../playonlinux_4.2.8-1_amd64.changes
dpkg-genchanges: inclusion du code source original dans l'envoi (« upload »)
 dpkg-source --after-build playonlinux-4.2.8
dpkg-source: info: retrait de remove_binary_plugin.diff
dpkg-source: info: retrait de set_debian_env.diff
dpkg-buildpackage: envoi complet (inclusion du code source d'origine)
Now running lintian...
W: playonlinux source: changelog-should-mention-nmu
W: playonlinux source: source-nmu-has-incorrect-version-number 4.2.8-1
Finished running lintian.
Now signing changes and any dsc files...
 signfile playonlinux_4.2.8-1.dsc 0x100F502F

You need a passphrase to unlock the secret key for
user: "Sebastien XXXX (seb95) <xxxxx@xxx.xx>"
2048-bit RSA key, ID 100F502F, created 2015-05-19

                  
 signfile playonlinux_4.2.8-1_amd64.changes 0x100F502F

You need a passphrase to unlock the secret key for
user: "Sebastien XXXXXX (seb95) <xxxx.xxx@xx.xx>"
2048-bit RSA key, ID 100F502F, created 2015-05-19

                  
Successfully signed dsc and changes files

On aura de jolies paquets deb, et pour finir un coup de debuild clean.

Création de paquets DEB (méthode1 : dpkg-buildpackage)

    On va commencer par changer une règle de compilation d’un paquet déjà présent dans debian :

1/ Je récupère les sources de debian, apt-get source nom_du_paquet ou par exemple :

apt-get source mldonkey

2/ Je m’occupe donc de mettre une version différente de celle du dépôt pour pas entrer en conflit avec ceux du dépôt, par exemple si c’est la version 3.5.1 dans le dépôt, je change le miens en 3.5.1-scha1. Je le fais avec dch, :

dch -v 3.1.5-2.scha1

3/
J’effectue les modification, admettons que je veux seulement changer un truc dans la compilation, par exemple la prise en charge de tout les protocoles, faudra aller dans le fichier rules du dossier /debian. Le fichier control me sers a transcrire les changements et alleger les dépendances (debian aime bien donner des versions a ses dépendances ce qui est nécessaire car elle a plusieurs versions (stable, testing, sid))

4/ On télécharge les dépendances du paquet a construire :

# apt-get build-dep mldonkey

5/ Ensuite pour construire le paquet on rentre un

dpkg-buildpackage -rfakeroot -us -uc

(-us -uc pour ne pas chiffrer avec une clef)

on installe ce que nous demande le terminal( d’ou l’utilité d’un chroot) ou de ne faire que pour des paquets qu’on utilise…
et on a un joli paquet.

Dans les prochains posts, enfin j’espére, on parlera de paquet a partir de zéro, ou avec checkinstall, et ensuite de dépôt privé mais accessible par internet par exemple pour la famille. J’ai déjà lu la doc (tres bonne au passage), il manque plus que le courage pour se lancer.

P.S : toutes les commandes sont a taper en user simple et pas en root ! Sauf si

#

est mis avant la commande


Changements apporté au fichier rules :

     —enable-multinet
     —enable-bittorrent
     —enable-filetp
     —enable-gnutella
     —enable-gnutella2
  —enable-fasttrack

Description supplémentaire apporté au fichier changelog :

mldonkey (3.1.5-2.scha1) UNRELEASED ; urgency=medium
 * Activation des réseaux fasttrack, bittorrent, gnutella1&2, filetp
— Sebastien CHA <sebastien@xxxxxxxx.xx.xx> Wed, 15 Apr 2015 14:04:01 +0200

L’adresse a été changé pour ne pas être exploité.

A la suite de quoi nos nouveaux paquets sont disponible comme on peut le voir par un « ls » :

[ /Public/debian] :$ ls
mldonkey-3.1.5                  mldonkey_3.1.5-2.scha1.dsc
mldonkey_3.1.5-2.debian.tar.xz            mldonkey_3.1.5.orig.tar.bz2
mldonkey_3.1.5-2.dsc             mldonkey-gui_3.1.5-2.scha1_amd64.deb
mldonkey_3.1.5-2.scha1_amd64.changes    mldonkey-server_3.1.5-2.scha1_amd64.deb
mldonkey_3.1.5-2.scha1.debian.tar.xz

Je viens de refaire un autre paquet, pour le moment ce ne sont qu’a partir des sources de debian, donc le paquet doit être déjà packagé.

apt-get source xfce4-systemload-plugin
apt-get build-dep xfce4-systemload-plugin
exit (on revient dans le terminal utilisateur)
dch -v 1.1.1-4.scha1
dpkg-buildpackage -rfakeroot -us -uc

Création de paquets RPM

Je me suis lancé dans le rpm, bon quelle simplicité par rapport aux DEB !
On commence par faire un répertoire rpm ou rpmbuild comme on veut, avec des sous dossiers, pour cela on va faire la commande suivante :

$ mkdir -p ~/rpmbuild/{BUILD,RPMS/{i586,noarch,x86_64},SOURCES,SRPMS,SPECS}

Puis on installe les paquets nécessaires :

urpmi rpm-build rpm-sign

Bon pour faire un simple rétro-portage il suffit de télécharger le rpm.source du paquet désiré :

$ wget http://mirror.internode.on.net/pub/mageia/distrib/cauldron/SRPMS/core/release/pbzip2-1.1.8-3.mga3.src.rpm

Ensuite, la deuxième étape consiste à télécharger les build-requires, c’est à dire les paquets nécessaires au bon fonctionnement de la future application à packager :

# urpmi --buildrequires pbzip2-1.1.8-3.mga3.src.rpm

Dernière étape, on build notre paquet :

$ rpmbuild --rebuild pbzip2-1.1.8-3.mga3.src.rpm

on aura un joli rpm !!!

Continuer la lecture de « Création de paquets RPM »

Création/Mise à jour de paquets DEB

Après la publication d’un paquet, il sera rapidement nécessaire de le mettreà jour.

8.1. Nouvelle révision Debian

Soit un rapport de bogue numéroté #654321, concernantvotre paquet et décrivant un problème que vous pouvez résoudre. Voici ce quevous devez faire pour créer une nouvelle révision du paquet :

  • pour un nouveau correctif :
    • configurer le nom du correctif : dquilt newnomdubogue.patch ;
    • déclarer le fichier à modifier : dquilt addfichier-bogué ;
    • corriger le problème dans le paquet source pour le bogue amont ;
    • l’enregistrer ennomdubogue.patch :dquilt refresh ;
    • ajouter sa description : dquilt header -e ;
  • pour la mise à jour d’un correctif :
    • rappeler le correctiftoto.patch existant :dquilt pop toto.patch ;
    • corriger le problème dans l’ancientoto.patch ;
    • mettre à jour toto.patch :dquilt refresh ;
    • mettre à jour sa description : dquilt header -e ;
    • appliquer tous les correctifs en enlevant les approximations(fuzz) : while dquilt push; do dquilt refresh;done ;
  • ajouter une nouvelle révision au début du fichierchangelog Debian, par exemple avec dch-i, ou explicitement avec dch -vversion-révision,et ajoutez ensuite les commentaires en utilisant votre éditeurfavori ;[78]
  • ajouter une courte description du bogue et de la solution dans l’entrée duchangelog, suivie par Closes: #654321. De cette manière,le rapport de bogue sera automagiquement fermé par lelogiciel de maintenance des archives une fois le paquet accepté dansl’archive Debian ;
  • répéter les opérations précédentes pour corriger plus de bogues tout enmettant à jour le fichier changelog avecdch selon votre besoin ;
  • recommencer ce qui a été fait en Section 6.1, « Reconstruction complète » et Chapitre 7, Contrôle des erreurs du paquet ;
  • une fois satisfait, modifier la valeur de distribution danschangelog d’UNRELEASED à la valeurde distribution cible unstable (ou mêmeexperimental). [79]
  • envoyer le paquet comme en Chapitre 9, Envoi de paquet. La différence est quecette fois, l’archive source originale ne sera pas incluse, car elle n’a pasété modifiée et est déjà dans l’archive Debian.

Un cas délicat peut se produire quand vous faites un paquet local pourexpérimenter l’empaquetage avant d’envoyer la version normale vers l’archiveofficielle, par exemple1.0.1-1.Pour des mises à niveau plus en douceur, il vaut mieux créer une entrée dechangelog avec une chaîne de version comme1.0.1-1~rc1.Vous pouvez nettoyer le changelog en fusionnant cesentrées de modification en une unique entrée pour le paquetofficiel. Consultez Section 2.6, « Nom et version de paquet » pour l’ordre des chaînes deversion.

Continuer la lecture de « Création/Mise à jour de paquets DEB »