Hi Daniel, Dne 31.03.2024 (ned) ob 16:01 +0200 je Daniel Gröber napisal(a): > > 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. > Fixed (even salsa pipeline is happy:).
> Workflow wise I don't see why you needed to make a merge commit at > d0cc659. Can you explan what you were doing? > Well, after i updated the upstream branch, i wanted to preserve your original debian/sid branch, so i renamed it and merged it into the new debian/sid branch, based at the latest 0.4.6 release tag of the upstream branch. Actually, this is the point, where i need to learn, how debian/sid branch is to be managed in a 'debianized' git repo through upstream updates? > 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. > I had 'pristine-tar' set to 'True' in my '~/.gbp.conf'. After changing it to 'False' i can simply run 'gbp buildpackage'. Would you recommend setting 'pristine-tar=False' also in 'debian/gbp.conf' of the git-subrepo? > 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. > something new for me to digest:) Actually i preserved upstream history in my manual git-subrepo upstream branch update and lost your history in new debian/sid branch with merge. Maybe rebasing of 'debian/sid' to newer upstream could solve that as well... > 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. > Now i actually use 'sbuild-createchroot' (https://wiki.debian.org/sbuild) to create chroot used by sbuild, however sbuild is not run from my old ubuntu host directly, but from 'schroot -c debian-sid' prepared previously (see: https://wiki.debian.org/Packaging/Pre-Requisites#Option_2:_Schroot_and_Sbuild) > 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. > noted and thanks for valuable insights. best regards, Samo
