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
