Victor STINNER a écrit 1632 commentaires

Aucun bug n'est spécifique à Fedora. Le premier était un bug Firefox (remonté à Firefox), le second un bug Gtk (remonté à Gtk, mais il était déjà corrigé, alors j'ai backporté le corrrectif dans Fedora).

"quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie…"

Sur quels paquets avais-tu rapporté des bugs ?

Utilisateur de Fedora de longue date, j'ai aussi vu plusieurs de mes bugs rapportés à Fedora rester lettres mortes.

Déjà, il faut comprendre que Fedora est une distribution Linux, et non pas l' "upstream" du projet. Le ou les responsables d'un paquet ont parfois des connaissances limitées du projet qu'ils empaquetent. Il n'est pas rare qu'une seul personne soit responsable d'une dizaine de paquet, sinon plus.

Parfois, le bug est rare et difficile à reproduire. Je maintiens Python pour Fedora, et récemment on a reçu un bug que le rapporteur reproduisait sans problème, alors qu'en s'y mettant à 4, aucun n'a réussi à reproduire le bug. Même en demandant des informations complémentaires à plusieurs reprises, on n'a pas réussi. Il faut comprendre que Fedora est un système complet : un bug dépend rarement d'un seul composant, c'est souvent la combinaison des plusieurs composants dans des versions précises combinées à une configuration utilisateur particulière. Reproduire la configuration de l'utilisateur produisant le bug n'est pas trivial. Exemple anodin : certains bugs dépendent de la locale (langue) de l'utilisateur.

Mais plusieurs fois, le bug que j'ai rapporté a été corrigé entre 1 semaine et 1 mois.

Fedora a un outil génial pour collecter des traces lors d'un crash ABRT. L'outil reconstruit la pile d'appel via un serveur dédié sans que l'utilisateur ait besoin d'avoir l'outillage (notamment les symboles de debug) installés en local. C'est efficace, mais encore une fois, "voir" un crash ne suffit pas à reproduire les conditions qui permettent de reproduire le bug.

Certains packageurs sont employés par Red Hat. Certains sont volontaires. Certains travaillent uniquement sur Fedora. Certains travaillent sur Fedora et RHEL. Il y a beaucoup de cas.

Firefox fait parti des dernières applications de mon desktop GNOME utilisant encore l'API X11 et nécessite le serveur Xwayland (émulation X11 pour Wayland). Parfois au lancement, la fenêtre Firefox était à moitié noire (genre à moitié dessinée), alors le motto Wayland est “Every frame is perfect” (chaque image est parfaite).

J'étais un des premiers à tester Wayland sous Fedora, en choisissant volontairement "GNOME (Wayland)" au login. Au début, plusieurs features me manquaient avec Wayland : raccoucis clavier (ALT+e pour lancer un terminal, m'enfin !) et capture d'écran. gnome-screenshot et GIMP peuvent à nouveau faire des captures d'écran. Le partage d'écran fonctionne dans Bluejeans. Et je peux à nouveau définir des raccourcis clavier via gnome-shell (à configurer dans les paramètres globaux de GNOME).

Dans Fedora 30, j'ai forcé l'usage de Wayland pour Firefox en mettant MOZ_ENABLE_WAYLAND=1 dans /etc/environment. Il est aussi possible de lancer "firefox-wayland", mais je préfère taper ALT+F2 puis "firefox" (plus court !) :-)

Bref, ça marchait bien jusqu'à une régression il y a une semaine :-( Entre deux versions mineures de Firefox 69, le rendu Wayland s'est mis à produire plein de glitches assez pénible à l'usage :
https://bugzilla.mozilla.org/show_bug.cgi?id=1580152

Je suis plutôt content car mon collègue Martin Stránský a rapidement eu vent du bug et travaille d'arrache pied sur un correctif. Ce matin j'ai lu "Martin, I installed the firefox-69.0-7.fc31 build you did today and it does seem to fix this, on my local system at least. Not sure if it fixes the openQA issue yet (it'll be easier to tell when it's submitted as an update). Thanks!". À priori, le bug vient d'être corrigé dans Fedora 31 (mais pas encore dans Fedora 30).

