<farkuhar>
that issue might have nothing to do with webhooks, but if that comment exemplifies the typical gitea dev's attitude toward timestamps, it wouldn't surprise me to see similar bugs in the webhooks.
<jaeger>
I saw that issue, not sure what they meant by that
chrcav has quit [Ping timeout: 268 seconds]
pitillo has quit [Ping timeout: 268 seconds]
pitillo has joined #crux-devel
<beerman>
jaeger: what have you done to the disk space? :D
<farkuhar>
https://lists.crux.nu/pipermail/crux/2022-September/007231.html <-- I thought this kind of error during upgrade would have been prevented because setup runs pkgadd with the '--force' flag. But the report suggests that 'pkgadd -u -f' did not work as intended, at least for core/filesystem. Maybe jaeger was right to worry about opt/linux-firmware as well.
<SiFuh>
worry?
* SiFuh
looks for a thesaurus for farkuhar :-P
<beerman>
just checked two machines and who reports my logged in users just fine
<beerman>
since /var/run now is a symlink to /run it makes no sense to check for that path anymore
<beerman>
it seems like Markus has a foobared filesystem port
<farkuhar>
or Markus had /etc/pkgadd.conf preventing some necessary upgrades to the startup scripts, and he hasn't yet rejmerged them.
<beerman>
maybe
<beerman>
hard to tell without further information etc
<beerman>
i'll just send a reply when i am back home
<jaeger>
beerman: interstingly the timestamps from gitea are different now... maybe the changes to the config were correct but we had to wait for the next mirror?
<jaeger>
2022-10-02T08:33:06+02:00 for example
<beerman>
I still have absolutely no idea lol, but if it’s better now that would be great
<beerman>
The only thing i really changes was to set a default timeline
<beerman>
Timezone
<jaeger>
The only thing I can guess is that gitea relies on that setting to write the proper timestamps into the webhook json, though I have no idea why that would be the case since they worked fine elsewhere
<beerman>
Yep
<beerman>
Was my best guess really
<jaeger>
Perhaps the code for the webhook json was written by someone else
<beerman>
Probably, or it relies on go modules that needs that set or whatever. One might never know till you study the code and the code it relies on
<jaeger>
could be
<SiFuh>
Weird... pretty sure it was mentioned in #crux
<beerman>
So many possibilities, aren’t computers just great?
<jaeger>
yeah, it spilled across both channels a couple times
<beerman>
Which channel?
<beerman>
Discord?
<SiFuh>
It was more for your eyes that anyting jaeger. So what file did beerman change? Was it app.ini?
<jaeger>
no, here in IRC
<jaeger>
SiFuh: oh, do you mean the [time] section of the ini?
<SiFuh>
Yes
<jaeger>
If so, beerman had already made the change at that point and it wasn't having any effect
<SiFuh>
So not the UI line?
<jaeger>
But today it's working... so, magic! (tm)
<beerman>
Ah
<jaeger>
I'm guessing since it's mirroring the repo, not hosting it itself, past commits were not being updated but now new ones are working
<SiFuh>
This one jaeger ;DEFAULT_UI_LOCATION =
<beerman>
🪄
<jaeger>
yes. beerman had already added that at the time
<SiFuh>
And now over the course of time, without any other modifications it works?
<jaeger>
So it would seem, yeah
<SiFuh>
Thumbs up
<SiFuh>
This line was introduced later on since gitea would have an 'empty value', so chances are that line was the reason
<jaeger>
haha, so, guess what? I just tested the webhook again and the timestamp is back to empty :P
<jaeger>
So maybe it's only testing that triggers this
<jaeger>
(which I was doing a lot of yesterday)
<SiFuh>
Maybe
<beerman>
Oh lol
<jaeger>
Adding some handling code for that to the webhook, will see
<beerman>
I answered Markus mail about who not working. It should be the run directory
<jaeger>
ok
<darfo>
beerman, /var/run is not symlinked on an upgrade only on an install of 3.7
<beerman>
bummer
<jaeger>
does rejmerge not cover that?
<darfo>
not sure why beerman mentioned /var/run. I've been updating my ports to use /run. Ran into glibc /usr/include/path.h
<beerman>
I am not sure why you mention /usr/include/path.h darfo, care to elaborate?
<darfo>
Used by some wares for _PATH_VARRUN
<darfo>
which is: #define _PATH_VARRUN "/var/run/"
<darfo>
So it's a bit harder to override thats an autoconf configure option. Oh well, now stranger to diff/patch
<darfo>
s/now/no/
<darfo>
wow my finger don't type what my brain thinks: s/thats/than/
<darfo>
i like the idea that /run is cleared on a boot so changing my ports to use it. When I've got them all I'll symlink /var/run to /run.
<darfo>
jaeger, no sure how rejmerge would help since many of the files in /var/run are not in the .footprint but are created at run time.
<jaeger>
Are /var/run and /run not owned by filesystem? I'll look at it later when I have time but I was thinking of the top level dir and symlink, not the files within
<darfo>
Yes that is their owner. Is that what triggers rejmerge?
<jaeger>
rejmerge deals with files in packages, so yeah
<darfo>
it's all good for me
<darfo>
really got a crush on 3.7
<beerman>
glad you like it
<farkuhar>
jaeger: http://ix.io/4c85 confirms my hunch about what happened when Markus and darfo and I performed our 3.6->3.7 upgrades. Maybe setup-helper will need a few extra lines.
<farkuhar>
even if I insert a mkdir command to create var/lib/pkg/rejected under the chroot, the unsuccessful pkgadd command doesn't put anything there that would trigger rejmerge.
<jaeger>
so the base issue is that /var/run is a directory in 3.6 and it's non-empty, and neither pkgadd nor rejmerge can deal with it?
<jaeger>
yeah, looks like that's the case, so on an upgraded system both /run and /var/run are directories
<jaeger>
So setup-helper should move anything in /var/run to /run, remove /var/run, and create the symlink to /run
<beerman>
setup-helper can also just not care about the content of /var/run as /run gets wiped during the reboot anyway
<jaeger>
true
<jaeger>
This could also probably be fixed in rc.fix
<beerman>
yeah
<beerman>
probably a good idea
<darfo>
it will be interesting to see how ports that create a dir in /var/run via Pkgfile behave when the directory disappears after a reboot. Try: grep -E 'var/run/[^\\w]' /usr/ports/*/*/.footprint
<darfo>
those I see are all contrib or my ports except one in opt: krb5
<darfo>
rc.fix sounds like a good place to force a test :) thanks jaeger
<beerman>
its not that much left anymore, krb5 is the most interesting port to still have it imo