🚲 Tanguy Ortolo a écrit 12224 commentaires

Aucune chance, et même s'il le détectait, aucune chance que GRUB soit capable de le lancer, c'est à dire de la chainloader, dans la mesure où dans son cas présent, c'est GRUB sous BIOS qu'il a, et un chargeur de Windows pour UEFI. Or on ne peut pas lancer un exécutable UEFI sous BIOS.

Visiblement tu as installé Debian en mode BIOS, et donc GRUB pour BIOS. L'ennui, c'est qu'il ne peut pas passer la main au chargeur de Windows qui est un exécutable UEFI.

Il va te falloir GRUB pour UEFI. Le problème, c'est qu'en démarrant Debian en mode BIOS, tu peux certes installer GRUB pour UEFI à la place de GRUB pour BIOS, mais que celui-ci ne pourra pas se déclarer à la carte mère pour que celle-ci le lance au démarrage.

La solution est plutôt compliquée : il va falloir donc démarrer Debian (en mode BIOS), installer GRUB pour UEFI (paquet grub-efi-amd64), puis :

1. monter la partition système UEFI ;
2. renommer l'exécutable UEFI principal du chargeur de Windows (pas la moindre idée de son nom, mais il doit être quelque part dans un répertoire nommé Microsoft ou Windows) ;
3. copier l'exécutable principal de GRUB UEFI (qui doit être installé sous debian/grubx64.efi) dans le répertoire et sous le nom que portait l'exécutable principal du chargeur de Windows ;
4. redémarrer et entrer dans la configuration de ta carte mère pour activer le démarrage UEFI et désactiver SecureBoot ;
5. redémarrer et laisser charger ce que la carte mère croit être le chargeur de Windows et qui est en fait GRUB ;
6. remettre les exécutables principaux du chargeur de Windowd et de GRUB à leur place ;
7. lancer grub-install /dev/sda, enfin, sur ton disque dur, qui n'est pas forcément sda ;
8. éditer /etc/grub.d/41_custom pour y ajouter une entrée de chainload sur l'exécutable principal du chargeur de Windows, puis lancer update-grub ;
9. redémarrer, et vérifier que la carte mère propose bien une entrée de démarrage « debian », que celle-ci lance bien GRUB, et que l'entrée personnalisée que tu viens de créer lance bien le chargeur de Windows.

Le chocolat contient tout de même des molécules actives, biologiquement parlant, notamment des psychotropes légers. Le sucre, c'est actif aussi, mais de façon plus simple.

C'est bon ça, merci !

Oui en effet, je force l'usage d'une version de jQuery dont je sais qu'elle reçoit des mises à jour de sécurité, c'est bien ça.

Et sinon, c'est permis de, par exemple, critiquer Monsanto, ou est-ce qu'il faut forcément créer un nouveau semencier pour avoir le droit de l'ouvrir ?

Eh bien, soit ces clefs prennent en charge des tensions qui peuvent varier entre 9 et 30 volts (d'après la page Wikipédia : je me souvenais de 48 volts mais c'est visiblement 30 volts en réalité), auquel cas elles devraient coûter bien plus cher que des clefs USB. Soit elles fonctionnent sous 9 volts, et si on les branche sur une implémentation valide de Firewire qui fournit du 30 volts, on les crame.

Et comme exemple de patch envoyé aux développeurs amont mais conservé pendant longtemps dans Debian, il y avait à une époque un bug dans Brasero, un logiciel de gravure de disques, qui faisait échouer une bonne partie des gravures de disques audio. Ce bug venait de la génération de feuilles CUE invalides, avec des index temporels avec un nombre de jiffies — soixantièmes de secondes — qui pouvait être de 60, alors qu'il aurait dû être de 0 sur la seconde d'après.

J'avais donc rédigé un patch assez simple pour corriger cela, qui avait évidemment été appliqué dans Debian, par moi-même d'ailleurs, sous la forme de ce qu'on appelle un NMU, non maintainer upload, c'est à dire un envoi de nouvelle version de paquet par quelqu'un qui n'est pas le mainteneur officiel du paquet en question. Puis transmis le bug aux développeurs amont, qui avaient mis deux ou trois ans avant de l'intégrer : pendant ce temps, Brasero était bogué pour la création de disques audio, partout sauf dans Debian où ce patch était resté jusqu'à ce qu'ils l'aient finalement intégré…

