Mattia Rizzolo writes ("Bug#910725: dgit: something eats
../foo_1.2.3.orig.tar.gz"):
> It's just a rendomly named directory. I like to keep a directory named
> the same as the package it is going to contain. So:
> ~/devel/debian/QA/mason ← random directory. I usually mkdir that
> directory, then cd in, `apt source -d $pkg` ($pkg == mason here),
> then `debcheckout -a $pkg`, or `dgit clone $pkg` in this case,
> which is going to create
> ~/devel/debian/QA/mason/mason ← git checkout of the mason package.
>
> The files that are shown there are there from previous work on that
> package, whatever that work might be.
No, I meant, what is is mason/mason. From your message the answer is
`the result of dgit clone mason' ? If that were true you wouldn't
need --include-dirty.
I want to be able to repro this bug. Can you give me a formal set of
"steps to reproduce" which start from an empty directory and use only
public data sources ?
When I file a bug that I can repro, I write `steps to reproduce' at
the same time as actually testing them. That avoids accidentally
leaving something out.
I mean, your other bug report gives me some hints about what might be
in mason/mason, but it would involve guessing which can be quite time
consuming and annoying.
Thanks,
Ian.
