Hi,
This blog
http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup-and-cloning-tools-under-mac-os-x/
has an explanation of all the kinds of file metadata that exists on MacOS X:
resource forks, creation date, ACLs, extended attributes.
Some of these (ACLs, extended attributes) also ex
"cp --help" says
--preserve[=ATTR_LIST] preserve the specified attributes (default:
mode,ownership,timestamps), if possible
additional attributes: context, links, all
but the info formatted documentation does not mention 'c
As you are probably aware, there are two authors named FIXME. In addition, both
David Ihnat and Richard Stallman appear twice, once with their middle initial
M., once without.
--
Michael Piefel
Humboldt-Universität zu Berlin
Institut für Informatik
___
"Michael Piefel" <[EMAIL PROTECTED]> wrote:
> As you are probably aware, there are two authors named FIXME. In addition,
> both David Ihnat and Richard Stallman appear twice, once with their middle
> initial M., once without.
Thank you for reporting that.
I am well aware of the FIXME problem, ho
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>> I've rebased the patch for the new `timeout` command
>>> against the latest tree, now that 6.12 has been released.
>>> I also fixed a couple of typos in the patch.
>>> It passes `make chec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I just noticed the addition of the timeout command:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=265c4b8
But was this hunk to configure.ac intentional? It isn't mentioned in
ChangeLog:
http://git.savannah.gnu.org/gitweb/?p=core
Eric Blake <[EMAIL PROTECTED]> wrote:
> I just noticed the addition of the timeout command:
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=265c4b8
>
> But was this hunk to configure.ac intentional? It isn't mentioned in
> ChangeLog:
> http://git.savannah.gnu.org/gitweb/?p=cor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/2/2008 7:05 AM:
|
| I need a tool to automatically verify that ChangeLog
| and diffs are consistent.
New enough git supports pre-commit hooks. I imagine we could probably
come up with a way to reject patches where the
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 6/2/2008 7:05 AM:
> |
> | I need a tool to automatically verify that ChangeLog
> | and diffs are consistent.
>
> New enough git supports pre-commit hooks. I imagine we could probably
> come up with a way to reject patches where t
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 6/2/2008 7:05 AM:
> |
> | I need a tool to automatically verify that ChangeLog
> | and diffs are consistent.
>
> New enough git supports pre-commit hooks. I imagine we could probably
> come up with a way to reject patches where t
Jim Meyering meyering.net> writes:
> >>>
> >>> http://www.pixelbeat.org/patches/coreutils-timeout.diff
>
> Thanks again!
> I've tweaked the log message and pushed the result.
This needs a patch before it can build on cygwin and other non-glibc platforms:
gcc -std=gnu99 -gdwarf-2 -Wall -Werror
Eric Blake <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>
>> >>>
>> >>> http://www.pixelbeat.org/patches/coreutils-timeout.diff
>>
>> Thanks again!
>> I've tweaked the log message and pushed the result.
>
> This needs a patch before it can build on cygwin and other non-glibc
>
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.
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
Version: 6.12.
If system `selinux/selinux.h' is compilable, coreutils always uses it
(does not build `selinux/selinux.h' in `lib'), and `src/install.c'
assumes that it always provides (correct) declaration of
`matchpathcon_init_prefix'. If system header does not declare it at
all, build of `ginst
-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
"Ilya N. Golubev" <[EMAIL PROTECTED]> wrote:
> Version: 6.12.
>
> If system `selinux/selinux.h' is compilable, coreutils always uses it
> (does not build `selinux/selinux.h' in `lib'), and `src/install.c'
> assumes that it always provides (correct) declaration of
> `matchpathcon_init_prefix'. If s
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
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
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
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
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
Eric Blake wrote:
> I just noticed the addition of the timeout command:
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=265c4b8
>
> But was this hunk to configure.ac intentional? It isn't mentioned in
> ChangeLog:
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit
Eric Blake <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>
>> >>>
>> >>> http://www.pixelbeat.org/patches/coreutils-timeout.diff
>>
>> Thanks again!
>> I've tweaked the log message and pushed the result.
>
> This needs a patch before it can build on cygwin and other non-glibc
>
Andreas Schwab suse.de> writes:
>
> Mike Frysinger gentoo.org> 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, j
Pádraig Brady draigBrady.com> writes:
> BTW why does gnulib require "program_name" to be exported?
The error module uses 'extern char * program_name'; this is provided by default
in glibc (via the name program_invocation_name, which is exported as part of
glibc), but for the rest of the world
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
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
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
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
-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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/2/2008 3:11 PM:
|> Sounds like a 'make syntax-check' rule on top of this patch would be
|> worthwhile, although I didn't tackle that...
|
| I did it with this, after normalizing all existing uses:
But you introduced war
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 6/2/2008 1:39 PM:
| Subject: [PATCH] accommodate older SELinux which lacks
matchpathcon_init_prefix
|
| * m4/jm-macros.m4: Check for matchpathcon_init_prefix.
| * src/install.c [!HAVE_MATCHPATHCON_INIT_PREFIX]
| (matchpath
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 6/2/2008 3:11 PM:
> |> Sounds like a 'make syntax-check' rule on top of this patch would be
> |> worthwhile, although I didn't tackle that...
> |
> | I did it with this, after normalizing all existing uses:
>
> But you introduced
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 6/2/2008 1:39 PM:
> | Subject: [PATCH] accommodate older SELinux which lacks
> matchpathcon_init_prefix
> |
> | * m4/jm-macros.m4: Check for matchpathcon_init_prefix.
> | * src/install.c [!HAVE_MATCHPATHCON_INIT_PREFIX]
> | (matc
36 matches
Mail list logo
