Crash de libreoffice sur debian 32 bit causé par une mauvaise version de l'image

Support Debian
Tags: #<Tag:0x00007f50b0eff7b0>
#1

Bonjour,

Je reviens vers un bug que je pensais avoir résolu avec ma debian Stretch 9.4 mais qui revient avec l’actualisation de ma Debian à la version Stretch 9.5 …

En juin 2017 un bug lié à un problème de compatibilité entre les derniers noyaux debian et OpenJDK 8 à causé comme effet de bord le crash systématique de Libreoffice lorsque celui-ci active java. Voir à ce sujet par exemple :
[ Bug 108619 ] (32bitjavacrash) - Java Crash on x86 in jfw_plugin_startJavaVirtualMachine w/ recent linux kernels
# LibreOffice Base crashes on 32bit Linux

Comme je programme une base de donnée avec LOoo Base en interface et HSQLDB en backend, j’avais contourné le problème avec la version LibreOffice 1.7.5… livrée avec Debian Stretch 9.4 en ajoutant le paramètre stack_guard_gap=1 au lancement de mon image… C’était pas clean niveau sécurité mais cela me permettais de continuer mon projet .

Il y a quelques semaines j’ai appliqué un upgrade à la version debian 9.5, puis cette semaine un update qui a actualisé mon image et maintenant libreoffice crash comme avant, même avec le paramètre stack_guard_gap=1, même avec la dernière version stable de LibreOffice 6.0.6, même avec l’installation de la dernière JRE de Java, même en essayant de revenir à la version 1:5.2.7-1+deb9u4(stable) livrée avec ma Debian Stretch 9.5…

L’image que j’utilise est la plus récente proposée dans mes packages, la commande de lancement de mon image est la suivante :

BOOT_IMAGE=/vmlinuz-4.17.0-0.bpo.1-686 root=/dev/mapper/gelinux-root ro quiet stack_guard_gap=1

Il semblait dans les forums que le bug était résolu dans les images à partir de la version 4.14…, donc je ne pensais pas rencontrer de problème avec la version 4.17 … Mais je ne suis pas pour autant certain que cette image soit intéressante pour mon système : DELL INSPIRON 640m 32 bits.

