This is due to the line
#print-this-article, #gplv3-dogear, .netscape4, #sidebar,
#navigation-bar, #fsflinks, #gnulogo, #dbdlogo, #links, #translations,
#searcher{display: none !important;}
in gnu-print.css.
Matt Lee <[EMAIL PROTECTED]>, the chief GNU webmaster these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sean Boudreau on 9/30/2007 4:10 PM:
> Hello:
Hello Sean, and adding bug-gnulib,
>
> Would it be possible to not bring in freading.c and fpurge.c
> and to disable the associated tests if fflush() behaves as
> you expect?
For m4 1.4.x: I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Martin Koeppe on 9/30/2007 9:38 AM:
> where do I find test-strerror.c? I looked in the coreutils snapshot and
> in gnulib cvs to no avail.
Which cvs repository? Gnulib is now stored in git, and the CVS repository
changed:
http://lists.gn
I propose to make Eric Blake an admin of the gnulib project at
...
operating in "handle the mail backlog" mode.
Since apparently everyone is in agreement, I went ahead and checked the
admin box for ericb on the gnulib members' page so you guys could get
back to your mail backlog :).
On Sep 30, 2007, at 9:41 PM, Bruno Haible wrote:
it should be
possible to create a custom [merge "cl-merge"] in your git config
file,
which points to a script designed specifically for resolving
changelog
conflicts
I would love such a script, instead of constantly having to do
conflict
> it should be
> possible to create a custom [merge "cl-merge"] in your git config file,
> which points to a script designed specifically for resolving changelog
> conflicts
I would love such a script, instead of constantly having to do conflict
resolution at the top of ChangeLog.
Bruno
Hello Benoit,
> You shouldn't pull if you want to rebase. Read man git-pull, it
> clearly states that pull = fetch + merge in current branch. If you
> want to rebase, you don't want to merge. That's why you had to solve
> conflicts twice (once for merge, once for rebase). The resulting
On Sep 30, 2007, at 4:48 PM, Bruno Haible wrote:
Hello Jim,
- Did "git pull". It told me:
Then (everything is committed), you switch to the trunk and pull
(update from public repo) from there:
git checkout master
git pull
then go back to your branch and use git-rebase to make your br
Hi Eric,
On Sat, 29 Sep 2007, Eric Blake wrote:
Wait with the change! I just tested strerror() and strerror_r() on
Interix, and they already report "Unknown error: 4294967294" for e.g.
-2. Sorry.
Does the test-strerror.c program pass without the use of a replacement?
If so, then maybe the ea
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
> Right?
That sounds reasonable.
I usually switch to master, pull, then switch back and then rebase.
Probably not much difference.
Another command you might like: git-stash.
It's relatively new, so install a newer version
of git if you don't have it yet
Hello Jim,
> > - Did "git pull". It told me:
>
> Then (everything is committed), you switch to the trunk and pull
> (update from public repo) from there:
>
> git checkout master
> git pull
>
> then go back to your branch and use git-rebase to make your branch
> change set(s) apply cleanly
Jim Meyering wrote:
> I've learned not to modify ChangeLog on my private branches.
Certainly the ChangeLog will be the file that causes the most conflicts.
But conflicts can occur any time, even for intended short-lived modifications,
therefore I need to learn how to deal with conflicts even if th
Sylvain Beucler wrote on 2007-09-17:
> I added getopt in my packages, following the documentation. Here are
> the fixes I needed in Section 2.1:
>
> LIBADD = lib/libgnu.la
> becomes
> LDADD = $(top_builddir)/lib/libgnu.a
>
> - no .la in the common case
>
> - switching to LDADD (LIBADD doesn't se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 9/30/2007 6:21 AM:
> But I had to resolve the conflicts twice, which is inefficient. Any hint
> how to avoid that?
git rerere is supposed to be able to help with repeated rebase resolution
(git remembers how you resolved a
Bruno Haible <[EMAIL PROTECTED]> wrote:
> A git question:
>
> In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
> you wrote:
>> When one branch (your topic branch) is private, you *can* rebase, and thus
>> avoid the merge.
>> ...
>> That's the whole point of rebasing.
>> rebasin
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> A git question:
>
> In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
> you wrote:
>> When one branch (your topic branch) is private, you *can* rebase, and thus
>> avoid the merge.
>> ...
>> That's the whole point of rebasing
Hi Jim,
A git question:
In http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00130.html
you wrote:
> When one branch (your topic branch) is private, you *can* rebase, and thus
> avoid the merge.
> ...
> That's the whole point of rebasing.
> rebasing is essentially adjusting your deltas so t
Unit tests need not be compiled if the user just does "make; make install"
without "make check".
2007-09-30 Bruno Haible <[EMAIL PROTECTED]>
* modules/dirname-tests (check_PROGRAMS): Renamed from noinst_PROGRAMS.
*** modules/dirname-tests.orig 2007-09-30 13:12:10.0 +0200
--- m
Paul Eggert wrote on 2007-09-11:
> I assume we should use the ".in.h"
> suffix instead? I can propose a patch along those lines.
That was 3 weeks ago. Since preparing this patch is purely mechanical, I
hope you don't mind if I will do it. Here is a proposed patch. (Time to
learn about "git-mv"...
Bruno Haible <[EMAIL PROTECTED]> ha escrit:
> I propose to make Eric Blake an admin of the gnulib project at
> http://savannah.gnu.org/projects/gnulib.
Agreed.
Regards,
Sergey
Bruno Haible <[EMAIL PROTECTED]> wrote:
> I propose to make Eric Blake an admin of the gnulib project at
> http://savannah.gnu.org/projects/gnulib.
Seconded.
21 matches
Mail list logo
