Re: Help testing release candidate / mc-4.8.26-rc1
Hello,
I just compiled mc-4.8.26 (release version) on two systems, one
ancient, one current gentoo and:
On Mon, 18 Jan 2021, David Haller wrote:
>1. mcedit causes a SIGSEGV when jumping out via Ctrl-o, even if just
> too _look_ at stuff, not doing anything on the (sub-)shell:
I can confirm this is fixed, thanks a lot!
>2. I don't know if that's a current regression or if that already was
> the case in 4.8.25 and earlier: if compiled without slang, no mouse
> actions work anymore (has the curses code gone?)
As ABorodin wrote, known issue, also confirmed fixed.
>3.: you should add the version to AC_INIT, so that PACKAGE_VERSION
>gets set correctly during configure. If not, generated docs have
>'mc-' instead of 'mc-$VERSION' (e.g. mc-4.8.25) as version in e.g.
>the pdf ;)
Again known issue, https://midnight-commander.org/ticket/3603, still
open but fix pending for .27 ;) I can live with a local fix until
then.
But I noticed a 4th issue, both in 4.8.26_rc1 and 4.8.26 compiled
against ncursesw6, namely that e.g. Ctrl-Pos1/Ctrl-End in mcedit did
nothing at all (it works compiled against slang).
Anyone heard of that / noticed it? Any possible recent change in the
code that could trigger this? I can easily recompile, but I guess I'll
need to install the "broken" version under a different name, because
without mc/mcedit I feel crippled I use Ctrl-{Pos1,End} a lot ;)
-dnh
--
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first. (Arno Schaefer's .sig)
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.26-rc1
On Mon, 11 Jan 2021, Sergei Trofimovich wrote: Is there an option to tag release candidates just like releases and name/upload tarballs into expected locations just like releases? Hi Sergei, Yes, I can do this in the future if this would make your life easier - I just took over the process from Slava and never realised that it might be inconvenient for maintainers, after we decided to distribute internal test builds as rcs before release to get a bit more coverage. What should the tags look like? 4.8.27-rc1 -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.26-rc1
On Mon, 18 Jan 2021 08:35:24 +0300 Andrew Borodin wrote: > On Mon, 18 Jan 2021 04:38:10 +0100 David Haller wrote: > > 1. mcedit causes a SIGSEGV when jumping out via Ctrl-o, even if just > >too _look_ at stuff, not doing anything on the (sub-)shell: > > Confirmed. > I'll fix this today. Fixed: https://midnight-commander.org/changeset/a88a626e76139259e5b6fc0db39045f051e243dd -- Andrew ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.26-rc1
On Mon, 18 Jan 2021 04:38:10 +0100 David Haller wrote:
> Hello,
Hi!
Thanks for testing.
> On Sun, 10 Jan 2021, Yury V. Zaytsev wrote:
> >TLDR; I would appreciate if you could please test the following tarball on
> >your systems and report any blocker regressions as compared to the previous
> >4.8.25 release:
>
> Two things:
>
> 1. mcedit causes a SIGSEGV when jumping out via Ctrl-o, even if just
>too _look_ at stuff, not doing anything on the (sub-)shell:
Confirmed.
I'll fix this today.
> 2. I don't know if that's a current regression or if that already was
>the case in 4.8.25 and earlier: if compiled without slang, no mouse
>actions work anymore (has the curses code gone?)
>
> I can do more debugging if you can't pinpoint the change...
This is known: https://midnight-commander.org/ticket/4144
> 3.: you should add the version to AC_INIT, so that PACKAGE_VERSION
> gets set correctly during configure. If not, generated docs have
> 'mc-' instead of 'mc-$VERSION' (e.g. mc-4.8.25) as version in e.g.
> the pdf ;)
This is known too: https://midnight-commander.org/ticket/3603
> A possible patch might be:
>
> mc-4.8.26-fix_ac_version.patch
> diff '-bpurNx*~' g/configure.ac h/configure.ac
> --- g/configure.ac 2021-01-10 12:50:16.0 +0100
> +++ h/configure.ac 2021-01-11 13:56:25.382961865 +0100
> @@ -3,7 +3,8 @@ dnl Configure.in file for the Midnight C
> dnl
>
> AC_PREREQ(2.60)
> -AC_INIT([GNU Midnight Commander], [], [mc-devel@gnome.org])
> +m4_define(pkg_VERSION,[m4_esyscmd([sh ./ver.sh])])
> +AC_INIT([GNU Midnight Commander], [pkg_VERSION], [mc-devel@gnome.org])
> m4_pattern_forbid(MC_)
> AC_CONFIG_MACRO_DIR([m4])
> AC_CONFIG_AUX_DIR(config)
> diff '-bpurNx*~' g/ver.sh h/ver.sh
> --- g/ver.sh1970-01-01 01:00:00.0 +0100
> +++ h/ver.sh2021-01-11 13:54:30.0 +0100
> @@ -0,0 +1,2 @@
> +#!/bin/sh
> +awk -F'"' '/MC_CURRENT_VERSION/{printf("%s",$2);}' version.h
>
>
> (not using the external script get's you into quoting hell ;)
>
> I've seen that it's somewhat redundant, but possible the later setting
> of the version from version.h can be removed then, I've not looked
> into that yet.
--
Andrew
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.26-rc1
Hello,
On Sun, 10 Jan 2021, Yury V. Zaytsev wrote:
>TLDR; I would appreciate if you could please test the following tarball on
>your systems and report any blocker regressions as compared to the previous
>4.8.25 release:
Two things:
1. mcedit causes a SIGSEGV when jumping out via Ctrl-o, even if just
too _look_ at stuff, not doing anything on the (sub-)shell:
$ gdb /usr/bin/mcedit core.0-mcedit
[..]
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f16a96eaca6 in do_update_prompt ()
(gdb) bt
#0 0x7f16a96eaca6 in do_update_prompt ()
#1 0x7f16a96eb2b5 in do_subshell_chdir ()
#2 0x7f16a96eb4e7 in invoke_subshell ()
#3 0x7f16a9b1 in toggle_subshell ()
#4 0x7f16a96e4061 in edit_dialog_command_execute ()
#5 0x7f16a96e4813 in edit_dialog_callback ()
#6 0x7f16a9670ad4 in dlg_process_event ()
#7 0x7f16a9670e00 in dlg_run ()
#8 0x7f16a96e3b00 in edit_files ()
#9 0x7f16a9678717 in do_nc ()
#10 0x7f16a9664505 in main ()
2. I don't know if that's a current regression or if that already was
the case in 4.8.25 and earlier: if compiled without slang, no mouse
actions work anymore (has the curses code gone?)
I can do more debugging if you can't pinpoint the change...
Ah, yes:
$ mc --version
GNU Midnight Commander 4.8.25-154-g33c84e75e
Built with GLib 2.64.5
Built with S-Lang 2.3.2 with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs
Data types:
char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
I have the detailed compilation log (and no relevant local patches
were applied, one just added some tmux/alacritty stuff to misc/mc.lib,
the other just changes doxygen stuff to generate pdf and manpages if
wanted).
Oh, and
3.: you should add the version to AC_INIT, so that PACKAGE_VERSION
gets set correctly during configure. If not, generated docs have
'mc-' instead of 'mc-$VERSION' (e.g. mc-4.8.25) as version in e.g.
the pdf ;)
A possible patch might be:
mc-4.8.26-fix_ac_version.patch
diff '-bpurNx*~' g/configure.ac h/configure.ac
--- g/configure.ac 2021-01-10 12:50:16.0 +0100
+++ h/configure.ac 2021-01-11 13:56:25.382961865 +0100
@@ -3,7 +3,8 @@ dnl Configure.in file for the Midnight C
dnl
AC_PREREQ(2.60)
-AC_INIT([GNU Midnight Commander], [], [mc-devel@gnome.org])
+m4_define(pkg_VERSION,[m4_esyscmd([sh ./ver.sh])])
+AC_INIT([GNU Midnight Commander], [pkg_VERSION], [mc-devel@gnome.org])
m4_pattern_forbid(MC_)
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_AUX_DIR(config)
diff '-bpurNx*~' g/ver.sh h/ver.sh
--- g/ver.sh1970-01-01 01:00:00.0 +0100
+++ h/ver.sh2021-01-11 13:54:30.0 +0100
@@ -0,0 +1,2 @@
+#!/bin/sh
+awk -F'"' '/MC_CURRENT_VERSION/{printf("%s",$2);}' version.h
(not using the external script get's you into quoting hell ;)
I've seen that it's somewhat redundant, but possible the later setting
of the version from version.h can be removed then, I've not looked
into that yet.
-dnh
--
My claim-to-fame in that respect involved a training-room-full of Suns
and a little script that would, at suitable intervals, cause one Sun to
"ping" in the style of a WWII Navy ASDIC echosounder, while another
would randomly respond with the appropriate echo-reply-sound. -- Tanuki
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.26-rc1
On Sun, 10 Jan 2021 15:52:22 +0100 (CET) "Yury V. Zaytsev" wrote: > Hi there, > > TLDR; I would appreciate if you could please test the following tarball on > your systems and report any blocker regressions as compared to the > previous 4.8.25 release: > > https://www.midnight-commander.org/nopaste/tarball/mc-4.8.25-154-g33c84e75e.tar.xz > > $ sha256sum mc-4.8.25-154-g33c84e75e.tar.xz > ce5f965a9be603098eda65afd1aa149e285d903fe303fe907c6a5e88f28dd772 > mc-4.8.25-154-g33c84e75e.tar.xz > > I've built this tarball out of the latest master with translations from > Transifex pulled in on a fresh Fedora 33 VM, which I'm also going to use > to build the final release in about a week from now if nothing serious > comes up. Is there an option to tag release candidates just like releases and name/upload tarballs into expected locations just like releases? That would make pulling release candidates (at least) into Gentoo an almost automatic action. Otherwise I'm always spending some time to name candidate as 4.8.26_rc1 (or 4.8.25_p154, or something else) downstream to the point I decide not to package candidates to avoid user confusion. -- Sergei pgpFW2TGyFsq8.pgp Description: Цифровая подпись OpenPGP ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: Help testing release candidate / mc-4.8.26-rc1
Hi! On Sun, 10 Jan 2021, Yury V. Zaytsev wrote: > TLDR; I would appreciate if you could please test the following tarball on > your systems and report any blocker regressions as compared to the previous > 4.8.25 release: > > https://www.midnight-commander.org/nopaste/tarball/mc-4.8.25-154-g33c84e75e.tar.xz > > $ sha256sum mc-4.8.25-154-g33c84e75e.tar.xz > ce5f965a9be603098eda65afd1aa149e285d903fe303fe907c6a5e88f28dd772 > mc-4.8.25-154-g33c84e75e.tar.xz > > I've built this tarball out of the latest master with translations from > Transifex pulled in on a fresh Fedora 33 VM, which I'm also going to use to > build the final release in about a week from now if nothing serious comes up. Works fine for me. I tested most of the tickets. However, #3987 does not seems a quite right to me. Are you sure that errno after readdir() will not be EINTR all the time? I think is a possibility. Not very likely, but still there. Maybe a better implementation is to have a counter and if errno is EINTR after XXX readdir calls, just abort the readdir. Sincerely, Gabriel -- // Gabriel VLASIU // // OpenGPG-KeyID : 44952F15 // OpenGPG-Fingerprint: 4AC5 7C26 2FE9 02DA 4906 24B2 D32B 7ED7 4495 2F15 // OpenGPG-URL: http://www.vlasiu.net/public.key ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
