Gitea: Fournir des versions et des packages deb/rpm via Bintray

A-t-on vraiment besoin de deb/rpm ? Les images Docker ne suffisent-elles pas ? Idk, prouvez-moi que j'ai tort ! :)

drone n'a que des images docker, n'est-ce pas ?

Gogs utilise packager.io, pourquoi ne pas le réutiliser ?

Parce que tout le monde n'utilise pas / n'utilisera pas docker.

Packager.io ne prend en charge que ses versions, à côté du fait que l'empaquetage golang peut être fait beaucoup plus facilement qu'avec la surcharge de Packager.io.

Bon, je ne m'y connais pas assez en Go. Mais avoir une solution pour Ubuntu 16.04 serait formidable, car https://github.com/gogits/gogs/pull/3617 n'a pas été fusionné :(

Pour fournir des packages pour n'importe quelle version d'ubuntu/debian/n'importe quelle version, nous pouvons intégrer le même binaire dans le package et il suffit d'ajuster le script init (sysvinit, systemd).

Pouvons-nous fusionner le 16.04 packager.io PR et activer gitea dessus pour le moment ?

Binaire et docker sont nécessaires.

Pouvons-nous fusionner le 16.04 packager.io PR et activer gitea dessus pour le moment ?

Nous n'avons encore rien activé là-bas, mais puisque ce problème est estimé pour 1.0.0, je voudrais le présenter pour notre première version.

J'aimerais aussi des versions binaires - je n'ai pas de configuration d'environnement de développement pour compiler les choses.

Aussi, pourrai-je passer à gitea depuis gogs ? Je détesterais perdre mes problèmes, etc.

Nous aurons des versions binaires et, espérons-le, également des packages pour les principales distributions Linux. Vous n'avez pas besoin de compiler quoi que ce soit.

Nous aurons également des binaires pour la dernière version principale.

Vous pourrez directement lancer gitea avec la base de données Gogs. Si nous avons des modifications de la base de données, elles sont automatiquement migrées.

Oh ça a l'air génial ! J'ai hâte alors ☺

-- Starbeamrainbowlabs (keybase.io/sbrl)

https://packagecloud.io (OSS — 25 Go de stockage / 250 Go de bande passante + CDN bintray.com 1 To/m)

@tboerger https://packagecloud.io/docs#os_distro_version LTS et non-LTS deb/rpm/etc…
OS élémentaire / Raspbian / Ubuntu / Debian / SUSE Linux Enterprise Server / openSUSE / Fedora / LinuxMint / poky distro / Oracle Linux / Scientific Linux / Enterprise Linux (CentOS, RedHat, Amazon Linux)

@denji ouais je connais packagecloud, peut-être qu'on va le prendre, mais qu'on a besoin d'un plugin drone pour ça :)

Cela n'arrivera pas pour 1.0.0, donc je vais le déplacer vers 1.1.0.

Gogs fournit déjà des packages deb et rpm, donc ce serait vraiment dommage si cela ne se produisait pas pour 1.0.0.

Pourrai-je mettre à jour Gogs 0.9.99.0903 vers Gitea 1.1.0 sans problème ?

Gogs utilise un service qui ne prend en charge que ses versions et qui effectue un emballage binaire étrange. Nous voulons avoir une vraie solution.

Je pense que vous pourriez passer de Gogs 0.9.99.0903 à Gitea 1.1.0.

@tboerger qu'en est-il de faire quelque chose comme ça ? https://blog.codeship.com/using-docker-build-debian-packages/

@lunny Je suppose que @jhasse signifie une mise à niveau de apt-get upgrade

Une simple mise à niveau apt-get ne fonctionnera pas car nous aurons un nom de package différent. Mais je pense que cela fonctionnera pour faire apt-get remove gogs && apt-get install gitea :)

Ensuite, ils doivent copier le fichier app.ini de Gogs vers Gitea.

Ensuite, ils doivent copier le fichier app.ini de Gogs vers Gitea.

Ils doivent cependant le faire avant apt-get install gitea , sinon le service aurait déjà été démarré.

Les règles d'empaquetage de Debian @jhasse IIRC interdisent l'activation automatique des services lors de l'installation :wink:

Vous pouvez configurer ceci : http://askubuntu.com/questions/365911/why-the-services-do-not-start-at-installation

Et je pense que la valeur par défaut sur Ubuntu est de les activer automatiquement. Au moins, lorsque j'ai installé Gogs sur Ubuntu 14.04, je n'ai pas eu besoin de le faire manuellement.

