Hello, On Mon 28 Dec 2020 at 12:08PM GMT, 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.
>
>> 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?
>
> 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.
It can't distinguish between stuck in some dak queue vs. actually
rejected, though?
>> 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?
>
> 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 think the solution has to involve dgit push messing about with
> pristine-tar to send a pristine-tar branch to dgit-repos :-/.
I must be missing something here, because I don't see why the rejected
orig.tar is needed. apt-get source will get you the orig.tar for the
version actually in the archive, which is what you want to base your
work off?
--
Sean Whitton
signature.asc
Description: PGP signature
