jaeger changed the topic of #crux-devel to: CRUX (https://crux.nu/) development channel | Logs: https://libera.irclog.whitequark.org/crux-devel/
<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)
SiFuh has quit [Ping timeout: 265 seconds]
SiFuh has joined #crux-devel
<farkuhar> June 15 fits the timeline for "before 3.7 but still recent": https://github.com/util-linux/util-linux/commit/28b391ce7e58f8327c092b3911c05f526d0ad586
<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.
darfo has quit [Ping timeout: 265 seconds]
ivandi has quit [Quit: WeeChat 3.6]
ivandi has joined #crux-devel
<beerman> cool, sounds good
ivandi has quit [Quit: WeeChat 3.6]
<beerman> but I'm not too sure
ivandi has joined #crux-devel
<jaeger> back
<jaeger> still weird to be scheduling software updates for my car
<beerman> ¯\_(ツ)_/¯ as long as it still can run Doom
<jaeger> It probably can
<jaeger> It's got a ryzen in it, heh
<jaeger> heh
<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.
<stenur> ...which makes for an immense path:
<stenur> /opt/tarantella/bin:/opt/SUNWsftransport/bin:/opt/SUNWsasm/bin:/opt/SUNWrtvc/bin:/opt/SUNWlwact/bin:/opt/RICHPse/bin:/opt/ocm/bin:/opt/csw/bin:/opt/csw/sbin:/opt/bop/bin:/home/sdaoden/usr-login-sunos-sun4v/bin:/home/sdaoden/usr-login-sunos-sun4v/sbin:/bin:/usr/bin:/usr/X11/bin:/sbin:/usr/sbin:/usr/xpg4/bin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/usr/sfw/bin:/usr/sfw/sbin
<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?
<beerman> s/ware/are/
<jaeger> the one in the individual commits
<beerman> https://dpaste.com/68TP65M7W this one for example?
<jaeger> and yes, you can see it in the body
<beerman> line 22
<beerman> gotcha
<jaeger> line 22, yeah
<beerman> ok i pressed the "test delivery" button so sorry if there is an email now :D same problem for me it seems
<jaeger> no worries
<beerman> well, I am stumped. Any chance you think it could be possible that its the reverse proxy or mirrored repository that we do right now?
<jaeger> It doesn't appear to be repository-specific either, just made a fresh test repo and it does the same
<jaeger> Did that because I was curious if the mirroring was the issue, doesn't seem to be
<jaeger> I suppose it could be the proxy but I doubt it
<beerman> the problem with the reverse proxy is static content delivery
<beerman> some things just fail to load, it's weird. it's not matching the behaviour of my test instance that ran on 443 directly
<beerman> logs are not really helpful either as it just says destination unknown
<beerman> but i guess that can just wait till the final switch
<beerman> though the webhooks are curious
<jaeger> have you configured static stuff to be served directly by nginx rather than the reverse?
<beerman> https://docs.gitea.io/en-us/reverse-proxies/#single-node-and-single-domain basically that with subpath instead of /