Bug#1016230: auctex: FTBFS: ! LaTeX Error: File `hypdoc.sty' not found.
tags 1016230 + pending thanks. > LN == Lucas Nussbaum [2022-7-29] [...] LN> During a rebuild of all packages in sid, your package failed to build LN> on amd64. Thanks for the report. It should be fixed by adding a Build-Depends-Indep on texlive-latex-extra. I'll test and upload a fixed package next week. -- Thanks, Davide
Bug#908081: NMU
> BR == Bastien ROUCARIES [2018-12-4] BR> Hi, I plan to do a NMU in a week about this bug. BR> Can you ACK ? Hi Bastien, thank you for your offer. However I would like to cater this by myself, therefore please do not NMU. -- Thanks, Davide
Bug#867020: auctex: fails to remove: auctex/remove: Removing parsed (La)TeX macros for emacs25...rm: cannot remove '/var/lib/auctex/emacs25': Directory not empty
>>>>> AB == Andreas Beckmann [2017-8-12] AB> On 2017-08-12 02:43, Davide G. M. Salvetti wrote: >> I think I found the cause. At installation time the auctex package >> starts in background (per default) the script udpate-auctex-elisp, which >> keeps running for some time after installation writing files in AB> If you write "per default", it there some way to change that behavior? Running it in foreground is a debconf low priority user choice. It does still take some minutes today on a typical desktop machine (used to be tens of minutes some years ago), so that it runs in background by default. AB> How long does it take? Or could it just be run in the foreground per AB> default? AB> I could just add some sleep for that package in piuparts... wouldn't be AB> the first time. Thanks, thinking about it however I feel that killing running update-auctex-elisp instances if any at package remove time is indeed the right thing to do. I will think some more on the proper way to kill them before uploading a bug fix. -- Pace e bene, Davide
Bug#867020: auctex: fails to remove: auctex/remove: Removing parsed (La)TeX macros for emacs25...rm: cannot remove '/var/lib/auctex/emacs25': Directory not empty
tags 867020 + confirmed patch pending
thanks
>>>>> AB == Andreas Beckmann [2017-7-3]
AB> Package: auctex
AB> Version: 11.90-1
AB> Severity: serious
AB> User: debian...@lists.debian.org
AB> Usertags: piuparts
AB> Hi,
AB> during a test with piuparts I noticed your package fails to remove.
>> From the attached log (scroll to the bottom...):
AB> Removing auctex (11.90-1) ...
AB> Remove auctex for emacs25
AB> auctex/remove: Removing parsed (La)TeX macros for emacs25...rm: cannot
remove '/var/lib/auctex/emacs25': Directory not empty
AB> ERROR: remove script from auctex package failed
AB> dpkg: error processing package auctex (--remove):
AB> subprocess installed pre-removal script returned error exit status 1
AB> This was observed during a test of stretch, i386, --install-recommends.
Hi Andreas,
thanks for the report; I can confirm it.
I think I found the cause. At installation time the auctex package
starts in background (per default) the script udpate-auctex-elisp, which
keeps running for some time after installation writing files in
/var/lib/auctex/${emacsen-flavor} as part of its job. During piuparts
tests the package gets removed before update-auctex-elisp has got the
chance to finish, so that when the package emacsen remove script invoke
the "rm --recursive --force /var/lib/auctex/emacs25" command
update-auctex-elisp still writes files in that directory. Thus it may
happen, as far as I can undestand, that rm fails due to the non
atomicity of its non empty directory removal operations, because
update-auctex-elisp may create a new file after rm thinks it has removed
all of the directory files and before rm tries and removes the
directory, resulting in rm trying to unlink a non empty directory.
If my analysis is correct, this bug is unlikely to manifest itself
during normal operations, since it can only happen if auctex gets
removed shortly after its installation.
The solution I'm evaluating is to kill running update-auctex-elisp
instances before invoking "rm --recursive --force
/var/lib/auctex/${emacsen-flavor}" in auctex emacsen remove script.
Since "update-auctex-elisp" should be a rather distinct and private
process name, I think I will do it with something along the lines of
"pkill -f update-auctex-elisp", as in the patch attached.
--
Thanks,
Davide
>From 0dd8709b456afa76f1d73d79da3e02a48fd6cc27 Mon Sep 17 00:00:00 2001
From: "Davide G. M. Salvetti" <sa...@debian.org>
Date: Sat, 12 Aug 2017 00:46:05 +0200
Subject: [PATCH] Kill update-auctex-elisp instances at package remove time
* debian/auctex.emacsen-remove.eperl: When the package is being removed,
take care of killing any running update-auctex-elisp instance before
removing parsed macro caches in /var/lib/auctex/$FLAVOR.
* debian/control (auctex/Depends): Add procps, needed for pgrep and pkill
used above.
Closes: #867020
---
debian/auctex.emacsen-remove.eperl | 9 +
debian/control | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/debian/auctex.emacsen-remove.eperl b/debian/auctex.emacsen-remove.eperl
index 79bf23294..c4adebc3e 100644
--- a/debian/auctex.emacsen-remove.eperl
+++ b/debian/auctex.emacsen-remove.eperl
@@ -36,6 +36,15 @@ undo_install () {
}
undo_update_auctex_elisp () {
+<: # Take care of running update-auctex-elisp instances :>//
+while pgrep -f update-auctex-elisp >/dev/null; do
+ echo -n "${PROGNAME}:" \
+ "Killing $(pgrep -fc update-auctex-elisp) running" \
+ "update-auctex-elisp instance(s)..."
+ pkill -f update-auctex-elisp || true
+ sleep 1
+ echo 'done.'
+done
echo -n "${PROGNAME}:" \
"Removing parsed (La)TeX macros for ${FLAVOR}..."
rm --recursive --force /var/lib/auctex/${FLAVOR}
diff --git a/debian/control b/debian/control
index d2489bb4c..b052b11af 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Vcs-Git: https://anonscm.debian.org/git/users/salve/auctex.git
Package: auctex
Architecture: all
-Depends: emacs25 | emacs24 | emacs-snapshot, emacsen-common (>= 2.0.8), preview-latex-style, ${misc:Depends}
+Depends: emacs25 | emacs24 | emacs-snapshot, emacsen-common (>= 2.0.8), preview-latex-style, procps, ${misc:Depends}
Recommends: ghostscript, texlive-latex-recommended, xpdf | evince | evince-gtk | okular
Suggests: catdvi, dvipng, lacheck
Breaks: emacspeak (<= 17.0-1)
--
2.11.0
Bug#839579: intent to NMU
> RV == Rémi Vanicat [2016-11-20] RV> Hello, I intent to nmu auctex for those 3 bugs, with the attached RV> patch: Fine with me, thanks for your work. While you are at it, I think you could also drop emacs23 support (just remove emacs23 wherever it occurs). -- Regards, Davide
Bug#768724: fixed in auctex 11.87-3
> RV == Rémi Vanicat [2016-9-23] RV> I intent to NMU auctex to fix this problem this week-end, if there RV> is no opposition against it. Thanks Rémi, you are welcome to NMU with this patch. RV> Davide, if you don't have time enough to take care of this package, RV> the new debian emacs package teams could probably take care of it if RV> you wish. I'd rather keep maintaining it. -- Thanks, Davide
Bug#768724: auctex: FTBFS in jessie: build-dependency not installable: emacs23
LN == Lucas Nussbaum [2014-11-9] LN Source: auctex LN Version: 11.87-2 LN Severity: serious LN Tags: jessie sid LN User: debian...@lists.debian.org LN Usertags: qa-ftbfs-20141108 qa-ftbfs LN Justification: FTBFS in jessie on amd64 LN Hi, LN During a rebuild of all packages in jessie (in a jessie chroot, not a LN sid chroot), your package failed to build on amd64. LN Relevant part (hopefully): [...] The following packages have unmet dependencies: sbuild-build-depends-auctex-dummy : Depends: emacs23 but it is not installable E: Unable to correct problems, you have held broken packages. apt-get failed. Hi Lucas, I do no quite understand: auctex Build-Dependes-Indep has emacs23 | emacs24 | emacs-snapshot, of which emacs24 is installable in jessie. What's the relevance of emacs23 (and emacs-snapshot) not being in jessie? I can remove emacs23 for jessie, but I would like to keep emacs-snapshot for people who might want to rebuild auctex on their system and have but emacs-snapshot installed. N.B.: emacs-snapshot is not in Debian, but there are repositories for it and AFAIK people do use it. -- Thanks, Davide -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768724: auctex: FTBFS in jessie: build-dependency not installable: emacs23
tag 768724 + pending thanks LN == Lucas Nussbaum [2014-11-9] LN Hi Davide, [...] LN sbuild (which is used on the buildds) only uses the first alternatives LN in build-dependencies in order to provide reproducible builds. I see. Shouldn't perhaps sbuild only use the first installable alternatives instead? Wouldn't it be reproducible as well? However, I will move emacs24 to the front for next uploads, and will upload 11.87-3 to close this bug in a few minutes. -- Thanks, Davide -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706098: auctex 11.86 is not loaded by emacs 23.4
tag 706098 +unreproducible +moreinfo thanks DC == Domenico Cufalo [2013-4-24] DC I just upgraded my machine from Squeeze to Wheezy. DC As in subject, it seems that auctex is not loaded by emacs. In another DC machine (but with wheezy Xfce 32bit; fresh installation), on the contrary, I'm DC not affected by this problem. DC Unfortunately I have no idea of how to make debugging in this case. ;-) I can not reproduce this bug. I can't parse «it seems that auctex is not loaded by emacs»: what did you do, and what did you expect to happen? Please, provide more information. For example, I suggest you to create a new account and try starting Emacs from that, to exclude every user configuration effects. -- Thanks, Davide -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694800: auctex: fails to upgrade or install
severity 694800 important thanks TK == Thomas Koch [2012-11-30] TK Package: auctex TK Version: 11.86-12 TK Severity: serious Downgrading to important (reread http://www.debian.org/Bugs/Developer: I fail to see how the serious level applies to this bug; feel free to educate me if you disagree). TK Hi, first I tried to upgrade auctex from 11.86-11 to 11.86-12. This TK failed with dpkg returning 1 from the configure step. I found a file TK /var/lib/auctex/emacs23'/CompilationLog TK containing: TK /usr/sbin/update-auctex-elisp: line 112: emacs23': command not found Looks interesting, thanks. TK Then I purged auctex and tried to install it again, what also failed: TK auctex/install: Byte-compiling for Emacs flavor emacs-snapshot (log to /usr/share/emacs-snapshot/site-lisp/auctex/CompilationLog)... done. TK Install auctex for emacs23 TK auctex/install: Byte-compiling for Emacs flavor emacs23 (log to /usr/share/emacs23/site-lisp/auctex/CompilationLog)... done. TK Install auctex for emacs24 TK auctex/install: Byte-compiling for Emacs flavor emacs24 (log to /usr/share/emacs24/site-lisp/auctex/CompilationLog)... done. TK Processing triggers for auctex ... TK dpkg: error processing auctex (--configure): TK subprocess installed post-installation script returned error exit status 1 This one too. TK Errors were encountered while processing: TK auctex -- Thanks, Davide -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506961: NMU diff for auctex 11.83-7.3
BH == Ben Hutchings [2008-12-7] BH I am uploading the following changes to delayed/3. Thanks Ben, I will let it in for the moment, due to the security implications. I think I will revert to /tmp as soon as I have some more time to ponder about it, which won't happen for at least two weeks. Please, if you think /var/log is better than /tmp on some other than security related grounds, let me know. -- Ciao, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503340: Bug#502762: Bug#503340: emacs-goodies-el: etch to lenny upgrade fails
MJ On Sat Oct 25 08:25, 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. Opinions? (mailcrypt maintainer here) As I've already said, I am for it. -- Ciao, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502762: Simple Fix - more cause and better fix
AM == Agustin Martin [2008-10-23] AM For the records, a proposed fix for sendmail.el Debian changes in emacs22 AM is to use AM (if (not (file-executable-p /usr/bin/mail)) AM (progn AM (message /usr/bin/mail is not executable) AM (setq mail-interactive t))) AM instead of AM (if (not (file-executable-p /usr/bin/mail)) AM (error /usr/bin/mail is not executable)) AM I am including #429059 in my reply, so emacs22 maintainers are aware that an AM RC bugreport has been filed against mailcrypt because of this problem and AM can join the thread. I think we should along this route, and I'm inclined to reassign this bug to emacs22. What do you think? -- Ciao, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502762: mailcrypt: piuparts test fails: emacs-install error
TW == Thomas Weber [2008-10-21] TW Package is dead upstream, maintainer seems MIA. Maintainer is here and reads what you write. -- Ciao, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502762: Simple Fix
MJ == Matthew Johnson [2008-10-22] MJ I am happy to NMU or sponsor a fix What about coordinating with the maintainer? -- Thanks, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483731: auctex: postinst failed with emacs-snapshot
Hi, please attach the /usr/share/emacs-snapshot/site-lisp/auctex/CompilationLog file. -- Thanks, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392863: Bug#395294: I'm going to NMU this
fant == Frank Küster [2006-10-26] fant Davide, I hope I don't interfere while you are just about to fant upload your own version. But since we haven't heard anything from fant you, I am not willing to wait. No problem for me, just go ahead. However, please, next time do spell your intentions to NMU clearly _before_ you do it, even if I have not answered your previous mails right away (the fact that I wait some time before replying does not mean that I don't read what you write: sending in another mail stating that you would like to NMU is appreciated). -- Thanks, Davide
Bug#374789: mailcrypt: Removing/purging the package fails
tags 374789 + confirmed pending thanks. YD == Yavor Doganov [2006-6-21] YD I am unable to remove the package, the following error occurs: I see, thanks for reporting. -- Ciao, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370638: auctex: fails to install
JG == Julian Gilbey [2006-6-6] JG No longer have the broken one. Seems the problem was caused by the JG /usr/bin/emacs symlink not existing. Do you think we can close this bug? -- Ciao, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355608: [Lewis, James M.] RE: Bug#355608: auctex: auctex-11.82-1 will not install
Hi Frank, as always, thank you very much for your help with the BTS. LJM == Lewis, James M [2006-3-16] LJM !! Found it. I had EMACS_UNIBYTE=t in the environment. I unset LJM that and it installed. I think that was cruft left over from LJM emacs 20 days. Can't remember now why I had it set... Shall we unset EMACS_UNIBYTE in emacsen install? I think it could be a good idea. -- Thanks, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349330: auctex also fails to configure with emacs21
Hi folks, just a quick mail to state that this is not the first time that we encounter this problem. Autoconf should not be called (of course, it should be called for CVS versions only); it's a timing problem, as you noticed. I do not recall if its in auctex or mailcrypt bts, but we have already discussed and solved the problem in the past. I am not sure of why 11.81-2 displays the problem again. IIRC we should have a line in emacsen.install which should take care of this (via a touch call), but maybe something has got messed up, or another configure dependency has been added in the Makefile (the bottom line is: make calls the configure target, while it should not). I will look into the bug asap. Thanks also for the gs dependency: I'd added it to Build-Depends-Indep and forgot Depends (now I have a doubt: does it also belong to Build-Depends-Indep, or maybe I just made a field mistake while adding it to Depends? I will check this again). -- Cheers, Davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341226: auctex: emacs freezes with fly spell chequer activated
severity 341226 important tags 341226 + moreinfo unreproducible thanks LFLD == Luis Fernando Llana Díaz [2005-11-29] LFLD Package: auctex LFLD Version: 11.55-1 LFLD Severity: critical LFLD Justification: causes serious data loss Hi! Please, do not abuse severity levels. You can find a description of their meaning and intended use at: http://www.debian.org/Bugs/Developer#severities. LFLD I have been using emacs/auctex satisfactory for quite a long time. LFLD Now I have activated the fly spell checker. It seems that when there LFLD is an italized word whose spelling is not correct then emacs blocks. On my systems, it seems not: I cannot reproduce this bug. Fly spelling works fine here with AUCTeX. Can you please provide a minimal example (a file or a buffer content) to trigger this bug, so that I can try to reproduce it? -- Thanks, Davide
