Cela évite de dépendre d'un reboot (choisi ou subi) pour supprimer les fichiers qui traînent dans /tmp (depuis trop longtemps ou sur lesquels on était en train de travailler quand oh-zut-un-reboot).
Utiliser cette variable (ou TMPDIR à défaut) dans un fichier de configuration peut être compliqué, d'où ma proposition. Je pense notamment aux paramètres ControlPath/ControlMaster de ssh_config.
Comme le note JoeltheLion dans sa réponse, on peut aussi passer par une création de répertoire temporaire sécurisée. Cela est relativement peu pratique pour les fois où l'on a à créer un fichier temporaire pour stocker un résultat intermédiaire, c'est pourquoi je proposais de s'habituer les doigts à taper ~/tmp au lieu de /tmp.
Réaction primaire : Cela ne coûte pas très cher d'utiliser ~/tmp au lieu de /tmp et cela peut rapporter gros… (Ne serait-ce que pour éviter de marcher sur les orteils du voisin, ou bien pour éviter les problèmes de sécurité triviaux.)
Cette nouvelle fonctionnalité me permettra donc de continuer à utiliser un tunnel SSH, et ainsi utiliser mes outils, de manière transparente.
On peut effectivement gagner en transparence mais on peut noter qu'il est déjà possible d'utiliser socat pour transformer une socket UNIX en une socket TCP, qu'on peut ensuite trimballer avec les redirections de port (locales ou distantes), et au besoin retransformer de socket TCP en socket UNIX de l'autre côté.
Cela fait plusieurs semaines que j'ai en tête de jouer avec ELK, et tes derniers tweets à propos de Suricata m'ont fait ajouter un item à ma todo list. Ravi d'avoir une image qui regroupe l'ensemble, avec Scirius en bonus. Merci. :)
Effectivement. C'est d'ailleurs l'occasion rêvée d'apprendre à faire un peu plus avec sed, comme la suppression ou l'ajout de ligne(s), en plus de la très connue substitution. ;)
Petit problème de mise en forme pour les différents types de sceau (WRITE et SEAL).
« Si vous n’avez jamais entendu parler des étiquettes de flux de flux (flow label) en IPv6 […] », je pense que c'est parce qu'il y a des mots en trop. ;)
C'est sympa de voir comment une distribution en retard (effectivement on ne voit que wayland/weston en version 1.6 dans testing/unstable) et pas wayland-ready finit par satisfaire tes besoins.
Ou bien, nous pourrions utiliser CPUSchedulingPolicy=idle pour s'assurer que les processus abrtd crashent en tâche de fond uniquement, en autorisant le noyau à donner sa préférence à tout ce qui fonctionne et qui a besoin de temps CPU.
Je pense qu'un s/crashent/tournent/ (ou une réécriture) s'impose.
D'après ma lecture de la VO, il s'agit plutôt de « s'assurer qu'ABRT traite les traces de crash en tâche de fond uniquement ».
dh_make peut effectivement faire un peu peur parce qu'il génère plein de fichiers.
Dans ton cas précis, tu auras principalement besoin de :
debian/changelog : descriptif des changements mais aussi définition de la version.
debian/compat : probablement '8' ou '9', pas pertinent de passer du temps là-dessus.
debian/control : tu auras ici plusieurs « stanzas », la première définissant le paquet source (nom, dépendances de build, mainteneur, etc.), les suivantes définissant les paquets binaires (nom, architecture, dépendances, description, etc.). Tu auras probablement envie d'avoir un -dev pour le .h et un autre paquet pour la bibliothèque. Attention aux changements futurs : en cas d'incompatibilité binaire (changement d'ABI) ton SONAME doit changer et le paquet être renommé en conséquence. On peut imaginer librustpinyin-dev et librustpinyin0 (en imaginant que tu fournisses libpinyinengine0.so) pour commencer.
debian/copyright : je ne te fais pas de dessin.
debian/rules : cf. ci-dessous.
Vu les informations données dans le README.md, tu pourrais probablement commencer par ce qui suit (en faisant attention à bien utiliser des tabulations plutôt que des espaces) :
#!/usr/bin/make -f
%:
dh $@
Cela permet d'avoir plein de choses gérées de façon automatique. Tu peux ainsi te concentrer sur ce qui a besoin d'être spécifique. Comme le système de build est particulier, il te faudra probablement commencer par :
override_dh_auto_configure:
# Do nothing
override_dh_auto_build:
cargo build
Concernant la ventilation des fichiers parmi les paquets binaires, le plus simple est probablement de lister les fichiers voulus dans debian/librustpinyin-dev.install et debian/librustpinyin0.install
Le canal #debian-mentors et la liste de diffusion debian-mentors@ sont les bons endroits pour poser des questions supplémentaires.
J'ai tendance à être un peu frileux concernant les histoires de flashing/rooting etc. (bricker un téléphone, jamais rigolo…) mais là je trouve cela vraiment rédhibitoire :
Step 1 (rooting) is necessary only once. Step 2 (upgrading) can be done everytime you want to upgrade Firefox OS
En parlant de PDF, c'est vraiment compliqué de partir de la norme… puisqu'il n'y a pas unicité. Des fonctionnalités peuvent très bien être normées et non supportées par les outils libres.
Je pense notamment aux signatures numériques : CAdES, XAdES, et donc dans le cas PDF : PAdES.
XFA semble ne pas encore avoir été accepté côté ISO mais les spécifications existent…
Prendre quelques minutes pour consulter la page de manuel d'xargs est probablement un bon investissement.
Une option ultra classique (avec -0/--null, déjà mentionnée) est -r/--no-run-if-empty, qui permet typiquement d'éviter de lancer une commande sans paramètre, ce qui peut éviter un code de retour en erreur et un script/crontab/etc. qui termine un peu trop vite parce que « set -e » avait été déclaré.
Un dernier commentaire sur ton problème : il y a déjà eu au moins un rapport de bogue concernant le support NCQ. S'il est compliqué de diagnostiquer le problème ou s'il s'avère que le matériel est bogué, cela peut finir par la désactivation de cette fonctionnalité pour ce matériel, afin que les utilisateurs suivants n'aient pas à jouer avec leur ligne de commande de noyau.
Bugzilla me semble être le point de passage incontournable, notamment si tu as envie que des gens qui s'y connaissent en NCQ, SATA II vs. III, etc. puissent jeter un coup d'œil.
OK, merci. [Même si la bonne réponse était 3.14.12-1~bpo70+1, cf. /proc/version ;)]
Probablement pas corrigé depuis (au moins au niveau de drivers/ata/pata_marvell.c) puisque les deux commits entre v3.14 et master ne sont que du clean-up (1bc18086231c130895b87ec049be8ddcdab552b8) et de l'ajustement concernant des options de compilation pour la gestion de l'énergie (58eb8cd565af4a104395e3c10443951c1f73dafe).
Je t'invite à donner un peu plus d'infos, notamment le numéro de version précis de ton noyau. Des fois, cela peut inciter des lecteurs désœuvrés à aller regarder s'il n'y a pas un correctif ou un contournement qui aurait été intégré entre temps, qu'il suffirait de backporter en le signalant sur la liste ou le bugtracker qui va bien. Dans tous les cas, un rapport de bogue dans ta distribution est (à ma connaissance) toujours une bonne idée.
<a
href="http://cdimage.debian.org/debian-cd/7.6.0/multi-arch/iso-cd/debian-7.6.0-amd64-i386-netinst.iso">Télécharger Debian 7.6<em>(installation par le réseau, PC 32 et 64 bits)</em></a>
s390x (remplaçant s390) ne comporte pas vraiment d'interface graphique à ma connaissance (c'est pour des mainframes). On peut jeter un œil à https://buildd.debian.org/quinn-diff/sid/Packages-arch-specific pour constater que la plupart des pilotes X ne sont pas compilés pour cette architecture.
Vérifier l'installabilité des desktops à proposer fait partie des évolutions que j'espère implémenter (cf. lien dans mon premier commentaire). Il devrait être possible de prendre en compte la disponibilité d'un miroir apt et la présence éventuelle de plusieurs images d'installation.
Par ailleurs, j'ai peut-être loupé quelque chose, mais le « média d'installation par défaut » n'existe pas à ma connaissance. Les liens sur le site web pointent vers des répertoires qui contiennent un certain nombre d'images en fonction de l'architecture :
- iso-cd/ : CD#1, CD#2, KDE CD#1, netinst, etc.
- iso-dvd/ : DVD#1, DVD#2, etc.
Certains utilisateurs vont foncer vers CD#1, vers $favorite_desktop CD#1, vers netinst. D'autres vers DVD#1.
La seule chose qui pourrait venir en tête est l'image amd64-i386 pour laquelle un lien est présent à la racine du site web. Or on n'essaie pas de mettre de desktop sur cette image à ma connaissance.
# Gnome Foundation ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Qui bosse sur Gnome?. Évalué à 5.
Probablement un bon point de départ pour avoir une idée de la gouvernance, des sponsors, etc. : http://www.gnome.org/foundation/
Il y a une section contenant des rapports financiers, les top contributeurs, ce qui devrait répondre en partie à tes questions.
Debian Consultant @ DEBAMAX
[^] # Re: /tmp, vraiment ?
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 1.
tmpreaper est ton ami.
Cela évite de dépendre d'un reboot (choisi ou subi) pour supprimer les fichiers qui traînent dans /tmp (depuis trop longtemps ou sur lesquels on était en train de travailler quand oh-zut-un-reboot).
Debian Consultant @ DEBAMAX
[^] # Re: /tmp, vraiment ?
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 3.
Utiliser cette variable (ou TMPDIR à défaut) dans un fichier de configuration peut être compliqué, d'où ma proposition. Je pense notamment aux paramètres ControlPath/ControlMaster de ssh_config.
Comme le note JoeltheLion dans sa réponse, on peut aussi passer par une création de répertoire temporaire sécurisée. Cela est relativement peu pratique pour les fois où l'on a à créer un fichier temporaire pour stocker un résultat intermédiaire, c'est pourquoi je proposais de s'habituer les doigts à taper ~/tmp au lieu de /tmp.
Debian Consultant @ DEBAMAX
# /tmp, vraiment ?
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Utiliser colout pour colorier tout ce qu'affiche GDB. Évalué à 3.
Réaction primaire : Cela ne coûte pas très cher d'utiliser ~/tmp au lieu de /tmp et cela peut rapporter gros… (Ne serait-ce que pour éviter de marcher sur les orteils du voisin, ou bien pour éviter les problèmes de sécurité triviaux.)
Debian Consultant @ DEBAMAX
[^] # Re: Forward/tunnel
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche 67 chaussettes pour OpenSSH. Évalué à 4.
On peut effectivement gagner en transparence mais on peut noter qu'il est déjà possible d'utiliser socat pour transformer une socket UNIX en une socket TCP, qu'on peut ensuite trimballer avec les redirections de port (locales ou distantes), et au besoin retransformer de socket TCP en socket UNIX de l'autre côté.
(Contexte typique : /var/run/pcscd/pcscd.comm, PKCS#11, etc.)
Debian Consultant @ DEBAMAX
# Quel timing
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche SELKS 1.0 : une distribution . Évalué à 4.
Cela fait plusieurs semaines que j'ai en tête de jouer avec ELK, et tes derniers tweets à propos de Suricata m'ont fait ajouter un item à ma todo list. Ravi d'avoir une image qui regroupe l'ensemble, avec Scirius en bonus. Merci. :)
Debian Consultant @ DEBAMAX
[^] # Re: Facile !
Posté par Cyril Brulebois (site web personnel) . En réponse au message [Résolu] Fichiers de configuration daemon. Évalué à 1.
Effectivement. C'est d'ailleurs l'occasion rêvée d'apprendre à faire un peu plus avec sed, comme la suppression ou l'ajout de ligne(s), en plus de la très connue substitution. ;)
Debian Consultant @ DEBAMAX
# Ajustements mineurs
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Linux 3.17. Évalué à 6.
Merci à tous pour la dépêche.
Quelques ajustements mineurs :
Debian Consultant @ DEBAMAX
[^] # Re: ca depend...
Posté par Cyril Brulebois (site web personnel) . En réponse au message Apprendre sur wayland. Évalué à 6.
C'est sympa de voir comment une distribution en retard (effectivement on ne voit que wayland/weston en version 1.6 dans testing/unstable) et pas wayland-ready finit par satisfaire tes besoins.
Debian Consultant @ DEBAMAX
# CPUSchedulingPolicy
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, parties 3, 4 et 5. Évalué à 1.
Je pense qu'un s/crashent/tournent/ (ou une réécriture) s'impose.
D'après ma lecture de la VO, il s'agit plutôt de « s'assurer qu'ABRT traite les traces de crash en tâche de fond uniquement ».
Debian Consultant @ DEBAMAX
[^] # Re: Script de build ?
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Bref j'ai créé une bibliothèque Rust et un moteur ibus (et je cherche comment les packager). Évalué à 3.
dh_make peut effectivement faire un peu peur parce qu'il génère plein de fichiers.
Dans ton cas précis, tu auras principalement besoin de :
Vu les informations données dans le README.md, tu pourrais probablement commencer par ce qui suit (en faisant attention à bien utiliser des tabulations plutôt que des espaces) :
Cela permet d'avoir plein de choses gérées de façon automatique. Tu peux ainsi te concentrer sur ce qui a besoin d'être spécifique. Comme le système de build est particulier, il te faudra probablement commencer par :
Concernant la ventilation des fichiers parmi les paquets binaires, le plus simple est probablement de lister les fichiers voulus dans debian/librustpinyin-dev.install et debian/librustpinyin0.install
Le canal #debian-mentors et la liste de diffusion debian-mentors@ sont les bons endroits pour poser des questions supplémentaires.
Debian Consultant @ DEBAMAX
[^] # Re: ABI Xorg
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Les pilotes libres et propriétaires des prochaines radeon partageront le même module noyau. Évalué à 2.
J'ai eu exactement la même réaction, un petit lien logique à ce sujet semble manquer. ;)
Debian Consultant @ DEBAMAX
[^] # Re: A passer en 2.0+
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Firefox OS sur ZTE Open C : la voie est libre, mais la route est encore longue…. Évalué à 6.
J'ai tendance à être un peu frileux concernant les histoires de flashing/rooting etc. (bricker un téléphone, jamais rigolo…) mais là je trouve cela vraiment rédhibitoire :
puis :
Sans moi.
Debian Consultant @ DEBAMAX
# openssl
Posté par Cyril Brulebois (site web personnel) . En réponse au message Konqueror ne valide pas les certificats SSL quand la connexion est mauvaise. Évalué à 4.
Mon réflexe quand il s'agit de déboguer des problèmes de type certificats SSL est le suivant :
Note : tu peux vouloir jouer les options -CApath/-CAfile (cf. -help).
Debian Consultant @ DEBAMAX
[^] # Re: Un format plus ouvert
Posté par Cyril Brulebois (site web personnel) . En réponse au journal PDF d'un site de l'administration illisible. Évalué à 3.
En parlant de PDF, c'est vraiment compliqué de partir de la norme… puisqu'il n'y a pas unicité. Des fonctionnalités peuvent très bien être normées et non supportées par les outils libres.
Je pense notamment aux signatures numériques : CAdES, XAdES, et donc dans le cas PDF : PAdES.
XFA semble ne pas encore avoir été accepté côté ISO mais les spécifications existent…
Debian Consultant @ DEBAMAX
[^] # Justificatifs sécurisés
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Coup de gueule : il devrait être obligatoire d'avoir une boîte aux lettres. Évalué à 2.
C'est typiquement le besoin que tente de couvrir 2D-DOC (http://www.2d-doc.com/), norme établie par des experts en dématérialisation en collaboration avec l'Agence Nationale des Titres Sécurisés (https://ants.gouv.fr/Les-solutions/2D-Doc).
Debian Consultant @ DEBAMAX
# Paramètres d'xargs
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à 5.
Prendre quelques minutes pour consulter la page de manuel d'xargs est probablement un bon investissement.
Une option ultra classique (avec -0/--null, déjà mentionnée) est -r/--no-run-if-empty, qui permet typiquement d'éviter de lancer une commande sans paramètre, ce qui peut éviter un code de retour en erreur et un script/crontab/etc. qui termine un peu trop vite parce que « set -e » avait été déclaré.
Debian Consultant @ DEBAMAX
[^] # Re: Détails, et rapports de bogue
Posté par Cyril Brulebois (site web personnel) . En réponse au journal stabilité du contrôleur SATA Marvell 88SE9230. Évalué à 6.
Un dernier commentaire sur ton problème : il y a déjà eu au moins un rapport de bogue concernant le support NCQ. S'il est compliqué de diagnostiquer le problème ou s'il s'avère que le matériel est bogué, cela peut finir par la désactivation de cette fonctionnalité pour ce matériel, afin que les utilisateurs suivants n'aient pas à jouer avec leur ligne de commande de noyau.
Le commit qui introduit la « blacklist NCQ » :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=67809f85d31eac600f6b28defa5386c9d2a13b1d
Bugzilla me semble être le point de passage incontournable, notamment si tu as envie que des gens qui s'y connaissent en NCQ, SATA II vs. III, etc. puissent jeter un coup d'œil.
Debian Consultant @ DEBAMAX
# Thanks!
Posté par Cyril Brulebois (site web personnel) . En réponse à l’entrée du suivi Prévenir de l'existence d'un login plutôt que de créer toto-0 etc.. Évalué à 0 (+0/-0).
Super, merci !
Debian Consultant @ DEBAMAX
[^] # Re: Détails, et rapports de bogue
Posté par Cyril Brulebois (site web personnel) . En réponse au journal stabilité du contrôleur SATA Marvell 88SE9230. Évalué à 5.
OK, merci. [Même si la bonne réponse était 3.14.12-1~bpo70+1, cf. /proc/version ;)]
Probablement pas corrigé depuis (au moins au niveau de drivers/ata/pata_marvell.c) puisque les deux commits entre v3.14 et master ne sont que du clean-up (1bc18086231c130895b87ec049be8ddcdab552b8) et de l'ajustement concernant des options de compilation pour la gestion de l'énergie (58eb8cd565af4a104395e3c10443951c1f73dafe).
Debian Consultant @ DEBAMAX
# Détails, et rapports de bogue
Posté par Cyril Brulebois (site web personnel) . En réponse au journal stabilité du contrôleur SATA Marvell 88SE9230. Évalué à 8.
Je t'invite à donner un peu plus d'infos, notamment le numéro de version précis de ton noyau. Des fois, cela peut inciter des lecteurs désœuvrés à aller regarder s'il n'y a pas un correctif ou un contournement qui aurait été intégré entre temps, qu'il suffirait de backporter en le signalant sur la liste ou le bugtracker qui va bien. Dans tous les cas, un rapport de bogue dans ta distribution est (à ma connaissance) toujours une bonne idée.
Debian Consultant @ DEBAMAX
[^] # Re: Jessie
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche FreeBSD 9.3 sort des cartons. Évalué à 3.
C'est correct :
(dixit https://lists.debian.org/debian-devel-announce/2014/08/msg00005.html)
Côté code c'était ici :
http://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=2f856a6ee682acae4b42f03ac7833012caaef776
Il y a aussi un fil de discussion sur debian-bsd@ à ce sujet :
https://lists.debian.org/debian-bsd/2014/07/msg00018.html
Debian Consultant @ DEBAMAX
[^] # Re: Tasksel
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 1.
Je parle de cela :
qui se trouve dans un encadré vert sur https://www.debian.org/
Pour les DVD, aucune idée, je n'ai jamais joué avec. Déjà trop de choses à gérer avec le reste. :)
Debian Consultant @ DEBAMAX
[^] # Re: Xfce vs GNOME vs KDE vs LXDE vs LXQt
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 5.
Petit tour rapide :
Debian Consultant @ DEBAMAX
[^] # Re: Tasksel
Posté par Cyril Brulebois (site web personnel) . En réponse au journal Quel environnement de bureau par défaut pour Debian Jessie ?. Évalué à 3.
Vérifier l'installabilité des desktops à proposer fait partie des évolutions que j'espère implémenter (cf. lien dans mon premier commentaire). Il devrait être possible de prendre en compte la disponibilité d'un miroir apt et la présence éventuelle de plusieurs images d'installation.
Par ailleurs, j'ai peut-être loupé quelque chose, mais le « média d'installation par défaut » n'existe pas à ma connaissance. Les liens sur le site web pointent vers des répertoires qui contiennent un certain nombre d'images en fonction de l'architecture :
- iso-cd/ : CD#1, CD#2, KDE CD#1, netinst, etc.
- iso-dvd/ : DVD#1, DVD#2, etc.
Certains utilisateurs vont foncer vers CD#1, vers $favorite_desktop CD#1, vers netinst. D'autres vers DVD#1.
La seule chose qui pourrait venir en tête est l'image amd64-i386 pour laquelle un lien est présent à la racine du site web. Or on n'essaie pas de mettre de desktop sur cette image à ma connaissance.
Debian Consultant @ DEBAMAX