On Wed, 13 Nov 2024 at 16:48, "Gaël PORTAY via lists.openembedded.org
<gael.portay=gmail....@lists.openembedded.org> wrote:
>
> Alex,
>
> On Tue Nov 12, 2024 at 9:22 PM CET, Alexander Kanavin wrote:
> > I'm sorry, this was probably already covered and I'm just forgetful,
> > but why not do this in do_install?
> >
>
> It was initially performed by a rootfs post-command to mimic what does
> rootfs_update_timestamp() but for systemd. And you argued it is recipe
> specific and should not be a rootfs post-command.
>
> The idea was to create the file at image creation time in order to set a
> better date than the one hardcoded in the systemd binary (taken from the
> date of the tag IIRC).
>
> Also, playing with the variable $REPRODUCIBLE_TIMESTAMP_ROOTFS for the
> reproducible-builds (kirkstone, scarthgap).
>
> Note: Obviously, it is now the variable $SOURCE_DATE_EPOCH_FALLBACK to
> play with on the master branch.
>
> Peter suggested to move it to pkg_postinst:${PN} so the file is created
> at image creation time.
This is partly on me, for not paying enough attention to the mailing
list, but our use case for the
set-time-epoch PACKAGECONFIG (and time-epoch before it) is because we
have a requirement
that the system *always* boot with the time set to the epoch. This
change breaks that case, but
otherwise this seems like a reasonable change. How do people feel
about wrapping the pkg_postinst
append in this patch inside a PACKAGECONFIG check? Something like
pkg_postinst:${PN}:append () {
if ${@bb.utils.contains('PACKAGECONFIG', 'set-time-epoch', 'true',
'false', d)}; then
touch $D${libdir}/clock-epoch
fi
}
>
> > Alex
> >
>
> Regards,
> Gaël
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#207398):
https://lists.openembedded.org/g/openembedded-core/message/207398
Mute This Topic: https://lists.openembedded.org/mt/109541328/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
