On Oct 4, 2007, at 3:21 AM, Bruno Haible wrote:
Hello Benoit,
I was looking for a portable replacement of `trunc' for systems where
it is not be available. I saw that gnulib had that (http://
www.gnu.org/software/gnulib/manual/html_node/trunc.html)
Well, there is a misunderstanding here. Th
On Oct 4, 2007, at 3:05 AM, Bruno Haible wrote:
Hello Benoit,
Benoit Sigoure wrote:
* doc/gnulib-tool.texi (CVS Issues): Rename as `SCM Issues' and
adjust accordingly.
I object to the use of term "SCM", because - as you can see from
http://en.wikipedia.org/wiki/scm - the term
When writing tests modules, when one forgets to write an EXTRA_DIST line,
some files belonging to the test are not packaged by "make dist". Let me
fix this by synthesizing the EXTRA_DIST line automatically, like it is
already done for normal modules.
2007-10-03 Bruno Haible <[EMAIL PROTECTED]>
Hello Benoit,
> I was looking for a portable replacement of `trunc' for systems where
> it is not be available. I saw that gnulib had that (http://
> www.gnu.org/software/gnulib/manual/html_node/trunc.html)
Well, there is a misunderstanding here. That doc says that
1) gnulib has no module sup
Hello Benoit,
Benoit Sigoure wrote:
> * doc/gnulib-tool.texi (CVS Issues): Rename as `SCM Issues' and
> adjust accordingly.
I object to the use of term "SCM", because - as you can see from
http://en.wikipedia.org/wiki/scm - the term SCM also means "Software
Configuration Management",
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 10/3/2007 8:26 AM:
>
> I'm leery of this.
> What if chroot works for non-privileged users on some type of system?
It works for all users on cygwin (seeing as how chroot isn't natively
provided by Windows, cygwin has no ab
Benoit SIGOURE wrote:
> >>> Is there some shorthand for this process, such as a "git-recover"
> >>> command?
> >>
> >> you can run git fsck and look for
> >> a dangling commit (which can be inspected with git show ) where
> >> you are most likely to find your stash (unless you run git-gc or this
>
Hi,
I was looking for a portable replacement of `trunc' for systems where
it is not be available. I saw that gnulib had that (http://
www.gnu.org/software/gnulib/manual/html_node/trunc.html) so I tried
to use it somehow. It's the first time I borrow something from
gnulib so I went through
* doc/gnulib-intro.texi (Steady Development): Mention the Git
* repository instead of the CVS one.
* doc/gnulib-tool.texi (CVS Issues): Rename as `SCM Issues' and
adjust accordingly.
* doc/gnulib.texi (Introduction): Capitalize `Git'.
* doc/maintain.t
> The change looks fine. You're welcome to commit it.
Committed.
Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> Wandering through http://www.gnu.org/software/gnulib/manual/
> gnulib.txt.gz in order to find how to get a replacement for non-
> portable `trunc', I found:
> "We [...] recommend to use the newest version of Gnulib from the CVS"
> Although there is a RO g
Wandering through http://www.gnu.org/software/gnulib/manual/
gnulib.txt.gz in order to find how to get a replacement for non-
portable `trunc', I found:
"We [...] recommend to use the newest version of Gnulib from the CVS"
Although there is a RO git-cvsserver, shouldn't this be changed to
adve
Hi,
I wrote:
> "git lost-found" does not work well for me: I stopped it after it ate
> 10 minutes of CPU time without producing a result.
It's not a bug, it's just slow:
$ git-fsck
dangling commit f62c4fa05422fd4fb8610bdb02a7160121657893
(took 4 sec)
$ git-lost-found
[f62c4fa05422fd4fb8610bdb02
Bruno Haible <[EMAIL PROTECTED]> wrote:
> The fpending module has no test in gnulib, but it has one in coreutils.
> How about moving that test to gnulib? So that e.g. m4's "make check"
> verifies it on all kinds of platforms.
>
> Here is a proposed patch for gnulib. On the coreutils side, if you wa
Hi Jim,
The fpending module has no test in gnulib, but it has one in coreutils.
How about moving that test to gnulib? So that e.g. m4's "make check"
verifies it on all kinds of platforms.
Here is a proposed patch for gnulib. On the coreutils side, if you want
to keep that test as part of the test
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> This patch to fpending.m4 should be useful for QNX. But I don't feel
> that it's safe committing it until someone with access to a QNX system has
> verified it. Do you have any testers in the QNX users camp?
I don't know of anyone who builds gn
Hi Jim,
This patch to fpending.m4 should be useful for QNX. But I don't feel
that it's safe committing it until someone with access to a QNX system has
verified it. Do you have any testers in the QNX users camp?
--- m4/fpending.m4.orig 2007-10-03 21:35:27.0 +0200
+++ m4/fpending.m4 2
Here's the unfinished and untested port to QNX of the stdio extension
modules. Since it's likely to be a better starting point for whomever
volunteers to support that platform than no port at all, I'm committing it.
2007-10-03 Bruno Haible <[EMAIL PROTECTED]>
Port the stdio extensions
On Wed, Oct 03, 2007 at 09:30:12PM +0200, Bruno Haible wrote:
> Sylvain Beucler wrote:
> > Hmm, that's too bad. If it's not done by default there's little chance
> > it'll actually be used, especially in distributions.
>
> Distributions are well served without --enable-relocatable.
The day I'll b
Sylvain Beucler wrote:
> Hmm, that's too bad. If it's not done by default there's little chance
> it'll actually be used, especially in distributions.
Distributions are well served without --enable-relocatable. The people for
whom --enable-relocatable are useful are IMO
- maintainers of a packag
On Wed, Oct 03, 2007 at 01:40:32PM +0200, Bruno Haible wrote:
> Hello Sylvain,
>
> Sylvain Beucler wrote:
> > I noticed that even if I imported the 'relocatable-prog' module,
> > ./configure still requires the user to type '--enable-relocatable' to
> > take this into account.
> >
> > I guess that
Martin Koeppe <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Oct 2007, Jim Meyering wrote:
>> Martin Koeppe <[EMAIL PROTECTED]> wrote:
>>> A question arises: How should one portably test for "root"? Neither
>>> "root" nor uid 0 seem to be a POSIX requirement. I found one solution
>>> so far, but I'm not s
Jim Meyering scripsit:
> What if chroot works for non-privileged users on some type of system?
That sounds extremely unlikely, as it is a great big security hole.
With such a chroot, an unprivileged process could put a fake root around
a setuid program, supplying it with a forged /etc/passwd and
On Wed, Oct 03, 2007 at 10:07:28AM -0400, Bruno Haible wrote:
> Sean Boudreau wrote:
> > If it were a simple matter of porting I would have done it
>
> It is a simple matter of porting. The code is already ported to GNU
> libc,
> *BSD, MacOS X, AIX, HP-UX, IRIX, OSF/1, Solaris, Cygwin, mingw, BeO
John Cowan <[EMAIL PROTECTED]> wrote:
> Jim Meyering scripsit:
>> What if chroot works for non-privileged users on some type of system?
> That sounds extremely unlikely, [...]
It's not so far-fetched.
There's a hint on the first lines of "info coreutils chroot":
`chroot' runs a command with a
On Wed, 3 Oct 2007, Jim Meyering wrote:
Martin Koeppe <[EMAIL PROTECTED]> wrote:
A question arises: How should one portably test for "root"? Neither
"root" nor uid 0 seem to be a POSIX requirement. I found one solution
so far, but I'm not sure how good it really is:
For shell scripts run:
$ /u
Martin Koeppe <[EMAIL PROTECTED]> wrote:
> A question arises: How should one portably test for "root"? Neither
> "root" nor uid 0 seem to be a POSIX requirement. I found one solution
> so far, but I'm not sure how good it really is:
>
> For shell scripts run:
> $ /usr/sbin/chroot / /bin/true
> If s
Martin Koeppe <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Sep 2007, Jim Meyering wrote:
>
>> Martin Koeppe <[EMAIL PROTECTED]> wrote:
>> ...
>>> And yes, I'll of course try a new coreutils/gnulib version (but I
>>> think in this case I shouldn't yet). Are there any coreutils snapshot
>>> .tar.gz avail
Sean Boudreau wrote:
> If it were a simple matter of porting I would have done it
It is a simple matter of porting. The code is already ported to GNU libc,
*BSD, MacOS X, AIX, HP-UX, IRIX, OSF/1, Solaris, Cygwin, mingw, BeOS, uClibc.
> Consider a system where FILE * is opaque which is possible wh
On Thu, 27 Sep 2007, Jim Meyering wrote:
Martin Koeppe <[EMAIL PROTECTED]> wrote:
...
And yes, I'll of course try a new coreutils/gnulib version (but I
think in this case I shouldn't yet). Are there any coreutils snapshot
.tar.gz available?
Yes. I made a new snapshot just a few hours ago, t
Jim, Eric,
> Wouldn't @command be better than @samp?
Yes, sure. You're right. Committed.
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=7bfb1880ea713532edaaed3386bc0a2ba45a28a6
Bruno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sean Boudreau on 10/3/2007 6:49 AM:
> Sorry, I thought we were still in the m4 realm.
Yes, it would be nice if m4 didn't have problems with the gnulib portion
of the testsuite on compliant platforms, for the part of gnulib that got
sucked
On Tue, Oct 02, 2007 at 09:19:32PM -0400, Bruno Haible wrote:
> Hello Sean,
>
> Sean Boudreau wrote:
> > Under QNX with 1.4.10 the only things that actually need
> > fpurge() and freading() are their tests. The tests fail but
> > in this context it doesn't matter. Or are you saying their
> > rol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/3/2007 6:05 AM:
> 2007-10-03 Bruno Haible <[EMAIL PROTECTED]>
>
> * doc/relocatable.texi: Use @samp instead of @program.
Wouldn't @command be better than @samp?
- --
Don't work too hard, make some time for fun
Bruno Haible <[EMAIL PROTECTED]> wrote:
> makeinfo of relocatable.texi yields this error:
>
> relocatable.texi:24: Unknown command `program'.
> relocatable.texi:24: Misplaced {.
> relocatable.texi:24: Misplaced }.
>
> @program is not documented in texinfo-4.11.
>
> Fixing it like this:
>
> 2007-10-
makeinfo of relocatable.texi yields this error:
relocatable.texi:24: Unknown command `program'.
relocatable.texi:24: Misplaced {.
relocatable.texi:24: Misplaced }.
relocatable.texi:34: Unknown command `program'.
relocatable.texi:34: Misplaced {.
relocatable.texi:34: Misplaced }.
@program is not d
Hello Sylvain,
Sylvain Beucler wrote:
> I noticed that even if I imported the 'relocatable-prog' module,
> ./configure still requires the user to type '--enable-relocatable' to
> take this into account.
>
> I guess that most users won't notice this switch, and compile a
> non-relocatable binary.
37 matches
Mail list logo
