Hello Nicholas!
A few problems...
these commands:
git clone git@salsa.debian.org:emacsen-team/atomic-chrome-el.git
cd atomic-chrome-el
uscan --download-current-version
git bp
give me this error:
anarcat@angela:atomic-chrome-el(master)$ git bp
dh clean --with elpa
dh_clean
gbp:info: Creating atomic-chrome_2.0.0.orig.tar.xz from 'v2.0.0'
gbp:info: Exporting 'HEAD' to '/home/anarcat/src/build-area/atomic-chrome-tmp'
gbp:info: Moving '/home/anarcat/src/build-area/atomic-chrome-tmp' to '/home/anarcat/src/build-area/atomic-chrome-2.0.0'
gbp:info: Performing the build
dpkg-source: error: source package has two conflicting values - atomic-chrome-el and atomic-chrome
E: Failed to run dpkg-source --before-build /home/anarcat/src/build-area/atomic-chrome-2.0.0
i am not sure, but i suspect it is a mismatch between the
debian/changelog and debian/control package names. indeed, with the
following patch:
From 419b3c708fbc41e727fc2dd880b7d90da8ada692 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org>
Date: Fri, 17 Apr 2020 20:52:07 -0400
Subject: [PATCH] fix package name to match debian/control
---
debian/changelog | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index d11e6c7..98e3daa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-atomic-chrome (2.0.0-1) unstable; urgency=medium
+atomic-chrome-el (2.0.0-1) unstable; urgency=medium
* Initial release. (Closes: #909336)
--
2.20.1
... the package compiles.
The other issue I found is what now seems to be a recurring disagreement
between us. :) This is the tarball that `uscan` gives me when I run the
above command:
anarcat@angela:src(master)$ sha256sum atomic-chrome-2.0.0.tar.gz
f239fabd2438df8d947b333453534e6ab76f946c8879df2e3f1151baf76dac97 atomic-chrome-2.0.0.tar.gz
anarcat@angela:src(master)$ file atomic-chrome-2.0.0.tar.gz
atomic-chrome-2.0.0.tar.gz: gzip compressed data, from Unix, original size 296960
Yet, git-buildpackage will not use that tarball. Because it has the
following configuration:
compression = xz
compression-level = 9
It generates the following, different tarball:
anarcat@angela:atomic-chrome-el(master)$ sha256sum ../build-area/atomic-chrome-el_2.0.0.orig.tar.xz
2d55a3646307be8c4b1703e3f353a358987592d6523a8de0ffb7be1292e678ab ../build-area/atomic-chrome-el_2.0.0.orig.tar.xz
anarcat@angela:atomic-chrome-el(master)$ file ../build-area/atomic-chrome-el_2.0.0.orig.tar.xz
../build-area/atomic-chrome-el_2.0.0.orig.tar.xz: XZ compressed data
There are a few things wrong here:
1. we should not needlessly differ from the upstream tarball
2. if we really have to, `uscan` should allow us to reconstruct our
tarball reproducibly, or at least `README.source` should explain
how. at minimum, `README.source` should explain *why* we differ
3. even if we insist on using `xz` (and I don't see why we do in this
case), we don't need the maximum compression level. this is a small
package and there's not reason to "crank it up to 11", so to speak :)
The following patch should fix the problem:
From a9dc9a10a4c1ea9024a70335232dd837d36738d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org>
Date: Fri, 17 Apr 2020 21:01:14 -0400
Subject: [PATCH] remove superfluous diff with upstream tarball
---
debian/gbp.conf | 3 ---
1 file changed, 3 deletions(-)
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 07b0329..839ffea 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -6,6 +6,3 @@ debian-tag = debian/%(version)s
sign-tags = True
pristine-tar = False
pristine-tar-commit = False
-
-compression = xz
-compression-level = 9
--
2.20.1
I feel uncomfortable sponsoring a package if it doesn't use the upstream
tarballs. I hope you'll understand.
A.
--
Nature hides her secret because of her essential loftiness, but not by
means of ruse.
- Albert Einstein
Attachment:
signature.asc
Description: PGP signature