Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory

[David Bremner]

Xiyue Deng  writes:

>
> Make sense.  AIUI rebuild is not necessary for enabling this because
> currently there is no package depending on this feature, and before and
> after this patch existing package will behave the same.  It is only
> making a difference when a package has source code in a sub-directory
> and this patch will disable loading that sub-directory into `load-path'.
> Currently AFAIK only auctex has this issue, and it's not yet elpafied so
> we are good.

Right, I'm just being extra paranoid (and not investingating very much
yet) about something breaking in the maintainer scripts via this change.

Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory

[David Bremner]

Xiyue Deng  writes:

>
> I have tested running the previously failed tests, e.g. clojure-mode
> which uses buttercup and flycheck which uses both buttercup and ERT, and
> they are now passing using the new implementation.
>

Build failures are (relatively) fine. What I really want to avoid is
having to do a mass rebuild to fix maintainer scripts (or worse, to have
broken maintainer scripts shipped in stable). So we need to take some
extra care and attention with changes to dh-elpa.

Bug#1080506: Should cycle-quotes be removed from unstable?

[David Bremner]

Helmut Grohne  writes:

> Source: cycle-quotes
> Severity: serious
> Justification: grab attention of maintainer

For the record, this "justification" is pretty infuriating, no matter
how well thought the rest of the message (which I am now not going to
read) might be.

Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory

[David Bremner]

Xiyue Deng  writes:

> Xiyue Deng  writes:
>
>> [[PGP Signed Part:Undecided]]
>> Sean Whitton  writes:
>>
>>> Hello Xiyue,
>>>
>>> On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote:
>>>
 I have prepared a patch at [3] and also attached.  Please help review
 and comment.  I'll merge it once it's approved.
>>>
>>> Please don't merge this yourself; let me or David do it.  Thanks.
>>
>> Ack. Will wait for your reviews.  Thanks.
>
> Friendly ping for comments.

No review yet, but what have you done for testing?

Bug#996357: RFP: python3-hawkmoth -- minimalistic Sphinx C Domain autodoc directive extension

[David Bremner]

Jani Nikula  writes:

> Bump. Looks like this has been pretty much ignored and forgotten.
>
> Hawkmoth would benefit from distro packaging, because it depends on a
> native package not available via pip (python3-clang and its
> dependencies).
>
> What could I do to move things forward?

Maybe you can do a better job than I did of convincing people that
hawkmoth will useful to a broad enough set of users of Debian to make
the maintenance burden worthwhile. One very common justification is that
it is or will be required to build other packages. A quick search for
"hawkmoth" on codesearch.debian.net suggest that it is at least used
upstream by some other packages. I don't know what those packages are
doing now (not building docs?) but maybe you do, since one of them is
mesa. OTOH network manager references hawkmoth via a vendored library,
which supports the guess of not building docs.

Bug#1076296: reset autoremoval clock

[David Bremner]

migration is blocked until sbcl migrates; debugging sbcl is ongoing.

Bug#1078076: autopkgtest: a-b-podman fails due to bad proxy choice

[David Bremner]

Simon McVittie  writes:

> I think these are the key facts here.
>
> Your apt proxy on the host system is probably set to http://127.0.0.1:3142?
>
> The bug is that a-b-podman auto-detects this, and tries to use the same
> proxy inside the container; but the host system's 127.0.0.1 will not be
> reachable from inside the container, so it tries to translate it to an
> IP address at which the host will be reachable.

Yes, that's the setting on all of my hosts with acng.

> Probably the only solution to this is for a-b-podman to refuse to use an
> auto-detected proxy if it's 127.0.0.1 (behave as if DIRECT), and instead
> log a warning that recommends using the --apt-proxy option.

That makes sense to me.

Bug#1078076: autopkgtest: a-b-podman fails due to bad proxy choice

[David Bremner]

Package: autopkgtest
Version: 5.38
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

SYMPTOMS:

+ echo no known network config tool found, skipping network config
no known network config tool found, skipping network config
+ return
+ echo Acquire::Languages "none";
+ echo force-unsafe-io
+ echo Acquire::Retries "10";
+ echo APT::Update::Error-Mode "any";
+ [ -n http://10.0.2.2:3142 ]
+ echo Acquire::http { Proxy "http://10.0.2.2:3142";; };
+ AUTOPKGTEST_APT_PROXY=http://10.0.2.2:3142
+ [ / != / ]
+ [ / != / ]
+ [ -z  ]
+ chroot / apt-get update
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Err:1 http://deb.debian.org/debian unstable InRelease
  Could not connect to 10.0.2.2:3142 (10.0.2.2). - connect (101: Network is 
unreachable)
Reading package lists...
E: Failed to fetch http://deb.debian.org/debian/dists/unstable/InRelease  Could 
not connect to 10.0.2.2:3142 (10.0.2.2). - connect (101: Network is unreachable)
E: Some index files failed to download. They have been ignored, or old ones 
used instead.
+ sleep 15
+ chroot / apt-get update
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Ign:1 http://deb.debian.org/debian unstable InRelease
Err:1 http://deb.debian.org/debian unstable InRelease
  Could not connect to 10.0.2.2:3142 (10.0.2.2). - connect (101: Network is 
unreachable)
Reading package lists...
E: Failed to fetch http://deb.debian.org/debian/dists/unstable/InRelease  Could 
not connect to 10.0.2.2:3142 (10.0.2.2). - connect (101: Network is unreachable)
E: Some index files failed to download. They have been ignored, or old ones 
used instead.
Error: building at STEP "RUN sh -eux /opt/autopkgtest/setup-testbed /": while 
running runtime: exit status 100
ERROR:autopkgtest-build-docker:Command '['podman', 'build', '--tag', 
'autopkgtest/debian:unstable', '--build-arg=IMAGE=debian:unstable', 
'--build-arg=AUTOPKGTEST_APT_PROXY=http://10.0.2.2:3142', 
'--build-arg=AUTOPKGTEST_SETUP_APT_PROXY=http://10.0.2.2:3142', 
'--build-arg=AUTOPKGTEST_SETUP_VM_POST_COMMAND=true', 
'--build-arg=MIRROR=http://deb.debian.org/debian/', 
'--build-arg=RELEASE=unstable', '/tmp/tmpkxmg48w8']' returned non-zero exit 
status 100.

EXTRA VERSIONS:

% apt policy passt
passt:
  Installed: 0.0~git20240726.57a21d2-1
  Candidate: 0.0~git20240726.57a21d2-1
  Version table:
 *** 0.0~git20240726.57a21d2-1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
-10 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

% apt policy slirp4netns
slirp4netns:
  Installed: 1.2.1-1+b1
  Candidate: 1.2.1-1+b1
  Version table:
 *** 1.2.1-1+b1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
-10 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

WORKAROUND:

Both --apt-proxy=DIRECT and --apt-proxy=http://192.168.122.1:3142

allow a-b-podman to complete (libvirt is installed and configured on
this machine).

- -- 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.9.12-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 autopkgtest depends on:
ii  apt-utils   2.9.7
ii  libdpkg-perl1.22.11
ii  mawk1.3.4.20240622-2
ii  procps  2:4.0.4-5
ii  python3 3.12.4-1
ii  python3-debian  0.1.49
ii  retry   1.0.5-3

Versions of packages autopkgtest recommends:
ii  autodep8  0.28+nmu1
ii  fakeroot  1.33-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
ii  genisoimage  9:1.1.11-3.5
pn  incus
ii  lxc  1:6.0.1-1
pn  lxd  
ii  ovmf 2024.05-1
pn  ovmf-ia32
ii  podman  

Bug#1077910: notmuch: autopkgtest failure with glib 2.81.1

[David Bremner]

Control: tag -1 -ftbfs
Control: severity -1 important

Not that it matters too much, but the original metadata (other than
affects) seems copy-pasted from the other bug.

Bug#1076296: src:slime: fails to migrate to testing for too long: autopkgtest regression

[David Bremner]

Paul Gevers  writes:

>
> The Release Team considers packages that are out-of-sync between testing 
> and unstable for more than 30 days as having a Release Critical bug in 
> testing [1]. Your package src:slime has been trying to migrate for 37 
> days [2]. Hence, I am filing this bug. The version in unstable fails its 
> own autopkgtest. Ironically the log shows: 0 errors, 0 warnings. It also 
> shows this:
> File #P"/usr/share/common-lisp/source/slime/xref.lisp" does not exist

The problem referenced in this bug is fixed (at least in my local runs
of autopkgtest), but slime cannot migrate to testing until after sbcl
2.4.*. 

Bug#1077773: slime: does not work with sbcl 2:2.3.7-2

[David Bremner]

Source: slime
Version: 2:2.30+dfsg-2
Severity: serious
Justification: 42

This bug is to prevent slime from migrating to testing before the
newer release of sbcl does.

-- 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.9.10-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

Bug#1077041: segfault in the style editor

[David Bremner]

Control: tag -1 unreprodicible

David Bremner  writes:

> This may be fixed in the next upload. I'm currently running an
> unofficial 4.8.0 package, and I cannot duplicate the problem there. When
> we upload 4.8.1, I'll let you know and you can see if you can still
> duplicate the problem.

I tried with 4.8.0-1, and I cannot duplicate your problem(s).

Bug#1077041: segfault in the style editor

[David Bremner]

Michael Deegan  writes:

> Package: darktable
> Version: 4.6.1-3+b2
> Severity: normal
>
> To reproduce:
>  - create or edit a style
>  - upon use of the Select All or Select None buttons, the dialog mostly
>stops working (except for the cancel button). Further interactions with
>the dialog either do nothing, or cause a SEGV.
>

This may be fixed in the next upload. I'm currently running an
unofficial 4.8.0 package, and I cannot duplicate the problem there. When
we upload 4.8.1, I'll let you know and you can see if you can still
duplicate the problem.

It _might_ be related to differences in environment, so if you can
reproduce in a clean debian sid or trixie environment (including a
current kernel), that might be informative.


d

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

Bernhard Übelacker  writes:

> Hello David, hello Axel,
>
>
>> I had hoped the expected behaviour might have been the error message 😉
>
> Maybe it is the expected behaviour?
>
> Following is the output of the last not crashing version 1.13
> and the current version in testing 2.2+10~g7ed88a0 with the cli_program fix.
>
> Both look quite similar except the previously crashing error message,
> so this is maybe expected by upstream?

Or it's just an old bug?

It still looks like pretty strange behaviour to me. Does (nullmailer's
version of) sendmail -bs always return a non-zero exit code, or just in
some circumstances?

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

Bernhard Übelacker  writes:

> Am 21.06.24 um 01:57 schrieb Bernhard Übelacker:
>
>> Especially the third point is puzzling, I could not yet see why this 
>> pointer-content-mixup happens.
>
>
> Hello David, hello Axel,
> I did some further tests and found following location where cli_program
> is delared here:
>
>./lib/cli++/cli++.h:35:extern const char* cli_program;
>
> But the defintion looks a bit different:
>
>./src/smtpd.cc:55:extern const char cli_program[] = "nullmailer-smtpd";
>
>
> A package built with following change does no longer show this crash.
>
> Kind regards,
> Bernhard

Hi Bernhard;

Thanks for the patch. This does seem to be progress, but I don't think
it completely fixes Axel's bug. At least for me I still see

 -> .
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No 
child processes
<** 451 4.3.0 Error returned from nullmailer-queue

and I get a non-zero exit code. I think the problem you found was
probably a crash during the reporting of the error message.

Bug#1073287: transition: lrslib

[David Bremner]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: lrs...@packages.debian.org
Control: affects -1 + src:lrslib
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is only one build-rdep, that I also maintain.  The Ben file is a
guess, since something ate the automatic transition.

Ben file:

title = "lrslib";
is_affected = .depends ~ /\b(liblrs1.*|liblrs2)\b/
is_good = .depends ~ "liblrs2";
is_bad = .depends ~ /\b(liblrs1.*)\b/";



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZuLzUACgkQA0U5G1Wq
FSFjbxAAkXf47/36S4Jz19DS43quuDZvyyNrA3nXO3WgHzHI6n5HLbsT7h2aTFx2
tS2use2ctIL09ylwEULZd3UORlhuVsa6PKXrD/u7GQsiX5JNduEk6s7Baals7tWR
6SimSvasyzveNVBhdVaOrbakNxjlKA3jJgQSKehEoJvO1HQr1nMp8px3T8ktwj18
DkNTYzEhtn7S9XgdU7TlkgA/n4O8U64eyEaKgQXV1MIeZ9jr/uFV+pjjdTM1oY1I
bpwaS2+WuruUWJ+UnzgCgfFbeK/T6hPeMOShr3yUH139P4ZvaLmRQHzS5hSussV4
CofoisF2vn12Hpcn90wgO/7Hvi2Hxg5TBejLk8z+T9X7VL3yx5O88coHxcmQA86G
nJQnC82R8KjDN8+MLYW3FuGoVq9Fs2ahZpsYtFcQbQ5kQjC1fbOWvEbLa1vOMuP9
NZiY3I8vfjGqnV0tG2O20CaeNDKQjU+8ODWzLhRAL9p8EZmXxVaefuKyNp1bPF1q
aTuWtKlroFTHRoPhmgKcj8MmgF6zm2pmRx3mJet9AaQvKFYiLRSsD93VvwoIMa6d
Lrlw191I4/nDWKZwoz2ifafl/VzdArw3WJlWmvKkfWuLDN1GO/w2/gihNRhtwSEt
6at3VaUSpMJYgtiNDLvKEw6ss7ySYKTGfVk1/2XF1hizLKr28oQ=
=HKsK
-END PGP SIGNATURE-

Bug#1073173: patch

[David Bremner]

David Bremner  writes:

> I wanted to unstick a couple of entwined transitions, so I took a guess
> at the appropriate change. Someone (TM) should confirm this is the right
> fix before uploading to unstable. Also, it would be nice to have an
> upstreamable version that builds with the older API as well.

I am someone (TM). I confirmed with lrslib author David Avis that 1 is
"legacy mode". More detailed discussion is needed about whether
polymake/sympol can take advantage of the new mode which also finds
linearities.

Bug#1073173: patch

[David Bremner]

I wanted to unstick a couple of entwined transitions, so I took a guess
at the appropriate change. Someone (TM) should confirm this is the right
fix before uploading to unstable. Also, it would be nice to have an
upstreamable version that builds with the older API as well.

From: David Bremner 
Date: Thu, 13 Jun 2024 19:40:51 -0300
Subject: Adapt new lrslib API for checkindex

According to lrslib.c

/* phase=0 find hidden linearities  phase=1 redundant inequalities only */

The latter sounds like the previous behaviour.
---
 bundled/lrs/apps/polytope/src/lrs_interface.cc  | 2 +-
 bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bundled/lrs/apps/polytope/src/lrs_interface.cc b/bundled/lrs/apps/polytope/src/lrs_interface.cc
index 1b8839d..a027d55 100644
--- a/bundled/lrs/apps/polytope/src/lrs_interface.cc
+++ b/bundled/lrs/apps/polytope/src/lrs_interface.cc
@@ -554,7 +554,7 @@ ConvexHullSolver::find_irredundant_representation(const Matrix& Points
 
Bitset V(Points.rows());
for (Int index = D.Q->lastdv+1, end = D.P->m_A+D.P->d; index <= end; ++index)
-  if ( !checkindex(D.P,D.Q,index) )
+  if ( !checkindex(D.P,D.Q,index,1) )
  V += D.Q->inequality[index - D.Q->lastdv]-1;
 
return std::pair< Bitset, Matrix >(V,AH);
diff --git a/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp b/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp
index 68fa21f..5ef0ebe 100644
--- a/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp
+++ b/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp
@@ -245,7 +245,7 @@ bool RayComputationLRS::determineRedundancies(Polyhedron & data, std::listinequality[index - lastdv]; /* the input inequality number corr. to this index */
 
-redineq[ineq] = checkindex (P, Q, index);
+redineq[ineq] = checkindex (P, Q, index, 1);
 }  /* end for index . */
 
 std::list redundancies;

Bug#1073173: polymake: FTBFS with lrslib 0.73

[David Bremner]

Package: polymake
Version: 4.11-2
Severity: important
Tags: upstream ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

polymake 4.11 and 4.12 both fail to build because of (apparently) breaking 
changes
in lrslib 0.73 (or maybe they happened in 0.71).

Here is a bit of the log from 4.11; the log from 4.12 is similar.

FAILED: /<>/build/Opt/staticlib/sympol/raycomputationlrs.o 
  g++ -c -o /<>/build/Opt/staticlib/sympol/raycomputationlrs.o 
-MMD -MT /<>/build/Opt/staticlib/sympol/raycomputationlrs.o -MF 
/<>/build/Opt/staticlib/sympol/raycomputationlrs.o.d -fPIC -pipe 
-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 
-fno-strict-aliasing -fopenmp -Wshadow -Wlogical-op -Wconversion 
-Wzero-as-null-pointer-constant -Wno-parentheses -Wno-error=unused-function 
-Wno-stringop-overflow -Wno-array-bounds -Wno-maybe-uninitialized 
-Wno-free-nonheap-object -DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 
-Wno-deprecated-declarations -Wno-shadow -Wno-conversion 
-Wno-zero-as-null-pointer-constant -I/<>/include/external/permlib 
-DGMP -DMA -I/usr/include/lrslib -DHAVE_LRSDRIVER 
-DPOLYMAKE_LRS_SUPPRESS_OUTPUT=1 -Wno-unused-result -Wno-stringop-overflow  
/<>/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp && 
: 'COMPILER_USED=13.2.0'
/<>/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp: 
In member function ‘virtual bool 
sympol::RayComputationLRS::determineRedundancies(sympol::Polyhedron&, 
std::__cxx11::list&) const’:
/<>/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp:248:36:
 error: too few arguments to function ‘long int checkindex_gmp(lrs_dic*, 
lrs_dat*, long int, long int)’
  248 | redineq[ineq] = checkindex (P, Q, index);
In file included from /usr/include/lrslib/lrslib.h:170,
 from 
/<>/bundled/sympol/external/sympol/sympol/raycomputationlrs.cpp:31:
/usr/include/lrslib/lrslib.h:39:24: note: declared here
   39 | #define checkindex suf(checkindex)
  |^~
/usr/include/lrslib/lrsgmp.h:83:19: note: in definition of macro ‘suf’
   83 | #define suf(func) func##_gmp
  |   ^~~~
/usr/include/lrslib/lrslib.h:478:6: note: in expansion of macro ‘checkindex’
  478 | long checkindex (lrs_dic * P, lrs_dat * Q, long index, long phase); /* 
index=0 non-red.,1 red., 2 input linearity NOTE: row is returned all zero if 
redundant!!  */
  |  ^~



- -- 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.7.12-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 polymake depends on:
ii  libbliss2   0.77-3+b2
ii  libc6   2.38-12
ii  libcdd0t64  094m-1.1
ii  libeantic3  2.0.2+ds-2
ii  libflint19  3.1.3-1
ii  libgcc-s1   14-20240330-1
ii  libgmp102:6.3.0+dfsg-2+b1
ii  libgmpxx4ldbl   2:6.3.0+dfsg-2+b1
ii  libgomp114-20240330-1
ii  liblrs1t64  0.71b-2.1+b1
ii  libmpfr64.2.1-1+b1
ii  libnormaliz33.10.3+ds-1
ii  libpolymake-dev-common  4.11-2
ii  libppl141:1.2-8.1+b2
ii  libsingular4m4n01:4.4.0-p2+ds-1
ii  libstdc++6  14-20240330-1
ii  ninja-build 1.12.1-1
ii  perl5.38.2-5
ii  perl-base [perlapi-5.38.2]  5.38.2-5
ii  polymake-common 4.11-2

Versions of packages polymake recommends:
ii  chromium   125.0.6422.60-1
ii  gfan   0.6.2-7
ii  graphviz   2.42.2-9+b1
ii  xdg-utils  1.1.3-4.1

Versions of packages polymake suggests:
pn  povray   
ii  texlive-latex-extra  2023.20240207-1
ii  texlive-pictures 2023.20240207-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZrckoACgkQA0U5G1Wq
FSG+mw/9F+e2My55VdpP4XTOlrI6lOi4DpweAm0BQY73RPD+H3Ym0YVlSxxvDAeE
NDGWUk9OZXD1VR9Oy2Z8HRAZ4MuuLCIP2P/FBEX6B1UscHQVvlq04eTDG6/DogUg
w+/1KbjdkjuOe9GJZtcY5VPvIm12m4kmJNVyJeBb1Xj0YthAcwJUw9s3nT9QcRRz
Q2ulCuIkxny3StHT/avAWtfMyFpmTeb3DteCEumWWfi7EybBk2K2VYLnlOwuDl77
lz+HSP4o28J5a8rvHnpsrGgSq9uXlfXms6bHLW+dV0Ql1Kfx0KDT643yeDHzaulL
Nq0ufPgl4dD6HXU3Bqv28vXBCzVEbG5HUm/j8plyqYjpnCsQsXLbnTwmKrgIbIf4
vIzW/U/Ayd9LM75OXnlIsl6X8xCQ7tRWMd7uvoP/dQA2CnA23AAOhD8sYrXqqD8H
Z33nhbgf+7oohBM5JsheCtKYu0nX+VaipMo2Y9ubhr3EI/gwgMCNHAcHwmj8s4TX
ji0g+ZiZpcYB2nrqOp+h7R+3McOy7WQoVV13DbfEdLdHHrRHBa9fmnC793N9lFyb
QpnrB3JqKQQDvXZ5t17RKyFrvj50LXhxwGg1/MTdILQl5iyui2BmIuFCG2Bp92C3
uDC3TuYfshlNLmoU08a

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

David Bremner  writes:

>
> Attempt #3
>
> swaks -t brem...@debian.org --pipe 'valgrind /usr/lib/sendmail -bs'
>
> This also runs without errors, so I'm out of ideas for the moment.

Attempt #4:

Rebuild with asan

make clean
make CXXFLAGS="-g -O1 -fsanitize=address"
make check

I don't know if this is coincidence, or actually meaningful, but the
test "Testing protocol success with smtp (stdin)" finds one memory leak.

220 OK
smtp: Succeeded: 220 OK

=
==3035435==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7f64762edd10 in strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:578
#1 0x563a16835173 in parse_option 
/home/bremner/software/debian/nullmailer/protocols/protocol.cc:116
#2 0x563a16835173 in parse_options 
/home/bremner/software/debian/nullmailer/protocols/protocol.cc:130
#3 0x563a16835173 in cli_main(int, char**) 
/home/bremner/software/debian/nullmailer/protocols/protocol.cc:138

SUMMARY: AddressSanitizer: 13 byte(s) leaked in 1 allocation(s).

Looking at the code there is indeed a leak, but it's hard to see how it
would lead to a crash.

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

Axel Beckert  writes:

> Hi David,
>
> David Bremner wrote:
>> swaks -t brem...@debian.org --pipe 'gdb -batch -ex run -ex bt --args 
>> /usr/lib/sendmail -bs'
>> 
>> This actually runs without segfaulting, which made me think it might be
>> a memory error.
>
> There's one memory fix commit upstream in the master branch:
> https://github.com/bruceg/nullmailer/commit/834e2eb6b7eac2648fc371c432a46e98d5966bb4
>
> Could it be this one? At least "fdbuf.c" sounds as if it might be
> involved in file descriptor thingies.
>

We're actually running a snapshot of master, so that commit is in
testing and unstable.

d

Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"

[David Bremner]

Control: tag -1 confirmed

Axel Beckert  writes:

> Package: nullmailer
> Version: 1:2.2+10~g7ed88a0-5
> Severity: important
> Control: found -1 1:2.2-3
>
> Dear David,
>
> I managed to reproducibly crash nullmailer-smtpd with a "general
> protection fault" by calling the following command:
>
>   swaks -t a...@debian.org --pipe 'sendmail -bs'
>
> This call produces the following output first:

I can duplicate this. I made a few (unsuccessful) attempts at localize
the error.

Attempt #1

If I run /usr/lib/sendmail -bs directly (or nullmailer-smtpd, which
amounts to the same thing, I think), and give exactly the same input, it
exits cleanly when I type QUIT.  I also tried your swaks command on a
host where sendmail is postfix, and I see end of the transaction

-> .
<-  250 2.0.0 Ok: queued as 5EC225FB72
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with child process.

Attempt #2

swaks -t brem...@debian.org --pipe 'gdb -batch -ex run -ex bt --args 
/usr/lib/sendmail -bs'

This actually runs without segfaulting, which made me think it might be
a memory error.

Attempt #3

swaks -t brem...@debian.org --pipe 'valgrind /usr/lib/sendmail -bs'

This also runs without errors, so I'm out of ideas for the moment.

Bug#1072951: racket: FTBFS on hppa - illegal pb instruction

[David Bremner]

John David Anglin  writes:

> Source: racket
> Version: 8.13+dfsg1-2
> Severity: normal
> Tags: ftbfs
>
> Dear Maintainer,
>
> Racket build fails here:
> running cs/c/ChezScheme/pb/bin/pb/scheme to build 
> cs/c/ChezScheme/xc-tpb32b/s/cmacros.so
> illegal pb instruction
> failed
>  in build-one
>  in loop
>  in module->hash
> illegal pb instruction
> make[1]: *** [Makefile:22: all] Error 1

If you want to followup with upstream [1], they are generally quite
responsive, even with exotic architectures.

[1]: https://github.com/racket/racket

Bug#1021614: [PATCH] test/cli: Add known broken test for (missing) quoting in From

[David Bremner]

In [1], Jakub Wilk observes that the current behaviour is confusing
since it looks like there are two mailboxes in From, while in fact
there is only one.  It seems to me that notmuch should at least quote
the display-name part of a mailbox if it has "funny" characters in it,
and perhaps always quote it. Either way will require changing the
indexing code, since the structure is lost when writing the headers to
the database.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021614
---
 test/T520-show.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/test/T520-show.sh b/test/T520-show.sh
index 6bcf109c..8121c3db 100755
--- a/test/T520-show.sh
+++ b/test/T520-show.sh
@@ -45,6 +45,12 @@ if [ "${NOTMUCH_HAVE_SFSEXP-0}" = "1" ]; then
 
 fi
 
+test_begin_subtest "quoting in From"
+test_subtest_known_broken
+add_message '[from]="=?UTF-8?Q?=3Cfoo=40example.org=3E=2C?= 
"'
+output=$(notmuch show id:${gen_msg_id}|grep From:)
+test_expect_equal "${output}" 'From: "," '
+
 add_email_corpus duplicate
 
 ID1=debian/2.6.1.dfsg-4-1-g87ea161@87ea161e851dfb1ea324af00e4ecfccc18875e15
-- 
2.43.0

Bug#1071948: nmu: polymake_4.11-2

[David Bremner]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: polym...@packages.debian.org
Control: affects -1 + src:polymake
User: release.debian@packages.debian.org
Usertags: binnmu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

nmu polymake_4.11-2 . ANY . unstable . -m "rebuild against libsingular4m4n0"


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZTFZAACgkQA0U5G1Wq
FSHLIQ//fw3CHgIWdpwU0gw+W7pnrs2foRdlT4YOLtgUcKIvTKlUIkOJFhDK+wO6
92rh9hGi/JZXRFN8J4VIEhZnGQdL/K3Rc0wzeeszFPYNgc85yBFn+x21IoSW+0wG
j24nQQaKuPIkbZTJrw8kD4lvFFVCvf8+w9ykTOxzoSbXEi8ZG5kBmojh3TsveYu9
VRjR4AwDNXrWamGU2YdMGEjgq0yD95NX2vqnhj+PgX/Ufvv4cBBDPPqCzMjuGXYn
yCpdhx6W/6TBdWHtQWLImkzpSDetG8Q15WMrWicD1STWOh2+bEiq9W/NcVzOd8xY
Vjb2df10kQWJlMf1AgwkFABafyaT/hkHcaaUmDW/GdYSC18Uj6xjrt9Ua6B5dYjR
XY9P71Vnmlv8it9tfiAPmFsK6SgXC3nHYHFLP28EVQfN0kkqnk8+vSYmrXCMniCp
2y10VBi60IHj0BZuxoKy3thHdBxamzAai/7Kad6khrN6Yi7beidVuBTFuLga3ph2
aQqs5JZJFa3KG6wtdl+RvQf09z+KbwQo4QCbXZUaz3kh8Kq05NxbuPACiQE56EmB
qW9eMp1ryiHQkcIl+gkxQCGhBzDoum8e2gKvAvVewcCiFxGOXt1DyWGxg5RJ8ucu
21ANaSoWS5hxzoBOLqaVbs4vX9ojgy6sjF0Dnn1OqFj1SOpbP7g=
=Q4wx
-END PGP SIGNATURE-

Bug#1071870: janus: run janus daemon as non-root?

[David Bremner]

Package: janus
Version: 1.1.2-1+b4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The systemd service for janus currently runs janus as root. Does it
need to? Upstream seems a bit ambiguous on that point. Both examples I
could find (in main.dox) use root, but one has the comment "Root
generally not recommended but necessary if you are using the Raspberry
Pi GPIO from Python."

As far as I can tell janus only listens on ports > 1024 by default,
but there could be some other issues I suppose.



- -- 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.7.12-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 janus depends on:
ii  init-system-helpers  1.66
ii  libc62.38-11
ii  libconfig9   1.5-0.4+b1
ii  libcurl4t64  8.7.1-5
ii  libduktape2072.7.0-2+b1
ii  libglib2.0-0t64  2.80.2-1
ii  libjansson4  2.14-2+b2
ii  liblua5.3-0  5.3.6-2+b2
ii  libmicrohttpd12t64   1.0.0-2.1+b1
ii  libnanomsg5  1.1.5+dfsg-1.1+b1
ii  libnice100.1.21-2+b1
ii  libogg0  1.3.5-3+b1
ii  libopus0 1.4-1+b1
ii  libpaho-mqtt1.3  1.3.13-1+b2
ii  librabbitmq4 0.11.0-1+b2
ii  libsofia-sip-ua0t64  1.12.11+20110422.1+1e14eea~dfsg-6.1+b1
ii  libsrtp2-1   2.5.0-3+b1
ii  libssl3t64   3.2.1-3
ii  libsystemd0  255.5-1
ii  libusrsctp2  0.9.5.0-2+b1
ii  libwebsockets19t64   4.3.3-1.1
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

Versions of packages janus recommends:
ii  lua-ansicolors  1.0.2-3
ii  lua-json1.3.4-2
ii  ssl-cert1.1.2

Versions of packages janus suggests:
pn  janus-doc
ii  janus-tools  1.1.2-1+b4

- -- Configuration Files:
/etc/janus/janus.plugin.videoroom.jcfg changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZSG1IACgkQA0U5G1Wq
FSF/nhAAvi/zjpRcBgpw3+pARPqleUBecF8uqvtzhiCnvibVuNqlMzkq2lsHhlzG
ihefhzL1WvOpzvMj+AdGqv8HWQHQaDv7MJfJu1vtZiAcIZDFGxSUtvesGZLwqeGf
sarhBWe2Yu462BG8D35Dso5lI281b7BB2G4y/znE2gkDal0L2qNP5Un8MweVYk/x
oW78/+7VEL2fUpF+xn6P6EE2Ev9D4zxuFK8Pgut+l3/KL3nJTya+2slImXbHKdDV
Slq0sDKp3PR8kvokmkPs9ryJknA5kX1a6Yo2SNiGM8gNXTYnPtF1EvK9rD0IYYlN
iDhr7KvBEZjj3Sv+2BzEezgIHr8ZwLQ4iwPz7PUVvSHSeDsAAg6s+SbJUA/JKPYU
fnHqC8K38/f31+y00hbO3yQoKP3tG0l8WBI3cvHr6iXjaMtDcOEFdNhErqzhYp7i
ga3i1VAsQr0K/5pha/5xNpGktQAUXnWQcvcsUtNghzQanXAXSHeLO9/lPMWQ+GLO
ZaKtchEvBdFpe8j6dqGpq/j28FSgKc1zMezNDkYamwSX2LbOObytyZ50Osu1av2f
uot8F0X4i15WNQO6eHPJ4kI7ltr19DE7OQj/ZJ7hn4G5K8/d4p2qw/cwxrj8YhmU
XlLJGPsHWLkIjEz8mPzd8Q0EloggIRL6puE27UrD07qQl/k2ow8=
=P5W5
-END PGP SIGNATURE-

Bug#1071585: libsingular4m3n0t64: SONAME change w/o package rename

[David Bremner]

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#1071538: Acknowledgement (janus-demos: please support some admin customization of settings.js)

[David Bremner]

David Bremner  writes:
>
> The naive thing to do is to symlink to a file in /etc; perhaps there
> is a smarter way to override settings.js? Otherwise it seems the only
> way to use the installed version is editing files in /usr
>

I did a quick proof-of-concept update at

  https://salsa.debian.org/bremner/janus

A simpler fix might be just to add definitions for token and apisecret
to settings.js

var token ="";
var apisecret="";

Bug#1071538: janus-demos: please support some admin customization of settings.js

[David Bremner]

Package: janus-demos
Version: 1.1.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have janus running on the same host as the the browser running the demos.
(and the same host as serving the static files)

After some struggle, I finally diagnosed the reason none of the demos
were running was because one of "token" and "apisecret" were
referenced in the code but not defined in settings.py (indeed the
commented out definitions don't seem to be correct either).

That perhaps deserves it's own bug report, but since README.Debian
says iceServers needs to be defined it seems that there needs to be
some admin customization anyway.

The naive thing to do is to symlink to a file in /etc; perhaps there
is a smarter way to override settings.js? Otherwise it seems the only
way to use the installed version is editing files in /usr


- -- 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 janus-demos depends on:
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-4.1
ii  libjs-bootbox 5.5.3~ds-1
ii  libjs-bootstrap   3.4.1+dfsg-3
ii  libjs-bootswatch  3.3.7+dfsg2-1.1
ii  libjs-janus-gateway   1.1.2-1
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-blockui  2.70-5
ii  libjs-spin.js 1.2.8+dfsg2-1.1
ii  libjs-toastr  2.1.4~ds-5
ii  libjs-webrtc-adapter  8.2.3~ds-1
ii  node-blueimp-md5 [libjs-blueimp-md5]  2.19.0~ds-3

janus-demos recommends no packages.

Versions of packages janus-demos suggests:
ii  janus   1.1.2-1+b4
ii  janus-tools 1.1.2-1+b4
pn  libjs-bootstrap-slider  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmZLp1gACgkQA0U5G1Wq
FSF8Iw//TQc1Mt1sVn9SVXCd0Gwc6KF5WBbGYqqz7iDCoxta7fUhIpD3Esul1UrG
QEM9hSHp5mHBhQH5u0Sr3yO2J9RAFZnwahRjEUSSq+pHqr7xTU4+42eK/KsnNZOd
mXzlSkSkOtkYyo0B9MmIMHHU6j0e8vJg5TCPI/8oh1xW/AX3nHJpXB6gXPHoHdlI
dhmTzS0VLI2tYvDw5cXrLjzW9yPDPPQPFV0YbszbENoUevhPt9Kuwe+xwNGXsiiu
ijKV+jdE+KRPIVnvag5WVGs1yQ2j+tdK2IA72JJdPkOKsMopJQVHJeVYkth+q5NT
OV3fr5NnGzJ3QttghkooJH69lbJTCxxOowELtPSN78+1u193l3/prxVHH/WcjDe4
M5r67KNAU1kd1tKw54T9WwFKnfnRRjW6piCeZC7N6n+mKOWGGLl5go4Au2jtcKJf
ikSTo0MZQlAQiCv64MyDPuXpAidzTn7h5Rw0nYAHp7bOgasPASVE7N13WIYarcBV
iTZP3at62FGQ1rujH4eBMYNFn9nSuaeZ5mCghji3xpZ2dcfQrkhya6FZWKFLpYGT
55fBN1sNYt0WL3sKxtl0/MkVJBz76f895fQ2jzRn9mK/vz/+twQmKHFd3Ox1XC6+
ec5FHyN0UJdSN90liU233IJCWXL3clk5tKi9rHPzOY2UL0lyrEs=
=pSzN
-END PGP SIGNATURE-

Bug#1070405: darktable: Please drop unused Build-Depends: libsoup2.4-dev

[David Bremner]

Jeremy Bícha  writes:

> Source: darktable
> Version: 4.6.1-2
>
> Please drop Build-Depends: libsoup2.4-dev . It isn't used at all and
> we would eventually like to remove libsoup2.4 from Debian.
>
> Thank you,
> Jeremy Bícha

How can I verify that it is not used?

d

Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting

[David Bremner]

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

[David Bremner]

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#1068370: elpa-dpkg-dev-el: Comp warnings due to XEmacs compatible code

[David Bremner]

Xiyue Deng  writes:

>
> Will re-evaluate if XEmacs compatibility would be dropped.
>
> [1] 
> https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b
>

Does the package currently work (somehow?) with XEmacs? At least dh-elpa
byte compilation does not support XEmacs, but I have not tested the
binary package with XEmacs.

d

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)

[David Bremner]

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)

[David Bremner]

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&arch=amd64&ver=4.11-2%2Bb4&stamp=1711743555&raw=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)

[David Bremner]

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

[David Bremner]

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"

[David Bremner]

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#1067539: 4.11-2.1~exp1 does not fix it

[David Bremner]

Joachim Zobel  writes:

> I just ran a pbuilder build of experimental for gap polymaking. The
> error message persists.

The version of flint in unstable has an uncoordinated transition to
SONAME libflint19. As far as I can tell this is from Julien's commit
711f501dec6ed05ac5c6d4b21eb428b5cfc48da3.

There is a certain amount of confusion due to the t64 transition, but I
think there is an RC bug about this already for flint.

In summary I don't think this is a polymake bug. Or at least there is an
RC bug in flint that should probably be fixed first, before we can debug
polymake.

Bug#1067539: Causes FTBFS for gap-polymaking by failing tests 2

[David Bremner]

Joachim Zobel  writes:

> Package: polymake
> Version: 4.11-2
> Severity: important
>
> Hi.
>
> I am seeing FTBFS for my packages gap-polymaking and gap-hapcryst. 
> The error message is
>
>> Can't load '/usr/lib/polymake/perlx/5.38.2/x86_64-linux-gnu-thread-
> multi/auto/Polymake/Ext/Ext.so' for module Polymake::Ext:
> libflint.so.18: cannot open shared object file: No such file or
> directory at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line
> 201.
>
> This is most likely caused by the latest version of libflint beeing
> libflint18t64. The bug is similiar to #1053316, just the library is
> different.

I see the NMUed "t64" version of polymake has not been uploaded to
unstable yet, so I assume that transition is still in progress for
polymake.

Bug#1065597: racket: Inclusion of mzdyn.o in the binary package

[David Bremner]

Rafael Laboissière  writes:

> At any rate, I wonder why the following mzscheme code:
>
>  (begin
>   (require dynext/link)
>   (with-handlers
>(((lambda args #t) (lambda args #f)))
>(for-each (lambda (x) (printf "~a" x))
>  (expand-for-link-variant 
> (current-standard-link-libraries)
>

I'm not sure what will come of it, but I have reported this issue as

https://github.com/racket/cext-lib/issues/4

I haven't marked this Debian bug as forwarded as I believe they are
different bugs.

Bug#1065597: racket: Inclusion of mzdyn.o in the binary package

[David Bremner]

Rafael Laboissière  writes:

>
> However, it does not work because the file mzdyn.o is needed and 
> cannot be found anywhere. Indeed, this file is mentioned in the Racket 
> documentation.[*]
>

My knowledge here is incomplete, and I'd be happy to be corrected, but:

I think that documentation relates to the old "bc" backend of racket.
For most architectures we are using the new "cs" backend (and will
possibly migrate the remaining architectures).  So it may not be
possible to do the same kind of linking as was done with the old
backend.

Bug#1065041: src:racket-mode: fails to migrate to testing for too long: autopkgtest failure

[David Bremner]

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#1064381: ITP: elfkickers -- collection of programs that access and manipulate ELF files

[David Bremner]

Gürkan Myczko  writes:

> On 21.02.2024 12:28, David Bremner wrote:

> Being the universal operating system, these tools are certainly not for 
> normal users
> but more like developers and people in the embedded area.
>

I include developers in people who don't care about the implementation,

> I have found sstrip to squeeze away some more kilobytes from binaries.

A list of the tools with what they do would be more useful.

> Similar like elfutils it will only be interesting to people that want to 
> use it.

Sure, I'm not talking about making it interesting for every user, just
having a description that helps someone in the target audience find the
package and/or know if they want to install it.

Bug#1064381: ITP: elfkickers -- collection of programs that access and manipulate ELF files

[David Bremner]

Gürkan Myczko  writes:
>   This distribution is a collection of programs that are generally
>   unrelated, except in that they all deal with the ELF file format.
>   .
>   The main purpose of these programs is to be illustrative and
>   educational -- to help fellow programmers understand the ELF file
>   format and something of how it works under the Linux platform. For the
>   most part, these programs have limited real-world utility.
>   .
>   With the exception of shared use of the elfrw static library, each
>   program is independent of the others. There is no other shared code
>   between them, and they all take slightly different approaches to
>   handling ELF files.

I question how helpful this description is helpful for users of a
binary distribution like Debian, who are (IMHO) generally more focused
on functionality than studying the implementation of programs.

Bug#682397: darktable: recommend opencl package

[David Bremner]

Tino Mettler via Pkg-phototools-devel
 writes:

>
> This is a general issue that the darktable package can not change.  So
> I propose to close this bug.
>
> Regards,
> Tino

I wonder if having the bug helps people see that there is no point in
filing more bugs on the same topic. I guess we can always leave the next
OpenCL bug open if that occurs.

Bug#1062366: nullmailer: adminaddr should also set From on mails from root@localhost

[David Bremner]

Martin-Éric Racine  writes:
>
> The /etc/nullmailer/adminaddr address should also define the From for
> messages sent BY root, not just TO root, and use it to make nullmailer
> overwrite any outgoing root@defaultdomain message.
>

Hi Martin-Éric;

Just to confirm, this seems like an upstream issue that I should
forward?

d

Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

[David Bremner]

Matthias Geiger  writes:

> * Package name: rust-toml2json
>   Version : 1.3.1
>   Upstream Contact: woodruffw
> * URL : https://github.com/woodruffw/toml2json
> * License : MIT
>   Programming Lang: Rust
>   Description : A very small CLI for converting TOML to JSON
>
> Filing on behalf on bremner. Since src: reserialize provides a toml2json
> binary it would have to be renamed. All its dependencies are in debin
> so this would be easy to package.

I inherited this "wish" from a private upstream project. I'm not sure
it's strictly needed or if I can use the one from "reserialize" with
some work. I did notice some grumbling about reserialize (don't
know/remember the specifics) and that the rust toml2json supports a -p
for pretty-print option, while reserialize apparently does not support
pretty-printing.

Bug#1049313: ledger: Fails to build source after successful build

[David Bremner]

Control: tag -1 help

Lucas Nussbaum  writes:

> This is probably a clear violation of Debian Policy section 4.9 (clean 
> target),
> but this is filed as severity:minor for now, because a discussion on
> debian-devel showed that we might want to revisit the requirement of a working
> 'clean' target.

I'm afraid this class of issues is a low priority for me, but I welcome
contributions if someone else feels motivated.

Bug#1057881: Please drop Felix from Uploaders

[David Bremner]

Felix Lechner  writes:

> Package: nullmailer
> Severity: wishlist
>
> Hi David,
>
> Please remove my name from the list of Uploaders at your convenience.  I
> switched to OpenSMTPd and am not a good contributor anymore.  Thanks!
>
> Kind regards
> Felix

Hi Felix;

Isn't this a duplicate of #1040002 (just closed)?

Confused,

David

Bug#1057732: Acknowledgement (utfcpp: please update to 4.0.1)

[David Bremner]

In case it is not clear, later versions are fine also.

d

Bug#1057732: utfcpp: please update to 4.0.1

[David Bremner]

Source: utfcpp
Version: 3.2.5-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Apologies for the inflated severity, but it looks like utfcpp 3.2.5 is what is 
breaking
the ledger build [1]

[1]: https://github.com/ledger/ledger/issues/2302


- -- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-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-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmVx7vIACgkQA0U5G1Wq
FSHbTA/9HZVMDpb1wvFmzVVnfK1Jm21KAwZUqA8pH8ZhwmbfcDx1NRG0HY2ey9hT
Cf5qDOewnYhfVyifkuFxrQbhrAmuoPzlMWWNAFtw7ngGorwPPl2ApZk1OD0SjTbn
0Lz1hO7gg2nEuKuVrSLr36NYh3JvsMVE8sKOtvq1GX0h8pojDI3BIZp1+XmmFMDS
LQQOnt+5/bWhFerd5sedhLvcl0PTqa8rLWUROYtlIDfTH2o29l7IopL3+Cw76ruy
bIBe4M8mjwkDQfH9INB2Fq+tD+ToGPk2asCk2rx7B0OtZZ4HleXstHdi6urQBaUL
URtyAaHujzPPTPkWrsZg2rG7FUHXL3b0nvRAdVv7rTUP8ErXrBEwnCY1bSBXktTp
hV8OxklLctrpfqIi5oDkajeiaa3I94lEVmIBvRY8bjUn7vx1ZWud0Qd/FVt1BBjB
92Tos0vG0vx+tM5vjN/NDwNueIjiuxS+M5wzzhq5s8h5p9Mgwr5cl5WcgKpFjHEl
wuvr7e6d4WhDj4+MgahBzWOXuYmOcppUkRrINFlxbFuZ50CTBrQ//UeiEL0jBrik
nqV0cnT4qmA5qNZOksOgxIA1obo+bhGUHZu15g+qaaNvXWdpRUbELqiJc363pw7s
u6f32URKUtQrdxhFAV/k8x6LkrdyT7qVz0R4Ow71C5eAu1xMc+s=
=p2HZ
-END PGP SIGNATURE-

Bug#1057472: darktable: diff for NMU version 4.4.2-1.1

[David Bremner]

Boyuan Yang  writes:

> I've prepared an NMU for darktable (versioned as 4.4.2-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

As long as you are prepared to deal with any fallout, go ahead. In any
case I doubt there are very many darktable users on arm64.

> I am disabling the OpenMP support for now on arm64 so that it does not
> block library transitions indefinitely. Currently it blocks the completion
> of libavif transition, and transitively blocks jpeg-xl transition from
> starting, etc. For a full list of blocked transition, check information on
> https://tracker.debian.org/pkg/darktable . I don't think we should delay it
> any longer given that no signs of bug solving is currently visible.

Well, take that up with the gcc maintainer, since that is where the
(fixed upstream) bug is.

Bug#1057313: racket: Please build and install Zuo

[David Bremner]

G. Weinholt  writes:


> I mean, I could easily package Zuo separately. I could do the first
> upload and put the Scheme team as maintainer so anyone who needs to can
> update it. I'm guessing you would still use the copy that comes as part
> of Racket to build Racket, though.
>

Sure, don't let me stand in the way. Maybe when things stabilize we can
eliminate the duplication / embedding.

d

Bug#1057313: racket: Please build and install Zuo

[David Bremner]

"G. Weinholt"  writes:

> Package: racket
> Version: 8.10+dfsg1-2
> Severity: wishlist
> X-Debbugs-Cc: debian-sch...@lists.debian.org
>
> Hello David,
>
> I'm looking at the upcoming Chez Scheme release and I see that it has
> a build-dependency on Zuo :
>
>   "This is a mirror of the Zuo sources in the racket/src/zuo directory of
>   the Racket repository."
>
> Does it seem reasonable to build and install a zuo package from the
> Racket source package? Alternatively, I could package zuo separately
> using the above repository. They haven't tagged any releases though.

I don't really object to adding another binary package if it's just a
matter of listing what files to install. I can't promise to do snapshot
releases between racket releases though, so it depends a bit on the pace
of development (and whether there are any complications like building
with different options).

d

Bug#1056193: is actually a bug, sorry

[David Bremner]

Control: reopen -1
"Debian Bug Tracking System"  writes:

> This is an automatic notification regarding your Bug report
> which was filed against the glusterfs-client package:
>
> Am 18.11.2023 um 17:37 schrieb Xan Charbonnet:

>> I recently upgraded the backup machine to bookworm.  Suddenly I was unable to
>> mount the cluster.  The key error in the logs was:
>>
>> E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our
>> cert at /usr/lib/ssl/glusterfs.pem
>>
[snip]

>
> But if you look in /usr/lib/ssl =>
>
> $ ls -l /usr/lib/ssl/ insgesamt 4 lrwxrwxrwx 1 root root 34 23. Okt 
> 19:52 cert.pem -> /etc/ssl/certs/ca-certificates.crt lrwxrwxrwx 1 root 
> root 14 13. Mär 2012 certs -> /etc/ssl/certs drwxr-xr-x 2 root root 4096 
> 25. Okt 06:25 misc lrwxrwxrwx 1 root root 20 23. Okt 19:52 openssl.cnf 
> -> /etc/ssl/openssl.cnf lrwxrwxrwx 1 root root 16 13. Mär 2012 private 
> -> /etc/ssl/private
>
> So if you use the subdirectories the paths are correct (in /etc)

That's all very well, but glusterd is not looking in a subdirectory of
/usr/lib/ssl it is looking for /usr/lib/ssl/glusterfs.pem, as pointed
out above.

FYI, upstreams docs [1] show gluster looking in /etc/ssl, not in a
subdirectory.

https://docs.gluster.org/en/latest/Administrator-Guide/SSL/

Bug#1056757: ITP: solanum -- simple pomodoro time tracking app for GNOME

[David Bremner]

Jeremy Bícha  writes:
>
> Package Name: solanum
> Version: 5.0.0
> Upstream Author: Christopher Davis
> License: GPL-3+
> Programming Lang: Rust
>
> Description: simple pomodoro time tracking app for GNOME
>  Solanum is a time tracking app using the pomodoro technique.
>  Work in four sessions, with breaks in between each session and
>  one long break after all four.

I note that solanum-ircd is a thing (although not yet in Debian).  I
guess first come first serve for the name, but it does turn out to be
surprisingly generic (at least a scan of github reveals several other
projects with the same name).

d

Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver

[David Bremner]

Timo Röhling  writes:


> More importantly though, all three of PaPILO, SoPlex, and SCIP can 
> potentially be linked against each other. In order to avoid circular 
> dependencies, I came to the conclusion that SCIP should be linked 
> against both PaPILO and SoPlex, PaPILO should probably be linked 
> against SoPlex, and SoPlex should be built standalone.
>
> If you think otherwise, I'd be happy to hear your thoughts.

Based on my limited understanding of what these things do, that makes
sense to me.

Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver

[David Bremner]

Timo Röhling  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Timo Röhling 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> * Package name: soplex
>   Version : 6.0.3
>   Upstream Author : Zuse Institute Berlin (ZIB)
> * URL : https://github.com/scipopt/soplex
> * License : Apache-2, LGPL-2.1+, BSD-3-clause
>   Programming Lang: C, C++
>   Description : sequential object-oriented simplex solver
>
> This package is part of the SCIP Optimization Suite. SoPlex is an optimization
> package for solving linear programming problems (LPs) based on an advanced
> implementation of the primal and dual revised simplex algorithm. It provides
> special support for the exact solution of LPs with rational input data.
>
> The package will be team-maintained under the umbrella of the
> Debian Math Team 
> at https://salsa.debian.org/math-team/soplex

Great, see also

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039923

if you were not aware.

There seems to be no patching needed to get the full scipoptsuite to
build under sid (or even bullseye). I have not carefully examined what
external software is embedded in the source.  There seem to be a few
things under papilo (presolver); I'm not sure if that is used by soplex
or only by scip.

d

Bug#1053316: polymake: Causes FTBFS for gap-polymaking by failing tests

[David Bremner]

Joachim Zobel  writes:

Control: fixed -1 4.11-2

> Package: polymake
> Version: 4.6-5+b2
> Severity: important
>
> Dear Maintainer,
>
> The package polymake causes a FTBFS in its GAP interface package 
> gap-polymaking
> when building for trixie.
>
>> Architecture: x86_64-pc-linux-gnu-default64-kv8
>>
>> testing: /<>/debian/gaproot/pkg/\
>> polymaking/tst/example.tst
>> polymake: upgrading /tmp/gaptempdirKvYo8c/poly1318 from old plain file format
>> polymake:  ERROR: "/usr/share/polymake/perllib/Polymake/Core/CPlusPlus.pm",

I have marked this fixed (for now) in 4.11-2, but I have not followed in
detail enough to know if the fix is permanent or just fluke.

d

Bug#1056381: bbdb3 compilation/installation fails when notmuch is not installed

[David Bremner]

Derek Upham  writes:

>
> I have emacs-snapshot and bbdb3 installed.  Updating emacs-snapshot
> attempts to byte-compile the various Emacs Lisp packages, including
> bbdb3.  The bbdb3 byte-compilation fails for bbdb-notmuch.el.

Can you duplicate the problem without emacs-snapshot? I don't know
offhand why it should depend on emacs-snapshot, but formally
emacs-snapshot isn't a package in Debian, so not supported. Looking at
the hand-rolled install script [1], it looks like you are correct, there is
special code to detect vm and mu4e.


[1]: /usr/lib/emacsen-common/packages/install/bbdb3

Bug#1055989: emacs-gtk: emacs rejects font preference, falls back to "Purisa" font

[David Bremner]

Control: tag -1 confirmed

Christoph Reichenbach  writes:

> * What exactly did you do (or not do) that was effective (or ineffective)?
>
> Executing the following steps:
>
> - (customize-face 'default)
>   - Font Family: setting "Terminus (TTF)"
>   - Font Foundry: setting "PfEd"
>   - Optionally (does not affect outcome):
> - Weight: setting "medium"
> - Disabling any font attributes (inlcuding Weight)
>   - [Apply]
[snip]
> * What was the outcome of this action?
>
> Emacs used the "Purisa" font as default font.  This font has the same Font
> Foundry as "Terminus (TTF)" but is a "Comic Sans"-like special-purpose font
> and unsuitable for normal operations.
>

For me, it is Fantasque Sans Mono, but I agree it is not selecting the correct
font. The selected font seems non-deterministic, possibly state
dependent. After some various choices of Mono font, I ended up with 

Can you duplicate the problem for other fonts?  I tried 4 or 5 other
monospaced fonts and they all seemed to work, at least in a fresh "emacs
-Q".

I observed that choosing some non-existing font name (e.g. FooBar) had
more or less the same effect. So maybe the issue is just that emacs
cannot find "Terminus (TTF)". A wild guess would be the parens in the
name causing the problem.

Apologies if this is covered already in your extensive report.

Bug#1055860: Acknowledgement (elpa-org-contrib: should not bind C-c j)

[David Bremner]

"Debian Bug Tracking System"  writes:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1055860: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055860.
>

The offending file is "org-secretary.el", which rebinds several keys
reserved for users. It seems to have registered "join" as an autoloaded
function from org-secretary.el, which sounds like a pretty bad choice of
name. I think I ran it by mistake when attempting to run #'join-line.

Bug#1055860: elpa-org-contrib: should not bind C-c j

[David Bremner]

Package: elpa-org-contrib
Version: 0.4.2-1
Severity: normal
Tags: upstream

According to (info "(elisp) Key Binding Conventions")

 Don’t define ‘C-c LETTER’ as a key in Lisp programs.  Sequences
 consisting of ‘C-c’ and a letter (either upper or lower case; ASCII
 or non-ASCII) are reserved for users; they are the *only* sequences
 reserved for users, so do not block them.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-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 elpa-org-contrib depends on:
ii  dh-elpa-helper  2.0.17
ii  elpa-org9.6.10+dfsg-1
ii  emacsen-common  3.0.5

Versions of packages elpa-org-contrib recommends:
ii  emacs  1:29.1+1-5
ii  emacs-gtk [emacs]  1:29.1+1-5

elpa-org-contrib suggests no packages.

-- no debconf information

Bug#1055601: darktable: Segfault in first run after system hang

[David Bremner]

Control: tag -1 wontfix

Greg Schmidt  writes:

> Package: darktable
> Version: 4.4.2-1+b1
> Severity: normal
> X-Debbugs-Cc: g...@desk1.attlocal.net
>
> Dear Maintainer,
>
> I was using darktable when my system hung. I had to reboot to recover. After 
> the reboot I started darktable and 
> it segfaulted. A backtrace was created which implicated dlopen. It was 
> attempting to load "libMesaOpenCL.so.1".
> A subsequent start of darktable was normal. 

Hi Greg;

This looks OpenCL related. I don't have a working OpenCL setup, so I
can't help you there (even if the problem was reproducible). If you find
a way to reproduce it, feel free to report a bug to upstream darktable
on github including the output of darktable -d common.

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

[David Bremner]

David Bremner  writes:

> Benjamin Lorenz  writes:
> Dear Benjamin;
>
> Thanks for letting me know. I will try to update the Debian package
> within a week or so.
>
> David

I didn't have a chance to investigate so far, but I am seeing a test
failure with Polymake 4.11 building with Perl 5.36. I will try to build
with 5.38 and report a proper build log.

*** Failed tests ***

/<>/apps/polytope/rules/slack_ideal.rules:29: testcase 1
expected: regular return
 got: EXCEPTION: no more rules available to compute 'GENERATORS

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

[David Bremner]

Benjamin Lorenz  writes:

> we have now managed to work around the perl changes and released 
> polymake version 4.11 which restores compatibility with perl 5.38.
>
> Among various other adjustments the workaround relies on an 
> auto-generated perl source file that was is now copied into the polymake 
> source.
> This means it will almost surely need more changes for future perl 
> releases and we cannot really say if this approach will keep working.
> Right now polymake does work with the latest perl blead and we will be 
> on the lookout for new issues.

Dear Benjamin;

Thanks for letting me know. I will try to update the Debian package
within a week or so.

David

Bug#1054139: file conflict between python3-ledger-dbgsym and ledger-dbgsym

[David Bremner]

Control: tag -1 wontfix

Marcin Owsiany  writes:

> Package: python3-ledger-dbgsym
> Version: 3.3.0-3
> Severity: normal
>
> I got the following error when trying to install ledger-dbgsym while
> python3-ledger-dbgsym is already installed:
>
> Przygotowywanie do rozpakowania pakietu .../ledger-dbgsym_3.3.0-3_amd64.deb 
> ...
> Rozpakowywanie pakietu ledger-dbgsym (3.3.0-3) ...
> dpkg: błąd przetwarzania archiwum 
> /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb (--unpack):
>  próba nadpisania 
> "/usr/lib/debug/.build-id/bb/b9da531167728c34db6adc7a5ace6f0d21a6d2.debug", 
> który istnieje także w pakiecie python3-ledger-dbgsym 3.3.0-3
> Wystąpiły błędy podczas przetwarzania:
>  /var/cache/apt/archives/ledger-dbgsym_3.3.0-3_amd64.deb
>

For future reference, it is better to generate such output with LANG=C

> I guess the packages should conflict with each other?
>

Probably, but since they are automatically generated, I have no idea how
to do that.

Bug#1053661: [Miloš Komarčević] Re: [darktable-org/darktable] imageio: adjust for libavif 1.0.0 API change (PR #15128)

[David Bremner]

--- Begin Message ---
I think we only need the following CMake change on 4.4.x branch, the source 
code changes only apply to 4.6:
```
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index e3eaa697fe..5cb3bf9fd8 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -353,16 +353,22 @@ if(USE_WEBP)
 endif(USE_WEBP)
 
 if (USE_AVIF)
