dosbox-staging 🚀 - Rendre les versions disponibles via Ubuntu PPA | bleepcoder.com (2024)

En tant qu'utilisateur d'Ubuntu (mint), je ne peux pas être plus d'accord :-)

Vous voulez probablement des canaux -stable / -release vs -latest / -nightly aussi.

_ (Il y a quelques mois, j'ai tenté de créer un PPA en utilisant une poignée de tutoriels et de tutoriels. J'ai finalement jeté l'éponge après que la frustration ait eu raison de moi ... et j'ai l'impression que le tout est chargé d'étapes inutiles ou délibérément compliquées ;: tête_explosion:) ._

En espérant que quelqu'un avec une expérience en emballage PPA puisse offrir un coup de main, à n'importe quel titre. Conseils utiles, aide au type de questions-réponses, configuration de votre propre PPA de préparation comme preuve de concept ou empaquetage direct des binaires à partir des pages de publication et de CI - toute aide est une bonne aide.

@dreamer et moi avons tous deux signé des comptes de tableau de bord, nous pouvons donc les utiliser le moment venu.

Je ne sais pas pour PPA, mais j'ai lancé un POC apt-repo

https://github.com/FeignInt/dosbox-staging-apt-repo-POC

Très récemment, j'ai ajouté à debian / rules (make file) pour assouplir les dépendances, j'ai parlé des numéros de version dans le wiki (lié dans le README.md)

J'espère que deb fonctionnera sur n'importe quelle distribution avec une ressemblance passagère avec Debian

Je ne l'ai pas testé sur autre chose que Debian SId, je serais intéressé de savoir jusqu'où les goûts de Mint vont.

Remarque: dans le README.md j'ai inclus une ligne deb-src
C'est facultatif
mais pour les coups de pied

apt -s source dosbox-staging

-s est simulé, il ne téléchargera rien.

J'espère que cela aide à emballer les debs

Jusqu'ici tout va bien!

Ajout de la clé et du dépôt, puis mis à jour

Get:1 https://raw.githubusercontent.com/feignint/dosbox-staging-apt-repo-POC/master/generic unstable InRelease [2,336 B]Hit:2 http://packages.microsoft.com/repos/vscode stable InRelease Hit:3 http://mirrors.edge.kernel.org/ubuntu focal InRelease Get:4 http://mirrors.edge.kernel.org/ubuntu focal-updates InRelease [107 kB]Get:5 http://mirrors.edge.kernel.org/ubuntu focal-security InRelease [107 kB] Get:6 http://mirrors.edge.kernel.org/ubuntu focal-backports InRelease [98.3 kB] Get:7 https://raw.githubusercontent.com/feignint/dosbox-staging-apt-repo-POC/master/generic unstable/otherosfs Sources [744 B] Hit:8 http://archive.canonical.com/ubuntu focal InRelease Get:9 https://raw.githubusercontent.com/feignint/dosbox-staging-apt-repo-POC/master/generic unstable/otherosfs amd64 Packages [1,425 B] ...

apt show dosbox-staging

Package: dosbox-stagingVersion: 0.75.1-2Priority: optionalSection: otherosfsMaintainer: Feignint <[emailprotected]>Installed-Size: 3,257 kBDepends: libasound2, libc6, libgcc-s1, libgl1, libopusfile0, libpng16-16, libsdl2-2.0-0, libsdl2-net-2.0-0, libstdc++6, zlib1gConflicts: dosboxHomepage: https://dosbox-staging.github.io/about/Distribution: unstableDownload-Size: 1,023 kBAPT-Sources: https://raw.githubusercontent.com/feignint/dosbox-staging-apt-repo-POC/master/generic unstable/otherosfs amd64 PackagesDescription: x86 emulator for DOS-era video games dosbox-staging is an attempt to revitalize DOSBox's development process. It's not a rewrite, but a continuation and improvement on the existing DOSBox codebase while leveraging modern development tools and practices. . Yes I did copypasta that from the about page

Installez et exécutez!

Pour obtenir les packages .deb , s'agit-il d'une série d'étapes de compilation et de packaging que vous avez exécutées manuellement (ou scriptées) de votre côté?

Ou y a-t-il un script deb-creator qui digère le contenu de conf , db et dists/unstable et crache les fichiers deb?

curl https://raw.githubusercontent.com/feignint/dosbox-staging-apt-repo-POC/master/feignint.gpg | sudo apt-key add -sudo add-apt-repository -s 'deb https://raw.githubusercontent.com/feignint/dosbox-staging-apt-repo-POC/master/generic unstable otherosfs'

Et jusqu'à présent, ppa et dosbox fonctionnent bien.

le POC est en fait juste reprepro
le seul fichier que j'ai créé était generic / conf / distributions

Je l'ai ensuite alimenté avec le fichier .changes, et reprepro a rempli le reste
et je viens de l'héberger à cheappskate sur github: D

Je n'ai pas scénarisé la construction, mais c'est certainement possible
Prêt à l'emploi, des choses comme la finalisation d'une entrée de journal des modifications engendrent un éditeur,
si vous regardez

apt changelog dosbox-staging