Les images installées sur mon système sont listées ci-dessous :
dpkg-query -l ‘linux-image*’

Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom            Version      Architecture Description
+++-==============-============-============-=================================
ii  linux-image-4. 4.17.8-1~bpo i386         Linux 4.17 for older PCs
ii  linux-image-4. 4.18.6-1~bpo i386         Linux 4.18 for modern PCs
rc  linux-image-4. 4.9.65-3+deb i386         Linux 4.9 for modern PCs
rc  linux-image-4. 4.9.110-3+de i386         Linux 4.9 for older PCs
ii  linux-image-4. 4.9.110-3+de i386         Linux 4.9 for modern PCs
ii  linux-image-68 4.9+80+deb9u i386         Linux for modern PCs (meta-packag

J’ai essayé la plus récente (linux-image-4. 4.18.6-1~bpo i386) et la plus ancienne (linux-image-4. 4.9.65-3+deb i386) : sans succès … A chaque installation je supprime le fichier ~/.config/libreoffice mais cela ne change rien. A chaque fois j’essaie avec OpenJDK 8 et la dernière JRE Oracle 32 bits. Je pourrais sans doute essayer de reinstaller OpenJDK7 mais comment faire ?

Merci pour votre aide …
Patrick

#2

Il y a quelque chose que je ne comprends pas: le noyau sur lequel tu bootais avant plante aussi oo/java maintenant ?

Si c’est ça, ça veut dire que le soucis est dans la version de java ou de libreoffice, pas dans celle du noyau.
Ca vaudrait donc le coup que tu testes les différentes versions du jre qui te sont disponibles, quitte à régresser (voir la liste des versions dispos avec apt-cache policy ), et/ou que tu en trouves une ailleurs, genre dans les backports, peut être ?

Sinon, 1ere alternative, le problème semble ne se produire qu’en 32 bits, mais que fait ta machine en 32 bits (quelle idée) ?
Passe là en 64 ?
https://wiki.debian.org/CrossGrading

Autre alternative, c’est de trouver pourquoi ça plante, et de le corriger pour toutes les versions présentes ou à venir.
Mais pour ça, il faudrait un peu plus d’éléments, genre messages d’erreur au plantage en lançant oo en mode verbeux (flag à trouver) ou en activant un mode de debug du jre pour avoir des infos sur le plantage dans les logs (idem, je ne sais pas ou ça peut s’activer).

#3

Je ne sais plus vraiment quel noyau j’utilisais sous Debian 9.4, car après l’ugrade vers la 9.5 je l’ai supprimé avec d’autres encore plus anciens … J’avais un peu oublié cette histoire de Bug PC32bit-Kernel-Java-LibreOffice, et je pensais aussi à demi mot que les derniers noyaux avaient sans doute résolu le problème … Alors j’ai bien réinstaller un ancien noyau, mais cela ne fonctionne pas … Et j’ai bien aussi d’autres noyaux plus anciens dans le dépot debian 9.5, je crois le plus ancien ce doit être linux-image.4.9.0.-3-686. Je m’apprête à la tester …

Pourquoi je suis en 32 bits ? En voilà une question qu’elle est bonne :slight_smile: Parce que je fonctionne avec une brouette 32 bits … (DELL INSPIRON 640m). Dois-je comprendre qu’il serait possible d’émuler un PC 64 bits avec un matériel 32 bits ? Et qu’est ce qu’on gagne ?

Info intéressante depius mon premier poste : J’ia deux applications java qui semblent parfaitement fonctionner : Dbeaver qui utilise donc la même base de donnée que mon appli Libreoffice Base, et TaskUnifier. J’ai lu sur un forum que le problème est spécifique à l’utilisation Java par LibreOffice … et quelques autres applications que je n’ai plus en mémoire …

Dans ce thread il y a plus d’infos sur les raisons du plantage. A noter que j’ai également supprimé les packages gtk de libreoffice, en particulier gtk2 mais cela ne change rien…

Je vois aussi dans les options de libreoffice la possibilité d’utiliser OpenGL mais j’ai dejà testé hier sans succès. Je vais peut être réessayer …

#4

Ah oui, zut…
OK, effectivement aucun intérêt à basculer à ma connaissance.

En fait, 9.4 ou 9.5, c’est la 9 qui a un moment de son évolution a changé de sous version, mais si tu avais fait des mises à jour continues, tu aurais eu à un moment une 9.4 qui diffère plus d’une 9.4 installée initialement que d’une 9.5.
Juste pour dire que c’est un peu un abus de langage de parler de “bascule”, théoriquement, c’est juste une légère évolution.
Bref…

De ce que tu m’as montré et de ce que j’ai lu ailleurs, ça a l’air d’être une interaction entre 3 choses:
libreoffice qui fait un appel rare au JRE, java qui fait un appel à la pile mémoire dangereux pour la sécurité (débordement de pile ?), et le noyau 32 bits qui contient des protections contre ce type de manip mémoire et fait tout planter en refusant l’opération.
Le coupable est donc a priori le JRE qui est mal codé en 32 bits, et comme ce plantage n’a l’air d’arriver que sur des applis “user space” que de moins en moins d’users risquent d’utiliser en 32 bits et que ça ne doit que peu toucher les usages embarqués, je parie qu’il ne sera jamais corrigé.

Donc…

Je reviens sur ce que j’ai proposé, il faut que tu testes différents noyaux, en remontant dans le temps pour trouver le plus récent qui marche, AVEC L’OPTION stack_guard_gap=1 (même si c’est dangereux pour la sécu, c’est la seule condition qui t’a permis de tourner jusqu’ici a priori).

Ne te prends pas la tête avec les dépots: vu qu’une fois que tu auras trouvé, tu seras surement obligé de rester définitivement sur le même noyau, il vaut mieux que tu sauvegardes dans un coin le .deb, pour l’avoir sous la main si tu dois le reinstaller, au cas où il disparaitrait des dépots.

Tu peux télécharger directement les versions de linux-image une à une ici:
http://mirrors.gandi.net/debian/pool/main/l/linux/
Tu les testes avec dpkg -i <la version qui t’interesse>.deb jusqu’à ce que tu trouves.
Une fois que tu as trouvé la bonne version, tu ne gardes que celle là, et tu télécharges, toujours au même endroit tous les paquets issus des mêmes sources de noyau (avec le même numéro de version) qui te sont nécessaires ou qui pourraient l’être un jour.
Par exemple, il te faut les kernel-headers de la version de noyau, pour pouvoir recompiler un module dessus. Idem avec linux-cpupower, etc qui sont compilés avec les mêmes sources de noyau.
La liste compléte des paquets dépendant (au niveau de version prés) est par exemple ici:
https://packages.debian.org/source/stretch/linux
Tu stockes tous ceux qui te paraissent importants avec ton noyau quelquepart en sauvegarde.
Aprés, tu “hold” la version de noyau que tu veux figer, pour éviter qu’apt ne te propose de le désinstaller pour une raison ou pur une autre, et ça devrait suffire à ce que tu puisses continuer à faire tes mises à jour du reste sans que ça n’impacte ta config noyau:
echo “linux-image hold” | sudo dpkg --set-selections

Enfin je pense que c’est plutôt ça qu’il faut faire.

#5

Ou bien rachète toi une machine, sinon… :smiley:

#6

ok avec votre analyse. Il y a effectivement l’option de racheter une becane 64 bits… Si j’ai bien compris il y aurait aussi la possibiloité de retrograder OpenJDK à la version 7 … Et comme elle n’est pas en dépôt il faudrait que je la trouve en igne, peut être sur un dépôt Jessie… Il me semble que cette dernière solution serait la plus simple et cela me permettrait de désactiver le paramètre stack_guard_gap=1 au lancement du noyau.

Savez-vous comment revenir a OpenJDK 7 simplement sous Debian Stretch 9(.5) ? Par exemple ce paquet sous jessie, est ce que je pourrais l’installer simplement ? Et d’abord est-ce-que je vais pouvoir désinstaller simplement openjdk 8 ? Rien n’est moins sur s’il y a de nombreuses dépendances Java …

#7

Alors si tu veux tester un retour en java7, c’est simple et tu peux même faire cohabiter le 7 et le 8.
Le 7 est dans les dépots avec le 8 donc tu peux l’installer juste avec apt install oracle-java7-jre oracle-java7-jdk .
Ensuite, tu peux si nécessaire éviter que ta debian ne force la version 8 par défaut (apt remove oracle-java8-set-default).
Tu peux ensuite choisir avec update-alternatives --config java la version par défaut.
Et si tu veux ponctuellement lancer un truc avec une autre version, il me semble que la syntaxe est:
JAVA=/usr/lib/jvm/java-<chemin à déterminer en fonction de la version>/jre/bin/java <la commande>

#8

A la limite, tu installes juste le 7, tu regardes si libreoffice fonctionne avec en le lançant ponctuellement JAVA=… libreoffice, et si ça marche, tu te fait un alias qui lance libreoffice avec la 7 et tu laisses tout le reste en 8.

#9

Sur cette page il est expliqué comment installé Open-JDK-7 simplement sous stretch qui devrait se trouver sur le dépôt, mais en fait je ne l’ai pas sur mes dépôts stretch (ci-dessous) … Alors je en comprends pas !

# Debian Stretch, dépôt principal + paquets non libres
deb http://deb.debian.org/debian/ stretch main contrib non-free
# Debian Stretch, mises à jour de sécurité + paquets non libres
deb http://security.debian.org/ stretch/updates main contrib non-free
# Debian Stretch, mises à jour "volatiles" + paquets non libres
deb http://deb.debian.org/debian/ stretch-updates main contrib non-free
# Debian Stretch, dépôt de rétroportages ("backports")
deb http://deb.debian.org/debian/ stretch-backports main contrib non-free

Et le site Web du projet OPenJDK ne propose en téléchargemnt que des version 64 bits de la verson 7. Oracle même chose avec en plus obligation de s’inscrire sur leur site…

#10

l’ orthographe peut-être

apt policy open*jdk-7

openjdk-7-jre-zero:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
openjdk-7-jre-lib:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
        500 http://deb.debian.org/debian-security jessie/updates/main i386 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
          1 http://deb.debian.org/debian experimental/main i386 Packages
openjdk-7-jre-dcevm:
  Installé : (aucun)
  Candidat : 7u79-4
 Table de version :
     7u79-4 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
openjdk-7-source:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
        500 http://deb.debian.org/debian-security jessie/updates/main i386 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
          1 http://deb.debian.org/debian experimental/main i386 Packages
openjdk-7-jdk-headless:
  Installé : (aucun)
  Candidat : (aucun)
 Table de version :
openjdk-7-demo:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
uwsgi-plugin-jwsgi-openjdk-7:
  Installé : (aucun)
  Candidat : 2.0.7-1+deb8u2
 Table de version :
     2.0.7-1+deb8u2 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
openjdk-7-jre-headless:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
openjdk-7-dbg:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
openjdk-7-doc:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
        500 http://deb.debian.org/debian-security jessie/updates/main i386 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
          1 http://deb.debian.org/debian experimental/main i386 Packages
openjdk-7-jdk:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
openjdk-7-jre:
  Installé : (aucun)
  Candidat : 7u181-2.6.14-1~deb8u1
 Table de version :
     7u181-2.6.14-1~deb8u1 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
     7u161-2.6.12-1 1
          1 http://deb.debian.org/debian experimental/main amd64 Packages
uwsgi-plugin-jvm-openjdk-7:
  Installé : (aucun)
  Candidat : 2.0.7-1+deb8u2
 Table de version :
     2.0.7-1+deb8u2 500
        500 http://deb.debian.org/debian-security jessie/updates/main amd64 Packages
#11

Je viens de tester avec OpenOffice 4.1.5-1 Java Oracle jdk1.8.0_191 : c’est le même problème…

Je ne comprends pas, je n’ai pas le même résultat que vous, avec ma Debian Stretch 9.5 j’ai une liste vide des packages open-jdk-7 …

lernstick-openjdk-7-jre:
  Installé : (aucun)
  Candidat : 1.0-1
 Table de version :
     1.0-1 500
        500 http://www.geogebra.net/linux stable/main i386 Packages
openjdk-7-jre-headless:
  Installé : (aucun)
  Candidat : (aucun)
 Table de version :
openjdk-7-jdk:
  Installé : (aucun)
  Candidat : (aucun)
 Table de version :
openjdk-7-jre:
  Installé : (aucun)
  Candidat : (aucun)
 Table de version :

j’ai trouvé une solution consistant à installer les dépots suivants pour l’installation de Open-JDK-7 dans Stretch 9 :

deb http://ftp.caliu.cat/debian/ experimental main
deb-src http://ftp.caliu.cat/debian/ experimental main

Mais lorsque je sélectionne le package openjdk-7-jre j’ai l’erreur suivante :

    openjdk-7-jre:
     Dépend : openjdk-7-jre-headless mais ne doit pas être installé
      Dépend : libfontconfig1 (>=2.12) mais 2.11.0-6.7+b1 doit être installé
#12

Dans Debian visiblement il faut les dépôts Jessie pour avoir openjdk-7
https://tracker.debian.org/pkg/openjdk-7
ce qui est mon cas car j’ai gardé Jessie securité dans mon fichier sources

# Jessie 8 sécurité
deb http://deb.debian.org/debian-security/ jessie/updates contrib main non-free

jé n’ai aucun crash de libreoffice , j’en fait une utilisation simpliste

Capture%20d%E2%80%99%C3%A9cran%20du%202018-11-03%2020-10-20

Capture%20d%E2%80%99%C3%A9cran%20du%202018-11-03%2020-09-42

 apt list --installed | grep openjdk

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

openjdk-10-jre-headless/testing,unstable,now 10.0.2+13-2 amd64  [installé, automatique]
openjdk-10-jre/testing,unstable,now 10.0.2+13-2 amd64  [installé, automatique]
openjdk-8-jre-headless/stable,proposed-updates,now 8u181-b13-2~deb9u1 amd64  [installé, automatique]
openjdk-8-jre/stable,proposed-updates,now 8u181-b13-2~deb9u1 amd64  [installé, automatique]
#13

Comme indiqué, le problème vient de la config 32bits, donc normal que tu n’aies aucun problème.

Sinon, @grandtoubab, attention, car openjdk dépend de java-tzdata, qui dépend lui même du paquet tzdata de jessie (précisément), ce n’est pas grave, mais déjà il faut être OK pour downgrader tzdata.

Par ailleurs il faut faire du pinning, car sans ça, ça me propose de l’install d’un tas de paquets qui n’existent qu’en jessie, qui n’ont rien à voir avec les dépendances d’openjdk et sont inutiles sur une etch, mais qu’aptitude me demande d’installer à l’upgrade depuis jessie (paquets suggèrés ?).

Je crois qu’il faut installer ça depuis des dépots non debian, finalement:
https://www.2daygeek.com/install-oracle-java-jdk-jre-7-8-9-on-debian/
c’est le paragraphe 2

#14

Bonjour,
Il y a un an, j’ai fait des installations sur des PC 32 bits.
Si je me souviens bien, il y avait writer qui ne se lançait pas, par contre pas de souci avec calc.
A l’époque, j’avais résolu le problème en désinstallant uniquement le paquet libreoffice-wiki-publisher qui sert à avoir une extension pour écrire dans les mediawikis.
Je ne sais pas si cette solution a duré dans le temps par contre, je n’ai pas eu de nouvelles des PCs.

#15

Bonjour,
Merci mattotop pour l’info ci-dessous :

Mais en fait le paragraphe 2 comme le 1 utilisent le même dépôt webupd8team qui ne propose en fait que la version Openjdk-8 !!! (j’ai testé jusqu’au bout…)

Et puis pour le conseil de chalu :

A l’époque, j’avais résolu le problème en désinstallant uniquement le paquet libreoffice-wiki-publisher qui sert à avoir une extension pour écrire dans les mediawikis.

j’ai réinstallé libreoffice stable 6.0.6 sans le package du mediawiki mais cela ne change (encore) rien. J’utilise toujours Openjdk-8 de la Stretch et la commande de lancement de mon noyau est BOOT_IMAGE=/vmlinuz-4.18.0-0.bpo.1-686-pae root=/dev/mapper/gelinux-root ro apparmor=1 security=apparmor… Je vais essayer de réactiver le paramètre stack_guard_gap=1 au lancement du noyau …

J’ai aussi regardé du côté de http://snapshot.debian.org qui propose des snapshots debian dans l’espoir de réinstaller OpenJDK-7 sinon le noyau Linux Debian stretch d’origine. Mais je ne comprends pas comment cela fonctionne …

J’ai retrouvé également deux revues debian 8.4 (Jessie) et Debian 9.4 (Stretch). J’ai essayé de monter les volumes dans synaptics pour récupérer un noyau plus ancien, mais je n’y arrive pas. Lors de l’update Synaptic balance un message d’erreur :
The repository 'cdrom://[Debian GNU/Linux 8.4.0 _Jessie_ - Official i386 DVD Binary-1 20160402-13:26] jessie Release' does not have a Release file.
Je n’ai jamais compris comment m’en sortir pour réinstaller un dépôt depuis un CDROM debian … Faut-il copier l’ensemble des fichiers Debs dans un dossier spécifique sur le disque dur avec un fichier release à chercher je ne sais où ?

#16

Je précise que le système était Debian 32 bits et dépôts stretch seulement.
Pas les backports …
Tu utilises visiblement le noyau backports et la version de libreoffice n’est pas celle de stable non plus qui est
Paquet : libreoffice (1:5.2.7-1+deb9u4)

#17

Salut
En ajoutant

deb http://deb.debian.org/debian-security/ jessie/updates contrib main non-free
deb http://deb.debian.org/debian/ jessie main

Meme sur ma version Buster cette installation passerait bien, à voir en 32 bits

sudo apt -s install openjdk-7-jre openjdk-7-jre-headless tzdata-java/jessie

 sudo apt -s install openjdk-7-jre openjdk-7-jre-headless tzdata-java/jessie
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Version choisie « 2018g-0+deb8u1 » (Debian-Security:8/oldstable [all]) pour « tzdata-java »
Version choisie « 2018g-0+deb8u1 » (Debian-Security:8/oldstable [all]) pour « tzdata » à cause de « tzdata-java »
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  icedtea-netx-common
Veuillez utiliser « sudo apt autoremove » pour le supprimer.
Les paquets supplémentaires suivants seront installés : 
  libgif4 libpng12-0 tzdata
Paquets suggérés :
  icedtea-7-plugin icedtea-7-jre-jamvm libnss-mdns sun-java6-fonts fonts-ipafont-gothic
  fonts-ipafont-mincho fonts-wqy-microhei fonts-wqy-zenhei fonts-indic
Les paquets suivants seront ENLEVÉS :
  icedtea-8-plugin icedtea-netx openjdk-8-jre openjdk-8-jre-headless
Les NOUVEAUX paquets suivants seront installés :
  libgif4 libpng12-0 openjdk-7-jre openjdk-7-jre-headless tzdata-java
Les paquets suivants seront mis à une VERSION INFÉRIEURE :
  tzdata
0 mis à jour, 5 nouvellement installés, 1 remis à une version inférieure, 4 à enlever et 0 non mis à jour.
Remv icedtea-8-plugin [1.6.2-3.1]
Remv icedtea-netx [1.6.2-3.1]
Remv openjdk-8-jre [8u181-b13-2~deb9u1]
Remv openjdk-8-jre-headless [8u181-b13-2~deb9u1]
Inst libgif4 (4.1.6-11+deb8u1 Debian:8.11/oldstable [amd64])
Inst libpng12-0 (1.2.50-2+deb8u3 Debian:8.11/oldstable [amd64])
Inst tzdata [2018g-1] (2018g-0+deb8u1 Debian-Security:8/oldstable [all])
Inst tzdata-java (2018g-0+deb8u1 Debian-Security:8/oldstable [all])
Inst openjdk-7-jre-headless (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [amd64])
Inst openjdk-7-jre (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [amd64])
Conf libgif4 (4.1.6-11+deb8u1 Debian:8.11/oldstable [amd64])
Conf libpng12-0 (1.2.50-2+deb8u3 Debian:8.11/oldstable [amd64])
Conf tzdata (2018g-0+deb8u1 Debian-Security:8/oldstable [all])
Conf tzdata-java (2018g-0+deb8u1 Debian-Security:8/oldstable [all])
Conf openjdk-7-jre-headless (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [amd64])
Conf openjdk-7-jre (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [amd64])
#18

J’ai d’abord réinstaller les depôts Debian Stretch de base (voir ci-dessous) mais toujours pas de OpenJdk-7 en vu …

 # Debian Stretch, dépôt principal
 deb http://deb.debian.org/debian/ stretch main
 # Debian Stretch, mises à jour de sécurité
 deb http://security.debian.org/ stretch/updates main
 # Debian Stretch, mises à jour "volatiles"
 deb http://deb.debian.org/debian/ stretch-updates main

L’ajout des dépôts Jessie propose effectivement l’installation avec rétrogradation de tzdata. C’est quoi tzdata ? Mais cela ne fonctionne pas car au final la commande

sudo apt -s install openjdk-7-jre openjdk-7-jre-headless tzdata-java/jessie

… affiche les informations ci-dessous et quitte, sans me permettre l’installation… Un essai depuis synaptic me montre que lorsque je sélectionne par exemple le paquet openjdk-7-jre celui-ci a une case rouge,indiquant un paquet cassé … Mais je ne sais ps comment savoir quel autre paquet empêche sa sélection, car en géénral c’est cela qui se passe dans ce cas, une incompatibilité avec un autre paquet …

sudo apt -s install openjdk-7-jre openjdk-7-jre-headless tzdata-java/jessie
    Lecture des listes de paquets... Fait
    Construction de l'arbre des dépendances       
    Lecture des informations d'état... Fait
    Version choisie « 2018g-0+deb8u1 » (Debian-Security:8/oldstable [all]) pour « tzdata-java »
    Version choisie « 2018g-0+deb8u1 » (Debian-Security:8/oldstable [all]) pour « tzdata » à cause de « tzdata-java »
    Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
      4ti2 cdbs cysignals-tools cython ecl eclib-tools f2c famfamfam-silk fflas-ffpack fflas-ffpack-common flintqs gap gap-alnuth gap-atlasrep
      gap-autpgrp gap-character-tables gap-core gap-dev gap-doc gap-gapdoc gap-libs gap-online-help gap-polycyclic gap-prim-groups
      gap-small-groups gap-table-of-marks gap-trans-groups gfan gmp-ecm ipython isympy isympy-common javahelp2 jupyter-client jupyter-core
      jupyter-nbextension-jupyter-js-widgets lcalc libaec0 libarpack2 libasm4-java libatomic-ops-dev libblas-dev libbrial-groebner0 libbrial0
      libbsh-java libbz2-dev libcdd-doc libcdd-tools libcdd0d libcliquer1 libcommons-cli-java libcxsparse3 libdsdp-5.8gf libec2 libecm1
      libequinox-osgi-java libf2c2 libf2c2-dev libfelix-framework-java libfelix-main-java libffi-dev libflint-2.5.2 libflint-arb1 libfltk-gl1.3
      libfltk1.3 libfplll2 libgap-sage-4 libgc-dev libgivaro9 libgl2ps1 libglpk40 libgmp-dev libgmp3-dev libgmpxx4ldbl libhdf5-100 libiml0
      libjcommander-java libjmol-java libjna-platform-java libjpeg-dev libjpeg62-turbo-dev libjs-backbone libjs-bootstrap libjs-bootstrap-tour
      libjs-codemirror libjs-es6-promise libjs-jquery-colorpicker libjs-jquery-form libjs-jquery-typeahead libjs-json libjs-marked libjs-moment
      libjs-prettify libjs-requirejs libjs-term.js libjs-text-encoding liblapack-dev liblfunction0 liblinbox-1.4.2-0 liblinboxsage-1.4.2-0
      liblrcalc1 libluajit-5.1-2 libluajit-5.1-common liblzma-dev libm4ri-0.0.20140914 libm4rie-0.0.20150908 libmpfi0 libnaga-java libnauty2
      libnb-org-openide-modules-java libnb-platform18-java libncurses5-dev libnormaliz0 libntl27 liboctave3v5 libosgi-annotation-java
      libosgi-compendium-java libosgi-core-java libpari-gmp-tls5 libplanarity0 libppl14 libpynac2 libpython-all-dev libqhull7 libqrupdate1
      libqscintilla2-12v5 libqscintilla2-l10n libratpoints-2.1.3 libreadline-dev librw0 libsingular4 libsingular4-dev libsingular4-dev-common
      libswing-layout-java libsymmetrica2 libsz2 libtachyon-mt-0 libtinfo-dev libvisualvm-jni libxt-dev libyaml-snake-java libzn-poly-0.9
      maxima-sage maxima-sage-doc maxima-sage-share nauty normaliz normaliz-bin octave octave-common octave-info palp pandoc pandoc-data
      pari-doc pari-elldata pari-galdata pari-gp pari-seadata python-all python-all-dev python-attr python-backports-abc
      python-backports-shutil-get-terminal-size python-backports.ssl-match-hostname python-blinker python-brial python-cffi-backend python-click
      python-colorama python-concurrent.futures python-configparser python-constantly python-cryptography python-cvxopt python-cycler
      python-cysignals-pari python-decorator python-entrypoints python-enum34 python-flask python-flask-autoindex python-flask-babel
      python-flask-oldsessions python-flask-openid python-flask-silk python-fpylll python-funcsigs python-functools32 python-future python-gd
      python-gmpy python-gnutls python-idna python-incremental python-ipaddress python-ipykernel python-ipython python-ipython-genutils
      python-ipywidgets python-itsdangerous python-jsonschema python-jupyter-client python-jupyter-core python-keyring python-keyrings.alt
      python-matplotlib python-mistune python-mock python-moinmoin python-mpmath python-nbconvert python-nbformat python-networkx
      python-notebook python-openid python-openssl python-pam python-parsedatetime python-passlib python-path python-pathlib2 python-pbr
      python-persistent python-pickleshare python-pip python-pip-whl python-pkgconfig python-ply python-prompt-toolkit python-psutil
      python-pyasn1-modules python-pyglet python-pygraphviz python-pyicu python-recaptcha python-rpy2 python-sagenb python-sagenb-export
      python-scipy python-secretstorage python-serial python-service-identity python-setuptools-scm python-simplegeneric python-singledispatch
      python-snowballstemmer python-subprocess32 python-sympy python-sympy-doc python-terminado python-tornado python-traitlets
      python-transaction python-twisted python-twisted-bin python-twisted-core python-vcversioner python-wcwidth python-werkzeug python-wheel
      python-xapian python-xappy python-xdg python-zc.lockfile python-zconfig python-zdaemon python-zmq python-zodb python-zope.event
      python3-entrypoints python3-ipykernel python3-ipywidgets python3-jinja2 python3-jsonschema python3-jupyter-client python3-jupyter-core
      python3-markupsafe python3-mistune python3-nbconvert python3-nbformat python3-notebook python3-terminado python3-zmq r-base-core
      r-base-dev r-cran-boot r-cran-class r-cran-cluster r-cran-codetools r-cran-foreign r-cran-kernsmooth r-cran-lattice r-cran-mass
      r-cran-matrix r-cran-mgcv r-cran-nlme r-cran-nnet r-cran-rpart r-cran-spatial r-cran-survival r-doc-html r-recommended rubiks
      sagemath-common sagemath-database-conway-polynomials sagemath-database-elliptic-curves sagemath-database-graphs
      sagemath-database-mutually-combinatorial-designs sagemath-database-polytopes sagemath-doc-en singular singular-data singular-doc
      singular-modules singular-ui sqlite3 surf-alggeo surf-alggeo-nox sympow sympow-data tachyon tachyon-bin-nox testng tinymce
    Veuillez utiliser « sudo apt autoremove » pour les supprimer.
    The following additional packages will be installed:
      initscripts insserv libgif4 libpng12-0 libsctp1 startpar sysv-rc tzdata
    Paquets suggérés :
      bootchart2 lksctp-tools icedtea-7-plugin icedtea-7-jre-jamvm sun-java6-fonts fonts-ipafont-gothic fonts-ipafont-mincho fonts-wqy-microhei
      fonts-wqy-zenhei fonts-indic bum
    Les paquets suivants seront ENLEVÉS :
      default-java-plugin default-jdk default-jdk-headless default-jre default-jre-headless icedtea-8-plugin icedtea-netx icedtea-plugin jmol
      openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-dcevm openjdk-8-jre-headless openjdk-8-source python-sagetex sagemath
      sagemath-jupyter sagetex visualvm
    Les NOUVEAUX paquets suivants seront installés :
      initscripts insserv libgif4 libpng12-0 libsctp1 openjdk-7-jre openjdk-7-jre-headless startpar sysv-rc tzdata-java
    Les paquets suivants seront mis à une VERSION INFÉRIEURE :
      tzdata
    0 mis à jour, 10 nouvellement installés, 1 remis à une version inférieure, 20 à enlever et 3 non mis à jour.
    Remv default-java-plugin [2:1.8-58]
    Remv visualvm [1.3.9-1]
    Remv default-jdk [2:1.8-58]
    Remv default-jdk-headless [2:1.8-58]
    Remv openjdk-8-source [8u181-b13-2~deb9u1]
    Remv openjdk-8-jdk [8u181-b13-2~deb9u1]
    Inst openjdk-7-jre (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [i386]) []
    Remv openjdk-8-jre [8u181-b13-2~deb9u1] [default-jre:i386 icedtea-8-plugin:i386 icedtea-netx:i386 ]
    Inst openjdk-7-jre-headless (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [i386]) [default-jre:i386 icedtea-8-plugin:i386 icedtea-netx:i386 ]
    Remv openjdk-8-jdk-headless [8u181-b13-2~deb9u1] [default-jre:i386 icedtea-8-plugin:i386 icedtea-netx:i386 ]
    Remv openjdk-8-jre-headless [8u181-b13-2~deb9u1] [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst tzdata [2018g-0+deb9u1] (2018g-0+deb8u1 Debian-Security:8/oldstable [all]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst tzdata-java (2018g-0+deb8u1 Debian-Security:8/oldstable [all]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst insserv (1.14.0-5.4+b1 Debian:9.5/stable [i386]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst startpar (0.59-3.1 Debian:9.5/stable [i386]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst sysv-rc (2.88dsf-59.9 Debian:9.5/stable [all]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst initscripts (2.88dsf-59.9 Debian:9.5/stable [i386]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst libsctp1 (1.0.17+dfsg-1+b1 Debian:9.5/stable [i386]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst libgif4 (4.1.6-11+deb8u1 Debian:8.11/oldstable [i386]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Inst libpng12-0 (1.2.50-2+deb8u3 Debian:8.11/oldstable [i386]) [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv sagemath-jupyter [7.4-9] [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv sagetex [3.0+ds-4] [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv python-sagetex [3.0+ds-4] [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv sagemath [7.4-9] [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv jmol [14.6.4+2016.11.05+dfsg1-3] [default-jre-headless:i386 default-jre:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv default-jre [2:1.8-58] [default-jre-headless:i386 icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv default-jre-headless [2:1.8-58] [icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv icedtea-plugin [1.6.2-3.1] [icedtea-8-plugin:i386 openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv icedtea-8-plugin [1.6.2-3.1] [openjdk-8-jre-dcevm:i386 icedtea-netx:i386 ]
    Remv icedtea-netx [1.6.2-3.1] [openjdk-8-jre-dcevm:i386 ]
    Remv openjdk-8-jre-dcevm [8u112-1]
    Conf openjdk-7-jre (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [i386])
    Conf openjdk-7-jre-headless (7u181-2.6.14-1~deb8u1 Debian-Security:8/oldstable, Debian:8.11/oldstable [i386])
    Conf tzdata (2018g-0+deb8u1 Debian-Security:8/oldstable [all])
    Conf tzdata-java (2018g-0+deb8u1 Debian-Security:8/oldstable [all])
    Conf insserv (1.14.0-5.4+b1 Debian:9.5/stable [i386])
    Conf startpar (0.59-3.1 Debian:9.5/stable [i386])
    Conf sysv-rc (2.88dsf-59.9 Debian:9.5/stable [all])
    Conf initscripts (2.88dsf-59.9 Debian:9.5/stable [i386])
    Conf libsctp1 (1.0.17+dfsg-1+b1 Debian:9.5/stable [i386])
    Conf libgif4 (4.1.6-11+deb8u1 Debian:8.11/oldstable [i386])
    Conf libpng12-0 (1.2.50-2+deb8u3 Debian:8.11/oldstable [i386])
#19

tzdata c’est simplement la gestion des fuseaux horaires donc pas de soucis avec ça la version jessie est ok

apt -s ça veut dire simulation

c’est une précaution pour savoir ce qui se passerait

pour installer

sudo apt install openjdk-7-jre openjdk-7-jre-headless tzdata-java/jessie

les indications sur les paquets inutiles prouvent que ton installation est dans un état déplorable, probablement du à l’utilisation de dépots + ou - farfelu

#20

Les indications sur les paquets inutiles ne sont apparues qu’après l’ajout des deux dépots Jessie… Ce que je ne comprends pas puisque Jessie étant avant Stretch alors pourquoi cet ajout indiquerait-il soudain des paquets obsolètes ?

Je viens d’installer OpenJDK-7 et retour à Libreoffice 1:5.2.7-1+deb9u4 proposé par debian Stretch. J’ai supprimé le dossier ~/.config/libreoffice. J’ai bouté avec la ligne de commande BOOT_IMAGE=/vmlinuz-4.9.0-8-686-pae root=/dev/mapper/gelinux-root ro apparmor=1 security=apparmor Après ouverture de libreoffice base j’ai paramétré les options pour utiliser OpenJDK-7, et j’ai réinstallé mon driver hsqldb.jar.

Résultat : Ca crash de la même façon … Dès que ma base accède à la macro d’ouverture mon appli crash… Je pense qu’il y a autre chose. Je vais quand même rebooté en ajoutant le paramètre stack_guard_gap=1 et je reviens …