Bug#503340: emacs-goodies-el: etch to lenny upgrade fails
Bill Allombert
Version: 29.3-2
Severity: serious
Hello Peter,
Upgrading from etch to lenny fails with
Setting up emacs22 (22.2+2-4) ...
emacs-install emacs22
install/cedet-common: Handling install for emacsen flavor emacs22
Loading /etc/emacs/site-start.d/00debian-vars.el (source)...
No /etc/mailname. Reverting to default...
Loading /etc/emacs/site-start.d/50cedet-common.el (source)...
Loading /etc/emacs/site-start.d/50chess.el (source)...
Loading /usr/share/emacs/site-lisp/chess/chess-auto.el (source)...
Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...
Package emacs-goodies-el not fully installed. Skipping setup.
Loading /etc/emacs/site-start.d/50emacs-intl-fonts.el (source)...
Loading /etc/emacs/site-start.d/50emacs-jabber.el (source)...
Loading /etc/emacs/site-start.d/50emacs-wiki.el (source)...
Loading /etc/emacs/site-start.d/51speedbar.el (source)...
Wrote /usr/share/emacs22/site-lisp/cedet-common/cedet-autogen.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/cedet-compat.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/cedet-edebug.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/cedet-load.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/cedet.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/ezimage.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/fame.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/inversion.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/mode-local.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/pprint.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/sformat.elc
Wrote /usr/share/emacs22/site-lisp/cedet-common/working.elc
install/emacs-goodies-el: Handling emacs22, logged in /tmp/elc_cdQaPI.log
emacs-install: /usr/lib/emacsen-common/packages/install/emacs-goodies-el emacs22 emacs21 failed at /usr/lib/emacsen-common/emacs-install line 28, <TSORT> line 8.
dpkg: error processing emacs22 (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
emacs22
E: Sub-process /usr/bin/dpkg returned an error code (1)
The file /tmp/elc_cdQaPI.log is in attachement.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Agustin Martin
Really attaching patch now.
On Sat, Oct 25, 2008 at 08:25:45AM +0200, Sven Joachim wrote:
> That is the same problem as in #502762, triggered by a Debian-specific
> patch that lets sendmail.el throw an error if neither sendmail nor
> /usr/bin/mail can be found, first reported and discussed in #429059.
> Since a sensible solution had already been proposed in #429059, I'm
> inclined to throw all these bugs together and assign them to the emacs22
> package.
Doing the actual reassign. Did not include 503340, because has been merged
with #434104 and worked around by not requiring sendmail.el.
I have been playing with emacs22 and noticed from
void-fakemail-mail-loss.diff that there are three files affected,
lisp/mail/feedmail.el
lisp/mail/sendmail.el
lisp/gnus/message.el
I guess we need to change the test in all three files. I am attaching a
patch that changes the test in the three files. I modified the message to
warn if mail-interactive is enabled.
sendmail.el changes are minimally tested with mailcrypt in a pbuilder
chroot.
Rob?
--
Agustin
Rob Browning
> I think the proper solution to #429059 is to remove the
> avoid-fakemail-mail-loss.diff completely and change the default of
> mail-interactive to t. These days there are simply too many systems
> where the MTA is configured for local delivery only, or not
> configured at all, and the danger of silently losing mail is too
> high. For the record, upstream changed the default of
> mail-interactive to t in Emacs 23 precisely for that reason.
Agustin Martin <agma...@debian.org> writes:
> I guess we need to change the test in all three files. I am
> attaching a patch that changes the test in the three files. I
> modified the message to warn if mail-interactive is enabled.
>
> sendmail.el changes are minimally tested with mailcrypt in a
> pbuilder chroot.
>
> Rob?
Ideally, I'd love to go with the solution that's been adopted
upstream. However, I think it's probably more important to keep
Debian's Emacs behavior consistent within a major release
(i.e. emacs22). Given that, I think the proposal sounds pretty good.
I'll look at it more closely today, and probably upload this, or
something similar soon.
Thanks for all the help.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
--
To UNSUBSCRIBE, email to debian-bugs...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org