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."
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
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,
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
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
>
>
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
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
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
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
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
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 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
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:
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
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
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
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
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
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?).
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
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
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
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.
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:
>
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 "(
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
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
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-dis
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
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
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.
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.
>
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
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
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
>
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
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
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
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
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
Descripti
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
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
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
ebian/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/de
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
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
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) unstabl
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 +-
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.
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
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
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
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
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
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
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
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
-
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
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.
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
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
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
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
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
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
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
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 rea
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
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
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
>
>
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
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
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]
[
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,
>
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
>>
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
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
"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
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 ou
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
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
>>
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
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
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:
>
>
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
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
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
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
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
|
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.
,
|
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
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
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
Santiago Vila writes:
> ./sketch.texi:257: Emergency stop.
> @epsfxsize
>
> @epsfspecial #1->@epsftmp =10@epsfxsize
> @divide @epsftmp by @pspoints
> @ifnum...
>
> @epsfsetgraph ... to @epsfxsize {@epsfspecial {#1}
>
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 o
"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
>
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
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
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
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:
>
1 - 100 of 276 matches
Mail list logo