Il est vrai que packager.io effectue un emballage binaire, mais il est nécessaire pour gogs/gitea. Plusieurs variables d'environnement doivent être configurées, etc. J'ai trouvé le RPM CentOS 6 gogs très simple à installer et à configurer.
Quelle que soit la solution d'emballage que vous choisissez pour gitea, assurez-vous qu'elle est facile à installer, à configurer et à mettre à niveau.

De nombreux packages reposent sur des variables d'environnement, mais il n'est toujours pas nécessaire d'encapsuler le binaire. Et la facilité d'installation et de configuration est-elle toujours au centre d'un package ou non ?

Donc j'ai en fait gitea emballé dans un .deb . Je n'autorise rien sur mon serveur qui ne soit pas emballé correctement. C'est un peu un patchwork pour le moment (en partie à cause de ce #480).

Au sujet du chemin de mise à niveau... Les packages .deb permettent à certains fichiers d'être déclarés comme fichiers "config" que le gestionnaire de packages :

• Conserver après la désinstallation du package jusqu'à ce que l'utilisateur "purge" explicitement le package
• Vérifiez les modifications avant d'écraser avec une mise à niveau. Il demandera à l'utilisateur quoi faire si la configuration a changé.

Cela permet au .deb d'inclure un fichier par défaut app.ini contenant un ensemble de valeurs par défaut différentes des valeurs par défaut de base de gitea (par exemple : les chemins de fichiers mentionnés au #480).

Il existe également un mécanisme pour rendre obsolètes d'autres packages (tels que gogs) mais cela peut être moins utile si gogs a été installé sans .deb

Pour toute personne intéressée à jeter un coup d'œil sur mon code de configuration, c'est ici : https://github.com/couling/gitea/tree/dpkg-config/scripts/dpkg

Je construis le paquet (basé sur le fichier manifeste dans ma config ) en utilisant un ancien script que je n'ai pas encore lancé en open-source mais je peux le faire bientôt si cela aide.

Les règles d'empaquetage de Debian @jhasse IIRC interdisent l'activation automatique des services lors de l'installation 😉

C'est intéressant. Chaque package de serveur (y compris des éléments tels que apache2) a démarré le service lors de l'installation.

@couling pourriez-vous envoyer un PR?

@tboerger une mise à jour ?

Aucune mise à jour pour l'instant de ma part. À mon humble avis, nous devons exécuter différents conteneurs Docker pour nous assurer qu'ils correspondent correctement au système d'exploitation cible (en référence au problème glibc). À côté de cela, un workflow docker exclut les systèmes 32 bits et les autres architectures car nous ne pouvons pas encore le prendre en charge avec notre buildchain.

Passons donc à la v1.2 ?

Je ne sais pas si cela est utile. Mais j'ai une bibliothèque/outil Golang expérimentale pour créer des packages Debian sans utiliser du tout debian (juste golang natif). J'ai également eu quelques "problèmes" lors de la création de packages pour Debian de manière "multiplateforme" et je ne suis pas un grand fan de dpkg builder. Jetez un œil : https://github.com/xor-gate/debpkg

Il est encore au stade expérimental, mais il est capable de générer des packages installables.

@xor-gate merci, j'y jetterai un coup d'œil quand je reviendrai sur ce problème.

J'allais essayer d'empaqueter Gitea pour Debian, mais je vois que quelqu'un d'autre m'a devancé - voir Debian Bug 79210 .

@mjturner Cela a été un projet de cinq mois pour moi jusqu'à présent et à mon rythme actuel, au moins beaucoup plus longtemps. Le gros du travail n'est pas trop mal, mais je suis coincé dans quelques endroits clés qui détruisent absolument ma capacité à progresser.

J'ai le plus besoin d'aide pour écrire des descriptions de paquets pour toutes les dépendances de gitea qui ne sont pas actuellement empaquetées dans Debian. Cela a pris au moins 80% de mon temps car mes compétences en Golang sont faibles et beaucoup de ces dép. ont peu ou pas de description de ce qu'ils font. Je me suis aussi battu avec d'autres trucs de Debian-Build.

Si vous, ou quelqu'un d'autre voulant 1. installer debian 2. apt-get install gitea, voulez me donner un coup de main, n'hésitez pas à me contacter sur IRC ! MTecknologie @ Freenode/OFTC

