[onlyoffice] échec d'installation car dépendances cassées

Matériel: PC fixe
Version de YunoHost: 4.0.8
J’ai accès à mon serveur : complet
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Bonsoir,

Voici mon log d’install

Tu as mobilizon d’installé ?

Non, pourquoi ?

Parce qu’il y a un soucis de conflit avec esl-erlang possiblement … mais sinon je vois également :

2020-10-28 23:18:13,392: WARNING - libcurl4-gnutls-dev : Conflicts: libcurl4-nss-dev but 7.64.0-4+deb10u1 is to be installed
2020-10-28 23:18:13,393: WARNING - libcurl4-nss-dev : Depends: libcurl3-nss (= 7.64.0-4+deb10u1) but it is not going to be installed
2020-10-28 23:18:13,393: WARNING - Conflicts: libcurl4-gnutls-dev but 7.64.0-4+deb10u1 is to be installed

qui est un autre soucis connu (conflit de dépendance avec une app qui dépends de libcurl4-gnutls-dev ou libcurl4-nss-dev … c’est actuellement fixé par la branche testing normalement, donc si tu veux tu peux tenter l’install avec

sudo yunohost app install https://github.com/YunoHost-Apps/onlyoffice_ynh/tree/testing 

Nope, j’ai exactement le même problème avec la branche testing.

Hmpf est-ce que tu peux quand même partager le log parce que je doute que le message soit exactement le même vu que la branche testing dépends de libcurl4-dev et non libcurl4-nss-dev …

https://paste.yunohost.org/raw/ebixujeban

Donc oui il y a bien deux problèmes et le premier a été résolu par l’utilisation de la branche testing donc ce n’est pas “exactement le même problème” … Je ne sais pas si tu te rends compte du temps passé chaque jours à juste demander aux gens “montrer nous les logs”. Dans l’informatique, le diable est dans les détails, et le mot “exactement” a un sens qui veut dire “c’est pareil”. Si “c’est pareil” alors ça veut dire “rien n’a changé” et on peut se retrouver à passer des heures et des heures à chercher autre chose pour au final se rendre compte que “ah non en fait c’était différent”. Si c’est vraiment pareil, alors mieux vaut quand même montrer le log pour que tout le monde puisse s’en convaincre plutôt que de partir avec des fausses hypothèses dans la résolution du problème. (Je dis tout ça parce que c’est loin d’être la première fois où ça arrive, avec d’autres ou avec toi)

Bon.

Du coup regardons la sortie de

apt policy erlang-eldap

et

apt install --dry-run erlang-eldap

J’ai lu dans les logs que c’étaient les mêmes dépendances qui étaient cassées, donc je croyais en toute bonne fois que le problème était identique.

Enfin bref.

Le résultat des commandes:

root@stemy:~# apt policy erlang-eldap
erlang-eldap:
  Installé : (aucun)
  Candidat : 1:21.2.6+dfsg-1
 Table de version :
     1:21.2.6+dfsg-1 500
        500 http://ftp.debian.org/debian buster/main amd64 Packages

root@stemy:~# apt install --dry-run erlang-eldap
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  adwaita-icon-theme argon2 at-spi2-core dconf-gsettings-backend dconf-service erlang-mode glib-networking
  glib-networking-common glib-networking-services gsettings-desktop-schemas gtk-update-icon-cache
  inotify-tools libatk-bridge2.0-0 libatk1.0-0 libatk1.0-data libatspi2.0-0 libcairo-gobject2 libcolord2
  libdconf1 libepoxy0 libgail-common libgail18 libgtk-3-0 libgtk-3-bin libgtk-3-common libgtk2.0-0
  libgtk2.0-bin libgtk2.0-common libinotifytools0 libjson-glib-1.0-0 libjson-glib-1.0-common libncurses5
  libnotify4 libproxy1v5 librest-0.7-0 libsoup-gnome2.4-1 libsoup2.4-1 libtinfo5 libwxbase3.0-0v5
  libwxgtk3.0-0v5 libxcomposite1 notification-daemon
Veuillez utiliser « apt autoremove » pour les supprimer.
Les paquets supplémentaires suivants seront installés : 
  erlang-asn1 erlang-base erlang-crypto erlang-mnesia erlang-public-key erlang-runtime-tools erlang-ssl
  erlang-syntax-tools
Paquets suggérés :
  erlang erlang-manpages erlang-doc erlang-tools erlang-inets
Les paquets suivants seront ENLEVÉS :
  elixir esl-erlang mobilizon-ynh-deps
Les NOUVEAUX paquets suivants seront installés :
  erlang-asn1 erlang-base erlang-crypto erlang-eldap erlang-mnesia erlang-public-key erlang-runtime-tools
  erlang-ssl erlang-syntax-tools
0 mis à jour, 9 nouvellement installés, 3 à enlever et 1 non mis à jour.
Remv mobilizon-ynh-deps [0.1.0-2019-12-28~ynh1]
Remv elixir [1.10.4-1]
Remv esl-erlang [1:23.1-1]
Inst erlang-base (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-asn1 (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-crypto (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-public-key (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-mnesia (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-runtime-tools (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-ssl (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-eldap (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Inst erlang-syntax-tools (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-base (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-asn1 (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-crypto (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-public-key (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-mnesia (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-runtime-tools (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-ssl (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-eldap (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])
Conf erlang-syntax-tools (1:21.2.6+dfsg-1 Debian:10.6/stable [amd64])

Bon du coup il y a bel et bien mobilizon d’installé et c’est pour ça qu’il y a un conflit avec esl-erlang … Je sais comment le résoudre car on a eu le même cas chez nous récemment mais c’est clairement technique … J’essaye de retrouver la page de doc …

Mouaip donc la démarche globale est écrite ici mais bon …

https://wiki.arn-fai.net/technique:yunohost_mutu

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.