Diaoul

Y'a pas le code source à priori donc c'est mort

Parce que le .so est une librairie compilée et qu'il faut la compiler avec la toolchain de Synology pour ton architecture de CPU. Tu peux copier mais ça marchera pas. Ce qui empêche de le faire en natif est l’absence de tout outil de développement sur ton Syno (gcc, autotools, libtool, etc.) Fais moi une liste des modules qui t'intéressent, je te ferai un SPK avec ces modules et tu testeras. Quand c'est validé on fera la release du nouveau SPK.

Tu confonds 2 choses : l'utilisation de znc et la compilation de znc. --enable-extra est une option de compilation qui est activé pour ZNC fourni par SynoCommunity : https://github.com/SynoCommunity/spksrc/blob/develop/cross/znc/Makefile#L15 Impossible de compiler un module pour ZNC en dehors de ce qui est fourni dans le SPK. Si tu souhaites rajouter un module, tu peux ouvrir une issue sur SPKSRC : https://github.com/SynoCommunity/spksrc/issues

Bon on récapitule : Activer le post traitement dans NZB Config - > SickBeard Configurer le post traitement dans NZB Config pour ton newsgrabber (NZBGet ou SABnzbd) Chez moi ça marche donc je pense que tu cliques pas au bon endroit. La seule chose qui n'est pas mises à jour c'est le port en cas de changement.

J'en pense que tu rêves un peu Si tu trouves un programme qui fait déjà tout ça, je peux te faire un SPK avec mais sinon c'est cuit je pense.

Le APC Back-UPS CS 650VA est offline contrairement à ce qui a été dit.

Comme par exemple avec Headphones ?

Et bah tu vas dans NZB Config, tu coches postprocessing et tu valides.

Voilà de la doc pour faire de la doc : https://github.com/SynoCommunity/spksrc/wiki/Create-documentation

De quoi tu parles ? NZB Config fait très bien ça tout seul.

En revanche, il y a des alternatives opensource et librement redistribuables : http://cgit.openembedded.org/openembedded/tree/recipes/openjdk http://cgit.openembedded.org/openembedded/tree/recipes/icedtea Franchement ça risque d'être chaud vu le nombre de patchs appliqués. En gros il faudrait tout reprendre et convertir à SPKSRC... S'il y a un courageux ça peut valoir le coup

Il est, a ma connaissance, interdit de redistribuer Java sans l'accord de Oracle. Donc ça fait un SPK ou l'utilisateur doit télécharger java et le transférer sur son Syno. Je trouve ça bof :/

Hello, Je crois que c'est un bug connu, contacte Syno pour avoir un patch : https://github.com/SynoCommunity/spksrc/issues/81 Ici : http://59.124.41.244/enu/viewtopic.php?f=7&t=49878&sid=b9f6b9f8956b7fd654d69083431593a0&start=30

Un SPK c'est jamais que : Le programme que tu as cross compilé avec succès Un script de start-stop-status Un script d'installation / update Une icone (Optionnel) Une interface web intégrée à DSM ou un raccourcis vers l'interface web du binaire Ca se passe dans spk/ et il y a un dossier par SPK. Je pense qu'un bon exemple est uMurmur, tu copies spk/umurmur vers spk/{package} et tu modifies en conséquence. Tu remarqueras que les scripts sont assez standardisés, tu devrais pouvoir trouver des bouts de code dans les SPKs existants.

Pour le lancement des kernel modules je t'invite à regarder le SPK audio station. Il y a un keyword dans le INFO je crois qui les lance automatiquement. Ou alors c'est dans le script de start-stop-status. Tu peux aussi regarder nos travaux sur spksrc et le repo de SynoCommunity. On est ouvert à toute personne intéressée pour contribuer. Pour info c'est un outil qui permet de cross compiler facilement et de faire des SPKs tout aussi simplement. Un minimum d'étape est nécessaire à la création de SPK.

Non c'est pas reparti pour un tour Là c'est ton HOSTCC (gcc sur ta machine host, x86 donc) qui utilise les arguments (CFLAGS) du gcc de la toolchain (un gcc qui permet de faire des binaires utilisables sur la target : le NAS). Tu as bien mis le doigt dessus : HOSTCC ?= $(CC) HOSTCFLAGS ?= $(CFLAGS) On a corrigé le HOSTCC qui prennait le mauvais GCC mais on n'a pas corrigé les arguments qui y sont passés et qui sont spécifique à l'ARCH. ENV += HOSTCC=gcc HOSTCFLAGS=[/code]

