Congrats, that was a big speedup 🙂 (Benchmark 2 is the updated version.)

danilo@c3po:stepreduce$ hyperfine --warmup 3 'stepreduce-cpp/StepReduce bench/00010546_919044145dd24288a1945b5c_step_008.step /dev/null' 'stepreduce-cpp/stepreduce bench/00010546_919044145dd24288a1945b5c_step_008.step /dev/null'

Benchmark 1: stepreduce-cpp/StepReduce bench/00010546_919044145dd24288a1945b5c_step_008.step /dev/null
  Time (mean ± σ):     486.9 ms ±  23.2 ms    [User: 479.7 ms, System: 5.3 ms]
  Range (min … max):   448.6 ms … 507.3 ms    10 runs

Benchmark 2: stepreduce-cpp/stepreduce bench/00010546_919044145dd24288a1945b5c_step_008.step /dev/null
  Time (mean ± σ):      93.7 ms ±   1.0 ms    [User: 85.5 ms, System: 7.7 ms]
  Range (min … max):    91.1 ms …  96.1 ms    31 runs

Summary
  stepreduce-cpp/stepreduce bench/00010546_919044145dd24288a1945b5c_step_008.step /dev/null ran
    5.20 ± 0.25 times faster than stepreduce-cpp/StepReduce bench/00010546_919044145dd24288a1945b5c_step_008.step /dev/null

Unfortunately we can't do that. But it's good to see that the issue report already has a lot of upvotes, and that it was upgraded to P1 priority.

Hello! I'm responsible for a GitLab Premium self-hosted instance with >30 users, and we would be highly interested in either this or #464591. The use case is that we are using a CI integration that needs to be able to post comments in MRs, but we don't want to give it full api permission. Is there any way to advance this feature request?

Hello! I'm responsible for a GitLab Premium self-hosted instance with >30 users, and we would be highly interested in either this or #388829. The use case is that we are using a CI integration that needs to be able to post comments in MRs, but we don't want to give it full api permission. Is there any way to advance this feature request?

The cargo home path is embeded in the rust libs. It's /rust/cargo in your environment. Can you remove it with --remap-path-prefix?

I'll check, but that approach seems a bit brittle. In the long run, https://rust-lang.github.io/rfcs/3127-trim-paths.html would probably be the best solution. Tracking issue: https://github.com/rust-lang/rust/issues/111540

Note: Even if we'd remove the prefix, you'd still need to remap it to the same prefix in your build pipeline. Right now, /rust/cargo can be considered a stable prefix in our build pipeline.

By the way, regarding libjnidispatch.so, if you have ideas how to handle this better (e.g. by fetching and extracting it from the maven package through gradle somehow?) we're open for suggestions! Right now this seems required by JNA. (Of course the .so file is unmodified from upstream.)

I'm not sure what the issue is. We tried again and successfully reproduced the build for 5.8.0 using this process.

export VERSION=5.8.0 VARIANT=libre
export APP_ID=ch.threema.app.libre
adb pull $(adb shell pm path $APP_ID | grep "/base.apk" | sed 's/^package://') threema-extracted.apk
curl -LO https://oss.threema.ch/android/docker/docker-image-android-$VERSION.tar.gz
gunzip --stdout docker-image-android-$VERSION.tar.gz | docker image load
git clone https://github.com/threema-ch/threema-android
cd threema-android/
git checkout $VERSION
./scripts/build-release.sh -v $VARIANT -n $VERSION --no-image-export --i-accept-the-android-sdk-license
./scripts/verify-build.sh -n $VERSION -v $VARIANT -p ../threema-extracted.apk

Danilo Bargen (a82e12bf) at 01 Feb 21:14

... and 5 more commits

Case insensitive sorting of authors.

Danilo Bargen (67b18086) at 01 Feb 21:12

The APK should be available here: https://releases.threema.ch/fdroid/repo/ch.threema.app.libre-5.8.0l.apk

In case there are build issues, please see discussion above.

@linsui today I tested our process for reproducible builds (using the Docker image) and successfully reproduced version 5.8.0 (which was released recently). If there is an issue in your build pipeline, it must be a difference between your setup and our Docker based flow.

If you find things that we can adjust so that the reproducibility works for you as well, we're happy to help. But for us, the official way to reproduce the builds with identical build tool configuration is the Docker image (which is built from this Dockerfile).

Not really, I'd have to dig in more. (I'm currently on parental leave, so might be a bit slow to respond 🙂)

@linsui Update: We do build from the exported sourcecode, but before committing it. Due to a faulty .gitignore (which you already pointed out), the files were not included.

This is now fixed with an additional commit. We will probably not create a new release just for the reproducible builds, but the next regular release will probably follow within 1-2 weeks.

In the past, we got negative feedbacks for updating a tag after initial publication, so I'm wary of doing that. Would an updated tag help you to push the release, or does the commit ref work as well?

Huh, that is weird... I thought we always build from the exported (published) source, which would mean internal builds would fail as well.

Probably an issue with the build pipeline. I'll check with the team.

The old version depended on an incompatible version of pikepdf:

>>> import ocrmypdf
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    import ocrmypdf
  File "/home/danilo/Projects/docscan/venv/lib/python3.13/site-packages/ocrmypdf/__init__.py", line 10, in <module>
    from ocrmypdf import helpers, hocrtransform, pdfa, pdfinfo
  File "/home/danilo/Projects/docscan/venv/lib/python3.13/site-packages/ocrmypdf/pdfinfo/__init__.py", line 9, in <module>
    from ocrmypdf.pdfinfo.info import Colorspace, Encoding, PageInfo, PdfInfo
  File "/home/danilo/Projects/docscan/venv/lib/python3.13/site-packages/ocrmypdf/pdfinfo/info.py", line 23, in <module>
    from pikepdf import (
    ...<9 lines>...
    )
ImportError: cannot import name 'PdfMatrix' from 'pikepdf' (/home/danilo/Projects/docscan/venv/lib/python3.13/site-packages/pikepdf/__init__.py). Did you mean: 'Matrix'?

Newer version also has some OCR improvements, see https://github.com/ocrmypdf/OCRmyPDF/blob/main/docs/release_notes.rst

Danilo Bargen (e05c24ab) at 08 Jan 21:45