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)

2024-03-25 Thread 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

2024-03-25 Thread 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"

2024-03-24 Thread 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

2024-03-24 Thread 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

2024-03-23 Thread 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

2024-03-08 Thread 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

2024-03-07 Thread 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

2024-02-29 Thread 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

2024-02-21 Thread 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

2024-02-21 Thread 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

2024-02-19 Thread 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

2024-02-01 Thread 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

2024-01-23 Thread 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

2023-12-11 Thread 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

2023-12-10 Thread 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)

2023-12-07 Thread David Bremner


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

d



Bug#1057732: utfcpp: please update to 4.0.1

2023-12-07 Thread 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

2023-12-05 Thread 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

2023-12-03 Thread 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

2023-12-03 Thread 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

2023-12-02 Thread 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

2023-11-25 Thread 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

2023-11-25 Thread 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

2023-11-24 Thread 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

2023-11-22 Thread 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

2023-11-22 Thread 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

2023-11-16 Thread 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)

2023-11-13 Thread 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

2023-11-12 Thread 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

2023-11-08 Thread 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

2023-11-08 Thread 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

2023-11-08 Thread 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

2023-10-18 Thread 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)

2023-10-09 Thread 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

2023-10-09 Thread 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

2023-10-09 Thread 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?)

2023-10-03 Thread 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

2023-10-01 Thread 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

2023-09-30 Thread 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

2023-09-29 Thread 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

2023-09-23 Thread 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

2023-09-17 Thread 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

2023-09-17 Thread 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 

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

2023-09-16 Thread 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

2023-09-15 Thread 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

2023-09-15 Thread 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

2023-09-15 Thread 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"

2023-09-15 Thread 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"

2023-09-15 Thread 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"

2023-09-15 Thread 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

2023-09-12 Thread 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

2023-09-09 Thread 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)

2023-09-01 Thread 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)

2023-08-31 Thread 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

2023-08-26 Thread 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

2023-08-23 Thread David Bremner
/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

2023-08-23 Thread 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

2023-08-23 Thread 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

2023-08-09 Thread 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

2023-08-09 Thread 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

2023-08-03 Thread 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

2023-08-03 Thread 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

2023-08-03 Thread 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

2023-08-02 Thread 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

2023-07-30 Thread 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



Bug#1012500: ITP: latte-int -- Lattice point Enumeration

2023-07-29 Thread David Bremner
"Torrance, Douglas"  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Doug Torrance 
> X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@debian.org
>
> * Package name: latte-int
>   Version : 1.7.6
>   Upstream Author : The LattE Team 
> * URL : https://www.math.ucdavis.edu/~latte/software.php
> * License : GPL
>   Programming Lang: C++
>   Description : Lattice point Enumeration

Hi Doug;

Are you still working on this? For what it's worth I started some
packages for my own use at

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



Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

2023-07-24 Thread David Bremner
Richard Lewis  writes:

> On Sun, 23 Jul 2023, 12:34 David Bremner,  wrote:
>
>> Did you start from a clean debootstrap here?  Because I don't see where
>> in your second reproducer the addon packages get installed.
>>
>
> no, i reused the chroot from the "first attempt" reproducer
> A clean recipe, not requiring any 'login' is:
>
> mkdir -p /tmp/bullseye
> cd /tmp/bullseye
> debootstrap bullseye . https://deb.debian.org/debian
> ln -s /tmp/bullseye /var/lib/machines/bullseye

btw, there is no need to use a symlink here (depends on space in /var I guess)

> systemd-nspawn --machine bullseye apt install emacs elpa-helpful

A smaller set of packages is just emacs and elpa-dash.


> sed -i /bullseye/bookworm/ tmp/bullseye/apt/sources.list

There are a couple of typos here, but I get what you meant. Should be
more like

 sed -i s/bullseye/bookworm/ /var/lib/machines/bullseye/etc/apt/sources.list


> systemd-nspawn --machine bullseye apt update
> systemd-nspawn --machine bullseye apt upgrade

I checked that changing this to full-upgrade does not change anything
> # this all works, including upgrading emacs :)

OK, this downgrades the importance of the crash when upgrading emacs in
a chroot, I agree.

As far as the actual bug with failing to clean up, I ran

% systemd-nspawn --machine bullseye /usr/lib/dh-elpa/helper/remove emacs  dash 
2.17.0

and that cleans up the directory

/usr/share/emacs/site-lisp/elpa/dash-2.17.0

so the bug is at some other level of the stack. I guess I will have to
look at the log from the upgrade, but I haven't had a chance to do that yet.



Bug#929265: me too!

2023-07-23 Thread David Bremner


