<Arnavion>
Oh I see, it's not that the dep (wayland-client) is missing, it's that the tests can't find wayland-client.h even though the rest of foot found it. Include paths are wrong perhaps...
<Arnavion>
Or just because tests/meson.build is missing wayland_client in the dependencies[] ? (I don't know much about meson)
<dnkl>
Yeah, I think that's it
<Arnavion>
Specifically the path is test-config.c -> config.c -> config.h -> terminal.h -> wayland-client.h
<dnkl>
Pretty sure you're right about wayland _client missing in the dependency list for the test binary
<Arnavion>
How does it work without that for you and the CI?
<dnkl>
On my system the header files are in /usr/include.
<dnkl>
Guessing it's the same on the CI, or another dependency pulls in the correct path
<dnkl>
(i run arch, CI runs alpine and freebsd)
<Arnavion>
Ah, that would make sense. On openSUSE it's under /usr/include/wayland/
<Arnavion>
I recall we were carrying a patch for sway to change the #include's for that same reason, that we don't need now in 1.7
<dnkl>
Ah :)
<dnkl>
I'll open an issue and commit a patch tomorrow, but guessing you don't need a patch release for this?
<Arnavion>
I can patch locally for now, yeah
<Arnavion>
But even better if you also add an option to not build the tests :)
<dnkl>
Sure
<Arnavion>
because I suspect RPMlint will complain about the unpackaged binary that I'll have to override
Consolatis is now known as Guest8213
Guest8213 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
Consolatis has joined #foot
Arnavion has quit [Remote host closed the connection]
<ericonr>
Arnavion: shouldn't RPMlint care more about running tests instead of leftover binaries?
pranjal has quit [Ping timeout: 240 seconds]
<sochotnicky>
ericonr: not really - rpmlint is for catching basic issues with the packaging itself, not so much app problems itself
pranjal has joined #foot
pranjal has quit [Client Quit]
<sochotnicky>
you can run app tests during rpm build process itself
<sochotnicky>
that said - very few packages do that AFAIK, mostly because it usually adds little value to re-run upstream tests which are usually unit-test type
<sochotnicky>
plus that often pulls in a fair amount of deps for the build process, and not all of those deps might be packaged
<ericonr>
sochotnicky: hm, I don't agree there. There are tests that can catch issues with underlying library incompatibility
<sochotnicky>
ericonr: sure, there's those cases, but those generally manifest in broken compilation/linking etc. Not 100% - but vast majority
<sochotnicky>
rpmlint basically runs either on the final binary rpm or the source rpm - but it does not get involved in the build process itself
<sochotnicky>
at least last I worked in RPM packaging in Fedora (which has been a few years so maybe things have changed - but I doubt that)
<ericonr>
sochotnicky: to make my point clear, I feel like rpmlint complaining about those non installed binaries will discourage running tests
avane_ has joined #foot
avane has quit [Ping timeout: 256 seconds]
<sochotnicky>
ericonr: well leftover binaries warning is meant to warn packager they might have accidentally left out instructions to actually install those pieces. I am trying to remember what was the exact trigger though...
<sochotnicky>
Ah, I think it was then you had stuff that got make-installed into BUILDROOT during the install phase but not included in the actual RPM manifest anywhere
<sochotnicky>
so maybe the question is - is there some binary installed with make install that should not be?
<sochotnicky>
well "make install"
<dnkl>
the test binary is not installed, no. I believe Arnavion was speculating that he _may_ have to deal with RPMlint
<sochotnicky>
ah right, missed the older message context
dutchie has quit [Ping timeout: 260 seconds]
<hexa->
hm, I might have to recompile foot with debug symbols as promised a while ago :D
<dnkl>
crash with a warning just before?
<hexa->
was mod+f'ing a foot window so it went into and out of fullscreen
<hexa->
and then it was poof
<hexa->
#0 0x000000000042a6d5 in set_pivot_point_for_block_and_char_wise ()
<hexa->
only hint I have
<hexa->
#1 0x000000000042e32b in selection_update ()
<hexa->
those two
<dnkl>
hexa-: is this with the new 1.11 release?
<hexa->
oh, 1.10.3
<hexa->
on nixos
<hexa->
same problem I hit back in november
<hexa->
on 1.10.1
<dnkl>
hexa-: I remember committing "something" related to that. Don't think I made a changelog entry about it though. But, might be worth testing with 1.11 first
<hexa->
^ sterni? :)
<dnkl>
hexa-: there's a nixos PR open already, but don't think it's merged
<sterni>
1.11 is in master rn
<hexa->
ah ok, rebuilding my system on master from 20 minutes ago since 20 minutes
<sterni>
then you should get the update
<sterni>
for what it's worth, I have been using foot with sway this whole time as well and never had such a crash
<hexa->
sometimes my fingers are erraticly pressing key combos :) like mod+f
<hexa->
and as you can see I managed to crash it only twice in 3 month
<sterni>
surprised I didn't manage to hit it if it's related to selections
<sterni>
I have a strange compulsion to randomly select and unselect things on my screen all the time
<hexa->
oh, that's good to know :)
<dnkl>
hexa-: looking through the git log, I can't find anything related to this. I very clearly remember the issue, and _think_ I did something about it. But not absolute sure... 😅
<hexa->
15:25 <dnkl> hexa-: I took a quick look, and one thing I found was that foot wouldn't "finalize" (stop) an ongoing selection on point leave events
<hexa->
what i like about github is that it shows you git tag --contains on a commit :)
<hexa->
so that went into 1.10.2
<hexa->
so unrelated :)
<dnkl>
hexa-: if you can reproduce the issue with mod+f, while the mouse cursor is over the terminal window in both the normal window, and the fullscreened window (i.e. the mouse cursor never goes outside the window), then we know the issue is completely unrelated
<hexa->
still looking for ways to repro at all :<
<hexa->
didn't find one last time either
dutchie has joined #foot
<Lord>
ho no. foot-terminfo and ncurses can't be installed at the same time :-/
<dnkl>
Lord: most distros should allow both to be installed at the same time. Which distro are you using?
<Lord>
gentoo
<Lord>
[blocks B ] >=sys-libs/ncurses-6.3 (">=sys-libs/ncurses-6.3" is soft blocking gui-apps/foot-terminfo-1.11.0)
<dnkl>
Lord: the foot terminfo from ncurses is "good enough" in most cases. But, gentoo should perhaps consider renaming the files in the foot-terminfo package to foot-extra and foot-extra-direct. This is what e.g. Arch, Alpine and OpenSUSE (and probably more) do.
<dnkl>
Then it's up to the user if he/she wants to use the ncurses terminfo, or the ones from the foot-terminfo package
<Lord>
ncurses doesn't provide aa terminfo for foot
<dnkl>
Lord: it does if it's new enough
<Lord>
it's 6.3_p20211106 so quite recent
<dnkl>
not sure how gentoo packages ncurses and its terminfo. Some distros split them up into a base package containing the "popular" terminals, and another package with "the rest".
<dnkl>
but ncurses 6.3 definitely has a "foot" terminfo
<angry_vincent>
Lord: can you give qlist ncurses?
<Lord>
dnkl : there is a USE="tinfo" for ncurses
<Lord>
angry_vincent : it appears in qlist ncurses ! o__O
<angry_vincent>
so, block is reasonable
<angry_vincent>
if foot-terminfo better for foot instead of ncurses one, then rename of it is also reasonable, if foot can find renamed foot-terminfo
<Lord>
it appears in qlist but not on my fs :-/
<angry_vincent>
how to understand fs?
<Lord>
filesystem
<angry_vincent>
why is that?
<angry_vincent>
qlist supposed to read what is /var/db/*/*/contents which must be in filesystem
<Lord>
i emerge ncurses again
<angry_vincent>
*/* is category/pkgname
an3223 has quit [Remote host closed the connection]
an3223 has joined #foot
<Lord>
ok after re emerging ncurses it's here now :-)
<Lord>
sorry for bothering you
<angry_vincent>
it's ok. such cases are interesting
<dnkl>
Users can tell foot to use a different terminfo by setting "term=<name>" in foot.ini. I have mine set to "foot-extra".
<angry_vincent>
i found no report about it on bugs.gentoo.org, so it maybe good to report
<angry_vincent>
so, then, it is very easy fix
<angry_vincent>
blocks are good, but they are very furstrating when you want clean updates
<angry_vincent>
i don't use gentoo for some years now, but i still remember something
<sochotnicky>
well - stable ncurses in Gentoo is 6.2.x so it's not going to be hitting users on stable (or most mixed envs)
<sochotnicky>
for a while anyway :-)
<angry_vincent>
does not matter as both foot and foot-terminfo are ~amd64 only
<angry_vincent>
stable users have no this problem at all as a matter of fact
<Lord>
angry_vincent : it's probably my fault cause i may have fiddled with this some months ago and not remember
<angry_vincent>
okey :)
<sochotnicky>
angry_vincent: sure, but I'd say it's more likely that someone (i.e. me) installs foot from unstable (i.e. unmask/keyword just specific packages interested in)
<sochotnicky>
anyway, I agree preferably a fixed thing
<sochotnicky>
actually - foot is not even in main portage tree AFAIK
<sochotnicky>
for now I'll probably stay on my ebuild with ugly PGO ...
<Arnavion>
(For closure to the earlier conversation, yes RPMLint indeed did not complain, because the binary wasn't installed)
<dnkl>
hexa-: when you got the crash, were you selecting text in the terminal? Or was there text selected? Or were you perhaps using the scrollback search?
<dnkl>
I somehow managed to get foot into a state where an ongoing selection wasn't being visualized correctly. Then, with the mouse button still pressed, fullscreened the window. That caused me to hit an assertion in the resize logic.
<dnkl>
in a release build that assertion doesn't exist, but the internal state is of course equially broken. I _think_ it could result in a crash in selection_update()
<dnkl>
setting scrollback.lines=0 made it easier to trigger the broken selection. But I'm still not sure exactly how to trigger it
<hexa->
re selection: not deliberately
<hexa->
and not that I would remember
<dnkl>
That would suggest some kind of corruption, making foot _think_ there's an ongoing selection (one where the start coordinates are outside the grid, causing the crash)
k-man has quit [Quit: WeeChat 3.4]
k-man has joined #foot
<dnkl>
Another possibility: there are "pivot" coordinates that aren't being translated when the window is resized. That could result in invalid input to set_pivot_...()