Comment 22 for bug 2060732

About the noble dep8 failures, check this conversation from irc in #ubuntu-devel:

https://irclogs.ubuntu.com/2024/05/21/%23ubuntu-devel.html#t15:53

<paride> ahasenack, did that happen more than once?
<paride> ahasenack, not that once is ok
<ahasenack> yes, in multiple architectures
<ahasenack> https://autopkgtest.ubuntu.com/packages/s/software-properties/noble/amd64 for example
<paride> ahasenack, I just reproduced it locally
<ahasenack> 0.99.48 extracted fine with apt-get source here, noble
<paride> it tries to download a different version:\
<paride> apt-get source -d -q --only-source software-properties=0.99.48.1
<paride> and this fails: E: Can not find version '0.99.48.1' of package 'software-properties'
<ahasenack> where is 0.99.48.1 coming from?
<ahasenack> noble has 0.99.48, and noble-proposed has 0.99.49
<paride> ahasenack, checking
<ahasenack> juliank: do you know something abouv this? I vaguely remember a comment from you in an SRU that mfo was checking
<juliank> paride, ahasenack So it gets confused by software-properties-qt temporarily existing in its own source package in a 0.99.48.1
<juliank> Well I say temporarily but that is in the release pocket
<juliank> and it seems to use that to determine the version of software-properties source package to download
<paride> I wonder if some changes I introduced locally to the "find source package to download" algorithm would work better
<ahasenack> why would a different source package interfere here?
<ahasenack> just because it's a substring match?
<juliank> ahasenack: autopkgtest tries to find out the source version to download but it looks at the wrong binary package
<paride> ahasenack, it is not that simple
<juliank> something like that
<paride> ahasenack, let me test from master, i.e. with https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/324 merged in
<ahasenack> paride: ok
<paride> ahasenack, still fail, same failure mode
<paride> *fails