[16:21] <realtime-neil> sbuild --source --source-only-changes produces a `*_source.changes` that launchpad rejects, saying "Mismatch in binaryfulness. (arch) False != (files) True". What am I doing wrong with my sbuild? How do I tell sbuild to make an acceptable `*_source.changes`?
[16:25] <cjwatson> Can I see your .changes?
[16:25] <cjwatson> You might be running into https://bugs.launchpad.net/launchpad/+bug/1699763
[16:26] <realtime-neil> Whoops, I might have missed this: https://wiki.debian.org/SourceOnlyUpload#git-buildpackage_support
[16:27] <realtime-neil> cjwatson: generating that file now...
[16:28] <cjwatson> I tend to just use "debuild -S -nc" (dropping the -nc if the source tree might not be clean and if I know I have the build-deps)
[16:29] <cjwatson> I think you could add --debbuildopt=--buildinfo-option=-O though
[16:29] <cjwatson> (to sbuild)
[16:34] <realtime-neil> cjwatson: https://paste.ubuntu.com/p/SJWnmYvkjR/
[16:34] <cjwatson> realtime-neil: Right, try adding --debbuildopt=--buildinfo-option=-O
[16:35] <realtime-neil> cjwatson: will do
[16:35] <cjwatson> Failing that in extremis you can delete all the .buildinfo lines and re-sign, but that's generally best avoided
[16:48] <realtime-neil> cjwatson: same error https://paste.ubuntu.com/p/zPd6vxVG9D/
[16:49] <cjwatson> realtime-neil: now that shouldn't produce the same error - it looks right
[16:50] <cjwatson> realtime-neil: are you certain that's what you reuploaded?
[16:50] <realtime-neil> very; I can try with a new launchpad repo
[16:51] <cjwatson> realtime-neil: That would be a waste of time
[16:51] <cjwatson> realtime-neil: Your last upload got a completely different error, according to our logs
[16:52] <cjwatson> realtime-neil: (I mean, it was one of the errors present in your earlier rejection, but the most recent rejection did *not* include the "Mismatch in binaryfulness" error)
[16:53] <realtime-neil> Here's more error message: https://paste.ubuntu.com/p/sgs7pf49Mj/
[16:54] <cjwatson> That's not the most recent rejection
[16:54] <realtime-neil> correct
[16:54] <cjwatson> The most recent one just has the last two lines of that
[16:54] <cjwatson> "Unable to find arenasdk_0.1.38.orig.tar.xz in upload or distribution" should be fixable by adding --force-orig-source
[16:55] <realtime-neil> retrying
[16:58] <realtime-neil> cjwatson: same
[16:59] <cjwatson> Can I see the new .changes?
[16:59] <cjwatson> I agree that this time it is in fact the same error
[17:00] <realtime-neil> https://paste.ubuntu.com/p/58TnH3xtQf/
[17:00] <cjwatson> sbuild's source building is some of those things that I think is conceptually a good idea but seems to have a ropey implementation :-/
[17:00] <cjwatson> So sbuild hasn't put the .orig in there.  Could I maybe see the full output of your sbuild command?
[17:01] <cjwatson> Not sure what to do if you told it to force and it ignored you, but let's see
[17:01] <realtime-neil> doing it like this: `gbp buildpackage --source --source-only-changes --force-orig-source --debbuildopt=--buildinfo-option=-O`
[17:01] <cjwatson> You changed tools without telling me? :-(
[17:01] <cjwatson> --force-orig-source is an option to sbuild
[17:02] <realtime-neil> because I have a gbp.conf telling buildpackage.builder = sbuild
[17:02] <cjwatson> Yeah but you specifically said you were using "sbuild --source --source-only-changes" so I assumed you were still using sbuild directly
[17:02] <cjwatson> Basically you need to get the -sa option passed through to dpkg-buildpackage
[17:02] <cjwatson> Do that in whatever way is appropriate to the tool you're using
[17:03] <realtime-neil> shucks; so this is a case of gbp injecting options into the sbuild invocation that are incompatible with launchpad?
[17:03] <cjwatson> Or maybe it's failing to inject options that are necessary
[17:04] <cjwatson> Fundamentally Launchpad needs a copy of your .orig.tar.xz if you expect it to be able to build anything
[17:04] <cjwatson> That would be true of any upload target.  gbp may be leaving dpkg-buildpackage to guess from the version number that the .orig isn't required
[17:04] <cjwatson> dpkg-buildpackage's -sa option exists to override that behaviour
[17:05] <cjwatson> So I'm afraid I'm not a "gbp buildpackage" user so I don't know exactly how to pass it through, but hopefully with that information you can work it out?
[17:05] <realtime-neil> still digesting ... reading man pages
[17:06] <realtime-neil> maybe another --debbuildopt is in order
[17:06] <realtime-neil> namely --debbuildopt=-sa
[17:10] <cjwatson> Worth a try
[17:29] <realtime-neil> cjwatson: Is this something that can be diagnosed via the *.changes file? Is there something in there I can use to know if launchpad will reject it?
[17:30] <cjwatson> realtime-neil: If the .orig isn't in the target archive already, then it needs to be mentioned in the .changes
[17:30] <cjwatson> realtime-neil: It's not diagnosable solely from the state of the .changes because it also depends on the state of the target archive (though always including the .orig is OK, just wasteful of bandwidth)
[17:33] <realtime-neil> Okay, got it. All of the valid  *.changes I've created mention the *.orig.tar*, so that's a good indicator for me.
[18:38] <realtime-neil> Welp that was exhausting. Here's what gbp with a `buildpackage.builder=sbuild` needs to create a `*_source.changes` WITH an origtar and WITHOUT buildinfo:   `gbp buildpackage --no-arch-any --no-arch-all --source --debbuildopt=-sa --debbuildopt=--buildinfo-option=-O`
[18:38] <realtime-neil> Which launchpad has just accepted.
[20:27] <cjwatson> realtime-neil: Glad it worked in the end.  I do wonder what all the extra layers of abstraction actually add and if just using debuild -S -sa (maybe with -nc) would've been easier ...
[20:28] <realtime-neil> cjwatson: concur --- just about the only work gbp is saving me is the generation and placement of the origtar
[20:29] <cjwatson> (I do appreciate that if building your source package involves non-trivial use of build-dependencies then it can be convenient to do that in a chroot.  I normally try to just avoid my source packages needing that property, but sometimes there's no reasonable alternative)
[22:44] <juliank> Has anyone suggested adding attachments to merge proposals yet?
[22:45] <juliank> I was just reviewing one and wanted to attach data, and ended up going with a github gist