Bug#979188: Maintaining git-subrepo in Debian?
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
> control@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
Reply to: