Bug 1216738 - ERROR SOURCE_DATE_EPOCH is in the future, ..., returning error
Summary: ERROR SOURCE_DATE_EPOCH is in the future, ..., returning error
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Michael Schröder
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-31 10:30 UTC by Jiri Slaby
Modified: 2024-02-08 11:48 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Slaby 2023-10-31 10:30:54 UTC 
When build now in BS, I see a lot of failures due to:
[   13s] setting SOURCE_DATE_EPOCH to 1698749844
[   13s] ERROR SOURCE_DATE_EPOCH is in the future, clamping mtime if used might fail in hard to notice way, returning error

Like in IBS: Devel:Kernel:stable/kernel-default/standard/x86_64

Fabian says: 
It mixes up time zones
"Mon Oct 30 12:36:34 CET 2023" in .changes results in SOURCE_DATE_EPOCH=1698669395 but that's Mon 30. Oct 12:36:35 UTC 2023
Comment 1 Jiri Slaby 2023-10-31 10:37:04 UTC 
Maybe post-build-checks' fail?
Comment 2 Jiri Slaby 2023-10-31 10:42:35 UTC 
Likely related to:
https://github.com/openSUSE/post-build-checks/pull/58

A note added there.
Comment 3 Jan Zerebecki 2023-10-31 11:32:15 UTC 
Michael, it seems obs-build is adding the zone an additional time after str2time already takes it into account: https://github.com/openSUSE/obs-build/blob/5d1da8553791ecdf35ab538bddd6afa4494d66d0/changelog2spec#L159

Can you fix that? I'm not sure if removing that line is correct.
Comment 4 Jan Zerebecki 2024-01-31 14:40:58 UTC 
https://github.com/openSUSE/obs-build/pull/977
Comment 5 Michael Schröder 2024-02-08 11:48:56 UTC 
Removing the line is not correct, but I've now committed a fix.