vous devriez voir que je lie les notes de publication (j'ai fait preuve de créativité avec la 0.75.1)
pour le moment manuel, mais c'est quelque chose que je voudrais automatiser

La version réelle était, en utilisant
L'arbre debian / trouvé ici

une solution plutôt décousue
https://github.com/FeignInt/dosbox-staging-deb/wiki
quand je l'écrivais, je me rappelais surtout que je n'utilise pas git-buildpackage depuis longtemps

gbp buildpackage -sa \ --git-overlay \ --git-pbuilder \ --git-export-dir=../SomeBuildDir \ --git-export=<debian-tag>

L'arbre Debian vit sur sa propre branche, dans le même dépôt que dosbox-staging

checkout gbp
il traduit ensuite la version Debian trouvée dans le changelog en balise amont.
archive la balise amont et la balise debian
le bit pbuilder se construit dans un chroot, ce qui garantit une construction propre

git buildpackage n'a pas besoin d'être utilisé,
Déposez simplement le debian / tree dans dosbox-staging et en cours d'exécution

dpkg-buildpackage -b

suffit à le construire,
mais je pense que la fonction de superposition / exportation de gbp est plus propre

gbp a toutes sortes de hooks, c'est-à-dire qu'une compilation réussie peut déclencher un push / upload de fichier, etc.

En ce moment, je suis heureux que Mint soit satisfait d'un deb construit dans un chroot DebianSid

Je vais fouiller et voir comment les versions actuelles sont automatisées
laisser tomber --git-pbuilder va probablement être bien en supposant qu'une certaine saveur de debian construit déjà des choses

juste une note rapide sur le workflow gbp
La superposition git peut compliquer les choses

quelque chose comme ça serait plus simple

#!/bin/bashTAG=v0.75.0-rc1DEBTAG=${TAG:1}DEBTAG=${DEBTAG//-/\~} PostEdit="sed -i '3{s@UNRELEASED<strong i="8">@New</strong> upstream release:"PostEdit+="\n - https://dosbox-staging.github.io/"PostEdit+="'${TAG//[.]/-}'/@}' debian/changelog"gbp import-ref --upstream-tag=$TAG -u$DEBTAG || exitgbp dch -N ${DEBTAG}-1 \ -R \ --spawn-editor=never \ --postedit="$PostEdit" \ --commit -- debian/ || exitgbp tag || exitgbp buildpackage -sa \ --git-export-dir=../FooBuild \ --git-export=debfoo/${DEBTAG/\~/_}-1 || exit

c'est un script approximatif, juste pour faire une démonstration de l'automatisation
J'espère que ça a du sens

Edit: je dois noter que j'ai modifié debian / gbp.conf

debian-branch = debfoodebian-tag = debfoo/%(version)s

en testant ça

Je vais voir si je peux m'entraîner comment les crochets fonctionnent en gbp
Je pense que l'importation-ref peut démarrer une chaîne pour faire la plupart de ce que fait cet extrait de code, avec une restauration plus robuste si les choses ne se passent pas bien

Merci @FeignInt , c'est exactement l'aide dont nous avons besoin! Je dois parcourir toutes vos instructions en détail, afin de pouvoir poser des questions éclairées.

Mais en général, oui - autant de progrès que vous pouvez faire sur les scripts, ce serait parfait.

Voici le contexte général que nous pouvons supposer avec la chaîne CI actuelle:

1. Nous avons un nouveau clone du dépôt dosbox-staging, et nous sommes actuellement assis dans son répertoire racine (par exemple: /home/github-bot/dosbox-staging/ ).
2. Nous avons les outils de construction et les dépendances nécessaires pour compiler dosbox-staging (donc ./autogen.sh && ./configure && make fonctionnerait propre et produirait un binaire).
3. Supposons que nous puissions extraire le contenu $ VERSION, $ TAG et $ CHANGELOG dans des variables d'environnement, qui peuvent être utilisées par votre script (pour garantir que tout peut être automatisé).
4. Nous pouvons supposer que tous vos fichiers de configuration statiques de métadonnées Debian existeraient dans l'arborescence de répertoires dont ils ont besoin, juste à côté de la source, y compris une clé GPG.
5. Nous aurions alors apt-get install ... les outils spécifiques à Debian nécessaires pour générer le paquet .deb , et toutes les autres sorties nécessaires pour satisfaire le monde PPA / Debian. (les machines virtuelles buildbot GitHub démarrent toujours avec une table rase, nous devons donc installer deps à chaque fois).
6. Ensuite, nous lancerons votre nouveau script Debian-package-and PPA-creator , qui ferait ce que vous décrivez ci-dessus. Peut-être qu'il organiserait tout dans un sous-répertoire, disons ./debian-ppa/*
7. Nous trouverions alors comment pousser l'arborescence PPA vers une zone github ou gitlab, comme vous l'avez fait.

La grande aide sera dans 4 à 6; et vous avez probablement déjà tout exposé; et j'ai juste besoin de lire ce que vous avez fait!

Mon objectif paresseux idéal serait pour vous de fixer un montant de tar.gz et dire: « extraire ceci dans votre DOSBox-staging sources, puis exécuter le script ./scripts/deb-ppa-creator.sh , et l'arbre PPA est prêt à aller à l' intérieur ./debian-ppa/ (ou quelque chose comme ça.

ok, ça ne devrait pas être trop un problème
J'ai eu un bref jeu avec Ubuntu 18.04 via LXC

Les choses sont un peu différentes de Debian Sid, mais aucun showstoppers.

Je ne sais pas comment gérer la clé gpg
à partir de l'apparence des choses, il est possible d'ajouter la clé privée en tant que «secret» sur le dépôt, en ayant éventuellement le mot de passe pour la clé comme deuxième «secret». pour le moment, je vais sauter la signature et traverser ce pont plus tard.

Je suis tombé sur un cache persistant
Il met en garde contre le stockage d'informations sensibles, car elles pourraient devenir accessibles au public, ce que nous voulons en fait
Ce n'est probablement pas si pratique.

pour obtenir à la fois le nouveau journal des modifications et le repo apt mis à jour dans un état utilisable, cela semble prometteur
les actions créent une demande d'extraction

Je suis totalement dans le noir avec tout ce truc CI Actions
mais le croquis dans ma tête ressemble à quelque chose comme ça

1. tag déclenche une action CI
2. le script a passé la balise comme argument
3. script génère un nouveau journal des modifications, build && tags deb / version.
4. script ajoute à apt-repo
5. script ouvre PR pour la branche "debian" et le "apt-repo"
6. PR fusionnés comme avec tout autre PR

pour l'instant je vais me concentrer sur {2..4}, en essayant de le garder aussi simple que possible tout en n'étant pas si simple que cela risque d'échouer

cela fonctionne sur lxc bionic

pas de journalisation ou de messages d'erreur significatifs
et je n'ai pas encore fait tout mon possible pour le casser.
ne signe pas le bit de repo apt, il les archive simplement

Super progrès!

J'ai ajouté le script à .github/scripts/build-deb-pkgs.sh au-dessus de la branche principale (sans autres fichiers de votre dépôt) et l'ai lancé sur ma boîte Ubuntu 20.04.

bash -x ./.github/scripts/build-deb-pkgs.sh v0.75.0+ BaseDir=/home/kcgen+ debian_branch=debianish+ debian_worktree=/home/kcgen/debianish-worktree+ reprepro_branch=reprepro+ reprepro_base=/home/kcgen/reprepro-worktree+ buildarea=/home/kcgen/buildarea/+ debian_changelog=debian/changelog+ [[ 1 != 1 ]]+ case $1 in+ case $0 in+ [[ ! -d .git ]]+ build_deb_pkgs=/usr/src/dosbox-staging/./.github/scripts/build-deb-pkgs.sh+ dosbox_staging_git=/usr/src/dosbox-staging+ upstreamTAG=v0.75.0+ debVersion=v0.75.0-1+ debVersion=0.75.0-1+ debTAG=debianish/0.75.0-1+ cd /usr/src/dosbox-staging+ ListTag v0.75.0++ git tag --list v0.75.0+ [[ v0.75.0 == \v\0\.\7\5\.\0 ]]+ ListTag debianish/0.75.0-1++ git tag --list debianish/0.75.0-1+ [[ '' == \d\e\b\i\a\n\i\s\h\/\0\.\7\5\.\0\-\1 ]]+ init_worktree /home/kcgen/debianish-worktree debianish+ grep -q '\[debianish\]'++ git worktree list+ git worktree add /home/kcgen/debianish-worktree debianishfatal: invalid reference: debianish+ exit 1

Je sais que vous y travaillez toujours, alors fournissez simplement des commentaires en cours. Des tonnes de bonnes choses dans le script .. seront retestés quand vous le souhaitez.

cela échoue pour vous car vous n'avez pas la branche debianish

Je ne vais pas très loin pour le faire fonctionner sur github
Cela va jusqu'à append_changelog
le problème est que je n'ai pas compris comment en extraire un fichier journal, donc je ne sais pas pourquoi gbp dch échoue.
J'ai juste écrasé un yml ensemble basé sur le "quickstart" et l'archive tar de téléchargement du linux.yml.

Initialement, la configuration de l'arbre de travail a échoué, mais une extraction a semblé résoudre ce problème

• gbp semble être installé, je n'obtiens pas de sortie de "gbp config dch"
• la suppression du postedit ne l'a pas corrigé
• ni n'a pas validé le changelog

Je pense que je vais essayer de pousser un changelog prédéfini et voir si le buildpackage gbp fonctionne, puis recommencer avec une certaine expérience.

mais au moins je peux me débarrasser du bit de détection de chemin complet $ 0 que j'ai piraté, je peux localiser des choses en fonction de $ GITHUB_WORKSPACE
là encore, je pourrais simplement supprimer gbp caliing le script pour les hooks postbuild et simplement glober le fichier de modifications à reprepro

Eh bien, je pense que je l'ai construit

pousser un journal des modifications et désactiver le marquage semblait faire l'affaire
donc je suppose que c'est en lecture seule, je dois regarder ces "actions aux relations publiques"

Je suppose maintenant que je ne reçois pas de journaux en raison de la sortie du script aucun zéro, donc il n'atteint jamais le bit d'artefact

btw, si vous ajoutez la branche debianish, vous devrez supprimer les 0.75.Xs du debian / changelog et supprimer les balises debianish /

1. Cloné dosbox-staging
2. Création d'une succursale debianish , dans dosbox-staging .
3. Copie ./debian arborescence dosbox-staging/ , dans le cadre de la nouvelle branche debianish . J'ai donc maintenant votre arbre boulonné sur le repo: ./dosbox-staging/debian/
4. Copié votre script .github/scripts/build-deb-pkgs.sh également dans le même chemin à l'intérieur de dosbox-staging/

5. Lancé ./.github/scripts/build-deb-pkgs.sh v0.75.0

   • line 171: cd: ~/debianish-worktree: No such file or directory , donc j'ai créé ceci. Suggérez de créer ceci (ou d'utiliser mktemp -d pour garantir un nouveau répertoire propre).

6. Relancé

   • line 52: gbp: command not found , j'ai donc essayé sudo apt install gbp , mais le package n'est pas trouvé. J'ai regardé dans le script et trouvé une ligne apt get , donc installé tout cela en un seul coup. Tout est bien installé.
   1. Relancé
   
   
   • grep: debian/changelog: No such file or directory
   
   
   • gbp:error: ~/debianish-worktree is not a git repository
   
   

Je ne sais pas pourquoi git-buildpackage n'a pas été installé initialement
J'ai changé le saut si le test installé est tardif (mon original n'a pas échoué si la configuration résiduelle est présente)
le nouveau test est un peu spammé, je n'ai pas envoyé à / dev / null

