GNU bug report logs - #14503
24.3.50; MSYS out-of-tree build fails

Previous Next

Packages: w32, emacs;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Wed, 29 May 2013 13:52:02 UTC

Severity: normal

Found in version 24.3.50

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14503 in the body.
You can then email your comments to 14503 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Wed, 29 May 2013 13:52:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Richard Copley <rcopley <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 29 May 2013 13:52:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; MSYS out-of-tree build fails
Date: Wed, 29 May 2013 14:49:49 +0100
Building Emacs on Windows according to nt/INSTALL.MSYS,
outside the source tree as recommended, "make -k bootstrap"
fails while processing {build_dir}/lib/Makefile, with the errors:

make[2]: Entering directory `/c/emacs/build/lib'
make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
make[2]: *** No rule to make target `execinfo.in.h', needed by `execinfo.h'.
make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.

Note that the prerequisites are at {trunk}/lib/alloca.in.h, etc.
All seems to work fine if I build inside the source tree.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-05-29 on 57172UHB
Bzr revision: 112768 rgm <at> gnu.org-20130529071809-s1x95w8thdhvjdc1
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix c:/emacs/emacs-112768 CPPFLAGS='-I G:/usr/include
 -I C:/GnuWin32/include' LDFLAGS='-L G:/usr/lib -L C:/GnuWin32/lib''

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r - e - b <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort nadvice gnus-util mail-extr emacsbug message format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns
disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process w32notify w32 multi-tty emacs)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Wed, 29 May 2013 17:14:02 GMT) Full text and rfc822 format available.

Message #8 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Wed, 29 May 2013 20:12:03 +0300
> Date: Wed, 29 May 2013 14:49:49 +0100
> From: Richard Copley <rcopley <at> gmail.com>
> 
> Building Emacs on Windows according to nt/INSTALL.MSYS,
> outside the source tree as recommended, "make -k bootstrap"
> fails while processing {build_dir}/lib/Makefile, with the errors:
> 
> make[2]: Entering directory `/c/emacs/build/lib'
> make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
> make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
> make[2]: *** No rule to make target `execinfo.in.h', needed by `execinfo.h'.
> make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.

Looks like "make bootstrap" is currently broken on Windows when you do
that outside of the source tree.  The problem is tricky, I will fix it
when I have time.  (Btw, the problem I saw does not manifest itself by
the above error messages, it fails in a different way.)

Anyway, you don't need "make bootstrap" on the first build with the
MSYS method.  In fact, you shouldn't need "make bootstrap" at all,
unless there are deep changes in Lisp that break a normal "make"
build.  And, contrary to what you say, there's no recommendation to
bootstrap in INSTALL.MSYS, it says to use just "make".

I just tried a build with "make" outside of the source tree, and I
didn't have the above problems.  (There's a VPATH line in lib/Makefile
that points to the source directory and allows Make to find the
prerequisites.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Wed, 29 May 2013 23:50:01 GMT) Full text and rfc822 format available.

Message #11 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Thu, 30 May 2013 00:48:13 +0100
On 29 May 2013 18:12, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 29 May 2013 14:49:49 +0100
>> From: Richard Copley <rcopley <at> gmail.com>
>>
>> Building Emacs on Windows according to nt/INSTALL.MSYS,
>> outside the source tree as recommended, "make -k bootstrap"
>> fails while processing {build_dir}/lib/Makefile, with the errors:
>>
>> make[2]: Entering directory `/c/emacs/build/lib'
>> make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
>> make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
>> make[2]: *** No rule to make target `execinfo.in.h', needed by `execinfo.h'.
>> make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.
>
> Looks like "make bootstrap" is currently broken on Windows when you do
> that outside of the source tree.  The problem is tricky, I will fix it
> when I have time.  (Btw, the problem I saw does not manifest itself by
> the above error messages, it fails in a different way.)
>
> Anyway, you don't need "make bootstrap" on the first build with the
> MSYS method.  In fact, you shouldn't need "make bootstrap" at all,
> unless there are deep changes in Lisp that break a normal "make"
> build.  And, contrary to what you say, there's no recommendation to
> bootstrap in INSTALL.MSYS, it says to use just "make".
>
> I just tried a build with "make" outside of the source tree, and I
> didn't have the above problems.  (There's a VPATH line in lib/Makefile
> that points to the source directory and allows Make to find the
> prerequisites.)

