<farkuhar>
jaeger: i doubt the change from printing output to calling a pager had anything to do with rejmerge itself, the commit history doesn't support that theory: https://crux.nu/gitweb/?p=tools/pkgutils.git;a=history;f=rejmerge.in;h=ae93489a4a3c950b10a3e750da3cbe150cb042ee;hb=HEAD
<farkuhar>
but if the root user's profile defines any aliases or environment variables, rejmerge can fail to behave as expected. For example, one system I upgraded to 3.7 had EDITOR=neovim in root's profile, and rejmerge wasn't able to spawn the editor (because neovim was dynamically linked to older versions of the core libraries).
<jaeger>
I also doubt it had anything to do with rejmerge but something changed. Don't know if it's terminal, shell, etc.
<jaeger>
Romster: yeah, no good location for this but /usr/opt/$name doesn't conflict with the FHS suggestions at least
chrcav has quit [Ping timeout: 248 seconds]
chrcav has joined #crux-devel
mbarbar has quit [Ping timeout: 268 seconds]
mbarbar has joined #crux-devel
<beerman>
its the same for me, and i thought its just my local configuration that does it, but I get the pager as well with rejmerge (and i love it)
<farkuhar>
As rejmerge seems to have been running `cat $TMPFILE | more` for most of its history, one way we could have been fooled into thinking that no pager was involved is if /bin/more returned us to the shell without prompting (the old behaviour before this commit).
<jaeger>
Makes sense, I hadn't dug into it yet or thought hard about it... I guess the difference is that what it does now clears the terminal instead of just appending... so while it's paging in both cases it feels different
<jaeger>
Or maybe I'm just misremembering and it cleared before, but the different feel was returning to the shell instead of the prompt
<jaeger>
Unrelated to that, I'm working on the webhook API for gitea again... the email messages are going to change content, just so you know
<jaeger>
The original hooks run in the git repo itself and gather the log/merge-base/ref info directly
<jaeger>
The gitea hooks receive a json blob from gitea and it doesn't have exactly the same content
<jaeger>
beerman: any idea why the commit timestamps from gitea are like this? "timestamp": "0001-01-01T00:00:00Z",
<jaeger>
It seems to be fine in the web UI
<beerman>
jaeger: not right off the bat, have you looked into the configuration manual already? maybe its something I haven't touched yet
<jaeger>
Not yet. I'm about to run some errands, will look into it when I get back
<jaeger>
But I have it sending to redis and via email, just working out the email body stuff like timestamp, etc.
<jaeger>
Hrmm, that time config option doesn't seem to be it... the timestamps are fine in the web UI, just wrong in the webhook json
<jaeger>
for clarification it's always "0001-01-01T00:00:00Z", not an offset issue
<beerman>
no idea then
<beerman>
the config cheat sheet doesn't seem to be helpful, at least I didn't pick anything else up there, webhook section isn't it
<beerman>
maybe we need to set some timezone for it to actually be able to tell inside webhooks?
<jaeger>
maybe?
<jaeger>
can't hurt to try, I guess
<beerman>
ok, I restarted it with a default timezone
<jaeger>
ok, will test
<jaeger>
No change
<jaeger>
What version of gitea are we running?
<farkuhar>
looks like 1.17.2
<jaeger>
Asked in their discord, will see if anyone knows
<jaeger>
ok, thanks
<beerman>
version is printed in the footer, it should be the latest version
<beerman>
i just looked over the config cheat sheet again and more carefully, but I found nothing in them
<beerman>
just an fyi: we still have a few problems with giteas reverse proxy, but it seems like this is due to the port nginx runs on currently. I tested the exact same config somewhere else and it works, so I am very positive about as soon as we switch there errors will be sorted
<jaeger>
This looks like the "zero" value for a golang time.Time struct, or as someone said an empty value
<beerman>
the only thing that is visually broken right now is captcha I would ideally want to enable during registration
<beerman>
..is the captcha that I..
<beerman>
Is it a problem with our go port?
<jaeger>
I can't imagine it would be for 2 reasons: 1) I use timestamps with our go without issues, and 2) the timestamps are only wrong in the webhook post data, not the web UI (and the whole thing is go as far as I can see)
<stenur>
..it is to inviting, as i would rather have been afraid it _was_ something he touched..
<beerman>
mh
* stenur
RRRRRROFLLLLLLL
<SiFuh>
Limp Bizkit lyrics?
<beerman>
jaeger: guess you will have to endure some more weird conversations as I leave stenur back on the ignore list. i really wonder when we boot him for being whatever he tries to be, but gosh, I can't stand this internet bad ass
<beerman>
can't run irssi right, can't do sys admin stuff right, can't do proper commits nor pretty Pkgfiles, but he got some mouth on him for whatever reasons we don't know
darfo has joined #crux-devel
<stenur>
there was yet another thing i now have forgotten; stumbled upon it a few hours back; hmm; not that i think flyspry reports are worked.
<stenur>
ah yah, btrfs progs manual pages
<stenur>
btw i have not used /opt in two decades. I always stumble upon that on the OpenCSW.org cluster i think, because that puts a bunch of giants there.
<SiFuh>
stenur: I use /opt for binary installs because I don't like them located in amongst regular linux binaries.
<SiFuh>
Telegram, skypeforlinux and Virtual Box for example
<stenur>
and that is just the login machine, pooh.
<SiFuh>
I create a link to the binary under /opt/bin so need a path that stupid
<stenur>
SiFuh: luckily i do not use any of these; happy to have qemu here!
<stenur>
Well i would put to /usr/local/bla i think; /usr/local is "mine"
<stenur>
for example i still have -rwxr-xr-x 1 steffen steffen 2137448 Dec 6 2019 /usr/local/bin/bristol*
<stenur>
that pedja pointed me to. ('built myself though; but still.)
<stenur>
(And not that i use /usr/local; i have my own $HOME/$USR, where $USR is usr-${HOSTNAME}-${SYSNAME}-${OSTYPE}-${MACHTYPE} or without SYSNAME. Shared directory..
<jaeger>
stenur: what is this referencing? "..it is to inviting, as i would rather have been afraid it _was_ something he touched.."
<beerman>
jaeger: anyway, I rebuilt go and gitea and restarted the service, I don't think it made a change but maybe you can try it out once more
<jaeger>
sure, will try
<jaeger>
sadly, no change
<beerman>
I expected as much
<beerman>
maybe a bug on their end? hopefully somebody on discord will know what to poke at
<beerman>
wait, which timestamp exactly ware we looking at? contrib repository: settings -> webhooks -> edit that one entry -> recent deliveries -> body of content?