Hi Ian, Sean,
On 28-12-2020 13:08, Ian Jackson wrote:
> Sean Whitton writes ("Bug#977845: dgit: unhelpful behavior in case previous
> upload contained new upstream release"):
>> On Mon 21 Dec 2020 at 09:01PM +01, Paul Gevers wrote:
>>> In the end I resorted to
>>> paul@mulciber ~/packages/bugs $ dgit clone f2fs-tools testing
>>> as unstable and testing have the same version, but that doesn't work if
>>> unstable and testing don't have the same version.
>>
>> In this situation what it seems we want to achieve is
>>
>> a) get the version you want to hack on into dgit as if `dgit clone` had
>> given it you
>>
>> b) make it easy to `dgit push` your new version, which is based on the
>> result of (a).
>
> The problem is that in this situation the person who uses dgit clone
> does not get the orig tarball and has no systematic way to find it.Indeed. And the fact that I didn't expect to get a version that's not in the archive. Yes, there's a message, but it's buried in other output. Also, for NMU's, I think it's more natural to work on the version in the archive, not a version that's uploaded but didn't appear (yet) in the archive. But I think Sean is suggesting to make sure I also get something like "dgit clone XXX unstable", i.e. I can tell dgit to make sure I get something that reflects unstable, even though a later upload with dgit happened. >> However, detecting whether an upload made it to the archive would >> require incorporating a lot of idiosyncratic knowledge about dak into >> dgit, I think, with a fair bit of guessing? Or is the way that dak >> keeps track of such things amenable to adding a new ftp-master API query >> to find out? Without knowledge, yes, a fair bit of guessing I think. I have no knowledge of dak on this front. > dgit clone already knows this situation has arisen, because it can see > that the version in git is newer than the version in the archive. Exactly, it even tells me so (after I went back and read the output). However, what dgit could do in such a case is create a local situation that has both the situation in the archive >> In the meantime what I would have done is `apt-get source` followed by >> `dgit import-dsc` followed by pseudomerging in the result of `dgit fetch >> unstable`. What do you think about the error message suggesting that >> for this sort of situation? I'm getting around with git, but you'd have to explain quite literally how to get there, as it's unclear to me what "pseudomerging" means. > That wouldn't work either, because apt-get source doesn't have access > to the orig tarball. > > The original uploader had the orig tarball. dgit push sent it to the > archive. But I think if the upload was REJECTed (or dcut or > something), the archive doesn't have it any more. I don't think > ftpmaster keep uploaded things that don't end up in the archive. > (Please correct me if I'm wrong.) I'm not sure, but I think you're right. Paul
OpenPGP_signature
Description: OpenPGP digital signature