Thanks. I tried that too after reading your reply and got the same
errors again. Possibly there's an issue with VPATH support in the
default MSYS Make. In any case, I don't get this problem with the
pre-release version of Make mentioned in INSTALL.MSYS.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 17:05:02 GMT) Full text and rfc822 format available.

Message #14 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 2 Jun 2013 18:02:07 +0100
[Message part 1 (text/plain, inline)]
On 30 May 2013 00:48, Richard Copley <rcopley <at> gmail.com> wrote:

> On 29 May 2013 18:12, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Date: Wed, 29 May 2013 14:49:49 +0100
> >> From: Richard Copley <rcopley <at> gmail.com>
> >>
> >> Building Emacs on Windows according to nt/INSTALL.MSYS,
> >> outside the source tree as recommended, "make -k bootstrap"
> >> fails while processing {build_dir}/lib/Makefile, with the errors:
> >>
> >> make[2]: Entering directory `/c/emacs/build/lib'
> >> make[2]: *** No rule to make target `alloca.in.h', needed by `alloca.h'.
> >> make[2]: *** No rule to make target `errno.in.h', needed by `errno.h'.
> >> make[2]: *** No rule to make target `execinfo.in.h', needed by
> `execinfo.h'.
> >> make[2]: *** No rule to make target `getopt.in.h', needed by `getopt.h'.
> >
> > Looks like "make bootstrap" is currently broken on Windows when you do
> > that outside of the source tree.  The problem is tricky, I will fix it
> > when I have time.  (Btw, the problem I saw does not manifest itself by
> > the above error messages, it fails in a different way.)
> >
> > Anyway, you don't need "make bootstrap" on the first build with the
> > MSYS method.  In fact, you shouldn't need "make bootstrap" at all,
> > unless there are deep changes in Lisp that break a normal "make"
> > build.  And, contrary to what you say, there's no recommendation to
> > bootstrap in INSTALL.MSYS, it says to use just "make".
> >
> > I just tried a build with "make" outside of the source tree, and I
> > didn't have the above problems.  (There's a VPATH line in lib/Makefile
> > that points to the source directory and allows Make to find the
> > prerequisites.)
>
> Thanks. I tried that too after reading your reply and got the same
> errors again. Possibly there's an issue with VPATH support in the
> default MSYS Make. In any case, I don't get this problem with the
> pre-release version of Make mentioned in INSTALL.MSYS.
>

... but the out-of-tree build is still broken (even with the pre-release
make, and without bootstrap).

The failures are:

Compiling g:/emacs/trunk/lisp/calc/calc-aent.el

In toplevel form:
../../trunk/lisp/calc/calc-aent.el:29:1:Error: Cannot open load file:
calc-loaddefs.el
Makefile:247: recipe for target `calc/calc-aent.elc' failed
make[2]: *** [calc/calc-aent.elc] Error 1
make[2]: Leaving directory `/g/emacs/build/lisp'

Compiling g:/emacs/trunk/lisp/eshell/em-alias.el

In toplevel form:
../../trunk/lisp/eshell/em-alias.el:93:1:Error: Cannot open load file:
esh-groups
Makefile:247: recipe for target `eshell/em-alias.elc' failed
make[2]: *** [eshell/em-alias.elc] Error 1
make[2]: Leaving directory `/g/emacs/build/lisp'

Compiling g:/emacs/trunk/lisp/org/ob-calc.el

In toplevel form:
../../trunk/lisp/org/ob-calc.el:30:1:Error: Cannot open load file:
calc-loaddefs.el
Makefile:247: recipe for target `org/ob-calc.elc' failed
make[2]: *** [org/ob-calc.elc] Error 1
make[2]: Leaving directory `/g/emacs/build/lisp'
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 17:26:01 GMT) Full text and rfc822 format available.