Pas forcément, il y a a vraiment des trucs que je n'envoie pas du tout aux développeurs amont parce que je sais qu'ils le refuseront, et à juste titre, donc ce ne serait que les ennuyer pour rien.

Le plus bel exemple que j'aie de cela, c'est DokuWiki, un moteur de wiki, qui, comme souvent pour les logiciels Web, intègre des bibliothèques externes telles que GeSHi, jQuery ou encore SimplePie. C'est utile pour les gens qui installent ce logiciel à la main sur leur serveur Web, mais dans le cadre de la distribution Debian, c'est mal, parce que ça alourdit inutilement le système et que ça complique la maintenance de sécurité. Donc, dans le paquet Debian de DokuWiki, j'ai ce genre de patch :

Author: Tanguy Ortolo <tanguy plusse debian chez ortolo point, con ! eu>
Description: Use packaged version of jQuery instead of an embedded one
Forwarded: not-needed
Last-Update: 2012-01-02

Index: dokuwiki/lib/exe/js.php
===================================================================
--- dokuwiki.orig/lib/exe/js.php        2014-06-08 16:11:35.544575705 +0200
+++ dokuwiki/lib/exe/js.php     2014-06-08 16:11:35.532575542 +0200
@@ -40,9 +40,9 @@

     // array of core files
     $files = array(
-                DOKU_INC."lib/scripts/jquery/jquery$min.js",
-                DOKU_INC.'lib/scripts/jquery/jquery.cookie.js',
-                DOKU_INC."lib/scripts/jquery/jquery-ui$min.js",
+                "/usr/share/javascript/jquery/jquery$min.js",
+                '/usr/share/javascript/jquery-cookie/jquery.cookie.js',
+                "/usr/share/javascript/jquery-ui/jquery-ui$min.js",
                 DOKU_INC."lib/scripts/jquery/jquery-migrate$min.js",
                 DOKU_INC.'inc/lang/'.$conf['lang'].'/jquery.ui.datepicker.js',
                 DOKU_INC."lib/scripts/fileuploader.js",

Ce patch donc, est spécifique à Debian, d'où le champ d'en-tête Forwarded: not-needed. Les développeurs amont ne l'intègreront pas, parce que d'une part ce n'est pas utile pour eux et pour leurs utilisateurs directs, mais qu'en plus ça casserait franchement le logiciel, à moins d'être sous Debian ou une autre distro fournissant jQuery au même endroit.

Et surtout, ça se règle, de prendre automatiquement les simples recommandations ou seulement les dépendances dures.

Vous vous battez pour rien là : les habitudes en cours dépendent des gens ! Certains sont efficaces à noter sur un ordinateur, d'autres sur papier, et d'autres enfin n'ont pas besoin de prendre des notes.

En ce qui me concerne, je sais que si on me met un ordinateur devant moi en cours je ne serai pas capable de noter et que je ne retiendrai rien. Que si je ne prend pas de notes sur papier je ne retiendrai rien. Et que si je note, je retiendrai, même si je jette mes notes à la poubelle en sortant d'amphi : pour moi, c'est vraiment le fait de noter qui m'aide à retenir, pas les notes en tant que telles.

Bref, ça dépend des étudiants !

• Firewire : échec complet, l'USB ayant ratrapé son retard petit à petit

Le Firewire n'était surtout pas un remplaçant possibe de l'USB. En particulier, il lui manque un fil d'alimentation pour permettre de faire des clefs Firewire par exemple. Enfin, il a un fil d'alimentation, mais c'est du 48 volts, autrement dit inutilisable pour de l'électronique de consommation. Enfin, c'est théoriquement du 48 volts, mais comme aucun ordinateur actuel ne peut fournir ça facilement, en réalité c'est du… ben, du 5 volts, du 12 volts, ça dépend selon les ordinateurs. Bref c'est encore plus inutilisable.

• Thunderbolt : semi-échec pour le moment

Thunderbolt, c'est bien le port très haut débit développé par Intel, en fibre optique ? Enfin, prévu en fibre optique, mais comme ça coûte trop cher, en fait c'est du cuivre. Et qui a vocation à devenir universel, donc pour ça ils ont commencé par le distribuer exclusivement sur les ordinateurs Apple ?

/me se marre.

Question qualité, c'est généralement solide, mais loin d'être parfait aujourd'hui. En particulier, l'équivalent actuel de ton ordinateur, serait un portable Apple à la coque métallique, qui dégage beaucoup de chaleur par le bas, ce qui rend son utilisation pénible sur les genoux l'été. Et par ailleurs :

La batterie tient encore environ 3h

Ça, c'est excellent pour un ordinateur de huit ans, en revanche les plus récents s'usent assez vite, notamment à cause d'un défaut volontaire de conception : la batterie ne peut pas s'enlever facilement, du coup l'ordinateur est souvent en charge, ce qui évidemment l'use.

Personnellement, il y a quelques années je t'aurais conseillé de l'IBM ThinkPad, mais je ne sais pas ce qu'ils sont devenus avec Lenovo ; en tout cas il y a toujours l'excellent ThinkWiki pour se renseigner. Et autrement, je te recommande Dell Latitude, qui sont presque aussi bon que Lenovo pour la démontabilité et la réparabilité de leur portables.

Merci capitaine évident. Et à part ça, j'ai le droit de critiquer, ou seulement de fermer ma bouche ?

Parce que c'est un grand pas dans le verrouillage des utilisateurs, avec une mise en œuvre d'informatique déloyale que même Microsoft avait renoncé à faire. Le monde se porterait mieux si Apple n'existait pas, ou s'ils existaient mais ne verrouillaient pas leurs appareils et les logiciels qui tournent dessus.

Dit donc les prix ont vachement baissé ! Par contre, niveau distribution c'est très limité… C'est soit du Debian 7 ou du Ubuntu, et ArchLinux alors ?!

Sur du dédié, tu peux installer ce que tu veux, à condition de disposer d'une procédure d'installation qui ne nécessite pas d'accès physique ni d'accès déporté à l'écran et au clavier.

Pas convaincu : Apple ont souvent sorti des appareils qui n'avaient rien de nouveau, et qui étaient apparemment très décevants. Par exemple, l'iPad : un ordinateur sans clavier, sans souris, sans lecteur de carte mémoire, sans port USB, avec un écran tactile (ce qui existait déjà)… Sauf que malheureusement, ça a fait un carton !

Les fichiers requis ont (à peu près) tous une raison valable d'exister : le control c'est celui qui correspond le mieux à ce qui existe dans les autres distros pour « définir » le paquet ; le copyright est séparé car historiquement non-structuré, contrairement au control, même si ça n'est plus le cas aujourd'hui

Même structuré, je suis content que le debian/copyright soit séparé du debian/control, parce que c'est souvent p****n de long, ce qu'on met dedans. Pensez donc, des licences entières, et parfois plusieurs, si c'était dans le debian/control ça n'améliorerait pas sa lisibilité !

Ah ben non, la demande est différente. Aider un nouveau mainteneur de paquet, ça je peux faire, j'ai déjà fait d'ailleurs.

Et pour répondre à la question, non, je n'ai pas essayé autre chose, faute de raison de le faire !

Mais attention, l'option -L ca ne fonctionne que pour un paquet deja installé. Pour lister les fichiers fournis par un paquet à partir du fichier .deb non installé, c'est dpkg-deb qu'il faut utiliser. Et l'option n'est pas la meme evidemment, la c'est l'option -c de dpkg-deb qu'il faut utiliser pour lister les fichiers.

Là, c'est chercher la petite bête : tu devrais pouvoir reconnaître qu'entre lister les fichiers qui ont été fournis par un paquet installé, et ceux d'un paquet présent dans l'archive d'un paquet non installé mais présent dans le répertoire courant, ce n'est pas du tout le même boulot. Dans le premier cas, cela consiste à interroger une base de données locale, l'archive du paquet n'étant probablement nulle part sur ton ordinateur. Dans le second cas, cela consiste à lister le contenu d'une archive.

dpkg-deb sert à analyser des archives de paquets oui. Mais ça sert très peu pour un utilisateur normal, parce qu'il n'est justement pas habituel de télécharger à la main un paquet seul.

rajoute que ce répertoire doit obligatoirement se trouver à la racine lors de la "compilation"

Oui, ça s'appelle une convention plutôt qu'une configuration. Les outils de construction de paquet vont chercher un répertoire ./debian, pas ../debian ou /quelque/part/debian. Si c'est problématique, il y a sans doute des solutions : si c'est lié à l'imbrication de systèmes de versionnement par exemple, il y a des trucs comme svn-buildpackage qui permettent d'éviter cela.

La commande pour installer ou chercher n’est pas là même (apt-get vs apt-cache),

Tu vas être content, avec la prochaine Debian il y a une commande de haut niveau, apt tout court : apt search, apt show, apt install, apt update, apt upgrade…).

