On Mon, Oct 13, 2025 at 04:26:15PM +0200, Carsten Schoenert wrote:
Am 13.10.25 um 14:10 schrieb Colin Watson:
A fresh clone now _almost_ works, but you may have to argue with
.gitattributes; I couldn't think of anything I could do about that. I
found that the following procedure worked, though:
$ git clone https://salsa.debian.org/python-team/packages/python-odmantic.git
Cloning into 'python-odmantic'...
remote: Enumerating objects: 360, done.
remote: Counting objects: 100% (360/360), done.
remote: Compressing objects: 100% (292/292), done.
remote: Total 360 (delta 76), reused 306 (delta 44), pack-reused 0 (from 0)
Receiving objects: 100% (360/360), 259.07 KiB | 470.00 KiB/s, done.
Resolving deltas: 100% (76/76), done.
Encountered 1 file that should have been a pointer, but wasn't:
docs/img/usage_fastapi_swagger.png
$ cd python-odmantic/
$ dgit setup-gitattributes
$ git restore .
The repository has a file debian/README.source that explains how the
whole thing is handled. Kathara and I followed the suggested way to
work with gbp within the DPT and it works always flawless.
I'm familiar with how to work with gbp within the DPT, but neither the
team policy nor this document touches on the problem at hand.
(I just checked; if you don't have git-lfs installed, a simple clone
works, so it's possible that that would have worked around the problem.
But I don't expect to have to uninstall git plugins just in order to
work on a package.)
Kathara and I always did start with archives from GitHub based on the
tags, so no, it's not was made by some git checkout. Never.
You were using uscan mode=git, which does a git clone and archives the
result locally. For a tree involving git-lfs objects, the result will
probably depend on whether you had git-lfs installed or something like
that.
I changed this to use the archives provided by GitHub itself, which
don't have that problem: they resolve the git-lfs references into actual
files.
I haven't any special setup to handle a file .gitattributes and I also
don't encounter the problems you try to solve.
Here is and always was that file a "normal" file.
When I ran into the same problem myself I worked around it, but when
Santiago ran into it too on an independent system it was clear that
there was something at least a bit specialized going on, even if it was
by accident.
It wasn't just a git problem. You can tell that the file was _not_ a
"normal" file as follows:
$ tar xOf python-odmantic_1.0.2.orig.tar.gz
python-odmantic-1.0.2/docs/img/usage_fastapi_swagger.png
version https://git-lfs.github.com/spec/v1
oid sha256:8b4ce248fa26e05f17accc3bbadf995f5afb973fd0e6b50c2140fbcd49fec1d6
size 75423
That's clearly a bug. We shouldn't have objects like that in source
packages.
It seems also to me you mixing up two potential issues, one is the bug
report was about and another is the problems you see around git usage.
Not at all; I fixed separate things in separate commits, which is
normal. And the resulting git tree is identical except for the affected
file (I checked very carefully), so it really shouldn't cause a problem
for you.
The difference between the unpacked old and new tarballs is precisely
the following:
$ diff -ruN 1.0.2 1.0.2+ds1
Binary files 1.0.2/docs/img/usage_fastapi_swagger.png and
1.0.2+ds1/docs/img/usage_fastapi_swagger.png differ
$ ls -l 1.0.2/docs/img/usage_fastapi_swagger.png
-rw-r--r-- 1 cjwatson cjwatson 130 Apr 27 2024
1.0.2/docs/img/usage_fastapi_swagger.png
$ ls -l 1.0.2+ds1/docs/img/usage_fastapi_swagger.png
-rw-r--r-- 1 cjwatson cjwatson 75423 Apr 27 2024
1.0.2+ds1/docs/img/usage_fastapi_swagger.png
$ file 1.0.2/docs/img/usage_fastapi_swagger.png
1.0.2+ds1/docs/img/usage_fastapi_swagger.png
1.0.2/docs/img/usage_fastapi_swagger.png: ASCII text
1.0.2+ds1/docs/img/usage_fastapi_swagger.png: PNG image data, 1565 x 1244,
8-bit/color RGBA, non-interlaced
This is surely uncontroversially better. And for the next release, the
+ds1 wart can go away.
I also don't understand really why now a hectically work on this
package is needed. Rom wasn't build in a day!
The last time I had to work on python-odmantic, it was because of
difficult interactions with pydantic, which I had to do in a rush
because of a slightly underplanned transition not started by me.
In this case, it wasn't exactly hectic, just that nobody else had dealt
with an important bug filed on 30 September so I didn't see a problem
with going ahead and applying a fix for it while it was at the end of my
inbox. And if I could make things easier both for myself and for other
people working on the same package while I was at it, then why not?
--
Colin Watson (he/him) [[email protected]]