Message #17 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 02 Jun 2013 20:23:31 +0300
> Date: Sun, 2 Jun 2013 18:02:07 +0100
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 14503 <at> debbugs.gnu.org
> 
> ... but the out-of-tree build is still broken (even with the pre-release
> make, and without bootstrap).

Not here, sorry.

It sounds like the files it cannot find are all generated by saving
the autoloads of certain Lisp packages.  Did you perhaps inadvertently
deleted those files?  If so, does "make autoloads" in the Lisp
directory solve the problem?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 18:01:02 GMT) Full text and rfc822 format available.

Message #20 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 2 Jun 2013 18:58:23 +0100
[Message part 1 (text/plain, inline)]
[Yet again, sorry for dropping the bug from the CC.]
On 2 June 2013 18:23, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sun, 2 Jun 2013 18:02:07 +0100
> > From: Richard Copley <rcopley <at> gmail.com>
> > Cc: 14503 <at> debbugs.gnu.org
> >
> > ... but the out-of-tree build is still broken (even with the pre-release
> > make, and without bootstrap).
>
> Not here, sorry.
>
> It sounds like the files it cannot find are all generated by saving
> the autoloads of certain Lisp packages.  Did you perhaps inadvertently
> deleted those files?


No. I did this:

bzr clean-tree --unknown --ignored --detritus --verbose --force
bzr revert --no-backup
bzr pull --overwrite
bzr update

before running autogen, configure and make in MSYS.


>  If so, does "make autoloads" in the Lisp
> directory solve the problem?
>

Possibly, I will check. But make should still make, right?
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 18:14:01 GMT) Full text and rfc822 format available.

Message #23 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 2 Jun 2013 19:11:19 +0100
[Message part 1 (text/plain, inline)]
On 2 June 2013 18:58, Richard Copley <rcopley <at> gmail.com> wrote:

> On 2 June 2013 18:23, Eli Zaretskii <eliz <at> gnu.org> wrote:
>  If so, does "make autoloads" in the Lisp
>
>> directory solve the problem?
>>
> Possibly, I will check. But make should still make, right?
>

"make autoloads" in the lisp directory succeeds, but there
are errors from some of the commands (this is perhaps
nearer the root cause of the error). Subsequent "make"
still fails as before. I've attached the output of
"make autoloads 2>&1".
[Message part 2 (text/html, inline)]
[make-autoloads.log (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 18:20:04 GMT) Full text and rfc822 format available.

Message #26 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 02 Jun 2013 21:16:59 +0300
> Date: Sun, 2 Jun 2013 18:58:23 +0100
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 14503 <at> debbugs.gnu.org
> 
> bzr clean-tree --unknown --ignored --detritus --verbose --force
> bzr revert --no-backup
> bzr pull --overwrite
> bzr update
> 
> before running autogen, configure and make in MSYS.

It's possible that the above commands don't produce a clean branch.  I
suggest to do a "bzr branch" and then compare the pristine branch with
this one.

> >  If so, does "make autoloads" in the Lisp
> > directory solve the problem?
> >
> 
> Possibly, I will check. But make should still make, right?

The "all" target doesn't seem to invoke anything that recreates those
files.  Whether that is a or isn't a bug is another matter, but it
surely isn't Windows specific.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 19:31:02 GMT) Full text and rfc822 format available.

Message #29 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 02 Jun 2013 22:28:07 +0300
> Date: Sun, 2 Jun 2013 19:48:32 +0100
> From: Richard Copley <rcopley <at> gmail.com>
> 
> > > >  If so, does "make autoloads" in the Lisp
> > > > directory solve the problem?
> > > >
> > >
> > > Possibly, I will check. But make should still make, right?
> >
> > The "all" target doesn't seem to invoke anything that recreates those
> > files.
> 
> 
> They do get created by "make all" when run inside the tree.

I think the problem is here:

  EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs -batch --no-site-file --no-site-lisp -l autoload \
     --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
     --eval "(setq generated-autoload-file (unmsys--file-name \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
                                                               ^^^^

How come you get here "d:/foo/bar" style of file names, and not MSYS's
usual "/d/foo/bar"?  Did you per chance invoke the configure script as
"g:/emacs/trunk/nt/msysconfig ..."?  If so, try "/g/emacs/..."
instead.

I think what happens in the above command is that MSYS converts

  g:/emacs/trunk/lisp/calendar/cal-loaddefs.el

into

  g;\emacs\trunk\lisp\calendar\cal-loaddefs.el

(note the semi-colon and the backslashes), because it thinks this is a
colon-separated path.  That's why Emacs complains about invalid escape
sequences.  Can you add a 'message' to unmsys--file-name to see what
kind of argument it is called with?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Sun, 02 Jun 2013 20:30:02 GMT) Full text and rfc822 format available.