en tous cas

git clone https://github.com/dosbox-staging/dosbox-staging.gitcd dosbox-staginggit remote add \ -f \ -t debianish \ -t build_deb_pkgs \ feignint https://github.com/feignint/dosbox-staging-deb.gitgit merge feignint/build_deb_pkgs --allow-unrelated-histories

suit deux branhces, debianish et build_deb_pkgs

J'ai des branches builddeb et de type debian, (que je supprimerai bientôt) que j'utilisais pour en savoir plus sur les workflows
J'ai fini par fusionner debianlike dans builddeb, pour écarter tout problème lié à l'utilisation d'un arbre de travail,
Je digresse...

puisque debianish a déjà des changelogs et debianish / TAGs pour 0.75.0 etc.
créez simplement un nouveau tag de test

git tag v0.76.0-testbash -x ./.github/scripts/build-deb-pkgs.sh v0.76.0-test

vous pouvez soit ajouter de nouvelles balises, soit un cd à l'arbre de travail debian et

git reset HEAD~1

et supprimer le (s) tag (s)

git tag -d debianish/v0.76.0-test# or# while read tag;do git tag -d "$tag";done < <(git tag -l "v*76*-test" )

et ouais, je peux utiliser mktemp pour configurer le répertoire de l'arbre de travail
Je devrais aussi nettoyer en utilisant

