Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1265928

Bug#1116866: python-odmantic: FTBFS with the nocheck build profile

Show all headers | View raw

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)                              [cjwatson@debian.org]

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1116866: python-odmantic: FTBFS with the nocheck build profile Santiago Vila <sanvila@debian.org> - 2025-09-30 17:00 +0200
  Bug#1116866: python-odmantic: FTBFS with the nocheck build profile Santiago Vila <sanvila@debian.org> - 2025-10-13 13:00 +0200
    Bug#1116866: python-odmantic: FTBFS with the nocheck build profile Colin Watson <cjwatson@debian.org> - 2025-10-13 14:40 +0200
  Bug#1116866: python-odmantic: FTBFS with the nocheck build profile Colin Watson <cjwatson@debian.org> - 2025-10-13 17:10 +0200
    Bug#1116866: python-odmantic: FTBFS with the nocheck build profile Santiago Vila <sanvila@debian.org> - 2025-10-13 17:20 +0200

csiph-web