Hi Samo, On Sun, Mar 31, 2024 at 01:42:48PM +0200, Samo Pogačnik wrote: > I prepared a new git-subrepo in salsa as a fork of your project ( > https://salsa.debian.org/spog/git-subrepo). Then i updated upstream and > prepared debby> a new 'debian/sid' branch. Would you be so kind to take a look at it and comment > on what should be changed/fixed and how to proceed.
You removed the (Closes Bug#) ITP reference from d/changelog. It's policy to close that but with the first upload, so you have to keep it. Workflow wise I don't see why you needed to make a merge commit at d0cc659. Can you explan what you were doing? On Wed, Mar 27, 2024 at 07:27:31PM +0100, Samo Pogačnik wrote: > Thank you for the valuable information. Currently i managed to reactivate my > Salsa account, so that i am properly accessing your 'git-subrepo' repo. I was > also able to setup debian-sid chrooted environment on my old Ubuntu laptop up > to > the point that i think i can successfully rebuild your current 'git-subrepo' > project using the following commands after entering 'debian-sid' (schroot -c > debian-sid): > $ gbp clone --pristine-tar g...@salsa.debian.org:dxld/git-subrepo.git I don't use pristine-tar unless absolutely required (due to DFSG repacking or some such), gbp defaults to using git-archive to generate tarballs so just leave off the pristine-tar options. Packaging repos usually declare whether they use pristine-tar in d/gbp.conf so there should rarely be a need to fiddle with the options here. > $ cd git-subrepo > $ gbp buildpackage --git-pristine-tar-commit Don't use --git-pristine-tar-commit. Proper proceedure is to do that explicitily using gbp import-org (if using that). There's another option for importing upstream sources which I prefer (but that is a bit of a PITA): `gbp import-ref` it is a pure git workflow leaving the tarball hassle to gbp and that preserves upstream git history and git-blame'ability. Admittedly it's not very widely used in Debian ATM (which may change thanks to the current xz kerfluffle) so docs may be lacking. Let me know if you can't figure it out. > I hope this is the correct procedure - i wasn't very confident seing 'sbuild' > requireing another 'chroot' from within my original 'chroot', however it seems > to be working now? Seems ok, but building in "clean" chroots (using sbuild) is strongly preferred for real testing. sbuild calls schroot internally. You run it from your system like normal. You just have to configure a tell it which base chroot to use and that chroot needs special handling to be as close to the buildd ones as feasible. Relevant chroot bootstrapping tools often have an "sbuild"/"buildd" mode. I tend to use sbuild-createchroot(8) from ubuntu-dev-tools for chroot building, but debspawn is probably orders of magnitudes easier as far as setup and maintainance of the environments is concerned. > My plan now is to fork your git-subrepo project, fetch latest upstream changes > and rebuild the latest version. Would that be ok to get to the point, when a > new > ITP could have been issued? You don't need a new ITP, it's still open and valid. If you want to be proper you can change the "owner" field to yourself. Send an email to cont...@bugs.debian.org, see https://www.debian.org/Bugs/server-control. Good practice for interacting with the BTS anyway. > > https://github.com/lkhq/debspawn looks really neat and tidy but may be > > untrodden ground. Could be workable if you feel up to trying it. I would > > also be curios to know if it works well. See > > https://github.com/lkhq/debspawn/issues/27 for some discussion between > > ximion (the author) and josh (sbuild maintainer) how it compares against > > sbuild. > > > I might try debspawn on another 'non-debian' 'nixos-based' machine, but this > may > not happen very quickly. As i understood, it only requires a systemd-based > Linux. I wouldn't trust it working outside of Debian. It's a Debian tool for and by Debian people. > > Aah, it's nice and warm in the jungle but simetimes you get lost between > > all the vines~ > > I get lost a lot. Three years ago even so that i created new docker-pbuilder- > based packaging tool: https://salsa.debian.org/spog/debdocker, just to get my > head around debian ways. You can imagine that the project wasn't accepted very > well on debian-devel:). c.f. https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence While sometimes we may need to build to understand others need to see you understand before they let you build on their land ;-) --Daniel
signature.asc
Description: PGP signature
