dnkl changed the topic of #foot to: Foot - fast, lightweight and minimalistic Wayland terminal emulator || 1.11.0 || https://codeberg.org/dnkl/foot || channel logs: https://libera.irclog.whitequark.org/foot
hexa- has quit [Quit: WeeChat 3.3]
hexa- has joined #foot
avane has quit [Ping timeout: 272 seconds]
avane has joined #foot
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #foot
Arnavion has quit [Quit: Arnavion]
Arnavion has joined #foot
cbb has joined #foot
noteness has quit [Remote host closed the connection]
noteness has joined #foot
Gilgamew has joined #foot
an3223 has quit [Remote host closed the connection]
an3223 has joined #foot
cbb has quit [Ping timeout: 256 seconds]
cbb has joined #foot
<cbb> Anyone else getting "ninja install" failures with the latest git patch (2.35.3)...?
<cbb> Specifically; using "sudo ninja -v -C bld install" now gives the error:
<cbb> FAILED: version.h
<cbb> /usr/bin/env LC_ALL=C ../generate-version.sh 1.11.0 ../ version.h
<cbb> fatal: unsafe repository ('~/git/foot' is owned by someone else)
<cbb> To add an exception for this directory, call:
<cbb> git config --global --add safe.directory ~/foot
<cbb> Seems kind of a heavy handed fix
<dnkl> cbb: I'm on 2.35.3, and haven't noticed anything. But then that's perhaps because *I* own the repo? Is that what they mean by "owned by someone else"?
<cbb> I think it means "owned" as in owned by a particular system uid
<cbb> and it's something to do with using sudo
<dnkl> ah, yeah, seeing it too
<cbb> Using "sudo fakeroot ninja -v -C bld install" works
<cbb> and I guess the "safe.directory" suggestion in the error message would work
<cbb> seems like a wierd fix though...
<cbb> I guess I should just read that commit message and try to understand what they're fixing
<dnkl> also slightly annoying when all we do is run "git describe" and "git rev-parse"
<cbb> yeah
<cbb> I suppose it's because those commands are running under sudo
<cbb> would it be straight forward to somehow make so they only run when building?
<cbb> and not when installing?
<dnkl> not sure, but don't think so. running "ninja install" is supposed to build everything needed to "install" first.
<dnkl> but if we can figure out a way to add a dependency to, I don't know, the .git directory or something, so that we don't always have to rebuild the version target
<cbb> I think it's quite common for autoconf/makefile builds to make some exceptions there...
<cbb> for example:
<cbb> > Running ‘make install’ with a different value of prefix from the one used to build the program should not recompile the program.
<cbb> I think in that case it will typically compile the program, but it won't *re-compile* the program purely for that change
<cbb> generated version headers could be seen as a similar case
<dnkl> cbb: sure, but we're kind of limited by meson here. I'm looking at https://mesonbuild.com/Reference-manual_functions.html#custom_target, and I don't see a way to express that
<cbb> dnkl: hmm, yeah that's a good point
<cbb> I'm guessing probably not
<novakane> did using the git command `git config --global -add safe....` fix it for you guys though?
<cbb> novakane: I haven't tried that yet
<cbb> I just worked around it with fakeroot
<cbb> but I'm assuming it will
<cbb> let me try...
<dnkl> cbb: worth testing it at least. Not sure when it was added - docs doesn't say anything. Perhaps it's always been there, but I just didn't see it
<novakane> it seems like the way to go now for git though https://github.blog/2022-04-12-git-security-vulnerability-announced/
<novakane> but didn't fix it for me
<cbb> novakane: yeah, me neither
<cbb> lol
<cbb> I bet foot isn't the only case where it cause problems either
<novakane> ah nice fix then huh lmao
<cbb> and now it's on every single user to run that new command
<cbb> I think they need to go back to the drawing board
<novakane> yeah I searched for the error message and there is a looooot of issues found for this
<dnkl> let's wait a bit and see where this goes...
<novakane> just looking at this https://github.com/actions/checkout/issues/760
<cbb> dnkl: yeah, that seems like a good idea
<cbb> It looks like vcs_tag() was added in meson 0.23.0 btw
<cbb> ...but looking at the current custom_target(), vcs_tag() doesn't really seem flexible enough to replace it
<cbb> I also just tried it, out of curiosity, and it makes no difference to the git issue
<dnkl> cbb: too bad... but thanks for testing it
<novakane> this is annoying :/
<cbb> novakane: yeah it really is
<cbb> it's even worse that the original bug was mostly a Windows issue
<cbb> dnkl: no worries...thought I may as well test it and see
<novakane> yeah they should just have remove windows support :P
<cbb> novakane: yeah, my thoughts exactly 😆
<novakane> curious if that gonna break something for distro package too
<cbb> novakane: depends how fast they do something about it I guess
<cbb> or whether they even know
<cbb> time to look at the git mailing list
<novakane> good luck
Gilgamew has quit [Quit: Client closed]
<cbb> novakane: I don't think it will affect packages
<cbb> since they're installing into $DESTDIR and not using anything like sudo
cbb has quit [Quit: WeeChat 3.5]
<novakane> cbb: yeah that would makes sense, but then the command that should fix the problem doesn't works so we could have some surprise lol