Message #32 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Sun, 2 Jun 2013 21:27:03 +0100
[Message part 1 (text/plain, inline)]
On 2 June 2013 20:28, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sun, 2 Jun 2013 19:48:32 +0100
> > From: Richard Copley <rcopley <at> gmail.com>
> >
> > > > >  If so, does "make autoloads" in the Lisp
> > > > > directory solve the problem?
> > > > >
> > > >
> > > > Possibly, I will check. But make should still make, right?
> > >
> > > The "all" target doesn't seem to invoke anything that recreates those
> > > files.
> >
> >
> > They do get created by "make all" when run inside the tree.
>
> I think the problem is here:
>
>   EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs
> -batch --no-site-file --no-site-lisp -l autoload \
>      --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
>      --eval "(setq generated-autoload-file (unmsys--file-name
> \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
>                                                                ^^^^
>
> How come you get here "d:/foo/bar" style of file names, and not MSYS's
> usual "/d/foo/bar"?  Did you per chance invoke the configure script as
> "g:/emacs/trunk/nt/msysconfig ..."?  If so, try "/g/emacs/..."
> instead.
>

Yes, exactly that. My mistake. Sorry for taking up your time. Thank you.


> I think what happens in the above command is that MSYS converts
>
>   g:/emacs/trunk/lisp/calendar/cal-loaddefs.el
>
> into
>
>   g;\emacs\trunk\lisp\calendar\cal-loaddefs.el
>
> (note the semi-colon and the backslashes), because it thinks this is a
> colon-separated path.  That's why Emacs complains about invalid escape
> sequences.  Can you add a 'message' to unmsys--file-name to see what
> kind of argument it is called with?
>

Seems the crash occurred before unmsys--file-name was actually called,
because the message never got printed.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#14503; Package emacs. (Mon, 03 Jun 2013 17:03:01 GMT) Full text and rfc822 format available.

Message #35 received at 14503 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 14503 <at> debbugs.gnu.org
Subject: Re: bug#14503: 24.3.50; MSYS out-of-tree build fails
Date: Mon, 03 Jun 2013 19:59:59 +0300
> Date: Sun, 2 Jun 2013 21:27:03 +0100
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 14503 <at> debbugs.gnu.org
> 
> > I think the problem is here:
> >
> >   EMACSLOADPATH=g:/emacs/trunk/lisp LC_ALL=C /g/emacs/build/src/emacs
> > -batch --no-site-file --no-site-lisp -l autoload \
> >      --eval "(setq generate-autoload-cookie \";;;###cal-autoload\")" \
> >      --eval "(setq generated-autoload-file (unmsys--file-name
> > \"g:/emacs/trunk/lisp/calendar/cal-loaddefs.el\"))" \
> >                                                                ^^^^
> >
> > How come you get here "d:/foo/bar" style of file names, and not MSYS's
> > usual "/d/foo/bar"?  Did you per chance invoke the configure script as
> > "g:/emacs/trunk/nt/msysconfig ..."?  If so, try "/g/emacs/..."
> > instead.
> >
> 
> Yes, exactly that. My mistake. Sorry for taking up your time. Thank you.

I updated the instructions advising against using Windows style file
names.




bug closed, send any further explanations to 14503 <at> debbugs.gnu.org and Richard Copley <rcopley <at> gmail.com> Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 15 Jul 2013 22:37:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 13 Aug 2013 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 12 years and 9 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.