git worktree remove ${debian_worktree}

debian_worktree fonctionne dans l'arborescence des dépôts
edit: debian_worktree = / chemin / vers / ce / git-repo / debian

ça a l'air bizarre

dosbox-staging/└─debian/ └─debian/ ├─changelog └─rules

mais semble fonctionner (je ne sais pas si c'est git magic ou gbp excluant ./debian/ lors du tarage)

si vous voulez pousser les debs vers un repo
le $ {reprepro_base} doit pointer vers le répertoire contenant le repo git (ou un serveur web local comme apache ou lighttpd)
et éventuellement ajouter

SignWith: <gpg key id> 

aux conf / distributions
Je ne sais pas si le script attendra que passwd soit entré, je n'ai pas encore configuré de clé gpg sur le LXC
puis git add, commit, push

pointe:
J'ai récemment ajouté CFLAGS à debian / rules

revenir à 63e27285 pour un temps de construction réduit
vous devez également ajouter DEBUILD_PREPEND_PATH="/usr/lib/ccache" à ~/.devscripts pour faire fonctionner ccache

Edit2: woot j'ai enfin trouvé des journaux
lien vers le bit que j'ai lu pour savoir comment

edit3:
ahh, pourquoi n'y ai-je pas pensé plus tôt

2020-06-11T12:49:51.7081058Z + gbp dch --new-version=0.76.0~test1-1 --release --spawn-editor=never --commit -- debian/2020-06-11T12:49:52.3199292Z gbp:error: Error running git commit: *** Please tell me who you are.2020-06-11T12:49:52.3200167Z 2020-06-11T12:49:52.3204868Z Run2020-06-11T12:49:52.3205097Z 2020-06-11T12:49:52.3206024Z git config --global user.email "[emailprotected]"2020-06-11T12:49:52.3206535Z git config --global user.name "Your Name"2020-06-11T12:49:52.3206724Z 2020-06-11T12:49:52.3207111Z to set your account's default identity.2020-06-11T12:49:52.3207569Z Omit --global to set the identity only in this repository.

me donner des coups de pied

enfin, il a été construit, taré et téléchargé comme artefact

chemins idiots à cause de mon tar paresseux -cf, mais ce n'était pas ma préoccupation à l'époque.

maintenant que je connais le GIT_WORKSPACE, je peux configurer le script pour qu'il s'exécute différemment
Par exemple, quand vous n'êtes pas sur github, par défaut, --git-pbuilder, ou faites une forte indication et soyez plus prudent sur l'emplacement de buildarea

Des progrès impressionnants sur ce @FeignInt!

Curieux et excité de l'essayer (pas de précipitation; chaque fois que vous pensez que c'est prêt).
Au plaisir d'en apprendre davantage à ce sujet, puis de le plier dans la chaîne CI de préparation dosbox.

