[09:39] 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] 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] ginggs: https://paste.debian.net/1290233/ [10:50] ginggs: and the .dsc: https://paste.debian.net/1290234/ [10:51] ah wait, one moment [10:52] That's a different dsc than I uploaded, because that's from the build with source. [10:52] 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] Guess I have to check again when I have access to my gpg key and the build environment at the same time. [10:58] ok. what command did you run to "build" the source package? [11:04] 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] 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] Or am I thinking in the wrong direction? [11:10] Might it be the .buildinfo file? Is that an issue for ubuntu? [11:11] Because that obviously is arch specific. [11:19] A github comment hinted that the .buildinfo file might be the issue. Will try again with stripping that one out. [11:28] i don't have a problem uploading .buildinfo files to ubuntu [11:31] Maybe jammy didn't support them yet? [11:38] buildinfo file for an uplaod should not be arch specific [11:42] RikMills: They always are arch specific because they contain arch specific build environment versions [11:42] should be just be _source.buildinfo rather than _amd64.buildinfo [11:42] then you are not preparing the upload properly [11:42] Your build environment always has an architecture. [11:43] but a source upload does not [11:43] That's correct. [11:43] Well, it though still does. [11:43] You are building the source package still in some environment - which has an architecture. It's not created out of thin air. [11:44] The toolchain you use, including dpkg out of it all, is architecture dependent. [11:44] obviouly, but the resulting files should not reference that [11:45] Then you might miss significant information out of the buildinfo file for which it specifically was created. [11:45] https://paste.ubuntu.com/p/tS36kRrKgh/ [11:45] ^^ my last archive upload [11:46] debuild -S -sa in the source dir results in that [11:46] What's the content of that buildinfo file? [11:46] 2 secs [11:47] For debuild I would need to have all the build-depends installed in my regular environment. [11:48] Rhonda: -nc [11:48] https://paste.ubuntu.com/p/zfMXKx8Vrq/ [11:49] -d "Do not run dpkg-checkbuilddeps to check build dependencies." [11:50] -d doesn't work because my package at hand still would need python3 for the clean target. -nc did the trick though. [11:51] RikMills: So that "Build-Architecture: amd64" is not an architecture dependent entry in that file? [11:52] it should be "Build-Architecture: source" for an archive upload [11:52] That doesn't work. [11:53] And you don't have an Installed-Build-Depends field in there? That's interesting. [11:53] sorry, yes Build-Architecture: amd64 is there and fine for the [11:54] So yes, it's architecture dependent. [11:54] I did not paste the whole installed build depends bit there [11:54] 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] it should not be in name [11:55] So that buildinfo file isn't detachable from the architecture you build it on, practically and by design [11:55] as said you should enbd up with a _source.buildinfo [11:56] Seemingly, but then I rather strip it out for the upload than tweak the changes file after my test build manually. [11:57] … I mean I have to touch it manually regardless. [11:58] if you are building the sources for upload correctly, it should not need anything doing apart from uploading [11:59] … whatever. [12:00] 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] Calling an architecture dependent buildinfo file _source is something I don't really consider correctly, frankly speaking [12:01] it is a source upload [12:01] So? [12:01] That doesn't make the buildinfo less architecture dependent. [12:03] it is only a reference to the arch it was prepared on, it is still a source only upload [12:03] I don't deny that it's a source only upload. [12:05] The buildinfo is -- regardless of whether it is a source-only upload or not -- an inherently architecture dependent information. By. Design. [12:06] you should still end up with a _source.buildinfo no matter that [12:06] That's what the archive tools seem to enforce and require indeed. [12:06] … even though it does make little sense. [12:07] 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] fair enough. as long as you can produce the source files like that then fine :) [12:09] never had an issue my way, so obviously I stick to it [12:10] 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.