Sygne a écrit 628 commentaires

Bon, j'ai la réponse: un ou deux jours pour attendre un code, puis un chronométrage de 15 jours.

Merci du commentaire, qui indique qu'un travail est en cours (fini?) pour le portage des sony XA2 sur LineageOS 16.

Manifestement, le lien donné plus haut indiquant la liste des téléphones compatibles avec LineageOS 16 est dépassée. Ça fait sens (cette liste date de plusieurs mois), mais enfin, elle restait jusqu'alors la seule information disponible.

C'est tout de même une bonne nouvelle, merci encore!

Par contre, comme pour le sony XA2, le support sur lineageOS 16 ne semble pas être prévu…

Par contre Xiaomi à un système assez énervant, il faut attendre 360h après avoir demandé le déverrouillage du chargeur de démarrage.

Euh… 360h soit 15 jours, ou 36h soit 1.5 jour?

Le nom international du Redmi Note 5 qu'on trouve en France est le "Redmi Note 5 Pro"

Est-ce qu'il s'agit bien de ce téléphone là chez ldlc?

J'aimerais que ce fil de discussion se poursuive, et parvienne à présenter un téléphone disponible actuellement, compatible avec lineageOS 15 et 16…

J'épluche la liste, mais jusqu'alors, mon revendeur habituel n'en connaît aucun…

J'aimerais bien, moi aussi, comprendre dans le détail pourquoi liberapay ne peut pas utiliser les services d'une banque. Vu de loin, ses besoins ressemblent à ceux des commerces en lignes, qui semblent se satisfaire des outils proposés par les banques.

En général une banque ne propose pas d'API. Quand j'ai parler de ça à une banquière, elle m'a dit : "oui vous avez une interface web pour envoyer votre fichier de paiement chaque mois…"

En même temps, j'imagine que si la banquière est cette même personne que tu vois tous les jours à l'agence, elle n'est peut-être pas l'interlocutrice idéale pour discuter de l'implémentation technique. Je veux bien croire que leurs services soient moins faciles à utiliser que ceux de boites spécialisés, mais je reste étonné qu'elles n'aient rien à proposer.

Make, c'est un vrai langage de programmation. Et comme tout langage de programmation, si on ne l'apprend pas, on n'arrive pas bien à l'utiliser. Certes, sa syntaxe est pluôt datée, et la documentation de Gnu Make est particulièrement pas efficace, mais Make reste, malgrès ces défauts, un langage plutôt facile à appréhender. Et si Gnu Make est mauvais, BSD Make est réputé meilleur…

Pour récupérer le nom d'un fichier sans son extension, Gnu make propose $(basename target), par exemple $(basename $<). Gnu Make propose aussi la possibilité d'effectuer des substitutions sur le nom des variables, ce qui peut peut-être répondre à ton besoin:

MYFILES = alpha beta gamma
MYHTML = $(MYFILES:%=%.html)
MYMKD = $(MYFILES:%=%.mkd)
MYDIR = /path/to/my/dir
MYTARGET = $(MYHTML:%=$(MYDIR)/%)

Pour que le makefile soit pris en compte lors de la génération de l'arbre des dépendances, on l'indique explicitement comme dépendance:

%.html: %.mkd Makefile
    markdown $< $@

Si cette syntaxe n'est pas amicale, on devrait pouvoir faire ainsi:

%.html: %.mkd
    markdown $< $@

%.html %.pdf %.odt %.dvi: Makefile

Non, aucune interface avec Emacs n'est prévue.

Mais l'interface de Emacs pour mh existe toujours: mh-e. Elle utilise mailutils-mh en arrière plan, qui est en fait spécialement développé pour mh-e. Le développeur de mailutils est du reste très actif, et utilise mh-e lui-même.

Oui, neatmail et mh sont tous les deux non interactifs, et je me demande si ce ne sont pas les deux seuls clients mail non interactifs. Si dans mon journal les deux se ressemblent, c'est que l'interface de mon script m s'inspire de mh.

Et effectivement, pour avoir essayé le mh de mailutils, je trouve qu'il est bien plus simple de travailler avec neatmail et un script. Mailutil-mh n'est pas toujours facile à configurer, et une large part de son comportement est codé en dur en C.

Je n'ai pas eu l'occasion d'essayer, mais il est possible que la commande ex de neatmail puisse être utilisée comme substitut de pick pour une recherche triviale:

:/^From:mail@example.com/cp pick.mbox

Outre pick, un outil performant pour ajouter des pièces jointes comme mhn manque probablement. J'utilise un script basique pour cela, qui, s'il me convient très bien, reste très limité.

En réponse à ma demande de précision, Ali Gholami Rudi a modifié la licence, préférant dorénavant la licence ISC.

ça fonctionne bien avec Unicode ?

Neatmail ne fait aucun transcodage. C'est donc ton éditeur qui devra gérer l'encodage du fichier que tu reçois, et s'assurer que tu réponds avec le même encodage.

Concrètement, sur nos linux d'aujourd'hui, ce sont plutôt les encodages non unicode qui demanderont peut-être un transcodage manuel. Et si tu communiques avec des personnes qui ont des clients mails qui ne considèrent pas qu'unicode est l'encodage par défaut (mais est-ce que ça existe encore?), il faudra vraisemblablement construire des mails de type Mime, et indiquer l'encodage.