@MTecknology Vous m'avez devancé - j'allais vous envoyer un e-mail et voir si je pouvais vous aider de quelque manière que ce soit. J'ai une bonne expérience de l'empaquetage Debian (je suis un développeur émérite), bien qu'aucune avec l'empaquetage d'applications Go, et une bonne expérience du développement Go. Je vous contacterai via IRC sous peu

@mjturner Je semble vous avoir effrayé ! Si vous êtes toujours intéressé, je suis à un endroit où cela devient un peu écrasant et j'aurais vraiment besoin d'un coup de main.
ou .. quelqu'un d'autre? Y a-t-il quelqu'un qui comprenne l'empaquetage Debian et/ou Go ? Jolie s'il te plait?... :cry:

Salut les gars, l'empaquetage de Debian n'est pas très intuitif car il est très très flexible. La plupart des gens veulent juste quelques fichiers dans un .deb et quelques méta (paquets, version, description). Je pense que le moyen le plus rapide consiste à utiliser des outils frontaux pour créer un paquet Debian simple. Par exemple https://github.com/laher/goxc ou https://github.com/jordansisl/fpm.

Les gars de Syncthing (projet golang) utilisent FPM pour construire un paquet debian dans leur script build.go :
https://github.com/syncthing/syncthing/blob/2579e8f7152c3205691f3798a81d43c1af4e8af6/build.go#L531 -L539

Certaines personnes ont déjà fait des efforts dans le système de construction de Debian Make pour avoir un dh-make-golang (debian helper make for golang), voir https://github.com/Debian/dh-make-golang.

Il a besoin d'un peu d'amour pour empaqueter pour Debian, mais cela en vaut la peine.