et des opérations qui sont de base et super simples sous Arch sont impossibles sans outil externe : savoir à quel paquet appartient un fichier, lister les fichier d’un paquet

Là il y a une séparation sous Debian et ça complique en effet : c'est liée au fait qu'APT est une sur-couche au système d'installation des paquets qui est dpkg. Pour faire simple, dpkg installe des paquets et gère les fichiers des paquets installés, alors qu'APT est un ensemble d'outils (en fait une bibliothèque et des outils qui l'utilisent) pour télécharger des paquets et leur dépendances.

Donc, pour les fichiers des paquets, c'est dpkg. dpkg -S pour chercher quel paquet a installé tel fichier, et dpkg -L pour lister les fichiers installés par un paquet.

Ah, ça. Question de goût, entre tout mettre dans un fichier avec des tas de sections ou mettre un fichier par tâche. Entre un fichier contenant des sections ou un répertoire contenant des fichiers, c'est un peu kif-kif à mon avis, quoique, vu que certains fichiers (debian/control: description du paquet source et des paquets binaires générés, et debian/copyright: description des licences utilisées dans le logiciel et le paquet) utilisent déjà des sections ce n'est pas plus mal d'avoir des fichiers séparés.

Même chose pour la configuration d'un logiciel d'ailleurs, enfin pour pas mal de trucs qu'on trouve dans /etc quoi, il y a plusieurs approches, avec es avantages et des inconvénients pour les humains et pour les logiciels chargés de lire ou de modifier ces données.