Ce que je ne comprends pas c'est pourquoi il a besoin d'un HOSTCC alors que ce n'est pas précisé dans le configure. Bref, quand c'est comme ça ce que tu fais c'est : Recherche Google avec ton erreur Investigue toi même comme tu le fais Consulter les règles de OpenEmbedded s'ils l'ont http://cgit.openembe...ed/tree/recipes Consulter les règles Optware s'ils l'ont http://trac.nslu2-li...e/browser/trunk Tout ça a fin de trouver les bonnes variables à mettre et les bons arguments. Essaye d'écraser HOSTCC par "gcc" tout simplement en rajoutant HOSTCC=gcc dans CONFIGURE_ARGS Si ça ne marche pas, essaye de le mettre dans ENV : ENV += HOSTCC=gcc J'ai l'impression que ce darkstat est un bon cas d'école

Recherche HOSTCC dans le config.log, le Makefile. En général, c'est dans les .in comme configure.in etc. Parfois dans les ac

Ce qu'il y a c'est que il utilise un autre GCC pour compiler ça : HOSTCC au lieu de CC. Donc je pense que HOSTCC pointe vers ton gcc à toi et pas le cross. Ce qui fait que GCC il utilise un truc illisible produit par le GCC de cross. D'ou l'erreur. Essaye de faire "cross/darkstat/work-88f6281/darkstat-3.0.715/configure --help" pour voir les options qu'il te propose et s'il y a quelque chose en relation avec HOSTCC. Ultimement, essaye en écrasant la variable HOSTCC par la même valeur que CC avec qqch du genre : ENV += HOSTCC=$$(CC) dans le Makefile

Peut être que tu devrais rajouter cross/flex dans DEPENDS.

Si je résume : Tu as cross/libcap avec un Makefile adapté et la description de ce qu'il faut Quand dans cross/libcap tu tapes "make ARCH=88f6281" tout se passe bien ? Tu as bien le répertoire cross/libcap/work-88f6281/install/ avec toute l'arborescence qui va bien et les binaires dedans ? (lib+bin) Et les headers ? (include) Si ça c'est bon, tu fais pareil avec Darkstat : Répertoire cross/darkstat avec un Makefile adapté avec bien sur "DEPENDS = cross/libcap" Ensuite dans cross/darkstat tu tapes "make ARCH=88f6281" et là ça merdouille ? Le make de SPKSRC passe par plusieurs étapes pour un binaire : depends download extract patch configure build install Je te conseille donc d'essayer d'identifier à quelle étape ça merde, en tapant successivement "make ARCH=88f6281 {etape}" dans le répertoire cross/darkstat après avoir nettoyé le tout avec "make clean". Il faut vraiment plus de logs aussi, met sur pastebin et envoie la totale. Saches que dans spksrc on ne touche jamais au code des binaires, si ça merde c'est un problème de configuration (étape configure) ou build (étape de compilation). Peu utile donc d'aller voir le code du programme, je ne suis même pas sûr que ça puisse te donner des pistes. Quels paquets as tu installé sur Debian pour pouvoir cross compiler libcap ?

Oui tu peux mettre ton lien dans /usr/local et il sera conservé. /usr/local/site est très bien, mais je pense que CoolRaoul préfère taper /site Si c'est une fonctionnalité générique que tu cherches le mieux est encore de faire un SPK comme ça les autres en profitent aussi

Ce que je voulais dire c'est que pour l'instant dans l'installation il faut retirer les device USB, puis les remettre etc. Je pense que l'on peut améliorer cette partie là. Si j'ai bien compris. J'ai quelques questions : Qu'utilises-tu pour la cross compilation ? Est-ce que tu ajoutes des kernel modules ? Pourquoi ne pas faire une interface intégrée à DSM un peu comme VPN Center ou les autres SPKs officiels ? Qu'est-ce qu'il y a sous le capot du SPK ? Bravo pour le boulot en tout cas

Bah utilise le paquet de Merty si tu préfères hein. Avec NZB Config je n'ai jamais eu à éditer un seul fichier de conf en utilisant les ports par défaut. Je suis parti du principe qu'une personne voulant changer les ports serait capable de modifier les fichiers de configuration adéquats. J'ai fait en sorte que l'icone sur le bureau pointe toujours vers le bon raccourci même en cas de changement de port. NZB Config sera mis à jour avec des fonctionnalités permettant la bonne configuration du post processing malgré un changement de port et le support du HTTPS.

C'est pour ça que les SPKs créent un lien dans /usr/local/ vers /volume1/@appstore/{package}