When reuploading source package to PPA, suddenly "no @ found in email address part"

Asked by Andrew Chiw on 2017-11-07

I'm trying to make a PPA to hold newer dependencies.
In particular, python3-grpcio will not build on Launchpad PPA because it insists on running unittests.
So I want to try "debuild -S -eDEB_BUILD_OPTIONS=nocheck -k$GPGKEY -sd" (please tell me if this is the right way to solve the problem).
However, this time when I try to upload it 'dput ppa:randomkudo/qrllib-deps-builder grpcio_1.7.0-1_source.changes' Launchpad sends me an email saying:
Rejected:
DEB_BUILD_OPTIONS=nocheck: no @ found in email address part.

Further error processing not possible because of a critical previous error.

grpcio (1.7.0-1) xenial; urgency=low

  * source package automatically created by stdeb 0.8.5

But that's ridiculous, because the first time I uploaded it without the -eDEB_BUILD_OPTIONS it accepted it, and the build failed.

Here is my debian/changelog:
grpcio (1.7.0-1) xenial; urgency=low

  * source package automatically created by stdeb 0.8.5

 -- The gRPC Authors <email address hidden> Tue, 07 Nov 2017 18:16:27 +0000

debian/control
Source: grpcio
Maintainer: The gRPC Authors <email address hidden>
Section: python
Priority: optional

This is from py2dsc, so the email was taken from a pip package.

Any ideas?

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Andrew Chiw
Solved:
2017-11-09
Last query:
2017-11-09
Last reply:
2017-11-08
William Grant (wgrant) said : #1

debuild is a wrapper around a number of other programs, perhaps most importantly dpkg-buildpackage. When debuild sees an option that it doesn't recognise, it assumes that all further options are for dpkg-buildpackage. In this case, -S is a dpkg-buildpackage option, so -e is treated as a dpkg-buildpackage option rather than a debuild one. And dpkg-buildpackage's -e option sets the email address, so Launchpad's error message is correct. The correct syntax would be to swap the -S and -e.

However, setting DEB_BUILD_OPTIONS in debuild's environment won't do what you want; that would only set it for the local build. Instead of passing it on the commandline, you'd need to adjust the debian/rules that you upload to Launchpad to append nocheck to the DEB_BUILD_OPTIONS variable.

Andrew Chiw (randomkudo) said : #2

Thanks William, that was a really good explanation.

Launchpad still rejects my source dist - it says

Rejected:
File grpcio_1.7.0-1.debian.tar.xz already exists in qrllib-deps-builder, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
Files specified in DSC are broken or missing, skipping package unpack verification.

This makes sense, because I edited debian/rules. However I thought that passing debuild -sd instead of -sa would somehow communicate that the original source was not important, and that it should rebuild with the new rules in package-ver.debian.tar.xz.

Do I really have to specify a new version as in Section 9.3 https://www.debian.org/doc/manuals/maint-guide/upload.en.html? Incrementing a version number just to try out build options sounds silly.

Andrew Chiw (randomkudo) said : #3

Since it's a python pip package repackaged using pip, I found a way to increment the version number with python.setup.py --debian-version=x. Thank you very much for your help.

Colin Watson (cjwatson) said : #4

Yes, every upload requires a unique version number (-sd vs. -sa is for something else and not relevant here), but it doesn't have to be the upstream part - you'd typically increment the part after the "-" in some way. It sounds like you've got something working already, but for reference see https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning.