Jean-Baptiste Faure a écrit 1860 commentaires

C'est rigolo parce que les paquets Debian n'ont pas ces problèmes (à ma connaisance)!

Les paquets Ubuntu non plus à ma connaissance à moi, c'est pour cela que j'aimerais savoir sur quelle distribution ces paquets sont utilisés.
René Engelhard est effectivement un développeur LibreOffice, tout comme Bjoern Michaelsen (Canonical) qui est mainteneur des paquets pour Ubuntu.

Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar.

Ce paquet Ubuntu, tu le fais tourner sur Ubuntu / Unity ou bien sur une dérivée d'Ubuntu ?
Parce qu'il y a les mêmes problèmes avec les distributions et leurs dérivées qu'avec les logiciels upstream vs. packaging des distributions.

et ca ne correspond pas à l'enoncé premier de detecter si tu es sous windows natif ou sous linux natif
en effet l'appel system lors de l'execution devrait permettre de detecter l'OS
mais ce n'est alors pas à la compilation que tu detectes l'OS sur lequel tu compiles, mais bien à l'execution
du programe

Mon problème n'est pas la compilation, je compile toujours sous Linux, même pour produire un exécutable win32 ou win64. Là il n'y a pas de détection d'OS, juste un switch dans le makefile.

avec un simple ls ou un dir
ca devrait deja te dire si la commande existe ou pas,
et si elle n'existe pas, c'est que tu n'es pas sur l'OS visé (ls = linux, dir = windows)

Non, justement c'est le même cas que celui de mon 1er résultat : sous Linux, un programme win64 exécuté avec Wine me répondra que la commande ls n'existe pas et que la commande dir existe, donc ça ne me permet pas de savoir que l'OS sous-jacent est Linux. En plus il faut analyser la réponse pour détecter l'erreur, c'est plus compliqué que juste récupérer un booléen me disant si le fichier /bin/. existe ou pas. Le bout de code Fortran pour faire cela pourrait être quelque chose comme ça :

detection_Wine: block
logical :: bExist
inquire(file='/bin/.',exist=bExist)
if (bExist) slash='/'
end block detection_Wine

avec slash une variable définie précédemment en fonction de la variable OS définie à la compilation pour l'OS cible et insérée dans le code grâce à un include.

J'ai fait quelques essais ce matin :
- exécuter une commande genre uname : ça ne marche pas car c'est Wine qui répond et il ne connaît pas les commandes Linux ;
- analyser la variable d'environnement PATH : encore raté, si le code tourne sous Wine, c'est le PATH Windows qui est renvoyé ;
- tester l'existence du fichier /bin/. : ça ça marche

Au final, cependant, changer le séparateur de fichier seulement sur la base de l'OS cible et de l'OS hôte, complique les choses. Je peux tester avec Wine un code Windows sur des données Linux, mais je ne peux plus tester avec Wine un code Windows sur des données Windows. Donc ça ouvre une porte et ça en ferme une autre.
Du coup, je pense que le plus raisonnable est de laisser la main à l'utilisateur sur cette question, surtout que l'utilisateur en question c'est moi, les autres utilisateurs ne se poseront pas cette question. J'ai donc implémenté la lecture d'une variable d'environnement ad-hoc qui me permet de changer le séparateur de fichier seulement quand je le décide explicitement. Une option de la ligne de commande serait plus compliquée à implémenter car il y a une autre option avec un nom de fichier, donc potentiellement un séparateur de fichier, il me faut donc fixer le séparateur de fichier avant de décoder la ligne de commande.

En tous les cas un grand merci à tous pour vos commentaires.

À part le nombre de cpu disponibles qui s'obtient à l'exécution avec OpenMP, les autres détections me semblent devoir être faites à la compilation. Et comme la production des exécutables Windows est faite sous Linux, c'est un exécutable générique que je produis. Je n'ai pas trouvé de réglage plus efficace que l'option -O3 de gcc/gfortran.

Oui tu as raison, j'ai retrouvé où C. Villani en parle dans son bouquin : chapitre 31, où il parle de sa rencontre avec Voevodsky dans un parc à Princeton, de la preuve du théorème des quatre couleurs, de l'Inria, de Georges Gonthier et son travail sur COQ.

