Bug#893083: hello: Packaging should be hosted on salsa.debian.org
On Mon, 26 Dec 2022, Santiago Vila wrote: > So, suppose that someone has a package requiring the above for "gbp > buildpackage" to work. > Does the package have a disclaimer somewhere saying "plain dpkg-buildpackage > is not supported > here" or something alike? You can document any discrepancy in debian/README.source in general. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#893083: hello: Packaging should be hosted on salsa.debian.org
El 26/12/22 a las 17:30, Raphael Hertzog escribió: 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 Ok. For "hello" I will follow the trend and add whatever build-dependencies are required for it to work in all cases, but I'm still interested in these kind of tricks just in case I need them for other packages. So, suppose that someone has a package requiring the above for "gbp buildpackage" to work. Does the package have a disclaimer somewhere saying "plain dpkg-buildpackage is not supported here" or something alike? Thanks a lot.
Bug#893083: hello: Packaging should be hosted on salsa.debian.org
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 ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#893083: hello: Packaging should be hosted on salsa.debian.org
Hi. I'm working on this now. After considering available options, I'm going to host it under my "sanvila" namespace for now. My work in progress is here: https://salsa.debian.org/sanvila/hello-alpha But there are some technical and philosophical issues unsolved yet. 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? In the past I've used the trick of adding some touch statements in debian/rules (the current recode package, which I still have to update, is an example of this). Is there some git-buildpackage specific solution for this? 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? Thanks.
Bug#893083: hello: Packaging should be hosted on salsa.debian.org
Source: hello Version: 2.10-1 Severity: wishlist The "hello" package is the sample package that we want to use everywhere in documentation. Thus it should be really a model for all packages. Unfortunately hello is not maintained in a git repository. It should really be on https://salsa.debian.org/debian/hello and have Vcs-Git and Vcs-Browser fields. Because that's what we do for any sanely maintained package nowadays. BTW it should use DEP-14 layout in its git repository: http://dep.debian.net/deps/dep14/ -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