@kcgen J'y
semble qu'il y ait une bizarrerie avec les flux de travail, j'ai passé trop de temps à essayer de rendre un flux de travail "actif", j'ai finalement compris qu'il fallait push: branch:, qui peut ensuite être supprimé
pour le moment je l'ai juste en regardant les balises poussées.

La bonne nouvelle est que j'ai eu des actions push commits dans l'arborescence Debian et une branche sur un dépôt différent (fichiers reprepro qui servent à apt)

1. tag déclenche le workflow
2. yml checkout dosbox-staging (db-s) et apt-repo
3. le script crée / valide le journal des modifications sur la branche debian de la base de données
4. script compile, package debs et met à jour apt-repo
5. script valide les modifications sur db-s et apt-repo
6. yml télécharge les 10 fichiers pkg comme des artefacts # vraiment redondants

Comme j'y suis arrivé de manière itérative (dont beaucoup n'ont pas fonctionné), je dois écraser les commits et rebaser.

Je peux juste faire un (diff | patch); git add -p

Ensuite, je dois régler le problème de la signature.

Je vais probablement tout mettre dans le yml et retirer le script shell.

Je pense que j'ai réglé la plupart des choses maintenant

apt repo - détient les debs

Remarque: ce n'est plus "unstable otherosfs", c'est maintenant "bionic main", et la racine du sandbox au lieu du générique

L'arbre debian contient les fichiers d'emballage Debian

Pas la branche par défaut "debianish"

copie de release / 0.75.x, avec des scripts en

En gros, j'ai supprimé le .github / actuel, ajouté le mien et rebasé le commit juste avant la v0.75.0-rc1. Puis repensé, avec des annotations originales (en a fait une caractéristique)

La moitié de mes difficultés était de ne pas comprendre que les actions n'utilisaient que le .yml du commit par lequel elles avaient été déclenchées, donc quand je poussais une vieille balise, les choses ne fonctionnaient tout simplement pas.

"The Master" uniquement les scripts .github

J'ai besoin de PLACEHOLDER les variables principales
les variables ne sont pas synchronisées avec les branches de test ci-dessus.

Pour le moment, le yml est "codé en dur" avec les noms des branches
Je pense que je devrais les mettre dans l'en-tête (nommé: "set env" pour le moment) et faire en sorte que le corps utilise l'env. var.

dans le script shell, debian_branch et reprepro_branch doivent pointer vers les branches correctes
mais, il serait logique de lui faire obtenir ceux du yml, de la même manière qu'il obtient TAG.

J'ai également besoin de corriger un point d'échec, si je pousse vers le repo apt pendant qu'il est en cours de construction, il ne parvient pas à pousser car HEAD n'est pas ce à quoi il s'attend.
Donc, à la place, j'ai besoin de vérifier le repo apt juste avant qu'il ne soit prêt à pousser. et faites quelques essais en fonction du code de sortie donné par git.

En signant, j'ai réussi à tout faire fonctionner, y compris la clé privée protégée par mot de passe. Cependant, il est beaucoup plus facile d'utiliser simplement une clé sans mot de passe.

