Conversation
to make parsing unambiguous. Without this change, osc build mis-parsed this as another date which breaks reproducible builds
There was a problem hiding this comment.
Hi!
Thanks a lot for the requested change.
I'm not against of merging it, but I'd like to know a bit more about the rationale and/or problem before going ahead 😅
Probably due to my knowledge of OBS internals, but according to the PR description it looks a bit weird to me that only the changed WEST entry is the problematic one since there are a bunch of CEST entries in the changes file.
Moreover, there are (not too much) WEST and CEST entries across the YaST modules. See https://github.com/search?q=org%3Ayast+%22+WEST+%22+path%3A*.changes&type=code and https://github.com/search?q=org%3Ayast+%22+CEST+%22+path%3A*.changes&type=code
I've tried to find some information about the UTC requirement at OBS documentation without success. So, I wonder if it is about a bug in the OBS side or just I'm missing something.
May I ask you to provide a bit more information for a better understanding of the problem?
Thanks a lot!
|
Well, we usually create such entries with |
|
✅ Autosubmission job #12581303411 successfully finished |
|
I'm not sure how exactly it happened. What I observed was that on one machine (with And I observed it for timestamps that had an hour >12 , including one with Some other yast packages in ring1 were also affected: |
|
Here is some more detail on how it failed: I made a simple toolchain patch at openSUSE/obs-build#1047 so we don't need to patch any more .changes entries. |
|
Thanks a ton! For both, the input about the problem and the patch to fix it! ❤️ |
Convert timestamp to UTC
to make parsing unambiguous.
Without this change, osc build mis-parsed this as another date
which breaks reproducible builds