Re: [PATCH 2/2] Add missing argz_* functions from glibc

* Bob Friesenhahn wrote on Tue, Jun 03, 2008 at 03:29:57AM CEST: > On Mon, 2 Jun 2008, Eric Blake wrote: >> >> What would the libtool folks think of a patch to make libtool start >> depending on gnulib, and make gnulib the master repository for the argz >> replacements? I'm not convinced that dive

Re: [PATCH 2/2] Add missing argz_* functions from glibc

On Mon, 2 Jun 2008, Eric Blake wrote: What would the libtool folks think of a patch to make libtool start depending on gnulib, and make gnulib the master repository for the argz replacements? I'm not convinced that diverging libtool and gnulib is the best route yet, but I'm also not sure that l

Re: touch and utimens troubles on new/old software combinations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Schwab on 6/2/2008 3:57 PM: | Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | |> Mike, I thought the *at wrappers fell back to emulation if the |> syscalls were missing. Is that impossible for utimensat? | | Emulating utimensat i

Re: touch and utimens troubles on new/old software combinations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Mike Frysinger on 6/2/2008 3:32 PM: | On Monday 02 June 2008, Andreas Schwab wrote: |> Mike Frysinger <[EMAIL PROTECTED]> writes: |>> also after reading it, i dont think gnu/stubs.h would help in this |>> particular case. gnulib would ne

Re: [PATCH 2/2] Add missing argz_* functions from glibc

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to David Lutterkort on 6/2/2008 10:52 AM: | On Mon, 2008-06-02 at 14:00 +0200, Jim Meyering wrote: |> If I hear no objection soon, I will sync gnulib's argz.c |> directly from glibc, using something like the above. |> Then, gnulib and libtoo

Re: system(), Solaris, and the 'execute' module

Eric Blake wrote: > it could even allow a configure-time option for > mingw to pick a POSIX shell (particularly when targetting an MSYS build, > where such a shell is known to exist), rather than being hard-coded to the > current 'cmd /c' provided by system(). But it might also introduce > difficu

acl: new function for testing triviality of ACL

Hi Jim, In you asked to unify the ACL triviality tests used in copy-acl.c and file-has-acl.c. This patch does it, at least for the POSIX-draft like APIs. The other APIs will need different auxiliary functions, since they don't ha

acl: #if-ology

In preparation for the other ACL APIs: This puts a large #if USE_ACL # if HAVE_ACL_GET_FILE ... # endif #endif around the declarations of acl-entries.h which are specific to the POSIX-draft like API. I'm also starting to simplify things like HAVE_ACL_GET_FILE && HAVE_ACL_FREE to HA

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Bob Proulx wrote: > Daniel Jacobowitz wrote: > > Bob Proulx wrote: > > > Most common systems only support backward compatibility. I have not > > > heard of a system which supported forward compatibility. > > > > > > In other words, compiling on a platform usually results in

Re: touch and utimens troubles on new/old software combinations

Daniel Jacobowitz wrote: > Bob Proulx wrote: > > Most common systems only support backward compatibility. I have not > > heard of a system which supported forward compatibility. > > > > In other words, compiling on a platform usually results in an > > executable that only runs on that version or

acl: improve Tru64 support

Hi Jim, On Tru64, when TMPDIR is set to /tmp, the 3 tests pass. However, when TMPDIR is set to an NFS-mounted directory, the tests fail: setacl: tmpfile0: can't set acl: Operation not supported on socket PASS: test-file-has-acl.sh /home/haible/testdir0/build/gltests/test-set-mode-acl: setting per

acl: make acl_entries work reliably

Hi Jim, In my tests, I found that the textual representation of ACLs varies much more than the API used to access the ACLs. The acl_entries() function, currently, converts the ACL to a string whose format is undocumented and then starts counting newlines. This is already known to go wrong on IRIX

Re: acl: refactor error messages in copy-acl.c

Jim Meyering wrote: > > * lib/copy-acl.c (qcopy_acl): New function, extracted from copy_acl. > > (copy_acl): Just a wrapper around qcopy_acl that emits the error > > messages. > > Obviously an improvement, and looks correct. > Go ahead. Thanks! Applied, together with a corresponding

