Debian Bug report logs -
#677191
emacsen-common: errors while upgrading to wheezy(some time ago) => wheezy(today)
Reported by: Andreas Beckmann <anbe@debian.org>
Date: Tue, 12 Jun 2012 08:24:37 UTC
Severity: serious
Merged with 619367,
670292
Found in versions xemacs21/21.4.22-4, xemacs21/21.4.22-3.1
Fixed in version 21.4.22-4+rm
Done: Debian FTP Masters <ftpmaster@ftp-master.debian.org>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 12 Jun 2012 08:24:39 GMT) (full text, mbox, link).
Acknowledgement sent
to Andreas Beckmann <debian@abeckmann.de>:
New Bug report received and forwarded. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 12 Jun 2012 08:24:39 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: emacsen-common
Version: 2.0.3
Severity: serious
Hi,
an upgrade to current wheezy got stuck with emacsen-common:
# dpkg --configure --pending
Setting up emacsen-common (2.0.3) ...
Install emacsen-common for emacs23
emacsen-common: Handling install of emacsen flavor emacs23
Warning: Lisp directory `/usr/local/share/emacs/23.4/site-lisp' does not exist.
Wrote /etc/emacs23/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
Install emacsen-common for xemacs21
emacsen-common: Handling install of emacsen flavor xemacs21
WARNING:
Couldn't find obvious defaults for:
data-directory
mule-lisp-directory
lisp-directory
Perhaps some directories don't exist, or the XEmacs executable,
/usr/bin/xemacs21
is in a strange place?Loading /usr/share/emacs/site-lisp/debian-startup...
Loading 00debian...
Error while loading 00debian: Symbol's function definition is void: loop
Loading 00debian-vars...
Loading 50a2ps...
Loading 50autoconf...
Error while loading 50autoconf: No /usr/local/ prefixed paths in load-path
Loading 50cmake...
Loading 50cmake-data...
Loading 50dictionaries-common...
Error while loading 50dictionaries-common: No /usr/local/ prefixed paths in load-path
Loading 50emacs-goodies-el...
Package emacs-goodies-el not fully installed. Skipping setup.
Loading 50lilypond-data...
Loading 50psvn...
Symbol's function definition is void: batch-byte-compile
xemacs exiting
.
ERROR: install script from emacsen-common package failed
dpkg: error processing emacsen-common (--configure):
subprocess installed post-installation script returned error exit status 1
Setting up dictionaries-common (1.12.7) ...
Install dictionaries-common for emacs23
install/dictionaries-common: Already byte-compiled for emacs23. Skipping ...
Install dictionaries-common for xemacs21
install/dictionaries-common: Byte-compiling for emacsen flavour xemacs21
WARNING:
Couldn't find obvious defaults for:
data-directory
mule-lisp-directory
lisp-directory
Perhaps some directories don't exist, or the XEmacs executable,
/usr/bin/xemacs21
is in a strange place?Symbol's function definition is void: batch-byte-compile
xemacs exiting
.
ERROR: install script from dictionaries-common package failed
dpkg: error processing dictionaries-common (--configure):
subprocess installed post-installation script returned error exit status 1
As that's an experimental system (running testing/sid mix since
testing=lenny) and noone needs emacs there, I'm leaving it broken
for now and can provide additional information if needed.
Andreas
# COLUMNS=110 dpkg -l | grep emacs
iU emacs 23.4+1-3 The GNU Emacs editor (metapackage)
ii emacs-goodies-el 35.2 Miscellaneous add-ons for Emacs
iU emacs23 23.4+1-3 The GNU Emacs editor (with GTK+ user interface)
iU emacs23-bin-common 23.4+1-3 The GNU Emacs editor's shared, architecture dependent file
iU emacs23-common 23.4+1-3 The GNU Emacs editor's shared, architecture independent in
iF emacsen-common 2.0.3 Common facilities for all emacsen
ii xemacs21 21.4.22-3.2 highly customizable text editor
ii xemacs21-basesupport 2009.02.17.dfsg.1-1 Editor and kitchen sink -- compiled elisp support files
ii xemacs21-bin 21.4.22-3.2+b1 highly customizable text editor -- support binaries
iU xemacs21-mule 21.4.22-3.2+b1 highly customizable text editor -- Mule binary
ii xemacs21-mulesupport 2009.02.17.dfsg.1-1 Editor and kitchen sink -- Mule elisp support files
ii xemacs21-support 21.4.22-3.2 highly customizable text editor -- architecture independen
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (700, 'testing'), (600, 'unstable'), (130, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Mon, 25 Jun 2012 13:00:48 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Mon, 25 Jun 2012 13:00:55 GMT) (full text, mbox, link).
Message #10 received at 677191@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On Tue, Jun 12, 2012 at 10:22:10AM +0200, Andreas Beckmann wrote:
> Package: emacsen-common
> Version: 2.0.3
> Severity: serious
>
> Hi,
>
> an upgrade to current wheezy got stuck with emacsen-common:
>
> # dpkg --configure --pending
> Setting up emacsen-common (2.0.3) ...
> Install emacsen-common for emacs23
> emacsen-common: Handling install of emacsen flavor emacs23
> Warning: Lisp directory `/usr/local/share/emacs/23.4/site-lisp' does not exist.
> Wrote /etc/emacs23/site-start.d/00debian-vars.elc
> Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
> Install emacsen-common for xemacs21
> emacsen-common: Handling install of emacsen flavor xemacs21
>
> WARNING:
> Couldn't find obvious defaults for:
> data-directory
> mule-lisp-directory
> lisp-directory
> Perhaps some directories don't exist, or the XEmacs executable,
> /usr/bin/xemacs21
> is in a strange place?Loading /usr/share/emacs/site-lisp/debian-startup...
> Loading 00debian...
> Error while loading 00debian: Symbol's function definition is void: loop
> Loading 00debian-vars...
> Loading 50a2ps...
> Loading 50autoconf...
> Error while loading 50autoconf: No /usr/local/ prefixed paths in load-path
> Loading 50cmake...
> Loading 50cmake-data...
> Loading 50dictionaries-common...
> Error while loading 50dictionaries-common: No /usr/local/ prefixed paths in load-path
> Loading 50emacs-goodies-el...
> Package emacs-goodies-el not fully installed. Skipping setup.
> Loading 50lilypond-data...
> Loading 50psvn...
> Symbol's function definition is void: batch-byte-compile
> xemacs exiting
> .
> ERROR: install script from emacsen-common package failed
> dpkg: error processing emacsen-common (--configure):
> subprocess installed post-installation script returned error exit status 1
> Setting up dictionaries-common (1.12.7) ...
> Install dictionaries-common for emacs23
> install/dictionaries-common: Already byte-compiled for emacs23. Skipping ...
> Install dictionaries-common for xemacs21
> install/dictionaries-common: Byte-compiling for emacsen flavour xemacs21
>
> WARNING:
> Couldn't find obvious defaults for:
> data-directory
> mule-lisp-directory
> lisp-directory
> Perhaps some directories don't exist, or the XEmacs executable,
> /usr/bin/xemacs21
> is in a strange place?Symbol's function definition is void: batch-byte-compile
> xemacs exiting
> .
> ERROR: install script from dictionaries-common package failed
> dpkg: error processing dictionaries-common (--configure):
> subprocess installed post-installation script returned error exit status 1
>
>
> As that's an experimental system (running testing/sid mix since
> testing=lenny) and noone needs emacs there, I'm leaving it broken
> for now and can provide additional information if needed.
I'd say this seems something wrong in the xemacs21 side during xemacs21
upgrade. As a matter of fact I have found
http://bugs.debian.org/619367 [xemacs21: installing elisp packages fails:
Symbol's function definition is void: batch-byte-compile]
which has some common elements,
Setting up ocaml-mode (3.11.2-4) ...
install/ocaml-mode: Handling install for emacsen flavor xemacs21
WARNING:
Couldn't find obvious defaults for:
data-directory
mule-lisp-directory
lisp-directory
Perhaps some directories don't exist, or the XEmacs executable,
/usr/bin/xemacs21
is in a strange place?Symbol's function definition is void: batch-byte-compile
xemacs exiting
Note that I could not reproduce this in a system that is upgraded frequently.
May be this is a problem with upgrades from a particular version to a much
more recent version.
Apart from this, this problem looks triggered during install by the
persistence of http://bugs.debian.org/132355 [emacsen-common: Byte-compiling
too verbose]. Not loading site files during byte-compile may work around
this in the install phase. Do not know if there is any additional problem.
As pointed out in #132355, using single dashed -no-site-file should work for
both XEmacs and (although undocumented) FSF Emacs.
If maintainer wants to be in the safe side and use only documented features
I expect something like attached patch to work for emacsen-common.
Regards,
--
Agustin
[emacsen-common_portable-no-site-file.diff (text/x-diff, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org:
Bug#677191; Package emacsen-common.
(Tue, 26 Jun 2012 02:12:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Rob Browning <rlb@defaultvalue.org>:
Extra info received and forwarded to list.
(Tue, 26 Jun 2012 02:12:06 GMT) (full text, mbox, link).
Message #15 received at 677191@bugs.debian.org (full text, mbox, reply):
Agustin Martin <agmartin@debian.org> writes:
> I'd say this seems something wrong in the xemacs21 side during xemacs21
> upgrade. As a matter of fact I have found
>
> http://bugs.debian.org/619367 [xemacs21: installing elisp packages fails:
> Symbol's function definition is void: batch-byte-compile]
>
> which has some common elements,
So it sounds like you think this bit is an xemacs bug?
> Setting up ocaml-mode (3.11.2-4) ...
> install/ocaml-mode: Handling install for emacsen flavor xemacs21
> As pointed out in #132355, using single dashed -no-site-file should work for
> both XEmacs and (although undocumented) FSF Emacs.
> If maintainer wants to be in the safe side and use only documented features
> I expect something like attached patch to work for emacsen-common.
OK, I either hadn't seen this before, or just forgot. It looks an
update to emacsen-common would be in order, right?
Thanks for the help.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 26 Jun 2012 09:57:31 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 26 Jun 2012 09:57:36 GMT) (full text, mbox, link).
Message #20 received at 677191@bugs.debian.org (full text, mbox, reply):
On Mon, Jun 25, 2012 at 09:08:56PM -0500, Rob Browning wrote:
> Agustin Martin <agmartin@debian.org> writes:
>
> > I'd say this seems something wrong in the xemacs21 side during xemacs21
> > upgrade. As a matter of fact I have found
> >
> > http://bugs.debian.org/619367 [xemacs21: installing elisp packages fails:
> > Symbol's function definition is void: batch-byte-compile]
> >
> > which has some common elements,
>
> So it sounds like you think this bit is an xemacs bug?
I am not completely sure, but is strange that I could not reproduce it in my
frequently updated sid box. I am using pristine emacsen-common, so if it
were due to emacsen-comon I guess I should have reproduced it.
I have even manually tried
# /usr/lib/emacsen-common/emacs-remove xemacs21
# /usr/lib/emacsen-common/emacs-install xemacs21
with no problem.
Looking at #619367, happening with ocaml installation is what makes me think
about the possibility that the fact that this bug happens with emacsen-common
is just accidental.
As a blind guess I think about two other possibilities, a buggy xemacs21
version that has problems upgrading to a way more recent version or a buggy
emacsen add-on package that is messing up with paths and definitions. Or a
local problem.
Andreas, does manually running emacs-{remove,install} as above show anything
strange?
> > Setting up ocaml-mode (3.11.2-4) ...
> > install/ocaml-mode: Handling install for emacsen flavor xemacs21
>
> > As pointed out in #132355, using single dashed -no-site-file should work for
> > both XEmacs and (although undocumented) FSF Emacs.
>
> > If maintainer wants to be in the safe side and use only documented features
> > I expect something like attached patch to work for emacsen-common.
>
> OK, I either hadn't seen this before, or just forgot. It looks an
> update to emacsen-common would be in order, right?
Agreed. Even if only to look what happens, although I do not expect this bug
to suddenly dissapear just because of that, the ocaml bug seems to happen in
a "quiet" install.
Regards,
--
Agustin
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 26 Jun 2012 15:57:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 26 Jun 2012 15:57:07 GMT) (full text, mbox, link).
Message #25 received at 677191@bugs.debian.org (full text, mbox, reply):
On Tue, Jun 26, 2012 at 11:54:45AM +0200, Agustin Martin wrote:
> On Mon, Jun 25, 2012 at 09:08:56PM -0500, Rob Browning wrote:
> > Agustin Martin <agmartin@debian.org> writes:
> >
> > > I'd say this seems something wrong in the xemacs21 side during xemacs21
> > > upgrade. As a matter of fact I have found
> > >
> > > http://bugs.debian.org/619367 [xemacs21: installing elisp packages fails:
> > > Symbol's function definition is void: batch-byte-compile]
> > >
> > > which has some common elements,
> >
> > So it sounds like you think this bit is an xemacs bug?
>
> I am not completely sure, but is strange that I could not reproduce it in my
> frequently updated sid box. I am using pristine emacsen-common, so if it
> were due to emacsen-comon I guess I should have reproduced it.
>
> I have even manually tried
>
> # /usr/lib/emacsen-common/emacs-remove xemacs21
> # /usr/lib/emacsen-common/emacs-install xemacs21
>
> with no problem.
I have done some extra work with this and noticed I can reproduce this
problem when upgrading from a squeeze pbuilder chroot containing xemacs21.
However, if xemacs21 is already upgraded then there is no problem when
installing emacsen-common. I guess this is what happened in my regularly
updated sid box and the reason why I could not see this problem in it.
I also tried with a squeeze pbuilder chroot containing emacs23 and upgrade
to sid worked, just a warning on not yet available (emacs23-common not yet
configured) /usr/local/share/emacs/23.4/site-lisp.
Installing new version of config file /etc/emacs/site-start.el ...
Install emacsen-common for emacs23
emacsen-common: Handling install of emacsen flavor emacs23
Warning: Lisp directory `/usr/local/share/emacs/23.4/site-lisp' does not exist.
Wrote /etc/emacs23/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs23/site-lisp/debian-startup.elc
If after this pbuilder+emacs23 upgrade I install sid xemacs21 everything
works. No apparent problem.
So, seems that the problem appears when both xemacs21 stuff and emacsen-common
are ugraded at the same time. Seems that xemacs21 stuff needs something from
a postinst to become available for byte-compilation, so byte-compilation
fails and needed postinst is not reached. If in the failing chroot I run
# xemacs21 -vanilla -nw
WARNING:
Couldn't find obvious defaults for:
data-directory
mule-lisp-directory
lisp-directory
Perhaps some directories don't exist, or the XEmacs executable,
/usr/bin/xemacs21
is in a strange place?
.
and once xemacs is started I see
(1) (warning/warning) Autoload error in:
/usr/share/xemacs21/mule-packages/lisp/latin-euro-standards/auto-autoloads:
Cannot open load file: cl-macs
I think that emacsen-common > 2.0.0 considering the failure of any
add-on package install or remove script as a fatal error just makes this
underlying xemacs21 problem evident, but seems to be something wrong in
xemacs21.
Reading more carefully http://bugs.debian.org/619367 I see that it points
to http://bugs.debian.org/391778, where some symlinks are done at
xemacs21-* postinst. May be those symlinks should be done in appropriate
preinst if needed, so paths are available even if xemacs21* is not yet
configured.
Regards,
--
Agustin
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Fri, 29 Jun 2012 07:06:06 GMT) (full text, mbox, link).
Acknowledgement sent
to era eriksson <era@iki.fi>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Fri, 29 Jun 2012 07:06:06 GMT) (full text, mbox, link).
Message #30 received at 677191@bugs.debian.org (full text, mbox, reply):
Just a quick note that Ubuntu Launchpad has a largish number of recent
duplicates for this bug.
https://bugs.launchpad.net/ubuntu/+source/xemacs21/+bug/789706
xemacs21 has been stable (as in basically unmaintained in Ubuntu) for a
long time, across several Ubuntu releases. This points to
emacsen-common as the likely source for whatever exposes this, although
it may well be that the root cause for the bug is in the xemacs21
packaging.
#313511 looks similar, maybe the changes discussed there are actually
relevant for this case?
/* era */
--
If this were a real .signature, it would suck less. Well, maybe not.
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Fri, 29 Jun 2012 11:03:30 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Fri, 29 Jun 2012 11:03:36 GMT) (full text, mbox, link).
Message #35 received at 677191@bugs.debian.org (full text, mbox, reply):
On Tue, Jun 26, 2012 at 05:55:14PM +0200, Agustin Martin wrote:
> So, seems that the problem appears when both xemacs21 stuff and emacsen-common
> are ugraded at the same time. Seems that xemacs21 stuff needs something from
> a postinst to become available for byte-compilation, so byte-compilation
> fails and needed postinst is not reached. If in the failing chroot I run
>
> # xemacs21 -vanilla -nw
>
> WARNING:
> Couldn't find obvious defaults for:
> data-directory
> mule-lisp-directory
> lisp-directory
> Perhaps some directories don't exist, or the XEmacs executable,
> /usr/bin/xemacs21
> is in a strange place?
> .
>
> and once xemacs is started I see
>
> (1) (warning/warning) Autoload error in:
> /usr/share/xemacs21/mule-packages/lisp/latin-euro-standards/auto-autoloads:
> Cannot open load file: cl-macs
>
> I think that emacsen-common > 2.0.0 considering the failure of any
> add-on package install or remove script as a fatal error just makes this
> underlying xemacs21 problem evident, but seems to be something wrong in
> xemacs21.
>
> Reading more carefully http://bugs.debian.org/619367 I see that it points
> to http://bugs.debian.org/391778, where some symlinks are done at
> xemacs21-* postinst. May be those symlinks should be done in appropriate
> preinst if needed, so paths are available even if xemacs21* is not yet
> configured.
I am thinking about a possible alternative, a dirty workaround from the
emacsen-common side, make "emacs-install" and "emacs-package-install"
skip byte compilation for xemacs21 if those symlinks are not set, warning
about this.
"emacs-install" should be called again from relevant xemacs21* postinsts,
and this last must be done after symlinks are set.
Did not look at "emacs-install" and "emacs-package-install", nor sure how
reasonable / rock solid/ easy is this. Also, I find this a bit weak
regarding possible changes in xemacs21, but ...
Regards,
--
Agustin
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 10 Jul 2012 15:36:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Akarsh Simha <akarshsimha@gmail.com>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 10 Jul 2012 15:36:06 GMT) (full text, mbox, link).
Message #40 received at 677191@bugs.debian.org (full text, mbox, reply):
Hi
I just run an aptitude upgrade to upgrade my install of Debian
testing, and ran into this bug.
It would be very nice if this is fixed soon, because it is really hard
to live life without emacs and cmake.
Regards
Akarsh
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 10 Jul 2012 15:39:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Akarsh Simha <akarshsimha@gmail.com>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 10 Jul 2012 15:39:06 GMT) (full text, mbox, link).
Message #45 received at 677191@bugs.debian.org (full text, mbox, reply):
On 10 July 2012 10:32, Akarsh Simha <akarshsimha@gmail.com> wrote:
> Hi
>
> I just run an aptitude upgrade to upgrade my install of Debian
> testing, and ran into this bug.
>
> It would be very nice if this is fixed soon, because it is really hard
> to live life without emacs and cmake.
Also, any user-implementable workarounds will be fully appreciated!
Regards
Akarsh
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 10 Jul 2012 15:54:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Akarsh Simha <akarshsimha@gmail.com>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 10 Jul 2012 15:54:03 GMT) (full text, mbox, link).
Message #50 received at 677191@bugs.debian.org (full text, mbox, reply):
Hi
Sorry if I didn't keep my eyes open. The following workaround worked:
1. sudo aptitude install emacsen-common
<It barfs about not being able to install xemacs21 flavor>
2. sudo /usr/lib/emacsen-common/emacs-remove xemacs21
<It says it purged byte-compiled files for flavour xemacs21>
3. sudo aptitude install emacsen-common
<Should install without any issue, except without the xemacs21 flavor>
Many thanks to Kumar Appaiah for guiding me through this.
Regards
Akarsh
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 20 Nov 2012 16:33:10 GMT) (full text, mbox, link).
Acknowledgement sent
to intrigeri <intrigeri@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 20 Nov 2012 16:33:10 GMT) (full text, mbox, link).
Message #55 received at 677191@bugs.debian.org (full text, mbox, reply):
Hi,
(Meta: I was going to express my intent to NMU emacsen-common to fix the
#676424 RC bug, when I discovered that the package had another one
(#677191) => trying to understand what can be done with that one first.)
Rob Browning wrote (26 Jun 2012 02:08:56 GMT) :
> Agustin Martin <agmartin@debian.org> writes:
>> As pointed out in #132355, using single dashed -no-site-file should
>> work for both XEmacs and (although undocumented) FSF Emacs.
>>
>> If maintainer wants to be in the safe side and use only documented
>> features I expect something like attached patch to work for
>> emacsen-common.
>
> OK, I either hadn't seen this before, or just forgot. It looks an
> update to emacsen-common would be in order, right?
Reading these bugs log, it's not clear to me whether the single-dashed
option idea:
1. has any chance to fix #677191 and friends
2. was tried in the context of the Squeeze -> Wheezy dist-upgrade
Could anyone please enlighten me?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Tue, 20 Nov 2012 17:30:14 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Tue, 20 Nov 2012 17:30:14 GMT) (full text, mbox, link).
Message #60 received at 677191@bugs.debian.org (full text, mbox, reply):
On Tue, Nov 20, 2012 at 05:28:23PM +0100, intrigeri wrote:
> Hi,
>
> (Meta: I was going to express my intent to NMU emacsen-common to fix the
> #676424 RC bug, when I discovered that the package had another one
> (#677191) => trying to understand what can be done with that one first.)
>
> Rob Browning wrote (26 Jun 2012 02:08:56 GMT) :
> > Agustin Martin <agmartin@debian.org> writes:
> >> As pointed out in #132355, using single dashed -no-site-file should
> >> work for both XEmacs and (although undocumented) FSF Emacs.
> >>
> >> If maintainer wants to be in the safe side and use only documented
> >> features I expect something like attached patch to work for
> >> emacsen-common.
> >
> > OK, I either hadn't seen this before, or just forgot. It looks an
> > update to emacsen-common would be in order, right?
>
> Reading these bugs log, it's not clear to me whether the single-dashed
> option idea:
>
> 1. has any chance to fix #677191 and friends
> 2. was tried in the context of the Squeeze -> Wheezy dist-upgrade
#132355 is about decreasing verbosity when byte-compiling emacsen-common.
When I mentioned it in #677191 I did not yet know what was causing the
#677191 problem and thought that some of the files loaded at init might
be related, but few messages below in #677191 that was discarded and the
real reason for this problem become more evident.
The -no-site-file changes now seems mostly a cosmetic issue for XEmacs
with no relation at all to #677191.
Regards,
--
Agustin
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Mon, 26 Nov 2012 17:27:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Mon, 26 Nov 2012 17:27:05 GMT) (full text, mbox, link).
Message #65 received at 677191@bugs.debian.org (full text, mbox, reply):
On Tue, Nov 20, 2012 at 06:07:46PM +0100, Agustin Martin wrote:
> On Tue, Nov 20, 2012 at 05:28:23PM +0100, intrigeri wrote:
> > Hi,
> >
> > (Meta: I was going to express my intent to NMU emacsen-common to fix the
> > #676424 RC bug, when I discovered that the package had another one
> > (#677191) => trying to understand what can be done with that one first.)
> >
> > Rob Browning wrote (26 Jun 2012 02:08:56 GMT) :
> > > Agustin Martin <agmartin@debian.org> writes:
> > >> As pointed out in #132355, using single dashed -no-site-file should
> > >> work for both XEmacs and (although undocumented) FSF Emacs.
> > >>
> > >> If maintainer wants to be in the safe side and use only documented
> > >> features I expect something like attached patch to work for
> > >> emacsen-common.
> > >
> > > OK, I either hadn't seen this before, or just forgot. It looks an
> > > update to emacsen-common would be in order, right?
> >
> > Reading these bugs log, it's not clear to me whether the single-dashed
> > option idea:
> >
> > 1. has any chance to fix #677191 and friends
> > 2. was tried in the context of the Squeeze -> Wheezy dist-upgrade
>
> #132355 is about decreasing verbosity when byte-compiling emacsen-common.
> When I mentioned it in #677191 I did not yet know what was causing the
> #677191 problem and thought that some of the files loaded at init might
> be related, but few messages below in #677191 that was discarded and the
> real reason for this problem become more evident.
>
> The -no-site-file changes now seems mostly a cosmetic issue for XEmacs
> with no relation at all to #677191.
Looking again at xemacs21 status I see that it is not in testing and that
sid version ships the missing symlinks in the package instead of creating
them from a postinst on configuration.
I would expect that this should make all lisp stuff available during
emacsen-common configuration, thus fixing both #677191 and #619367 as well
as #670292, closed with sid upload. As a matter of fact I no longer see
the problem in squeeze->sid upgrade.
Can others still reproduce the problem?
--
Agustin
Information forwarded
to debian-bugs-dist@lists.debian.org, Rob Browning <rlb@defaultvalue.org>:
Bug#677191; Package emacsen-common.
(Wed, 28 Nov 2012 12:15:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Agustin Martin <agmartin@debian.org>:
Extra info received and forwarded to list. Copy sent to Rob Browning <rlb@defaultvalue.org>.
(Wed, 28 Nov 2012 12:15:05 GMT) (full text, mbox, link).
Message #70 received at 677191@bugs.debian.org (full text, mbox, reply):
unarchive 670292
reassign 670292 xemacs21
reassign 677191 xemacs21
forcemerge 670292 619367 677191
thanks
On Mon, Nov 26, 2012 at 06:23:57PM +0100, Agustin Martin wrote:
> On Tue, Nov 20, 2012 at 06:07:46PM +0100, Agustin Martin wrote:
> > On Tue, Nov 20, 2012 at 05:28:23PM +0100, intrigeri wrote:
> > > Hi,
> > >
> > > (Meta: I was going to express my intent to NMU emacsen-common to fix the
> > > #676424 RC bug, when I discovered that the package had another one
> > > (#677191) => trying to understand what can be done with that one first.)
> > >
> > > Rob Browning wrote (26 Jun 2012 02:08:56 GMT) :
> > > > Agustin Martin <agmartin@debian.org> writes:
> > > >> As pointed out in #132355, using single dashed -no-site-file should
> > > >> work for both XEmacs and (although undocumented) FSF Emacs.
> > > >>
> > > >> If maintainer wants to be in the safe side and use only documented
> > > >> features I expect something like attached patch to work for
> > > >> emacsen-common.
> > > >
> > > > OK, I either hadn't seen this before, or just forgot. It looks an
> > > > update to emacsen-common would be in order, right?
> > >
> > > Reading these bugs log, it's not clear to me whether the single-dashed
> > > option idea:
> > >
> > > 1. has any chance to fix #677191 and friends
> > > 2. was tried in the context of the Squeeze -> Wheezy dist-upgrade
> >
> > #132355 is about decreasing verbosity when byte-compiling emacsen-common.
> > When I mentioned it in #677191 I did not yet know what was causing the
> > #677191 problem and thought that some of the files loaded at init might
> > be related, but few messages below in #677191 that was discarded and the
> > real reason for this problem become more evident.
> >
> > The -no-site-file changes now seems mostly a cosmetic issue for XEmacs
> > with no relation at all to #677191.
>
> Looking again at xemacs21 status I see that it is not in testing and that
> sid version ships the missing symlinks in the package instead of creating
> them from a postinst on configuration.
>
> I would expect that this should make all lisp stuff available during
> emacsen-common configuration, thus fixing both #677191 and #619367 as well
> as #670292, closed with sid upload. As a matter of fact I no longer see
> the problem in squeeze->sid upgrade.
>
> Can others still reproduce the problem?
Hi, Rob, Ohura and Intrigeri
For completeness I tried a similar squeeze->sid upgrade in an amd64 pbuilder
chroot inside an amd64 box. As expected it worked well (just seemed that
emacsen-common was byte-compiled twice), no longer reproduce the problem.
Since #670292 seems indeed the same problem as #619367 and #677191 and is
fixed in sid xemacs21 21.4.22-4 (and so should be #619367 and #677191) I am
reassing all those bugs to xemacs21 package and forcibly merging them to get
all closed.
Regards,
--
Agustin
Bug reassigned from package 'emacsen-common' to 'xemacs21'.
Request was from Agustin Martin <agmartin@debian.org>
to control@bugs.debian.org.
(Wed, 28 Nov 2012 12:33:09 GMT) (full text, mbox, link).
No longer marked as found in versions emacsen-common/2.0.3.
Request was from Agustin Martin <agmartin@debian.org>
to control@bugs.debian.org.
(Wed, 28 Nov 2012 12:33:10 GMT) (full text, mbox, link).
Marked Bug as done
Request was from Agustin Martin <agmartin@debian.org>
to control@bugs.debian.org.
(Wed, 28 Nov 2012 12:33:10 GMT) (full text, mbox, link).
Notification sent
to Andreas Beckmann <debian@abeckmann.de>:
Bug acknowledged by developer.
(Wed, 28 Nov 2012 12:33:11 GMT) (full text, mbox, link).
Added indication that 677191 affects tuareg-mode,xemacs21-support,aplus-fsf-el,xemacs21
Request was from Agustin Martin <agmartin@debian.org>
to control@bugs.debian.org.
(Wed, 28 Nov 2012 12:33:11 GMT) (full text, mbox, link).
Marked as found in versions xemacs21/21.4.22-3.1.
Request was from Agustin Martin <agmartin@debian.org>
to control@bugs.debian.org.
(Wed, 28 Nov 2012 12:33:12 GMT) (full text, mbox, link).
Marked as fixed in versions xemacs21/21.4.22-4.
Request was from Agustin Martin <agmartin@debian.org>
to control@bugs.debian.org.
(Wed, 28 Nov 2012 12:42:04 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, OHURA Makoto <ohura@debian.org>:
Bug#677191; Package xemacs21.
(Wed, 28 Nov 2012 12:54:07 GMT) (full text, mbox, link).
Acknowledgement sent
to intrigeri <intrigeri@debian.org>:
Extra info received and forwarded to list. Copy sent to OHURA Makoto <ohura@debian.org>.
(Wed, 28 Nov 2012 12:54:07 GMT) (full text, mbox, link).
Message #91 received at 677191@bugs.debian.org (full text, mbox, reply):
Hi,
Agustin Martin wrote (28 Nov 2012 12:11:20 GMT) :
> Since #670292 seems indeed the same problem as #619367 and #677191
> and is fixed in sid xemacs21 21.4.22-4 (and so should be #619367 and
> #677191) I am reassing all those bugs to xemacs21 package and
> forcibly merging them to get all closed.
Awesome!
Marked as found in versions xemacs21/21.4.22-4; no longer marked as fixed in versions xemacs21/21.4.22-4 and reopened.
Request was from Andreas Beckmann <debian@abeckmann.de>
to 670292-submit@bugs.debian.org.
(Wed, 16 Jan 2013 15:54:06 GMT) (full text, mbox, link).
Changed Bug submitter to 'Andreas Beckmann <anbe@debian.org>' from 'Andreas Beckmann <debian@abeckmann.de>'
Request was from Andreas Beckmann <anbe@debian.org>
to control@bugs.debian.org.
(Sat, 26 Jan 2013 06:27:30 GMT) (full text, mbox, link).
Message #96 received at 619367-done@bugs.debian.org (full text, mbox, reply):
Version: 21.4.22-4+rm
Dear submitter,
as the package xemacs21 has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see http://bugs.debian.org/725883
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.
Debian distribution maintenance software
pp.
Ansgar Burchardt (the ftpmaster behind the curtain)
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Mon, 11 Nov 2013 07:48:07 GMT) (full text, mbox, link).
Bug unarchived.
Request was from Mark Brown <broonie@sirena.org.uk>
to control@bugs.debian.org.
(Sun, 17 Nov 2013 14:28:40 GMT) (full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Mon, 16 Dec 2013 07:43:23 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Fri Jan 12 14:14:00 2018;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.