-find_package(libavif 0.8.2 CONFIG)
-if (TARGET avif)
-list(APPEND LIBS avif)
-add_definitions(-DHAVE_LIBAVIF=1)
-list(APPEND SOURCES "imageio/imageio_avif.c")
-set(DT_SUPPORTED_EXTENSIONS ${DT_SUPPORTED_EXTENSIONS} avif CACHE 
INTERNAL "")
+  # no version check in config mode because of major only match policy
+  find_package(libavif CONFIG)
+  if (TARGET avif)
+if(libavif_VERSION VERSION_GREATER_EQUAL 0.8.2)
+  list(APPEND LIBS avif)
+  add_definitions(-DHAVE_LIBAVIF=1)
+  list(APPEND SOURCES "imageio/imageio_avif.c")
+  set(DT_SUPPORTED_EXTENSIONS ${DT_SUPPORTED_EXTENSIONS} avif CACHE 
INTERNAL "")
+else()
+  set(libavif_FOUND NOTFOUND)
 endif()
+  endif()
 endif()
 
 if(USE_HEIF)
+  # no version check in config mode because of exact match policy
   find_package(libheif CONFIG)
   if(NOT TARGET heif)
 find_package(libheif 1.13.0 MODULE)
@@ -373,7 +379,7 @@ if(USE_HEIF)
   add_definitions(-DHAVE_LIBHEIF=1)
   list(APPEND SOURCES "imageio/imageio_heif.c")
   set(DT_SUPPORTED_EXTENSIONS ${DT_SUPPORTED_EXTENSIONS} heif heic hif 
CACHE INTERNAL "")
-  if(NOT TARGET avif)
+  if(NOT libavif_FOUND)
 # libheif can handle avif, too
 set(DT_SUPPORTED_EXTENSIONS ${DT_SUPPORTED_EXTENSIONS} avif CACHE 
INTERNAL "")
   endif()