Excuses @MTecknology ! Je n'ai définitivement pas eu peur, j'ai juste été tellement submergé par une tonne d'autres choses que je n'ai pas eu l'occasion de jeter un autre coup d'œil à Gitea depuis notre dernier contact il y a quelques semaines :(

Mon temps est encore assez limité pour le moment, mais j'ai toujours très envie de m'impliquer.

Pas de soucis. Ce projet est plus que ce que toute personne raisonnable, saine d'esprit ou bien ajustée devrait tenter de réaliser. En ce moment, je pense que je suis confronté à des incompatibilités de version où la construction réussit mais les résultats d'exécution sont une erreur de segmentation. Au moins, c'est enfin une version conforme à la politique.

Il s'avère que j'ai besoin de quelques bibliothèques javascript supplémentaires emballées. Plus... woohoo..... :sanglot:

@MTecknology Avez -vous la possibilité de partager vos packages WIP actuels (par exemple via un référentiel public) ? Cela pourrait aider à encourager les autres à s'impliquer.

@mjturner heheh ... vous avez en fait posté un lien vers l'endroit où j'ai posté un lien vers mon WIP (le bogue de Debian)
--> https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress

Il n'y a pas eu de changement significatif depuis mon dernier commentaire sur ce fil. J'ai réussi à obtenir une version réelle, mais elle segfaults. J'ai une intuition assez solide que les erreurs de segmentation étaient dues à des versions de bibliothèque incompatibles. J'ai la plupart (~ 90) des nouveaux développements de construction inclus dans unstable, mais je dois attendre après le gel avant de pouvoir envisager de mettre à jour quoi que ce soit. (trooooon)

Pour le moment, j'ai le plus besoin d'aide avec les packages/dépendances javascript.

Cela va être retardé par le #1484, entre autres, mais Debian 9 est sortie et je prévois de recommencer à faire des progrès dans un futur proche. Il y a encore beaucoup à faire, mais je fermerai cette ventouse un jour !

bonjour, quelqu'un a-t-il réussi à créer des rpm dans fedora/centos/rhel ?

@tboerger - J'aime vraiment ce que vous et votre équipe faites avec Gitea ! Pour répondre aux préoccupations des gens concernant le fait que Gitea n'a pas encore de RPM, j'ai écrit un outil pour générer Gitea RPMS pour les dérivés Red Hat 6.x et 7.x. Je le teste localement depuis un moment maintenant et je suis vraiment sur le point de le publier dans un jour ou deux.

Vous ne savez pas si vous recherchez une solution GO pour créer des RPM ou si vous voulez simplement un processus qui crée des RPM. Mon outil (même s'il est principalement écrit en python) générera des RPMS conformes aux normes d'emballage de Redhat.

Je ne sais pas si vous êtes prêt à utiliser un tel outil, mais je prévois de mettre mon gitub public dans un jour ou deux.

Nous sommes toujours ouverts aux relations publiques, même si elles ne sont pas fusionnées, cela pourrait être utile à d'autres. Vous pouvez utiliser le dossier contrib pour stocker votre script. Dans l'ensemble, nous essayons de le garder pour golang mais pour des cas spécifiques, nous faisons une exception et python est un outil commun.

@codylane hâte d'y être ! Je travaillais à le faire en utilisant la méthode d'emballage Fedora, mais je sais à peine comment faire cela et j'allais être un coup dans le noir.

Juste sur, heureux d'entendre que cela pourrait être utile pour les gens. Je suis en train de terminer le readme mais je devrais l'avoir sur mon compte github public ce soir. Je partagerai le lien dès qu'il sera disponible.

Je serais heureux de soumettre une demande d'extraction à gitea, je me suis juste dit que la communauté pourrait m'aider à m'assurer que cela fonctionne avant qu'il n'entre dans votre dépôt. J'ai beaucoup de tests d'intégration autour du RPM, mais la meilleure façon de s'assurer que cela fonctionne est de se présenter devant les gens. :)

Merci encore d'avoir créé un outil open source aussi génial !

Peut-être que cela peut aussi être un travail de fond pour un plugin de drone, déjà parlé à un autre développeur qui a créé un plugin deb pour drone.

Cool. J'ai aussi besoin de vérifier le drone et il fait partie de ma liste de choses avec lesquelles jouer.

Comme promis, voici un processus CI automatisé pour construire le RPM Gitea pour CentOS 6 et 7. https://github.com/codylane/gitea-rpm.

S'il vous plaît laissez-moi savoir si vous avez des questions ou des préoccupations ou s'il y a des problèmes. J'ai déjà ouvert un petit problème avec systemd. Je le réparerai demain.

Avez-vous pensé à utiliser Copr ?

Peut-être qui peut envoyer un PR pour changer le fichier drone pour générer deb ? @tboerger @bkcsoft @appleboy

@jhasse que nous pouvons également utiliser le service de construction ouvert. Je ne crois pas que ces outils soient la meilleure sélection.

Je préférerais un plugin drone pour rpm et pour deb et héberger les dépôts par nous-mêmes ou sur bintray/packagecloud

@tboerger - Juste curieux, voudriez-vous que je m'attaque aux drones ? La raison pour laquelle je pose la question est que je pensais connecter mon repo à TravisCI. Je comprends tout à fait si vous préférez un service de construction autonome. :)

Si vous souhaitez que je me penche sur le drone, pourriez-vous partager de la documentation sur la façon dont votre équipe l'utilise ? Je suis grand sur les normes et je n'aime pas recréer la roue si je n'en ai pas aussi.

Actuellement, nous utilisons principalement des plugins créés par des contributeurs de drones de l'org github drone-plugins, @thomasf a commencé à construire drone-deb pour l'empaquetage basé sur Debian et j'aimerais démarrer un plugin drone-rpm dans l'org drone-plugins.

Vous pouvez voir notre .drone.yml dans la racine du projet, nous hébergeons notre instance de drone sur drone.gitea.io

Cool. Une fois que j'aurai résolu ce problème systemd, je jetterai un coup d'œil comme vous l'avez recommandé. Merci mec!

FYI - Le problème systemd a été résolu et les RPM devraient être en bon état de fonctionnement. Encore besoin de se pencher sur les trucs de drone.

Il suffit d'ajouter une autre idée pour fournir un moyen simple d'installation via un "paquet" sous Linux : http://linuxbrew.sh.

Salut, des nouvelles sur les paquets deb ? J'aimerais vraiment avoir un paquet gitea deb ;)
En fait j'en aurais besoin pour Ubuntu 16.04 et Ubuntu 18.04, juste pour être plus précis...

Je suis également disposé à créer le paquet debian et à le rendre disponible si cette étape n'a pas été effectuée auparavant, faites-le moi savoir ;)

Ce problème a été automatiquement marqué comme obsolète, car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu au cours des 2 prochaines semaines. Merci pour vos contributions.

Merci stalebot pour votre contribution.

Je fais toujours la promotion de mon package github.com/xor-gate/debpkg go pour l'empaquetage Debian 🎉 .

@xor-gate pourriez-vous envoyer un PR pour ajouter un fichier de configuration pour votre bibliothèque sur contrib ? Peut-être que nous pourrions le publier sur un plugin de drone.

Ce problème a été automatiquement marqué comme obsolète, car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu au cours des 2 prochaines semaines. Merci pour vos contributions.

Veuillez considérer comme une demande pour cela...

Seulement obsolète à cause de l'absence de solution.

Je ne pense pas qu'une seule personne ait assez d'énergie pour garder Gitea emballé pour
Debian main, il y a tout simplement trop de dépendances avec le golang typique
problèmes écosystémiques [1]. J'ai passé plus d'un an à > 30 h/semaine à essayer d'y arriver
se produire; quand j'ai abandonné, il a fallu moins de trois mois pour les libs que j'ai
poussé dans Debian pour être extrait de l'archive en raison de changements de rupture dans
dépendances.

Je pourrais aider quelqu'un à maintenir cela pour non-free (ou principal si un masochiste
l'équipe se présente), mais il faudrait qu'elle s'accompagne d'un avertissement concernant le manque
de stabilité, pour de nombreuses raisons.

[1]

• Certaines bibliothèques sont mortes, avec des bogues de sécurité contre elles
• De nombreuses bibliothèques ont été forkées avec un niveau de maintenance variable (principalement
  patcher et oublier)
• De nouvelles bibliothèques sont arbitrairement ajoutées, souvent avec peu ou pas de révision
• 'aller vendeur' (curl | sudo -)
• Les > 200 golang deps fournissent rarement des versions (en s'attendant à ce que les applications soient toujours
  tirez le dernier git, y compris les bibliothèques deps supplémentaires ajoutées)

En outre-

• Il semble n'y avoir aucune méthode pour coordonner les mises à jour de sécurité (avec le
  l'état d'esprit selon lequel la mise à jour vous protège... elle fait le contraire)