Au passage, j'ai galéré à comprendre d'où venait le bug. Mon laptop a 2 GPUs ce qui rend le debug plus complexe. J'ai écrit un article pour expliquer cette technologie du futur un peu bizzare qui vise à augmenter l'autonomie des laptops, "Hybrid Graphics" :

"Hybrid Graphics issues on Linux"
https://vstinner.github.io/debug-hybrid-graphics-issues-linux.html

--

Par le passé, j'avais déjà eu un bug majeur avec Firefox + Wayland, que j'ai du corrigé moi même en backportant un correctif Gtk. Sélectionner plus de 4000 caractères plantait tout Firefox :-( CTRL+a dans Gmail plantait Firefox, super pénible.

https://bugzilla.mozilla.org/show_bug.cgi?id=1539773
https://gitlab.gnome.org/GNOME/gtk/issues/1783
https://src.fedoraproject.org/rpms/gtk3/pull-request/5

La bonne nouvelle est qu'avec le libre, on peut corriger les bugs soit même si on sait faire ;-)

J'ai entendu qu'il y a une corrélation entre l'envolée de la popularité de Python et l'envolée de la popularité du {machine learning, data science, numpy, scipy, pandas, scikit-learn, etc.} : le milieu scientifique assez éloigné du développement logiciel classique.

J'ai entendu que doucement Python "remplace" plusieurs outils existants. Je ne saurai les citer, mais au pif je dirai : Matlab au moins (le seul que j'ai touché). À ce que j'ai compris, Python est supérieur aux outils existants parce qu'il est gratuit (hé oui), qu'il facilite l'intégration d'outils hétérogènes de métiers différents, et qu'il vient avec une grosse suite d'outils qui facilitent la vie (stdlib entre autres, genre lire un CSV dans un ZIP est trivial). Les notebooks Jupyter vont encore plus loin dans le remplacement de Matlab.

Quand je dis "milieu scientifique", c'est assez large. Récemment, j'ai appris que Python commence à remplacer les outils utilisés historiquement dans le domaine de l'astronomie (genre https://www.astropy.org/ ?).