Re: touch and utimens troubles on new/old software combinations

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > Mike, I thought the *at wrappers fell back to emulation if the > syscalls were missing. Is that impossible for utimensat? Emulating utimensat is rather difficult, due to the UTIME_NOW/UTIME_OMIT feature. Andreas. -- Andreas Schwab, SuSE Labs, [E

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Andreas Schwab wrote: > Mike Frysinger <[EMAIL PROTECTED]> writes: > > also after reading it, i dont think gnu/stubs.h would help in this > > particular case. gnulib would need a runtime test to detect that > > utimensat() is actually not available. > > That should be prett

Re: touch and utimens troubles on new/old software combinations

Mike Frysinger <[EMAIL PROTECTED]> writes: > also after reading it, i dont think gnu/stubs.h would help in this particular > case. gnulib would need a runtime test to detect that utimensat() is > actually not available. That should be pretty easy, just fall through to the fallback code when er

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Daniel Jacobowitz wrote: > On Mon, Jun 02, 2008 at 01:50:13PM -0600, Bob Proulx wrote: > > Jim Meyering wrote: > > > Mike Frysinger wrote: > > > > for example, if you're running a recent version of glibc (say 2.7) > > > > compiled against recent kernel headers (say 2.6.25) b

Re: touch and utimens troubles on new/old software combinations

On Monday 02 June 2008, Jim Meyering wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > a recent gnulib commit (faeb3e6b21...) causes trouble for some packages > > (such as touch in coreutils) on certain combinations of software. for > > example, if you're running a recent version of glibc (sa

Re: touch and utimens troubles on new/old software combinations

On Mon, Jun 02, 2008 at 01:50:13PM -0600, Bob Proulx wrote: > Jim Meyering wrote: > > Mike Frysinger wrote: > > > for example, if you're running a recent version of glibc (say 2.7) > > > compiled against recent kernel headers (say 2.6.25) but execute on > > > an older kernel (say 2.6.18), then the

Re: touch and utimens troubles on new/old software combinations

Jim Meyering wrote: > Mike Frysinger wrote: > > for example, if you're running a recent version of glibc (say 2.7) > > compiled against recent kernel headers (say 2.6.25) but execute on > > an older kernel (say 2.6.18), then the resulting touch binary will > > attempt to use utimensat() which fails

Re: touch and utimens troubles on new/old software combinations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 6/2/2008 12:43 PM: | I'm afraid the best advice I can give you is to run the tools on the same | (or newer) version of the system on which you configured the package. Or configure with ac_cv_func_futimens=no ac_cv_func_ut

Re: touch and utimens troubles on new/old software combinations

Mike Frysinger <[EMAIL PROTECTED]> wrote: > a recent gnulib commit (faeb3e6b21...) causes trouble for some packages (such > as touch in coreutils) on certain combinations of software. for example, if > you're running a recent version of glibc (say 2.7) compiled against recent > kernel headers (say

touch and utimens troubles on new/old software combinations

a recent gnulib commit (faeb3e6b21...) causes trouble for some packages (such as touch in coreutils) on certain combinations of software. for example, if you're running a recent version of glibc (say 2.7) compiled against recent kernel headers (say 2.6.25) but execute on an older kernel (say 2.

Re: [PATCH 2/2] Add missing argz_* functions from glibc

On Mon, 2008-06-02 at 14:00 +0200, Jim Meyering wrote: > If I hear no objection soon, I will sync gnulib's argz.c > directly from glibc, using something like the above. > Then, gnulib and libtool can evolve separately, if needed. > > However, I'd really like to hear that at least one owner of > an

Re: GNUMakefile: don't fail if there is no .tarball-version

Simon Josefsson <[EMAIL PROTECTED]> wrote: > 'make dist' gets into a infloop in gnulib daily builds for me since > there is no .tarball-version file. This should fix it. Ok to push? Hi Simon, Thanks for the report. In daily builds of gnulib itself? built how? In normal practice, the .tarball-

GNUMakefile: don't fail if there is no .tarball-version

'make dist' gets into a infloop in gnulib daily builds for me since there is no .tarball-version file. This should fix it. Ok to push? /Simon 2008-06-02 Simon Josefsson <[EMAIL PROTECTED]> * top/GNUmakefile: Don't infloop if .tarball-version doesn't exist. diff --git a/top/GNUmakefi

Re: [Bug-tar] [GNU tar 1.20] testsuite: 2 7 8 13 14 16 17 22 28 29 44 45 46 48 51 52 61 63 64 65 67 68 69 70 71 72 73 74 failed

On Mon, 02 Jun 2008 06:01:59 -0600, Eric Blake <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to H.Merijn Brand on 5/21/2008 6:53 AM: > |> | So obviously fseeko () (and.or fseek ()) are severely borked when > |> | called as first call after fopen (), ev

Re: system(), Solaris, and the 'execute' module

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/1/2008 3:58 AM: | What about OSF/1 4.0 and 5.1? On these systems, CONFIG_SHELL gets set to | /bin/ksh. I take this as an indication that /bin/sh is not POSIX conforming | either. The manual pages of system() and popen()

Re: [Bug-tar] [GNU tar 1.20] testsuite: 2 7 8 13 14 16 17 22 28 29 44 45 46 48 51 52 61 63 64 65 67 68 69 70 71 72 73 74 failed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to H.Merijn Brand on 5/21/2008 6:53 AM: |> | So obviously fseeko () (and.or fseek ()) are severely borked when |> | called as first call after fopen (), even if seek_offset == 0. |> |> Are you using the gnulib replacement for fseek/fseeko, o

Re: [PATCH 2/2] Add missing argz_* functions from glibc

Jim Meyering <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: > >> Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >>> Hi David, >> ... + err = __argz_append (&dst, &dst_len, src, (arg - src)); >>> >>> Shouldn't this be argz_append? How come you don't get a lin

Re: acl: rework platform support macro

> > * m4/acl.m4 (gl_FUNC_ACL): Separate the POSIX-like and the Solaris > > tests. Test for libpacl, needed for OSF/1. Test for extended ACLs, > > needed for MacOS X. Test for HP-UX API. Test for newer and older AIX > > APIs. > > > > OK to commit? > > Yes, please. Applied, together

Re: acl: rework platform support macro

Bruno Haible <[EMAIL PROTECTED]> wrote: > Here's the first proposed part: rework acl.m4 > - so that it detects all known ACL flavours (except native Woe32), > - for maintainability: put the tests one after an other. Currently the > test for POSIX-draft-like platform is buried inside an AC_S

Re: acl: refactor error messages in copy-acl.c

Bruno Haible <[EMAIL PROTECTED]> wrote: > After adding support for all platforms, copy-acl.c contains 7 times the error > message regarding the source file, and 11 times the error message regarding > the destination file. This begs for refactoring. Doing this refactoring > ahead of the other change

Re: acl: new tests

Bruno Haible <[EMAIL PROTECTED]> wrote: > Hi Jim, > > Now I've got support for ACL for these platforms: > Linux, FreeBSD, MacOS X, Tru64, IRIX (POSIX like API), > Solaris, probably also Cygwin (Solaris API), > HP-UX, > AIX. > > For the start, I added the unit tests. It will certainly break

[PATCH] announce-gen: use a better key-server host name

FYI, just pushed: >From 3825e896292608b8d225a2ea10e54c45a6867c0b Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Mon, 2 Jun 2008 11:32:02 +0200 Subject: [PATCH] announce-gen: use a better key-server host name * build-aux/announce-gen (main): Recommend keys.gnupg.net, since i

Re: coreutils-6.12 released

Werner Koch <[EMAIL PROTECTED]> wrote: > Hi Jim, > > On Sun, 1 Jun 2008 12:15, [EMAIL PROTECTED] said: >> gpg --keyserver wwwkeys.pgp.net --recv-keys B9AB9A16 > > I suggest that you use > >--keyserver keys.gnupg.net > > in the future. We have control over this domain and can easily add