• Les > 200 bibliothèques golang pâlissent par rapport aux > 2 000 bibliothèques js
• Il y a un terrible manque d'intérêt quant à ce qui peut légalement être inclus dans
  logiciels open source
• Les efforts pour résoudre ces problèmes se sont heurtés à une résistance importante

Bien qu'il soit possible d'empaqueter gitea pour les distributions qui ne s'en soucient pas
ces problèmes de licence et de compatibilité, j'ai abandonné quand je m'en suis rendu compte
ne peut jamais survivre dans Debian Main sans une équipe de masochistes avec tout un
beaucoup de temps disponible, pour plus que la simple version initiale.

Encore une fois, je suis heureux d'aider toute personne intéressée, mais je suis personnellement passé à
produire un "clone" plus minimaliste qui supprime ces problèmes. (Ralentir
partir à cause du peu de temps disponible)
... Si quelqu'un est intéressé par mon projet ou travaille sur gitea pour
Debian, contactez MTecknology sur Freenode.

>

@MTecknology il y a un PR pour résoudre ce problème. voir https://github.com/go-gitea/gitea/pull/6671 .

Cela ne résout aucun des problèmes que j'ai mentionnés, cela les introduit simplement dans un paquet pratique qui n'est toujours pas adapté à l'archive Debian.

Et qu'en est-il de fournir un ppa (que nous hébergerions) pour fournir des paquets Debian construits automatiquement ?

J'aurais pensé que les bibliothèques JS seraient regroupées avec gitea lui-même - j'ai toujours évité les versions des bibliothèques dites javascript disponibles via apt, car vous ne pouvez pas garantir de quelle version il s'agit.

En ce qui concerne les bibliothèques go, je pensais que Gitea ne publiait qu'un seul binaire ? C'est ce que j'utilise, du moins. Un simple référentiel apt ne pourrait-il pas être créé avec un package contenant ce seul binaire ?

Avis de non-responsabilité : je ne suis _pas_ un responsable de Debian et j'ai une expérience plutôt limitée de l'empaquetage d'éléments dans des fichiers .deb. Mon expérience va jusqu'à fpm

