Re: Expose openat(2), etc in libc

2011-07-15 Thread Matthew Dempsky
On Fri, Jul 15, 2011 at 10:51:19AM +, Christian Weisgerber wrote: > Done. A grand total of three ports failed: sysutils/bacula, > misc/findutils, net/rsync. All fixed in the respective port and/or > by matthew's additional work. > > As far as ports are concerned, the diff collection to > - e

Re: Expose openat(2), etc in libc

2011-07-15 Thread Christian Weisgerber
Stuart Henderson wrote: > > Now that all of the new AT_* flags are supported, it's okay to expose > > openat(2), etc. in libc. > > > > This will need at least a minor libc bump (not included below). I > > know martynas@ has a major bump planned for libc

Re: Expose openat(2), etc in libc

2011-07-14 Thread Matthew Dempsky
On Thu, Jul 14, 2011 at 3:10 PM, Christian Weisgerber wrote: > POSIX says utimensat() should be declared in . Yep, that's fixed in my local tree too. (Same goes for futimens(2) in my UTIME_* diff that I also mailed out.)

Re: Expose openat(2), etc in libc

2011-07-14 Thread Christian Weisgerber
Matthew Dempsky wrote: > Index: include/unistd.h > === > RCS file: /home/mdempsky/anoncvs/cvs/src/include/unistd.h,v > retrieving revision 1.64 > diff -u -p -r1.64 unistd.h > --- include/unistd.h 3 Jul 2011 18:51:01 - 1.64

Re: Expose openat(2), etc in libc

2011-07-12 Thread Matthew Dempsky
On Tue, Jul 12, 2011 at 10:45:00PM +, Christian Weisgerber wrote: > The test does > > ln -s conftest.no-such conftest.dangle > > and then runs this program: > > ---> > #include > #include > #include > #include > #include > int > main () > { > return (fchownat (AT_FDCWD,

Re: Expose openat(2), etc in libc

2011-07-12 Thread Ted Unangst
On Tue, Jul 12, 2011, Christian Weisgerber wrote: > Matthew Dempsky wrote: > >> Now that all of the new AT_* flags are supported, it's okay to expose >> openat(2), etc. in libc. > > ... revealing that the gnulib configure tests think that our > fchownat() is bro

Re: Expose openat(2), etc in libc

2011-07-12 Thread Christian Weisgerber
Matthew Dempsky wrote: > Now that all of the new AT_* flags are supported, it's okay to expose > openat(2), etc. in libc. ... revealing that the gnulib configure tests think that our fchownat() is broken. The test does ln -s conftest.no-such conftest.dangle and then runs t

Re: Expose openat(2), etc in libc

2011-07-08 Thread Stuart Henderson
On 2011/07/08 03:51, Matthew Dempsky wrote: > On Fri, Jul 8, 2011 at 3:45 AM, Stuart Henderson wrote: > > On 2011/07/08 01:53, Matthew Dempsky wrote: > >> Now that all of the new AT_* flags are supported, it's okay to expose > >> openat(2), etc. in libc. > >

Re: Expose openat(2), etc in libc

2011-07-08 Thread Matthew Dempsky
On Fri, Jul 8, 2011 at 3:45 AM, Stuart Henderson wrote: > On 2011/07/08 01:53, Matthew Dempsky wrote: >> Now that all of the new AT_* flags are supported, it's okay to expose >> openat(2), etc. in libc. >> >> This will need at least a minor libc bump (not included

Re: Expose openat(2), etc in libc

2011-07-08 Thread Stuart Henderson
On 2011/07/08 01:53, Matthew Dempsky wrote: > Now that all of the new AT_* flags are supported, it's okay to expose > openat(2), etc. in libc. > > This will need at least a minor libc bump (not included below). I > know martynas@ has a major bump planned for libc, so I figure

Expose openat(2), etc in libc

2011-07-08 Thread Matthew Dempsky
Now that all of the new AT_* flags are supported, it's okay to expose openat(2), etc. in libc. This will need at least a minor libc bump (not included below). I know martynas@ has a major bump planned for libc, so I figure it makes sense to either go before that or ride the same bump. Opi