J'ai besoin de mettre un avertissem*nt «clé en raison d'expirer» à la toute fin, l'e-mail d'échec d'exécution n'est pas très utile (ce serait bien s'il donnait au moins le code de sortie) mais le bas du journal aurait un message vous que la clé allait expirer dans X semaines

Construction de PPA
https://launchpad.net/~feignint/+archive/ubuntu/db-s-poc

déclenché par
https://github.com/FeignInt/dosbox-staging-deb/tree/pkg_debs/.github
et
https://github.com/FeignInt/dosbox-staging-deb/tree/debianlike

note: les commits .github sur pkg_debs ont été rebasés juste avant rc1

J'ai juste besoin de supprimer ou de conditionner l'extraction apt-repo, car pour le moment, il extrait inutilement un dépôt qu'il n'utilise jamais.

oh, et supprimez le non-sens de la mise en cache du mot de passe gpg, ajoutez un avertissem*nt d'expiration sig + d'autres choses

J'ai aussi besoin de rendre lintian heureux, il se plaint de la façon dont j'ai paramétré LDFLAGS, le fichier copyright et la page de manuel

@FeignInt Pourquoi la version s'appelle 0.75.1-1? Nous n'avons pas encore publié la version 0.75.1 (mais nous le ferons).

Pourquoi avez-vous eu besoin de changer les LDFLAGS? Si le système de construction n'est pas approprié pour une raison quelconque, veuillez nous en informer :)
Idem pour la page de manuel - si quelque chose manque / est incorrect, nous sommes très intéressés à adapter le correctif dès que possible.

Je n'ai pas regardé en détail dans le paquet (je ne suis pas une personne Debian), mais je vais y jeter un coup d'œil étant donné un peu de temps.

J'espère que le plan est de changer éventuellement le nom du dépôt en

@rêveur

il y avait un commit sur la branche release après la balise v0.75.0, donc je l'ai taguée comme version ponctuelle

Il n'y a rien de mal avec les LDFLAGS
au lieu de la valeur par défaut de Debian LDFLAGS=-Wl,-z,relro je l'ai défini -Wl,--as-needed -Wall -pipe -fpch-preprocess comme le build.sh actuel. lintian montre un avertissem*nt à cause de la façon dont je l'ai fait, c'est juste d'être difficile, il me plaît de le définir explicitement.

La seule raison pour laquelle j'ai essayé la construction de bras, c'est que j'ai vu des boutons sur PPA
Je vais voir jusqu'où j'arrive en utilisant les indicateurs de compilateur par défaut (qui devraient simplement fonctionner). Je ne sais pas quelle différence les drapeaux du compilateur font réellement dans le monde réel, mais je sais que -msse4.2 casse core2duo.
Je peux ensuite rechercher les bons drapeaux pour arm (mais je ne peux pas tester une construction, sauf si je vais sur la route qemu)

Le compte PPA sera supprimé, ce n'est qu'une preuve de concept, @kcgen mentionne ci-dessus que vous et eux avez des comptes PPA
mais pour l'image de marque, il vaut probablement mieux avoir

edit: nouvelle ligne, wrap avait l'air moche
ppa: dosbox-staging / {stable, alpha}

Puisque le côté PPA des choses s'est avéré être si simple. Le plus de problèmes que j'ai eu a été d'enregistrer la clé gpg, il s'avère que le meilleur moyen est de coller le pub blindé ascii dans https://keyserver.ubuntu.com/ au lieu de gpg --send-key comme le suggèrent les guides
Je peux grandement simplifier les scripts en supprimant tous les trucs liés à reprepro (plus de jouer avec les jetons d'accès et plusieurs dépôts git :))
Je prévois de réécrire dans un seul script yml
Je n'avais jamais utilisé de workflows github ou de PPA auparavant, donc je comprends mieux maintenant.

L'erreur de page de manuel est triviale

W: dosbox-staging: manpage-has-errors-from-man usr / share / man / man1 / dosbox.1.gz line 242: 'R' est une chaîne (produisant le signe enregistré), pas une macro.

problème similaire avec la ligne 112

vérification rapide, envoyer std à / dev / null
man docs / dosbox.1> / dev / null

Cela semble corriger ces erreurs,
mais je n'ai jamais fait de formatage de page de manuel auparavant

--- a/docs/dosbox.1+++ b/docs/dosbox.1@@ -109,9 +109,9 @@ an Internal Program, a DOS command or an executable on a mounted drive. Output version information and exit. Useful for frontends. .TP .BI "\-\-editconf ["editor ]-.R Open the default configuration file in a text editor. If no editor name+.RB "Open the default configuration file in a text editor. If no editor name is given, then use the program from EDITOR environment variable,-otherwise DOSBox will try to guess the name.+otherwise DOSBox will try to guess the name." .TP .BI \-opencaptures " program" .RI "calls " program " with as first parameter the location of the captures folder."@@ -238,7 +238,7 @@ this as well!) .RS .TP .B \-All-.R Reread directory structure for all drives.+.RB "Reread directory structure for all drives." .TP .B Drive: .RB "Reread directory structure for drive " Drive:

@rêveur

il y avait un commit sur la branche release après la balise v0.75.0, donc je l'ai taguée comme version ponctuelle

Euh, ok… mais cela pourrait être quelque peu trompeur pour les utilisateurs… Je suppose que les emballeurs seront plus intéressés par le suivi des balises et non des branches… c'est à cela que servent les balises en fait. Nous verrons comment cela se passera lorsque nous préparerons la sortie de la 0.75.1.

Il n'y a rien de mal avec les LDFLAGS
au lieu de la valeur par défaut de Debian LDFLAGS=-Wl,-z,relro je l'ai défini -Wl,--as-needed -Wall -pipe -fpch-preprocess comme le build.sh actuel. lintian montre un avertissem*nt à cause de la façon dont je l'ai fait, c'est juste d'être difficile, il me plaît de le définir explicitement.

