From yury at shurup.com Sun Mar 20 12:15:41 2022 From: yury at shurup.com (Yury V. Zaytsev) Date: Sun, 20 Mar 2022 13:15:41 +0100 (CET) Subject: Help testing release candidate / mc-4.8.28-rc1 Message-ID: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> 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.27 release: https://www.midnight-commander.org/nopaste/tarball/mc-4.8.28-pre1.tar.xz $ sha256sum mc-4.8.28-pre1.tar.xz e6b0423e47225e78fb59968cc45c0b004676a17ab45d7f304a091121326bfb77 mc-4.8.28-pre1.tar.xz I've built this tarball out of the latest master with translations from Transifex pulled in on a fresh Fedora 35 VM, which I'm also going to use to build the final release in about a week from now if nothing serious comes up. Many thanks! -- Sincerely yours, Yury V. Zaytsev From oswald.buddenhagen at gmx.de Sun Mar 20 14:22:14 2022 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Sun, 20 Mar 2022 15:22:14 +0100 Subject: Help testing release candidate / mc-4.8.28-rc1 In-Reply-To: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> References: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> Message-ID: On Sun, Mar 20, 2022 at 01:15:41PM +0100, 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.27 release: > i tested master instead: find.c: In function ?find_cmd?: find.c:1837:28: warning: ?start_dir_len? may be used uninitialized in this function [-Wmaybe-uninitialized] 1837 | p = name + (size_t) start_dir_len; | ^~~~~~~~~~~~~~~~~~~~~~ find.c:1897:13: note: ?start_dir_len? was declared here 1897 | ssize_t start_dir_len; | ^~~~~~~~~~~~~ coord_cache.c: In function ?mcview_ccache_add_entry?: coord_cache.c:97:5: warning: ?g_memdup? is deprecated: Use 'g_memdup2' instead [-Wdeprecated-declarations] 97 | cache->cache[pos] = g_memdup (entry, sizeof (*entry)); | ^~~~~ In file included from /usr/include/glib-2.0/glib.h:82, from ../../lib/global.h:66, from coord_cache.c:57: /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here 257 | gpointer g_memdup (gconstpointer mem, | ^~~~~~~~ `mc -P $file` doesn't work any more when the file already exists (which is of course the case after file=`mktemp`). From aborodin at vmail.ru Sun Mar 20 15:59:32 2022 From: aborodin at vmail.ru (Andrew Borodin) Date: Sun, 20 Mar 2022 18:59:32 +0300 Subject: Help testing release candidate / mc-4.8.28-rc1 In-Reply-To: References: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> Message-ID: On Sun, 20 Mar 2022 15:22:14 +0100 Oswald Buddenhagen via mc-devel wrote: > On Sun, Mar 20, 2022 at 01:15:41PM +0100, 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.27 release: > > > i tested master instead: > > find.c: In function ?find_cmd?: > find.c:1837:28: warning: ?start_dir_len? may be used uninitialized in this function [-Wmaybe-uninitialized] > 1837 | p = name + (size_t) start_dir_len; > | ^~~~~~~~~~~~~~~~~~~~~~ > find.c:1897:13: note: ?start_dir_len? was declared here > 1897 | ssize_t start_dir_len; > | ^~~~~~~~~~~~~ This isn't critical. start_dir_len is an output of find_parameters(). > coord_cache.c: In function ?mcview_ccache_add_entry?: > coord_cache.c:97:5: warning: ?g_memdup? is deprecated: Use 'g_memdup2' instead [-Wdeprecated-declarations] > 97 | cache->cache[pos] = g_memdup (entry, sizeof (*entry)); > | ^~~~~ > In file included from /usr/include/glib-2.0/glib.h:82, > from ../../lib/global.h:66, > from coord_cache.c:57: > /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here > 257 | gpointer g_memdup (gconstpointer mem, > | ^~~~~~~~ This is not critical too. https://midnight-commander.org/ticket/4270#comment:12 > `mc -P $file` doesn't work any more when the file already exists (which is of course the case after file=`mktemp`). Indeed. file is opened with O_CREAT | O_EXCL flags. In this case, as written in open(2), O_EXCL Ensure that this call creates the file: if this flag is specified in conjunction with O_CREAT, and pathname already exists, then open() fails with the error EEXIST. A following patch is proposed: diff --git a/src/main.c b/src/main.c index 3a33dfb59..a4910349a 100644 --- a/src/main.c +++ b/src/main.c @@ -492,6 +492,10 @@ main (int argc, char *argv[]) last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_CREAT | O_TRUNC | O_EXCL, S_IRUSR | S_IWUSR); + + if (last_wd_fd == -1 && errno == EEXIST) + last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_TRUNC, S_IRUSR | S_IWUSR); + if (last_wd_fd != -1) { ssize_t ret1; -- Andrew From oswald.buddenhagen at gmx.de Sun Mar 20 18:12:13 2022 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Sun, 20 Mar 2022 19:12:13 +0100 Subject: Help testing release candidate / mc-4.8.28-rc1 In-Reply-To: References: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> Message-ID: On Sun, Mar 20, 2022 at 06:59:32PM +0300, Andrew Borodin wrote: >On Sun, 20 Mar 2022 15:22:14 +0100 Oswald Buddenhagen via mc-devel > wrote: >> `mc -P $file` doesn't work any more when the file already exists >> (which is of course the case after file=`mktemp`). > >Indeed. > >A following patch is proposed: > >diff --git a/src/main.c b/src/main.c >index 3a33dfb59..a4910349a 100644 >--- a/src/main.c >+++ b/src/main.c >@@ -492,6 +492,10 @@ main (int argc, char *argv[]) > > last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_CREAT | O_TRUNC | O_EXCL, > S_IRUSR | S_IWUSR); >+ >+ if (last_wd_fd == -1 && errno == EEXIST) >+ last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_TRUNC, S_IRUSR | S_IWUSR); >+ > if (last_wd_fd != -1) > { > ssize_t ret1; > that seems overly complicated - why not just drop the O_EXCL? at least i can't see an obvious reason for having it in the first place. anyway, i wonder why i ran into this only recently, given that this behavior is actually rather ancient. probably has something to do with me porting the wrapper function from tempfile to mktemp (as debian started to complain about deprecation), though the replacement itself couldn't have caused it. From aborodin at vmail.ru Mon Mar 21 06:44:45 2022 From: aborodin at vmail.ru (Andrew Borodin) Date: Mon, 21 Mar 2022 09:44:45 +0300 Subject: Help testing release candidate / mc-4.8.28-rc1 In-Reply-To: References: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> Message-ID: On Sun, 20 Mar 2022 19:12:13 +0100 Oswald Buddenhagen via mc-devel wrote: > On Sun, Mar 20, 2022 at 06:59:32PM +0300, Andrew Borodin wrote: > >On Sun, 20 Mar 2022 15:22:14 +0100 Oswald Buddenhagen via mc-devel > > wrote: > >> `mc -P $file` doesn't work any more when the file already exists > >> (which is of course the case after file=`mktemp`). > > > >Indeed. > > > >A following patch is proposed: > > > >diff --git a/src/main.c b/src/main.c > >index 3a33dfb59..a4910349a 100644 > >--- a/src/main.c > >+++ b/src/main.c > >@@ -492,6 +492,10 @@ main (int argc, char *argv[]) > > > > last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_CREAT | O_TRUNC | O_EXCL, > > S_IRUSR | S_IWUSR); > >+ > >+ if (last_wd_fd == -1 && errno == EEXIST) > >+ last_wd_fd = open (mc_args__last_wd_file, O_WRONLY | O_TRUNC, S_IRUSR | S_IWUSR); > >+ > > if (last_wd_fd != -1) > > { > > ssize_t ret1; > > > that seems overly complicated - why not just drop the O_EXCL? at least i can't see an obvious > reason for having it in the first place. Ok. > anyway, i wonder why i ran into this only recently, given that this behavior is actually > rather ancient. probably has something to do with me porting the wrapper function from > tempfile to mktemp (as debian started to complain about deprecation), though the replacement > itself couldn't have caused it. mc-wrapper.sh doesn't create a file. It creates a file name only. then mc creates a file with given file name, and everything works fine. Wrapper patched to use mktemp creates a file, and mc tries to open an existing file and fails. A workaround is to apply `mktemp -u` or even `mktemp -u -t`, but is it portable? -- A. From oswald.buddenhagen at gmx.de Mon Mar 21 11:00:25 2022 From: oswald.buddenhagen at gmx.de (Oswald Buddenhagen) Date: Mon, 21 Mar 2022 12:00:25 +0100 Subject: Help testing release candidate / mc-4.8.28-rc1 In-Reply-To: References: <42486fc-94d0-7a4c-b8d2-fb2a39c3e7a@shurup.com> Message-ID: On Mon, Mar 21, 2022 at 09:44:45AM +0300, Andrew Borodin wrote: >mc-wrapper.sh doesn't create a file. i know, but i'm using my own function (for historical reasons): mc () { local tf=$(mktemp); /usr/local/bin/mc -P $tf "$@" && test -r $tf && cd "$(<$tf)"; rm -f $tf } ... which, *cannot* have ever worked. it's somewhat unsurprising that i didn't notice, as my kde-based workflows don't rely on it working. still, it seemed beizarre that i did't notice for a whole two decades, so i looked around ... and each of my two other machines has a different working version: one has tf=/tmp/mc-`whoami`/wd$$, which i presume is the oldest one, and one has tf=$XDG_RUNTIME_DIR/mc-wd-$$. so i suppose i'm sleepwalking. :'-D >A workaround is to apply `mktemp -u` or even `mktemp -u -t`, but is it >portable? > dunno. but it would be a mediocre idea anyway, and absolutely terrible without the O_EXCL (because symlink attacks). but anyway, this is an entirely self-made problem. sorry for the noise. From yury at shurup.com Sun Mar 27 13:15:38 2022 From: yury at shurup.com (Yury V. Zaytsev) Date: Sun, 27 Mar 2022 15:15:38 +0200 (CEST) Subject: Midnight Commander 4.8.28 released Message-ID: <8e606a69-942d-f886-8bde-bfeed36fcc22@shurup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I'm glad to announce the immediate availability of mc-4.8.28, a maintenance and bugfix release! We have fixed number of bugs in various subsystems, most notably a long-standing problem of mc being slow when moving large file trees (thanks to Sergei Trofimovich!). Other than that, we have finally completely removed half-broken, outdated and insecure SMB support. We recommend using one of the many current VFS solutions to work with Windows shares instead. For a detailed list of changes since the last release, please refer to the release notes. An upgrade is advised to benefit from these improvements! Download page: http://ftp.midnight-commander.org/?C=N;O=D Release notes: http://www.midnight-commander.org/wiki/NEWS-4.8.28 Unfortunately, Apple M1 is still not supported directly, the necessary changes will hopefully make it in Fedora 36, which we will be able to use as a build system for the next release. Until then, please re-bootstrap the build system on Mac or use the following workaround: CFLAGS="-target arm64-apple-macos12" \ ./configure \ --host=aarch64-apple-darwin \ --target=aarch64-apple-darwin \ --build=aarch64-apple-darwin As usual, thanks to Andrew Borodin, who was the main driving force behind this release, as well as all of our contributors, including translators. Have fun with this new release! Z. - -- Sincerely yours, Yury V. Zaytsev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJiQGOAAAoJEPci7nm8u+DvpgkQAIAFWAxHrvq/JicDkRKGT8fg 9HvTuVddGtGD1jFkSp50zJXmVZDBZCI+Yn+/q0AYPvutpgwYt2fGtQRVmlWvNfmW vI3zF9VlAgLx5tsvYXeKnM4qP18xh8V7CQO4Ndkf85kf6kAhRddYcxuHOP5oq9Gg vboLr59Bp6qsGMwpSQOMymdBYNbYarC1yJZ+nmabT2mqL1VUArqnm/XYdtYwR0ef Vm5S9OQKysnPJcdR68+I0SZYQdA3wCaCWTRNnLsay4ofdtY/w+OktHteVWnDdpK2 Qkb+QuV6E4ZacTcNRCp28s19gAXoLsVuqMqSMzDfMvNnbnBz6xTPdNjoA1BhyY2K 45RUJCdEy+LNOSlq8gX5Y12GXsArbkTn6935rUSlHUaZmYnfpWYT5k9wP/c++Orc khpI0YZKBpo2qiale3mO0CsG9wp6ARy6g+dokheHcevL8/4tkdWe8lYIEXXUf8QL +M+CKOBuSMxy2H7w+k7lB1jFyUld+aLztz7Gypjqnu+lJ8i2+0+tWnsTOLLiNFkp d9YM7t85JSgS7pij7yPvMdlUE318A85gZOFJjgc50MMRLMKkTuiQwDBPnUGaw8Hr 5YHLD1hfzJU6iMTE2lpLctmMcS6NjeCKJ8WrxmXdquM/m11OjZRLHE7C+xyxqABK z5f6PVvRfiJWIlFVJEmK =xj+I -----END PGP SIGNATURE----- From yury at shurup.com Mon Mar 28 12:55:25 2022 From: yury at shurup.com (Yury V. Zaytsev) Date: Mon, 28 Mar 2022 14:55:25 +0200 (CEST) Subject: Midnight Commander 4.8.28 released In-Reply-To: <230d2c07-39cf-6b69-10ad-a690fa160be0@reagle.org> References: <8e606a69-942d-f886-8bde-bfeed36fcc22@shurup.com> <230d2c07-39cf-6b69-10ad-a690fa160be0@reagle.org> Message-ID: <5faf7a79-566c-d1a0-14d6-5b927c8ee48@shurup.com> On Mon, 28 Mar 2022, Joseph Reagle wrote: > Hi, I've looked in the release notes, but I don't see anything related to > reopening [4198]? Why would there be anything regarding reopening this ticket in the release notes? The support for zsh is unfortunately flakey since a couple of releases already. There is an open ticket #3121, which I mentioned in #4198, but my answer was ignored so far. -- Sincerely yours, Yury V. Zaytsev