V
Victor

  • 7 juil. 2024
  • Inscrit 10 juin 2014
  • De rien @Victor et je vais en profité pour apporter également une légère correction (nouvelle version).

    wget -c "https://github.com/openssl/openssl/archive/OpenSSL_1_1_1q.tar.gz";\
    tar -xvf OpenSSL_1_1_1q.tar.gz;\
    cd openssl-OpenSSL_1_1_1q;\
    

    https://packages.debian.org/stretch/subversion
    https://subversion.apache.org/news.html
    https://opensource.wandisco.com/debian/dists/stretch/svn114/binary-amd64/
    http://xmlrpc-c.sourceforge.net/change.html
    https://github.com/rakshasa/libtorrent/branches (le dernier commit = 07 Août 2021)
    https://github.com/rakshasa/rtorrent/branches (le dernier commit = 12 Decembre 2021)

    wget -c "http://opensource.wandisco.com/debian/dists/stretch/svn114/binary-amd64/libsvn1_1.14.2-1%2bWANdisco_amd64.deb";
    wget -c "http://opensource.wandisco.com/debian/dists/stretch/svn114/binary-amd64/subversion_1.14.2-1%2bWANdisco_amd64.deb";
    dpkg -i libsvn1_1.14.2-1+WANdisco_amd64.deb;
    dpkg -i subversion_1.14.2-1+WANdisco_amd64.deb;
    svn --version | head -n 1;
    svn checkout http://svn.code.sf.net/p/xmlrpc-c/code/advanced xmlrpc-c_advanced;\
    cd xmlrpc-c_advanced;\
    ./configure;\
    make;\
    make install;\
    ## Cela fait longtemps que j'ai la version 1.59 de xmlrpc-c et je n'ai jamais remarqué de problème.
    ## Attendre les prochaines versions de libtorrent et rtorrent ?
    ## Faut garder les versions stable car la compile fonctionne (contrairement à la branche master).
    ## Parce que rakshasa semble avoir disparu (abandonné ?) depuis presque une année sic...
    

    Autrefois il fallait mettre à jour la clef du dépôt de wandisco. Cependant cette méthode est osbolète (à l'abandon qui empêche toute mise à jours (mismatch apt)) !
    Donc désormais cet exemple nous prouve qu'ils existent parfois déjà des paquets pour Debian.

    HS : Je pensais répondre la semaine dernière. Cependant c'était impossible car le site était en panne ?
    Comme je remarque qu'il n'y a aucune information, cela confirme (renforce) ce que je disais (cela décourage(ra) les anciens ainsi que le sang neuf).

    Finalement je remarque que désormais il y a une explication alors @MattProd je te remercie.

  • Bonsoir,

    je demande s'il y a un éventuel rapport avec le souci évoqué par @lapinkifum ou @Victor ici :
    https://mondedie.fr/d/5395-Discussion-Installation-de-l-application-seedbox-manager/328
    https://mondedie.fr/d/9018-plantages-reguliers-de-rtorrent-kimsufi-ks-2e/

    Edit Mai 2017: Je rajoute, cela concerne peut-être aussi @Bono2007. Cependant, c'est compliqué de regrouper les points communs car on ignore des détails (gamme ou modèle ou OS, etc) sur la machine...
    https://mondedie.fr/d/5304-discussion-installer-rutorrent-sur-debian-8/2545

  • git checkout feature-bind;
    ## À la place de ces commandes :
    ##		'git checkout 0.13.6;'
    ##		'git checkout 0.9.6;'
    ## La date (des derniers commit) : 20 Mars et 11 Avril 2017.
    

    @Victor Par exemple, nous pouvons nous servir de cette commande afin de changer la branche (de rtorrent ou libtorrent).
    Donc, elle est plus récente et j'espère que cela pourra aider à résoudre le problème. Cependant, je préviens, cela risque d'échouer car il doit en manquer (des instructions)...

    En tout cas, je crois que l'on peut exclure la distribution.

  • C'est dommage... Bon courage et merci pour le retour @Victor.

  • Merci @Victor maintenant c'est un peu plus clair. Est-ce que les logs (de rtorrent) peuvent nous fournir un indice ? Même sur les plugins ? Je l'ignore, il faudrait mener des recherches (désolé mais non merci)...
    Par contre, il y a une petite méprise car il s'agit plutôt de rtorrent_v0.9.6, ruTorrent_v3.7 et libtorrent_v0.13.6 mais je n'utilise plus cette version (j'entends PHP_v5).

    Sur le moment, je l'avais oublié mais oui, nous pouvons également les désactiver par l'interface de ruTorrent (via l'onglet Plugins) ou alors avec le fichier plugins.ini (dont je réindiquerais l'emplacement si besoin).
    Assez récemment, il y a eu un souci avec le logiciel xmlrpc-c (lors de compile). Alors je me demande s'il en existe d'autres ? Ou s'il y en a eu d'autres par le passé ?
    Grosso modo, il y a des chances qu'il existe toujours un problème avec les versions supérieurs (soit la xmlrpc-c_v01.46.03)...

    whereis libtorrent rtorrent xmlrpc-c-config
    ## Dont voici le résultat : 
    {
    	libtorrent: /usr/local/lib/libtorrent.la /usr/local/lib/libtorrent.so
    	rtorrent: /usr/local/bin/rtorrent
    	xmlrpc-c-config: /usr/local/bin/xmlrpc-c-config
    }
    rtorrent -h | grep version;
    xmlrpc-c-config --version;
    ## A priori, non c'est impossible de procéder de même avec libtorrent...
    ## Parce que je le crains, on doit obtenir ceci : "command not found"(sic)...

    C'est exacte, il existe bien un paquet libxmlrpc-core-c3. De plus, d'après cette page, il semble provenir du paquet xmlrpc-c (car c'est le même site (xmlrpc l'officiel) cf le HomePage). Or, normalement ce xmlrpc-c devrait déjà être installé (via le SVN (et non Git)) et assez bien convenir. Néanmoins, ce ne sera point la première fois qu'il soit la cause d'un souci... Alors faudrait-il installer libxmlrpc-core-c3 ? C'est peut-être déjà le cas, non ?

    aptitude -sV install libxmlrpc-core-c3
    ## The following NEW packages will be installed : libxmlrpc-core-c3 [1.33.14-0.2]
    ## La commande apt n'a aucun paramètre (comme le s) afin de "simuler l'action" (cf aptitude -h)
    

    D'après cette commande, il semble que l'on puisse le faire (alors non, il n'est pas installé).