Hi Samo, On Mon, Apr 01, 2024 at 07:54:09PM +0200, Samo Pogačnik wrote: > > 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?
Right, that's not how to do things in a git-buildpackage repo. See the problem gbp is solving is that Debian source packages (.dsc) are composed of two parts (tarballs) the upstream part (.orig.tar.*) and the debian part (debian.tar.*). To represent this in git gbp has the concept of an upstream branch and a debian branch. When updating your gbp packaging repo to a new upstream version you have to update the upstream branch pointer and merge that into the debian branch separately. import-orig and import-ref will do this for you as it's a hassle. Honestly I really hate this part of gbp's design. Having two branches is just such a hassle to manage and makes all the operations gbp performs non-atomic and it has to support rollback of whatever it has already tried to do in case anything (say a git-merge) fails down the line ... it's a mess. There are other git workflows in use in Debian, eg. dgit, but they're even harder to get your head around, or at least I haven't managed to, so gbp it is for now :/ Anyway gbp has reasonably good documentation, maybe you haven't seen it yet: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html (note the navigation buttons in the top right) > > 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? Oh I didn't even know gbp has a user config file. That seems ill-concieved. Gah. Yeah I would strongly reccomend not messing with the pristine-tar option in the user-config. We could explicitly set it =False in d/gbp.conf but I'd rather not as I don't think that's commonly done at all though I can find a number of occurrences in my Debian packaging workdir. > > 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... I wish we could use a rebase workflow with gbp but I haven't found a way to do it yet. At least not with gbp import-ref as-is. We could work on a patch for it I suppose ;) I just want to avoid using a custom script to import upstream sources if at all possible. Debian already has too much fude factor in packaging. > > 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) I don't see why that would be necessary though? Ubuntu also uses sbuild, the version in their archive should work just fine for our purposes as long as you make it use a Debian chroot. --Daniel
signature.asc
Description: PGP signature