J'ai écrit que Villani et Mouhot avaient utilisé Coq pour vérifier leurs démonstrations : celles de Villani et Mouhot. Ils ne travaillent pas sur Coq mais avec Coq.

Je pense que c'est déjà le cas pour certains mathématiciens. Dans Théorème vivant on voit que Cédric Villani et Clément Mouhot utilisent un outil de calcul formel pour manipuler leurs équations ainsi que Coq pour vérifier leurs démonstrations.

Ah, merci. Je n'ai pas le réflexe stackoverflow, je devrais. Et puis j'aurais du refaire ma recherche en restreignant la question à celle du séparateur de fichier. Je vais faire des essais lundi avec une fonction inspirée de ce bout de code. Je suis curieux de voir quelle valeur de PATH je vais obtenir à travers Wine.

Cela dit la question n'est pas si souvent posée. Celle qui l'est c'est celle à laquelle a répondu Sytoka et ça je fais déjà.
Une autre présentation de mon problème : comment mon exécutable win32 ou win64 peut-il détecter qu'il tourne en réalité sur une machine Linux avec Wine ?

Une autre piste : Fortran 2008 permet de tester l'existence d'un fichier ou d'un dossier, je peux tester l'existence de /bin ou /boot pour savoir si l'OS est Linux, à moins qu'il y ait un problème de droits pour obtenir une réponse. Je testerai.

Oui à peu près, mais là c'est juste pouvoir décider si slash = '/' ou slash = '\' de façon que le décodage des chemins fonctionne dans tous les cas. ;-)

À la réflexion, ce dont j'ai besoin pour l'instant c'est en fait détecter si le code est en train de tourner sur une machine Linux. Donc un script basé sur la commande uname devrait me donner la réponse, il faut juste que je traite correctement l'échec du script dans le cas où je le fais tourner sur MS-Windows.
S'il y avait une variable d'environnement qui donne l'info ce serait quand même plus pratique.

The Document Foundation a publié en urgence les versions 5.4.5 et 6.0.1 pour corriger des graves régressions sur 6.0.0 pour MS-Windows et une faille de sécurité pour 5.4 et 6.0.

http://blog.documentfoundation.org/blog/2018/02/09/early-availability-libreoffice-5-4-5-libreoffice-6-0-1/
http://nabble.documentfoundation.org/Publication-anticipee-de-LibreOffice-5-4-5-et-LibreOffice-6-0-1-tp4232542.html
https://www.libreoffice.org/about-us/security/advisories/

Mettez-vous à jour !

Destructuration malheureuse du navigateur et page de style en un machin énorme où il faut cliquer partout

De quoi tu parles là ? Le navigateur et le styliste n'ont pas fondamentalement changé. Ils sont juste empaquetés dans le volet latéral.

point 4 : https://bugs.documentfoundation.org/show_bug.cgi?id=106781 : Addition of a style-focused formatting toolbar
mais c'était déjà dans la 5.4 : https://wiki.documentfoundation.org/ReleaseNotes/5.4/fr#Writer

L'explication dans les notes de version : https://wiki.documentfoundation.org/ReleaseNotes/6.0/fr#Enregistrement_in-situ_des_images_modifiées

Le rapport de bug a été créé par Julien Nabet : https://bugs.documentfoundation.org/show_bug.cgi?id=115471
et il a été confirmé.

Il n'est pas nécessaire de savoir compiler LibreOffice pour faire un rapport de bug très détaillé :
https://wiki.documentfoundation.org/QA/BugReport
On peut facilement installer une version de développement en parallèle de son installation normale pour vérifier si le bug est reproductible sur les version les plus récentes. On peut aussi installer des anciennes versions pour vérifier s'il s'agit d'une régression. Enfin, si on est très impliqué et qu'il s'agit bien d'une régression on peut utiliser l'infrastructure prévue pour ça pour "bibisecter" le bug afin de localiser le commit à l'origine de la régression.
https://wiki.documentfoundation.org/QA/Bibisect

Je viens d'installer une mise à jour avec cette fois une nouvelle version du paquet shim-signed. Reboot sans problème.

Tu n'as pas répondu sur le fait que tu utilisais juste le boot UEFI ou bien Secure Boot.

Je n'ai pas vu de rubrique intitulée "Secure Boot" dans le bios de la machine.