En même temps, chaque fois qu'un outil s'améliore dans un métier, il peut être réutilisé dans un autre métier, parce que Python est maléable et permet de bien intéger des outils divers et variés (c'est sa force historique).

Perso je reste bluffé que le coeur de numpy/scipy reste du super vieux code (10 ans ? 20 ans ? je ne sais pas) écrit en Fortran. Info à vérifier, pas sûr des dates. Mais on m'a dit "le code marche et a été prouvé (stabilité numérique), pourquoi changer ?". Il existe des projets pour réécrire des briques de base (calcul matriciel) en C, mais l'existant en Fortran reste très populaire : OpenBLAS si ma mémoire est bonne. GitHub me dit qu'OpenBLAS est constitué de 50% de Fortran, 27% d'assembleur, 20% de C (+ qq. autres langages) : https://github.com/xianyi/OpenBLAS Ou bien peut être que je confonds avec ATLAS, une autre implémentation de l'API BLAS aussi écrite en Fortran.

Quand je lis LinuxFR sur téléphone, les liens Markdown et Epub sont gros et il m'arrive souvent de cliquer dessus par erreur. Je pense qu'il faudrait virer ces liens de la page d'accueil et des journaux. Uniquement afficher les liens quand on est sur la page d'un article.

La raison serait "Dû à un problème de filtrage sur l'adresse e-mail lors de l'inscription, …"

Il s'agit du bug https://bugs.python.org/issue34155

Journal Med Hondo (Voix francaise de L'Âne dans Shrek, Morgan Freeman, …) bronsonisé

Voix française de https://fr.wikipedia.org/wiki/Eddie_Murphy également.

_ tout court est utilisé par convention pour assigner une variable qui n'est pas utilisée. L'exemple typique est for _ in range(3): print('Bonjour') : l'itérateur est inutilisé. Autre exemple : nom, _, domaine = email.partition('@'), le 2e élément du résultat ("@") est ignoré. J'ai vu des cas avec plusieurs _ : x, y, _, _, z = func(). Bon, il ne faut pas en abuser :-) C'est purement une convention, la variable existe et on peut la lire :-)

Dans le REPL, _ est une variable magique qui contient le dernier résultat. Magique car elle est définie dans le module builtins : c'est la variable builtins._.

$ python3
>>> 1+1
2
>>> _
2
>>> import builtins; builtins._
2

gvim.exe

Il y a d'excellents outils Windows pour la sécurité informatique. Aujourd'hui j'ai vu passer un système de fichier pour monter une copie de la mémoire, "The Memory Process File System" :
* https://github.com/ufrisk/MemProcFS
* https://twitter.com/UlfFrisk/status/1067117027075260417

Et ils ont rajouté deux mots-clés. Non mais vraiment, j'aime bien python, j'aime bien son développement, mais on ne rajoute pas des mots-clés sur des versions intermédiaires. Ça casse tout.

async/await ont levé un DeprecationWarning depuis Python 3.5, sauf que ce warning était caché par défaut. D'où le travail sur l'affichage de ce warning dans __main__ et ma nouvelle option -X dev pour afficher tous les warnings partout. On ajoute des warnings, après si les devs ignorent les warnings…

Usez et abusez de PYTHONDEVMODE=1 à partir de Python 3.7 ! Pour les anciennes versions, perso j'utilise l'option -Wd (abbréviation de "-W default" pour afficher DeprecationWarning et ResourceWarning, par exemple).

Quelques liens sur la faille et OpenBSD :

• https://www.youtube.com/watch?v=UaQpvXSa4X8: video du talk de Theo de Raadt, "speculating intel"
• https://twitter.com/cperciva/status/1007010583244230656?lang=fr : tweets de Colin Percival qui explique le contexte dans lequel il a écrit un exploit suite à ce talk
• changement OpenBSD : https://marc.info/?l=openbsd-cvs&m=152818076013158&w=2
• changement DragonflyBSD : http://lists.dragonflybsd.org/pipermail/commits/2018-June/672324.html
• mail sur la liste oss-sec au sujet de l'embargo : http://seclists.org/oss-sec/2018/q2/184
• thread HackerNews sur la faille : https://news.ycombinator.com/item?id=17304233

Pour cette faille, je vois que l'embargo était prévu après le 13 juin 2018, et Theo de Raadt a donné une conférence sur la faille le 9 juin. C'est moi ou bien Theo ne respecte pas les embargos, puis il râle qu'on ne le mette pas dans le secret ?

Pour les failles Meltdown et Spectre, le projet OpenBSD avait râlé qu'ils n'avaient pas été inclus dans l'embargo.
https://marc.info/?l=openbsd-tech&m=151521435721902&w=2

Autre exemple au pif trouvé sur l'Internet : "OpenBSD has a reputation for not respecting embargoes, even as recently as the KRACK wifi thing last year".
https://news.ycombinator.com/item?id=16440948

Info à la source : "What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed."
https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz

Je comprends : "Nous, OpenBSD, décidons de la date de l'embargo."

Ensuite, faut pas venir pleurer et faire sa victime après…

Je trouve le comportement d'OpenBSD et de GRsecurity assez similaire. Leur seul argument de vente est la sécurité et ils ont du mal à collaborer.

Après j'suis pas un grand fan des embargos, et je trouve le projet Zero de Google assez courageux sur le très court délai avant publication des détails d'une vulnérabilité (genre 7 jours pour les failles les plus graves, 90 jours au pire).
https://en.wikipedia.org/wiki/Project_Zero

Après systemd, systemd dit que tout est OK si le service est désactivé.

Après systemd, status donne beaucoup plus d'infos !

"Tasks: 0 (limit: 4915)"

0 processus pour un démon, c'est quand même louche

"juin 12 13:25:29 zoro burp[16880]: burp disabled; edit /etc/default/burp"

systemd montre aussi les logs, ce qui me semble très pertinent dans ce cas précis :-)

Depuis le rachat, LinkedIn me propose aussi de suivre un seul et unique "influenceur": Bill Gates.

Je pense que l'IA LinkedIn est imparable et que tu rêves intimement d'être influencé par Bill Gates.

Tout les dépôts OpenPaperwork seront migrés sur gitlab.gnome.org (changement prévu de longue dates de toute façon).