@MTecknology Vous avez fait énormément de travail, mais malheureusement, j'ai l'impression que cela n'a pas nécessairement de sens de packager gitea pour debian. Il n'y a pas d'objectif dans le projet de prendre en charge les anciennes versions avec des correctifs de sécurité ou de bogues qui correspondraient aux cycles de publication de Debian. Et comme vous l'avez mentionné, le nombre de dépendances est ingérable. Le proverbe go "Un peu de copie vaut mieux qu'un peu de dépendance." a été ignoré. Mais c'est tout à fait compréhensible également, car il s'agit d'un effort bénévole avec peu de ressources pour des choses comme la mise à jour des dépendances ou la refactorisation du code copié pour n'inclure que les éléments nécessaires, puis rétroporter les correctifs. Et le monde des dépendances JS/NPM est encore pire. Je pense qu'un logiciel comme gitea est mieux proposé sous forme d'images docker qui fonctionnent sur plusieurs distributions Linux. Espérons que les images docker soient verrouillées, car le code présente toujours les problèmes de dépendances et de correctifs de sécurité que vous avez mentionnés.

Fournissez un référentiel yum et la source apt en sera une autre avec un script shell d'installation sera un autre choix.

Bien sûr, ce serait cool d'avoir gitea dans les dépôts officiels de Debian ou d'ubuntu, mais comme déjà indiqué ci-dessus, cela entraîne beaucoup de travail.

Pour éviter un tel cauchemar d'emballage, nous pourrions simplement créer des packages deb et rpm qui sont fournis via bintray ou même via un dossier sur le miroir de téléchargement qui est soutenu par le cloudflare cdn.

Les packages eux-mêmes pourraient être construits via fpm, ou quelqu'un contribuerait un plugin de drone qui pourrait même atterrir dans l'org drone-plugins s'il est écrit en go et a des standards. Il existe même une bibliothèque go qui a implémenté de nombreuses fonctionnalités fpm.

En termes d'emballage formel pour les distributions, même si cela pourrait et devrait probablement être un objectif à long terme, je ne pense pas que nous devrions nécessairement le faire à l'heure actuelle. Notre base de code continue d'évoluer rapidement et je pense qu'à l'heure actuelle, nous ne pouvons pas nous engager à maintenir les très anciennes versions qui finiraient par être formellement empaquetées avec ces distributions.

Je suis également préoccupé par le nombre de dépendances externes que nous avons - nous devrions certainement nous demander si nous en avons besoin en tant que dépendances matérielles (par exemple, magnifique, boltdb) et si certaines de nos plus petites dépendances pourraient bénéficier d'être bifurquées ou réécrites. (La session Macaron et le go-ini sont tous deux problématiques à mon humble avis.)

Nous devons également refactoriser notre structure interne pour faire des plugins Go une réalité. Je pense que cela nous permettrait de créer un core-gitea plus léger qui pourrait être empaqueté sans introduire toutes les autres dépendances.

Emballer correctement les projets Go est sur toute distribution un PITA. C'est pourquoi nous devrions simplement construire le binaire et fournir des packages simples qui ignorent les meilleures pratiques des distributions pour packager chaque dépendance dans un package séparé.

En tant que mainteneur de Debian, ce serait très bien d'avoir gitea dans Debian en tant que paquet lui-même. Mais il y a des problèmes techniques (et peut-être de licence), donc cela sort du cadre de ce problème.

En tant qu'utilisateur Debian, ce serait cool d'expédier gitea via le paquet deb. Comme nous avons déjà un binaire go statique, il peut être livré dedans. L'avancée de ceci est que nous pouvons également inclure une infrastructure appropriée comme les fichiers unitaires pour le démarrer au démarrage du système et peut-être une configuration par défaut saine si nécessaire.
Pour la plupart des utilisateurs, cela signifie ajouter une source de package, ajouter une clé de signature et simplement installer le package. Les mises à jour sont déployées d'une manière que les utilisateurs connaissent déjà.

RPM CentOS : https://cbs.centos.org/koji/buildinfo?buildID=25894

Ce serait formidable d'avoir un rpm dans un référentiel dnf/yum fréquemment mis à jour afin que les utilisateurs de la distribution rpm puissent facilement se tenir au courant des mises à jour de sécurité, etc. de gitea.

@waja Toute modification de votre package CentOS est-elle mise à jour pour Fedora et éventuellement ajoutée à EPEL s'il est testé et stable ?

des nouvelles à ce sujet? Il y a un mois, @techknowlogick dans # 6671 a déclaré que Drone pourrait être utilisé pour des builds automatisés de rpms et debs. Quelqu'un a-t-il réussi à trouver un moment pour l'activer ? Si oui, pourriez-vous mettre à jour la documentation ?

@Janhouse J'ai essayé de l'emballer pour Fedora mais Go est pénible à emballer correctement. La version CentOS liée ci-dessus n'a pas été correctement construite pour moi et j'ai remarqué quelques changements qui devaient être apportés avec elle.