Currently the version of ipopt is too old to be used by SCIP
(https://scipopt.org). 



Bug#1030394: Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

2023-07-23 Thread David Bremner
Richard Lewis  writes:

> I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:
>
> ln -s /tmp/bullseye/ /var/lib/machines
>
> # im sure there is a better way than these two lines
> cp /etc/passwd bullseye/etc/passwd
> cp /etc/shadow bullseye/etc/shadow
>
> systemd-nspawn --ephemeral --boot --machine bullseye
> # (you dont really need --ephemeral of course)
>
> log into the container as root:
> # apt install emacs-gtk
>
> (and say yes to allow the installation to finish)
>
> # ls /usr/share/emacs/site-lisp/elpa
> dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18  loop-1.3
> dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19  s-1.12.0
>
> Shows the 'duplicate' dirs for the old versions of elpa-dash and elpa-helpful
>

Did you start from a clean debootstrap here?  Because I don't see where
in your second reproducer the addon packages get installed.



Bug#1040690: reproducer(s)

2023-07-23 Thread David Bremner
Richard Lewis  writes:

> I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:
>

Not sure what you mean here. The reproducer using chroot you posted
works fine for me, it's just that AFAICT the real bug is the emacs
upgrade failing (and more precisely, in emacs being unable to run a
simple batch-byte-compile command after the new version is installed),
nothing to do with addon packages.



Bug#1039923: Acknowledgement (RFP: scip -- linear and nonlinear mixed integer optimization suite)

2023-07-22 Thread 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: 1039923: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039923.

I started some packages for my own use at

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

The packaging is currently not suitable for upload (aka RC buggy), but
it does solve a few of the initial technical problems.



Bug#1030394: Bug#1040690: reassign bug to correct package

2023-07-22 Thread David Bremner
David Bremner  writes:

>>
>> chroot . apt install emacs elpa-helpful

Try the same set of steps without elpa-helpful, and the upgrade still
fails with

Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-s
tartup.el: File error (("Doing chmod" "Operation not supported"
 "/usr/share/emacs/site-lisp/debian-startup.elc90iTVh"))

At this point dh-elpa is not involved. It seems most likely to be an
Emacs 28 bug, but I guess it could also be an issue with
emacsen-common.



Bug#1030394: Bug#1040690: reassign bug to correct package

2023-07-22 Thread David Bremner
Richard Lewis  writes:

> An attempt to reproduce - partially successful, maybe reveals deeper issues!
>
> su -
> mkdir /tmp/bullseye
> cd /tmp/bullseye
> debootstrap bullseye . https://deb.debian.org/debian
>
> chroot . apt install emacs elpa-helpful
>
> sed -i s/bullseye/bookworm/ ./etc/apt/sources.list
> chroot . apt update
> chroot . apt upgrade

Thanks Richard that does seem like progress.

I chrooted into to "bullseye" after the upgrade failure, and narrowed
the failing command down to

$ emacs --quick --batch -l package --eval "(setq package-user-dir 
\"/nonexistent\")" --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -f 
batch-byte-compile *.el

I'm not sure why that command should be be failing, certainly I can
chmod the file manually (as root).



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

2023-07-22 Thread David Bremner
Package: git-email
Version: 1:2.40.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I can send patches OK, and if I pass --annotate, I can also edit them
before sending. If I fail to pass --annotate, but rather type 'e' for
edit, then on returning from the text editor (emacsclient, if it
matters), I get

Can't locate object method "IN" via package "FakeTerm" at 
/usr/lib/git-core/git-send-email line 962.

and the script exits.

- -- 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 git-email depends on:
ii  git  1:2.40.1-1

Versions of packages git-email recommends:
ii  libauthen-sasl-perl2.1600-3
ii  libemail-valid-perl1.203-1
ii  libio-socket-ssl-perl  2.083-1
ii  libmailtools-perl  2.21-2
ii  libnet-smtp-ssl-perl   1.04-2
ii  perl   5.36.0-7

Versions of packages git-email suggests:
pn  git-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmS7zp8ACgkQA0U5G1Wq
FSFq7RAAoyPd6fekwpEZ9ifyy+c64uhNMVEDBqAmvA/qCniFZmquXQEvMfpp9pUA
8H3qZukmpzUxsXpbjDb1pnn/bDJSdRsHSSjS8f/P7SgD4bQgP8NOmx9lCjDLvo4f
IctgVDyPslo1IDhrwXgBfhAida23dea5y6fy86E5Z4d/WXMYvJ3Xp3t1DCP09KAT
6LK7vKlXYH4pdCSwTR7v2YC1LmJOkeBcHoHQwBef24WmLxpK5iwGzWPYI5xZJVHF
RV8fboVlvjBAvYMSurr0rHuBMealoQoL4gEa6ARWcTzFEls4c1gRuxRltPxXCJWu
07Z+bLT/z5goB8I4hNJ945jl17FRy96xj32j6/8mfsK72JzwpJD1hTg1HzUWiEoq
v35DO3v3znpQOOSLopS5QyrEuqB6hiLuvdhWJnlRNvYKRYnD2PzDEC+n7tzPJNRJ
bgrebnGyCLFl63PhOXxWJ5/ap4gYA30ZqqRaTNJMSznU1J2fNQlLLguaUTY4OFoO
Nrz8oaMXzJcIMq0j7logbg61hUTHBWSHT1Ea3arcvlM9UXIMOVauw6SR0h3u0whE
8xB0s02tefKbMPJP72sDBWKrhXQd54MrRv0nbvVLmidmWJLf4VX1Cmbpmncmkpqd
OA1I3+XeSsnB5ymlQU8pwWS1XJmjzF4glHluvvjlGAaeOfY/8EI=
=XQ9n
-END PGP SIGNATURE-



Bug#1041525: ITP: arcos-desktop -- The ArcOS Project

2023-07-20 Thread David Bremner
Izaak Kuipers  writes:

> ArcOS is an Operating System Environment built using web technologies. It uses
> svelte, making it easy to maintain and blazingly fast. For more information
> about the ArcOS project, be sure to check out the website. The ArcOS team is
> also ready to talk to you through our Discord server!

Since you currently only supply windows MSI installers, perhaps you can
fill us in a bit on how you plan to package ArcOS for Debian. Perhaps
more importantly, maybe you can explain what advantage being shipped
with Debian will provide for users; what kind of OS integration is
possible, and why would installing via debian be better than installing
a package from your site as is currently done for Windows.



Bug#923908: new upstream version available (9.2)

2023-07-18 Thread David Bremner
Bastien  writes:

> Hi Nicholas,
>
> thanks for your answer.
>
> Nicholas D Steeves  writes:
>
>> Thank you for the notification, and sorry for the unfortunate state of
>> Org mode in Debian 12 (bookworm).  A variety of factors intersected to
>> generate this outcome, and I wish we, as a team, had been able to do
>> better.
>
> No problem at all.  While I'm at it: any idea on how many persons are
> using the Debian Org package? I suspect there are less and less users,
> because Org comes with Emacs and is easily installable as an Emacs
> package, but perhaps I'm wrong.
>

In the end the state of org-mode in bookworm is fine: users get the
version from emacs as the separate elpa-org package is a dummy package.

It is hard to know what popcon numbers mean in absolute terms, but the
number of installs is overall trending upward:

   
https://qa.debian.org/popcon-graph.php?packages=elpa-org_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1

The question whether it is worth packaging org in Debian is essentially
the same as for any other package in GNU ELPA. Some users prefer a more
"upstream" approach as it generally gives newer software, while others
find value in the integration and testing provided by Debian.



Bug#1040787: dh-elpa: Lots of missing eln files

2023-07-16 Thread David Bremner
Aymeric Agon-Rambosson  writes:

> I would say that any directory in /usr/share/emacs/site-lisp/elpa 
> that has no namesake in /usr/share/emacs/site-lisp/elpa-src, AND 
> that is not provided itself by a package, should not be 
> there. Sean, does that seem right to you, or is that too violent a 
> predicate ?

Sounds about right. You could look for .elc files alongside broken
symlinks to the corresponding .el file

d



Bug#1041271: maildir-utils: public shared library shipped in maildir-utils binary package

2023-07-16 Thread David Bremner
Package: maildir-utils
Version: 1.8.14-2
Severity: serious
Justification: violates policy 8.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I think that libguile-mu.* need to be either moved to a private
directory or to their own packages. I don't know enough about guile to
say which is better.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages maildir-utils depends on:
ii  guile-3.0-libs  3.0.8-2
ii  libc6   2.37-3
ii  libgcc-s1   13.1.0-6
ii  libglib2.0-02.74.6-2
ii  libgmime-3.0-0  3.2.13+dfsg-2
ii  libreadline88.2-1.3
ii  libstdc++6  13.1.0-6
ii  libxapian30 1.4.22-1

maildir-utils recommends no packages.

maildir-utils suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmS0If4ACgkQA0U5G1Wq
FSFdlw//drvAFftKxrrn1Hk+A1wYL0ATPOgwI/61u3sC4P/uQRcTbC6zfJcO/uca
GJVFWaUHIFsmPr3lwQf6KkZweBtdnm38MXsXbxw7uBH5abEKoLPZCEr0FzArfZe/
CaPFMHgCl6/k25BNigIXUcx5rgvoLCjRYrh8RVvrIN/NWfEioYDYqYs4+ZEmswP3
fMOdoqfohtXlisfKrrI/ysK00gJpI0vWYJzdEcapirDy7eMtSBXOqjUz2a3kGJ/h
Oxtg1J1GCSp/pAb3lJvAojxITQI69ZAkX2T6xGqXUhGbRCKjVUulovI0iSQGbwM4
mKDMs5oH6kn8gM9z/HTUpoxhLE85KbMQjtsTx6MoXXZKPat02ipzloc3NqWQyBDj
pL8BEpnU6Hc0MtZLI6Q+gUG1akq5BmB24pKxrcEfAVRSdFXbOjfGIHjyH6achfcn
QwOz6R5kNte4VLfCOvWXhnsDvCeiOfePC/gaVqvvzJR5/iWMovDOdBTshK9uXWkl
3hgwYqRIYRtnKobz8QcOnqTbVxFiJv8gyaOm7cbhzKGfWeMFwv38mhmJXaRj7Znv
zb8MqG2eK89v8ZkD7RxsfVVOGOU94102QwlmQ6QOuB4etVyfuUkjjnRsjJgwSRE1
TtlYcHfIj8M2EgMPWEB2mjcFb/TKlx48+Br53YNk3z6mErYJtZk=
=HGuU
-END PGP SIGNATURE-



Bug#1037765: maildir-utils: ftbfs with GCC-13

2023-07-15 Thread David Bremner
Matthias Klose  writes:

> Package: src:maildir-utils
> Version: 1.8.14-1
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
>
> [This bug is targeted to the upcoming trixie release]
>
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.

I suspect we should probably move to a new upstream version rather than
adding yet another patch. However, if for some reason we want to stay
with 1.8.14, it looks like this specific issue is fixed by upstream
commit

   ce9446465260bd108bcf554cf503f72304f4276b

I attach a version with conflicts resolved (although I don't know the
codebase well enough to say if my resolution is correct). With that
patch the code builds, but the build still fails with mu4e.info and
mu4e-guile.info not being installed.

dh_missing: warning: usr/share/info/mu-guile.info exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/share/info/mu4e.info exists in debian/tmp but is 
not installed to anywhere 
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed 
(with files per package)
 * dh_elpa: maildir-utils (0), mu4e (25)
 * dh_install: maildir-utils (6), mu4e (0)
 * dh_installdocs: maildir-utils (3), mu4e (0)
 * dh_installman: maildir-utils (0), mu4e (0)


From: =?utf-8?q?Arsen_Arsenovi=C4=87?= 
Date: Sat, 21 Jan 2023 19:39:09 +0100
Subject: mu-error: Add missing  include
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

GCC 13s libstdc++ reduced its dependency on some headers like , so it's
no longer transitively included through various headers.  Include it explicitly.

See also: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes

  ../lib/utils/mu-error.hh:36:26: error: ‘uint32_t’ does not name a type
 36 | static constexpr uint32_t SoftError = 1 << 23;
|  ^~~~
---
 lib/utils/mu-error.hh | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/utils/mu-error.hh b/lib/utils/mu-error.hh
index c67fc5a..d3e2fc4 100644
--- a/lib/utils/mu-error.hh
+++ b/lib/utils/mu-error.hh
@@ -21,8 +21,10 @@
 #define MU_ERROR_HH__
 
 #include 
+#include 
+#include 
+
 #include "mu-utils-format.hh"
-#include "mu-util.h"
 #include 
 
 namespace Mu {
@@ -160,11 +162,18 @@ struct Error final : public std::exception {
 	 * @param err GError** (or NULL)
 	 */
 	void fill_g_error(GError **err) const noexcept{
-		g_set_error(err, MU_ERROR_DOMAIN, static_cast(code_),
+		g_set_error(err, error_quark(), static_cast(code_),
 			"%s", what_.c_str());
 	}
 
 private:
+	static inline GQuark error_quark (void) {
+	static GQuark error_domain = 0;
+	if (G_UNLIKELY(error_domain == 0))
+		error_domain = g_quark_from_static_string("mu-error-quark");
+	return error_domain;
+	}
+
 	const Code  code_;
 	std::string what_;
 };


Bug#1040973: RFP: haunt -- static site generator written in Guile Scheme

2023-07-13 Thread David Bremner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: vagr...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: haunt
  Version : 0.3.0
  Upstream Contact: David Thompson 
* URL : https://git.dthompson.us/haunt.git
* License : GPL3+
  Programming Lang: guile (scheme)
  Description : static site generator written in Guile Scheme

  - Easy blog and Atom/RSS feed generation
  - Supports any markup language that can be parsed to SXML
  - Simple development server
  - Purely functional build process

Looks like dependencies guile-reader and guile-commonmark would also
need packaging.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmSv8O8ACgkQA0U5G1Wq
FSG7rw//Yo9Y7P8jEdP0LuBf8aO4lxVvqb6WR09APZjBffjklu71R7Xe3k4vkq1t
CSwYRg1txPfXIglR0ioZ0sBFtJFusvgWG1C1kihhRidoC2Hf/BcgqVbXuEaiy50+
Gz750qhe6W5RIRftVOigv494Il37J88M56plsH9F0EC+qjyazmcLPN5cihvSZE55
wZSvAOBslsSSrGFOPxLr3F64eUC60iEO9r2VKqYKi5oXlzMDwI6S52CH+lQl36oF
Mpj2Xw0EcFwQeIepMf89aDU5tbAl7UMJCSxgX2WXU+BbklmEq3rlI8131hQCeGRr
W1WKwKLk4MOOnje6ykbD2/qxDy0xsgBrV0RiI5aXGUcGFhnMLO34BuS1538Sibva
Ke8GHByU3gqJke4yeajG689aM+l9ZT+o7Wk/DXCWygJOZKuAj1jX8OHi+n453WlO
IBMlwTcMZ1RB6LpA55CbQhOqwm45n9ZDRCX3oRWSmQVZcPkXUGnMWPLI8MoW3peC
Ll5HQZ1rcqseKkYGIq7ksrt0KZhOVnYgCQ+6HdscUbG9hLgGPcoQqen9oQ67LAeP
3XcwYOCb2YUw8xH46zn5KDu5p4Cd+n6pu5p+0xEVCMwvLovQzlt3A3fvTSMtPfLo
h4+yRJNvNFINWxikf/MKpNfkkJYqm2F0Q6obbDPCO86QpViKaoA=
=qxnu
-END PGP SIGNATURE-



Bug#1040856: RFP: duppy -- implements both a subset of RFC2136 and offers a simple HTTP API for performing dynamic DNS updates

2023-07-11 Thread David Bremner
Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: duppy
  Version : 2022-06-09
  Upstream Contact: Bjarni R. Einarsson 
* URL : https://github.com/pagekite/duppy
* License : MIT/X
  Programming Lang: python
  Description : implements both a subset of RFC2136 and offers a simple 
HTTP API for performing dynamic DNS updates

The intended audience for this software are DNS service providers who
store customer DNS data in a custom database, using something like
bind's DLZ. Writing some code and/or SQL statements is required.



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmStaZUACgkQA0U5G1Wq
FSGZhhAAtbmV5I2gziZchrGADw/+D2wtKlJyhct2hcM8ZZbb2PGMDAZg3GTf/rOH
l9z01Zlg3ZaxcI3RbXg1Iz1S9Lvob7VVqujBCzuiWOGFm3sC9V/3QjoSF8y/4nat
L53OuQN1Nab/z5cm3XrLyhE09wgiUj9+wBSKSO4aLtCi1HvMj+6XntN1uUnpdoSa
pN8+cfuG0GY3ZcRpI3LJtSG/Q6IyxFRmJu5bmK3Zs5sSWDHy6Py2r/Mua/Bg3+SK
wMcdrIeFPU8PER+n3mkl+Ma1YRnBU8RX/QE9Pyjbg8efuZvR8vlmotkIIdz1fSXv
BC53a4tY9Q4to7eK3IgrGaraXkjvBnltOslgO2ad9YQkOnC8+iWbyQ5zothFm49+
Sx5YkaIQ6fQplKqBUpIjP8v8QpOMe4r6WR1KorgaIh8/vjOjgua4LJXjfFq0tAbs
UPf/U1vuZzsnpv2Vk+S//eeJHtJVTDUm3JLet2CzdSIEGItMCRA9s38Jvi3IXrD5
hhzo1UhVXAu6POxTsU0zY5gk2rVSUktXsX6AECm1YZy7Ck/JppG75/dQceMfsaDA
PY+N3VE59bNS05g6qy0G5o8rXqzvtPAfWCFF/xUv0byIrGT9zl5x5CTVK6sA6t71
dzOyB+Ir8+IMnudEfmeNLub8l8LsL/2VHW5N3ffzNSOAk7iiAlg=
=h+41
-END PGP SIGNATURE-



Bug#1040689: Workaround without init and site file

2023-07-10 Thread David Bremner
Balbir Thomas  writes:

> Thanks to bremner on IRC it was found that
> launching emacs disabling the init and site lisp file
> ("emacs -Q") seems to fix the issue i.e. org-export-dispatch
> does work and and exported file is generated.

I was thinking about this a bit more, and I wonder if the two bugs you
filed are related. In particular I wonder if the problems you are having
with org-mode are related to your having .elc files from an old version
of org-mode still in your file system. Perhaps try removing the
directory /usr/share/emacs/site-lisp/elpa/org-9.4 (or moving it to some
location outside emacs search path, like /tmp).



Bug#1040689: List of emacs related packages installed

2023-07-10 Thread David Bremner
Balbir Thomas  writes:

> As requested I am listing below all Emacs related
> packages installed. These list was generated using
> "dpkg --get-selections" and grepping for "emacs" and
> "elpa".

On IRC you later mentioned you duplicated the problem with a smaller set
of packages installed. It would be helpful to know what precisely the
packages are. Note that emacs-goodies-el is just a dependency package
that brings in a bunch of "elpa-*" packages, so it doesn't really make
sense that (as I thought I understood you say), only the "emacs-*"
packages from the list were installed.

d



Bug#1039972: RFP: soju -- user friendly irc bouncer

2023-06-30 Thread David Bremner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

* Package name: soju
  Version : 0.6.2
  Upstream Contact: Simon Ser 
* URL : https://soju.org
* License : AGPL3
  Programming Lang: golang
  Description : soju

soju is a user-friendly IRC bouncer. soju connects to upstream IRC
servers on behalf of the user to provide extra functionality. soju
supports many features such as multiple users, numerous IRCv3
extensions, chat history playback and detached channels.



Bug#1039923: RFP: scip -- linear and nonlinear mixed integer optimization suite

2023-06-29 Thread David Bremner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-scie...@lists.debian.org, debian-m...@lists.debian.org

* Package name: scip
  Version : 8.0.3
  Upstream Contact: s...@zlib.de (Mailing list)
* URL : https://www.scipopt.org/
* License : Apache 2.0
  Programming Lang: C, C++
  Description : linear and nonlinear mixed integer optimization suite

Upstream writes:

SCIP is currently one of the fastest non-commercial solvers for mixed
integer programming (MIP) and mixed integer nonlinear programming
(MINLP). It is also a framework for constraint integer programming and
branch-cut-and-price. It allows for total control of the solution
process and the access of detailed information down to the guts of the
solver.

SCIP was recently relicensed as free software (Apache 2.0) so it makes sense to 
include it in Debian.



Bug#680619: nullmailer: dpkg-reconfigure corrupts IPv6 zone index in "remotes"

2023-06-28 Thread David Bremner
Jay  writes:

> Pretty sure this also affects passwords with special characters.  I'm not 
> sure what problem the postinst script is trying to solve.

It is transforming this input format

This is a colon-separated list of remote servers to which to send each
message. Each entry contains a remote host name or address followed by
an optional protocol string 'host protocol'. The protocol name defaults
to smtp, and may be followed by command-line arguments for that module.
.
Examples:
.
  smarthost
  smarthost smtp --port=10025
  mail.example.com smtp --user=foo --pass=bar
  192.168.1.254 qmqp 
  [fe80::5054:ff:fef4:ef81] smtp 

Into a syntax compatible with /etc/nullmailer/remotes
(see remotes(5)).

I didn't write that sed snippet, but I guess the intent is to stick to
posix tools to minimized dependencies.

I suspect part of the answer is not to use : as an input separator.
Apparently debconf can handle multiline strings directly using
"debconf-escape", so maybe that can replace the broken sed.



Bug#1033852: racket-mode: autopkgtest regression: Process *Racket REPL* connection broken by remote peer

2023-06-28 Thread David Bremner


Control: reopen -1
Control: found -1 racket-mode/20230425git0-1

> The release team has announced [1] that failing autopkgtest on amd64 and 
> arm64 are considered RC in testing. [Release Team member hat on] Because 
> we're currently in the hard freeze for bookworm, I have marked this bug 
> as bookworm-ignore. Targeted fixes are still welcome.

I missed that the autopkgtests were still failing on arm64.  Although
the failing autopkgtest itself (I guess?) should prevent migration, let
me try to correct the version tracking.



Bug#1039119: darktable: use packaged lua

2023-06-26 Thread David Bremner
roucaries bastien  writes:
>
> Yes in your case i cheched by grepping thé build log. Lua ils compiléd what
> why i set rc severity.

I suspect that you saw a different package with Lua in the name, namely
LuaAutoC. The embedding of that library is a bug, but I'm not sure
there's any practical benefit to filing it since it is not packaged
seperately in Debian, and darktable is afaik the only package using it.

Personally there are higher priority issues with darktable, in
particular the embedding of LibRaw (which is already tracked by it's own
bug iirc).



Bug#1039119: darktable: use packaged lua

2023-06-25 Thread David Bremner
Bastien Roucariès  writes:

> Source: darktable
> Version: Use packaged lua
> Severity: serious
> Justification: embded code copy
>
> Dear Maintainer,
>
> It appear that your package embded and compile lua
>
> Could you:
> - use the packaged lua lib
> - repack in order to avoid accidental reintroduction of compiling lua
>
> rouca

Since upstream already checks for the system lua (unless that changed)
repackaging seems unecessary. Do you have some evidence (build logs ?)
that the build is not using the system lua?

d



Bug#1033852: racket-mode: autopkgtest regression: Process *Racket REPL* connection broken by remote peer

2023-06-24 Thread David Bremner
Paul Gevers  writes:

> Source: racket-mode
> Version: 20210916git0-2
> Severity: serious
> Control: tags -1 bookworm-ignore
> User: debian...@lists.debian.org
> Usertags: regression

This bug should be fixed in testing as soon as the just-uploaded
20230425git0-2 migrates to testing (a few days?). I'm not sure if that
will beat the autoremoval, but perhaps this nudge to the bug will
prevent some disruption for testing users.



Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message

2023-06-21 Thread David Bremner
Andras Korn  writes:

>
> I'm running nullmailer-send via runit. stdout is definitely a pipe (and so is 
> stderr); somewhere it opens /dev/console explicitly.
>

If so, it does so in a somewhat non-obvious way, since the only mention
of /dev/console in the source is in README.Debian. As far as I can tell,
ferr is a buffer object opened on file descriptor 2.

>
>> > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname",
>> > not "/etc/nullmailer/../mailname".
>> 
>> Offhand I don't understand why it doesn't use an absolute path there. Maybe 
>> someone (tm) can change the appropriate line in hostname.cc and test the 
>> result.
>
> Well, that at least is easy. In 
> debian/patches/0005-Provide-for-etc-mailname.patch, you have:

I know where the code is changed, but I'm hoping for more understanding
/ analysis of why it is the way it is, since it long predates my taking
over maintenence.



Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message

2023-06-21 Thread David Bremner
Andras Korn  writes:

> I began using a revision tracking system for some configfiles. This
> involved replacing /etc/nullmailer with a symlink to a directory
> within the local working copy.

I don't know if it's practical for you, but as a workaround etckeeper
works fine with the current nullmailer, since it doesn't use symlinks.

> Also, printing messages to /dev/console isn't terribly useful in the
> case of remote headless servers.

I don't (yet) see what is explicitely opening /dev/console. How are you
starting nullmailer? For example, I would expect systemd to capture
stdout. Although README.Debian mentions /dev/console, this patching to
change upstream's logging is no longer done in the current version of
nullmailer.

> 1. in order to avoid violating the principle of least surprise, don't
> disregard /etc/nullmailer/me. If it's there, the admin put it there
> for a reason.

I would have to go back and read the (ancient) bugs for why this change
was made in the first place. I guess allowing /etc/nullmailer/me to
override /etc/mailname will break some existing configurations.

> 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname",
> not "/etc/nullmailer/../mailname".

Offhand I don't understand why it doesn't use an absolute path
there. Maybe someone (tm) can change the appropriate line in hostname.cc
and test the result.



Bug#1033341: org-mode: CVE-2023-28617

2023-06-04 Thread David Bremner
Salvatore Bonaccorso  writes:

>
> Looking at https://security-tracker.debian.org/tracker/CVE-2023-28617
> I think we should be fine for bookworm already, correct?

Yes, I think what is there makes sense, given the constraints of
expressing a weird situation.

d



Bug#1033341: org-mode: CVE-2023-28617

2023-06-04 Thread David Bremner
Nicholas D Steeves  writes:

> fixed 1033341 org/mode/9.5.2+dfsh-5
> fixed 1033341 org-mode/9.6.6+dfsg-1~exp1
> thanks

Are you sure about that? It depends on emacs 28.2, which afaik has the
vulnerable org-mode embedded. I guess it's a question of interpretation,
but the vulnerability is still there after installing the package.

d


signature.asc
Description: PGP signature


Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

2023-06-01 Thread David Bremner
Paul Gevers  writes:

>
> The debdiff in message #36 looks OK. If the upload happens very soon, as 
> in today, than we'll see if we can have it migrate in time.
>
> Paul

Uploaded and built:

https://buildd.debian.org/status/fetch.php?pkg=org-mode=9.5.2%2Bdfsh-5=all=1685619895

d



Bug#1036550: f3: dead homepage referenced in man page

2023-05-22 Thread David Bremner
Package: f3
Version: 8.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It seems like

   https://oss.digerati.com.br

no longer exists.

Unfortunately the man pages still point people there.


- -- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages f3 depends on:
ii  libc6   2.36-9
ii  libparted2  3.5-3
ii  libudev1252.6-1

f3 recommends no packages.

f3 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmRrTwkACgkQA0U5G1Wq
FSHsww/5AZ6kJ1GFPSf1K9LKK6w8VUdH2370IesFiEbzBvFTjLlmp9aNXC6yetaR
k55FI7hw/fTDC7YvrGz6iT0hdaJSlp6vX8JGwNL3uNXrN9UOKis1oq8bo/UJz7u+
WZn/rLX2Cxg3n5pl8CcfNdbJ8i2+s00LX7STdDxBwxJJ5tJ4eSDOtrwFAQHIUlpd
i3aO52InMoEtWtFis0zNHjyObo0oLKj6bQvDF7cCORU7+AkJGZM1VYr8alXyA4cz
z8eXWRs7EWTVLuxZrvSV0ZNTLsOHbFn1CEfWO1HQsk3zDIV61aiX2zTS4elm5Ol9
B44gOgVvwZAI3jhLsYSZbeoMsMz19+B3px6No2NgGdyTJVJCGyNGJAZ+TV7ZEXTZ
lIWjfvsRPzXXWU9M3bSPOHCriJjgzySyTWNC3eNNgitjI/urVvyK7ier6isRxEV/
qoiNGall9EGzji2fuWV62BgDGE7G+Yb5v/jc+3A7g/SQVURIUmeX1VrLXyEhJlVQ
toLnlR8ahYTKnmzQP9HjnSfV+luz2ErLN9ipriqbFreU3ko6DOrgmCw11kRsNM69
pNeZkrE/r+TJ7IVms9lJkJG9rojNJ4CODs8q3Wqty84fy79gYFwtF7gg2EfopjOl
9fwdSe0aZSj/agXOXRzGgFm0xmHQjqQeCuEX23DDBtGzk04TNB4=
=FXyt
-END PGP SIGNATURE-



Bug#1036551: f3: incorporate more documentation into man pages

2023-05-22 Thread David Bremner
Package: f3
Version: 8.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The f3 man pages are pretty sparse, while the package ships other
documentation as rst. Something like sphinx-doc would make it
relatively easy to include some of README into the man pages.

- -- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages f3 depends on:
ii  libc6   2.36-9
ii  libparted2  3.5-3
ii  libudev1252.6-1

f3 recommends no packages.

f3 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmRrT4cACgkQA0U5G1Wq
FSEUHBAArnaeuWHoPcIhIj2j8j2mKk9LttTd+BTHWdBWF0uEqA/CUHt18dA6qOf8
rN1djmG5+2130qg466Ly8EnMab6B3Hzf0l45ijkaE0NaeCs2druc+LMGsFXiAtZu
xpmKJfOqX2deSxvctru2QhBMoM1EJUhXUIl1ete7ZjXLuN+xx456UEAwzq8h/vX1
znWefa1Qdpqrw+FYssm+E9EnQpvqT5TQDhBRpf+uKeVVWHqRAMKE04327TTosnz3
Q+cq8ZAxntpjikX0oUzbEgiMRPzNMe1e6Cb7UqdK72luK0SU/DBTngtuX9g2/YUC
I2m0HEbSQgXkobOW3V7jVJ00zzX6lkr9ASvTt5ZrI8+3tTWwA6XMHBSkio2doilY
xG2GxCwj/GaKrk5l3GRViR3XddMNMK9Nvl8X1s8pjj6wMudbvX53qRRh3P8wPfEq
cwcv7llm/8r9fLHGAKgZSquV7lUabM8rfHh15+eduv7oNuDIW8l3HDr7vrb+UDVV
+K1cAy9051PCxtx3cwJHvfhUV2zj7Xk2ys6Va3wheo+T7W5f4D89MALiX7Bq4Dhw
TvGD4I30AdY+U6RgxTmpIvkOMZ7w5HLnIF1uZ6mqkDSjjw0dplMfwFK80d24zkaR
+I03fPo7xDZa4DsOe9sg4C4DuqDtF68Jk7t61HJehIQIQ5qsneQ=
=MP18
-END PGP SIGNATURE-



Bug#1036399: piuparts: false positives for unowned files left after purge

2023-05-20 Thread David Bremner
David Bremner  writes:

> David Bremner  writes:
>
>> Package: piuparts
>> Version: 1.1.7
>> Severity: normal
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> The following output from "piuparts -t /var/tmp --apt emacs" (also on 
>> piuparts.debian.org) looks suss to me:
>>
>> 0m43.8s INFO: Warning: Package purging left files on system:
>>   /root/.ssh/ not owned
>>   /var/cache/private/ not owned
>>   /var/lib/private/   not owned
>>   /var/lib/systemd/coredump/  not owned
>>   /var/lib/systemd/pstore/not owned
>>   /var/log/private/   not owned
>
> I just verified that something creates /root/.ssh when I run "apt
> install --no-install-recommends systemd" in a clean chroot.  So that
> part is a bug in some other package (presumably systemd or a
> dependency), not piuparts.

All of these directories are created by configuration in
/usr/lib/tmpfiles.d; in this case by systemd-tmpfiles.



Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

2023-05-20 Thread David Bremner
David Bremner  writes:

> 1m1.2s ERROR: FAIL: Package purging left files on system:
>   /root/.ssh/ not owned
>   /var/cache/private/ not owned
>   /var/lib/private/   not owned
>   /var/lib/systemd/coredump/  not owned
>   /var/lib/systemd/pstore/not owned
>   /var/log/private/   not owned
>

I dove down this rabbit-hole a bit, not enough to figure the ultimate
cause, but enough to notice these files are also because of
"apt install systemd". So no related to org-mode. FWIW, systemd is
pulled in by emacs-gtk.

d



Bug#1036399: piuparts: false positives for unowned files left after purge

2023-05-20 Thread David Bremner
David Bremner  writes:

> Package: piuparts
> Version: 1.1.7
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The following output from "piuparts -t /var/tmp --apt emacs" (also on 
> piuparts.debian.org) looks suss to me:
>
> 0m43.8s INFO: Warning: Package purging left files on system:
>   /root/.ssh/  not owned
>   /var/cache/private/  not owned
>   /var/lib/private/not owned
>   /var/lib/systemd/coredump/   not owned
>   /var/lib/systemd/pstore/ not owned
>   /var/log/private/not owned

I just verified that something creates /root/.ssh when I run "apt
install --no-install-recommends systemd" in a clean chroot.  So that
part is a bug in some other package (presumably systemd or a
dependency), not piuparts.



  1   2   3   4   5   6   7   8   9   10   >