Je suis tombé sur https://twitter.com/movingtogitlab hier : GitLab fait face à une montée en charge depuis les premières rumeurs de rachat. Il risque d'y avoir qq. soucis de perf ces prochains temps ;-)
https://www.dropbox.com/s/uzg9vc5oljr8lin/Screenshot%202018-06-03%2015.52.52.png?dl=0

Oh… Je ne savais pas que Seb s'était suicidé :-( Père de deux enfants, il s'est suicidé à cause d'un chagrin d'amour selon ce que j'ai lu :-(

• https://www.nextinpact.com/archive/Deces_de_Sebansky_ex_deJoystick.htm
• https://fr.wikipedia.org/wiki/S%C3%A9bastien_Hamon

OpenStack Horizon

OpenStack tout court. Càd plusieurs millions de ligne de code.

https://www.openhub.net/p/openstack

"In a Nutshell, OpenStack has had 942,125 commits made by 10,764 contributors representing 9,105,385 lines of code"

75% de Python

Donc je vais la faire cross-platform*, mais aussi cross-langages. Le plan, c'est d'utiliser la GLib et l'introspection GObject pour pouvoir générer des bindings pour un peu tout les langages facilement.

Utiliser GLib directement dans la lib bas niveau rend la lib dépendante de la GLib, ce qui peut être un soucis pour l'utiliser avec Qt. (Question de guerre de clocher.)

Pourquoi ne pas avoir une lib en C avec une API en C et fait des appels C depuis Python avec cffi ?

Je suppose qu'idéalement ta lib serait réutilisée par Gnome Simple Scan et autres outils similaires.

J'ai notamment écrit la PEP 564 "Add new time functions with nanosecond resolution" pour Python 3.7 car le type float de Python (IEEE 754) perd de la précision quand on manipule des dates avec une précision d'une nanoseconde.
https://www.python.org/dev/peps/pep-0564/

Python 3.7 permet maintenant de lire l'heure sous forme d'un nombre de nanosecondes, nombre entier (int), plutôt qu'un nombre de secondes, nombre floattant (float).

Je bosse sur le projet Python qui manipule des durées dans des tas de format différents : time_t (secondes), timespec (secondes et nanosecondes), timeval (secondes et microsecondes), nombre de millisecondes (pour appeler poll()), etc. J'ai choisi d'utiliser le type C int64_t (appelé _PyTime_t dans pytime.c ci-dessous) avec une unité d'une nanoseconde (note : cette unité ne fait pas partie de l'API publique, c'est censé être interne).

pytime.c:
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/Python/pytime.c

Les systèmes d'exploitation aiment la diversité. Windows fournit QueryPerformanceCounter() : nombre à diviser par QueryPerformanceFrequency() pour obtenir des secondes. En utilisant des nombres flottants, la division est facile à réaliser. Mais en utilisant des nombres entiers (_PyTime_t), euh, c'est plus difficile, surtout pour éviter un integer overflow (dépassement de capacité du type int64_t provoquant des erreurs de calcul). J'ai notamment écrit _PyTime_MulDiv() pour QueryPerformanceCounter() :
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/Python/pytime.c#L46-L61

Avec un peu de mathématique, on évite l'integer overflow en pratique :

(ticks * mul) / div == (ticks / div) * mul + (ticks % div) * mul / div
Le code gère 4 modes d'arrondi (_PyTime_ROUND_HALF_EVEN, _PyTime_ROUND_CEILING, _PyTime_ROUND_FLOOR, _PyTime_ROUND_UP) car en plus, selon le besoin, il faut arrondir différemment… Depuis 2012, j'ai du corriger 4x les arrondis…
https://vstinner.github.io/pytime.html
(cet article date de février 2016, il ne mentionne pas le dernier correctif de 2017)

En utilisant l'Epoch Unix (1er janvier 1970) comme référence, ce type permet de stocker des dates de l'année 1678 à l'année 2262. Vous me direz que c'est largement suffisant. Sauf que Python fournit le module datetime qui gère des dates de l'année 1 à 9999. Pour ce module, il faut conserver le type time_t (qui peut être en 32-bit ou 64-bit selon la plateforme) pour gérer des dates "extrêmes". Bien sûr, jouer avec de telles dates provoque des soucis sur certaines plateformes comme Windows, AIX ou Solaris.