Je suis toujours intéressé par les versions officielles appropriées, car cela garantit une meilleure maintenance des packages.

@waja ne sait pas comment mettre un projet dans le dépôt officiel debain mais alpine-linux a déjà un paquet de travail : source

Nous n'intégrerons pas gitea dans les dépôts officiels de Debian, c'est un énorme effort qui a déjà échoué dans le passé.

À quel point un ppa est-il difficile à entretenir ?

Pas particulièrement difficile, @6543. En fait, j'ai mon propre référentiel apt ici : https://apt.starbeamrainbowlabs.com/

Le code que j'utilise pour le gérer se trouve ici : https://git.starbeamrainbowlabs.com/sbrl/aptosaurus

Si quelqu'un a un script Bash qui télécharge automatiquement les fichiers de version de GitHub, vérifie les hachages SHA256 et les emballe avec fpm , je serais heureux de l'exécuter moi-même (bien que je ne sois pas sûr de pouvoir héberger versions précédentes du package ; Gitea est assez grand et l'espace de stockage s'additionne rapidement).

La construction du package doit être effectuée par drone, et ensuite il doit être simplement téléchargé sur le bac à fichiers ;)

@tboerger Je vais essayer de faire un brouillon de PR avec le script de construction deb ...
& nous avons dl.gitea.io vaut-il la peine de télécharger le deb là aussi (et peut-être comme pièce jointe à la sortie)

Personnellement, je n'aimerais pas gérer moi-même les repos deb et rpm, c'est pourquoi Bintray serait idéal pour cela. Le simple téléchargement d'un fichier deb ou rpm sans aucun référentiel est à mon humble avis assez inutile.

Le simple téléchargement d'un fichier deb ou rpm sans aucun référentiel est à mon humble avis assez inutile.

c'est complètement nul !

Nous pourrions également utiliser nfpm pour créer des fichiers deb et rpm

Quelqu'un a déjà commencé il y a quelque temps à construire un plugin fpm de drone... Je veux toujours en construire un dans l'org plugins basé sur le fork go fpm.

Voici un plugin de drone que j'ai créé pour nfpm : https://github.com/techknowlogick/drone-nfpm

Si vous créez des packages pour les systèmes FHS, n'oubliez pas d'utiliser le script d'observation dans contrib ou de construire avec le LDFLAGS défini correctement.

Salut à tous, j'ai mon propre référentiel de packages APT, je peux y ajouter gitea.
Voir le projet déjà inclus : https://packages.azlux.fr/
Maintenant qu'il est en cours d'exécution, il est facile d'ajouter n'importe quel .deb que vous voulez (je peux même le créer)

Azlux

@azlux tout se résume à la confiance. Vous êtes probablement un gars cool, mais je préférerais l'installer à partir d'un service d'automatisation connu où les scripts de construction sont maintenus par l'équipe de développement de gitea, plutôt que de l'obtenir à partir d'un dépôt privé. J'ai également construit mes propres packages, mais idéalement, ils seraient gérés par l'équipe gitea.

Accrocher
Merci pour l'info @Janhouse
J'ai configuré mon référentiel avec reprepro, je peux vous aider si vous en avez besoin.

Az

@Janhouse Après une réflexion plus approfondie, Le repo apt nous permet de vérifier que les sources n'ont pas été modifiées entre-temps. Idéalement, il est préférable que gitea maintienne son propre dépôt, mais ils peuvent également mettre d'autres dépôts en tant que "dépôt non officiel".
Beaucoup de projets n'ont pas de problème avec ça. Comme ça, a averti People.

Je sais que je l'ai déjà dit mais...

Si vous fournissez des packages Deb, vous devriez probablement construire Gitea afin qu'il obéisse au FHS en définissant le LDFLAGS comme décrit ici :

https://docs.gitea.io/en-us/install-from-source/#changing -the-default-custompath-customconf-and-appworkpath

Idem ici - j'ai un repo apt personnel dans lequel je peux héberger

J'aimerais aussi voir gitea suivre le FHS @zeripath , c'est idiot, ils ont besoin d'un script shell wrapper pour le faire aussi.

Des news sur les RPM en attendant ? Je vois beaucoup de discussions sur les DEB, mais de nombreuses entreprises utiliseront CentOS qui n'utilise pas de packages DEB. Les BSD semblent avoir leurs propres packages (avec des correctifs) mais leurs processus sont un peu différents.