C'est une proposition fantastique et très sympa! J'ai préparé une branche debian avec mon travail préliminaire:

Je l'utiliserai sans doute, en revanche après ce sera ma branche debian évidemment. Il ne sera pas forcément utile de la conserver dans ton dépôt, puisque j'aurai le mien.

Si j'ai bien compris le workflow typique consiste à garder cette branche à part et à y merger régulièrement master à chaque nouvelle version.

Il existe plusieurs pratiques d'empaquetage sous Git, mais c'est la mienne et je ne suis pas le seul à l'utiliser. :-)

C'est moi qui m'occuperai de cela ; il serait utile d'avoir un tag Git pour chaque nouvelle version, et que les fichiers y correspondent autant que possible au contenu du tarball officiel correspondant. Si ce n'est pas le cas, c'est à dire s'il y a de grosses différences entre le contenu du dépôt Git et le contenu des tarballs publiés, je ferai moi-même une branche tarball pour mon usage (ça arrive)…

Bon, je te tiendrai au courant. Ça m'intéresse ce projet, parce que compiler du LaTeX avec un Make, c'est quelque chose que j'aime bien. Et les taballs sont signés en plus ! La classe (ça peut être vérifié automatiquement par un paquet Debian source, mais je n'avais jamais eu l'occasion d'utiliser cette fonctionnalité) !

Et ça aurait été tellement compliqué voire impossibe que uscan ouvre le fichier "central" et lise la ligne qui va bien…

Quel fichier « central » ? Tu veux dire, indiquer à uscan une URL où il pourra toujours trouver la dernière version, puis qu'il l'extraie et aille lire un fichier qui indique le numéro de version ? Cela suppose deux choses :

• qu'il existe une URL unique vers un upstream-latest.tar.gz, ce qui n'est pas toujours le cas ;
• que le tarball amont contienne un fichier indiquant le numéro de version, ce qui n'est pas non plus toujours le cas.

un .spec (rpm), dans ce que je connais, permet la même chose, et donc?

Donc rien, c'est une fonctionnalité présente dans RPM, très bien. C'est le genre de truc que je m'attends à voir dans les outils d'empaquetage bien fournis, mais pas dans des trucs volontairement très simples, c'est tout.