[09:39] <Rhonda> I have issues uploading a SRU for fastapi.  I prepared it according to timelines.  When uploading source-only I get a reject saying "Mismatch in binaryfulness."  I assume that means I need to upload the binary too.  When I try that dput doesn't allow me to push: "There are .debs in this upload, and enforcing they don't exist."
[10:36] <ginggs> Rhonda: hi!  we never can upload binaries to ubuntu.  is it perhaps a mismatch between what's in your .dsc and .changes files?  could you pastebin them somewhere?
[10:48] <Rhonda> ginggs: https://paste.debian.net/1290233/
[10:50] <Rhonda> ginggs: and the .dsc: https://paste.debian.net/1290234/
[10:51] <Rhonda> ah wait, one moment
[10:52] <Rhonda> That's a different dsc than I uploaded, because that's from the build with source.
[10:52] <Rhonda> I think I don't have the other file anymore because it overwrites it in my spool dir because the name is the same for the .dsc
[10:56] <Rhonda> Guess I have to check again when I have access to my gpg key and the build environment at the same time.
[10:58] <ginggs> ok.  what command did you run to "build" the source package?
[11:04] <Rhonda> Oh. Wait. I think … I think the _source.changes file is just some by-product of cowbuilder --build.  I didn't explicitly ask for the source changes, so the .dsc was then overwritten by the binary build.  But what confuses me now, why does the source .dsc file *at all* has the architecture field, or has that recognized and compared with the _source.changes entry?
[11:05] <Rhonda> That it's in the .dsc doesn't make any sense because that's the source package description, but I think it's in there as hint to the build servers.  But why is that compared between the .changes and the .dsc?  That's confusing.
[11:08] <Rhonda> Or am I thinking in the wrong direction?
[11:10] <Rhonda> Might it be the .buildinfo file?  Is that an issue for ubuntu?
[11:11] <Rhonda> Because that obviously is arch specific.
[11:19] <Rhonda> A github comment hinted that the .buildinfo file might be the issue.  Will try again with stripping that one out.
[11:28] <ginggs> i don't have a problem uploading .buildinfo files to ubuntu
[11:31] <Rhonda> Maybe jammy didn't support them yet?
[11:38] <RikMills> buildinfo file for an uplaod should not be arch specific
[11:42] <Rhonda> RikMills: They always are arch specific because they contain arch specific build environment versions
[11:42] <RikMills> should be just be _source.buildinfo rather than _amd64.buildinfo
[11:42] <RikMills> then you are not preparing the upload properly
[11:42] <Rhonda> Your build environment always has an architecture.
[11:43] <RikMills> but a source upload does not
[11:43] <Rhonda> That's correct.
[11:43] <Rhonda> Well, it though still does.
[11:43] <Rhonda> You are building the source package still in some environment - which has an architecture.  It's not created out of thin air.
[11:44] <Rhonda> The toolchain you use, including dpkg out of it all, is architecture dependent.
[11:44] <RikMills> obviouly, but the resulting files should not reference that
[11:45] <Rhonda> Then you might miss significant information out of the buildinfo file for which it specifically was created.
[11:45] <RikMills> https://paste.ubuntu.com/p/tS36kRrKgh/
[11:45] <RikMills> ^^ my last archive upload
[11:46] <RikMills> debuild -S -sa in the source dir results in that
[11:46] <Rhonda> What's the content of that buildinfo file?
[11:46] <RikMills> 2 secs
[11:47] <Rhonda> For debuild I would need to have all the build-depends installed in my regular environment.
[11:48] <ginggs> Rhonda: -nc
[11:48] <RikMills> https://paste.ubuntu.com/p/zfMXKx8Vrq/
[11:49] <RikMills> -d  "Do not run dpkg-checkbuilddeps to check build dependencies."
[11:50] <Rhonda> -d doesn't work because my package at hand still would need python3 for the clean target.  -nc did the trick though.
[11:51] <Rhonda> RikMills: So that "Build-Architecture: amd64" is not an architecture dependent entry in that file?
[11:52] <RikMills> it should be "Build-Architecture: source" for an archive upload
[11:52] <Rhonda> That doesn't work.
[11:53] <Rhonda> And you don't have an Installed-Build-Depends field in there?  That's interesting.
[11:53] <RikMills> sorry, yes Build-Architecture: amd64 is there and fine for the
[11:54] <Rhonda> So yes, it's architecture dependent.
[11:54] <RikMills> I did not paste the whole installed build depends bit there
[11:54] <Rhonda> I know that Ubuntu doesn't do binary NMUs like Debian does, but the version list of the installed packages is practically architecture dependent.
[11:54] <RikMills> it should not be in name
[11:55] <Rhonda> So that buildinfo file isn't detachable from the architecture you build it on, practically and by design
[11:55] <RikMills> as said you should enbd up with a _source.buildinfo
[11:56] <Rhonda> Seemingly, but then I rather strip it out for the upload than tweak the changes file after my test build manually.
[11:57] <Rhonda> … I mean I have to touch it manually regardless.
[11:58] <RikMills> if you are building the sources for upload correctly, it should not need anything doing apart from uploading
[11:59] <Rhonda> … whatever.
[12:00] <Rhonda> I don't think I build them not correctly.  My worflow just seems to differ from yours, but that doesn't necessarily make it incorrect.
[12:00] <Rhonda> Calling an architecture dependent buildinfo file _source is something I don't really consider correctly, frankly speaking
[12:01] <RikMills> it is a source upload
[12:01] <Rhonda> So?
[12:01] <Rhonda> That doesn't make the buildinfo less architecture dependent.
[12:03] <RikMills> it is only a reference to the arch it was prepared on, it is still a source only upload
[12:03] <Rhonda> I don't deny that it's a source only upload.
[12:05] <Rhonda> The buildinfo is -- regardless of whether it is a source-only upload or not -- an inherently architecture dependent information. By. Design.
[12:06] <RikMills> you should still end up with a _source.buildinfo no matter that
[12:06] <Rhonda> That's what the archive tools seem to enforce and require indeed.
[12:06] <Rhonda> … even though it does make little sense.
[12:07] <Rhonda> But I'm fine with that, I can adapt to it now that I know that that's the reason for the reject.
[12:08] <RikMills> fair enough. as long as you can produce the source files like that then fine :)
[12:09] <RikMills> never had an issue my way, so obviously I stick to it
[12:10] <Rhonda> Hey, I needed a while to get used to using debhelper for my packages.  Maybe I can get used to adapt my general workflow too.  But first things first, we have a package here that is completely broken in jammy and noone got around to fix it yet for good.