[FFmpeg-devel] rebase bugs?

[Kacper Michajlow]

On Sat, 9 Aug 2025 at 01:29, Michael Niedermayer <michael at niedermayer.cc> wrote:
>
> On Fri, Aug 08, 2025 at 08:18:43PM -0300, James Almer wrote:
> > On 8/8/2025 8:09 PM, Michael Niedermayer wrote:
> > > git log --grep "Clear state on alloc" origin/master  --oneline
> > > 85a2beaa811 avcodec/ffv1: Clear state on alloc
> > > 70fc46d1856 avcodec/ffv1: Clear state on alloc
> >
> > Yeah, that's not good. The second commit is an empty duplicate.
>
> but how did this happen ?
>
> the webpage lists 70fc46d185 (https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20134)
> is this some sort multithreading feature where it spwns independant workers
> for each and then maybe end up with 2 for one pr ? iam just speculating i have
> not looked at one single line of forgejo code
>
> if thats the case it should have stoped when it realized the comits are empty

Hard to guess what has happened. But it definitely looks like Forgejo
"merged" this PR twice and the 2nd time it applied empty commits.

It looks really amateur on this side of Forgejo. Not only the race
condition (probably) that executed merge twice, but also allowing
empty commits by default, which git normally warns about. Forgejo
should abort at this point... or never do it twice.

Quite surprising, because this is a very basic scenario and we are
already finding bugs. This is also why my initial intuition in the
GitLab vs Forgejo discussion was that GitLab is battle tested and in a
corporate environment, things like that would never happen in more
mature software. But that's a discussion for another mail thread, my
list of forgejo issues is getting longer and longer...

> >
> > >
> > > also not signed, not even with forgejos key:
> > It only signs commits if they were signed in the PR prior to rebasing, i
> > think.
>
> git log fforge/pr/20134 -2 --show-signature
> commit a99fa230adbe52504e6fadc1a3f85b5c30154349 (fforge/pr/20134, fforge-michaelni/ff-tmp-uninit-ut-vlc-ffv1)
> gpg: Signature made Thu 07 Aug 2025 06:33:14 PM CEST
> gpg:                using EDDSA key DD1EC9E8DE085C629B3E1846B18E8928B3948D64
> gpg: Good signature from "Michael Niedermayer <michael-git at niedermayer.cc>" [ultimate]
> gpg:                 aka "Michael Niedermayer (key used for git commits) <michael at niedermayer.cc>" [ultimate]
> Author: Michael Niedermayer <michael at niedermayer.cc>
> Date:   Wed Aug 6 13:36:06 2025 +0200
>
>     avcodec/ffv1: Clear state on alloc
>
>     Fixes: use of uninitialized memory
>     Fixes: 428969823/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_DEC_fuzzer-5909681623334912
>
>     Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>     Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>
> commit 006125030a0c360539c615fa6b5881c9bd78e637
> gpg: Signature made Thu 07 Aug 2025 06:33:13 PM CEST
> gpg:                using EDDSA key DD1EC9E8DE085C629B3E1846B18E8928B3948D64
> gpg: Good signature from "Michael Niedermayer <michael-git at niedermayer.cc>" [ultimate]
> gpg:                 aka "Michael Niedermayer (key used for git commits) <michael at niedermayer.cc>" [ultimate]
> Author: Michael Niedermayer <michael at niedermayer.cc>
> Date:   Wed Aug 6 13:09:26 2025 +0200
>
>     avcodec/utvideodec: Set B for the width= 1 case
>
>     Fixes: use of uninitialized meory
>     Fixes: 428034093/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-6195630160805888
>
>     Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>     Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>

As far as I've seen Forgejo is only able to sign commits that it
produced, like when you create an initial community or edit something
in web ui.

I've tested a few days ago and neither rebases, nor merge commits were
signed by Forgejo and instead all signatures are stripped.

And this happens even though Forgejo explicitly says besides the
"merge" button, that commit will be signed by key <path>. Never seen
this work.

> btw: (not sure thats the same issue or a genuine typo, its not empty seem like a genuine typo)

Yes, this is my bad, sorry.

- Kacper