Open gelnior opened 11 years ago
Va sur http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable ça affiche les bug d'un pseudo-package appelé "wnpp", ce qui signifie "Work-Needing and Prospective Packages", et qui sert notamment mais pas que pour dire qu'on travaille sur un nouveau package. Dans ce cas précis on met dans le sujet du ticket "ITP" (Intent to Package). Il y a d'autres possibilités comme "O" (orphan) pour dire qu'on abandonne un package par exemple.
Sur cette page il faut chercher si newebe apparait. S'il y a une ITP, alors quelqu'un est en train de créer un package, ça permet de l'annoncer et d'éviter de refaire le même travail. S'il y a une RFP (Request for Package), alors un utilisateur demande s'il est possible de créer ce package ; dans ce cas si on désire le packager on transforme la RFP en ITP (en renommant le BR) et on "own" le bug (on marque qu'on est responsable du bug). Tu peux le faire par mail ou avec la commande 'bts'.
Dans le cas présent, il n'y a rien si j'ai bien lu, donc il faut que tu crées une ITP. Pour cela, regarde ici -> http://www.debian.org/Bugs/Reporting Précise que tu as un mentor (et tu peux mettre mon nom si besoin). Respecte bien les conventions, notamment de décrire sommairement le soft que tu vas packager en regardant la doc et les exemples.
Mon package python se base sur un fichier setup.cfg qui est le fichier rentrant dans la norme à venir des packages python. d2to1 permet de garder un setup.py et de rester compatible avec l'ancienne norme qui se base sur le setup.py.
Je vois. Je ne connais que le setup.py en fait, je n'ai pas fait de packaging Python depuis un moment.
En fait cet outil est déjà dans le package python-d2to1. Je te conseille donc de virer d2to1 de tes sources upstream. C'est de que faisait je patche je crois, donc tu peux le virer, et tout le répetoire 'debian/patches' devenu inutile par la même occase. Tu peux Build-Depends dessus et le générer à la volée, ça sera très élégant .
parce que debian supprime mes fichiers init.py dans certains dossiers. Leur absence provoque des problèmes d'import python. Je suis donc obligé de les recréer.
Ça n'est pas normal du tout, il doit y avoir un bug ou une explication quelque part, il faudra chercher.
Si, en fait je mets les logs dans /var/lib/newebe actuellement.
Ce n'est pas FHS compliant.
- il manque probablement un chmod après la création du certif (et pas systématiquement à chaque upgrade pour garder la conf custom du user) pour s'assurer que l'utilisateur newebe pourra lire la clef privée quels droits sont nécessaires ?
Je te conseille de faire que la clef privée appartienne au groupe newebe et de donner les droits de lecture au groupe (mais pas à other). Comme ça ton user newebe pourra uniquement lire la clef et personne d'autre.
parceque start stop daemon ne fonctionne pas avec newebe ou est trop compliqué à utiliser pour moi. Après de nombreux essais infructueux, j'ai laissé tombé pour une install plus directe que permet supervisor (ceci dit newebe est plus stable désormais, ça marcherait peut être).
Dans ce cas, vu qu'utiliser supervisor n'apporte absolument rien fonctionnellement, tu vas clairement te faire pourrir pour avoir forcé à installer une dépendance inutile. On pourra jeter un œil ensemble sur ce point si tu veux.
Résumé du reste à faire:
W: newebe source: maintainer-script-lacks-debhelper-token debian/postinst W: newebe source: maintainer-script-lacks-debhelper-token debian/postrm W: newebe source: package-needs-versioned-debhelper-build-depends 8 W: newebe source: build-depends-on-python-dev-with-no-arch-any W: newebe-server: copyright-without-copyright-notice W: newebe-server: extended-description-contains-empty-paragraph W: newebe-server: non-standard-dir-in-usr usr/newebe/ W: newebe-server: file-in-unusual-dir usr/newebe/LICENSE W: newebe-server: extra-license-file usr/newebe/LICENSE W: newebe-server: file-in-unusual-dir usr/newebe/MANIFEST.in W: newebe-server: file-in-unusual-dir usr/newebe/README.rst W: newebe-server: file-in-unusual-dir usr/newebe/setup.cfg W: newebe-server: file-in-unusual-dir usr/newebe/setup.py W: newebe-server: zero-byte-file-in-doc-directory usr/share/doc/newebe-server/copyright W: newebe-server: package-contains-vcs-control-file usr/share/pyshared/newebe/client/.gitignore W: newebe-server: binary-without-manpage usr/bin/newebe_server W: newebe-server: maintainer-script-ignores-errors postrm W: newebe-server: maintainer-script-needs-depends-on-adduser postins
From Duck, Debian developer:
Il faudra penser à s/UNRELEASED/unstable/ dans le changelog. Pour ce qui est du BR à clore, il faut chercher si quelqu'un a déjà créé un BR, voir avec lui pour le owner (bts owner) sans que ça soit du hijacking, sinon le créer selon le modèle usuel.
Dans debian/patches/ tu noteras qu'il y a un patch debian-changes-0.6.0. En fait quand tu modifies les sources comparativement à ton tarball, et que tu lance un build en gardant ces modifications, il crée automatiquement un patch, car en fait quand tu partage ton package source avec d'autres gens, les sources originelles et les infos debian permettent de regénérer le workdir et de build identiquement. Concernant ce patch :
Concernant debian/postinst :
Il manque un debian/postrm qui défait les choses de postinst en cas de purge :
Quelques questions, orientée upstream cette fois :