```
I'll let @TurboGit decide if he wants to commit this to the branch...

P.S. Arch e.g. already patched this in a more minimal way: 
https://gitlab.archlinux.org/archlinux/packaging/packages/darktable/-/commit/9826742182bf9ebf8c8ea3c51f0545a60bcdec23

-- 
Reply to this email directly or view it on GitHub:
https://github.com/darktable-org/darktable/pull/15128#issuecomment-1752830715
You are receiving this because you commented.

Message ID: --- End Message ---

Bug#1053705: dpkg-dev: please use a different word than Maintainer from dpkg-parsechangelog

[David Bremner]

Package: dpkg-dev
Version: 1.22.0
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The use of Maintainer in the output of dpkg-parsechangelog is
confusing, because it suggests that dpkg-parsechangelog is reporting
the Maintainer field from debian/control. I suggest Changed-By for consistency 
with changes files.


- -- Package-specific info:

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/12 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 dpkg-dev depends on:
ii  binutils  2.41-5
ii  bzip2 1.0.8-5+b1
ii  libdpkg-perl  1.22.0
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.36.0-9
ii  tar   1.34+dfsg-1.2
ii  xz-utils  5.4.4-0.1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.10
ii  fakeroot 1.32.1-1
ii  gcc [c-compiler] 4:13.2.0-1
ii  gcc-12 [c-compiler]  12.3.0-9
ii  gcc-13 [c-compiler]  13.2.0-4
ii  gnupg2.2.40-1.1
ii  gpgv 2.2.40-1.1
ii  libalgorithm-merge-perl  0.08-5

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2023.05.26

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmUj3PgACgkQA0U5G1Wq
FSH3Vg/9FPpO2BQXc4poo1KmvBlRuq3jKVBSusG0IvASO7vYkomU3xvIZkPCfArk
fHXOIwsFVsrF0nByyInAL65V9yMAJ8K89J0fJVB88xCoUCWolTFNSfUfyaUGXzIq
/EAD1IUNO4qdM+urpWy0zkjRMz0K5o2mh7PslyvhHep1EuPIPSQpejDGUsic1WKn
booDmq6gUY2vk3zqTSXEusY+Rjxy8OaxNp+q2fLw0z/4Tu4YMPpigwFdkoJYA8LK
EmFpSvaAtNG7wkmr1AxeeziKs3DPGgqZqpjPu/XNy+/18VVSrvBI+qsB3WMVerzF
a+5NoandSh0gjauChMgo9waGS2h3iNMpxRKwM9NBJQX6Aml0KZ4K75ONn1b5hyJa
9Cu3a/V8GGW5xSojqaqTM9rQGfxZDTMvcsOug4InspY8O1vJ334dMVHg0JneUKSB
vMmBbnEvn25CYz5Gz2cu+xtuJCoAzJOMdLlrk9K0RA7fQJ0vmF8pwdOtREiEzDEK
fKl8yrTlfdWjXB9B3DHITskDtthFqbQE+APOnmKfhJXWCjztjNOB+nEF27gj09yv
UP9WU5zyEMvoyVnsEGyaVvrkTys83zay+1M7EdrXcZ/N4P5mDEAyO4UnTrb9caRy
UGgSl+2iKwK4fqfxDQyCrYj8l4/6XrQj2QwNRJ3YgejSptw3tsM=
=qZyc
-END PGP SIGNATURE-

Bug#1053661: darktable: no longer detects libavif

[David Bremner]

Control: tag -1 upstream

Sebastian Ramacher  writes:

> Source: darktable
> Version: 4.4.2-1
> Severity: normal
> X-Debbugs-Cc: sramac...@debian.org
>
> After the rebuild for the libavif transition, darktable is no longer
> built with libavif support:
>

This seems to be work in progress upstream. I don't know if the
following patch(s) apply to 4.4.2, but they claim to fix the issue.

https://github.com/darktable-org/darktable/pull/15128

Bug#1053405: darktable: FTBFS on arm64 (gcc bug?)

[David Bremner]

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#1053316: polymake: Causes FTBFS for gap-polymaking by failing tests

[David Bremner]

Joachim Zobel  writes:

> Package: polymake
> Version: 4.6-5+b2
> Severity: important
>
> Dear Maintainer,
>
> The package polymake causes a FTBFS in its GAP interface package 
> gap-polymaking
> when building for trixie.
>

I'm currently waiting to see what happens with

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042521

before putting much effort into debugging polymake issues.

d

Bug#1053188: darktable removed at each apt full-upgrade

[David Bremner]

David Bremner  writes:

> Control: tag -1 unreproducible
>

Thierry told me off list that the problem went away after an upgrade, so
I'll close the bug for now. Feel free to reopen (ideally with the apt
debugging info above) if the problem resurfaces.

d

Bug#1053188: darktable removed at each apt full-upgrade

[David Bremner]

Control: tag -1 unreproducible

Thierry Dumont  writes:

> Package: darktable
> Version: 4.4.2-1
> Severity: important
> X-Debbugs-Cc: tdumon...@free.fr
>
> Dear Maintainer,
>
> On debian testing:
> * apt update foloweb by apt full-upgrade: package darktable is removed (not
> upraded, but removed).
> * But darktable is always available in packages list, anc can be re-installed
> by typing: apt install darktable.
> * This appeared  on 2023/09/28.

I can't reproduce this. There have been no recent obvious changes to
state of darktable in testing, unless you haven't updated for a month
(it migrated to testing on 2023-08-25).

Your issue might have something to do with your apt configuration.  Here
is the apt debugging hint from the #debian IRC channel.

To diagnose your problem, we need ALL OF THE FOLLOWING information:
1. complete output of your apt-get/apt/aptitude run (including the
command used) 2. output from "apt-cache policy pkg1 pkg2..." for ALL
packages mentioned ANYWHERE in the problem, and 3. "apt-cache
policy".

Ideally run the commands with LANG=C, so that the error messages are in
English. I can read French (well enough for this), but others trying to
read the bug log may not be able to.

d

Bug#1051490: Bug#1051373: libglib2.0-0: 2.77.3-1 breaks Midnight Commander extension file

[David Bremner]

Control: tag -1 + fixed-upstream

Simon McVittie  writes:

> Yes, I think that makes sense: while we're outside freeze, we want
> changes with an impact on dependencies to happen sooner rather than
> later, so that the impact can be found and fixed. Cc'ing the cloned mc
> and notmuch bug reports to make sure the maintainers of those packages
> are aware that this is likely to happen rather sooner in Debian than
> the GLib upstream version number would necessarily indicate.
>

As of 0.38.1 (not yet released), notmuch will pass through those errors
from GLib (at least, hopefully. It's not very convenient to test against
future releases of dependencies).

Bug#1013436: autopkgtest: Building of qemu images fails

[David Bremner]

David Bremner  writes:


>
> This is still happening with 5.30.

FWIW, my command line was

sudo autopkgtest-build-qemu sid autopkgtest-sid-i386 
https://deb.debian.org/debian i386

Bug#1013436: autopkgtest: Building of qemu images fails

[David Bremner]

"Roberto C. Sanchez"  writes:
>
> Attempting to build qemu images fails as follows:
>
> roberto@debian:~$ sudo autopkgtest-build-qemu buster ./autopkgtest-buster.img
> Load spec file /tmp/user/0/tmph19aaviw/vmdb2.yaml
> Exec: ['dpkg', '--print-architecture']
> Exec: ['qemu-img', 'create', '-f', 'raw', './autopkgtest-buster.img.raw', 
> '25G']
> Exec: ['parted', '-s', './autopkgtest-buster.img.raw', 'mklabel', 'msdos']
> Exec: ['parted', '-m', '/home/roberto/autopkgtest-buster.img.raw', 'print']
> Exec: ['parted', '-s', '/home/roberto/autopkgtest-buster.img.raw', '--', 
> 'mkpart', 'primary', 'ext2', '0%', '100%']
> Exec: ['parted', '-m', '/home/roberto/autopkgtest-buster.img.raw', 'print']
> Exec: ['kpartx', '-asv', './autopkgtest-buster.img.raw']
> remembering /dev/mapper/loop0p1 as root
> Exec: ['/sbin/mkfs', '-t', 'ext4', '/dev/mapper/loop0p1']
> Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/user/0/tmpllucvne5']
> Exec: ['debootstrap', '--variant', '-', 'buster', '/tmp/user/0/tmpllucvne5', 
> 'http://deb.debian.org/debian']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'apt-get', 'update']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'apt-get', 'update']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'apt-get', '-y', 
> '--no-show-progress', 'install', 'eatmydata']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'eatmydata', 'apt-get', 'update']
> Exec: ['chroot', '/tmp/user/0/tmpllucvne5', 'eatmydata', 'apt-get', '-y', 
> '--no-show-progress', 'install', 'linux-image-amd64', 'ifupdown']
> ERROR:root:Program failed: 100
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/vmdb/app.py", line 220, in 
> run_steps_helper
> method(values, settings, state)
>   File "/usr/lib/python3/dist-packages/vmdb/plugins/apt_plugin.py", line 47, 
> in run
> self.install_packages(mount_point, ["eatmydata"], packages)
>   File "/usr/lib/python3/dist-packages/vmdb/plugins/apt_plugin.py", line 61, 
> in install_packages
> vmdb.runcmd_chroot(
>   File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 64, in 
> runcmd_chroot
> return runcmd(full_argv, *argvs, **kwargs)
>   File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 58, in runcmd
> raise RuncmdError("Program failed: {}".format(p.returncode))
> vmdb.runcmd.RuncmdError: Program failed: 100

This is still happening with 5.30.

Load spec file /tmp/tmp9w769cua/vmdb2.yaml
Exec: ['dpkg', '--print-architecture']
Exec: ['qemu-img', 'create', '-f', 'raw', 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', '25G']
Exec: ['parted', '-s', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'mklabel', 'msdos']
Exec: ['parted', '-m', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'print']
Exec: ['parted', '-s', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'--', 'mkpart', 'primary', 'ext2', '0%', '100%']
Exec: ['parted', '-m', '/home/bremner/var/images/autopkgtest-sid-i386.raw', 
'print']
Exec: ['kpartx', '-asv', '/home/bremner/var/images/autopkgtest-sid-i386.raw']
remembering /dev/mapper/loop0p1 as root
Exec: ['/sbin/mkfs', '-t', 'ext4', '-O', '^large_dir', '-O', 
'^metadata_csum_seed', '/dev/mapper/loop0p1']
Exec: ['blkid', '-c/dev/null', '-ovalue', '-sUUID', '/dev/mapper/loop0p1']
Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmppt5v6frz']
Exec: ['qemu-debootstrap', '--arch', 'i386', '--variant', '-', '--components', 
'main', 'sid', '/tmp/tmppt5v6frz', 'https://deb.debian.org/debian']
ERROR: [Errno 2] No such file or directory: 'qemu-debootstrap'
ERROR: FileNotFoundError(2, 'No such file or directory')
Something went wrong, cleaning up!
Exec: ['zerofree', '-v', '/dev/mapper/loop0p1']
ERROR: [Errno 2] No such file or directory: 'zerofree'
ERROR: FileNotFoundError(2, 'No such file or directory')
Exec: ['kpartx', '-dsv', '/home/bremner/var/images/autopkgtest-sid-i386.raw']
Exec: ['losetup', '--json', '-l', '/dev/loop0']
2023-09-17 11:32:21 INFO Starting vmdb2 version 0.26
2023-09-17 11:32:21 INFO Load spec file /tmp/tmp9w769cua/vmdb2.yaml
2023-09-17 11:32:21 INFO Exec: ['dpkg', '--print-architecture']
2023-09-17 11:32:21 DEBUG STDOUT: amd64

2023-09-17 11:32:21 DEBUG STDERR: 
2023-09-17 11:32:21 INFO Running step: {'mkimg': 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', 'size': '25G'}
2023-09-17 11:32:21 INFO Calling >
2023-09-17 11:32:21 INFO Exec: ['qemu-img', 'create', '-f', 'raw', 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', '25G']
2023-09-17 11:32:21 DEBUG STDOUT: Formatting 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', fmt=raw size=26843545600

2023-09-17 11:32:21 DEBUG STDERR: 
2023-09-17 11:32:21 INFO Calling >
2023-09-17 11:32:21 INFO Running step: {'mklabel': 'msdos', 'device': 
'/home/bremner/var/images/autopkgtest-sid-i386.raw'}
2023-09-17 11:32:21 INFO Calling >
2023-09-17 11:32:21 INFO Exec: ['parted', '-s', 
'/home/bremner/var/images/autopkgtest-sid-i386.raw', 'mklabel', 'msdos']
2023-09-17 11:32:21 DEBUG STDOUT: 
2023-09-17 11:32:21 DEBUG STDERR: 
2023-09-17 11:32:21 INFO C

Bug#1051719: markdown-mode.el produces excessive warnings

[David Bremner]

Nicholas D Steeves  writes:
>
> David, do you think you'll be able to find time for this or do you want me
> to come back to it in a week or so?

I'm not likely to look at it soon, go ahead.

d

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

Lev Lamberov  writes:

>> elpa-hl-todo has a versioned depends which is wrong.
>
> It is not wrong. It is as it is stated in the code, and as it is
> detected by dh-elpa.
>
> Personally, I don't see any problem here. The hl-todo-el package is just
> waiting for the latest upstream version of complat-el. There's no hurry
> to make its way into testing right now. From my point of view there is
> only a wishlist bug requesting the latest upstream version of compat-el
> to be uploaded into unstable.

Yeah, I see what you mean, but the versioned depends is unsatisfiable in
unstable, so it doesn't make sense to upload the package to unstable,
unless there is something weird like a circular dependency. 

I don't think it's OK for packages in unstable to be uninstallable in
unstable. It certainly meets the textbook definition of a release
critical bug, since nobody can actually use the package.

What I don't really understand why this bug was not filed on elpa-hl-todo .

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

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

[David Bremner]

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#1041702: git-email: crashes when returning from "edit"

[David Bremner]

David Bremner  writes:

> David Bremner  writes:
>
>> Oh, and I am now seeing it with --compose, neither --annotate nor 'e' is
>> involved (cf. my original report).
>>
>> Bumping the severity as I am completely blocked from my normal
>> git-send-email workflow on this machine.
>
> prompted by Kibi on IRC, I observed that installing
> libterm-readline-perl-perl and removing libterm-readline-gnu-perl
> leads to
>
>   Cannot create second readline interface, falling back to dumb.
>   Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):
>
> this "dumb" seems to succeed.

And removing libterm-readline-perl-perl causes the warning messages to
go away. So maybe most people don't have these problems because they
don't have libterm-readline-*-perl installed.

Bug#1041702: git-email: crashes when returning from "edit"

[David Bremner]

David Bremner  writes:

> Oh, and I am now seeing it with --compose, neither --annotate nor 'e' is
> involved (cf. my original report).
>
> Bumping the severity as I am completely blocked from my normal
> git-send-email workflow on this machine.

prompted by Kibi on IRC, I observed that installing
libterm-readline-perl-perl and removing libterm-readline-gnu-perl
leads to

  Cannot create second readline interface, falling back to dumb.
  Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):

this "dumb" seems to succeed.

Bug#1041702: git-email: crashes when returning from "edit"

[David Bremner]

Sven Joachim  writes:

>
> For me this seems to happen whenever I do not give an email address via
> the "--to" option.  In this case, "git send-email" prompts
>
> "To whom should the emails be sent (if anyone)?"
>
> but no matter what I type, I get the exact same error as you.
>

Hmm. I am seeing it when prompted for an 8bit encoding. I guess the
common theme is prompting.

Bug#699001: elpa-notmuch should depend on notmuch

[David Bremner]

Benjamin Moody  writes:

> Package: elpa-notmuch
> Version: 0.31.4-2
> Followup-For: Bug #699001
>
> Dear Maintainer,
>
> The notmuch-emacs package has been replaced with elpa-notmuch.
> However, this bug still seems relevant; M-x notmuch doesn't work if
> notmuch isn't installed.  elpa-notmuch should at least have a
> "Recommends: notmuch", or more likely a "Depends".
>
> I have no idea whether the version coupling issue is still relevant.

Recommends seems reasonable to me. Depends is too strong because it is
possible (and more or less sensible) to use elpa-notmuch without a local
notmuch install.

Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates

[David Bremner]

Manphiz  writes:

>
> Hi sten,
>
> When trying to pick a new upstream to rebase, I found that pulling
> either upstream repo will result in an incompatible git history versus
> the current debian/master branch on salsa.  I wonder how I should handle
> this?  Is it OK to force push to master?  Will it affect existing
> annotated tags?

Please don't force push the public history. There are various ways to
"fake merge" that are preferable.

Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)

[David Bremner]

Manphiz  writes:

> Hmm, indeed I cannot reproduce this with "emacs -Q" either.  Will see
> what could have caused this.  Any tips on debugging?

The only thing I can think of is to bisect the packages you have enabled/loaded.

Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)

[David Bremner]

Control: tag -1 unreproducible

Xiyue Deng  writes:

> Package: elpa-debian-el
> Version: 37.10
> Severity: normal
> X-Debbugs-Cc: none, Xiyue Deng 
>
> I've encountered an error when using "M-x debian-bug" on certain binary
> package, such as linux-image-6.4.0-3-amd64.  The error backtrace look
> like this:
>

I can't duplicate this in testing. Maybe try with a minimal config to
isolate some interaction with other addons?

d

Bug#1050577: emacs: please limit number of native-compilation workers

[David Bremner]

Package: emacs
Version: 1:29.1+1-2
Severity: wishlist

native-comp-async-jobs-number is a variable defined in ‘comp.el’.

Its value is 0

Default number of subprocesses used for async native compilation.
Value of zero means to use half the number of the CPU’s execution units,
or one if there’s just one execution unit.

I think the upstream default is too aggressive, and we should set it
to a smaller number to reduce the "fork bomb" like behaviour of
spawning NUM_PHYSICAL_CORES worker processes for each user created
emacs process. This particularly manifests itself if the user is
running more than one emacs process. As an example, prior to patching
the notmuch test suite, I got 200 native compilation processes on my
desktop.

Upstream may be correct that "one emacs process per machine" is the
most common scenario, but the bad outcome of having the limit too
small seems better than the bad outcome of having it too high.  People
do use emacs in lots of other scenarios (e.g. servers and automated
processes), and expecting them all to customize their emacs to avoid a
performance / UX regression seems unkind.  AFAICT since the native
compilation is asynchronous, there is no obvious pause by queuing the
compilation jobs.


-- System Information: Debian Release: trixie/sid APT prefers testing
APT policy: (500, 'testing') Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 depends on:
ii  emacs-gtk  1:29.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1050377: ikiwiki: highlight plugin broken with highlight 4.x

[David Bremner]

z/ShWDF9O
sSOKCB9+6a7T6tT/rVxTBseWxshoAeXlt5t4AXGlOxMFMlb46tY=
=1/bp
-END PGP SIGNATURE-
From: David Bremner 
Date: Wed, 23 Aug 2023 14:54:34 -0300
Subject: Migrate highlight plugin to highlight 4.0

Highlight upstream has changed the API as of highlight 4.0
---
 IkiWiki/Plugin/highlight.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IkiWiki/Plugin/highlight.pm b/IkiWiki/Plugin/highlight.pm
index 04c554a..e70817b 100644
--- a/IkiWiki/Plugin/highlight.pm
+++ b/IkiWiki/Plugin/highlight.pm
@@ -54,7 +54,7 @@ sub checkconfig () {
eval q{use highlight};
if (highlight::DataDir->can('new')) {
$data_dir=new highlight::DataDir();
-   $data_dir->searchDataDir("");
+   $data_dir->initSearchDirectories("");
} else {
$data_dir=undef;
}

Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader

[David Bremner]

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#1050349: libimath-dev: CMake fails because of missing python bindings

[David Bremner]

Package: libimath-dev
Version: 3.1.9-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I was trying to update darktable, which uses libimath, and got the
following build failure (which went away when I added python3-imath to
the build-depends). It seems like a bug in the the CMake files for imath? 

- --

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Imath/ImathTargets.cmake:115 
(message):
  The imported target "Imath::PyImath_Python3_11" references the file

 "/usr/lib/x86_64-linux-gnu/libPyImath_Python3_11-3_1.so.29.8.0"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/x86_64-linux-gnu/cmake/Imath/ImathTargets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/Imath/ImathConfig.cmake:40 (include)
  src/CMakeLists.txt:311 (find_package)


- -- Configuring incomplete, errors occurred!
cd obj-x86_64-linux-gnu && tail -v -n \+0 CMakeCache.txt




- -- 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

Versions of packages libimath-dev depends on:
ii  libimath-3-1-29  3.1.9-2

libimath-dev recommends no packages.

libimath-dev suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmTiIkAACgkQA0U5G1Wq
FSGAxA//f8ZspvLPnSGZcgTsuYO0GJLSY/l6i7HmHh7VPsksZYJhLD91hAKrDX3u
Lpyh0Bf8YtZ1Ue+8W/Bq/dqRtro6wbxXayRUKJeKVuQwjbeqmlM3nJ5RfSzJroe7
7WkIThGRITMMmocAtCI8shjyEAJlFH0fbk9jeRA7f3djiyj0jB6E/PwB+N4FosUA
WIwITZv5fpwYM4jJHSvUNFvbs0WYcnyO6Te2PJDjAodOk+UCcfSagc0lWvbXsDrv
BGz747JY9dimI9UVGaaaRk4u7p2y5EStbDpq/vmgWudz/aV9Gyp204uDnYkKmXDM
vgy2+Ub7BNy63+/+breS/2iTl3mWUOYG6+nV1AH1dj1IOnK11YPGfcrUpFgB4OTK
mJqIICEv/dgLrxy6TJfFrUSgAYjnQViHvPvjgi2t/HJW4hVMoqvDhrczd29MXv2q
8xvD0sj7tHKLTaMFP5l51kVrHSOCEx/bhJvOQ1z4FkgVZpFjs0tY1WDJ8N0qruwy
vOAEH2O1qTRcWvCHzY5hFiWBLT+HfIVd/DBk1JQ7FT9Qv/gv+cOfL+9Q6UNY81j2
xS1mC3JLx+nc+YXGXl4LfN/YRUbYeD4JRpin5eQIOVO6VLg61+lo4NIliRqXhaNO
s+hQAlwgg/+SLLFL+HPvh/uBq4JeIZBvSqjkxKSdreHagvnf0E4=
=cbqu
-END PGP SIGNATURE-

Bug#1043242: highlight: new upstream version

[David Bremner]

Unit 193  writes:
>
> Actually at the time of this writing, 4.7 is the current release.  I had 
> gone ahead and jumped to the latest version a while ago, mainly to unify 
> my system on one Lua version, and I've attached the debdiff (debian/ only) 
> to this message.
>

Hi all;

I've orphaned the package [1] and created a gbp style repo in the debian
group on salsa. If some team or group decides to maintain highlight I
may rejoin in the future, but for now I decided to get out of the way.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022114

Bug#1022114: RFH: highlight -- Universal source code to formatted text converter

[David Bremner]

Control: retitle -1 O: highlight -- Universal source code to formatted text 
converter

Sorry I didn't manage to help you help me with the package. I have
orphaned the package and moved the git repo to the debian group so that
my inactivity won't be a blocker anymore for updating highlight.

d

Bug#1042968: emacs: Gnus unusable after upgrading to Emacs 29

[David Bremner]

Florent Rougon  writes:

> Package: emacs
> Version: 1:29.1+1-2
> Severity: normal
>
> Dear maintainer,
>
> This morning, I performed the following upgrade:
>
> [UPGRADE] emacs:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-bin-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-common-non-dfsg:amd64 1:28.2+1-2 -> 1:29.1+1-1
> [UPGRADE] emacs-el:amd64 1:28.2+1-16 -> 1:29.1+1-2
> [UPGRADE] emacs-gtk:amd64 1:28.2+1-16 -> 1:29.1+1-2
>
> and rebooted because the kernel was also upgraded at the same time.
> Since then, Gnus (the version shipped with Emacs) has become unusable
> for me because every time I hit RET in the *Summary* buffer in order to
> read a message, I get the following error:
>
> gnus-configure-frame: Symbol’s value as variable is void: gnus-carpal

Please try to duplicate the problem with "emacs -q". I suspect there is
either some obsolete/broken third party package or just some personal
configuration causing this problem.

I could not find gnus-carpal anywhere in current debian sources aside
from xemacs21-packages. So I guess checking if some xemacs21 things are
also installed would be worthwhile.

Thanks!

David

Bug#1024695: also debian-ispell

[David Bremner]

Dan Jacobson  writes:

> ⛔ Warning (comp): debian-el.el:90:26: Warning: reference to free variable 
> ‘dired-mode-map’
> ⛔ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of 
> unescaped single quotes (use \= or different quoting)
> ⛔ Warning (comp): debian-ispell.el:420:16: Warning: reference to free 
> variable ‘ispell-program-name’
> ⛔ Warning (comp): debian-ispell.el:427:16: Warning: reference to free 
> variable ‘ispell-dictionary’
> ⛔ Warning (comp): debian-ispell.el:429:11: Warning: assignment to free 
> variable ‘ispell-base-dicts-override-alist’
> ⛔ Warning (comp): debian-ispell.el:437:24: Warning: reference to free 
> variable ‘ispell-base-dicts-override-alist’
> ⛔ Warning (comp): debian-ispell.el:475:9: Warning: reference to free variable 
> ‘ispell-dictionary’
> ⛔ Warning (comp): debian-ispell.el:489:18: Warning: reference to free 
> variable ‘ispell-program-name’

As I'm sure you know, that's a different package, maintained by a
different person.

Bug#1042928: Please include example handler for mailto: URIs

[David Bremner]

Nicholas D Steeves  writes:

> 1. Set Notmuch as the default application for email (or URI handler)
> 2. Navigate to the BTS in a web browser like Firefox
> 3. Find a bug, and click on one of the reply links
> 4. Emacs opens in message-mode rather than notmuch-message-mode

OK, this seems like a completely different bug report :).

Unfortunately also not really one I know much about, as I don't use
Gnome (I assume step 1 above means set default in gnome?).

I guess my first question is if you can duplicate the problem from the
command line. I tried

% notmuch-emacs-mua --hello mailto:brem...@debian.org

It seems to do the right thing. 

Maybe your mailto URLs are more complicated? Anyway, if you can
duplicate the problem without requiring gnome or firefox, that would be
helpful.


d

Bug#1042928: Please include example handler for mailto: URIs

[David Bremner]

Control: severity -1 wishlist

Nicholas D Steeves  writes:

> It would be wonderful if elpa-notmuch provided an example handler for
> mailto: URIs.  Somewhere along the line I seem to have added a custom
> one; however, for some reason it opens message-mode rather than
> notmuch-message-mode.  Consequently, messages are not correctly Fcced,
> and are lost rather than inserted into the correct folder.  Needless
> to say, they're not indexed either.
>
> I'm not sure if I made a dumb mistake, or if this is nontrivial.
>
> I think the dh-examples mechanism should be used, because the user may
> be using emacsclient, or may be using Gnus or some other alternative
> to Message Mode.

I'm not sure exactly what you want, but it doesn't sound debian
specific. I'd imagine that your desired example could be included in the
upstream info / html docs.

Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope

[David Bremner]

Niko Tyni  writes:

>
> There's an upstream discussion at
> https://forum.polymake.org/viewtopic.php?t=1914 which does not look
> promising. Apparently polymake starting with 4.9 explicitly bails out
> for Perl >= 5.37 because Perl internal symbols that polymake was relying
> on are now hidden.
>
> Filing this to at least track the issue. David, any thoughts on this?

I don't have any real technical insight here (this is the first I'm
hearing of the issue).

Certainly if anybody understands the issues involved on the polymake
side, Ewgenij does. Also, pretty clearly we're not going to keep an
extra Perl stack around. It sounds like at least a short term removal
of polymake from Debian testing is likely at this point.

I've CC'ed my main contact on the project just in case Benjamin has
anything to add to the discussion.

David