Hello Peter,
On Tue Oct 22, 2024 at 8:40 PM CEST, Peter Kjellerstedt wrote:
> > I have created a rootfs-postcommand to be able to set a better time **at
> > image creation** to keep the systemd package untouched (not rebuilt) by
> > updateing the variable $REPRODUCIBLE_TIMESTAMP_ROOTFS.
>
> Can't you add a pkg_postinst:${PN} function to the systemd recipe and that
> way do it in the recipe while stile executing it at image creation time?
>
Well, that is certainly doable indeed; I have not think about it. Very
good catch, I will give a try, thanks.
To be honest, my first intention was to reuse the existing bits (i.e.
rootfs_update_timestamp) that is there already, and I wanted to make
this existing bits working with systemd as well :)
---
I am openning a parenthesis...
As I said, the variable $REPRODUCIBLE_TIMESTAMP_ROOTFS is to be used for
rootfs (i.e. image) only, am I right?
But it is used to compile the kernel... see:
-
https://git.yoctoproject.org/poky/tree/meta/classes-recipe/kernel.bbclass#n371
-
https://git.yoctoproject.org/poky/tree/meta/classes-recipe/kernel.bbclass#n427
The change was introduced a long time ago (2017-08-16 00:03:15 +0100):
-
https://git.yoctoproject.org/poky/commit/?id=55e9485735ae8393b410f30973c785236dc402d2
I think the kernel should (now) default to SOURCE_DATE_EPOCH_FALLBACK if
SOURCE_DATE_EPOCH cannot be deduced from the git repository.
That fallback variable was introduced afterward:
-
https://git.yoctoproject.org/poky/commit/?id=7e9c2f33d4ea9f6449dd56d19ff4522a9ddc2df1
But this is another story; parenthesis closed.
---
The worst thing is I figured out today my work does not work on master
branch; there must be changed since kirkstone that break it.
On kirkstone, stat() /usr/lib/clock-time at run-time returns same mtime
timestamp value than the one set in $REPRODUCIBLE_TIMESTAMP_ROOTFS.
On master, stat() /usr/lib/clock-time at run-time **DOES NOT** returns
the mtime timestamp value set in $REPRODUCIBLE_TIMESTAMP_ROOTFS.
It returns the values set in $SOURCE_DATE_EPOCH_FALLBACK instead! And
for every timestamp values, see:
root@qemux86-64:~# stat /usr/lib/clock-epoch
File: /clock-epoch
Size: 0 Blocks: 0 IO Block: 1024 regular
empty file
Device: fd00h/64768d Inode: 17 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-04-05 23:00:00.000000000 +0000
Modify: 2011-04-05 23:00:00.000000000 +0000
Change: 2011-04-05 23:00:00.000000000 +0000
The variable REPRODUCIBLE_TIMESTAMP_ROOTFS was set to "4000000000":
root@qemux86-64:~# cat /etc/timestamp
20961002070640
According to https://www.epochconverter.com, timestamp 4000000000 is
Tuesday, October 2, 2096 7:06:40 AM:
Supports Unix timestamps in seconds, milliseconds, microseconds and
nanoseconds.
Assuming that this timestamp is in seconds:
GMT: Tuesday, October 2, 2096 7:06:40 AM
Your time zone: Tuesday, October 2, 2096 9:06:40 AM GMT+02:00 DST
Relative: In 72 years
Therefore, the REPRODUCIBLE_TIMESTAMP_ROOTFS is set properly, but the
reproducible-builds resets the timestamp to $SOURCE_DATE_EPOCH_FALLBACK.
Is it the expected behaviour? I mean having the file timestamp created
before the binary is compiled (certainly yes, reproducible-builds) and
before the sources are actually released (maybe no)? or is it a bug :/
I have to **REDO** the test to ensure what I am telling is true for the
kirkstone branch; but I would not be able to do it before next week or
two (unless I found some free time to test it).
Note: IIRC, the files are created at the real date on kirkstone branch,
but I am not sure (i.e. do not use any reproducible-build variables).
> > +
> > + if [ -x /lib/systemd/systemd ]; then
>
> Umm, why are you looking at the host's files?
>
Oops, thas was a just snippet written on-the-fly for the post; So yes I
forgot to prefix the files ${IMAGE_ROOTFS}.
> > + if [ -x /lib/systemd/systemd ]; then
> > + ln -sf /etc/timestamp /usr/lib/clock-epoch
>
> This too is trying to create a link in the host's filesystem.
Indeed.
>
> //Peter
Regards,
Gaël
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#206181):
https://lists.openembedded.org/g/openembedded-core/message/206181
Mute This Topic: https://lists.openembedded.org/mt/109095282/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
