The package fails to build reproducible. The most striking thing when running
diffoscope is that fontforge writes the timestamp of the Creation time into
(e.g. afm) files:

ille@haka2:~/t2/debian/output/reprotest/control/source-root$ diff -i -u
bkaiu02.afm /home/hille/t2/debian/output/reprotest/experiment-1/source-
root/bkaiu02.afm
--- bkaiu02.afm 2025-11-25 19:23:00.000000000 +0100
+++ /home/hille/t2/debian/output/reprotest/experiment-1/source-root/bkaiu02.afm
2025-11-25 19:23:00.000000000 +0100
@@ -1,6 +1,6 @@
 StartFontMetrics 2.0
 Comment Generated by FontForge 20230101
-Comment Creation Date: Wed Nov 26 08:23:11 2025
+Comment Creation Date: Tue Nov 25 06:23:11 2025
 FontName bkaiu02
 FullName AR PL KaitiM Big5 02
 FamilyName AR PL KaitiM Big5
@@ -10,8 +10,8 @@
 Comment Subfont version 2025-11-25.
 ItalicAngle 0
 IsFixedPitch true
-UnderlinePosition -96,6797
-UnderlineThickness 48,8281
+UnderlinePosition -96.6797
+UnderlineThickness 48.8281
 Version 2.10
 EncodingScheme FontSpecific
 FontBBox -12425 -6536 7690 22253

For the second difference I don't see an explanation. For now I did not find an
option in FF to tweak the Creation time (except post processing).

Hilmar

Thanks, Hilmar.  Let me see if I can fix this.

Cheers,

Thanks, Hilmar.  Let me see if I can fix this.

Cheers,

Okay, mental note #1:
With "debuild" (without parallel jobs) I am getting the same AFM font
content with each build (and I did 3x):

The funny thing is that the creation date is always from 26 Nov 2025 at
exactly 02:23:11, even though today we are 27 Nov 2025 (even accounting for
timezone differences).
On my Debian/testing workstation I upgraded the package `devscripts', so
maybe that's got something to do with it.  Or it's some variable in my
terminal session under alacritty/zellij/zsh.

Let me try on pbuilder next.

On 11/27/2025 6:26 AM, Danai SAE-HAN (韓達耐) wrote:

Hello,

I just inspected just the deb packages, which were in the artifact of
Salsa CI.
The files are meanwhile deleted on the server, so the test needs to be
re-enabled to get a new set.

Hilmar

Mental note #2: the difference between both of Hilmar's AFM files is
exactly 26 hours, up to the second.
for Anglo-Saxon, and a comma for continental European countries.
Funny, I would have guessed that the AFM format always uses locale C (and
therefore a dot) and that FontForge would stick to a dot.

@@ -10,8 +10,8 @@
 Comment Subfont version 2025-11-25.
 ItalicAngle 0
 IsFixedPitch true
-UnderlinePosition -96,6797
-UnderlineThickness 48,8281
+UnderlinePosition -96.6797
+UnderlineThickness 48.8281
 Version 2.10
 EncodingScheme FontSpecific
 FontBBox -12425 -6536 7690 22253

I suspect a clock issue, and a locale issue.

Cheers,

18:23:11 2025 (in UTC).
Strange why Fontforge keeps using that particular time.

Anyway, I'm playing with the flag "no-FFTM-table" (see #1).  Maybe it
helps, maybe not.  We also have some upstream bug reports about this
annoying behaviour (see #2).

#1: https://github.com/fontforge/fontforge/pull/4320/commits
#2: https://github.com/fontforge/fontforge/issues/2711

Cheers,

On 11/27/25 17:27, Danai SAE-HAN (韓達耐) wrote:

Hello Danai,

Maybe just using SOURCE_DATE_EPOCH is enough (by just scrolling through [1].
And for the locale differences: it might by enough to set a well defined
locale during build (whichever generates the correct results...).

Hilmar

[1] https://github.com/fontforge/fontforge/issues/2490

Thanks, Hilmar.
Exporting SOURCE_DATE_EPOCH and LOCALE work in debian/rules.
We could just have an empty SOURCE_DATE_EPOCH variable, so it's always set
to epoch time:

But I think that's a bit ugly, and may perhaps cause weird results for
other parts that rely on this variable.
One suggestion from [1] is to use the latest timestamp in
debian/changelog.  I find this a good alternative.
We always have to close debian/changelog anyway, so we will always have a
proper timestamp, even in the event
of an unreleased build.

$ dpkg-parsechangelog -S timestamp
1764094991

Therefore I'd like to implement LOCALE=C, and SOURCE_DATE_EPOCH with the
latest timestamp of
debian/changelog.
What do you think?

[1] https://reproducible-builds.org/specs/source-date-epoch/


Cheers,

On 11/28/2025 6:14 AM, Danai SAE-HAN (韓達耐) wrote:

Hello Danai,
According to that web page

<snip>
In Debian, this is automatically set to the same time as the latest
entry in debian/changelog, i.e. the same as the output of
dpkg-parsechangelog -SDate.

1. For packages using debhelper versions >= 9.20151004, this variable is
automatically exported during builds, so you probably don’t need to
change anything. One exception is if your debian/rules needs this
variable in non-debhelper parts, in which case you can try (3) or (4).
<snip>

So I would have expected that everything is fine. I did not check if
SOURCE_DATE_EPOCH has a sane value during build.

I'm unsure about the locale, but LOCALE=C sounds reasonable in any way.

Please be aware that I've enable Salsa CI for that package. So every
"git push" triggers a Salsa CI run, unless you prepend the commit
message with "[skip-ci]".

Hilmar

Hi Hilmar,

Yeah, right after I sent that message I figured out the SOURCE_DATE_EPOCH
mechanism in Debian.  #retract

As for locale, I will add "LC_ALL".  But before I commit, can I check what
your build toolchain on your local environment looks like?

Could you also run:
  sudo pbuilder create --debootstrapopts --variant=buildd --distribution
unstable
  sudo pbuilder build latex-cjk-chinese-arphic_2.3.dsc
  dpkg --fsys-tarfile
/var/cache/pbuilder/result/latex-cjk-chinese-arphic-bkai00mp_2.3_all.deb |
tar -xO ./usr/share/texmf/fonts/afm/arphic/bkaiu/bkaiu02.afm > bkaiu02.afm

Then check the contents of bkaiu02.afm again?

Thanks.

P.S.: I'm browsing through a thread on the DD mailing list that touches on
this very subject of reproducibility and LC_ALL (no resolution though):
https://lists.debian.org/debian-devel/2024/06/threads.html#00033

Am 29.11.2025 um 08:16 schrieb Danai SAE-HAN (韓達耐):

Hello,
Sorry, for not answering. I'm quite busy these days.

H.

No worries, I think I've found the culprit for the timezone.  Ignore the
steam of branch updates on Salsa, but the CI/CD pipeline seems fixed now.
I'll do a cleanup later.

Cheers,