Re: [new] lnav 0.12.1
On Fri, Apr 26, 2024 at 10:41:46AM +0200, Landry Breuil wrote: > > On my machine it creates ~/.config/lnav, not ~/.lnav, and removing the > > ~/.config/lnav directory unfortunately doesn't change anything, it still > > crashes early at startup. > > it probably does funky things depending on $TERM. > > it works fine within tmux where TERM=screen, it crashes in > xfce4-terminal (where here TERM=xterm-256color) but works fine if i > manually set TERM=xterm. > > same thing with alacritty, it crashes if TERM=alacritty (the default) > but works fine with 'TERM=xterm lnav' > > you seem to be a guy with interest in low-level terminal stuff :) grep > -r TERM yields many things in lnav's code... and there seem to be > related issues upstream, cf https://github.com/tstack/lnav/issues/570 > and https://github.com/tstack/lnav/issues/1192 at least. But it shouldnt > crash like this :) > > in the meantime, here's a port of 0.12.2, still building here... it > might give better results, or not. This version does indeed solves the issues, it runs perfectly in the terminals I previously tested with, and it exits gracefully in case TERM is set to an unknown option: $ TERM=puffy lnav error: unable to open TUI reason: the terminfo database could not be found Looks good to me for import now, OK fcambus@.
Re: [new] lnav 0.12.1
Le Thu, Apr 25, 2024 at 05:00:26PM +0200, Frederic Cambus a écrit : > On Wed, Apr 24, 2024 at 08:21:38AM +0200, Landry Breuil wrote: > > > > I previously didn't notice this, it always ran fine here during my tests: > > > launching it in tmux worked both locally and through SSH. > > > > > > But launching it in alacritty outside of tmux indeed results in a crash, > > > although it works fine in xterm or in a framebuffer console. > > > > interestingly, it started working once i had rm -Rf ~/.lnav. so i guess > > something something corrupted internal database ? > > > > does it work again if you move away ~/.lnav on the machine where it > > crashes ? > > On my machine it creates ~/.config/lnav, not ~/.lnav, and removing the > ~/.config/lnav directory unfortunately doesn't change anything, it still > crashes early at startup. it probably does funky things depending on $TERM. it works fine within tmux where TERM=screen, it crashes in xfce4-terminal (where here TERM=xterm-256color) but works fine if i manually set TERM=xterm. same thing with alacritty, it crashes if TERM=alacritty (the default) but works fine with 'TERM=xterm lnav' you seem to be a guy with interest in low-level terminal stuff :) grep -r TERM yields many things in lnav's code... and there seem to be related issues upstream, cf https://github.com/tstack/lnav/issues/570 and https://github.com/tstack/lnav/issues/1192 at least. But it shouldnt crash like this :) in the meantime, here's a port of 0.12.2, still building here... it might give better results, or not. https://github.com/tstack/lnav/releases/tag/v0.12.2 Landry lnav-0.12.2.tgz Description: application/tar-gz
Re: [new] lnav 0.12.1
On Wed, Apr 24, 2024 at 08:21:38AM +0200, Landry Breuil wrote: > > I previously didn't notice this, it always ran fine here during my tests: > > launching it in tmux worked both locally and through SSH. > > > > But launching it in alacritty outside of tmux indeed results in a crash, > > although it works fine in xterm or in a framebuffer console. > > interestingly, it started working once i had rm -Rf ~/.lnav. so i guess > something something corrupted internal database ? > > does it work again if you move away ~/.lnav on the machine where it > crashes ? On my machine it creates ~/.config/lnav, not ~/.lnav, and removing the ~/.config/lnav directory unfortunately doesn't change anything, it still crashes early at startup.
Re: [new] lnav 0.12.1
Le Tue, Apr 23, 2024 at 02:20:21PM +0100, Stuart Henderson a écrit : > On 2024/04/23 10:29, Landry Breuil wrote: > > Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > > > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > > > > > this is a second attempt at a port for https://lnav.org, after > > > > https://marc.info/?t=15333968122=1=2 some years ago, which > > > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > > > linking against two readline libs. > > > > > > Thanks for picking this up again! > > > > > > > i had originally put it under textproc/ but frederic had it in > > > > sysutils/, no strong opinion on that. > > > > > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > > > either. > > > > > > > the attached port links against only one readline (the one from ports), > > > > and i've tried to do my best to have tests running. For now it seems one > > > > hangs.. > > > > > > > > PASS: lnav_doctests > > > > PASS: test_abbrev > > > > PASS: test_ansi_scrubber > > > > PASS: test_auto_fd > > > > PASS: test_auto_mem > > > > PASS: test_bookmarks > > > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > > > "$@" >> "$log_file" 2>&1 > > > > FAIL: test_date_time_scanner > > > > PASS: test_format_installer.sh > > > > > > > > > > > > in 0.12.1 a PRQL feature was added > > > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > > > but it relies on rust/cargo being run from gmake and at that point i've > > > > just disabled this feature. > > > > > > Makes sense, yes. > > > > > > > feedback & testing welcome > > > > > > The build fails at link time if devel/fmt is installed. > > > > i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when > > you saw that failure i suppose that was with the previous fmt version > > installed ? > > It's preferring libfmt in /usr/local for headers in some of the compiler > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > if it works now, things will likely break again in the future. > > It would be best to figure out how to get the -I reordered so that > -I./../fmtlib comes before -Iusr/local/include. You can check by > installing fmt, editing /usr/local/include/fmt/format.h to add a > #error at the top, and make sure that lnav still builds. this version builds fine with a poisoned fmt/format.h $grep \#error /usr/local/include/fmt/format.h #error lnav/patches/patch-src_tailer_Makefile_in just reorders the includes as advised, and it works fine. i've cleaned up makefile, tests still hang but some of them run fine, there's still room from improvement here so i've left NO_TEST commented out - but at least it now runs, even producing some NULL vfprintf on the way :) Apr 24 09:07:30 c64 lnav: vfprintf %s NULL in " XDG_CONFIG_HOME=%s" Apr 24 09:07:30 c64 lnav: vfprintf %s NULL in " TZ=%s" Apr 24 09:07:31 c64 lnav: vfprintf %s NULL in "read next header %s %s" Landry lnav-0.12.1_2.tgz Description: application/tar-gz
Re: [new] lnav 0.12.1
Le Tue, Apr 23, 2024 at 07:47:37PM +0200, Frederic Cambus a écrit : > On Tue, Apr 23, 2024 at 03:41:20PM +0200, Landry Breuil wrote: > > > > It's preferring libfmt in /usr/local for headers in some of the compiler > > > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > > > if it works now, things will likely break again in the future. > > > > > > It would be best to figure out how to get the -I reordered so that > > > -I./../fmtlib comes before -Iusr/local/include. You can check by > > > installing fmt, editing /usr/local/include/fmt/format.h to add a > > > #error at the top, and make sure that lnav still builds. > > > > and on top of that im not even sure this is worth importing as is, > > because it crashes/segfaults at startup here anyway. > > I previously didn't notice this, it always ran fine here during my tests: > launching it in tmux worked both locally and through SSH. > > But launching it in alacritty outside of tmux indeed results in a crash, > although it works fine in xterm or in a framebuffer console. interestingly, it started working once i had rm -Rf ~/.lnav. so i guess something something corrupted internal database ? does it work again if you move away ~/.lnav on the machine where it crashes ?
Re: [new] lnav 0.12.1
On Tue, Apr 23, 2024 at 03:41:20PM +0200, Landry Breuil wrote: > > It's preferring libfmt in /usr/local for headers in some of the compiler > > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > > if it works now, things will likely break again in the future. > > > > It would be best to figure out how to get the -I reordered so that > > -I./../fmtlib comes before -Iusr/local/include. You can check by > > installing fmt, editing /usr/local/include/fmt/format.h to add a > > #error at the top, and make sure that lnav still builds. > > and on top of that im not even sure this is worth importing as is, > because it crashes/segfaults at startup here anyway. I previously didn't notice this, it always ran fine here during my tests: launching it in tmux worked both locally and through SSH. But launching it in alacritty outside of tmux indeed results in a crash, although it works fine in xterm or in a framebuffer console.
Re: [new] lnav 0.12.1
Le Tue, Apr 23, 2024 at 02:20:21PM +0100, Stuart Henderson a écrit : > On 2024/04/23 10:29, Landry Breuil wrote: > > Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > > > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > > > > > this is a second attempt at a port for https://lnav.org, after > > > > https://marc.info/?t=15333968122=1=2 some years ago, which > > > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > > > linking against two readline libs. > > > > > > Thanks for picking this up again! > > > > > > > i had originally put it under textproc/ but frederic had it in > > > > sysutils/, no strong opinion on that. > > > > > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > > > either. > > > > > > > the attached port links against only one readline (the one from ports), > > > > and i've tried to do my best to have tests running. For now it seems one > > > > hangs.. > > > > > > > > PASS: lnav_doctests > > > > PASS: test_abbrev > > > > PASS: test_ansi_scrubber > > > > PASS: test_auto_fd > > > > PASS: test_auto_mem > > > > PASS: test_bookmarks > > > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > > > "$@" >> "$log_file" 2>&1 > > > > FAIL: test_date_time_scanner > > > > PASS: test_format_installer.sh > > > > > > > > > > > > in 0.12.1 a PRQL feature was added > > > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > > > but it relies on rust/cargo being run from gmake and at that point i've > > > > just disabled this feature. > > > > > > Makes sense, yes. > > > > > > > feedback & testing welcome > > > > > > The build fails at link time if devel/fmt is installed. > > > > i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when > > you saw that failure i suppose that was with the previous fmt version > > installed ? > > It's preferring libfmt in /usr/local for headers in some of the compiler > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > if it works now, things will likely break again in the future. > > It would be best to figure out how to get the -I reordered so that > -I./../fmtlib comes before -Iusr/local/include. You can check by > installing fmt, editing /usr/local/include/fmt/format.h to add a > #error at the top, and make sure that lnav still builds. and on top of that im not even sure this is worth importing as is, because it crashes/segfaults at startup here anyway.
Re: [new] lnav 0.12.1
On 2024/04/23 10:29, Landry Breuil wrote: > Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > > > this is a second attempt at a port for https://lnav.org, after > > > https://marc.info/?t=15333968122=1=2 some years ago, which > > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > > linking against two readline libs. > > > > Thanks for picking this up again! > > > > > i had originally put it under textproc/ but frederic had it in > > > sysutils/, no strong opinion on that. > > > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > > either. > > > > > the attached port links against only one readline (the one from ports), > > > and i've tried to do my best to have tests running. For now it seems one > > > hangs.. > > > > > > PASS: lnav_doctests > > > PASS: test_abbrev > > > PASS: test_ansi_scrubber > > > PASS: test_auto_fd > > > PASS: test_auto_mem > > > PASS: test_bookmarks > > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > > "$@" >> "$log_file" 2>&1 > > > FAIL: test_date_time_scanner > > > PASS: test_format_installer.sh > > > > > > > > > in 0.12.1 a PRQL feature was added > > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > > but it relies on rust/cargo being run from gmake and at that point i've > > > just disabled this feature. > > > > Makes sense, yes. > > > > > feedback & testing welcome > > > > The build fails at link time if devel/fmt is installed. > > i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when > you saw that failure i suppose that was with the previous fmt version > installed ? It's preferring libfmt in /usr/local for headers in some of the compiler commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even if it works now, things will likely break again in the future. It would be best to figure out how to get the -I reordered so that -I./../fmtlib comes before -Iusr/local/include. You can check by installing fmt, editing /usr/local/include/fmt/format.h to add a #error at the top, and make sure that lnav still builds.
Re: [new] lnav 0.12.1
On Tue, Apr 23, 2024 at 10:29:43AM +0200, Landry Breuil wrote: > > > feedback & testing welcome > > > > The build fails at link time if devel/fmt is installed. > > i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when > you saw that failure i suppose that was with the previous fmt version > installed ? Indeed, the failure was with fmt 8.1.1 installed. With 10.2.1 it builds as expected, sorry for the noise. One small nitpick: there are two blank lines instead of one above the USE_GMAKE directive. OK fcambus@ to import.
Re: [new] lnav 0.12.1
Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > this is a second attempt at a port for https://lnav.org, after > > https://marc.info/?t=15333968122=1=2 some years ago, which > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > linking against two readline libs. > > Thanks for picking this up again! > > > i had originally put it under textproc/ but frederic had it in > > sysutils/, no strong opinion on that. > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > either. > > > the attached port links against only one readline (the one from ports), > > and i've tried to do my best to have tests running. For now it seems one > > hangs.. > > > > PASS: lnav_doctests > > PASS: test_abbrev > > PASS: test_ansi_scrubber > > PASS: test_auto_fd > > PASS: test_auto_mem > > PASS: test_bookmarks > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > "$@" >> "$log_file" 2>&1 > > FAIL: test_date_time_scanner > > PASS: test_format_installer.sh > > > > > > in 0.12.1 a PRQL feature was added > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > but it relies on rust/cargo being run from gmake and at that point i've > > just disabled this feature. > > Makes sense, yes. > > > feedback & testing welcome > > The build fails at link time if devel/fmt is installed. i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when you saw that failure i suppose that was with the previous fmt version installed ? Landry
Re: [new] lnav 0.12.1
On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > this is a second attempt at a port for https://lnav.org, after > https://marc.info/?t=15333968122=1=2 some years ago, which > fcambus@ reminded me about. He pushed it to wip but had issues with it > linking against two readline libs. Thanks for picking this up again! > i had originally put it under textproc/ but frederic had it in > sysutils/, no strong opinion on that. FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion either. > the attached port links against only one readline (the one from ports), > and i've tried to do my best to have tests running. For now it seems one > hangs.. > > PASS: lnav_doctests > PASS: test_abbrev > PASS: test_ansi_scrubber > PASS: test_auto_fd > PASS: test_auto_mem > PASS: test_bookmarks > ../test-driver: line 112: 69425 Abort trap (core dumped) > "$@" >> "$log_file" 2>&1 > FAIL: test_date_time_scanner > PASS: test_format_installer.sh > > > in 0.12.1 a PRQL feature was added > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > but it relies on rust/cargo being run from gmake and at that point i've > just disabled this feature. Makes sense, yes. > feedback & testing welcome The build fails at link time if devel/fmt is installed.
