Diaoul

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}

Je dirais, accèdes y via le raccourcis dans DSM pour commencer avec les identifiants que tu as mis lors de l'installation (ou admin-admin il me semble si tu n'as rien renseigné)

Sinon, rapidement les points à savoir : Dans cross/ chaque sous dossier contient le nécessaire à la cross compilation de la librairie ou du programme. A savoir : Un Makefile qui indique les informations de cette lib/bin : Nom Version URL pour le téléchargement Extension du fichier téléchargé Dépendences vers d'autres libs s'il y en a Arguments supplémentaires au script de "configure" s'il y en a [*]Un PLIST qui contient la liste des fichiers binaires créés comme les programmes ou le .so. Une PLIST est automatiquement générée par spksrc dans les répertoires de travail (work*), il suffit alors de la compléter et de la mettre ici [*]Un digests qui contient les hashs md5 et sha1 du fichier téléchargé afin de vérifier que ce soit le bon. Ce fichier est optionel, s'il n'est pas présent, les digests ne sont pas vérifiés Pour commencer à cross compiler un programme ou une librairie il faut : Crééer un dossier dans le répertoire cross/ portant le nom de ce package en minuscule Copier un Makefile d'exemple dans ce dossier depuis un autre afin de s'épargner un peu de recopiage, au hasard cross/umurmur/Makefile Le modifier en changeant les variables, renseigner DEPENDS à vide pour l'instant Dans un terminal, aller dans cross/{package} et taper "make ARCH=88f6281" (par exemple). Tout le reste se fait automatiquement Selon les erreurs dans le configure (dépendances), ajouter les librairies dans DEPENDS (cross/zlib par exemple). Si la dépendance n'existe pas encore, l'ajouter en recommençant de l'étape 1. Selon les erreurs dans le configure (hors dépendances), les corriger en changeant les arguments du configure avec la variable "CONFIGURE_ARGS" Selon les erreurs de cross compilation, déposer des patchs dans le répertoire "patches", ils seront automatiquement appliqués En vrac, depuis cross/{package} : Pour nettoyer la cross compilation : "make ARCH=88f6281 clean" Pour ne nettoyer que le package actuel sans les dépendances : "make ARCH=88f6281 smart-clean" On verra plus tard pour les SPKs, quand tu auras un binaire tout fait

As tu lu le README ? https://github.com/SynoCommunity/spksrc/blob/develop/README.md Certes ce n'est pas grand chose mais c'est déjà ça. Je prévois de documenter un peu plus prochainement, c'est sur ma TODO avec environ 15 autres choses

Nickel, pour les prochaines mises à jour j'essayerai de faire le changelog...

/var/packages/sabnzbd/scripts/start-stop-status[/CODE]

La liste des commits : https://github.com/SynoCommunity/spksrc/commits/develop Pour mettre les changelog sur le site, c'est déjà le cas pour Python

Quand tu désactive le serveur SSH il y en a quand même un qui tourne... Moi je pense que Syno garde le moyen de se connecter en SSH avec un compte dont ils sont seuls à connaitre la private key (ou le password). J'ai jamais pris le temps de regarder de plus près tout ça cependant... Pourquoi d'autre un serveur SSH tournerait-il alors qu'on l'a désactivé ?

En effet, c'est la raison.

Il est possible d'utiliser un autre serveur UPnP que celui que fourni Syno et qui supporte le transcodage. C'est relativement simple à transcoder et ça prend pas trop de ressources visiblement vu qu'il suffit d'incruster des sous-titres. Cf http://bugs.freeplayer.org/task/3575#comment16374 http://blog.didrocks.fr/post/Media-server-sur-ubuntu-srt-et-youtube%3A-Freebox-V6-0%2C-PS3%3A-1 http://mediatomb.cc/ Ici la liste des serveurs UPnP : http://en.wikipedia.org/wiki/List_of_UPnP_AV_media_servers_and_clients#UPnP_AV_media_servers S'il y en a un qui supporte le transcoding et que tu veux tenter l'aventure sur Syno tu peux toujours faire un petit SPK avec spksrc

Pareil, et je suis sous DSM 4.0

Je crois que la freebox n'exploite pas le DLNA mais l'UPnP. L'UPnP du Syno envoie bien les sous-titres à ma connaissance mais la freebox ne sait pas les lire via UPnP. Une limitation du Freebox Player en somme...