Vous n'avez pas besoin de -Wall pour les builds de paquet (c'est pertinent pour le développement, mais pas pour l'empaquetage); mais convenez-vous. -pipe existe dans nos scripts de développement pour contourner les bogues sous macOS; AFAIK il n'est pas nécessaire de l'utiliser n'importe où en dehors de macOS (d'autant plus que vous ne comptez pas les résumés d'avertissem*nts comme nous le faisons dans notre CI); Je pense que vous pouvez ignorer ce drapeau. -fpch-preprocess est activé uniquement si vous avez ccache (encore une fois, sans importance pour l'empaquetage).

Je suggère de s'en tenir aux indicateurs suggérés par Debian - ils sont probablement mieux adaptés aux utilisateurs Debian. La seule grande exception est le drapeau du compilateur -O - nous vous recommandons fortement d'utiliser -O3 (jusqu'à ce que nous trouvions un bon moyen de générer et de distribuer des profils d'exécution aux packagers).

La seule raison pour laquelle j'ai essayé la construction de bras, c'est que j'ai vu des boutons sur PPA
Je vais voir jusqu'où j'arrive en utilisant les indicateurs de compilateur par défaut (qui devraient simplement fonctionner). Je ne sais pas quelle différence les drapeaux du compilateur font réellement dans le monde réel, mais je sais que -msse4.2 casse core2duo.

Ils font une petite différence (je n'ai pas de chiffres exacts, mais de manière anecdotique, le simple fait de passer de -march = nehalem à -march-haswell me donne des builds 1-3% plus rapides); mais je ne m'inquiéterais pas du tout pour le moment. Optez pour les valeurs par défaut de Debian - nous préférerions de loin un paquet Debian compatible ARM plutôt qu'une augmentation de vitesse de 1%. Une fois que le package sera bon et utilisable, nous pouvons améliorer le processus de construction pour s'adapter à différentes architectures.

Le compte PPA sera supprimé, ce n'est qu'une preuve de concept, @kcgen mentionne ci-dessus que vous et eux avez des comptes PPA
mais pour l'image de marque, il vaut probablement mieux avoir

edit: nouvelle ligne, wrap avait l'air moche
ppa: dosbox-staging / {stable, alpha}

J'espère que nous serons inclus dans les dépôts Debian et Ubuntu (le plus tôt sera le mieux) et qu'il n'y aura pas besoin à long terme de PPA. Je préférerais laisser l'emballage aux emballeurs de distribution - je leur fais confiance pour prendre de meilleures décisions concernant leur système d'exploitation que moi :) Je m'occuperai de ma distribution et créerai un package COPR pour accélérer l'inclusion dans Fedora, mais je ne prévois pas le maintien de PPA moi-même.

L'erreur de page de manuel est triviale

W: dosbox-staging: manpage-has-errors-from-man usr / share / man / man1 / dosbox.1.gz line 242: 'R' est une chaîne (produisant le signe enregistré), pas une macro.

problème similaire avec la ligne 112 (…)>

Cela semble corriger ces erreurs: (…)

Je vais jeter un oeil, merci! :)

ouais, je laisse normalement les valeurs par défaut

avec les valeurs par défaut arm64 construit avec succès

https://launchpad.net/~feignint/+archive/ubuntu/db-s-poc2/+sourcepub/11382068/+listing-archive-extra

au moment où l'arm64 est répertorié comme "publication en attente"
mais peut être téléchargé depuis
https://launchpad.net/~feignint/+archive/ubuntu/db-s-poc2/+build/19492930

Je n'ai rien pour le tester

test programmé à

1. 16:00 UTC - devrait être v0.75.0-rc1
2. 17:00 UTC - devrait être v0.75.0
3. 18h00 UTC - ne devrait "rien faire"

Cela poussera à
https://launchpad.net/~feignint/+archive/ubuntu/dosbox-staging-test1

cela peut prendre un certain temps à construire une fois qu'il atteint PPA,

J'ai changé quelques choses depuis la dernière fois que j'ai poussé à PPA, mais je pense que cela fonctionnera

J'ai coché de nombreuses cases

• [x] AMD x86-64 (amd64)
• [x] ARM ARMv8 (arm64)
• [x] ARM ARMv7 Soft Float (armel)
• [x] ARM ARMv7 Hard Float (armhf)
• [x] Intel x86 (i386)
• [x] PowerPC (powerpc)
• [x] PowerPC64 Little-Endian (ppc64el)
• [] RISC-V 64 bits (riscv64)
• [] IBM System z (s390x)

basé sur des tests antérieurs:

| Architecture | Construit | Runs | commentaire |
| - |: -: |: -: | - |
| AMD x86-64 (amd64) | : lourd_check_mark: | : lourd_check_mark: | bullseye / sid, |
| Intel x86 (i386) | : lourd_check_mark: | : grey_question: | |
| ARM ARMv8 (arm64) | : lourd_check_mark: | : grey_question: | |
| ARM ARMv7 Soft Float (armel) | : grey_question: | : grey_question: | |
| ARM ARMv7 Flotteur dur (armhf) | : grey_question: | : grey_question: | |
| PowerPC (powerpc) | : grey_question: | : grey_question: | |
| PowerPC64 Little-Endian (ppc64el) | : grey_question: | : grey_question: | |

@FeignInt oubliez la v0.75.0-rc1 - plus personne ne se soucie de cette ancienne télécommande maintenant une fois la v0.75.0 sortie :)

Je vois que vous avez sauté s390x - c'est bon, je doute qu'il y ait des utilisateurs intéressés à exécuter dosbox-staging sur cette architecture; nous l'incluons cependant dans nos builds de plateforme, juste pour avoir un processus de build de test sur au moins une arche big-endian sur une base régulière;)

De plus, je pense que nous ferons bientôt la version 0.75.1 (comme dans une semaine ou deux - nous verrons) - cela inclut des corrections de bogues importantes (certains commits étaient déjà rétroportés dans la branche release/0.75.x , mais nous n'avons pas t l'a encore étiqueté).

en ce qui concerne 0.75.0-rc1, ouais, je peux juste pré-taguer pour qu'il soit ignoré

Les Archs non cochés sur PPA sont ceux que je ne pouvais pas cocher, je pense que vous devez demander à un administrateur de les "déverrouiller", mais comme vous l'avez dit, je doute que quiconque en veuille / en ait besoin.

malheureusem*nt, il semble avoir échoué du côté des PPA
Il a été téléchargé mais le tableau de bord semble l'avoir ignoré, je suppose que c'est un problème avec la signature gpg.

J'espère avoir une chance de comprendre pourquoi plus tard aujourd'hui

Je vais désactiver la prochaine course jusqu'à ce que je le comprenne.

Je l'ai compris à la fin
J'ai négligé d'importer un morceau qui a renommé PPA_ID en PPA_REPO dans push_to_ppa ()

https://launchpad.net/~feignint/+archive/ubuntu/dosbox-staging-test1/+sourcepub/11409782/+listing-archive-extra

