Stéphane Glondu writes ("Re: Bug#1005765: dgit doesn't handle upstream files
with CRLF well"):
> I had trouble uploading opam/2.1.2-1 with dgit. Eventually, I gave up
> and did a regular upload.
>
> The commit id is 225dd4102cfd4391fab166d7cc220d020efedafd on:
>
> https://salsa.debian.org/ocaml-team/opam
Thanks. That is helpful information. I observe that:
1. In opam_2.1.2-1.dsc, appveyor_build.cmd has CRLF line endings;
2. In 225dd4102cfd4391fab166d7cc220d020efedafd it has unix line endings.
3. There is nothing in debian/patches to represent this change.
I see this:
opam$ git checkout 225dd4102cfd4391fab166d7cc220d020efedafd
HEAD is now at 225dd41 Prepare upload to unstable
opam$ dgit --gbp quilt-fixup
Format `3.0 (quilt)', need to check/update patch stack
gzip: warning: GZIP environment variable is deprecated; use an alias or script
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
examining quilt state (multiple patches, gbp mode)
dgit: base trees orig=1aba501b88d166b9b63f o+d/p=4c4f0f75326134d939d1
dgit: quilt differences: src: ## orig ## gitignores: == orig ==
dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p
dgit: error: --quilt=gbp specified, implying patches-unapplied git tree
dgit: but git tree differs from orig in upstream files.
dgit: For full diff showing the problem(s), type:
dgit: git diff 1aba501b88d166b9b63f363a1583c6b6a4ac111e HEAD -- :/ ':!debian'
':!/.gitignore' ':!*/.gitignore'
opam$ git --no-pager diff --stat 1aba501b88d166b9b63f363a1583c6b6a4ac111e HEAD
-- :/ ':!debian' ':!/.gitignore' ':!*/.gitignore'
appveyor_build.cmd | 416
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------------------------
1 file changed, 208 insertions(+), 208 deletions(-)
opam$
You said
> > I couldn't find a combination of checked-in files and git crlf
> > handling that would please both git and dgit.
You seem to be using tarball imports for your git tree. I don't know
what tool you are using for your tarball imports, but I think you need
to tell it not to convert line endings.
I don't think git converts line endings by default, so I think you
probably enabled some conversion feature. I recommend against that.
If some tool you are using (eg for your tarball imports) converted the
line endings, then I think it's a bug in that tool.
I did this experiment:
opam$ git checkout 225dd4102cfd4391fab166d7cc220d020efedafd
HEAD is now at 225dd41 Prepare upload to unstable
opam$ unix2dos appveyor_build.cmd
unix2dos: converting file appveyor_build.cmd to DOS format...
opam$ git commit -m fix appveyor_build.cmd
[detached HEAD 761e246] fix
1 file changed, 208 insertions(+), 208 deletions(-)
opam$ dgit --gbp quilt-fixup
Format `3.0 (quilt)', need to check/update patch stack
gzip: warning: GZIP environment variable is deprecated; use an alias or script
dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
examining quilt state (multiple patches, gbp mode)
dgit: base trees orig=1aba501b88d166b9b63f o+d/p=4c4f0f75326134d939d1
dgit: quilt differences: src: == orig ## gitignores: == orig ==
dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p
dgit view: creating patches-applied version using gbp pq
dgit view: created (commit id 795bce795ad5b5f6164f757b13892275968b3b05)
opam$
> > Ideally, a run with dgit -D would be helpful.
> I will try when I update the package.
(FTAOD this isn't needed now.)
> > If you have a situation that doesn't match the criteria above, but you
> > think should be able to work, and currently doesn't, please also let
> > us know.
>
> I'm not sure whether my situation matches the criteria above, but I
> guess dgit should be able to do any upload to the official Debian
> archive, shouldn't it?
dgit ought to be able to upload any source package that the archive
will accept, yes. But dgit requires that the git branch you are using
corresponds, *precisely*, to the source package. Otherwise people who
ran "dgit clone" might get a different tree to people who did "apt-get
source", for the very same upload, which would be really very bad.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
