I'm glad to hear GNU Emacs builds fine. What version? (Ie, if it's
recent CVS there's some chance that they've already dealt with the
glibc change. I have a couple more reports, I'm reasonably sure
that the glibc change is it.)
I believe the version in Debian is not the bleeding edge CVS
I'm glad to hear GNU Emacs builds fine. What version? (Ie, if it's
recent CVS there's some chance that they've already dealt with the
glibc change. I have a couple more reports, I'm reasonably sure
that the glibc change is it.)
I believe the version in Debian is not the bleeding edge CVS
Mark == Mark Brown [EMAIL PROTECTED] writes:
Mark You need to downgrade everything that depends on the new
Mark libc before downgrading libc itself. dpkg should have told
Mark you this when you were doing the downgrade (IIRC it should
Mark have required some explicit cooercion
Junichi == Junichi Uekawa [EMAIL PROTECTED] writes:
Junichi It failed to build in my pbuilder run as well, not sure
Junichi if it is problem of glibc or xemacs.
It's almost surely an XEmacs problem (supporting unexec is not
glibc's problem), for which I believe we have a workaround
On Tue, Nov 05, 2002 at 12:43:22AM +0900, Stephen J. Turnbull wrote:
Daniel going to preserve forward compatibility, we might as well
Daniel stop developing the library. It is absolutely impossible
Daniel to add new functions, change the size of data structures,
Daniel change
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel Ahem? You'd prefer we just stopped including libdb1
Daniel entirely and let all programs using it go to rot? That's
Daniel what upstream did.
And that's exactly what Ben Collins tried to do. He told me that it
was a
Mark == Mark Brown [EMAIL PROTECTED] writes:
Mark You need to downgrade everything that depends on the new
Mark libc before downgrading libc itself. dpkg should have told
Mark you this when you were doing the downgrade (IIRC it should
Mark have required some explicit cooercion
Junichi == Junichi Uekawa [EMAIL PROTECTED] writes:
Junichi It failed to build in my pbuilder run as well, not sure
Junichi if it is problem of glibc or xemacs.
It's almost surely an XEmacs problem (supporting unexec is not
glibc's problem), for which I believe we have a workaround
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel You're talking about _forward_ compatibility. If we're
OK.
Daniel going to preserve forward compatibility, we might as well
Daniel stop developing the library. It is absolutely impossible
Daniel to add new
On Tue, Nov 05, 2002 at 12:43:22AM +0900, Stephen J. Turnbull wrote:
Daniel going to preserve forward compatibility, we might as well
Daniel stop developing the library. It is absolutely impossible
Daniel to add new functions, change the size of data structures,
Daniel change
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel Ahem? You'd prefer we just stopped including libdb1
Daniel entirely and let all programs using it go to rot? That's
Daniel what upstream did.
And that's exactly what Ben Collins tried to do. He told me that it
was a
On Tue, Nov 05, 2002 at 02:25:43AM +0900, Stephen J. Turnbull wrote:
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel Ahem? You'd prefer we just stopped including libdb1
Daniel entirely and let all programs using it go to rot? That's
Daniel what upstream did.
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel You're not listening to yourself. I was objecting to your
Daniel comment that we did _worse_ than upstream on
Daniel compatibility. Which is untrue.
Depends on how you look at it. As far as I'm concerned, neither glibc
On Sat, 2002-11-02 at 02:32, Junichi Uekawa wrote:
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper
Please provide the text of the actual error message.
It failed to build in my pbuilder run as well, not sure if it is problem of glibc or
xemacs.
8
Processing commands for [EMAIL PROTECTED]:
severity 167409 important
Bug#167409: glibc 2.3.1: breaks XEmacs builds; system breaks on revert to 2.2.5
Severity set to `important'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system
severity 167409 important
thanks
I'm not going to comment on the dumper problem, since I haven't looked
at it; the dumper has a history of being grossly non-portable, I'm not
surprised to see it break. I want to explain something to you about
severity and compatibility, though.
On Sat, Nov 02,
On Sat, Nov 02, 2002 at 03:42:17PM +0900, Stephen J. Turnbull wrote:
it. Dammit, for libc, of all packages, it is not acceptable to break
backward compatibility, even if upstream does! There always has to be
the escape hatch of reversion to previous.) So do all the basic
system utilities
Mark Brown [EMAIL PROTECTED] wrote:
You need to downgrade everything that depends on the new libc before
downgrading libc itself. dpkg should have told you this when you were
doing the downgrade (IIRC it should have required some explicit
cooercion to do the downgrade).
1. dpkg does
Package: glibc
Version: 2.3.1
Severity: critical
... and yes, it is critical, even if it only affects Emacs
maintainers. When it manifests, it's quite possible that the whole
system will break.
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper, at least the
On Sat, 2002-11-02 at 01:42, Stephen J.Turnbull wrote:
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper
Please provide the text of the actual error message.
Tks,
Jeff Bailey
--
When you get to the heart,
use a knife and fork.
- From instructions on how to
At Sat, 02 Nov 2002 15:42:17 +0900,
Stephen J.Turnbull [EMAIL PROTECTED] wrote:
I would assume this will also affect GNU Emacs and possibly other
applications that use unexec to build preloaded versions.
emacs21 seems to build fine.
regards,
junichi
At 02 Nov 2002 02:10:37 -0500,
Jeff Bailey wrote:
[1 text/plain (quoted-printable)]
On Sat, 2002-11-02 at 01:42, Stephen J.Turnbull wrote:
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper
Please provide the text of the actual error message.
It failed
On Sat, 2002-11-02 at 02:32, Junichi Uekawa wrote:
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper
Please provide the text of the actual error message.
It failed to build in my pbuilder run as well, not sure if it is problem of
glibc or
xemacs.
8
Processing commands for [EMAIL PROTECTED]:
severity 167409 important
Bug#167409: glibc 2.3.1: breaks XEmacs builds; system breaks on revert to 2.2.5
Severity set to `important'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system
severity 167409 important
thanks
I'm not going to comment on the dumper problem, since I haven't looked
at it; the dumper has a history of being grossly non-portable, I'm not
surprised to see it break. I want to explain something to you about
severity and compatibility, though.
On Sat, Nov 02,
On Sat, Nov 02, 2002 at 03:42:17PM +0900, Stephen J. Turnbull wrote:
it. Dammit, for libc, of all packages, it is not acceptable to break
backward compatibility, even if upstream does! There always has to be
the escape hatch of reversion to previous.) So do all the basic
system utilities
Dumping under the name xemacs
Testing for Lisp shadows ...
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Ugh. I don't know elisp at all. I'll need someone else to do some
analysis on this to figure out what's up.
It's not
Mark Brown [EMAIL PROTECTED] wrote:
You need to downgrade everything that depends on the new libc before
downgrading libc itself. dpkg should have told you this when you were
doing the downgrade (IIRC it should have required some explicit
cooercion to do the downgrade).
1. dpkg does
On Sat, 2002-11-02 at 01:42, Stephen J.Turnbull wrote:
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper
Please provide the text of the actual error message.
Tks,
Jeff Bailey
--
When you get to the heart,
use a knife and fork.
- From instructions on how to
At Sat, 02 Nov 2002 15:42:17 +0900,
Stephen J.Turnbull [EMAIL PROTECTED] wrote:
I would assume this will also affect GNU Emacs and possibly other
applications that use unexec to build preloaded versions.
emacs21 seems to build fine.
regards,
junichi
--
To UNSUBSCRIBE, email to
30 matches
Mail list logo