@evitalis vous n'avez pas besoin d'un script si vous le construisez avec le LDFLAGS approprié.

Je sais, je faisais référence à leur besoin d'avoir même ceci .

Juste en y pensant. Le chemin FHS devrait être par défaut pour la v2 car il s'agirait d'un changement de rupture nécessaire.

Je pense que nous devons décomposer un peu cela. Il existe actuellement quatre types de build :

• builds de développement - vous téléchargez la source et vous construisez avec make
• constructions personnelles - vous téléchargez la source et vous construisez avec make mais vous voulez que ce soit un serveur en cours d'exécution
• release builds - nous construisons avec make release et restons sur gitea.io et GH
• docker construit

FHS par défaut a du sens pour jusqu'à 2 d'entre eux : version et éventuellement personnel - mais à l'heure actuelle, vous ne pouvez pas dire si une version personnelle est une version de développement ou vice versa. Briser les builds de développement serait une très très mauvaise idée.

Le Docker devrait également avoir ses valeurs par défaut intégrées - il est absurde d'avoir à exiger "-c" par défaut sur une construction de docker que nous construisons nous-mêmes.

Il y a une possibilité de changer où nous regardons par défaut en fonction de l'endroit où le binaire est placé - mais je soupçonne que cela pourrait être une mauvaise idée. Je suppose que je devrais vérifier à nouveau quelle est la pratique normale pour cela. (hiérarchies des recherches de configuration ? - ugh complexe)

Lorsque j'ai fait fonctionner l'option LDFLAGS pour la première fois, j'ai proposé :

• Créer une version distincte avec des chemins FHS intégrés
• Faites en sorte que le menu fixe ait les chemins par défaut pour le menu fixe intégré - ce qui résout quelques autres problèmes étranges liés à l'exécution de gitea sur la ligne de commande du menu fixe.
• Ajouter/exposer un point de terminaison make pour les builds FHS qui définit correctement les drapeaux <- Les constructeurs de packages devraient utiliser ceci...

Ce sont des modifications sans rupture qui ne nécessiteraient pas nécessairement d'attendre la version 2.0 - nous ajoutons simplement une nouvelle option de téléchargement.

Une alternative consiste à ajouter un script de configuration et à créer des points de terminaison d'installation - car cela aurait alors l'air "normal" pour les personnes habituées à :

# get source by whatever means necessary
cd gitea
./configure
make
sudo make install

Il est tout à fait normal de rechercher des configurations dans des chemins prédéfinis si vous ne fournissez pas d'indicateur pour un chemin personnalisé. C'est par exemple déjà une partie de https://github.com/spf13/viper pour définir plusieurs chemins standard. Le comportement foutu actuel de Gitea est totalement inhabituel.

Peut-être que cela vaudrait la peine de mettre d'abord les versions de version dans les dépôts, ce serait une bonne première étape ?

@sbrl déjà fait sur mon repo , le script de build est stocké ici : https://github.com/azlux/dpkg-deb
Comme vous l'avez dit, il utilise directement la version de version.

@zeripath Je pense que vous rendez cela plus compliqué que nécessaire sur la base de votre réponse, mais je l'interprète peut-être mal. Si les gens utilisent git clone et construisent eux-mêmes des choses, ils doivent savoir que des problèmes peuvent survenir. Pour de nombreux projets, faire ladite construction à partir de la branche master ou utiliser une version est considéré comme stable, tout le reste ne l'est pas et peut casser à tout moment.

Même dans Docker, il n'y a aucune raison de ne pas suivre le FHS, donc ce cas disparaît également. Pour le reste, comme l'a noté @tboerger, la vérification d'un ensemble standard de chemins pour une configuration est considérée comme normale. S'appuyer uniquement sur $PWD ou sur des drapeaux de compilation aléatoires que la plupart des utilisateurs ne verront jamais cause plus de problèmes, y compris avec l'empaquetage du système d'exploitation. En tant que quelqu'un qui a empaqueté plus que quelques choses, moins l'application est standard, plus il y a de travail pour moi et plus je devrai introduire de correctifs.

Cela dit, je suis toujours intéressé à voir au moins les RPM officiels. Je n'utilise pas Debian ou Ubuntu mais je suis sûr qu'un DEB officiel serait également le bienvenu. Merci à tout le monde dans ce fil qui fait de son mieux sur l'emballage dans l'intervalle.