Si ce dernier est activé, je te déconseille fortement de mettre à jour shim en virant shim-signed. Il n'y a pas de dépendance entre shim et shim-signed, mais sans ce dernier, Secure Boot risque de beaucoup moins bien fonctionner.

Dans l'incertitude à propos du secure boot, c'est aussi le conseil que je me donne. ;-)

J'ai fait un rapport de bug sur launchpad.net car finalement je me dis qu'une procédure de mise à jour qui échoue ce n'est pas normal et qu'il y a peut-être un problème de dépendance mal configurée entre les paquets shim et shim-signed.

La mise à jour concerne :
- grub-common
- grub-efi-amd64
- grub-efi-amd64-bin
- grub-efi-amd64-signed
- grub2-common
- shim

Pour shim, il s'agit de passer de la version 0.9+1474479173.6c180c6-1ubuntu1 à la version 13-0ubuntu2
shim-signed n'est pas indiqué comme pouvant être mis à jour. En plus je suis surpris par le gros changement dans le n° de version de shim. Je ne trouve cette version que ici : https://ubuntu.pkgs.org/17.10/ubuntu-proposed-main-amd64/shim_13-0ubuntu2_amd64.deb.html mais c'est pour Ubuntu 17.10
Peut-être que cette nouvelle version de shim permet justement de s'affranchir de cette dépendance à shim-signed.

LO 5.4.4.1 est une RC1, la version finale qui a été publiée par TDF est la RC2 (5.4.4.2) qui corrige quelques bugs supplémentaires : https://wiki.documentfoundation.org/Releases/5.4.4/RC2

Ceci dit il faudrait vérifier si vous avez le même problème avec la version compilée par TDF et disponible sur le site LibreOffice : https://fr.libreoffice.org/download/libreoffice-fresh/

Pour ma part je n'ai pas le problème avec la version 5.4.4.2 pour Ubuntu 16.04 fournie par le PPA de Canonical.

Pour Java, vérifiez si votre LibreOffice a l'extension Mediawiki-Publisher. Si c'est le cas désinstallez la, c'est elle qui a besoin de Java et qui vérifie la présence d'un JRE au démarrage.

Sinon pour les suspicions de bug, merci d'en faire part sur qa@fr.libreoffice.org

Certes, mais les promoteurs du bitcoin prétendent qu'il peut remplacer les vraies monnaies. Or il déraille déjà pour seulement 30 millions d'utilisateurs et 350000 transactions par jour.

Par exemple, jusqu'à maintenant, le capitalisme (basé sur l'idée de l'accumulation infinie) réussit

ça dépend des critères qu'on se donne pour évaluer la réussite ou l'échec.

toute monnaie basée sur le blockchain deviendra un échec à mesure qu'elle devient populaire…

Donc ça devient un échec à mesure que ça réussit…

Donc, t'aurais du intitulé ton journal: "le service client de la banque postal est pourri".

Oui mais non. On pourrait aussi écrire que la BP est la seule qui s'est retenue d'accuser quelqu'un d'autre pour se dédouaner. Au final on n'a aucune information sur la raison réelle du dysfonctionnement. Et je ne serais pas surpris que personne, ni le conseiller de la banque, ni le commerçant ni les intermédiaires, ne comprennent ce qui s'est passé.

Pour ma part cela fait longtemps que je ne donne plus mon numéro de CB pour les paiements en ligne. La e-cartebleue de la BP fonctionne très bien, même pour la SNCF une fois qu'on a compris qu'il ne faut pas prendre d'assurance car cela implique 2 paiements en un ce qui n'est pas possible avec une CB virtuelle à usage unique.
La seule fois où ça n'a vraiment pas marché, c'était avec Dell, du coup je suis allé dans une boutique LDLC…

À quoi ça t'avance qu'un moteur de recherche soit libre ? Tu veux l'héberger toi-même ? Et s'il est libre comment sais-tu que l'instance que tu peux interroger a bien le même code source que celui auquel tu peux accéder ?

Moi j'ai surtout compris qu'il disait hier samedi que la semaine ne finit que dimanche soir. Il a donc jusqu'à ce soir minuit pour tenir sa promesse et il ne lui sera pas tenu rigueur s'il ne peut pas la tenir.