Bug#619367: Bug#677191: Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-11-28 Thread Agustin Martin 
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 agmar...@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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619367: Bug#677191: Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-11-28 Thread intrigeri 
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!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619367: Bug#677191: Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-11-26 Thread Agustin Martin 
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 agmar...@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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#619367: Bug#677191: Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-11-20 Thread intrigeri 
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 agmar...@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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#132355: Bug#677191: Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-11-20 Thread Agustin Martin 
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 agmar...@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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-06-26 Thread Agustin Martin 
On Mon, Jun 25, 2012 at 09:08:56PM -0500, Rob Browning wrote:
 Agustin Martin agmar...@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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-06-25 Thread Agustin Martin 
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
diff --git a/emacsen-common.install b/emacsen-common.install
index de2e7a7..b8046a9 100755
--- a/emacsen-common.install
+++ b/emacsen-common.install
@@ -3,8 +3,27 @@
 set -e
 
 FLAVOR=$1
+package=emacsen-common
+
+case $FLAVOR in
+emacs)
+# Dummy emacs flavor. Do nothing and exit
+exit 0
+;;
+xemacs*)
+no_site_file=-no-site-file
+;;
+emacs*)
+no_site_file=--no-site-file
+;;
+*)
+echo install/${package}: Ignoring emacsen flavor [${FLAVOR}]
+exit 0
+;;
+esac
+
 # Make sure these options are appropriate for the given package.
-compile_options=--no-init-file --no-site-file -batch -f batch-byte-compile
+compile_options=--no-init-file $no_site_file -batch -f batch-byte-compile
 
 echo emacsen-common: Handling install of emacsen flavor ${FLAVOR}

Bug#132355: Bug#677191: emacsen-common: errors while upgrading to wheezy(some time ago) = wheezy(today)

2012-06-25 Thread Rob Browning 
Agustin Martin agmar...@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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org