Bug#1071585: libsingular4m3n0t64: SONAME change w/o package rename
Package: libsingular4m3n0t64 Version: 1:4.4.0+ds-1 Severity: serious Justification: Policy 8.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to policy 8.1 "The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes." The most recent upload of singular (4.4.0+ds-1) bumped the SONAME but did not rename the shared library package or otherwise do a transition. This broke at least polymake at run time. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsingular4m3n0t64 depends on: ii libc62.38-11 ii libflint19 3.1.2-1 ii libgmp10 2:6.3.0+dfsg-2+b1 ii libntl44 11.5.1-1+b2 ii libreadline8t64 8.2-4 ii libstdc++6 14-20240330-1 libsingular4m3n0t64 recommends no packages. libsingular4m3n0t64 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZMyK0ACgkQA0U5G1Wq FSG2gQ//QmM6pmFe/VFcB94PRKvyMRd153JwHmaw1HJ8XQi/+8UTa+43/gQxg+sL KQ1ydhXHZeWGtRBW9Vb/iG/fGQtU8Si0NZ2385o5IP/CPpu06ZlhL59vkj/xx/pt 4c0knwl/5dSM46V8sbaHUdEqKUIerJek5R4Pc4EzcwNtTIubLQYyUv1ho/Xkf/3A ZyhwBlerM0XOge1UICG3RMfNLVRkJdRWtsx/LpRDFa4gu1UYRSCEv4TUA+ZFB9xd PCcDaKfqcqa/sBhbFbtGvU1Vc/jyCj46weiJg9VIKXxorEyj4udfDYsp0MfHqFC7 VKtQvSK0zwa8TQ8TDRTILpL2Ht6W2YKQ9+2Pnxw1NvyQma3X1+mFwZJUU/6RgWpG 9+K7iKWfllgO2DlJYoJXgZCzViPG1tXwAQ0k0zIolrgMcyOs1/ke46vAmI3XSpQ4 rGOb4XMNuF3ehFRRziHApPvKKD/wF2GcJyiPJJ1jEQ0yo+dcC3m1V7aHYmzUJJIt maSxVZlfIsEJdQq1r+L2QMOjO8QmXDhTjqGX9YXoM8flGywUz3+pkyVh02KjCMHu R6/QAvsDTCIOuCw/H1+JzEy0vvCOg/vg+dX93BW/9t2JEyu/dkeo5TTcbloQ12D0 65akpFKjsaiNtZao96AaOPvzFBmNeWZ/9O9rlW64cQUstptSpoQ= =dlC5 -END PGP SIGNATURE-
Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting
Control: severity -1 important > Source: racket > Version: 8.12+dfsg1-7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel OK, I figured out why this doesn't show up on the buildd's: they don't build the arch all packages on armel. For many years, armel hasn't been able to build the documentation for racket, and it has been disabled there. After some informal consultation with the release team I'm downgrading this bug to non-RC. I'll work on having more clear diagnostics for the build failure. I don't know how common this scenario is, but it might make sense to restrict such rebuilds to arch:any on armel (and armhf), depending on your goals of course.
Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting
Control: tag -1 confirmed Lucas Nussbaum writes: > Source: racket > Version: 8.12+dfsg1-7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armel. Thanks for the report. I don't know why it wasn't triggered previously, but I can confirm the problem is not architecture specific, and I can replicate it on amd64 with CONFIG_ARGS_amd64 := --disable-docs --enable-bc Rather than being architecture specific it seems related to the configuration options that happen to only be used for armel at the moment.
Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Sebastian Ramacher writes: > Control: affects -1 src:polymake > [...] > Let's make sure that it is visible for polymake then. Otherwise I'll > file it a third time ;) Thanks, I thought to myself at some point this morning it should have affects, and then, well, I didn't do it. many hands make light-er work, I guess David
Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Control: reassign -1 flint Sebastian Ramacher writes: > Source: polymake > Version: 4.11-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=polymake=amd64=4.11-2%2Bb4=1711743555=0 As I said the previous two times this bug was reported, as far as I know this has to be a bug (uncoordinated transition) in flint. I guess I can stop building polymake against flint, but really someone(TM) should fix flint. The fact that it uses a hardcoded shlibs file instead of symbols is a bit worrying for me.
Bug#1067363: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Control: reassign -1 flint Lucas Nussbaum writes: > Source: polymake > Version: 4.11-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > I'm fairly sure this is actually a bug in flint.
Bug#1067663: org-mode: Org mode 9.6.23 that fixes several critical
Package: org-mode Version: 9.6.10+dfsg-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: debian-emac...@lists.debian.org, Debian Security Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In https://list.orgmode.org/87o7b3eczr@bzg.fr/T/#t, Ihor Radchenko writes I just released Org mode 9.6.23 that fixes several critical vulnerabilities. The release is coordinated with emergency Emacs 29.3 release (https://lists.gnu.org/archive/html/info-gnu/2024-03/msg5.html). Please upgrade your Org mode *and* Emacs ASAP. The vulnerabilities involve arbitrary Elisp and LaTeX evaluation when previewing attachments in Emacs or when opening third-party Org files. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages org-mode depends on: ii elpa-org 9.6.10+dfsg-1 org-mode recommends no packages. org-mode suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmYBSjMACgkQA0U5G1Wq FSHjuA/+PbZdJex2gariys1U8zA9ExAUW0TKE2Pt/k/bngZt9+B7JGm1bNqSMkBm mPN+6uIEZdmmasNCqHzNwlxPyezWnL1ik4n3lfz1fkXMSf7YWExcL/rnBvsc6aqi yzTB0IPP2+1Jx0BV3ysiX62eRlLXiv3NlJQuKHyOwVCjOUDJUdN25YgZQ7b4Q2/S 4lC6O1wkmJqyV/PopvHIeFTo76l8Cg612ZGFrdniXkWB4zUSl2MdfsduimFO4xfp /izY1u7nCT+bdsKT6OdvKqV5bStEukiklo/A2V9KTWrAQ2xeNwgE0gtP6MYzVfZ+ f7of4+SCqt0dZMwLiuZse+XA82nPnDqSdiT5A5EGRQ8am5BQ9d0weOoaQMho3vym bUQO0rdU0MCrZR3MxCH4YPKm1ge1wPS7zLL48/+6PFhlHHkmQ1t98EzCbJ+gEgJW Qm/wnT0ctJRmp2uqGDpRLeI0t+YU/kyfaaHS/rB7XSkQN6vBmJKnClGmgFnhVphR hrQVVpJjD0SeZSv9uOUI17HfPz9v3pIKLCMs4R2+WTddxf6bdXytFmlOWBlcvEpE 0ocIW00D68jDWx0Bq1PItEJ11V9GbcqrigtBHfEocYVnL4hB3x5lkaGkMF5P2gOn 4OL3eC+UqJoEpr53PiD5fdbo7WkeI3NCdDBqb/GDn9Kj4HQyZqY= =aTCW -END PGP SIGNATURE-
Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"
Source: emacs Version: 29.2+1-2 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team , debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to the 29.3 release notes * Changes in Emacs 29.3 Emacs 29.3 is an emergency bugfix release intended to fix several security vulnerabilities described below. ** Arbitrary Lisp code is no longer evaluated as part of turning on Org mode. This is for security reasons, to avoid evaluating malicious Lisp code. ** New buffer-local variable 'untrusted-content'. When this is non-nil, Lisp programs should treat buffer contents with extra caution. ** Gnus now treats inline MIME contents as untrusted. To get back previous insecure behavior, 'untrusted-content' should be reset to nil in the buffer. ** LaTeX preview is now by default disabled for email attachments. To get back previous insecure behavior, set the variable 'org--latex-preview-when-risky' to a non-nil value. ** Org mode now considers contents of remote files to be untrusted. Remote files are recognized by calling 'file-remote-p'. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmYAhNIACgkQA0U5G1Wq FSEANg//cukjqohXxNRpkxbutqHHvOB1aAr3d78jowjP3Yb9ozAArNxUjuJHEdSZ 5HCASm269atf5753maZILjyx3VmF/qUihyGjbbWjqMwNrQkkQiuXBfYn1F4R76/V tyFile5NZVXIgYMykLb+rSHap6KMBnhjvLWSwNsDMuD8WB7OPH7KOI2xYqkUb7ue SIgkCr0GJ+LaHOAYlRKkAYok4qwIfijLBw41Bt7t9Tawh+5d5nDkNPDphFOB+bG+ 1hOQD8KVYWIceRK83wcDictSxbeTSo/cp6cEtVZX3yrDvBRbj3VKjKWL+0UIKfWO iGWQYn622B7WbBIwEddQMmla+nxa5rxEN9VMEE8N5xcpI1lnL0lVSxw0jbT0FopJ PmwFYmz1+pxB2fhRTv1T7ZTSAJS3BKQ9u2R8tuKO5ilSYp1zJrBBIazGPZ3Q+UBS EoPh4hy5G4IZ3X3yaE9cX76fdDMMGPQ7HIinkw5A7KWb8zHse5m3+WG+iPNuveHU GRwOB9pDDRTQrQVG8of2YVS0kLb9eu2jUD0sbi8As3P5Mr/gXHlrSgs5t1qg3HuA Kkg7m7PAONZu0LBZNZsItm/V0weDqBdE+LZsa/1LUk3H+zvswhctlNLuZ7Y4mKqh YpuwmZ2+cv1To2M/DKbBx2ngl5EiojF8hk5pGezcZ811NRFAQKc= =BxE4 -END PGP SIGNATURE-
Bug#1065041: src:racket-mode: fails to migrate to testing for too long: autopkgtest failure
Paul Gevers writes: > Source: racket-mode > Version: 20231222git0-1 > Severity: serious > Control: close -1 20240129git0-1 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > In principle the autopkgtest failure should be fixed with 20240129git0-2 just uploaded to unstable. We'll have to wait for the servers to catch up to see for sure. d
Bug#1053405: darktable: FTBFS on arm64 (gcc bug?)
Gianfranco Costamagna writes: > Source: darktable > Version: 4.4.2-1 > Severity: serious > forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 > tags: ftbfs > Do you think maybe there should be a debian gcc bug? after all, the distinction you point to is a difference of debian version. d
Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid
Control: severity -1 important David Bremner writes: > Andreas Beckmann writes: > >> Package: compat-el >> Version: 29.1.4.1-2 >> Severity: serious >> >> elpa-hl-todo/sid is currently uninstallable since it depends on >> elpa-compat (>= 29.1.4.2). >> >> >> Andreas > > Maybe it doesn't matter, but I don't think this is a serious bug in > compat.el. It's not like a it's a regression. It's a serious bug in the > package which is uninstallable. Addendum: it does matter, there are a bunch of rdepends and unless they all don't work with current elpa-compat, then it is needlessly disruptive to auto-remove elpa-compat (or even to mark it for auto-removal). elpa-hl-todo has a versioned depends which is wrong.
Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid
Andreas Beckmann writes: > Package: compat-el > Version: 29.1.4.1-2 > Severity: serious > > elpa-hl-todo/sid is currently uninstallable since it depends on > elpa-compat (>= 29.1.4.2). > > > Andreas Maybe it doesn't matter, but I don't think this is a serious bug in compat.el. It's not like a it's a regression. It's a serious bug in the package which is uninstallable. d
Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader
Source: flycheck Severity: serious Justification: Team decision X-Debbugs-Cc: debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nobody has stepped up to take care of flycheck, and it currently blocks the transition of emacs 29 to testing. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmTmA08ACgkQA0U5G1Wq FSFx4RAAug0/SVS+L2nFAKwRHgsqypfuSZ46JP+ayMV+O3yLc2vyZy6HOgt1Ew7c Psfjt3s3ba2adbOZraPT0CAx2Dgz/0cKg2Rm4M6fMOCwYsqjwNSlPpE8rw0o0k5i xPV5x+WKpoGWQB4sWW3QqDmZEdU3OY3szkpCKxDnR2Dk4rGRXBbI1utH4DOpdT8R fCN6Qg+MWtimK+M33n/nklxvK8Ze7RLo2swy19rk/3ekJ3ZkwmXLmlVCRjEyt/bR 6uROHIX4HzK0La8JlU7gTgc77tZpC7uovbRQiMZOX8Waw0eIb9lqSMtKWJI8XgLG v255LLb8qyaAbXBlq+D/ettUauAcJkEAWPSMuJ+WPkKuYotbyIXYBpELOa1f0EkF /khUdCYob2Jak81cRURC7cY4JDWVa0qlLCWGYaKpTW4ACAajBrq1BSfAyrjFFuGS XfBDj+0CSqtWo1ZR4Krpgg23xPFPWo07+TGhSAyqsbhmWfsHLqB9+kF930yZ/76+ cXI/zgFZ0pAXRzBIVxPCB7qN9AH+Zr8et4U2mn2Rc3PbpmZZflOw/spqOsXJe1XR 8i7+K3AkPtfeaGXqaDQI4y+uTi7Vq8tWwBwqDavThQtZH1kSfUfx5AiqNuvCnyUb yLd/pDqgRr69GEo2YuS3T2HvK55hFtiDGZWjiSF1ddybcOtaT5s= =tOrz -END PGP SIGNATURE-
Bug#1041271: maildir-utils: public shared library shipped in maildir-utils binary package
Package: maildir-utils Version: 1.8.14-2 Severity: serious Justification: violates policy 8.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think that libguile-mu.* need to be either moved to a private directory or to their own packages. I don't know enough about guile to say which is better. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maildir-utils depends on: ii guile-3.0-libs 3.0.8-2 ii libc6 2.37-3 ii libgcc-s1 13.1.0-6 ii libglib2.0-02.74.6-2 ii libgmime-3.0-0 3.2.13+dfsg-2 ii libreadline88.2-1.3 ii libstdc++6 13.1.0-6 ii libxapian30 1.4.22-1 maildir-utils recommends no packages. maildir-utils suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmS0If4ACgkQA0U5G1Wq FSFdlw//drvAFftKxrrn1Hk+A1wYL0ATPOgwI/61u3sC4P/uQRcTbC6zfJcO/uca GJVFWaUHIFsmPr3lwQf6KkZweBtdnm38MXsXbxw7uBH5abEKoLPZCEr0FzArfZe/ CaPFMHgCl6/k25BNigIXUcx5rgvoLCjRYrh8RVvrIN/NWfEioYDYqYs4+ZEmswP3 fMOdoqfohtXlisfKrrI/ysK00gJpI0vWYJzdEcapirDy7eMtSBXOqjUz2a3kGJ/h Oxtg1J1GCSp/pAb3lJvAojxITQI69ZAkX2T6xGqXUhGbRCKjVUulovI0iSQGbwM4 mKDMs5oH6kn8gM9z/HTUpoxhLE85KbMQjtsTx6MoXXZKPat02ipzloc3NqWQyBDj pL8BEpnU6Hc0MtZLI6Q+gUG1akq5BmB24pKxrcEfAVRSdFXbOjfGIHjyH6achfcn QwOz6R5kNte4VLfCOvWXhnsDvCeiOfePC/gaVqvvzJR5/iWMovDOdBTshK9uXWkl 3hgwYqRIYRtnKobz8QcOnqTbVxFiJv8gyaOm7cbhzKGfWeMFwv38mhmJXaRj7Znv zb8MqG2eK89v8ZkD7RxsfVVOGOU94102QwlmQ6QOuB4etVyfuUkjjnRsjJgwSRE1 TtlYcHfIj8M2EgMPWEB2mjcFb/TKlx48+Br53YNk3z6mErYJtZk= =HGuU -END PGP SIGNATURE-
Bug#1037765: maildir-utils: ftbfs with GCC-13
Matthias Klose writes:
> Package: src:maildir-utils
> Version: 1.8.14-1
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
>
> [This bug is targeted to the upcoming trixie release]
>
> Please keep this issue open in the bug tracker for the package it
> was filed for. If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
I suspect we should probably move to a new upstream version rather than
adding yet another patch. However, if for some reason we want to stay
with 1.8.14, it looks like this specific issue is fixed by upstream
commit
ce9446465260bd108bcf554cf503f72304f4276b
I attach a version with conflicts resolved (although I don't know the
codebase well enough to say if my resolution is correct). With that
patch the code builds, but the build still fails with mu4e.info and
mu4e-guile.info not being installed.
dh_missing: warning: usr/share/info/mu-guile.info exists in debian/tmp but
is not installed to anywhere
dh_missing: warning: usr/share/info/mu4e.info exists in debian/tmp but is
not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed
(with files per package)
* dh_elpa: maildir-utils (0), mu4e (25)
* dh_install: maildir-utils (6), mu4e (0)
* dh_installdocs: maildir-utils (3), mu4e (0)
* dh_installman: maildir-utils (0), mu4e (0)
From: =?utf-8?q?Arsen_Arsenovi=C4=87?=
Date: Sat, 21 Jan 2023 19:39:09 +0100
Subject: mu-error: Add missing include
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
GCC 13s libstdc++ reduced its dependency on some headers like , so it's
no longer transitively included through various headers. Include it explicitly.
See also: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
../lib/utils/mu-error.hh:36:26: error: ‘uint32_t’ does not name a type
36 | static constexpr uint32_t SoftError = 1 << 23;
| ^~~~
---
lib/utils/mu-error.hh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/lib/utils/mu-error.hh b/lib/utils/mu-error.hh
index c67fc5a..d3e2fc4 100644
--- a/lib/utils/mu-error.hh
+++ b/lib/utils/mu-error.hh
@@ -21,8 +21,10 @@
#define MU_ERROR_HH__
#include
+#include
+#include
+
#include "mu-utils-format.hh"
-#include "mu-util.h"
#include
namespace Mu {
@@ -160,11 +162,18 @@ struct Error final : public std::exception {
* @param err GError** (or NULL)
*/
void fill_g_error(GError **err) const noexcept{
- g_set_error(err, MU_ERROR_DOMAIN, static_cast(code_),
+ g_set_error(err, error_quark(), static_cast(code_),
"%s", what_.c_str());
}
private:
+ static inline GQuark error_quark (void) {
+ static GQuark error_domain = 0;
+ if (G_UNLIKELY(error_domain == 0))
+ error_domain = g_quark_from_static_string("mu-error-quark");
+ return error_domain;
+ }
+
const Code code_;
std::string what_;
};
Bug#1033852: racket-mode: autopkgtest regression: Process *Racket REPL* connection broken by remote peer
Control: reopen -1 Control: found -1 racket-mode/20230425git0-1 > The release team has announced [1] that failing autopkgtest on amd64 and > arm64 are considered RC in testing. [Release Team member hat on] Because > we're currently in the hard freeze for bookworm, I have marked this bug > as bookworm-ignore. Targeted fixes are still welcome. I missed that the autopkgtests were still failing on arm64. Although the failing autopkgtest itself (I guess?) should prevent migration, let me try to correct the version tracking.
Bug#1039119: darktable: use packaged lua
roucaries bastien writes: > > Yes in your case i cheched by grepping thé build log. Lua ils compiléd what > why i set rc severity. I suspect that you saw a different package with Lua in the name, namely LuaAutoC. The embedding of that library is a bug, but I'm not sure there's any practical benefit to filing it since it is not packaged seperately in Debian, and darktable is afaik the only package using it. Personally there are higher priority issues with darktable, in particular the embedding of LibRaw (which is already tracked by it's own bug iirc).
Bug#1039119: darktable: use packaged lua
Bastien Roucariès writes: > Source: darktable > Version: Use packaged lua > Severity: serious > Justification: embded code copy > > Dear Maintainer, > > It appear that your package embded and compile lua > > Could you: > - use the packaged lua lib > - repack in order to avoid accidental reintroduction of compiling lua > > rouca Since upstream already checks for the system lua (unless that changed) repackaging seems unecessary. Do you have some evidence (build logs ?) that the build is not using the system lua? d
Bug#1033852: racket-mode: autopkgtest regression: Process *Racket REPL* connection broken by remote peer
Paul Gevers writes: > Source: racket-mode > Version: 20210916git0-2 > Severity: serious > Control: tags -1 bookworm-ignore > User: debian...@lists.debian.org > Usertags: regression This bug should be fixed in testing as soon as the just-uploaded 20230425git0-2 migrates to testing (a few days?). I'm not sure if that will beat the autoremoval, but perhaps this nudge to the bug will prevent some disruption for testing users.
Bug#1036359: crashes with (wrong-type-argument consp nil)
Antoine Beaupre writes: > Package: elpa-markdown-toc > Version: 0.1.5-2 > Severity: grave > > In Debian bookworm, markdown-toc is currently unusable. > > Given the following markdown buffer: > Hi Antoine; I agree that markdown file looks innocuous, but do you know if it is just this file or any markdown file? d
Bug#1035650: elpa-org version older than built-in Org in bookworm
Maxim Nikulin writes: > Package: elpa-org > Version: 9.5.2+dfsh-4 > Severity: serious > > Installing elpa-org package to current Debian testing (bookworm) results > in older Org version than Org shipped with Emacs. I consider it as a > really bad surprise for people who will upgrade from bullseye when > bookworm becomes stable. > Note that by filing this bug with severity serious, you are proposing to remove elpa-org from bullseye. This might be the right course of action, I'm not sure. I guess one downside is that people will just keep the old version of elpa-org when upgrading, but at least it will show up as an obsolete package in some package management interfaces. This bug is also duplicate of #1033400, but that bug (for now) has different severity.
Bug#1033655: elpa-flycheck: Emacs28 / flycheck is spawning wild running shellcheck processes eating up the system memory (oom-kill)
Control: tag -1 unreproducible Control: severity -1 important H.-Dirk Schmitt writes: > Package: elpa-flycheck > Version: 32~git.20200527.9c435db3-3 > Severity: grave > X-Debbugs-Cc: none, H.-Dirk Schmitt > > > The combination of Emacs28 + elpa-flycheck + shellcheck in *bookworm* > spawn never terminating shellcheck processes. These are eating up the > memory and trigger oom-kill. > > **This renders my system unstable.** It appears to be blocked minutes > till the oem-kill cleans up some memory. I can't duplicate this on a bookworm system. Does it happen for any shell script, or some particular ones? d
Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25
David Bremner writes: > Adrian Bunk writes: > >>> FTR, the dates when epl started to FTBFS in sid and bookworm are >>> a good match for when emacs 1:28.2+1-9 entered sid and bookworm: >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html >> >> Correct link: >> https://tests.reproducible-builds.org/debian/history/epl.html > > Some pretty weird behaviour here > > HOME=/n0nexistent emacs -batch -Q -l package \ > --eval "(add-to-list 'package-directory-list > \"/usr/share/emacs/site-lisp/elpa\")" \ > --eval "(add-to-list 'package-directory-list > \"/usr/share/emacs/site-lisp/elpa-src\")" \ > -f package-initialize -L . -L test --eval "(progn (setq > comp-enable-subr-trampolines nil) \ > (load-file \"test/test-helper.el\") (load-file \"test/epl-test.el\"))" \ > -l test/epl-test.el --eval \(ert-run-tests-batch-and-exit\) > > fails, but replacing /n0nexistent with /nonexistent passes. I hope this is > not a sign that someone has special cased /nonexistent, but I fear otherwise. This weird behaviour is a consequence of emacs' ill-advised special-casing of "HOME==/nonexistent" in startup.el (around line 550). if HOME==/nonexistent, then emacs tries to provide a temporary directory for native compilation output. Why this is needed is a different question.
Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25
Adrian Bunk writes: >> FTR, the dates when epl started to FTBFS in sid and bookworm are >> a good match for when emacs 1:28.2+1-9 entered sid and bookworm: >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html > > Correct link: > https://tests.reproducible-builds.org/debian/history/epl.html Some pretty weird behaviour here HOME=/n0nexistent emacs -batch -Q -l package \ --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" \ --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" \ -f package-initialize -L . -L test --eval "(progn (setq comp-enable-subr-trampolines nil) \ (load-file \"test/test-helper.el\") (load-file \"test/epl-test.el\"))" \ -l test/epl-test.el --eval \(ert-run-tests-batch-and-exit\) fails, but replacing /n0nexistent with /nonexistent passes. I hope this is not a sign that someone has special cased /nonexistent, but I fear otherwise.
Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25
Sergio Durigan Junior writes: > On Monday, February 27 2023, David Bremner wrote: > >> Sergio Durigan Junior writes: >>> >>> I was testing with an upstream build. For Debian's Emacs, we should >>> use: >>> >>> buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L . >>> >> >> Did you get that working with the upstream version currently in master >> or with a new upstream snapshot? I tried cherry picking 8379be91 but it >> seemed not to be enough (there was a bunch of conflicts, so maybe I >> missed something). > > I backported 8379be91, and it needed manual adjustments to apply > cleanly. After that, it was enough to solve the other two failures. > > Here's the full diff. If you're OK with it I can upload the package. > Go ahead. d
Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25
Sergio Durigan Junior writes: > > I was testing with an upstream build. For Debian's Emacs, we should > use: > > buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L . > Did you get that working with the upstream version currently in master or with a new upstream snapshot? I tried cherry picking 8379be91 but it seemed not to be enough (there was a bunch of conflicts, so maybe I missed something). d
Bug#1020192: Remove cycle-quotes from Debian? (was: Re: Bug#1020192: cycle-quotes: FTBFS: make: *** [debian/rules:4: build] Error 25)
Sergio Durigan Junior writes: > Agreed. I'm thinking about filing an RM bug against cycle-quotes; its > last release happened 4 years ago (although there are some non-useful > new commits on https://github.com/emacsmirror/cycle-quotes), it fails to > build with Emacs 28, has been blocked for 790 days, and doesn't have any > reverse-dependencies. > I would say that compared to some contexts, 4 years is not that long for an emacs package to be static. On the other hand, cycle-quotes is not in melpa, and it has pretty low popcon numbers, so it isn't hugely popular. I guess I would be inclined to just let it get removed semi-automatically when the release team notices it has been out of testing for a while.
Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25
David Bremner writes: > I don't think these are the same as previously encountered > native-compilation related failures. I get the same / similar failures > when running > > EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l > buttercup -f buttercup-run-discover > > as a non-root user with a defined home directory. Log is attached (there > is one more failure in the log, iiuc related to gpg missing in the > chroot). With the latest upstream master (32-182-g5561440) which contains the merge of PR 2002, this is down to 2 failures, both trampoline related.
Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25
I don't think these are the same as previously encountered native-compilation related failures. I get the same / similar failures when running EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l buttercup -f buttercup-run-discover as a non-root user with a defined home directory. Log is attached (there is one more failure in the log, iiuc related to gpg missing in the chroot). I tried with the upstream master branch, which contains an upstream change related to buttercup and emacs 28, and I still get the same 4 failures, including the two buffer-file-name related failures. buttercup.log Description: Binary data
Bug#1027542: epl: FTBFS: make: *** [debian/rules:6: build] Error 25
Lucas Nussbaum writes: > Source: epl > Version: 0.9-5 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230101 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > This seems tricky to duplicate - building on bare metal (sid/bookworm): works - building in sbuild chroot by running dpkg-buildpackage: works - building with sbuild: fails. As a wild guess I tried adding export EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t to debian/rules, but it did not help.
Bug#1020189: helpful-el: FTBFS: make: *** [debian/rules:4: binary] Error 25
Lucas Nussbaum writes: > Source: helpful-el > Version: 0.19-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. this seems unrelated to native compilation, probably needs an upstream fix for emacs 28
Bug#1020192: cycle-quotes: FTBFS: make: *** [debian/rules:4: build] Error 25
Lucas Nussbaum writes: > Source: cycle-quotes > Version: 0.1-4 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > this seems unrelated to native compilation. It probably needs an upstream fix for emacs 28. Unfortunately upstream seems dead / static.
Bug#1020143: yasnippet: FTBFS: make[1]: *** [debian/rules:7: override_dh_auto_build] Error 255
Lucas Nussbaum writes: > Source: yasnippet > Version: 0.14.0+git20200603.5cbdbf0d-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > This seems unrelated to native compilation. At a guess, it is because emacs now includes a new enough org-mode to trigger the previous bug that caused someone to add a Build-Conflicts with elpa-org.
Bug#1020193: pcre2el: FTBFS: make: *** [debian/rules:4: binary] Error 25
Lucas Nussbaum writes: > Source: pcre2el > Version: 1.8-4 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > This bug seems unrelated to native compilation, consider checking for an emacs 28 related fix upstream. d
Bug#1020195: elisp-bug-hunter: FTBFS: make: *** [debian/rules:4: binary] Error 25
Lucas Nussbaum writes: > Source: elisp-bug-hunter > Version: 1.3.1+repack-5 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This bug seems unrelated to native compilation, probably an API change in emacs28. Consider checking for an upstream fix... d
Bug#1020029: emacs-deferred: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Lucas Nussbaum writes: > Source: emacs-deferred > Version: 0.5.1-4 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > This bug seems unrelated to native compilation. Most likely some API change in emacs 28. Perhaps check for a fix upstream? d
Bug#1020189: still failing with dh-elpa 2.0.12
This looks like a real bug though, unrelated to native compilation
Searched 1/1 files
passed 19/87 helpful--display-implementations (0.122235 sec)
passed 20/87 helpful--docstring (0.44 sec)
Test helpful--docstring-advice backtrace:
signal(ert-test-failed (((should (equal (helpful--docstring #'test-f
ert-fail(((should (equal (helpful--docstring #'test-foo-advised t) "
(if (unwind-protect (setq value-47 (apply fn-45 args-46)) (setq form
(let (form-description-49) (if (unwind-protect (setq value-47 (apply
(let ((value-47 'ert-form-evaluation-aborted-48)) (let (form-descrip
(let* ((fn-45 #'equal) (args-46 (condition-case err (let ((signal-ho
(let ((lexical-binding t)) (let* ((fn-45 #'equal) (args-46 (conditio
(closure (t) nil (let ((lexical-binding t)) (let* ((fn-45 #'equal) (
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name helpful--docstring-advice :documentat
ert-run-or-rerun-test(#s(ert--stats :selector t :tests ... :test-map
ert-run-tests(t #f(compiled-function (event-type event-args) #
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
command-line-1(("-l" "package" "--eval" "(setq native-compile-target
command-line()
normal-top-level()
Test helpful--docstring-advice condition:
(ert-test-failed
((should
(equal
(helpful--docstring ... t)
"Docstring here too."))
:form
(equal "Docstring here too.\n\nThis function has :around advice:
`ad-Advice-test-foo-advised'." "Docstring here too.")
:value nil :explanation
(arrays-of-different-length 84 19 "Docstring here too.\n\nThis function
has :around advice: `ad-Advice-test-foo-advised'." "Docstring here too."
first-mismatch-at 19)))
FAILED 21/87 helpful--docstring-advice (0.000165 sec)
passed 22/87 helpful--docstring-keymap (0.000490 sec)
Bug#1020185: persists with dh-elpa 2.0.12
here's the failed build with dh-elpa 2.0.12
dh_elpa_test
emacs -batch -Q -l package --eval "(setq
native-compile-target-directory \"/tmp/NpGLjk7chP\")" --eval "(add-to-list
'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval
"(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")"
-f package-initialize -L . -l simple-httpd-test.el --eval
\(ert-run-tests-batch-and-exit\)
Running 10 tests (2022-09-26 10:33:27+, selector ‘t’)
passed 1/10 httpd-clean-path-test (0.000103 sec)
passed 2/10 httpd-get-servlet-test (0.80 sec)
passed 3/10 httpd-mime-test (0.62 sec)
passed 4/10 httpd-parse-args-test (0.60 sec)
passed 5/10 httpd-parse-endpoint (0.57 sec)
passed 6/10 httpd-parse-test (0.001130 sec)
passed 7/10 httpd-parse-uri-test (0.63 sec)
passed 8/10 httpd-send-header-test (0.213662 sec)
Test httpd-status-test backtrace:
native-elisp-load("/sbuild-nonexistent/.emacs.d/eln-cache/28.1-73153
comp-trampoline-search(file-readable-p)
comp-subr-trampoline-install(file-readable-p)
fset(file-readable-p (lambda (file) nil))
(progn (fset 'file-exists-p #'(lambda (file) t)) (fset 'file-readabl
(unwind-protect (progn (fset 'file-exists-p #'(lambda (file) t)) (fs
(let ((file-exists-p (symbol-function 'file-exists-p)) (file-readabl
(let ((lexical-binding nil)) (let ((file-exists-p (symbol-function '
(lambda nil (let ((lexical-binding nil)) (let ((file-exists-p (symbo
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name httpd-status-test :documentation "Tes
ert-run-or-rerun-test(#s(ert--stats :selector t :tests [... ... ...
ert-run-tests(t #f(compiled-function (event-type event-args) #
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
command-line-1(("-l" "package" "--eval" "(setq native-compile-target
command-line()
normal-top-level()
Test httpd-status-test condition:
(native-lisp-load-failed "file does not exists"
"/sbuild-nonexistent/.emacs.d/eln-cache/28.1-73153f3e/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
FAILED 9/10 httpd-status-test (0.364922 sec)
passed 10/10 httpd-unhex-test (0.000129 sec)
Bug#1017818: elpa-jabber: Fails to compile with Emacs 28: Error: Wrong number of arguments: make-obsolete, 2
Yavor Doganov writes: > Package: elpa-jabber > Version: 0.8.92+git98dc8e-7 > Severity: serious > > The upgrade from Emacs 27 to 28 aborts because byte-compilation of > elpa-jabber fails with the following error(s): > > | In toplevel form: > | jabber-vcard.el:67:1: Error: Wrong number of arguments: make-obsolete, 2 > I've pushed a version that fixes this to https://salsa.debian.org/emacsen-team/emacs-jabber It depends on elpa-srv, which is currently NEW, but can also be downloaded from salsa. d
Bug#1017853: emacs-nox: byte compiling debian-startup.el fails if emacs-el is not installed
David Bremner writes: > Package: emacs-nox > Version: 1:28.1+1-2 > Severity: serious > Justification: does not install > X-Debbugs-Cc: debian-emac...@lists.debian.org Here is the output of strace in case it is useful. It uncompresses to 16M, just FYI. strace.log.xz Description: application/xz
Bug#1017853: emacs-nox: byte compiling debian-startup.el fails if emacs-el is not installed
Package: emacs-nox Version: 1:28.1+1-2 Severity: serious Justification: does not install X-Debbugs-Cc: debian-emac...@lists.debian.org Recipe to duplicate === (assuming schroot is set up in a more or less standard way with a chroot called sid, and session support). % schroot -c sid -n test -b # the following fails with crash [1]. % sudo schroot -c test -r -- apt install --no-install-recommends emacs-nox # the following succeeds: sudo schroot -c test -r -- apt install --no-install-recommends emacs-nox emacs-el Discussion == This is most likely the same bug as #1017798 and #1017779 (and probably others). I don't think it depends on the flavour of emacs (I tested also emacs-gtk, same results). [1]: crash log: Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs corrupted size vs. prev_size Fatal error 6: Aborted Backtrace: emacs(+0xe9d13)[0x55ec81734d13] emacs(+0x30fed)[0x55ec8167bfed] emacs(+0x314b7)[0x55ec8167c4b7] emacs(+0xe8058)[0x55ec81733058] emacs(+0xe8149)[0x55ec81733149] /lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f9f70c64af0] /lib/x86_64-linux-gnu/libc.so.6(+0x8983c)[0x7f9f70cb083c] /lib/x86_64-linux-gnu/libc.so.6(raise+0x12)[0x7f9f70c64a52] /lib/x86_64-linux-gnu/libc.so.6(abort+0xcf)[0x7f9f70c4f469] /lib/x86_64-linux-gnu/libc.so.6(+0x7dc18)[0x7f9f70ca4c18] /lib/x86_64-linux-gnu/libc.so.6(+0x9355a)[0x7f9f70cba55a] /lib/x86_64-linux-gnu/libc.so.6(+0x93eb6)[0x7f9f70cbaeb6] /lib/x86_64-linux-gnu/libc.so.6(+0x967a1)[0x7f9f70cbd7a1] /lib/x86_64-linux-gnu/libc.so.6(malloc+0x1a2)[0x7f9f70cbe382] emacs(+0x12ba45)[0x55ec81776a45] emacs(+0x12bbb6)[0x55ec81776bb6] emacs(+0x12bdf2)[0x55ec81776df2] emacs(+0x12bf21)[0x55ec81776f21] emacs(+0x102c38)[0x55ec8174dc38] emacs(+0x173a36)[0x55ec817bea36] emacs(+0x17790b)[0x55ec817c290b] emacs(+0x17850a)[0x55ec817c350a] emacs(+0x14df36)[0x55ec81798f36] emacs(+0x14e165)[0x55ec81799165] emacs(+0x14e3af)[0x55ec817993af] emacs(+0x1737a8)[0x55ec817be7a8] emacs(+0x174170)[0x55ec817bf170] emacs(+0x17790b)[0x55ec817c290b] emacs(+0x17850a)[0x55ec817c350a] emacs(+0x14df36)[0x55ec81798f36] emacs(+0x14e165)[0x55ec81799165] emacs(+0x14e3af)[0x55ec817993af] emacs(+0x1737a8)[0x55ec817be7a8] emacs(+0x174170)[0x55ec817bf170] emacs(+0x17790b)[0x55ec817c290b] emacs(+0x17850a)[0x55ec817c350a] emacs(+0x14df36)[0x55ec81798f36] emacs(+0x14e165)[0x55ec81799165] emacs(+0x14e3af)[0x55ec817993af] emacs(+0x1737a8)[0x55ec817be7a8] emacs(+0x174170)[0x55ec817bf170] ... Aborted -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-nox depends on: ii emacs-bin-common 1:27.1+1-3.1+b1 ii emacs-common 1:27.1+1-3.1 ii libacl1 2.3.1-1 ii libasound21.2.7.2-1 ii libc6 2.34-3 ii libdbus-1-3 1.14.0-2 pn libgccjit0 ii libgmp10 2:6.2.1+dfsg1-1 ii libgnutls30 3.7.7-2 ii libgpm2 1.20.7-10 ii libjansson4 2.14-2 ii liblcms2-22.13.1-1 ii libselinux1 3.4-1+b1 ii libsystemd0 251.3-1 ii libtinfo6 6.3+20220423-2 ii libxml2 2.9.14+dfsg-1+b1 ii zlib1g1:1.2.11.dfsg-4 emacs-nox recommends no packages. Versions of packages emacs-nox suggests: pn emacs-common-non-dfsg
Bug#1017798: please test
Can you test if having emacs-el installed (e.g. via recommends) allows the installation / postinst to complete? That will help narrow down what the bug is. d
Bug#1012407: libsingular4m2n1: changes SONAME without changing package name
Package: libsingular4m2n1 Version: 1:4.3.0-p1+ds-2 Severity: serious Justification: violates policy MUST: section 8.1, first paragraph -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Version 4.3.0 of libsingular4m2n1 has an SONAME of libsingular-Singular-4.3.0.so Version 4.2.1 has SONAME libsingular-Singular-4.2.1.so This means the package name has to change, otherwise packages built against 4.2.1 will break on systems with 4.3.0 installed. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsingular4m2n1 depends on: ii libc6 2.33-7 ii libflint-2.8.5 2.8.5-2 ii libgmp102:6.2.1+dfsg-3 ii libmpfr64.1.0-3 ii libntl4411.5.1-1+b1 ii libreadline88.1.2-1.2 ii libstdc++6 12.1.0-2 libsingular4m2n1 recommends no packages. libsingular4m2n1 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmKeDmMACgkQA0U5G1Wq FSGHzw//UV7FGyvisGdYJaHpl+OVZyvQ/lPrWZyelFM2U94o8hB+E4Mi6ZKvxX7/ jJ1G7U8yR5GSgkAmzNwrUTL2rO+F0db/qnQV7i5IgTOmtCOrSoDUKvf08daTTUMl 5/Fe1y7VrESL6aFljigYLf2HuO+uoXqQRmIP8hmr7Io4N4s01ipBojrQ1Kuj10PP VaRi3hPX/FzkVk6exA6W8sVxh36mMu1S6tAy9kWjpF3asnmy7dks/byjBwei88rL RKHVle59pjGghY3LscEesgHV05EiH1AFsc7h5XWpxKqaNpUtgunz0KSEsX3iAVqK jg76WErZAgzmclXsGPqgtdtxUYs7qa28Yf51X2PUhsYNpcXhr7lsOn+VT0GxXIEm Hp3T9QzNwXl51hXqy11ajPn2uZENUXF66UxAuxbTqbmuyxg8uCPg6s4i1UeLcYUI HDT38SVBj44dHdO8DrzrLTuCxxHx0cUKqX7Jq/Ie/1++JRkEUFyVr6Ls60szhKKs XPYLeRAZMtxk9Rg1Vbbsqnn7GAiq8C9OeiCgpBFGbXo9m2gMZkjrHOQjexT12vVw 5/my1wm3jpx8eGoJ+Trkz61aFqU0ohG+PWH0lwGnrkBahogdFMWkL6SKfS5r1bfO c7mJ7FIjO0Sxtu/HQ3KUaOhLv0jxw1bENV3gfPFyid37Xo1eetg= =IVAe -END PGP SIGNATURE-
Bug#999303: pfqueue: diff for NMU version 0.5.6-9.1
Control: tags 999303 + patch Control: tags 999303 + pending Dear maintainer, I've prepared an NMU for pfqueue (versioned as 0.5.6-9.1) and uploaded it to DELAYED/5-day. Please feel free to tell me if I should delay it longer. Regards. David PS the upload was done with dgit, if you prefer to retrieve the changes that way diff -u pfqueue-0.5.6/debian/changelog pfqueue-0.5.6/debian/changelog --- pfqueue-0.5.6/debian/changelog +++ pfqueue-0.5.6/debian/changelog @@ -1,3 +1,11 @@ +pfqueue (0.5.6-9.1) unstable; urgency=medium + + * Non-maintainer upload + * Bug fix: "missing required debian/rules targets build-arch and/or +build-indep", thanks to Lucas Nussbaum (Closes: #999303). + + -- David Bremner Tue, 04 Jan 2022 08:00:22 -0400 + pfqueue (0.5.6-9) unstable; urgency=medium * use dh-autoreconf to fix ppc64el FTBFS (Closes: #732831). diff -u pfqueue-0.5.6/debian/rules pfqueue-0.5.6/debian/rules --- pfqueue-0.5.6/debian/rules +++ pfqueue-0.5.6/debian/rules @@ -31,7 +31,12 @@ dh_autoreconf ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs" -build: build-stamp +build: build-indep build-arch + +build-indep: + @echo dummy target, nothing built + +build-arch: build-stamp build-stamp: config.status dh_testdir
Bug#1002900: darktable: FTBFS on arm64
Package: darktable Version: 3.8.0-1 Severity: serious Tags: fixed-upstream Justification: FTBFS, previously did on this architecture -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 See [1] for the full log. __DT_CLONE_TARGETS__ is undefined on aarch64. Fixed upstream in the darktable-3.8.x branch. There are quite a few fixes in that branch, so it may be worth waiting for a point release (or packaging a snapshot) rather than cherry-picking a fix for this bug. [1]: https://buildd.debian.org/status/fetch.php?pkg=darktable=arm64=3.8.0-1=1640868741=0 - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages darktable depends on: ii libc62.33-1 ii libcairo21.16.0-5 ii libcolord-gtk1 0.1.26-2+b1 ii libcolord2 1.4.5-3 ii libcups2 2.3.3op2-7 ii libcurl3-gnutls 7.79.1-2 ii libexiv2-27 0.27.3-3.1 ii libgcc-s111.2.0-13 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.70.2-1 ii libgomp1 11.2.0-13 ii libgphoto2-6 2.5.27-1 ii libgphoto2-port122.5.27-1 ii libgraphicsmagick-q16-3 1.4+really1.3.37-1 ii libgtk-3-0 3.24.31-1 ii libicu67 67.1-7 ii libilmbase25 2.5.7-2 ii libjpeg62-turbo 1:2.1.2-1 ii libjson-glib-1.0-0 1.6.6-1 ii liblcms2-2 2.12~rc1-2 ii liblensfun1 0.3.2-6 ii libopenexr25 2.5.7-1 ii libopenjp2-7 2.4.0-3 ii libosmgpsmap-1.0-1 1.2.0-1 ii libpango-1.0-0 1.48.10+ds1-1 ii libpangocairo-1.0-0 1.48.10+ds1-1 ii libpng16-16 1.6.37-3 ii libpugixml1v51.11.4-1 ii librsvg2-2 2.50.7+dfsg-2 ii libsecret-1-00.20.4-2 ii libsoup2.4-1 2.74.2-3 ii libsqlite3-0 3.36.0-2 ii libstdc++6 11.2.0-13 ii libtiff5 4.3.0-2 ii libwebp6 0.6.1-2.1 ii libx11-6 2:1.7.2-2+b1 ii libxml2 2.9.12+dfsg-5+b1 ii libxrandr2 2:1.5.2-1 ii zlib1g 1:1.2.11.dfsg-2 darktable recommends no packages. darktable suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmHO7G8ACgkQA0U5G1Wq FSHz1g/+Ov/i1IEujrRSFfdblQ676PJEOaonHAkxOAV0Z4lMAYZXf01c8c0AkSC+ GxDagr0hcDfqEZaxavmaps+D30MUwptBAf/7/Cfj13AFNOZ13Xls2q9jpZfkjYRp WnIBL9Rapyws6BtphU8LGTNkioVGrMYEMOwYCpLao1uWs4TbHJzhyxZnbxFpHJc4 BTLfXf/ZNZVRX5zTuR37f3qFXO10JjapzMt/Po8gIbRH3bnmsz+JppbJtlzj1a/W keTibD5cxjllpynUhj8Rz5XDTl3a6GlJeOuhOpMm1pLmk+I4GfWueXrbf5loLj5q gmvz0RgvjnBZpzx5plR+NPnhL4ryhY8g613feU1MeJlMZmVZSRbFVhDmzCTuFiuo ZvCHZeMV9u3c6xLR9pKG/t02/MvfEF0LuE8RnD0+fbFm4+jAHwvxVvQLZPVkVL5X H8Z06GzBC3ehRqxZCAyu2alTX8mqHN3qeHaJ9nfa9M6QToeTXJhroGtVUd94PSxe kcCFMVUqkP4QRtcVX0w3968YW2GMqaGBAstrg95qSymdzJoatGzSqTo25/rq5fYC NFJBuJYC/LWCKcT+GY2d8+SN6708aKblC15v1MCRW6ZxjOdTC66rV/1ivaQ2Qbuk urGmmEJOlVVluAFvH3A+ct3LEkDcDzDCaCe6I6RD+UewW58SLMg= =W6FW -END PGP SIGNATURE-
Bug#988583: elpa-debian-el: Cannot report any bugs at all. It is broken.
Control: tag -1 unreproducible Control: severity -1 normal Salman Mohammadi writes: > Package: elpa-debian-el > Version: 37.10 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: sal...@smoha.org > > Dear Maintainer, > > I cannot report any bugs using M-x debian-bug at all. After entering the bug > summary, I get the following error message, and cannot correctly reach the > page > where I should write the actual bug report. > > Getting package information from reportbug... > debian-bug-prefill-report: Reportbug did not produce expected output! > Bailing out. > Reportbug may have sent an empty report! I can't reproduce this behaviour. I guess it might be related to something in your reportbug configuration. Can you share your .reportbugrc? By the way, this bug by itself does not "render package unusable", since the package provides other functionality.
Bug#975227: syncmaildir: diff for NMU version 1.3.0-1.1
Control: tags 975227 + patch Control: tags 975227 + pending Dear maintainer, I've prepared an NMU for syncmaildir (versioned as 1.3.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. David diff -Nru syncmaildir-1.3.0/debian/changelog syncmaildir-1.3.0/debian/changelog --- syncmaildir-1.3.0/debian/changelog 2018-03-17 13:13:46.0 -0300 +++ syncmaildir-1.3.0/debian/changelog 2021-04-21 11:05:47.0 -0300 @@ -1,3 +1,13 @@ +syncmaildir (1.3.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Convert some 'grep foo bar | wc -l' to 'grep -c foo bar' in test +suite. Bug fix: "FTBFS: running client-server/02-move-mail: .grep: +log.s2c: binary file matches", thanks to Lucas Nussbaum (Closes: +#975227). + + -- David Bremner Wed, 21 Apr 2021 11:05:47 -0300 + syncmaildir (1.3.0-1) unstable; urgency=medium * New upstream release diff -Nru syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch --- syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch 1969-12-31 20:00:00.0 -0400 +++ syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch 2021-04-21 11:05:47.0 -0300 @@ -0,0 +1,186 @@ +From: David Bremner +Date: Wed, 21 Apr 2021 08:16:11 -0300 +X-Dgit-Generated: 1.3.0-1.1 6d7213c4f0646e9a896aa3acc16c886914bdd01d +Subject: Replace use of "grep | wc" with grep -c for binary files. + +The latter actually reports a number of matches on stdout, making the +tests pass. + +--- + +--- syncmaildir-1.3.0.orig/tests.d/client-server/02-move-mail syncmaildir-1.3.0/tests.d/client-server/02-move-mail +@@ -9,7 +9,7 @@ msync 2 + + test_eq Mail target/Mail + +-X=`grep '^MOVE ' log.s2c | wc -l` ++X=`grep -c '^MOVE ' log.s2c` + assert $X 1 "missing MOVE in s2c" + + X=`grep '^COMMIT$' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/03-copy-mail syncmaildir-1.3.0/tests.d/client-server/03-copy-mail +@@ -9,7 +9,7 @@ msync 2 + + test_eq Mail target/Mail + +-X=`grep '^COPY ' log.s2c | wc -l` ++X=`grep -c '^COPY ' log.s2c` + assert $X 1 "missing COPY in s2c" + + X=`grep '^GET ' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/04-replace-header syncmaildir-1.3.0/tests.d/client-server/04-replace-header +@@ -9,7 +9,7 @@ msync 2 + + test_eq Mail target/Mail + +-X=`grep '^REPLACEHEADER ' log.s2c | wc -l` ++X=`grep -c '^REPLACEHEADER ' log.s2c` + assert $X 1 "missing REPLACEHEADER in s2c" + + X=`grep '^GETHEADER ' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/05-replace-header-fail syncmaildir-1.3.0/tests.d/client-server/05-replace-header-fail +@@ -11,7 +11,7 @@ msync 2 + + test_eq target/Mail.old target/Mail + +-X=`grep '^REPLACEHEADER ' log.s2c | wc -l` ++X=`grep -c '^REPLACEHEADER ' log.s2c` + assert $X 1 "missing REPLACEHEADER in s2c" + + X=`grep '^GETHEADER ' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/06-replace-header-already-ok syncmaildir-1.3.0/tests.d/client-server/06-replace-header-already-ok +@@ -10,7 +10,7 @@ test_eq Mail target/Mail + msync 2 + + test_eq Mail target/Mail +-X=`grep '^REPLACEHEADER ' log.s2c | wc -l` ++X=`grep -c '^REPLACEHEADER ' log.s2c` + assert $X 1 "missing REPLACEHEADER in s2c" + + X=`grep '^GETHEADER ' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/08-copy-mail-already-ok syncmaildir-1.3.0/tests.d/client-server/08-copy-mail-already-ok +@@ -10,7 +10,7 @@ msync 2 + + test_eq Mail target/Mail + +-X=`grep '^COPY ' log.s2c | wc -l` ++X=`grep -c '^COPY ' log.s2c` + assert $X 1 "missing COPY in s2c" + + X=`grep '^GET ' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/10-delete-already-done syncmaildir-1.3.0/tests.d/client-server/10-delete-already-done +@@ -10,7 +10,7 @@ msync 2 + + test_eq Mail target/Mail + +-X=`grep '^DELETE ' log.s2c | wc -l` ++X=`grep -c '^DELETE ' log.s2c` + assert $X 1 "missing DELETE in s2c" + + X=`grep '^COMMIT$' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/12-skip-add-already-there syncmaildir-1.3.0/tests.d/client-server/12-skip-add-already-there +@@ -10,7 +10,7 @@ msync 2 + + test_eq Mail target/Mail + +-X=`grep '^ADD ' log.s2c | wc -l` ++X=`grep -c '^ADD ' log.s2c` + assert $X 1 "missing ADD in s2c" + + X=`grep '^GET ' log.c2s | wc -l` +--- syncmaildir-1.3.0.orig/tests.d/client-server/14-skip-copy-already-there-copy-only syncmaildir-1.3.0/tests.d/client-server/14-skip-copy-already-there-copy-only +@@ -14,7 +14,7 @@ rm Mail/cur/$C + + test_eq Mail target/Mail + +-X=`grep '^COPY ' log.s2c | wc -l` ++X=`grep -c '^COPY ' log.s2c` + assert $X 1 "missing COPY in s2c" + + X=`grep '^GET ' log.c2s | wc -l`
Bug#975227: [PATCH] Replace use of "grep | wc" with grep -c for binary files.
The latter actually reports a number of matches on stdout, making the tests pass. --- tests.d/client-server/02-move-mail | 2 +- tests.d/client-server/03-copy-mail | 2 +- tests.d/client-server/04-replace-header| 2 +- tests.d/client-server/05-replace-header-fail | 2 +- tests.d/client-server/06-replace-header-already-ok | 2 +- tests.d/client-server/08-copy-mail-already-ok | 2 +- tests.d/client-server/10-delete-already-done | 2 +- tests.d/client-server/12-skip-add-already-there| 2 +- tests.d/client-server/14-skip-copy-already-there-copy-only | 2 +- tests.d/client-server/18-copybody | 2 +- tests.d/client-server/19-copybody-already-ok | 2 +- tests.d/client-server/22-replace | 2 +- tests.d/client-server/23-replace-aready-ok | 2 +- tests.d/client-server/34-move-fail2| 2 +- tests.d/client-server/35-delete| 2 +- tests.d/client-server/36-move-fail3| 2 +- 16 files changed, 16 insertions(+), 16 deletions(-) diff --git a/tests.d/client-server/02-move-mail b/tests.d/client-server/02-move-mail index e3dbd90..7828b69 100644 --- a/tests.d/client-server/02-move-mail +++ b/tests.d/client-server/02-move-mail @@ -9,7 +9,7 @@ msync 2 test_eq Mail target/Mail -X=`grep '^MOVE ' log.s2c | wc -l` +X=`grep -c '^MOVE ' log.s2c` assert $X 1 "missing MOVE in s2c" X=`grep '^COMMIT$' log.c2s | wc -l` diff --git a/tests.d/client-server/03-copy-mail b/tests.d/client-server/03-copy-mail index 0037531..ec185a2 100644 --- a/tests.d/client-server/03-copy-mail +++ b/tests.d/client-server/03-copy-mail @@ -9,7 +9,7 @@ msync 2 test_eq Mail target/Mail -X=`grep '^COPY ' log.s2c | wc -l` +X=`grep -c '^COPY ' log.s2c` assert $X 1 "missing COPY in s2c" X=`grep '^GET ' log.c2s | wc -l` diff --git a/tests.d/client-server/04-replace-header b/tests.d/client-server/04-replace-header index 8af6cbb..1ffcaf1 100644 --- a/tests.d/client-server/04-replace-header +++ b/tests.d/client-server/04-replace-header @@ -9,7 +9,7 @@ msync 2 test_eq Mail target/Mail -X=`grep '^REPLACEHEADER ' log.s2c | wc -l` +X=`grep -c '^REPLACEHEADER ' log.s2c` assert $X 1 "missing REPLACEHEADER in s2c" X=`grep '^GETHEADER ' log.c2s | wc -l` diff --git a/tests.d/client-server/05-replace-header-fail b/tests.d/client-server/05-replace-header-fail index 8743c24..9599251 100644 --- a/tests.d/client-server/05-replace-header-fail +++ b/tests.d/client-server/05-replace-header-fail @@ -11,7 +11,7 @@ msync 2 test_eq target/Mail.old target/Mail -X=`grep '^REPLACEHEADER ' log.s2c | wc -l` +X=`grep -c '^REPLACEHEADER ' log.s2c` assert $X 1 "missing REPLACEHEADER in s2c" X=`grep '^GETHEADER ' log.c2s | wc -l` diff --git a/tests.d/client-server/06-replace-header-already-ok b/tests.d/client-server/06-replace-header-already-ok index 1d29c14..c2c0b2f 100644 --- a/tests.d/client-server/06-replace-header-already-ok +++ b/tests.d/client-server/06-replace-header-already-ok @@ -10,7 +10,7 @@ test_eq Mail target/Mail msync 2 test_eq Mail target/Mail -X=`grep '^REPLACEHEADER ' log.s2c | wc -l` +X=`grep -c '^REPLACEHEADER ' log.s2c` assert $X 1 "missing REPLACEHEADER in s2c" X=`grep '^GETHEADER ' log.c2s | wc -l` diff --git a/tests.d/client-server/08-copy-mail-already-ok b/tests.d/client-server/08-copy-mail-already-ok index 781a109..0e481e5 100644 --- a/tests.d/client-server/08-copy-mail-already-ok +++ b/tests.d/client-server/08-copy-mail-already-ok @@ -10,7 +10,7 @@ msync 2 test_eq Mail target/Mail -X=`grep '^COPY ' log.s2c | wc -l` +X=`grep -c '^COPY ' log.s2c` assert $X 1 "missing COPY in s2c" X=`grep '^GET ' log.c2s | wc -l` diff --git a/tests.d/client-server/10-delete-already-done b/tests.d/client-server/10-delete-already-done index 926394d..c15603b 100644 --- a/tests.d/client-server/10-delete-already-done +++ b/tests.d/client-server/10-delete-already-done @@ -10,7 +10,7 @@ msync 2 test_eq Mail target/Mail -X=`grep '^DELETE ' log.s2c | wc -l` +X=`grep -c '^DELETE ' log.s2c` assert $X 1 "missing DELETE in s2c" X=`grep '^COMMIT$' log.c2s | wc -l` diff --git a/tests.d/client-server/12-skip-add-already-there b/tests.d/client-server/12-skip-add-already-there index 0a53a80..38ed3ff 100644 --- a/tests.d/client-server/12-skip-add-already-there +++ b/tests.d/client-server/12-skip-add-already-there @@ -10,7 +10,7 @@ msync 2 test_eq Mail target/Mail -X=`grep '^ADD ' log.s2c | wc -l` +X=`grep -c '^ADD ' log.s2c` assert $X 1 "missing ADD in s2c" X=`grep '^GET ' log.c2s | wc -l` diff --git a/tests.d/client-server/14-skip-copy-already-there-copy-only b/tests.d/client-server/14-skip-copy-already-there-copy-only index b5da177..08734a8 100644 --- a/tests.d/client-server/14-skip-copy-already-there-copy-only +++
Bug#984931: marking as a bug in git-el
Control: reassign -1 git-el I'm reassigning this bug to (only) git-el since it hasn't been confirmed that there is actually a problem with elpa-magit. IMHO it doesn't benefit anyone to drop elpa-magit (and it's rdeps) from bullseye because of a problem with a transitional package. signature.asc Description: PGP signature
Bug#984931: [PATCH] git-el: disable byte-compilation
Since there is no provided user functionality, there is no point in making things more complicated. --- debian/changelog | 6 ++ debian/git-el.emacsen-install | 6 +++--- 2 files changed, 9 insertions(+), 3 deletions(-) I confirmed that this fixes the installation problem, and that it still prints the same messages as before. There's really no benefit to byte compiling such simple elisp, especially since most users will probably only run it once. I'd rather not NMU git during the freeze; would you mind applying this (or something similar)? diff --git a/debian/changelog b/debian/changelog index c458ad8f05..a67c56e62c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +git (1:2.31.0-2) unstable; urgency=medium + + * git-el: Disable byte compilation (Closes: #984931). + + -- David Bremner Sat, 20 Mar 2021 20:20:04 -0300 + git (1:2.31.0-1) unstable; urgency=low * new upstream release (see RelNotes/2.31.0.txt). diff --git a/debian/git-el.emacsen-install b/debian/git-el.emacsen-install index 4b02513a5a..70809aa606 100755 --- a/debian/git-el.emacsen-install +++ b/debian/git-el.emacsen-install @@ -21,7 +21,7 @@ printf 'install/git: Handling install of emacsen flavor %s\n' "$FLAVOR" ln -sf $el_dir/$i $i done - printf 'install/git: Byte-compiling for %s\n' "$FLAVOR" - set -x - $FLAVOR -batch -q -no-site-file -f batch-byte-compile $el_files + printf 'install/git: Not byte-compiling for %s\n' "$FLAVOR" +# set -x +# $FLAVOR -batch -q -no-site-file -f batch-byte-compile $el_files ) -- 2.30.2
Bug#984931: git-el,elpa-magit: fails to install: /usr/lib/emacsen-common/packages/install/git emacs failed at /usr/lib/emacsen-common/lib.pl line 19, line 7.
David Bremner writes: > > As far as I can see, the problem is that the setup for elpa-magit and > git-el both call "emacs", but that does not exist until the > update-alternatives is called. So there seems to be a race condition > here where emacs-gtk (or whatever is providing /usr/bin/emacs) needs to > run its postinst before any add-on package wanting to do byte > compilation. > > Somewhat to my surprise I could duplicate this failure with > > $ sudo schroot -r -c test apt install git-el elpa-magit > > where test is an up to date sid chroot. Another thing I noticed is that git-el does not depend on emacsen-common per [1] (5), I think it should. I don't know if this has any practical impact. d
Bug#984931: git-el,elpa-magit: fails to install: /usr/lib/emacsen-common/packages/install/git emacs failed at /usr/lib/emacsen-common/lib.pl line 19, line 7.
Andreas Beckmann writes: > Install git for emacs > install/git: Handling install of emacsen flavor emacs > install/git: Byte-compiling for emacs > + emacs -batch -q -no-site-file -f batch-byte-compile git.el git-blame.el > /usr/lib/emacsen-common/packages/install/git: 26: emacs: not found > /usr/lib/emacsen-common/packages/install/git emacs failed at > /usr/lib/emacsen-common/lib.pl line 19, line 7. > dpkg: error processing package elpa-magit (--configure): >installed elpa-magit package post-installation script subprocess returned > error exit status 2 > Setting up libm17n-0:i386 (1.8.0-2) ... > Setting up librsvg2-2:i386 (2.50.3+dfsg-1) ... > Setting up librsvg2-common:i386 (2.50.3+dfsg-1) ... > Setting up glib-networking:i386 (2.66.0-2) ... > Setting up libsoup2.4-1:i386 (2.72.0-2) ... > Setting up libsoup-gnome2.4-1:i386 (2.72.0-2) ... > Setting up librest-0.7-0:i386 (0.8.1-1.1) ... > Setting up libgtk-3-0:i386 (3.24.24-3) ... > Setting up libgtk-3-bin (3.24.24-3) ... > Setting up emacs-gtk (1:27.1+1-3) ... > update-alternatives: using /usr/bin/emacs-gtk to provide /usr/bin/emacs > (emacs) in auto mode > update-alternatives: using /usr/bin/emacs to provide /usr/bin/editor > (editor) in auto mode As far as I can see, the problem is that the setup for elpa-magit and git-el both call "emacs", but that does not exist until the update-alternatives is called. So there seems to be a race condition here where emacs-gtk (or whatever is providing /usr/bin/emacs) needs to run its postinst before any add-on package wanting to do byte compilation. Somewhat to my surprise I could duplicate this failure with $ sudo schroot -r -c test apt install git-el elpa-magit where test is an up to date sid chroot.
Bug#981252: polymake: tests fail on mips{64,}el
Benjamin Lorenz writes: > Hello David, > > On 28/01/2021 12.59, David Bremner wrote: > > please try the attached patch, the issue is that this testcase should > not be run when flint is disabled. > > I will do some tests with the new flint 2.7 soon to check whether the > mips(64) situation has improved. Hi Benjamin; The patch worked, thanks very much. I guess I'll upload the patched version, unless you are planning a point release in the next few days. David
Bug#981252: polymake: tests fail on mips{64,}el
Source: polymake Version: 4.3-2 Severity: serious Justification: FTBFS X-Debbugs-Cc: Benjamin Lorenz -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The full log for mips64el is at https://buildd.debian.org/status/fetch.php?pkg=polymake=mips64el=4.3-2=1611277005=0 The relevant output from the tests seems to be [ /polytope/objects/Polytope/properties/Triangulation and volume/RELATIVE_VOLUME ] 1polymake: WARNING: rule RELATIVE_VOLUME : SQUARED_RELATIVE_VOLUMES failed: Undefined subroutine ::polytope::Polytope__Rational::_Full_Spez::sum_of_square_roots_naive called at /<>/apps/polytope/rules/rational.rules line 73. /<>/apps/polytope/rules/rational.rules:65: testcase 1 expected: regular return got: EXCEPTION: no more rules available to compute 'RELATIVE_VOLUME' At a guess I'd imagine an architecture dependent bug in one of the dependencies. But that's purely a guess. - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmASpwkACgkQA0U5G1Wq FSExZg/+M1Jnk7AEmuP4LH9VstNLkapOuqAcBsjm+FXBaPPYqZDbWFS/XhrrvcRX DeTpTciZRG+4dmOYkkN+iBTGEqHCKRxQ4Gfb1nhPN3zgLVLdsubbkFB9+bOgZK1r F6bu6Ry0nz/pCSi1d8LXZeJMXtctlTHHcb5JeJcpNevi+s8GdZ00jMdsghCLIsbz oYs3eVW534JAiSrPv3xBP8dlMOwSp9N1tvFqqy47vNvZkJW0IBq3u23dxdvMDVWZ rOnsSZynE8idI6uCySkeDjjs5g4sUjsE1p+BT9e+BGXuIoDPY2MswcaMyZIIMmvf MCPiZP1rb857B6+Z45phkac7JK9ZrEaOlwaQ94CyAH5CNyU1o+CIaX9QQg1nLZP5 aXJ+BE+sjbcs2SA7+ZKr1lfNVdhwTmZQ2fzmS2EOJm0RXSjOIwGHSYUqoBX2dJ6c toSKobwNDKd7EdXY4Yrz2HLJvGgpks1s6AR40CfkyycMSC0aE4ELLvQ5BAhp/u4O TK0tc+Sr81BLrQaGAfzUS1Zts57wrfHGaxH4zkit+TZvtm3oHHHNx4aa3nR4PSOQ 9sFNgiQ/S9tKt95FzYmJYD2jyZ1SKVo8waebzNlFEvYQrOMhBBLjKt8JU4bWwGLV EVdj9cVsNpDgxzjFKc6Swlx9eKw9GHV8jwtw1ucQ6PbbcQtv8+A= =F26M -END PGP SIGNATURE-
Bug#981227: python3-cpuset: missing dependency on python3-future
Package: python3-cpuset Version: 1.6-4 Severity: serious Justification: crashes on every invocation -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 If python3-future is not installed, then cset crashes on startup at "from future import standard_library" with "ModuleNotFoundError: No module named 'future'". - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-cpuset depends on: ii python3 3.9.1-1 python3-cpuset recommends no packages. python3-cpuset suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmAR9DIACgkQA0U5G1Wq FSFIDhAAl8PgOMVDo0+i1/hBLALM2VPULRpwvXXekR33cy9Lz9x13Bc7aGQl+YHp t1qM0DdDb4p4a8Uvm6bhRVCYhd/9uELiWKdMiAcjxgx9/CiR2P1SPqONk2Nw1NZz RXLYneRAyTvOAI3xMXQy28KcGbsJPLOj2UD6XukaCbnF1skbS0cJe20/2zs8a+5E wMi6DQomWF20U/mLpnaqJVL1hoOA/OOHIAjmQTf/MUUdFwInlMcyKlGyHkQRNrTv k/9QXqvgTXScbh09zEkfBzjP2zE/nskDhwpvgq1tDB+0NJ77S7pdV89eqMZ0h1u1 uISDi1plkc5VNiAHK8p2qj5KUSa8kofh6KdYCDx3KxipXsxTFMXFiuRuitgWdQx4 IAzhQDMYtJ+1/SVEmcRTCC1R9niDsjPhkFqlyODEcDHBL3zSi1srhjbNfmgxYOm9 KdMB3CJig07FOwvxfCz3BjRVZVXuGrjDGs+TAuHfwVLVY2sdaiQ0TwJXnOY+/7kd Wee+5GG18HCLJsFap4cnidPS43LxeHjNKoTcj6FhViXU8t12St17nRnNSEfSjcF5 5FI44YZk+J44iBWcqgHpPFh1bRf4Ay1jzVOmj9yywSRYyW//kzYOpdr79naY4DIZ ukOUHXTvTGy0DweRHc7/VuUvMjnH2Udn+A/6IZ+2ZUsgEfWdmD0= =GXNS -END PGP SIGNATURE-
Bug#978936: darktable: FTBFS on arm64
Package: darktable Version: 3.4.0-1 Severity: serious Tags: upstream Justification: ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: -1 forwarded https://github.com/darktable-org/darktable/issues/7583 The new release requires xmmintrin.h in several places, and that include file is only present (in Debian) on amd64. https://buildd.debian.org/status/fetch.php?pkg=darktable=arm64=3.4.0-1=1608929069=0 - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages darktable depends on: ii libc62.31-6 ii libcairo21.16.0-4 ii libcolord-gtk1 0.1.26-2 ii libcolord2 1.4.4-2 ii libcups2 2.3.3op1-3 ii libcurl3-gnutls 7.72.0-1 ii libexiv2-27 0.27.3-3 ii libgcc-s110.2.1-3 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgomp1 10.2.1-3 ii libgphoto2-6 2.5.26-2 ii libgphoto2-port122.5.26-2 ii libgraphicsmagick-q16-3 1.4+really1.3.36-1 ii libgtk-3-0 3.24.24-1 ii libilmbase25 2.5.3-2 ii libjpeg62-turbo 1:2.0.5-1.1 ii libjson-glib-1.0-0 1.6.0-2 ii liblcms2-2 2.9-4+b1 ii liblensfun1 0.3.2-5 ii liblua5.3-0 5.3.3-1.1+b1 ii libopenexr25 2.5.3-2 ii libopenjp2-7 2.3.1-1 ii libosmgpsmap-1.0-1 1.1.0-7 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpng16-16 1.6.37-3 ii libpugixml1v51.11.4-1 ii librsvg2-2 2.50.2+dfsg-1 ii libsecret-1-00.20.4-1 ii libsoup2.4-1 2.72.0-2 ii libsqlite3-0 3.34.0-1 ii libstdc++6 10.2.1-3 ii libtiff5 4.2.0-1 ii libwebp6 0.6.1-2+b1 ii libx11-6 2:1.6.12-1 ii libxml2 2.9.10+dfsg-6.3+b1 ii libxrandr2 2:1.5.1-1 ii zlib1g 1:1.2.11.dfsg-2 darktable recommends no packages. darktable suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl/uD6kACgkQA0U5G1Wq FSFD8A/+KlBt0LMrGwiDWI/p56Gcdg5EMMbPMG7G7E1LJBBMSyQ5EhEUjo+TQRhR HRBzfEKPgkYJu+93XvDRVeITJtq9xIL1KTISWgcQRTIC71SDDHGtG7nvJTLVK/fD 7+PnVI3hTPoyNmg2WAK8PtX/TbsOcGNIsx3h173/vonGpL7PUMkhJOWNhH4u/OB8 R7NgusGmji5ylnaPFVNYHII0Ig4r2pBQa7crNiBbCCS7gLMV/BZbp+zbcsnFyLsR Iynu2+I0S0lCHIEbMblwwz68eHoC0cwaJQ6ypcansMT/4v8pYWnByc9U9qZfc8yf g4ZhQKBxofq3GRFY/k+CguIDXub1jBP23WWM7lWZgRL/l0BYQDybPvJ7kqCevDM3 xdJNA2/XZA7M6e0VlNR7V4wuuSaThhUusqE+FZebS2yfCfV2n4QdW74vBDV+E7dP DqexnuS5Xig0lC/PZ5Eg49ZN4k65Qpf945UMjbHzSKNa45m4+wJLigxdvdMXBN0H E0cdYwGecL0WAlzZNUtfLLEYG0zyZxijrWHV3DjysDf3AnxWcuS+3fFoy/aR/oNw niQFX+M21HLUaqpJBTBs3xCZWMvmMK6vbETuWqEzSR18HDKIXnuTCkpNsZ23BnQ7 5OrPfb2eZZUWkfg9fhFS6lgv6Ysk/Liv7FJ9YVrR4V7XKx7m6Ow= =HiaZ -END PGP SIGNATURE-
Bug#978444: FTBFS: fails to contact repl server in tests
Source: racket-mode
Version: 20201227git0-1
Severity: serious
Justification: ftbfs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Control: tag -1 help
This is a different test problem than Lucas reported in #978345.
I can duplicate the bug in sbuild, but if I use
- --build-failed-commands="%SBUILD_SHELL" and run dpkg-buildpackage in
the resulting shell, tests complete fine. Similarly spinning up a
schroot session and running dpkg-buildpackage there works fine. I'm a
bit at a loss as to how to proceed.
seemingly relevant bit of log follows
- -
racket-tests/debugger
Could not connect to REPL server at 127.0.0.1:36701
{racket-mode-back-end-stderr} exception raised by error display handler:
tcp-write: error writing
system error: Broken pipe; errno=32; original raise called (with
non-exception value): #f
Test racket-tests/debugger backtrace:
signal(ert-test-failed (((should (get-buffer racket-repl-buffer-name
ert-fail(((should (get-buffer racket-repl-buffer-name)) :form (get-b
(if (unwind-protect (setq value-520 (apply fn-518 args-519)) (setq f
(let (form-description-522) (if (unwind-protect (setq value-520 (app
(let ((value-520 'ert-form-evaluation-aborted-521)) (let (form-descr
(let* ((fn-518 #'get-buffer) (args-519 (condition-case err (let ((si
(progn (racket-tests/call-until-true #'(lambda nil (get-buffer racke
(let* ((path (make-temp-file "test" nil ".rkt")) (name (file-name-no
(closure (t) nil (let* ((path (make-temp-file "test" nil ".rkt")) (n
funcall((closure (t) nil (let* ((path (make-temp-file "test" nil ".r
(unwind-protect (funcall thunk) (racket-stop-back-end))
(let ((racket-command-timeout racket-tests/timeout)) (unwind-protect
racket-tests/call-with-back-end-settings((closure (t) nil (let* ((pa
(closure (t) nil (message "racket-tests/debugger") (racket-tests/cal
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name racket-tests/debugger :documentation
ert-run-or-rerun-test(#s(ert--stats :selector t :tests [... ... ...
ert-run-tests(t #f(compiled-function (event-type event-args) #
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
eval((ert-run-tests-batch-and-exit) t)
command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
command-line()
normal-top-level()
Test racket-tests/debugger condition:
(ert-test-failed
((should
(get-buffer racket-repl-buffer-name))
:form
(get-buffer "*Racket REPL*")
:value nil))
FAILED 2/12 racket-tests/debugger (10.004132 sec)
- -- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl/or4EACgkQA0U5G1Wq
FSFyWhAAq0OmhkY2xS7EyyevRVqDIVO+zd3joBSUGZM14Mosdh3uU8FoStLhbMzk
O0xGRRjdroVnYdsUyFdpWm49Q+cbqbzlx3rXBakoIFfHR+TLhPX4glZB3MtQ8RbT
V2okZVe+9PtbFh2NF7FpyEAqozV51vQcFpZm/M63RjsyCUdSo0fF79gKUYYMueYP
ZLQLyeo7ezlQqPDQTOPVXYgTx1+Q4mz5H8VHFk/Jia41w7p0hubCylt4dbzAfhXl
Uge3ZypW06vYPoGpZwTZ03des8e1LxyaKtHOvcdMxrMEhGRFhbhYdgpyWsFCGw/A
XLniN6lOH8YMFDudjQeXpB/5fWHgB+wCXV9pKDEBUOgXvhLAv2Q7I0elhUJQAbJd
oZy9cBzJQCl+Qd9gg73Zw14lBJe0SgOAe6rnzDnJzYza1N2UEncKKStz3VpUPsrq
6zFE7ybUU52uKMQYdnmdedSeyBffHFwAPV6GMY/oOQ7nx5DDqSvu4p5eSrdcShpN
gF9OWptMYIiRvhfZkrQtJ3NGYDYJKsvvzTo30QeZjKJd5Xl/mfmcyEU3Duxu2Faj
HgnBIM8Etx5Mts2JCeddTZGgtXHo9Sce37z3FFD6vgzyAHex+q90EE3M9tAeqt2A
YR0PTAoDK73LoyudfDXrJiD4VRZP1PJrmyA1HGjergfjKK2z/ZA=
=GEWs
-END PGP SIGNATURE-
Bug#976934: [PATCH] build/docs: move docstring prereq to file targets
Tomi Ollila writes: > On Wed, Dec 09 2020, David Bremner wrote: > >> Under a sufficiently high level of parallelism [1] there seems to be a >> a race condition that allows sphinx-build to start running before the >> docstrings are extracted. This change moves the docstring stamp from >> the phony targets sphinx-html and sphinx-info to the file targets that >> they depend on. I'm not sure why this makes things better, but I am >> fairly confident it does not make things worse, and experimentally it >> seems to eliminate the race condition. > > Good enough for me if this helps. I also don't see reason why that would > make things better (and probably not things worse), just that I got > headache reading that Makefile ;) (and, for example, these particular > targets mentioned would not need to be marked .PHONY...) > > I'd suggest to monitor the behaviour for a while and if things are > consistently better then merge -- such a things when we don't know > enough experience may be enough (or someone(tm) could try to parse make > debug logs ;/) -- or someone(tm) may tell us why that heleps :D I'll try a test upload to Debian and see if that fixes the problem there. I did 2000 builds (sortof by mistake) at -j32 on a 16 thread / 8 core machine, with no crashes. Much less parallelism than the original report, but lots of repetition. d
Bug#976934: [PATCH] build/docs: move docstring prereq to file targets
Under a sufficiently high level of parallelism [1] there seems to be a a race condition that allows sphinx-build to start running before the docstrings are extracted. This change moves the docstring stamp from the phony targets sphinx-html and sphinx-info to the file targets that they depend on. I'm not sure why this makes things better, but I am fairly confident it does not make things worse, and experimentally it seems to eliminate the race condition. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976934 --- doc/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/Makefile.local b/doc/Makefile.local index 60bd7184..f476d1da 100644 --- a/doc/Makefile.local +++ b/doc/Makefile.local @@ -43,7 +43,7 @@ INFO_INFO_FILES := $(INFO_TEXI_FILES:.texi=.info) rm -f $@ && gzip --no-name --stdout $^ > $@ ifeq ($(WITH_EMACS),1) -$(DOCBUILDDIR)/.roff.stamp sphinx-html sphinx-texinfo: docstring.stamp +$(DOCBUILDDIR)/.roff.stamp $(DOCBUILDDIR)/.html.stamp $(DOCBUILDDIR)/.texi.stamp : docstring.stamp endif sphinx-html: $(DOCBUILDDIR)/.html.stamp -- 2.29.2
Bug#976934: notmuch: FTBFS on ppc64el: FileNotFoundError: [Errno 2] No such file or directory: '/<>/emacs/notmuch.rsti'
Control: tag -1 confirmed Lucas Nussbaum writes: > Source: notmuch > Version: 0.31.2-3 > Severity: serious > Justification: FTBFS on ppc64el > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. > > I'm marking this bug as severity:serious since your package currently has > ppc64el binary packages in unstable (so this is a regression). Thanks for the report. It looks like it is some combination of an arch all build, and fairly high degree of parlellism in the build. I only managed to duplicate it on plummer with -j32. For future runs it would be great if the sbuild flags could be in the actual bug report (it took me a while to realize you were doing sbuild -A), and if possible the amount of parallelism (parallel=whatever, or equivalent). d
Bug#974058: Help with an arm64 specific gcc internal error with polymake
Wookey writes: > On 2020-11-27 10:28 -0400, David Bremner wrote: > >> I'm talking about remove polymake/arm64, not perl. > > Right, but perl build-depends on polymake, so with no polymake we > can't update perl (e.g. for security reasons) > That doesn't make sense to me. Polymake is software for mathematical research, which happens to be a perl extension. apt showsrc perl says: Package: perl Binary: perl-base, perl-doc, perl-debug, libperl5.32, libperl-dev, perl-modules-5.32, perl Version: 5.32.0-5 Maintainer: Niko Tyni Uploaders: Dominic Hargreaves Build-Depends: file, cpio, libdb-dev, libgdbm-dev (>= 1.18-3), libgdbm-compat-dev, netbase , procps [!hurd-any] , debhelper-compat (= 13), zlib1g-dev | libz-dev, libbz2-dev, dpkg-dev (>= 1.17.14), dist (>= 3.5-236), libc6-dev (>= 2.19-9) [s390x] Version: 5.30.3-4 Build-Depends: file, cpio, libdb-dev, libgdbm-dev (>= 1.18-3), libgdbm-compat-dev, netbase , procps [!hurd-any] , debhelper-compat (= 13), zlib1g-dev | libz-dev, libbz2-dev, dpkg-dev (>= 1.17.14), dist (>= 3.5-236), libc6-dev (>= 2.19-9) [s390x]
Bug#974058: Help with an arm64 specific gcc internal error with polymake
Wookey writes: >> At the risk of being repetitive, this is only a workaround for the perl >> transition, it does almost nothing for polymake on arm64. The package is >> still RC buggy since it is compiled with a non-default version of >> gcc. I'm still looking at an arch-specific removal for bullseye. > > What are the implications of that? Wouldn't that make perl unbuildable > on arm64 for the lifetime of the release which sounds like a big > problem for everyone? i.e polymake is now pseudo build-essential. > > Obviously it's bad that polymake can only be built with an older > compiler version, but we are at the mercy of compiler engineers fixing > what appears to be a very old and difficult bug. Removing the package > (and thus security support for perl) doesn't seem like something that > serves our uses very well. > > Have I misunderstood the problem, or is this the situation? I'm talking about remove polymake/arm64, not perl. d
Bug#972981: src:uncrustify: fails to migrate to testing for too long: FTBFS on armhf
Paul Gevers writes: > Source: uncrustify > Version: 0.69.0+dfsg1-1 > Severity: serious > Control: close -1 0.71.0+dfsg1-1 > Tags: sid bullseye > User: release.debian@packages.debian.org > Usertags: out-of-sync The give-back I triggered built on armhf, so it should migrate in due course. I wonder how often a give-back helps, and if it is worth considering triggering a give-back before filing the bug. d signature.asc Description: PGP signature
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
Emilio Pozuelo Monfort writes: > > You're missing libpoppler-glib's dbgsym. Could you install it? > > Also if you could bisect this against poppler that would help. Given that this > is linking against libpoppler-glib and not libpoppler(-private), you shouldn't > need to recompile epdfinfo, just run it against the local poppler build with > the > appropriate LD_LIBRARY_PATH or so. Oh! installing the matching version of libpoppler-glib8 from unstable makes the segfaults go away. I can probably fix elpa-pdf-tools-server by adding a versioned depends. Should something else be ensuring the version of libpoppler-glib8 matches (or is high enough)? d
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
David Bremner writes: > Package: elpa-pdf-tools-server > Version: 0.90-3+b2 Here's a backtrace Program received signal SIGSEGV, Segmentation fault. 0x77e5951e in ?? () from /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 (gdb) bt #0 0x77e5951e in () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 #1 0x77ac284f in Gfx::opShowSpaceText(Object*, int) (this=0x555c3100, args=0x7fffddb0, numArgs=) at ./poppler/Object.h:411 #2 0x77ab8637 in Gfx::go(bool) (this=this@entry=0x555c3100, topLevel=topLevel@entry=true) at ./poppler/Gfx.cc:679 #3 0x77ab8b50 in Gfx::display(Object*, bool) (this=this@entry=0x555c3100, obj=obj@entry=0x7fffe0c0, topLevel=topLevel@entry=true) at ./poppler/Gfx.cc:640 #4 0x77b12652 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*, bool) (this=0x555b6020, out=0x555c0be0, hDPI=, vDPI=, rotate=, useMediaBox=, crop=, sliceX=, sliceY=-1, sliceW=-1, sliceH=-1, printing=false, abortCheckCbk=0x0, abortCheckCbkData=0x0, annotDisplayDecideCbk= 0x0, annotDisplayDecideCbkData=0x0, copyXRef=false) at ./poppler/Page.cc:574 #5 0x77e4439c in () at /usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 #6 0xee26 in image_render_page (pdf=, page=0x555bd440, width=, options=0x55589f18, do_render_annotaions=1) at epdfinfo.c:491 #7 0xf9ab in cmd_renderpage (ctx=0x7fffe3c8, args=) at epdfinfo.c:3100 #8 0xb33a in main (argc=, argv=) at epdfinfo.c:3689
Bug#969537: elpa-pdf-tools-server: broken when compiled against libpoppler102
Package: elpa-pdf-tools-server Version: 0.90-3+b2 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Here's a script to reproduce the segfault (path needs adjusting, must be absolute). I suspect any pdf will be the same, but I will attach the pdf in question. I say grave because this is the first command sent by the emacs package elpa-pdf-tools to verify the server is working. /usr/bin/epdfinfo < wt8.pdf Description: Adobe PDF document
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
Michael Meskes writes: > On Mon, 2020-06-22 at 11:37 -0300, David Bremner wrote: >> Michael Meskes writes: >> >> > > IMO the move of col needs to be rolled back ASAP. And, if it is >> > > to >> > >> > Why? Care to give a reason? >> > >> >> The change broke man-db, as I explained in a previous message. > > Oh, that I understand and I'm sorry I didn't notice that issue before, > but why is rolling back preferable over fixing man-db? I don't know what Julien had in mind, presumably worried about other breakage to surface. Note that obvious fix to man-db will all debhelper using packages transitively build-depending on bsdextrautils. d
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
Michael Meskes writes: >> IMO the move of col needs to be rolled back ASAP. And, if it is to > > Why? Care to give a reason? > The change broke man-db, as I explained in a previous message. d
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
Lucas Nussbaum writes:
>
> Hi David,
>
> 'col' indeed moved to bsdextrautils. But in the notmuch case, there's
> nothing pulling bsdextrautils during the build, so it's not installed.
>
> I suspect that when you dist-upgraded your chroot, you somehow ended up
> with a non-minimal chroot that included bsdextrautils.
Yes, that seems to be the case. It looks like bsdutils recommends
bsdextrautils. I suppose in a "minimal" chroot you do not install
recommends.
notmuch does not call "col" directly, only man. So I guess if anything
needs an extra dependency on bsdextrautils, it is man-db?
If I install man-db in a fresh chroot with --no-install-recommends, then the
following
fails:
(unstable-amd64-sbuild)root@convex:/home/bremner# man man < /dev/null >
/dev/null
man: can't execute col: No such file or directory
man: command exited with status 127: col -b -p -x | sed -e '/^[[:space:]]*$/{
N; /^[[:space:]]*\n[[:space:]]*$/D; }'
Bug#948789: [racket/racket] Illegal Instruction on freescale i.mx53 (armv7l) (#3050)
David Bremner writes: > Paulo Matos writes: > >> Upstream issue reference for: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948789 >> Mailing list information: >> https://groups.google.com/d/msg/racket-dev/o631-azv-5g/r9Ct1H_KDAAJ > > I'm not sure if this is a surprise or not, but it looks like the 7.6 is > breaking in the same place: > > https://buildd.debian.org/status/fetch.php?pkg=racket=armhf=7.6%2Bdfsg1-1=1584149113=0 Paulo earlier asked if this was still getting an illegal instruction. It's a bit surprising (to me), but running in GDB I get SIGSEGV, I would have thought SIGILL. In any case dissassembly shows an "stmdb" instruction, as before. d
Bug#948789: [racket/racket] Illegal Instruction on freescale i.mx53 (armv7l) (#3050)
Paulo Matos writes: > Upstream issue reference for: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948789 > Mailing list information: > https://groups.google.com/d/msg/racket-dev/o631-azv-5g/r9Ct1H_KDAAJ I'm not sure if this is a surprise or not, but it looks like the 7.6 is breaking in the same place: https://buildd.debian.org/status/fetch.php?pkg=racket=armhf=7.6%2Bdfsg1-1=1584149113=0
Bug#951151: polymake: test failure on mips64el
Benjamin Lorenz writes: > >> It looks like it's flint related? > > Yes, I think this is a bug in flint and for now I suggest disabling the > flint-interface of polymake with the configure option --without-flint on > mips64el. This has basically no functionality loss as polymake will use > its own generic polynomial arithmetic instead (it will be somewhat slower). > Currently rebuilding polymake to check the testsuite again but this will > take some time and I will report back tomorrow. > The easy thing would be to disable it everywhere. It is also possible to do it on an architecture specific basis. Do you think the (small) added complexity of the latter is worth it? d
Bug#951151: polymake: test failure on mips64el
Package: polymake Version: 4.0-2 Severity: serious Justification: FTBFS After building on mips64el, I get HOME=$(mktemp -p build -d) perl perl/polymake --script run_testcases --emacs-style polymake: WARNING: created private directory build/tmp.8rZQYU191i/.polymake [snip] [ /core/functions/Schemas/create_restrictive_schema ] 1 verifying: 1 OK [ /common/functions/Linear Algebra/det ] 1 2zsh: segmentation fault HOME=$(mktemp -p build -d) perl perl/polymake --script run_testcases My naive attempt to get a backtrace just got the following: rogram received signal SIGSEGV, Segmentation fault. 0x00fff786029c in _fmpz_poly_xgcd_modular () from /usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so (gdb) bt #0 0x00fff786029c in _fmpz_poly_xgcd_modular () from /usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so #1 0x00fff7860294 in _fmpz_poly_xgcd_modular () from /usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so Backtrace stopped: frame did not save the PC It looks like it's flint related? -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-7-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages polymake depends on: ii libbliss2 0.73-2 ii libc6 2.28-10 ii libcdd0d094j-2 ii libgcc1 1:8.3.0-6 ii libgmp102:6.1.2+dfsg-4 ii libgmpxx4ldbl 2:6.1.2+dfsg-4 ii libgomp18.3.0-6 ii liblrs0 0.70-3 ii libmpfr64.0.2-1 ii libnormaliz33.6.3+ds-1 ii libpolymake-dev-common 3.2r4-4 ii libppl141:1.2-7 ii libstdc++6 8.3.0-6 ii libxml2 2.9.4+dfsg1-7+b3 ii ninja-build 1.8.2-1 ii polymake-common 3.2r4-4 Versions of packages polymake recommends: ii chromium 79.0.3945.130-1~deb10u1 ii gfan 0.6.2-2 ii graphviz 2.40.1-6 ii sketch 1:0.3.7-11 ii xdg-utils 1.1.3-1 Versions of packages polymake suggests: pn povray ii texlive-pictures 2018.20190227-2 -- no debconf information
Bug#948789: [racket-dev] build failures for 7.5 on debian armhf
Matthew Flatt writes:
> At Fri, 17 Jan 2020 09:43:15 -0400, David Bremner wrote:
>> Matthew Flatt writes:
>> > At Fri, 17 Jan 2020 08:31:22 -0400, David Bremner wrote:
>> >> => 0xb6ea3254 <+8>: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11,
>> >> lr}
>> >>0xb6ea3258 <+12>:add r3, pc
>> >
>> > That certainly looks like a valid ARM instruction. Maybe the processor
>> > is expecting Thumb instructions. What does `print $cpsr` report?
>>
>> (gdb) print $cpsr
>> $3 = 196656
>
> Since bit 5 is set, I think that means the processor was expecting
> Thumb instructions, which at least explains the error.
>
> To confirm that it's some bad jump or mismanagement of the mode by the
> Racket JIT, does changing "racket/src/lightning/arm/asm.h" to disable
> Thumb support allow the build to work?
I'm not very sure I'm doing the right thing, but With the following
change, I get the same build failure.
% diff -u asm.h~ asm.h
--- asm.h~ 2019-12-30 19:12:36.0 +
+++ asm.h 2020-01-17 16:06:45.964573092 +
@@ -2299,4 +2299,7 @@
#define THUMB2_CLZ 0xfab0f080
#define T2_CLZ(rd,rm) thumb2_orrr(THUMB2_CLZ,rd,rm,rm)
+# undef JIT_ARM_THUMB
+# define JIT_ARM_THUMB 0
+
#endif /* __lightning_asm_h */
Bug#948789: [racket-dev] build failures for 7.5 on debian armhf
Matthew Flatt writes:
> At Fri, 17 Jan 2020 08:31:22 -0400, David Bremner wrote:
>> I tried both modes, at least to my inexpert eye they look the same.
>>
>> The hardware claims to be arm v7 (Freescale i.MX53).
>>
>> (gdb) set arm fallback-mode arm
>> (gdb) disassemble
>> Dump of assembler code for function malloc_stats:
>>0xb6ea324c <+0>: ldr r1, [pc, #328] ; (0xb6ea3398
>> )
>>0xb6ea324e <+2>: ldr r2, [pc, #332] ; (0xb6ea339c
>> )
>>0xb6ea3250 <+4>: add r1, pc
>>0xb6ea3252 <+6>: ldr r3, [pc, #332] ; (0xb6ea33a0
>> )
>> => 0xb6ea3254 <+8>: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
>>0xb6ea3258 <+12>:add r3, pc
>
> That certainly looks like a valid ARM instruction. Maybe the processor
> is expecting Thumb instructions. What does `print $cpsr` report?
(gdb) print $cpsr
$3 = 196656
(gdb)
Bug#948789: [racket-dev] build failures for 7.5 on debian armhf
Matthew Flatt writes:
> Since the build log says "illegal instruction", what instruction is it
> trying to execute? Since there's so much variation in supported ARM
> instructions, maybe Racket's JIT is trying to use one not supported by
> the machine. Or maybe execution has just jumped to a bad place, such as
> the middle of an instruction.
>
> In gdb, you should be able to use `disassemble` in the vicinity of the
> address where Racket crashes (like 0xb6ea3254), but you may need to use
>
I tried both modes, at least to my inexpert eye they look the same.
The hardware claims to be arm v7 (Freescale i.MX53).
(gdb) set arm fallback-mode arm
(gdb) disassemble
Dump of assembler code for function malloc_stats:
0xb6ea324c <+0>: ldr r1, [pc, #328] ; (0xb6ea3398
)
0xb6ea324e <+2>: ldr r2, [pc, #332] ; (0xb6ea339c
)
0xb6ea3250 <+4>: add r1, pc
0xb6ea3252 <+6>: ldr r3, [pc, #332] ; (0xb6ea33a0
)
=> 0xb6ea3254 <+8>: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0xb6ea3258 <+12>:add r3, pc
0xb6ea325a <+14>:ldr r2, [r1, r2]
0xb6ea325c <+16>:sub sp, #60 ; 0x3c
0xb6ea325e <+18>:ldr r5, [pc, #324] ; (0xb6ea33a4
)
0xb6ea3260 <+20>:ldr r2, [r2, #0]
0xb6ea3262 <+22>:str r2, [sp, #52] ; 0x34
0xb6ea3264 <+24>:mov.w r2, #0
0xb6ea3268 <+28>:ldr r2, [r3, #64] ; 0x40
0xb6ea326a <+30>:add r5, pc
0xb6ea326c <+32>:ldr r7, [r3, #36] ; 0x24
0xb6ea326e <+34>:cmp r2, #0
0xb6ea3270 <+36>:blt.w 0xb6ea338c
0xb6ea3274 <+40>:ldr r3, [pc, #304] ; (0xb6ea33a8
)
0xb6ea3276 <+42>:add.w r9, sp, #12
0xb6ea327a <+46>:ldr r4, [pc, #304] ; (0xb6ea33ac
)
0xb6ea327c <+48>:movsr6, #0
0xb6ea327e <+50>:Cannot access memory at address 0xb6ea327e
(gdb) set arm fallback-mode thumb
(gdb) disassemble
Dump of assembler code for function malloc_stats:
0xb6ea324c <+0>: ldr r1, [pc, #328] ; (0xb6ea3398
)
0xb6ea324e <+2>: ldr r2, [pc, #332] ; (0xb6ea339c
)
0xb6ea3250 <+4>: add r1, pc
0xb6ea3252 <+6>: ldr r3, [pc, #332] ; (0xb6ea33a0
)
=> 0xb6ea3254 <+8>: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
0xb6ea3258 <+12>:add r3, pc
0xb6ea325a <+14>:ldr r2, [r1, r2]
0xb6ea325c <+16>:sub sp, #60 ; 0x3c
0xb6ea325e <+18>:ldr r5, [pc, #324] ; (0xb6ea33a4
)
0xb6ea3260 <+20>:ldr r2, [r2, #0]
0xb6ea3262 <+22>:str r2, [sp, #52] ; 0x34
0xb6ea3264 <+24>:mov.w r2, #0
0xb6ea3268 <+28>:ldr r2, [r3, #64] ; 0x40
0xb6ea326a <+30>:add r5, pc
0xb6ea326c <+32>:ldr r7, [r3, #36] ; 0x24
0xb6ea326e <+34>:cmp r2, #0
0xb6ea3270 <+36>:blt.w 0xb6ea338c
0xb6ea3274 <+40>:ldr r3, [pc, #304] ; (0xb6ea33a8
)
0xb6ea3276 <+42>:add.w r9, sp, #12
0xb6ea327a <+46>:ldr r4, [pc, #304] ; (0xb6ea33ac
)
0xb6ea327c <+48>:movsr6, #0
0xb6ea327e <+50>:Cannot access memory at address 0xb6ea327e
(gdb)
Bug#948789: racket ftbfs at least on armhf, and doesn't migrate
Matthias Klose writes: > Package: src:racket > Version: 7.5+dfsg2-1 > Severity: serious > Tags: sid bullseye > > racket ftbfs at least on armhf, and doesn't migrate: > Yup, thanks for filing. I had a look at it, but I didn't get very far. I also didn't get any response on #debian-arm (which is obviously not the most official way to ask for help). d
Bug#944249: [Pkg-emacsen-addons] Bug#944249: marked as done (gnuplot-mode does not work with emacs26)
"Debian Bug Tracking System" writes: > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > Do you plan to do a stable update? It seems not great that the package is pretty broken in stable. d
Bug#936834: ledger: Python2 removal in sid/bullseye
David Bremner writes: > ChangZhuo Chen (陳昌倬) writes: > >> Control: severity -1 serious >> > > Control: severity -1 important > > There is already a (merged) bug on libboost-python167.0 tracking the > missing soname issue, and keeping the problematic version out of > testing. Last I heard xnox was working on that issue. > > The bug that doko filed is about the dependency on python2, which is not > yet RC. And upstream seems to have merged xnox's port to python3. Let's wait a bit to see if the world explodes, then maybe upload a snapshot. d
Bug#936834: ledger: Python2 removal in sid/bullseye
ChangZhuo Chen (陳昌倬) writes: > Control: severity -1 serious > Control: severity -1 important There is already a (merged) bug on libboost-python167.0 tracking the missing soname issue, and keeping the problematic version out of testing. Last I heard xnox was working on that issue. The bug that doko filed is about the dependency on python2, which is not yet RC.
Bug#945316: polymake: FTBFS with perl 5.30
Benjamin Lorenz writes: > On 22/11/2019 22.06, Andreas Beckmann wrote: >> polymake FTBFS against perl 5.30: >> https://buildd.debian.org/status/package.php?p=polymake=unstable >> >> *** Summary *** >> >> *** Failed tests *** >> >> /<>/apps/polytope/src/gc_closure.cc:173: testcase 1 >> expected: regular return >> got: EXCEPTION: no more rules available to compute >> 'HILBERT_BASIS_GENERATORS' >> >> make[1]: *** [debian/rules:41: override_dh_auto_test] Error 1 > > This was already reported and should be fixed with > https://bugs.debian.org/941933 > but it seems that the builds need to be triggered again as the logs are > older than the normaliz 3.8.1+ds-1 upload. > > Benjamin Hello Benjamin; That's true, however with normaliz 3.8.1 I also get test failures. [ /functions/Producing a polytope from polytopes/stack ] 1 verifying: 1 OK [ /functions/Triangulations, subdivisions and volume/staircase_weight ] 1 verifying: 1 OK [ /functions/Producing a polytope from polytopes/tensor ] 1 verifying: 1 OK [ /functions/Optimization/totally_dual_integral ] 1Segmentation fault Full log is attached. polymake_3.2r4-4_amd64-2019-11-23T16:47:22Z.build.gz Description: application/gzip
Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26
Agustin Martin writes: > > I have been thinking about this and I see a problem with the elpa way of > handling prefix auto-mode-alist associations. They go to a file that is not > a conffile. So, if that kind of conflicts appear it is not as easy to > handle as just editing one of the conffiles and commenting the undesired > association. > I guess it should still be possible to override these settings, definitely for an individual user, or probably also system-wide. But Debian should really not ship packages with conflicts, whatever mechanism of setting variables is used. d
Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26
Agustin Martin writes: > > Hi, David, > >> That's not loaded by elpa packages. > > But AFAIK it should be loaded by Emacs, Perhaps. Team packages don't use these startup files anymore. Most of the content (updating load paths in particular) is handled more reliably by package.el generated autoload files. > >> The general approach is to add an autoload cookie to set >> auto-mode-alist. See "HINTS" in dh_elpa(1). > > I was looking at it and noticed the autoloads part, but nothing about > `auto-mode-alist'. Where is it? > See "Other customizations"
Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26
Dima Kogan writes: > Thanks for the patches, Agustin. I just tried it out. Works for the most > part. One thing that doesn't work for me is (gnuplot-mode) being > executed when opening a .gp file. You added this to the package, and the > dh-elpa machinery is creating the appropriate file: > > /etc/emacs/site-start.d/50elpa-gnuplot-mode.el > > I don't think this is being evaluated, however. Is it working for you? That's not loaded by elpa packages. The general approach is to add an autoload cookie to set auto-mode-alist. See "HINTS" in dh_elpa(1). Of course the usual cautions about auto-mode-alist apply, in particular there's no nice way to resolve conflicts with other packages (e.g. pari-gp) that might want to use the same suffix.
Bug#941046: bbdb: byte-compilation and startup broken with unversioned emacs
Control: severity -1 important Control: tag -1 help David Bremner writes: > > debian/bbdb.emacsen-install was never updated for unversioned > emacs. This means the package fails to byte compile, which in turn > causes the startup file to bail out. I have work in progress [1] that fixes the byte-compilation. Unfortunately that seems to reveal another bug with the maintainer scripts that bbdb-autoload.elc is not being generated. That feels like a different bug to me, but I'd need more testing to be sure. > I'm not 100% sure about the severity. This bug does mean that unless > people write their own startup code (manipulating load-paths and so > on), bbdb is completely useless. I'm downgrading the severity of this bug, as it only affects users without emacs25 installed, and I suspect that's a minority. [1]: https://salsa.debian.org/emacsen-team/bbdb/tree/buster
Bug#941046: bbdb: byte-compilation and startup broken with unversioned emacs
Package: bbdb Version: 2.36-4.1 Severity: serious Justification: package does not load -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 debian/bbdb.emacsen-install was never updated for unversioned emacs. This means the package fails to byte compile, which in turn causes the startup file to bail out. I'm not 100% sure about the severity. This bug does mean that unless people write their own startup code (manipulating load-paths and so on), bbdb is completely useless. - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bbdb depends on: ii emacs-gtk [emacsen] 1:26.1+1-4 ii make 4.2.1-1.2 ii perl 5.28.1-6 bbdb recommends no packages. Versions of packages bbdb suggests: pn gnus | t-gnus pn gnuserv ii perl 5.28.1-6 pn vm pn w3m-el - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl2JVkAACgkQA0U5G1Wq FSHHEA/9GKyJ3tO/0HJyU+Tj+y1oYwoLOlbggdeCNgO5IcXUBAC3BH3wx8Y6ebQm /XuKUAC+xReUc3FL7PjYPTm6evUQP6fCNF8IUqcQBEzzWM4WBeAFcefyyZOHN5on kSS7oqMTou+GHGdP+xl9gmzP0VJCDerR7dQbOdK9cQNd5aCtcqewFrq42qjpgXnX Rnnz1CQ8UFYtDVuYBxt2N0YU0I9828ssp8oDkduvjDMANZNCpyVn1qukJ/MnYYij 6jt4Tg86dLw+KljCI7I3mF4GAofRgyK9m8PfYS2cJSjMfZ3PDCHWJnLwWlz8UKcW t23UjIKf0PWLQA1SjVee+fH+zoFo1tPmRD+gFKxjZE/+eo6CJJgnsviqlj3LUAtX uGRpbGu26vJbaEg2FBLywN21Q3pDs95K73n8Ajq7dObrSNLF2ug6xnI+7qk+NWo9 YOg2Z27fZebrBBmVJ2DI+ebpOm3mV+Z2V0DiuXzXYTrKn0Ji5tAqs+ffvp6eNww/ L6kIf6CR0rTL6tom31TFJo3L8EITcFsZE4TeiyFXmjUwdkPuSksb3SeVS+DlEsBO pa3X5/kgx1EVYSq0wCne8UE36+dHeXRT32Gl8T1X80Hc3Z0a6oFBZAd9Cy1tRtBu IyFb0l6XI8zDEMc4PN32eUnpY2eJxKupjwty4TF1VMgeykz6Auk= =/02+ -END PGP SIGNATURE-
Bug#939755: darktable: FTBFS with gcc-9
Package: darktable Version: 2.6.2-1 Severity: serious Tags: upstream Justification: ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 darktable in unstable and experimental fails to build with gcc-9, due to openmp related changes. This is known, and fixed upstream in git master. It will probably be at least another month or so before a release. There is more than one merge request upstream that would have to be backported to do this nicely. Currently the options seem to be - - force the build to use gcc-8 - - package a git snapshot, and (presumably) keep it out of testing - - take on faith a 5k line patch opensuse is using; that patch only mentions one pull request, so I don't know if it is a complete solution. - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages darktable depends on: ii libc62.28-10 ii libcairo21.16.0-4 ii libcolord-gtk1 0.1.26-2 ii libcolord2 1.4.3-4 ii libcups2 2.3.0-3 ii libcurl3-gnutls 7.65.3-1 ii libexiv2-14 0.25-4 ii libflickcurl01.26-4+b1 ii libgcc1 1:9.2.1-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.60.6-2 ii libgomp1 9.2.1-4 ii libgphoto2-6 2.5.22-3 ii libgphoto2-port122.5.22-3 ii libgraphicsmagick-q16-3 1.4+really1.3.33-1 ii libgtk-3-0 3.24.11-1 ii libilmbase23 2.2.1-2+b1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjs-prototype 1.7.1-3 ii libjs-scriptaculous 1.9.0-2 ii libjson-glib-1.0-0 1.4.4-2 ii liblcms2-2 2.9-3+b1 ii liblensfun1 0.3.2-4 ii liblua5.3-0 5.3.3-1.1+b1 ii libopenexr23 2.2.1-4.1+b1 ii libopenjp2-7 2.3.0-2 ii libosmgpsmap-1.0-1 1.1.0-6 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libpng16-16 1.6.37-1 ii libpugixml1v51.9-3 ii librsvg2-2 2.44.14-1 ii libsecret-1-00.18.7-1 ii libsoup2.4-1 2.64.2-2 ii libsqlite3-0 3.29.0-2 ii libstdc++6 9.2.1-4 ii libtiff5 4.0.10+git190818-1 ii libwebp6 0.6.1-2+b1 ii libx11-6 2:1.6.7-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii zlib1g 1:1.2.11.dfsg-1+b1 darktable recommends no packages. darktable suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl10/GAACgkQA0U5G1Wq FSFWDA//UL9/NKzuYqDuMzS3TSJaROUb3YzWRtrQVcjd0F3+hYZ7/iXwfKSfndNw Bs3jHQI0at1MOIv+eCWVhZAfen9fRJ0I184QCYqfUuN+zCZ1p6vDFj/6Bzem+eBK /WPhEvqTjQpIC37ODX1tPsoM5D8cmD/O344y69Sp2bbIUoP3lM7IZa4oGS9Jkamf itMXjGqHvcQwUh2kDqBaaRG4qMOtQOAwpFVYBhFPdIARiAW8JQK6kAXEyLLIB3pB vc7wqNbp5SMrclKlNP2cOrlddUVi7VAnDh69/mjUfipt7uxKxp+BKDvg6BxZYZze zCwoqi25p+aKvb66AgUUsmm1n+2QEutDNu1Ah009e1fzTZyZF+kcteB/midEShDz lCPsHwJ+JUOSLKehjsLjviWtk+SRIeshsnhmtqNvMkdSZPjcYQbPXaQ35mjROSv1 VKu7CYO6EVJCvBTTKRmQmBgDTn6SjFPLEa5bRohwb1EBkzOI2H9ntGWRhEhfFIgi P6LCm1wda3coyxEXn5gbFnbE1gsPG5m9uBFGsIOZ0+VcFnF0ohbDKL1X/xnf5VOn y/RJT1qTVlyEHhBZvpmOs9IH7bP755kIoWJkW5WunbjaaSTz4zxRuwn2WsBzhg89 EEfQl2DXmpW63Mxk9HOW2jAoLlt4nrXVC4Intmd0FyIvEpnD5Tk= =Q60t -END PGP SIGNATURE-
Bug#935346: work in progress upstream?
It looks like the pyqt5 branch discussed in https://github.com/keithgg/puddletag/issues/418 has been merged to master, but I didn't manage to make it work with PyQt5. It looks like the source still hardcodes pyqt5, so I don't know what's going on there. d
Bug#935717: FTBFS: tests fail
Package: haskell-mode Version: 16.1-6 Severity: serious Justification: ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 during a no-change rebuild of haskell-mode I noticed the tests are failing. failing tests: , | 4 unexpected results: |FAILED haskell-cabal-compute-checksum-1 |FAILED haskell-cabal-compute-next-prev-section-1 |FAILED haskell-cabal-enum-targets-1 |FAILED haskell-cabal-get-field-1 ` full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-mode=all=16.1-7=1566743946=log - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages haskell-mode depends on: ii elpa-haskell-mode 16.1-6 haskell-mode recommends no packages. haskell-mode suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl1io0EACgkQA0U5G1Wq FSHJAw/9FhtGmX6sgT/fR/muGtTG+zUDoslYpjsBEnrReRRJhlIwxCIYK49Hl2ew oZbSRxo4h5Ut9alewSB5pstt6h+4xZ3+hZ/B8OaPk116BMxsed3LMUWRDZXnjUnn JaffmLeykgMtLFi2eLyeE/L+x8VyLnUby3jFAfUM0NsHLvMy+aMlyYa1hMi3Fe1t /xGixtXMhLA7X7/4lEYd8yOFh+6Krqh4g/UoAPogS9V6fgQeIXIgnCLWHPv074Gv uH36OIQgjTiQChwe4GBlgEvdwrNiU9XZ4QNd9fpR2azFlz/KgDDQf1JvD7Dncecy q1fZy1iZkbUO5BwVez84Y2lfwF+rse9GU+8O5ykFg0x4KllJJe2deNW2nRXNex8B 0g7xFCwvIlDH84Pxicl3NMyCZ30d4Mp0qZ2c15CuYhLZ5QRKzj4Q1oVQSQdFzHZv +CNWAnGokkRnCIPCadzuJpF8U+63P2l/k/qSIkPv57obCuRhiqmGhrIq/MkSDvtw a6ZAQIEMiMARDUkAmieG6nKGfhBVeCR0jxqUzi1F1rr5XPYFabdb5V7PzUNNRynu 3N+EOkW+3QUFbnpatN/SuZ4pXtXa8Lqg0rtbKaJ3q4/WLL+xstr5pUL7wJHyW8Fr th2DoEN9qT5AmTPHscZxfsG23InsnDizvhKswjHqRMMPoBV7+kw= =nxBG -END PGP SIGNATURE-
Bug#935712: FTBFS: dh-elpa error
Source: emacs-git-modes Version: 1.2.8-2 Severity: serious Justification: ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 during a no-change rebuild of this package I noticed that it fails to build from source It looks like there is an incompatibility with the latest dh-elpa. , | Generating git-modes-autoloads.el | Installing... | make[1]: Leaving directory '/<>' |dh_elpa -i | dh_elpa: emacs -batch -Q -l package --eval (add-to-list 'package-directory-list "/usr/share/emacs/site-lisp/elpa") --eval (add-to-list 'package-directory-list "/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -l dh-elpa.el -f dhelpa-batch-install-file debian/elpa-git-modes//usr/share/emacs/site-lisp/elpa-src ./git-modes.el /<>/debian/.debhelper/elpa 1566734946 returned exit code 255 | E: The Debian version cannot be used as an ELPA version. | See dh_elpa(1) HINTS for how to deal with this. | make: *** [debian/rules:4: binary-indep] Error 255 | dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess returned exit status 2 ` - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl1ikmgACgkQA0U5G1Wq FSEbQw/+OXMkwDg7Pw5Cid5/x8GM8JRnWFKypsEBGeRDE0qdNHaGY0ep2uv67lLE +1OwHCkuMMIkPNgb0qxX66iXejatKKtFefQ/YE6GwtIHaPlr1Fjdi+CeJpRF/PIP 06II9XCzcb8fIPHhQWgOnkO+8ZqQtI26l5piLYqrehfd3ztsoCmP0mlRPtkdYKUJ 0/Ia3t61yq0KYdn8KKNEZD3GPLAbz4c/9zr8FFp30u4qvX6KanYZ7G5Dix1H8sti Y3fDOzLmjhyLOzVi2Vg7nb1ZzuPqEH0zAcQT+G0ONibuR+Ttfa/Z7StSLaF9Kf1p W1SoM/TupjYxuDdwGEfnoDVHiBdrWRRkAHngp6vmX/N7odCB3pPGxuM05kOKJhch duv4hWzMdu6iPoS9Qfm/3FSQe5mUN0bTqfAogRJjTLnXPNkufV1pTmCfE8sT2TJj O12EUmhB0ELdPVEak6QS2kSXfV6y04iImOkS27lTiE+xtxrrt8RCxRGwZ06Z6lv6 ubdUG9yREAhDsLVFcCISF2YiwhCZ2Pv0wQuTQE+XJLhNyIa1D1v1sOeP02+z8A0o hCRDB4Hv9H2PzDIY9eDEUOc3VJxk5y21Kj9BLaSAA6aVpbmHCQTjXlS2AdDIE/0j tB4r5TrT+3mEsM2tt5rv/isPoIg5ZZt+Hbk+8rftdxOw/z9lhU4= =N3Up -END PGP SIGNATURE-
Bug#935711: FTBFS: looks for docker?
Source: emacs-pdf-tools Version: 0.90-2 Severity: serious Justification: ftbfs During a no-change rebuild I noticed this packge does not build from source. Apologies if this is caused by the way I created the source package: % dgit --quilt=auto push-source --overwrite A sample build log is at https://buildd.debian.org/status/fetch.php?pkg=emacs-pdf-tools=amd64=0.90-2=1566739129=log I'm not sure what it wants docker for, but here is the relevant portion of logs: Creating Dockerfile for target gentoo Creating Dockerfile for target centos-7 cat docker/templates/gentoo.Dockerfile.in docker/templates/Dockerfile.in > docker/gentoo.Dockerfile Creating Dockerfile for target fedora-25 cat docker/templates/centos-7.Dockerfile.in docker/templates/Dockerfile.in > docker/centos-7.Dockerfile Creating Dockerfile for target arch cat docker/templates/fedora-25.Dockerfile.in docker/templates/Dockerfile.in > docker/fedora-25.Dockerfile cat docker/templates/arch.Dockerfile.in docker/templates/Dockerfile.in > docker/arch.Dockerfile Creating Dockerfile for target ubuntu-16 cat docker/templates/ubuntu-16.Dockerfile.in docker/templates/Dockerfile.in > docker/ubuntu-16.Dockerfile Creating Dockerfile for target fedora-24 Creating Dockerfile for target debian-9 cat docker/templates/fedora-24.Dockerfile.in docker/templates/Dockerfile.in > docker/fedora-24.Dockerfile cat docker/templates/debian-9.Dockerfile.in docker/templates/Dockerfile.in > docker/debian-9.Dockerfile Creating Dockerfile for target fedora-26 cat docker/templates/fedora-26.Dockerfile.in docker/templates/Dockerfile.in > docker/fedora-26.Dockerfile Creating Dockerfile for target ubuntu-14 cat docker/templates/ubuntu-14.Dockerfile.in docker/templates/Dockerfile.in > docker/ubuntu-14.Dockerfile Creating Dockerfile for target ubuntu-17 cat docker/templates/ubuntu-17.Dockerfile.in docker/templates/Dockerfile.in > docker/ubuntu-17.Dockerfile Creating Dockerfile for target debian-8 cat docker/templates/debian-8.Dockerfile.in docker/templates/Dockerfile.in > docker/debian-8.Dockerfile Building target gentoo docker build -q -t epdfinfo/gentoo -f docker/gentoo.Dockerfile ../ Building target centos-7 make[3]: docker: Command not found Building target fedora-25 docker build -q -t epdfinfo/centos-7 -f docker/centos-7.Dockerfile ../ make[3]: docker: Command not found Building target arch make[3]: *** [Makefile:30: docker/.gentoo.build] Error 127 make[3]: *** Waiting for unfinished jobs make[3]: *** [Makefile:30: docker/.centos-7.build] Error 127 docker build -q -t epdfinfo/fedora-25 -f docker/fedora-25.Dockerfile ../ make[3]: docker: Command not found make[3]: *** [Makefile:30: docker/.fedora-25.build] Error 127 docker build -q -t epdfinfo/arch -f docker/arch.Dockerfile ../ make[3]: docker: Command not found make[3]: *** [Makefile:30: docker/.arch.build] Error 127 make[3]: Leaving directory '/<>/server/test' make[2]: *** [Makefile:940: check-local] Error 2 make[2]: Leaving directory '/<>/server' make[1]: *** [Makefile:801: check-am] Error 2 make[1]: Leaving directory '/<>/server' dh_auto_test: cd server && make -j4 check VERBOSE=1 returned exit code 2 make: *** [debian/rules:15: build-arch] Error 255 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Build finished at 2019-08-25T13:18:44Z Finished -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#935710: FTBFS: tests fail
Source: emacs-python-environment Version: 0.0.2-4 Severity: serious Justification: ftbfs During a no-change rebuild, I noticed this package fails to build from source Apparently the tests are failing https://buildd.debian.org/status/fetch.php?pkg=emacs-python-environment=all=0.0.2-4=1566739692=log -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#934977: Bug#934994: gnuplot: FTBFS because transitional emacs25 et al. doesn't exist anymore
Paul Gevers writes: > Package: gnuplot > Version: 5.2.6+dfsg1-2 > Severity: serious > Justification: FTBFS > Tags: ftbfs > > Hi, > > The emacs source package has been providing transitional packages for > the buster release, but apparently decided to drop them. Because you > depend on them, you package now can't be build. > > In bug #934977 I read you could depend on emacs-gtk instead. > > Paul I would imagine emacs-nox would make more sense as a build-dep for most packages. or just "emacs", which depends on the 3 variants. d
Bug#934036: sketch: FTBFS in stretch (LaTeX error)
Santiago Vila writes:
> ./sketch.texi:257: Emergency stop.
> @epsfxsize
>
> @epsfspecial #1->@epsftmp =10@epsfxsize
> @divide @epsftmp by @pspoints
> @ifnum...
>
> @epsfsetgraph ... to @epsfxsize {@epsfspecial {#1}
> @hfil }@else @vfil @hbox
> t...
>
> @imagexxx ...ysize =#3@relax @fi @epsfbox {#1.eps}
> @else @doxeteximage
> {#1}{#...
>
> @image ...true @fi @else @imagexxx #1,@finish
> @fi
> @hfil @ignorespaces @image {ex000}
> @unskip @hfil
> ...
> l.257 @center @image{ex000}
That looks very similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916150
Although the timing is a bit confusing, since supposedly 916150 was
caused by a change to unstable in December of 2018
If someone wants to test, the fix for the previous incarnation was
iff --git a/Doc/make.pl b/Doc/make.pl
index 2259f74..d1c9868 100644
--- a/Doc/make.pl
+++ b/Doc/make.pl
@@ -32,10 +32,10 @@ sub make_example {
print STDERR "latex example '$ex-tmp.tex':\n";
system("sed -e s/TEXFILE/$ex/ makeex-tmp.tex > $ex-tmp.tex") == 0 or die
"$!";
system("latex $LATEX_OPTS $ex-tmp.tex") == 0 or die "$!";
-system("dvips -E $ex-tmp -o tmp.eps") == 0 or die "$!";
+system("dvips -E $ex-tmp -o $ex.eps") == 0 or die "$!";^M
# fix up bounding box (originally this was not necessary; something was
"improved")
-system("epstool --copy --bbox tmp.eps $ex.eps") == 0 or die "$!";
-unlink "tmp.eps";
+#system("epstool --copy --bbox tmp.eps $ex.eps") == 0 or die "$!";^M
+#unlink "tmp.eps";^M
local *F;
open(F, "> $ex.txt") or die "$!";
print F "Image $ex omitted in text version of this document.";
Bug#932123: nullmailer-send does not work as /var/spool/nullmailer/trigger is missing
David Bremner writes: > "Alejandro S." writes: > >> Hi David, >> >> I'm running stable (buster), I just tested purging and reinstalling but >> didn't solved the problem. >> >> Keep in mind that if you are still using SysV init it would work ok, as the >> responsible for creating the /var/spool/nullmailer/trigger is >> /etc/init.d/nullmailer, but if you are using only systemd, I think that >> init.d file is no longer used, so nobody is recreating the trigger file. >> In this machine I have purged the sysv packages (initscripts sysv-rc >> insserv startpar) as recommended by the installation guide [0]. > > I'm running testing, but the same nullmailer version. I'm running > systemd. I don't have initscripts, sysv-rc, insserv or startpar > installed. > > I admit it's not clear to me how the trigger file is being created, but > it definitely is. > With some help from Ansgar Burchardt, I realized/remembered that the pipe is being created by systemd-tmpfiles in the postinst. Can you try running (as root) # systemd-tmpfiles --create nullmailer.conf The error output of that is redirected to /dev/null in the postinst, but running it interactively should help figure out what went wrong also you might check /usr/lib/tmpfiles.d/nullmailer.conf, it should contain p /var/spool/nullmailer/trigger 622 mail root
Bug#932123: nullmailer-send does not work as /var/spool/nullmailer/trigger is missing
"Alejandro S." writes: > Hi David, > > I'm running stable (buster), I just tested purging and reinstalling but > didn't solved the problem. > > Keep in mind that if you are still using SysV init it would work ok, as the > responsible for creating the /var/spool/nullmailer/trigger is > /etc/init.d/nullmailer, but if you are using only systemd, I think that > init.d file is no longer used, so nobody is recreating the trigger file. > In this machine I have purged the sysv packages (initscripts sysv-rc > insserv startpar) as recommended by the installation guide [0]. I'm running testing, but the same nullmailer version. I'm running systemd. I don't have initscripts, sysv-rc, insserv or startpar installed. I admit it's not clear to me how the trigger file is being created, but it definitely is. d
Bug#932123: nullmailer-send does not work as /var/spool/nullmailer/trigger is missing
Hi Alejandro; I just purged and re-installed nullmailer on this (Debian testing) qmachine and /var/spool/nullmailer/trigger was re-created. It would be helpful to know if the same is true for you (after backing up your nullmailer configuration). d
Bug#932123: nullmailer-send does not work as /var/spool/nullmailer/trigger is missing
Alejandro Suarez writes: Control: severity -1 normal > Package: nullmailer > Version: 1:2.2-3 > Severity: grave > Tags: patch > Justification: renders package unusable I'm using the package on about 10 systemd based machines, so I think there is something else going on here. I'm dropping the severity for now, until I can understand what the problem you are encountering is. d
Bug#924866: elpa-geiser: incompatible with emacs 26
Package: elpa-geiser Version: 0.8.1-3 Severity: serious Tags: upstream Justification: does not load Control: tag -1 pending geiser 0.8.1 has upstream issue #207 [1], which makes it unable to load in emacs 26. To duplicate: emacs -q M-x package-initialize M-x toggle-debug-on-error C-x C-f foo.rkt backtrace starts Debugger entered--Lisp error: (invalid-function (lambda () geiser-racket--binding-forms*)) (lambda () geiser-racket--binding-forms*)() geiser-impl--set-buffer-implementation(nil t) geiser-mode(1) [1] https://gitlab.com/jaor/geiser/issues/207 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-geiser depends on: ii emacs1:26.1+1-3.2 ii emacs-gtk [emacsen] 1:26.1+1-3.2 ii emacsen-common 3.0.4 ii install-info 6.5.0.dfsg.1-4+b1 elpa-geiser recommends no packages. Versions of packages elpa-geiser suggests: ii racket 7.2+dfsg1-2 -- no debconf information
Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Didier 'OdyX' Raboud writes: > === Resolution === > > The Technical Committee resolves to decline to override the debootstrap > maintainers. > > Furthermore, using its §6.1.5 "Offering advice" power, the Technical > Committee considers that the desirable solution at the time of `bullseye` is: > > * W: `weak`: both directory schemes are allowed, but packages should only > be built on hosts with classical directory schemes (or in such > chroots) > > * M: `middle`: both directory schemes are allowed, and packages (including >official packages) can be built on hosts with either classical >or "merged `/usr`" directory schemes > > * H: `hard`: both directory schemes are allowed, but packages should only > be built on hosts with "merged `/usr`" directory schemes (or in > such chroots) > > * FD: Further Discussion > > === End Resolution === I vote M > W > H > FD signature.asc Description: PGP signature