Le seul hic, c'est lorsque le sujet d'un mail contient des caractères non unicode: ceux-ci s'afficheront mal dans la liste générée par neatmail, qui sera alors composée de plusieurs encodages.

Mais pour ma part, il n'y a qu'un organisme qui m'envoie encore des mails non unicode, et comme il ne veut pas qu'on lui réponde par mail, je ne me soucis pas outre mesure de ce problème.

Est-ce qu'un modérateur pourrait corriger les nombreuses fautes contenues dans cet article s'il vous plaît?

• Le nom du développeur s'écrit Ali Gholami Rudi (et non Ali Golhami Rudi).
• Il ne sait pas ni rapatrier -> Il ne sait ni rapatrier,
• propose ainsi de pop3 -> propose ainsi un pop3
• et smtp. pour envoyer -> et smtp pour envoyer

Merci!

Il n'y a pas grand chose à montrer, sinon, peut-être, la liste des mails telle qu'elle est rendue par la commande neatmail mk ‐r ‐0 18from:48~subject.

R0051   [Dave Kemper <saint]    [[groff] vertical resolution and page location tr]
R0052   [Werner LEMBERG <wl]     [+[groff] vertical resolution and page location ]
R0053   [Werner LEMBERG <wl]      [+[groff] vertical resolution and page location]
R0054   [Tadziu Hoffmann <h]      [+[groff] vertical resolution and page location]

Pour le reste, j'imagine que chacun utilisera son éditeur préféré avec la coloration syntaxique adéquate.

La licence mérite probablement clarification, mais elle est indiquées dans les sources de mail.c: « modified BSD license ».

C'est surtout parce que la problématique s'est déplacée, et que les licences libres ne suffisent plus à y répondre. Une licence libre répondait plutôt bien à l'enjeu de maîtrise de son outil de travail à l'époque de l'ordinateur personnel, mais pas du tout à l'enjeu de maîtrise de ses données personnelles à notre époque. On peut maintenant respecter à la lettre la licence d'un logiciel libre, sans accorder de droits à l'utilisateur du même logiciel.

Bref, c'était très frustrant de devoir débattre à 4 sur 40mn sur un sujet aussi vaste.

La frustration doit être inhérente au fait de débattre, parce que ce débat était plutôt réussi. ;)

Merci pour le compliment, ça fait plaisir!

ça fait moins peur que mutt

Par contre, à mon avis, ça devrait faire plus peur que mutt. Mutt n'aura besoin que d'être configuré, et je suis certain qu'on trouve en ligne des exemples basiques.

Pour neatmail, il faudra déjà compiler neatmail, pop3, smtp. Pop3 se configure via modifications des sources, et demandera les certificats pem pour se connecter au serveur en ssl. Et ensuite il faudra encore écrire le script shell pour avoir quelque chose d'utilisable.

J'ai trouvé le tout très plaisant, mais honnêtement, ça fait peur. :)

J'avoue que les deux critiques de make exposées dans le journal me laissent coi…

Il m'arrive encore de créer des petits Makefiles manuellement mais c'est vite pénible.

C'est pas faux ! Mais d'un autre côté, je n'ai pas l'impression que l'on ait à modifier le makefile bien souvent, sinon pour ajouter une dépendance, ce qui prend trois secondes. Donc ce temps perdu peut vite ressembler à du temps gagné si, par ailleurs, (BSD)make fait le boulot.

Un autre point difficile à gérer concerne la dépendance au fichier Makefile lui-même.

Trop gros, passera pas.

C'est effectivement la liste des logiciels libres grand public qui se sont fait une petite place sur le marché. Mais justement, face à leurs concurrents (IE, Microsoft Office), ils n'occupent qu'une petite part de marché.

Ce que les invités de cette discussion mettaient en avant, était le contraste saisissant entre une présence minoritaire du logiciel libre dans les produits finaux et une présence probablement majoritaire dans les briques logicielles bas niveau.

Oui, il manque les deux points après « http ». En outre il manque le point d'interrogation à la fin de, « Que reste-t-il du logiciel libre ».

Est-ce qu'un modérateur passant par là pourrait corriger ces fautes s'il vous plaît?

J'avoue avoir eu du mal à comprendre moi aussi. dicollecte.org est le site dédié au développement collaboratif du dictionnaire français de hunspell et grammalecte.

Par contre, je n'ai pas trouvé la forge dédiée.

Voir le Bépo reconnu par l'afnor est une vraie bonne nouvelle. Surtout, que, d'après la dépêche, l'afnor met clairement en avant l'intérêt du Bépo:
- La seule raison d'être de l'azerty est historique,
- Le Bépo est qualifié d'ergonomique et d'efficace pour la saisie du français.

Le problème semble être résolu maintenant…

Oui, je n'ai constaté le problème qu'aujourd'hui, mais n'ai pas envoyé de mails ces derniers jours…

Merci.

Merci!

Je ne sais pas comment ltsp sert cette image système, mais cela semble revenir au même qu'une racine servie par NFS: le client exécute les programmes localement, mais a besoin d'accéder à l'exécutable au préalable via le réseau.

Si c'est tout à fait fluide lorsque la connection se fait par wifi, il n'y a probablement pas de raison de persévérer dans mon idée de clients ayant chacun leur système de fichier à synchroniser avec le serveur.