jdv [Coke]: can't you just retar and push that up? 15:39
talking about github.com/MoarVM/MoarVM/issues/1905
[Coke] jdv? 18:50
ah 18:51
jdv: I could retar ... but it'd be with the same toolchain and have the same problems. 19:11
jdv gist.github.com/jdv/03387afb1c78d4...c20e52977c ? 19:34
that's just the mod date on the gh release - arbitrary... 19:35
maybe I'm missing something
[Coke] Guessing his version of tar is more strict and turning that warning into an error 19:36
jdv that what it sounds like 19:38
ab5tract Seems to be the presence of a TZ value 19:41
The issue made it seem far more nefarious when mentioning “negative ranges” 19:42
I think `TZ= tar ...` might work 19:46
or `set -gx TZ; tar ...`if you are using `fish` like the 90s actually happened :) 19:47
jdv how did you come to that conclusion? 19:49
ab5tract by searching for timezone in `man tar` 20:00
It's pretty clear to me that `Treating date '2025-01-25T17:46-0500' as 2025-01-25 17:46:00` is referencing a trailing TZ value 20:01
But now that I'm reading the gist on my laptop instead of a phone, I guess the source of the breakage could be separate 20:02
jdv oh, i thought you meant something to do with the original taring or the untaring person
yeah, that's just noise on my idea
ab5tract Ah, I see. No I was hoping to help [Coke] and you in fixing 20:03
jdv thanks!
[Coke] wouldn't surprise me that it's a TZ value since my original error with this was LOCALE related
ab5tract but... why is there a hidden elisp file in the moarvm directory anyway?
or should I rather not ask :)
[Coke] ? 20:05
ah. Guessing someone checked in their editor file? 20:06
dates from 2015
also an .editorconfig 20:07
ab5tract As an aside, I'm always amused (in a I-kind-of-want-to-cry kinda way) when someone running an almost 20 year old toolchain files an issue report without even mentioning it until the fourth or fifth interaction 20:12
Apparently gnutar has been dying on this issue for decades unix.stackexchange.com/a/227503
oops, wrong link
Anyway, if I was using a bespoke platform, I'd at least google for the apparent answer on my end before filing the issue. Apparently `--warning=no-timestamp` should fix it 20:17
[Coke] yah, that version of gnutar was released in 2007 20:17
ab5tract: can you add that to the ticket? 20:18
ab5tract Sure thing
[Coke] We will try to avoid the warning in future releases, but I don't think we need to make a tarball for this particular case.
ab5tract But the other side of this is that best practices for reproducible builds is apparently zero-ing out timestamps
So it could actually be a result of all the awesome work that timo++ has been putting in 20:19
[Coke] I assumed it was because we're using some arcane tar invocation that isn't entirely portable. 20:21
(and I hope to rip that out of moarvm and use a much simpler tar option in 2025.02)
ab5tract Might be.. but I found the fix in a quite recent issue report from opensearch where this has apparently been introduced by following gradle recommendations for build reproducibility 20:24
[Coke] Please feel free to add notes to this ticket or the linked one. 20:25
if there are other changes we should be making to the tar command in moarvm, need to do something similar for nqp/rakudo
ab5tract issue updated 20:26
timo the changes related to reproducibility of builds does not include anything with taring, those parts are handled for us by things like the debhelpers invoked by the debian/control scripts, and those aren't in the upstream moarvm repo at all 23:18
ab5tract timo: ah, got it. looks like we've got some delving yet to do 23:32
ab5tract recently found out that his love of the world delving is symptomatic of being an absolute robot
*word

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!