• [x] amd64 - Publication en attente
• [x] arm64 - Publication en attente
• [x] armhf - Publication en attente
• [x] i386 - Publication en attente
• [x] ppc64el - Publication en attente

Je ne sais pas pourquoi armel et powerpc manquent, je ne vois pas d'erreurs pour eux.
mais au moins les amd64 et arm64 semblent être ok.

Je laisserai ce PPA pendant un moment, jusqu'à ce que j'en tienne un plus propre, avec des descriptions / liens complets, etc.

https://launchpad.net/~feignint/+archive/ubuntu/dosbox-staging

https://github.com/FeignInt/dosbox-staging-deb/tree/debianish

presque entièrement automatisé.

Pour le moment, si cela ne tient pas compte des modifications apportées à la construction, je peux peut-être écrire cela, je ne suis pas sûr.

est focal 20.04?

pour le moment, il utilise ubuntu-latest, qui est 18.04
Je suppose que je pourrais faire une de ces choses marix à faire ubuntu-20.04, et toutes les autres
edit: en fait c'est beaucoup plus facile que ça, je pense que je peux dire à gbp dch de forcer une distribution au lieu d'utiliser l'environnement. il est entré. Je vais essayer plus tard, ce sera une version -2

Le nom de code n'est pas si important que cela, j'ai supprimé la référence au numéro de version minimum, cela devrait fonctionner.
Vous pouvez compiler / empaqueter vous-même, quelques détails sur celui inclus dans le READ.md sur la branche debianish

mettre à jour:

• Dosbox-staging release PPA

  • Groovy, Focal, Eoan, Bionic, Xenial, Trusty

• Dosbox-staging-hebdomadaire PPA

  • Groovy, Focal

L'hebdomadaire est seulement amd64, je peux cocher plus d'arches si nécessaire. Je peux également l'avoir dans un package de séries Ubuntu plus anciennes. Pour le moment, il s'agit d'un flux de travail .yml séparé, mais je pense que je vais fusionner les deux flux de travail en un seul fichier avec une réécriture.

J'ai ajouté la prise en charge de fluidsynth, mais cela ne sera activé que sur Focal et plus récent car la version de Fluidsynth est <2.0.0 pré Focal, pour autant que je ne puisse voir aucun backport v2.

Remarque: je n'ai pas ajouté fluidsynth comme dans un cherrypick , juste inclus la construction dépend et une condition à ajouter --disable-fluidsynth si la version est trop basse.

Le premier journal des modifications hebdomadaire est énorme (tous les commits depuis la v0.75.0), le suivant ne listera que les changements depuis la dernière semaine. J'ai encore besoin de filtrer les entrées du journal des modifications, par exemple pour ignorer les changements dans

Actuellement, l'hebdomadaire et la version ne peuvent pas être installés côte à côte.

À l'avenir, je pourrais ajuster les choses pour qu'elles soient des paquets indépendants séparés, par exemple _-- program-suffix = -alpha_ et que _debian / rules_ utilise des modèles control.in pour modifier le nom du paquet, la description, etc.

Vraiment lisse @FeignInt!

J'aime l'art ascii; c'est certainement un autre joyau perdu qui me manque dans les scènes de BBS, de sortie et de démo du début des années 90.

En ce qui concerne les plates-formes, je pense que l'amd64 couvrira les 99%, et si les utilisateurs ont un moyen de demander autre chose, nous pourrions évaluer l'intérêt de cette façon. Quelque chose comme "_Vous ne voyez pas votre plate-forme ou la version de votre système d'exploitation? Contactez-nous à l'adresse xyz_"

Les versions hebdomadaires sont parfaites pour les utilisateurs qui souhaitent conserver le dernier code mais ne veulent pas avoir à faire leurs propres versions; laissez simplement le programme de mise à jour automatique vous synchroniser. Je conviens également que c'est probablement bien que cela entre en conflit avec la version stable.

Si quelqu'un veut vraiment basculer entre les deux versions, il construira probablement à partir des sources de toute façon et vérifiera même des commits spécifiques.

C'est un bon résumé du journal des modifications; est-ce quelque chose que vous avez ajouté ou qui est généré par l'outillage ppa?

https://launchpadlibrarian.net/489902812/dosbox-staging_0.76.0~alpha~332~g6694-1+u20.10_source.changes

Ouais, je pensais que l'ascii était amusant

J'ai essayé la couleur ascii, cela a fonctionné mais a rendu la page ppa illisible car asciiart a défini le code de couleur pour chaque caractère., Je l'ai depuis apprivoisé manuellement un peu (ne changez le code de couleur que si nécessaire) peut-être que je l'ajouterai plus tard.

Le journal des modifications provient de git-buildpackage (gbp dch --since =, mais j'ai dû le pirater un peu car par défaut, il ne considérera que la branche sur laquelle vous vous trouvez.

Les hacks sont dans hack_dch_py() et patched_dch() dans hebdomadaire_PPA.yml
Actuellement sed. Je dois creuser plus profondément et éventuellement produire un patch (ensemble) plus complet et plus propre pour l'amont

gbp dch --verbose montre un peu ce qui se passe sous le capot, essentiellement git rev-parse et git show --pretty=format:...
Mais il a également une analyse de méta-étiquettes pratique pour inclure des correctifs: et merci:

Cette page vous a été utile?

0 / 5 - 0 notes