Le noyau Linux a un type opaque ktime_t https://lwn.net/Articles/167897/ mais ce type n'est pas (forcément) un entier, et on ne peut pas écrire t1 + t2 ou t2 - t1, contrairement au type _PyTime_t.

This type, found in , is meant to be used as an opaque structure. And, interestingly, its definition changes depending on the underlying architecture. On 64-bit systems, a ktime_t is really just a 64-bit integer value in nanoseconds. On 32-bit machines, however, it is a two-field structure: one 32-bit value holds the number of seconds, and the other holds nanoseconds.

Gérer le temps, c'est simple ! Bon, maintenant on va parler des timezones et de changement d'heure d'été …

Soit un mini programme :

    use std::io;
    use std::io::Read;
    use std::fs::File;

    fn readfile() -> Result<String, io::Error> {
        let mut f = File::open("hello.txt")?;
        let mut s = String::new();
        f.read_to_string(&mut s)?;
        Ok(s)
    }

    fn main() {
        let bla = readfile();
        match bla {
            Ok(_) => println!("success"),
            Err(e) => println!("failure {}", e),
        }
    }

Le fichier hello.txt fait 10 Mo, et je limite la mémoire du programme à 20 Mo avec "ulimit -v 20000". Résultat : le runtime Rust affiche "fatal runtime error: allocator memory exhausted", puis le programme Rust plante avec le signal SIGILL (Illegal instruction).

Sur IRC, on m'apprend que Rust n'a pas encore implémenté la gestion d'erreur sur les allocations mémoires. Ah. C'est dommage ça.

• RFC : https://github.com/rust-lang/rfcs/pull/2116
• Bug : https://github.com/rust-lang/rust/issues/32838

De là à appuyer tout l'argumentaire de Rust sur "les programmes écrits en C et C++ peuvent planter, un code écrit en Rust ne peut pas planter", je trouve que ça méritait quelques précisions :-) (Par planter je veux dire : signal fatal genre SIGSEGV… ou SIGILL.)

En attendant, j'ai remis au propre l'app Mailman (2.x) (…) l'interface web est affreuse.

C'est un peu dommage d'avoir choisi Mailman 2 quand Mailman 3 est dispo et que son interface web est plus jolie ! Exemple au pif : l'interface web publique pour consulter les archives de la liste buildbot-status@python.org (une des premières à avoir migré à Mailman 3).

https://mail.python.org/mm3/archives/list/buildbot-status@python.org/

Pour avoir connu l'interface d'admin de Mailman 2, euh, je préfère carrément celle de Mailman 3. Pour info, on m'a dit que l'interface web ne permet pas encore de configurer tout ce que sait faire le backend.

Je ne sais pas pour Sympa, mais je peux dire que la migration à GitHub début de l'année a reboosté les contributions à CPython ! Je pense que c'est plus simple pour les contributeurs d'écrire une pull request et de la faire vivre jusqu'à ce qu'elle soit intégrée. D'ailleurs, les tests sont désormais lancés sur les pull requests, ce qui a beaucoup aidé !

CPython a implémenté une optimisation similaire dans Python 3.3:
https://www.python.org/dev/peps/pep-0393/

Si une chaîne ne contient que des caractères dans U+0000-U+00FF ("Latin1") : 1 octet par caractère. Que dans U+0000-U+FFFF ("BMP") : 2 octets par caractères. Sinon ("Astral"), 4 octets par caractère (désolé pour vos jolis emojis). Du coup, "toto" prend 4 octets au lieu de 16 avec Python 2 (en ignorant les entêtes des objets).

Je pense qu'il veut dire que l'exploit trouve par la NSA EternalBlue, a été développé volontairement par Microsoft.

Euh non pas du tout. Attention, je connais très Windows. J'ai répêté les infos que j'ai entendu à droite et à gauche. Mais je pense qu'il est encore tôt pour comprendre en détail ce qui s'est passé.

Ce que je voulais dire : c'est que le malware est assez malin et sait exploiter correctement les fonctionnalités d'administration de Windows. Je ne vois pas ce qu'il y a d'étonnant à ce qu'un admin puisse modifier des postes clients. Linux a des technologies similaires.