<dnkl>
will: you can also set [colors].alpha in foot.ini - it will make the *default* background color transparent.
<alice>
TIL i really can't read for shit
<dnkl>
well, 'opacity' would have been a better name...
novakane has joined #foot
novakane has quit [Quit: WeeChat 3.2]
<Arnavion>
dnkl: Are you planning to only release the terminfo path change in 1.9.0 ? As in, not in a 1.8.x release?
novakane has joined #foot
<dnkl>
Arnavion: yeah, that's the plan.
<Arnavion>
Okay
<Arnavion>
I guess I can take the patch for 1.8.x until 1.9.0 releases
<dnkl>
I think I'll do the 1.9 release really soon in any case. I want to get it out before the next ncurses release. And there's nothing more in the pipe for 1.9.
<Arnavion>
How soon do you think?
<Arnavion>
I'm asking now because in OpenSUSE the terminfo update that has the conflicting files will be merged within the next couple of days, so I'd like to have the foot package resolve the conflict within that time
<dnkl>
I guess today is as good as any day :)
<dnkl>
Let me look through the open issues etc, but hopefully I can tag a release no later than this weekend. Fingers crossed
<Arnavion>
Oh, okay. I thought the fcft-3.0 PR was going to take more time than that
<dnkl>
Arnavion: I'm not planning on including that in 1.9
<Arnavion>
Okay. It was in the 1.9.0 milestone
<Arnavion>
But okay, looking forward to the release soon then
<dnkl>
Ah, right. Sorry, it _was_ intended for 1.9. Changed my mind, but forgot to update the milestones
st3r4g has joined #foot
st3r4g has quit [Read error: Connection reset by peer]
<dnkl>
Arnavion: *sigh*. I just noticed that ssh drops the TERMINFO environment variable. And you have to modify both the server and the client to be able to pass it through.
<dnkl>
I though I had tested this, but obviously not
<Arnavion>
And the same for TERMINFO_DIRS I guess?
<dnkl>
Yup
<Arnavion>
Welp
<dnkl>
I'm starting to think that we should simply rename our terminfo instead, and install it in the standard location
<dnkl>
With the downside that we no longer fall back gracefully to ncurses version of our terminfo
<Arnavion>
And then change the default value of the term config to match?
<Arnavion>
Will TD then... be motivated to rename ncurses' version of the terminfo to match the new name?
<Arnavion>
"I added a terminfo for foot, but they call themselves foot2 now, so let me rename it too" ?
<dnkl>
yeah... there's a possibility
<dnkl>
but I don't think so. There's already precedence
<dnkl>
both kitty and rxvt install custom terminfos alongside ncurses'
<Arnavion>
Ah right
<dnkl>
and, this would make it up the user to decide which version to use, without accidentely/unknowingly switching to the other one
* dnkl
apologizes for his english today - worse than usual
<dnkl>
but what to call it? "-" has special meaning, so it shouldn't include that. foot2 implies a versioning scheme
<Arnavion>
Hmm, but thinking about it, isn't it okay to use the TERMINFO env var even though it doesn't get transferred over ssh?
<Arnavion>
The client can't know what the proper value should be for the server anyway
<dnkl>
that's true
<dnkl>
but I was hoping distros would go with the default location
<Arnavion>
And you don't need ssh to transfer the env var; the server operator would've added it to sshd's env vars appropriately
<dnkl>
hmm, ok, true. Though, I think in most cases, the clients (our foot users) will not be the server admins...
<Arnavion>
"I've installed only ncurses terminfos therefore I expect the terminfo to be looked up from there", or "I also installed foot's terminfo to /path and therefore I'll add TERMINFO_DIRS=/path to sshd's env vars"
<dnkl>
I guess we could go with TERMINFO in 1.9, and see how much issues it raises...
<dnkl>
alright, I'll go ahead with the 1.9 release - no more terminfo changes
<Arnavion>
The foot-terminfo package *could* also include /etc/ssh/sshd_config.d/50-foot-terminfo.conf with SetEnv TERMINFO_DIRS=... but maybe that's pushing it (not in the least because not all distros have Include /etc/ssh/sshd_config.d/*.conf in their default sshd_config)
<dnkl>
we could mention the possibility in INSTALL.md
<Arnavion>
Also wouldn't scale with multiple such files because SetEnv can't append
<dnkl>
ah, that makes it a no-go...
<Arnavion>
I guess we're walking down the same path as kovidgoyal which led him to make his "ssh pre-deploys the terminfo to the remote" helper
<dnkl>
yup, sounds like it :)
novakane has quit [Quit: WeeChat 3.2]
<sterni>
I still think ideal would be overwriting ncurses' terminfo :p
<sterni>
but I guess a lot of package managers can't do that
<sterni>
I guess apt can do it via alternatives maybe? but it's probably very clunky
<dnkl>
sterni: I wont stop you from doing that in nix... (not sure what dickey thinks about that though)
<sterni>
dnkl: yeah that's my plan currently (unless there's major pushback within nixpkgs I guess)
<sterni>
dnkl: idk ncurses is unaffected if you neither install foot nor its terminfo explicitly
<dnkl>
yeah, that makes sense
<sterni>
I'm pretty sure people will report any issues to foot first and it would also be transparent to users that the terminfo file doesn't come from ncurses
<dnkl>
Weird... Those line numbers don't point to anything useful
<dnkl>
Plus, I build with gcc all the time...
<dnkl>
sterni: was that build 1.9? Or the PR?
* ifreund
wonders why terminfo directorys are alphabetically sorted into sub-directories
<novakane>
ifreund: "Compiled terminfo file descriptions are placed in subdirectories under the /usr/share/lib/terminfo directory to avoid performing linear searches through a single directory containing all of the terminfo file description files."
<dnkl>
ifreund: probably to avoid overly large directories. Some filesystems are slow...
<sterni>
actually with foot setting TERMINFO it doesn't matter if we install it globally or not on NixOS or not
<sterni>
it really only matters for installing it on remote systems
<sterni>
okay right now foot doesn't extend TERMINFO_DIRS, just sets TERMINFO?
<dnkl>
sterni: yeah, it seemed to be better supported
<dnkl>
sterni: so, your gcc issue... the lines it's complaining about; they point right into main() for me, on 1.9.0. That makes zero sense
<dnkl>
unless there's some macro magic happening here
<dnkl>
anyway you could get a preprocessed version of pgo.c? Basically, copy the command line, add -E and maybe rename the -o <output> file to something that doesn't end with .o
<sterni>
dnkl: yeah same for me, only the previous definition ones make sense
<dnkl>
I can't even reproduce it... I do gcc PGO builds almost daily
<dnkl>
so it's either something in your environment, or something is different between our gcc versions
<dnkl>
but getting a pre-processed file is a good start
<dnkl>
then we'll know what it's _actually_ trying to compile
<sterni>
also fails with clang
<dnkl>
that's actually good... I think. It suggests something in your environment
<novakane>
I do gcc pgo build after every commit too whitout problem, gcc 10.2.1
<dnkl>
gcc 11.1 gere
<dnkl>
here
<sterni>
gcc 10.3 clang 7.1 and 11 exhibit this behavior atm
<dnkl>
the fact that it's *just* those three functions, makes me think that PR is being applied as a patch, on top of 1.9...
<sterni>
dnkl: haha you were exactly right I'm stupid
<dnkl>
sterni: :)
<dnkl>
I
<dnkl>
I'm just glad I don't have to do a 1.9.1 release 1h after 1.9.0
<sterni>
okay wait, so if foot sets TERMINFO I actually don't need to install the terminfo dir anymore
<sterni>
foot can just reference the /nix/store path
<sterni>
*install into the user environment
<sterni>
that's quite neat
<sterni>
love how inadvertently you made foot behave more nix-ish by hardcoding specific installation location instead of relying on the global environment
<dnkl>
sterni: glad someone is happy :D
<dnkl>
but hopefully this is a solution that works well enough
<sterni>
I'm interested to see if we run into trouble down the line, yeah
<sterni>
NixOS sets TERMINFO_DIRS and I expect non conforming packages have been patched to respect that
<sterni>
I fear a little bit that there may be packages that don't like TERMINFO
<sterni>
but if that turns out to be the case, I'll just make a patch for foot to prepend to TERMINFO_DIRS
<dnkl>
sterni: how does nix deal with TERMINFO_DIRS in e.g. sudo and ssh?
<sterni>
sudo seems to inherit the current users TERMINFO_DIRS
<sterni>
but it relies on the remote system to set something useful in the user environment for ssh
<sterni>
I'll check with TERMINFO shortly waiting for my system rebuild
<dnkl>
hmm, you must have patched in someway then? By default it doesn't pass that one on. I had to add "Defaults env_keep += "TERMINFO"" to enable that
<dnkl>
s/patched/patched sudo/
<dnkl>
TERMINFO, and TERMINFO_DIRS alike
<sterni>
dnkl: it's possible it's just TERMINFO_DIRS, not TERMINFO?
<sterni>
don't see a patch and only a env_keep for SSH_ATUH_SOCK
<sterni>
ohhhh no
<sterni>
fish unsets TERMINFO?
<sterni>
no that's not it
<sterni>
instance two of sterni being stupid today
<dnkl>
sterni: for me, sudo removes both TERMINFO and TERMINFO_DIRS . By default
<sterni>
TERMINFO is also preserved for me, interesting
<sterni>
maybe my testing is flawed?
<dnkl>
Not sure. I just ran "sudo env | grep TERM"
lemontree has quit [Remote host closed the connection]
<sterni>
maybe sudo is something you don't want to look too closely at anyways :p
lilblacky has joined #foot
<lilblacky>
Any plans to add a sig and/or checksum to the source downloads for integrity/auth? Foot (I.e. terms in general) is a fairly critical piece of software.
<dnkl>
lilblacky: the downloads are auto-generated by gitea. An alternative is to check out the tag instead. All my commits are gpg signed
novakane has quit [Quit: WeeChat 3.2]
<lilblacky>
Will do. Is the tag signed by a generic codeberg key? Is B1996...73F your signing key? If so, where can I find the pub key (gnupg/openpgp/mit keyservers cannot find the key)?
<dnkl>
lilblacky: it's my key. It's not (yet) available on any public servers. I'll see what I can do.
<lilblacky>
Perfect. Thanks :)
alice has quit [Remote host closed the connection]