60

flanker (./59) :
J'ai l'impression qu'on ne se comprend pas grin
Alors ça oui, je te confirme, c'est même ce que j'essaie d'expliquer depuis plusieurs posts grin
flanker (./59) :
Si c'est un dépôt de type tar.gz (qui n'existe pas encore), on aura un seul fichier /var/backups/monarchive.tar.gz (avec un petit dossier caché à côté pour conserver l'état du dépôt).
Arg, "tar" aussi ça va devenir à la fois un type de local repo et de remote repo ? Je pense vraiment que ça aurait du être un local repo et rien d'autre, si tu comptes laisser les deux alors vraiment je ne comprends pas la logique derrière le découpage sorry
flanker (./59) :
Malheureusement, ça modifie /var/backups/local1 et ça me chagrine quand même pas mal sad
Mais pourquoi tu veux que ça modifie ton dossier ? Garde les metadonnées Git ailleurs, par exemple avec core.worktree, c'est pourtant pas les options qui manquent ?

Mais bon, pour insister encore une fois, tout ça me semble moins gênant que la différence qui me parait de plus en plus floue entre les deux types de repos sad
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

61

Ah ok, c'est sûrement l'option core.worktree qui me manquait ^^ Du coup, je peux en effet abandonner le type « git » pour les dépôts locaux.

En revanche, après une courte réflexion (bon, ok, une nuit complète grin) : je ne peux pas créer l'archive côté local. Je veux pouvoir stocker d'un côté les fichiers dans un gitlab distant, d'un autre faire des archives à échéances régulières. Ça impose que la création d'archive soit faite par le remote repository.

L'autre possibilité serait de faire un truc en trois couches : stockage local | stockage distant | transport. Cela reviendrait à ajouter une nouvelle section (optionnelle) dans le remote repository, afin d'éventuellement transformer les fichiers qui seront envoyés. Ça ne serait pas trop coûteux, et la valeur par défaut serait une fonction identité.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

62

flanker (./61) :
Je veux pouvoir stocker d'un côté les fichiers dans un gitlab distant, d'un autre faire des archives à échéances régulières. Ça impose que la création d'archive soit faite par le remote repository.
Je n'ai pas compris cette partie ?

Tel que je vois le machin actuellement, on a :

- Repo local 1 (engine=files) sauvegarde ses fichiers bruts
- Repo local 2 (engine=tar) sauvegarde ses fichiers dans un .tar
- Repo remote 1 (engine=git) prend les fichiers de repo local 1 + le tar de repo local 2, fait un commit avec ça et l'envoie sur le remote

C'est pas comme ça que ça fonctionne ? (ou pourrait fonctionner)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

63

Zeph (./62) :
flanker (./61) :
Je veux pouvoir stocker d'un côté les fichiers dans un gitlab distant, d'un autre faire des archives à échéances régulières. Ça impose que la création d'archive soit faite par le remote repository.
Je n'ai pas compris cette partie ?

Tel que je vois le machin actuellement, on a :

- Repo local 1 (engine=files) sauvegarde ses fichiers bruts
- Repo local 2 (engine=tar) sauvegarde ses fichiers dans un .tar
- Repo remote 1 (engine=git) prend les fichiers de repo local 1 + le tar de repo local 2, fait un commit avec ça et l'envoie sur le remote
C'est pas comme ça que ça fonctionne ? (ou pourrait fonctionner)
Je n'accroche pas à cette vision :
  • ça imposerait deux dumps SQL successifs de la même base (avec la possibilité d'avoir des dumps légèrement différents),
  • ça voudrait dire donner deux fois les mêmes coordonnées de la base de données,
  • si le remote prend les deux locaux en même temps, ça signifie que les deux locaux ont la même fréquence de sauvegarde.
  • cela signifie mélanger les données de deux projets différents ensemble dans le même remote.


Dans mon idée, il y a un dépôt local par projet à sauvegarder (par site web, par exemple) avec les fichiers et les bases de données. Il y a également un dépôt distant par destination de sauvegarde (par exemple un git et un archivage régulier de tar.gz).
Et surtout :
  • si j'ajoute un site web, j'ajoute un fichier .local et les données de ce nouveau site sont automatiquement ajoutées aux deux destinations,
  • si j'ajoute une nouvelle destination, j'ajoute un seul fichier .remote et automatiquement les données de tous les sites existants sont poussées vers ce nouveau site à la prochaine sauvegarde,
  • chaque destination et source a sa propre fréquence de sauvegarde.

Le fonctionnement est donc plutôt :
  • local1.backup()
  • local2.backup()
  • remote1.backup(local1)
  • remote2.backup(local1)
  • remote1.backup(local2)
  • remote2.backup(local2)
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

64

J'arrive pas trop à comprendre à quel niveau de la discussion on se perd, mais j'ai l'impression d'être d'accord avec tous les points que tu cites, juste pas avec l'implémentation actuelle grin

Je suis bien sûr d'accord qu'un unique snapshot devrait être pris par repo local lors d'un backup, et que n'avoir aucun lien entre "local repo" et "remote repo" permet de dissocier les sources à sauvegarder des emplacements de sauvegarde, ce qui est une bonne chose. D'ailleurs le duo "local repo git" et "remote repo git" me semble aller exactement à l'encontre de cette dernière règle.

Il me semble qu'on peut répondre à toutes tes contraintes tout en appliquant les suggestions que je listais en ./53 ; la seule contrainte est d'utiliser un dossier temporaire entre le dump et l'envoi sur les remotes, mais ça me semble plutôt acceptable (et surtout transparent).
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

65

Prenons un exemple : j'ai www.yaronet.com et ns.yaronet.com à sauvegarder.
Je veux les fichiers uploadés et les bases MySQL pour les deux sites :
  • les données telles quelles dans un serveur git+http tous les jours
  • les données dans une archive.tar.gz toutes les semaines poussée dans un FTP
J'ai deux sites à sauvegarder, et deux systèmes de sauvegarde : je ne veux donc pas plus de 4 fichiers de conf' au total : deux .local (www.local et ns.local) et deux .remote (git.remote et tar-curl.remote) .

Pour chacun des deux sites, j'ai donc les opérations suivantes à effectuer
  • (A : collecte des données) -> (B : fonction identité) -> (C : git add en local + git push distant)
  • (D : collecte des données) -> (E : archivage et compression) -> (F : curl -T vers le serveur FTP)
La collecte des données (A et D) ne doit se faire qu'une fois, on est d'accord pour mettre ça dans le fichier .local de chaque site, avec une section du fichier de conf pour décrire où je collecte et à quelle fréquence, et une section par source (MySQL, fichiers, Postgres…).

Actuellement on n'a que des couples (B, C) et (E, F), sans possibilité de choisir (B, F) ou (E, C) et le couple (B, C) est décrit dans un fichier git.remote, le couple (E, F) étant dans tar-curl.remote.

Si je comprends bien ce que tu veux dire, tu proposes de décrire B et E dans les fichiers www.local et ns.local, pour obtenir www-identite.local, www-targz.local, ns-identite.local, ns-targz.local. Seul C serait dans git.remote, et enfin seul F serait dans curl.remote. Ça double donc les fichiers de conf -> inacceptable.
L'autre possibilité pour découpler (B, C) et (E, F) est de ne garder que www.local et ns.local, et de décrire les étapes B et E dans chacun de ces deux fichiers. Mais comment C et F sauraient qu'ils ne doivent s'appliquer qu'à B et E respectivement ?



En revanche, une solution, peu coûteuse, serait de découper les .remote en deux sections : [format] et [transport].
Dans la section [format], qui serait optionnelle, on décrirait la transformation à appliquer aux fichiers avant de les envoyer (donc B et E).
Dans la section [transport], obligatoire, on décrirait la méthode d'envoi (donc C et F).
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

66

Zeph (./64) :
D'ailleurs le duo "local repo git" et "remote repo git" me semble aller exactement à l'encontre de cette dernière règle.
C'était seulement un problème de compétence du développeur gni
J'ai modifié le code (mais pas encore testé) pour utiliser les options --git-dir et --worktree (que je connaissais pas), et donc utiliser n'importe quel type de dépôt local avec du git distant.
Mais ça n'empêche pas l'utilisateur de vouloir utiliser un git en local (sans sauvegarde distante, par exemple) à la place de fichiers plats.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

67

flanker (./65) :
Si je comprends bien ce que tu veux dire, tu proposes de décrire B et E dans les fichiers www.local et ns.local, pour obtenir www-identite.local, www-targz.local, ns-identite.local, ns-targz.local. Seul C serait dans git.remote, et enfin seul F serait dans curl.remote.
Non pas du tout ?

Pour reprendre ton exemple j'aurais bien un fichier local pour www.yaronet.com et un second pour ns.yaronet.com. Ils décriraient chacun comment récupérer les données à sauvegarder, par exemple exporter une BDD, lire tel quel un dossier dans mon file system, créer une archive "tar", etc. En revanche il n'est pas question ici de parler de git, à moins éventuellement de vouloir sauvegarder le contenu d'un repo Git (mais le mode "file system" pourrait probablement être utilisé ici donc je ne suis pas sûr de voir l'intérêt).

Ensuite, une fois ces deux ensembles d'actions effectués se pose la question de ce que je veux en faire. À nouveau deux fichiers ici : celui pour décrire ma sauvegarde vers un serveur Git et celui pour envoyer mes fichiers via FTP. En traitant mes deux fichiers locaux j'ai obtenu tous les fichiers à sauvegarder, il n'est donc pas question ici de transformer quoi que ce soit, uniquement envoyer le contenu là où il doit se retrouver : dans le cas de Git il s'agira d'un commit + push, dans le cas du FTP il s'agira d'une commande cURL pour envoyer mon/mes fichiers sur un serveur distant.

Dans ton dernier paragraphe je ne comprends (toujours) pas pourquoi tu veux absolument mettre le format dans les remotes, alors qu'il me parait bien plus logique de les mettre dans les locaux. Pourquoi est-ce que ton transport (remote) aurait quoi que ce soit à connaître du contenu qu'il transporte ? En revanche à l'endroit où je décris ce que je veux sauvegarder (local), ça me semble possible de décrire également sous quelle forme je veux le sauvegarder. On pourrait imaginer un truc à trois niveaux à la place, mais je ne pense pas que ça représente un intérêt suffisant pour tout compliquer davantage.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

68

mais si je crée l'archive "tar" au niveau du local, elle sera envoyée dans le git (ce que je ne veux pas) et dans le FTP (ce que je veux). On donne le même local à manger aux deux remote ; je ne vois pas comment git saurait qu'il ne faut pas utiliser le "tar" et comment ftp saurait qu'il faut au contraire l'utiliser. Je veux bien que tu me montres les exemples de fichiers de conf, je ne vois vraiment pas comment ils seraient rédigés.
Dans ton dernier paragraphe je ne comprends (toujours) pas pourquoi tu veux absolument mettre le format dans les remote, alors qu'il me parait bien plus logique de les mettre dans les locaux.

Sûrement parce que je veux utiliser des formats différents pour chaque remote ^^
Pourquoi est-ce que ton transport (remote) aurait quoi que ce soit à connaître du contenu qu'il transporte ?
Point de détail : certains transports ne fonctionnent facilement qu'avec un seul fichier (coucou WEBDAV), sachant que je veux au moins une solution sans ssh ^^
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

69

flanker (./68) :
Sûrement parce que je veux utiliser des formats différents pour chaque remote ^^
Ah, alors c'est probablement ça que je n'avais pas compris. Je ne pense pas que ce soit une bonne idée, mais OK effectivement à cause de cette contrainte tu ne vas pas pouvoir trop t'éloigner de ton modèle actuel.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

70

* Je trouve dommage d'utiliser git pour y stocker des .tar.gz smile j'aime bien l'idée d'avoir une interface graphique (gitlab, en l'occurrence) pour consulter les fichiers sauvegardés
* ce que tu veux faire est cependant tout à fait possible, il suffit de créer un nouveau type de dépôt local, en plus du mode "fichiers plats" et "git" (j'ai un tout petit ajustement d'API à faire, mais c'est une bonne idée)
* j'ajouterai peut-être la section supplémentaire dans les remotes, ça ne coûte pas grand-chose (et pourrait être utilisée pour le chiffrement)
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

71

flanker (./70) :
Je trouve dommage d'utiliser git pour y stocker des .tar.gz smile
Je suis d'accord, mais si c'est ce que demande de faire la configuration, tant pis smile (en pratique bien sûr j'utiliserai surement une sauvegarde en mode "files" à la place)
flanker (./70) :
* ce que tu veux faire est cependant tout à fait possible, il suffit de créer un nouveau type de dépôt local, en plus du mode "fichiers plats" et "git" (j'ai un tout petit ajustement d'API à faire, mais c'est une bonne idée)
OK, je ne vois pas encore comment ça pourrait être intégré mais si c'est possible tant mieux smile

Sinon est-ce que tu sais ce qui peut provoquer le bug de ./50 ? Je l'avais encore la dernière fois que j'ai tenté (cf ./53) et je pense que c'est l'unique chose qui manque avant de pouvoir remplacer tous mes scripts par ton soft. Mais peut-être que tu l'as déjà corrigé, je n'ai pas essayé depuis plusieurs jours smile
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

72

Je pense que je l'ai corrigé depuis (config chargeait les plugins disponibles lui-même - utiliser les setuptools ne prend que 2 lignes, ça ne valait pas le coup de factoriser le code). Mais autant que tu attendes quelques jours, histoire que je rajoute les nouvelles fonctionnalités.

J'ai également passé pas mal de temps sur la doc smile

Par contre, pour les tests, c'est un peu en pause tant que je n'aurais pas mon nouvel ordi sad
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

73

Zeph (./71) :
flanker (./70) :
Je trouve dommage d'utiliser git pour y stocker des .tar.gz smile
Je suis d'accord, mais si c'est ce que demande de faire la configuration, tant pis smile (en pratique bien sûr j'utiliserai surement une sauvegarde en mode "files" à la place)
Mais du coup, comment imaginerais-tu mon cas d'usage (des archives de temps en temps, et du diff très souvent pour économiser la bande passante) ? Autant avoir tous les arguments pour les deux propositions, tant qu'à faire ^^

Au passage, je suis assez rassuré qu'on ait fini par se comprendre, je commençais à me poser des questions grin
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

74

Bon a priori le bug des engines non chargés n'est pas corrigé sad

Sinon pour ton cas d'utilisation, je pense que si j'avais le même j'aurais coupé en trois parties : des sources qui collectent les fichiers à sauvegarder (sans les modifier), des formats d'archivage qui appliquent une éventuelle modification à ces fichiers (ex. : tar, chiffrement, etc.), et des emplacements de sauvegarde vers lesquels on copie les données (ex. : copie locale, git, ftp, webdav).
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

75

Ça rendrait la config un peu complexe à mon goût (faut gérer les associations local <-> formats <-> remote, je trouve que c'est déjà assez pénible comme ça).

Bon, au moins on se comprend, c'est l'essentiel smile

Rapide état des lieux :
  • nouveau type de dépôt local : archive tar.(gz|xz|bz2), pour faire plaisir à Bob (^^)
  • possibilité de créer automatiquement un projet Gitlab avant de pusher dedans
  • normalement compatible Python 2.7&3.3+ (j'attends de finir mon Vagrant pour tester proprement)

Ce qui reste à faire
  • faire un client webdav minimaliste (peut-être à coups de cURL)
  • toute la partie restauration (*)
  • faire un système de filtres après le backup local ou avant le backup remote pour ajouter ou remplacer des fichiers (chiffrer, signer, calculer des hash…)
  • noter les hash md5 des fichiers de conf pour forcer un backup en cas de modification

(*) le vrai problème est de pouvoir récupérer le dernier fichier envoyé et sa date, pour pouvoir récupérer les données du remote le plus récent. Exemple à la con : on envoie les données vers l'URL http://webdav.example.org/project/archive-MM-DD-YYYY.tar.gz dans un cas, et http://webdav.example.org/project/archive-DD-MM-YYYY.tar.gz dans l'autre.
Déjà il faut pouvoir lister les fichiers du dossier, et ensuite déterminer le bon fichier. Je ne suis pas encore sûr de la bonne solution à retenir.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

76

flanker (./75) :
Ça rendrait la config un peu complexe à mon goût (faut gérer les associations local <-> formats <-> remote, je trouve que c'est déjà assez pénible comme ça).

Bon, au moins on se comprend, c'est l'essentiel smile
Oui je comprends ton choix et les raisons derrière, et ça ne m'empêchera rien de ce que je comptais faire avec polyarchiv donc pas de problème smile
flanker (./75) :
nouveau type de dépôt local : archive tar.(gz|xz|bz2), pour faire plaisir à Bob (^^)
top
flanker (./75) :
faire un système de filtres après le backup local ou avant le backup remote pour ajouter ou remplacer des fichiers (chiffrer, signer, calculer des hash…)
...créer un .tar.gz... tongue (cool pour le chiffrement sinon smile)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

77

Désolé de t'embêter encore une fois, mais j'ai une petite question ^^

J'imagine de faire des fichiers de conf un peu modifiés :

[repository]
engine=files
path=/var/backups/project1
[source:bdd]
engine=mysql
host=localhost
[source:files]
engine=files
[filter:hashes]
engine=hashsum
type=md5

Cela permettrait d'ajouter les fameux filtres sans trop de souci, et sans avoir une syntaxe trop alambiquée. Qu'en penses-tu ?
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

78

C'est toi qui code, ça serait plutôt moi qui t'embête depuis le début pour le coup grin

Pour ta nouvelle syntaxe, c'est pas mal et ça permet en bonus de désambiguiser la section "repository" (on peut à nouveau avoir une source qui s'appelle comme ça), donc cool smile Juste une suggestion : ce que tu fais ressemble beaucoup aux fichiers de configuration de Git, qui sont des INI avec une syntaxe très proche pour gérer les sous-sections, par exemple :[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "origin"] url = git@github.com:r3c/creep.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/masterJe ne sais pas si c'est standard (= si c'est utilisé ailleurs que dans Git), mais quitte à implémenter quelque chose de similaire ça pourrait être pas mal de réutiliser le même format non ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

79

Bon ça va, c'est pas toi qui va te réécrire ConfLib embarrassed

80

Ok pour la syntaxe ^^ (bon, en vrai, ça fonctionnera quand même si on ne met pas de guillemets vu que j'utilise shlex pour décoder)

On peut maintenant créer des filtres, je suis en train d'en écrire un basé sur gpg, en mode naïf : je chiffre chaque fichier indépendamment et les noms de fichier sont conservés.

Ça va me faire pas mal de docs à réécrire, au final sad 

Et surtout, il faut absolument que j'écrive la phase de restauration, qui est pas mal compliquée par l'existence des filtres :
  • trouver le remote repository le plus récent (j'ai un petit souci à ce niveau)
  • récupérer les données
  • appliquer dans l'ordre inverse les filtres du remote
  • appliquer dans l'ordre inverse les filtres du local
  • extraire les données du local
  • restaurer les données dans chaque source
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

81

Je crois que tu n'as pas bien compris le principe de l'open-source. Il ne fallait pas faire ce que Zeph demande, mais lui répondre : "si ça ne te convient pas, crée un fork" oui
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

82

flanker (./80) :
Ok pour la syntaxe ^^ (bon, en vrai, ça fonctionnera quand même si on ne met pas de guillemets vu que j'utilise shlex pour décoder)
top encore mieux smile

Je ne sais pas si le bug des engines pas trouvés est facile à résoudre, mais si c'est pas trop compliqué ça me permettrait de commencer à utiliser le soft et te trouver plein d'autres bugs grin
Zerosquare (./81) :
Je crois que tu n'as pas bien compris le principe de l'open-source. Il ne fallait pas faire ce que Zeph demande, mais lui répondre : "si ça ne te convient pas, crée un fork" oui
Attends voir ton prochain bug report sur yN toi embarrassed
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

83

Zeph (./82) :
Zerosquare (./81) :
Je crois que tu n'as pas bien compris le principe de l'open-source. Il ne fallait pas faire ce que Zeph demande, mais lui répondre : "si ça ne te convient pas, crée un fork" oui
Attends voir ton prochain bug report sur yN toi embarrassed
Ça ne vaut pas parce que yN n'est pas libre.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

84

Oh, pardon : </BLAGUE>.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

85

Zeph (./82) :
Attends voir ton prochain bug report sur yN toi embarrassed
fear
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

86

Zeph (./82) :
flanker (./80) :
Ok pour la syntaxe ^^ (bon, en vrai, ça fonctionnera quand même si on ne met pas de guillemets vu que j'utilise shlex pour décoder)
top encore mieux smile

Je ne sais pas si le bug des engins pas trouvés est facile à résoudre, mais si c'est pas trop compliqué ça me permettrait de commencer à utiliser le soft et te trouver plein d'autres bugs grin
Je pense avoir trouvé celui qui restait, mais du coup j'ai un peu de mal à être très affirmatif tsss

J'ai commencé à modifier la doc, qu'en penses-tu ?

Au passage, je pense que je vais devoir modifier un peu les différents remote, voire en supprimer, afin de pouvoir récupérer facilement la date de dernière mise à jour.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

87

vagrant@limestone:~$ sudo -u polyarchiv polyarchiv backup List of built-in engines: In file '/etc/polyarchiv/httpd_site__fr_mirari_www.local', section 'repository': invalid engine 'files'Toujours pas sad

Je peux faire quelque chose pour t'aider à trouver ? (pke bon c'est assez gênant comme bug du coup, ça m'empêche totalement d'utiliser le soft grin)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

88

mais là, tu ne l'exécutes pas depuis les sources hum je croyais que c'était le cas (avec python run.py — va falloir que je renomme le fichier, au passage)
Du coup, comment as-tu installé le truc ?
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

89

Si si, j'ai simplement cloné le repo (hier à peu près à l'heure de mon post) dans /var/opt/polyarchiv, puis créé un lien symbolique dans /usr/bin/polyarchiv vers /var/opt/polyarchiv/run.py.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

90

Ça explique tout, je pense.

Je cherche un fichier engines.ini par rapport au fichier run.py. Mais avec le symlink, il cherche /usr/bin/engines.ini et non /var/opt/polyarchiv/engines.ini .

Du coup, ça devrait fonctionner smile
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant