Je ne comprends pas pourquoi tu écris que ooo.hg est 0% libre. Peux-tu détailler ?
Cela dit ooo.hg n'est pas un logiciel, c'est une extension qui ajoute une collection de cartes à la galerie de LO ou AOO. D'où, je présume, la licence CC.
Oui, pareil en Fortran, mais le problème n'est pas dans l'ouverture des fichiers, il est dans le décodage des chaînes de caractères.
J'ai des fichiers nommés par exemple ../rep1/rep2/foo.txt et j'ai besoin de séparer le chemin et le nom du fichier. Il faut donc que je cherche le 1er / dans la chaîne de caractères en partant de la droite. Il est plus simple de savoir a priori quel séparateur de fichier chercher que de systématiquement essayer les deux.
Exactement, c'est l'un des buts de l'empaqueteur que de faire le lien entre les utilisateurs de sa distribution
et le projet officiel. L'utilisateur ne doit pas rapporter un bogue upstream directement (sauf s'il sait ce qu'il
fait bien entendu).
C'est un point de vue qui me paraît complètement irréaliste pour un logiciel comme LibreOffice dont les utilisateurs sont vraiment nombreux. L'empaqueteur ne ferait que ça de la journée et passerait son temps à remonter des doublons upstream. Quand on suit les rapports de bug upstream, les bugs spécifiques à une distribution ne me semblent pas si nombreux que ça en fait.
Le meilleur moyen de savoir si un bug vient du packaging de la distribution, c'est justement d'en avoir connaissance upstream et d'essayer de le reproduire sur d'autres distributions et d'autres OS.
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.
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
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.
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.
# As-tu lu la doc ?
Posté par Jean-Baptiste Faure . En réponse au message installation de ubuntu. Évalué à 3.
Le point de départ : https://doc.ubuntu-fr.org/debutant
Pour poser des questions : https://forum.ubuntu-fr.org/index.php et voir les 2 premiers forums.
[^] # Re: Tout n'est pas libre la dedans
Posté par Jean-Baptiste Faure . En réponse au journal Le SILL 2018 est arrivé. Évalué à 1.
Je ne comprends pas pourquoi tu écris que ooo.hg est 0% libre. Peux-tu détailler ?
Cela dit ooo.hg n'est pas un logiciel, c'est une extension qui ajoute une collection de cartes à la galerie de LO ou AOO. D'où, je présume, la licence CC.
[^] # Re: J'habite dans un endroit étrange ?
Posté par Jean-Baptiste Faure . En réponse au message [CDD 24 mois] Ingénieur logiciel H/F. Évalué à 2.
Le profil de poste indique :
[^] # Re: Résultats de mes tests
Posté par Jean-Baptiste Faure . En réponse au message détecter l'OS depuis un code compilé. Évalué à 1.
Oui, pareil en Fortran, mais le problème n'est pas dans l'ouverture des fichiers, il est dans le décodage des chaînes de caractères.
J'ai des fichiers nommés par exemple ../rep1/rep2/foo.txt et j'ai besoin de séparer le chemin et le nom du fichier. Il faut donc que je cherche le 1er / dans la chaîne de caractères en partant de la droite. Il est plus simple de savoir a priori quel séparateur de fichier chercher que de systématiquement essayer les deux.
[^] # Re: Impolitesse ?
Posté par Jean-Baptiste Faure . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 5.
C'est un point de vue qui me paraît complètement irréaliste pour un logiciel comme LibreOffice dont les utilisateurs sont vraiment nombreux. L'empaqueteur ne ferait que ça de la journée et passerait son temps à remonter des doublons upstream. Quand on suit les rapports de bug upstream, les bugs spécifiques à une distribution ne me semblent pas si nombreux que ça en fait.
Le meilleur moyen de savoir si un bug vient du packaging de la distribution, c'est justement d'en avoir connaissance upstream et d'essayer de le reproduire sur d'autres distributions et d'autres OS.
[^] # Re: Impolitesse ?
Posté par Jean-Baptiste Faure . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 3.
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.
[^] # Re: Impolitesse ?
Posté par Jean-Baptiste Faure . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 2.
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.
[^] # Re: Résultats de mes tests
Posté par Jean-Baptiste Faure . En réponse au message détecter l'OS depuis un code compilé. Évalué à 1.
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.
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.
# Résultats de mes tests
Posté par Jean-Baptiste Faure . En réponse au message détecter l'OS depuis un code compilé. Évalué à 2.
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.
[^] # Re: Mauvaise idée ?
Posté par Jean-Baptiste Faure . En réponse au message détecter l'OS depuis un code compilé. Évalué à 1.
À 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.
[^] # Re: Math
Posté par Jean-Baptiste Faure . En réponse au journal La recherche en langages de programmation au quotidien. Évalué à 1.
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.
[^] # Re: Math
Posté par Jean-Baptiste Faure . En réponse au journal La recherche en langages de programmation au quotidien. Évalué à 2.
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.
[^] # Re: Math
Posté par Jean-Baptiste Faure . En réponse au journal La recherche en langages de programmation au quotidien. Évalué à 1.
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.
[^] # Re: #ifdef
Posté par Jean-Baptiste Faure . En réponse au message détecter l'OS depuis un code compilé. Évalué à 2.
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.
[^] # Re: #ifdef
Posté par Jean-Baptiste Faure . En réponse au message détecter l'OS depuis un code compilé. Évalué à 1. Dernière modification le 10 février 2018 à 14:07.
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.
# Faille de sécurité dans LO 5.4 et 6.0 : mettez à jour !!!
Posté par Jean-Baptiste Faure . En réponse à la dépêche Sortie de LibreOffice 6.0. Évalué à 10.
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 !
[^] # Re: Quelles sont les fonctionnalités malheureuses, selon vous ?
Posté par Jean-Baptiste Faure . En réponse à la dépêche Sortie de LibreOffice 6.0. Évalué à 3.
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.
[^] # Re: Quelles sont les fonctionnalités malheureuses, selon vous ?
Posté par Jean-Baptiste Faure . En réponse à la dépêche Sortie de LibreOffice 6.0. Évalué à 4. Dernière modification le 08 février 2018 à 07:02.
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
[^] # Re: Peu claire cette info sur l'enregistrement des images
Posté par Jean-Baptiste Faure . En réponse à la dépêche Sortie de LibreOffice 6.0. Évalué à 5.
L'explication dans les notes de version : https://wiki.documentfoundation.org/ReleaseNotes/6.0/fr#Enregistrement_in-situ_des_images_modifiées
# Rapport de bug créé
Posté par Jean-Baptiste Faure . En réponse au journal LibreOffice, altération d'images intégrées :( ?. Évalué à 10.
Le rapport de bug a été créé par Julien Nabet : https://bugs.documentfoundation.org/show_bug.cgi?id=115471
et il a été confirmé.
[^] # Re: Si j'ai bien compris...
Posté par Jean-Baptiste Faure . En réponse au journal LibreOffice, altération d'images intégrées :( ?. Évalué à 3.
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
# Problème résolu
Posté par Jean-Baptiste Faure . En réponse au message UEFI : shim-signed ou shim tout court ???. Évalué à 1.
Je viens d'installer une mise à jour avec cette fois une nouvelle version du paquet shim-signed. Reboot sans problème.
[^] # Re: UEFI / Secure Boot ?
Posté par Jean-Baptiste Faure . En réponse au message UEFI : shim-signed ou shim tout court ???. Évalué à 2.
Je n'ai pas vu de rubrique intitulée "Secure Boot" dans le bios de la machine.
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.
[^] # Re: UEFI / Secure Boot ?
Posté par Jean-Baptiste Faure . En réponse au message UEFI : shim-signed ou shim tout court ???. Évalué à 1.
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.
# C'est une RC1
Posté par Jean-Baptiste Faure . En réponse au message Libreoffice consommation anormale du CPU. Évalué à 1.
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