- Package:
- elpa-haskell-mode
- Source:
- elpa-haskell-mode
- Submitter:
- Frederic-Emmanuel Picca
- Date:
- 2025-06-03 18:05:01 UTC
- Severity:
- normal
- Tags:
Dear Maintainer,
While trying to open an haskell file, I get a error in the consol
Symbol’s value as variable is void: flymake-allowed-file-name-masks
When starting emacs -q and enabling the debug on error
I get this
Debugger entered--Lisp error: (void-variable flymake-allowed-file-name-masks)
add-to-list(flymake-allowed-file-name-masks ("\\.l?hs\\'" haskell-flymake-init))
load-library("haskell-mode")
funcall-interactively(load-library "haskell-mode")
command-execute(load-library record)
execute-extended-command(nil "load-library" "load-libraryhas")
funcall-interactively(execute-extended-command nil "load-library" "load-libraryhas")
command-execute(execute-extended-command)
So I would like your advice in order to solve this problem...
I observed also this kind of issue with magit...
Debugger entered--Lisp error: (void-function magit-menu-item)
(magit-menu-item "Rename file" #'magit-file-rename '(:enable (eq (magit-diff-scope) 'file)))
(define-keymap "C-j" #'magit-diff-visit-worktree-file "C-<return>" #'magit-diff-visit-worktree-file "C-x 4 <return>" #'magit-diff-visit-file-other-window "C-x 5 <return>" #'magit-diff-visit-file-other-frame "$
(defvar magit-diff-section-map (define-keymap "C-j" #'magit-diff-visit-worktree-file "C-<return>" #'magit-diff-visit-worktree-file "C-x 4 <return>" #'magit-diff-visit-file-other-window "C-x 5 <return>" #'magi$
load-with-code-conversion("/usr/share/emacs/site-lisp/elpa/magit-4.3.3/magit-diff.el" "/usr/share/emacs/site-lisp/elpa/magit-4.3.3/magit-diff.el" nil t)
require(magit-diff)
load-with-code-conversion("/usr/share/emacs/site-lisp/elpa/magit-4.3.3/magit.el" "/usr/share/emacs/site-lisp/elpa/magit-4.3.3/magit.el" nil nil)
load-library("magit")
funcall-interactively(load-library "magit")
command-execute(load-library record)
execute-extended-command(nil "load-library" "load-l")
funcall-interactively(execute-extended-command nil "load-library" "load-l")
command-execute(execute-extended-command)
Cheers
Frederic
Hi Frederic-Emmanuel, Frederic-Emmanuel Picca <picca@debian.org> writes: This seems to be the same as this upstream issue[1] which was supposed to be fixed in 17.5, and I cannot reproduce this when editing a .hs file (with haskell-mode enabled). Can you share the exact steps to reproduce this issue? Also providing the output of `M-x haskell-version' would be helpful. (Note that it would be better to file a separate bug report against magit so that it's easier to track each issue.) I cannot seem to be able to reproduce this on Magit 4.3.5, which should be available in sid. Can you try to upgrade to this version and try again? Similarly, `M-x magit-version' would be helpful. [1] https://github.com/haskell/haskell-mode/issues/1825
Hi Frederic-Emmanuel, Frederic-Emmanuel Picca <picca@debian.org> writes: This seems to be the same as this upstream issue[1] which was supposed to be fixed in 17.5, and I cannot reproduce this when editing a .hs file (with haskell-mode enabled). Can you share the exact steps to reproduce this issue? Also providing the output of `M-x haskell-version' would be helpful. (Note that it would be better to file a separate bug report against magit so that it's easier to track each issue.) I cannot seem to be able to reproduce this on Magit 4.3.5, which should be available in sid. Can you try to upgrade to this version and try again? Similarly, `M-x magit-version' would be helpful. [1] https://github.com/haskell/haskell-mode/issues/1825
Xiyue Deng <manphiz@gmail.com> writes: Hello Xiyue Dend, On my sid machine it is ok too. This bug is on a computer which I upgraded from bookworm to trixie. All I know is what I provided..., I load the package and boom... I can not provide the haskell-version on this machine due to this error... but the version on the working machine seems to be the same 17.5 This could be related to the bit compilation of the .el files. Is there some cache somewhere of nativ compilation of the elpa packages ? ? I will, do
Xiyue Deng <manphiz@gmail.com> writes: Hello Xiyue Dend, On my sid machine it is ok too. This bug is on a computer which I upgraded from bookworm to trixie. All I know is what I provided..., I load the package and boom... I can not provide the haskell-version on this machine due to this error... but the version on the working machine seems to be the same 17.5 This could be related to the bit compilation of the .el files. Is there some cache somewhere of nativ compilation of the elpa packages ? ? I will, do
"Debian Bug Tracking System" <owner@bugs.debian.org> writes: It seems that I found the culprite. on the working machine $ ls company-1.0.2 compat-30.1.0.0 debian-el-37.19 dpkg-dev-el-37.19 haskell-mode-17.5 htmlize-1.58 llama-0.6.2 magit-4.3.5 magit-section-4.3.5 notmuch-0.39 transient-0.8.8 with-editor-3.4.3 on the non working machine # ls company-0.9.13 dash-2.19.1 debian-el-37.19 dpkg-dev-el-37.19 flycheck-35.0 ht-2.3 llama-0.6.2 lv-0.15.0 magit-section-3.3.0 notmuch-0.39 spinner-1.7.4 with-editor-3.4.3 company-1.0.2 dash-2.20.0 devscripts-40 f-0.21.0 haskell-mode-17.2snapshot htmlize-1.56 lsp-haskell-1.0 magit-4.3.3 magit-section-4.3.3 powerline-2.4 transient-0.8.8 compat-30.1.0.0 debian-el-37 dpkg-dev-el-37.0 flycheck-32snapshot haskell-mode-17.5 htmlize-1.58 lsp-mode-9.0.0 magit-popup-2.13.3 markdown-mode-2.7 s-1.13.0 with-editor-3.0.5 look at these snapshot directory... what is the best way to clean this properly ? Fred
picca <picca@debian.org> writes: It seems that during the upgrade from bookworm to trixie, the old bookworm files where not removed... https://packages.debian.org/bookworm/all/elpa-haskell-mode/filelist Cheers
Hi Frederic-Emmanuel, picca <picca@debian.org> writes: bookworm: install elpa-haskell-mode, run `apt upgrade' to trixie, and run `emacs test.hs', but this doesn't seem to trigger this issue either. However, I do notice another issue in this process: the directory linked to /usr/share/emacs/site-lisp/elpa for the older version of elpa-haskell-mode is not cleaned up, which I'll file a separate issue. In the meantime, can you check under that directory that whether the directory for the older version of haskell-mode is still there? And if that's the case, can you remove that and try to reproduce? See above for the location of the potentially lingered over compiled caches for the previous version. If you do find the lingering directories, these 2 issues could be related, so let's track both here.
Hi Frederic-Emmanuel, picca <picca@debian.org> writes: test it doesn't actually caused the issue you were experiencing, those lingering files would be problematic anyway. In my test, this only happens when you run `apt upgrade' (with or without `--without-new-pkgs'), but not for `apt dist-upgrade'. Can you confirm which command you used for upgrading? For the testing purpose, I'd like to ask for a favor: can you try to move them out (e.g. to /tmp) and try to reproduce; and then move them back and retry to reproduce? This can help confirm that it was those lingering directories that was causing the issues for you. Thanks!
I think this could be one instance of the older-addon-version-left-over
issues like Bug#1099205. I managed to find a reproducer using my
Bookworm docker instance (I think a sbuild chroot also works):
1) Install elpa-haskell-mode
,----
| # apt install --no-install-recommends elpa-haskell-mode
`----
2) Update source.list/debian.sources to Trixie
,----
| # sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources # Or /etc/apt/sources.list
`----
3) Update and upgrade
,----
| # apt update
| # apt upgrade --without-new-pkgs # also reproducible without the option
`----
4) Notice that the directory for older version of the affected addon
still exists and contains broken links
,----
| $ ls -l /usr/share/emacs/site-lisp/elpa/
| total 8
| drwxr-xr-x 2 root root 4096 May 23 07:08 haskell-mode-17.2snapshot
| drwxr-xr-x 2 root root 4096 May 23 07:14 haskell-mode-17.5
`----
On further debugging, I think this happens when one has Emacs,
dh-elpa-helper, and an addon installed, and try to upgrade from Bookworm
to Trixie which upgrades emacsen-common. This combination requires the
creation of symlinks under
/usr/share/emacs/site-lisp/elpa/<package>-<version>/, and this happens
because the helper/remove script of the previous version of the addon is
not run. (In rare case, if one only installs the addon but not Emacs,
those symlinks are not created, so this doesn't matter.)
I believe that the actually issue here is that when emacsen-common is
unpacked but not configured, the helper/remove script will not run for
any Emacs addon that was unpacked before emacsen-common is configured
that was. As such, a minimal reproducer is to change the step 3) to the
following:
3) Update and upgrade emacsen-common and the affected package
# apt update
# apt install emacsen-common elpa-haskell-mode
See below for a session that exhibits the issue:
,----
| $ sudo apt install emacsen-common elpa-haskell-mode
| [..skip other informational output..]
| The following packages will be upgraded:
| elpa-haskell-mode emacsen-common
| 2 upgraded, 0 newly installed, 0 to remove and 515 not upgraded.
| Need to get 202 kB of archives.
| After this operation, 27.6 kB of additional disk space will be used.
| Get:1 http://deb.debian.org/debian trixie/main amd64 emacsen-common all 3.0.7 [12.7 kB]
| Get:2 http://deb.debian.org/debian trixie/main amd64 elpa-haskell-mode all 17.5-2 [190 kB]
| Fetched 202 kB in 0s (9888 kB/s)
| debconf: unable to initialize frontend: Dialog
| debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 2.)
| debconf: falling back to frontend: Readline
| (Reading database ... 46666 files and directories currently installed.)
| Preparing to unpack .../emacsen-common_3.0.7_all.deb ...
| Remove emacsen-common for emacs
| emacsen-common: Handling removal of emacsen flavor emacs
| Unpacking emacsen-common (3.0.7) over (3.0.5) ...
| Preparing to unpack .../elpa-haskell-mode_17.5-2_all.deb ...
| Unpacking elpa-haskell-mode (17.5-2) over (17.2-5) ...
| Setting up emacsen-common (3.0.7) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| Setting up elpa-haskell-mode (17.5-2) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| Install elpa-haskell-mode for emacs
| install/haskell-mode-17.5: Handling install of emacsen flavor emacs
| install/haskell-mode-17.5: byte-compiling for emacs
| Processing triggers for install-info (6.8-6+b1) ...
`----
Note that after preparing to unpack the newer version of emacse-common,
it was removed from Emacs, and before the newer version was set up,
elpa-haskell-mode was unpacked, and the helper/remove script didn't run
because there is no emacsen-common available.
Another interesting finding is that `apt dist-upgrade' is unaffected,
because in that process Emacs is upgraded and it will remove all known
addons before emacsen-common is processed, and thus not triggering this
issue.
I think this issue happens because of the recent update of
emacsen-common. If there is no update for it we won't see this issue
(e.g. from o-o-stable to o-stable).
An obvious fix for this is to make an addon Pre-Depends (according to
the Policy[1]) on emacsen-common of the latest version so that it is
ensured that emacsen-common is configured before an addon is unpacked.
However this requires updating the policy to add a `Pre-Depends' to all
packages, and to make it worse, we need to update the emacsen-common
version each time it is updated, which obviously doesn't scale.
Because ${elpa:Depends} also contains dh-elpa-helper, I tried to make
dh-elpa-helper Pre-Depends on `emacsen-common (>= 3.0.7)', and the
several test runs seem to suggest that it works. See below for a
working example (dh-elpa-helper 2.1.10 is my custom build with the
pre-depends):
,----
| $ sudo apt install elpa-haskell-mode ./dh-elpa-helper_2.1.10_all.deb
| [..skip other informational output..]
| The following packages will be upgraded:
| dh-elpa-helper elpa-haskell-mode emacsen-common
| 3 upgraded, 0 newly installed, 0 to remove and 514 not upgraded.
| Need to get 202 kB/212 kB of archives.
| After this operation, 29.7 kB of additional disk space will be used.
| Do you want to continue? [Y/n]
| Get:1 /home/manphiz/Projects/debian-packaging/build-area/dh-elpa-helper_2.1.10_all.deb dh-elpa-helper all 2.1.10 [9544 B]
| Get:2 http://deb.debian.org/debian trixie/main amd64 emacsen-common all 3.0.7 [12.7 kB]
| Get:3 http://deb.debian.org/debian trixie/main amd64 elpa-haskell-mode all 17.5-2 [190 kB]
| Fetched 202 kB in 0s (6910 kB/s)
| debconf: unable to initialize frontend: Dialog
| debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 3.)
| debconf: falling back to frontend: Readline
| (Reading database ... 46666 files and directories currently installed.)
| Preparing to unpack .../emacsen-common_3.0.7_all.deb ...
| Remove emacsen-common for emacs
| emacsen-common: Handling removal of emacsen flavor emacs
| Unpacking emacsen-common (3.0.7) over (3.0.5) ...
| Setting up emacsen-common (3.0.7) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| (Reading database ... 46667 files and directories currently installed.)
| Preparing to unpack .../dh-elpa-helper_2.1.10_all.deb ...
| Unpacking dh-elpa-helper (2.1.10) over (2.0.16) ...
| Preparing to unpack .../elpa-haskell-mode_17.5-2_all.deb ...
| Remove elpa-haskell-mode for emacs
| remove/haskell-mode-17.2snapshot: Handling removal of emacsen flavor emacs
| dh-elpa: purging flavor specific files for emacs
| Unpacking elpa-haskell-mode (17.5-2) over (17.2-5) ...
| Setting up dh-elpa-helper (2.1.10) ...
| Setting up elpa-haskell-mode (17.5-2) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| Install elpa-haskell-mode for emacs
| install/haskell-mode-17.5: Handling install of emacsen flavor emacs
| install/haskell-mode-17.5: byte-compiling for emacs
| Processing triggers for install-info (6.8-6+b1) ...
`----
Note that emacsen-common is configured before processing dh-elpa-helper
and elpa-haskell-mode, and helper/remove was run properly (notice the
"Remove elpa-haskell-mode from emacs" line).
This is also the reason why I'm reassigning to dh-elpa-helper instead of
emacsen-common. Hopefully this is a working single point of fix.
I have created a branch `bug#1106291' that contains the fix. The diff
can be seen at [2]. We need to bump the version on each emacsen-common
update as well.
As the fix involves using Pre-Depends, Policy suggests that it should be
discussed on debian-devel@. Please let me know whether this fix is
acceptable, or if other fixes are better and preferred.
TIA.
[1] https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
[2] https://salsa.debian.org/emacsen-team/dh-elpa/-/compare/master...bug%231106291?from_project_id=18920
control: reassign -1 dh-elpa-helper,emacsen-common Hello, Thanks for investigating. We can't add Pre-Depends without RT approval and -devel approval. You'd need an argument why that's the *only possible* fix, not just an argument that it works as *a* fix. Based on reading your report, it is not clear to me whether the bug is in dh-elpa or emacsen-common, so reassigning to both for now. Rob, what do you think? How is the symlink cleanup meant to work?
Hi Sean, Sean Whitton <spwhitton@spwhitton.name> writes: I don't know whether there is another way to ensure that an addon is not unpacked when emacsen-common is also unpacked but not configured/set-up. Pre-Depends on emacsen-common ensures this. Ack.
Hello, There might not be, but it might be possible to fix this concrete problem without ensuring that an addon is not unpacked when emacsen-common is not configured.
Hi Sean, Sean Whitton <spwhitton@spwhitton.name> writes: This sounds interesting. I think another possible fix is to let emacsen-common do `emacs-remove $FLAVOR' on preinst, so that the elpa directory of the old version of addon is cleaned up; and `emacs-install $FLAVOR' on postinst to handle the current version of the addon (could be old if the newer version is not yet unpacked). This requires that an addon is not configured/set-up before emacsen-common, which seems to be the case during my testing because an addon Depends on emacsen-common, I guess. Would be good if someone can confirm this behavior from from `apt upgrade'. This basically does what emacsVAR does during `apt dist-upgrade', which circumvents this issue during my testing. If this process sounds about right, I can try to implement and test.
Hello, We don't need to do this by experimentation :) Everything about what maintscripts may and may not assume is written down in Policy. Please take another look.
Hi Sean, Sean Whitton <spwhitton@spwhitton.name> writes: Indeed. Policy seems to confirm the assumptions this solution requires. I have implemented this in this RM[1], and run in my docker instance several times to test it and it seems working. Please review. [1] https://salsa.debian.org/rlb/deb-emacsen-common/-/merge_requests/3
Hello, We need Rob's review, but a couple of very general comments: - maintainer scripts are meant to be idempotent, i.e., if they are interrupted at any point and restarted, they should still do the right thing. I think this will be true of your scripts, but did you think about it? - I would suggest using find(1) instead of parsing the output of ls(1).
Hi Sean,
Sean Whitton <spwhitton@spwhitton.name> writes:
Yes. My additions to the preinst/postinst are idempotent as long as the
emacs-{install,remove} scripts are idempotent, which I think is the case.
Ack. I use "$(find "${DIR}" -type f -exec basename "{}" \;)" to get the
file names without path which is a bit long. Do let me know if there is
a better way.
MR updated. PTAL.
Hello,
find "${DIR}" -mindepth 1 -printf '%P\n'
Hi Sean, Sean Whitton <spwhitton@spwhitton.name> writes: TIL. I guess the "-type f" part is optional. Updated MR accordingly.
As we are mostly pursuing fixing this in emacsen-common, I'm reassigning to emacsen-common only and retitling accordingly.
We believe that the bug you reported is fixed in the latest version of
emacsen-common, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1106291@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Rob Browning <rlb@defaultvalue.org> (supplier of updated emacsen-common package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 03 Jun 2025 12:17:26 -0500
Source: emacsen-common
Architecture: source
Version: 3.0.8
Distribution: unstable
Urgency: medium
Maintainer: Rob Browning <rlb@defaultvalue.org>
Changed-By: Rob Browning <rlb@defaultvalue.org>
Closes: 1106291
Changes:
emacsen-common (3.0.8) unstable; urgency=medium
.
[ Rob Browning ]
* debian/changelog: correct lexical-binding warning info.
Thanks to Sean Whitton for reporting the issue.
.
[ Xiyue Deng ]
* When emacsen-common and add-ons are upgrading simultaneously,
aemacsen-common can be unpacked but not configured when an add-on's
prerm runs. That causes the add-on's removal command to be skipped,
which can cause the upgrade to fail. As a mitigation for now, remove
all installed emacs flavors in the preinst, keeping track of the fact
that they're really still installed, and then restore them from the
postinst, when emacsen-common is ready again. (Closes: #1106291)
Checksums-Sha1:
45aa6b47bde8a975e32aed91fa527fd9934e79fb 1585 emacsen-common_3.0.8.dsc
266850442d93e0589463532462be73de426248bd 17604 emacsen-common_3.0.8.tar.xz
9d49013718307568ff8beb5e8d980cf1c73d6853 5665 emacsen-common_3.0.8_amd64.buildinfo
Checksums-Sha256:
7218d84e7c8e11ab4a9fc73e988df3ad6f8cb1e17d61a778ab06e486c3fba065 1585 emacsen-common_3.0.8.dsc
6145aba63f38a611ce99ee2c46c4213d3f76aa4760df1544dd29217fa95c6feb 17604 emacsen-common_3.0.8.tar.xz
852dea9ac2c451cbebf374a2efa7eaaa21a1ef4a37f8a9c96319a46263ea8a09 5665 emacsen-common_3.0.8_amd64.buildinfo
Files:
9df41743fcd3c310eaf1f1bdbfdc1d1e 1585 editors optional emacsen-common_3.0.8.dsc
1982a634de9ab0a8f0913aafe2af5dba 17604 editors optional emacsen-common_3.0.8.tar.xz
8da3d34c0f0378603a16727a5810625d 5665 editors optional emacsen-common_3.0.8_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJJBAEBCgAzFiEEPTFSABe5ruOuhW+97vEWxVpaQvEFAmg/M50VHHJsYkBkZWZh
dWx0dmFsdWUub3JnAAoJEO7xFsVaWkLxhl8QAJrlgyzbFaXU+SChEo+6xG0yP9yb
Lk382WfqU4arlVfng2LhcBUbqSnB29pXsQ0zw2BflMEjegmxyethazB9lAS8+Fai
n9wXg4HqIY+NKzNhQjFXNNNe/L31ymcx9ZBL7HalxJLx27KCPbaR1FXycssIr5e/
zsmCpUAOpKTCCuIJ5x5fJ8vdeUZ4Uf011s5BCzHY39r0SOdj1ZCY/3aeGEZ4eNtx
RVJ4xnlXJMJaBwNaf3fD3IR9QS4EwY1VABeHLDsTqwPLbUvUEwdQiNedgS/fuZW3
7R3MujMDGdLSIu38HQMozdqJN8gZmWeyh4nGNBPBNj+8JKlJtpr8LCkprtf52fGf
PWcroSLcfP3Scu44ntLcA8rHoGgfz+5yE7UrM+mBy5bIs6lkaycQRioQZexLvSGm
292m56Df4CQYgi8laqwJIzdmPbbRjzct5WJqJZCUO4tMxeeWejJsknU4lr54ZHA1
RZJNC2z+2M0+BKoSlTlJpZF+0Eq/N+OPvocd9OTkCZfZB6g3ALNMeLAH5wt/vLeG
spPsyozL/LlerT3q31+T013zqhjopCAj9e0g/7y/V50gfrromyEnimMItmIfrTfX
Y+A0GtcQ0Zk7AS5izEhsLebCjfUkYDlIV8pr7Wv4fuX8pus0oAsRwfY/QkXVf/xq
KdnmekcxhEvUExNo
=jGZK
-----END PGP SIGNATURE-----