Hi, 在 2023-07-21星期五的 19:00 +0200，Vincent Lefevre写道： > On 2023-07-21 17:22:11 +0200, Vincent Lefevre wrote: > > The best solution would be to fix gnulib on the Debian side, IMHO. > > I wonder whether other packages are affected too. > [...] > > So, if I understand correctly, the fix in gnulib appeared between > > these two commits. But I don't see which change could affect the > > result. I could try to investigate. > > This was fixed in the following commit: > > ------------------------------------------------------------------------ > commit d4d8abb39eb02c555f062b1f83ffcfac999c582f > Author: Bruno Haible <br...@clisp.org> > Date: 2023-05-05 12:02:49 +0200 > > dirfd: Fix bogus override (regression 2023-04-26). > > Reported by Bjarni Ingi Gislason <bjarn...@simnet.is> in > <https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00040.html>. > > * m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change. > > diff --git a/ChangeLog b/ChangeLog > index aaffe12fc1..5f01a52535 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,10 @@ > +2023-05-05 Bruno Haible <br...@clisp.org> > + > + dirfd: Fix bogus override (regression 2023-04-26). > + Reported by Bjarni Ingi Gislason <bjarn...@simnet.is> in > + > <https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00040.html>. > + * m4/dirfd.m4 (gl_FUNC_DIRFD): Fix mistake in last change. > + > 2023-05-04 Bruno Haible <br...@clisp.org> > > c32swidth: Add tests. > diff --git a/m4/dirfd.m4 b/m4/dirfd.m4 > index d1ee2c7f61..7968b1287c 100644 > --- a/m4/dirfd.m4 > +++ b/m4/dirfd.m4 > @@ -1,4 +1,4 @@ > -# serial 27 -*- Autoconf -*- > +# serial 28 -*- Autoconf -*- > > dnl Find out how to get the file descriptor associated with an open DIR*. > > @@ -40,10 +40,6 @@ AC_DEFUN([gl_FUNC_DIRFD], > HAVE_DIRFD=0 > else > HAVE_DIRFD=1 > - dnl Replace only if the system declares dirfd already. > - if test $ac_cv_have_decl_dirfd = yes; then > - REPLACE_DIRFD=1 > - fi > dnl Replace dirfd() on native Windows, to support fdopendir(). > AC_REQUIRE([gl_DIRENT_DIR]) > if test $DIR_HAS_FD_MEMBER = 0; then > ------------------------------------------------------------------------ > > In the bug-gnulib discussion: > > https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00046.html > > Bernhard Voelker says: > > Gnulib commit 3f0950f65abb (2023-04-26) not only lead to build time > > issues, but also made e.g. coreutils' rm(1) fail: > > > > $ mkdir d && (cd d && seq 400000 | xargs touch ) > > > > $ rm -rf d > > rm: traversal failed: d: Operation not supported > > > > I can confirm that this gnulib commit d4d8abb39eb0 fixes the issue again. > > This is the same kind of error. > > But I can see: > > gnulib (20230615+stable-1) unstable; urgency=medium > > * QA upload. > * New upstream snapshot from stable branch stable-202301. > > -- Boyuan Yang <by...@debian.org> Tue, 20 Jun 2023 14:58:32 -0400 > > I've just rebuilt grep 3.11-1 with "debuild -i -us -uc -b", > but I still get the same issue with it. I'm wondering what > "stable branch stable-202301" means.
Looking at https://git.savannah.gnu.org/gitweb/?p=gnulib.git , gnulib upstream is now providing stable branches that only include important fixes. In Debian's package, I was tracking the stable-202301 branch. It is likely that this bugfix was not backported onto it. Anyway, I will look into it and see whether it affects Stable and Sid. Since gnulib upstream also opened stable-202307 branch, I will likely switch gnulib in Sid onto that branch, which should have included the fix that grep now needs. BTW: Is grep 3.11-1 using Debian-packaged gnulib anywere? I did not see a build-dependency in https://sources.debian.org/src/grep/3.11-1/debian/control/ . * If grep is indeed using it, please include the build-dep explicitly. * If not, your current grep issue is unrelated to Debian-packaged gnulib and you will need further debugging. Thanks, Boyuan Yang
signature.asc
Description: This is a digitally signed message part
