Hello, On Fri, 23 Dec 2022, Santiago Vila wrote: > For example, this one: > > I have just imported version 2.10-2. Now dpkg-buildpackage > does not work because it expects some timestamps to be the ones in the > orig.tar.gz where upstream maintainer already ran autoconf and friends. > > I know that autoreconf may help here, but I would prefer not to be forced > to use it. What are my options? > > Is there some git-buildpackage specific solution for this?
Yes, I think so. Use --git-export-dir=../build-area/ (many persons have it in their ~/.gbp.conf). $ cat ~/.gbp.conf [DEFAULT] pristine-tar = True cleaner = /bin/true [buildpackage] sign-tags = True export-dir = ../build-area/ ignore-branch = True ignore-new = True [import-orig] filter-pristine-tar = True [pq] patch-numbers = False [dch] multimaint-merge = True ignore-branch = True That way git-build-package will run the build in a fresh tree where all the files will have the same timestamp. > Related to the above: Is it acceptable/desirable to put a package in git when > it may not > be compiled from git yet? Or maybe I should start the git history in a point > where such build > from git is actually possible? Should I add a warning somewhere that only the > latest > version is expected to work, or maybe that's already implicit? It's certainly OK if the initial import does not work and if only the latest version is really working. It would be surprising that the checkout of the released tag does not work but it would not be a big deal either. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
