Bug#1103659: vcsh: autopkgtest regression on all archs

Dave Hibberd writes: > > Spent an hour or so trying to do some autotools magic to get compilation to a > stage where it won't compile as `ronn` is required. the previous version did not use autotools, so that is at least part of the mystery solved. The autopkgtests were not updated when the ups

Bug#1103659: vcsh: autopkgtest regression on all archs

Chris Hofstaedtler writes: > Source: vcsh > Version: 2.0.10-0.1 > Severity: serious > X-Debbugs-CC: hi...@debian.org > > vcsh 2.0.10-0.1 fails its autopkgtests on all architectures, > preventing migration to testing. Example on amd64: > https://ci.debian.net/packages/v/vcsh/testing/amd64/6017083

Bug#1026785: Intent to NMU gitolite3 to fix longstanding l10n bugs

Helge Kreutzmann writes: > Hello David, > I intend to NMU gitolite3 end of April 2025 to fix open l10n > bugs[1]. The changelog would be something like the following: > > gitolite3 (3.6.12-2.1) UNRELEASED; urgency=medium > > * Non-maintainer upload. > * Update debconf template translation >

Bug#1097768: racket: ftbfs with GCC-15

Control: found -1 8.16+dfsg1-1 Matthias Klose writes: > | void (*)(void) > In file included from ../src/rktio/rktio_process.c:2: > ../src/rktio/rktio_private.h:438:50: note: expected ‘void (*)(int)’ but > argument is of type ‘void (*)(void)’ > 438

Bug#1098664: afew: diff for NMU version 3.0.1.post63-0.1

Santiago Vila writes: > > Please cancel the NMU, as it has a version number higher than the > upload I've just made and it already contains your changes. > Done.

Bug#1098664: afew: diff for NMU version 3.0.1.post63-0.1

Santiago Vila writes: > Hi. > > Thanks for the NMU. The debdiff is a little messy indeed. > > I'm considering to make a proper "team upload" from this > (with attribution of course). > > Would it make a big difference if I put the diff between > old and new tarball as a patch in debian/patches ?

Bug#1098664: afew: diff for NMU version 3.0.1.post63-0.1

Santiago Vila writes: > Maybe what scares me is the number of dgit artifacts. > > At the very minimum, I'd try to make a team upload without them. > > Thanks. Sure, whatever you think is best.

Bug#1098664: afew: diff for NMU version 3.0.1.post63-0.1

pamFilter.py -afew/filters/__init__.py -afew/tests/__init__.py -afew/tests/test_dkimvalidityfilter.py -afew/tests/test_mailmover.py -afew/tests/test_settings.py -afew/tests/test_utils.py -docs/commandline.rst -docs/conf.py -docs/configuration.rst -docs/extending.rst -docs/filters.rst -docs/implement

Bug#1098664: NMUed

Control: tag -1 pending I have NMUed afew to DELAYED/5. Since the required a new upstream version and two patches, the NMUdiff is a bit messy. I pushed my work to https://salsa.debian.org/bremner/afew Let me know if you would like me to reschedule or cancel this upload.

Bug#1098995: notmuch: test suite regressions with fixed GnuPG

Daniel Kahn Gillmor writes: > > Please see the attached patch. > >--dkg > > From 6d7f5791830c6d3e7607812116e63c866f3c587c Mon Sep 17 00:00:00 2001 > From: Daniel Kahn Gillmor > Date: Thu, 27 Feb 2025 13:14:08 -0500 > Subject: [PATCH] Accept "key-missing" from a signature from a revoked k

Bug#1098852: [PATCH] test/emacs: add workaround for Emacs 30 pp changes

Tomi Ollila writes: > On Tue, Feb 25 2025, David Bremner wrote: > >> This relies on the fact that setting pp-default-function has no effect >> for Emacs <30. > > I think this close to a release (and maybe for a while later) this is LGTM. > > Tomi Applied to rele

Bug#1098852: [PATCH] test/emacs: add workaround for Emacs 30 pp changes

This relies on the fact that setting pp-default-function has no effect for Emacs <30. --- test/test-lib.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/test/test-lib.el b/test/test-lib.el index 4cfb8ef1..bf1fab66 100644 --- a/test/test-lib.el +++ b/test/test-lib.el @@ -33,6 +33,9 @@ (

Bug#1092047: notmuch: request tagging a new release

Xiyue Deng writes: > > Also there seems to be duplicated dpkg-dev requirements in > Build-Depends. The one with ">= 1.22.5" was added for the t64 > transition in the NMU 0.38.2-1.1, but it didn't remove the old dpkg-dev > requirement. The second patch consolidates the requirements. The second (

Bug#1098665: mailscripts: please update suggests from python3-notmuch to python3-notmuch2

Sean Whitton writes: > > We added it for the sake of sendmail-reinject, which has the line > "import notmuch2 as notmuch". that's fine, that comes from python3-notmuch2 (so the current suggests is not helpful) > > CCing the author of that script. > > Does this mean we need to drop the script? C

Bug#1098664: afew: python3-notmuch is going away

Package: afew Version: 3.0.1-6 Severity: important Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The legacy python bindings are going away with notmuch 0.39, which will be released soon. I will stop generating the binary package python3-notmuch with the next upload of notmuch (to

Bug#1098665: mailscripts: please update suggests from python3-notmuch to python3-notmuch2

Package: mailscripts Version: 30-1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As far as I could tell in a quick look, the python3-notmuch module is not actually used by the current scripts. In either case, that module will not be packaged generated starting wi

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

Xiyue Deng writes: > > +# Disable adding sub-directories to `load-path' > +for DIR in ${el_dir}/*; do [ -d ${DIR} ] && touch ${DIR}/.nosearch; done I wonder about quoting here. I tend to overquote in shell scripts, but what if some subdirectory has whitespace in the name? > +# Remove entries

Bug#1092530: daemontools: diff for NMU version 1:0.76-13.1

Control: tags 1092530 + patch Control: tags 1092530 + pending Dear maintainer, I've prepared an NMU for daemontools (versioned as 1:0.76-13.1) and uploaded it to DELAYED/5. Please feel free to cancel it if you prefer to fix the bug yourself. Regards. David Bremner diff -Nru daemontools

Bug#1092047: notmuch: request tagging a new release

Xiyue Deng writes: > > It looks like "0.39~rc0" is not supported by Pypa Version specifiers[1]. > "0.39rc0" should work fine. > > [1] https://packaging.python.org/en/latest/specifications/version-specifiers/ Yes, I understood that much. It's a question of needing to adapt the build and release p

Bug#1092047: notmuch: request tagging a new release

b586ba2a7ea7bbac4292dda0dd3 > [4] > https://git.notmuchmail.org/git?p=notmuch;a=commit;h=b526c5ef0e1ae78380e68e5a24170542b884cbe3 I started to tag a pre-release, but encountered the following python induced breakage. !! dist.fetch_build_eggs(dist.setup_requires) Traceback (most recent

Bug#1092530: daemontools: FTBFS: make[2]: *** [Makefile:168: hasshsgr.h] Error 1

Lucas Nussbaum writes: > > This build was done using sbuild from bookworm-backports and the > 'unshare' backend instead of schroot. > This seems backend specific. The package does build (for me) using schroot.

Bug#897140: ITA: geiser -- Generic Emacs/Scheme interaction mode

Xiyue Deng writes: > > Not really plan to remove it from team, as I could use some extra hands > from the team if there were any offering :) Anyway, I've retitled the > bug as ITA and scheduled to close it in the next upload so I hope the > procedure is OK. Yes, it all sounds fine. Hopefully my p

Bug#897140: ITA: geiser -- Generic Emacs/Scheme interaction mode

Xiyue Deng writes: > Recently there was a request to update geiser on IRC, and I'd like to > take this opportunity to adopt and update this package. An RFS has been > filed as Bug#1092829[1]. PTAL. > Do you plan to remove it from the team? Otherwise I'm not sure adoption is strictly needed (bu

Bug#1092000: ecl: use of t64 suffix after SONAME bump

Sebastian Ramacher writes: > Source: ecl > Version: 24.5.10+ds-1 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > The t64 suffix for shared library packages was only necessary for > rebuilds with the time_t 64 ABI without changing SONAME. Now that libecl > bumped its SONAME from 21.2

Bug#1091177: racket-mode: Clarify license of Debian packaging

Xiyue Deng writes: > Source: racket-mode > Version: 20240129git0 > Severity: important > > When working on updating the racket-mode package, I noticed that the > Debian packaging work under "debian/" does not have a separate copyright > clause. This is probably fine. However, upstream has updat

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

Xiyue Deng writes: >> Friendly ping. Would really like to get this in before Trixie so that >> dh-elpa is compatible with upstream ELPA. >> > > Friendly ping. Would really like to make it in before Trixie freeze. Is this an RC bug? because that's about all I have time for at the moment.

Bug#1085959: racket: Racket is unusually slow on aarch64

Humberto Ortiz Zuazaga writes: > $ time /usr/bin/racket -e '(exit)' > >* What was the outcome of this action? > > real3m24.268s > user3m23.567s > sys 0m0.643s > I guess I can sortof confirm this. On the aarch64 porterbox that command takes about 35s. It's notably faster than what

Bug#1084222: elpa-org: can no longer export to beamer

IOhannes m zmölnig (Debian/GNU) writes: > Package: elpa-org > Version: 9.7.11+dfsg-1 > Severity: normal > > Dear Maintainer, > > since i've upgraded elpa-org to 9.7.11+dfsg-1, I can no longer export my > presentations to LaTeX/beamer. > > With the current version, when I try to export my slides (

Bug#1083073: emacs-goodies-el: Use Reccommends instead of Depends to provide more flexibility in choosing packages

Xiyue Deng writes: > Package: emacs-goodies-el > Version: 42.5 > Severity: wishlist > > Hi, > > emacs-goodies-el depends on a list of useful Emacs addons. While most > of them are useful, it is less flexible that a user would have to > install all of them even if some of the packages are not of

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

Xiyue Deng writes: > > Make sense. AIUI rebuild is not necessary for enabling this because > currently there is no package depending on this feature, and before and > after this patch existing package will behave the same. It is only > making a difference when a package has source code in a sub

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

Xiyue Deng writes: > > I have tested running the previously failed tests, e.g. clojure-mode > which uses buttercup and flycheck which uses both buttercup and ERT, and > they are now passing using the new implementation. > Build failures are (relatively) fine. What I really want to avoid is havin

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

Helmut Grohne writes: > Source: cycle-quotes > Severity: serious > Justification: grab attention of maintainer For the record, this "justification" is pretty infuriating, no matter how well thought the rest of the message (which I am now not going to read) might be.

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

Xiyue Deng writes: > Xiyue Deng writes: > >> [[PGP Signed Part:Undecided]] >> Sean Whitton writes: >> >>> Hello Xiyue, >>> >>> On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote: >>> I have prepared a patch at [3] and also attached. Please help review and comment. I'll merge it onc

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

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

Bug#1076296: reset autoremoval clock

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

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

Simon McVittie writes: > I think these are the key facts here. > > Your apt proxy on the host system is probably set to http://127.0.0.1:3142? > > The bug is that a-b-podman auto-detects this, and tries to use the same > proxy inside the container; but the host system's 127.0.0.1 will not be > re

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

Package: autopkgtest Version: 5.38 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 SYMPTOMS: + echo no known network config tool found, skipping network config no known network config tool found, skipping network config + return + echo Acquire::Languages "none"; + echo force-uns

Bug#1077910: notmuch: autopkgtest failure with glib 2.81.1

Control: tag -1 -ftbfs Control: severity -1 important Not that it matters too much, but the original metadata (other than affects) seems copy-pasted from the other bug.

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

Paul Gevers writes: > > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 30 days as having a Release Critical bug in > testing [1]. Your package src:slime has been trying to migrate for 37 > days [2]. Hence, I am filing this bug. The version

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

Source: slime Version: 2:2.30+dfsg-2 Severity: serious Justification: 42 This bug is to prevent slime from migrating to testing before the newer release of sbcl does. -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing

Bug#1077041: segfault in the style editor

Control: tag -1 unreprodicible David Bremner writes: > This may be fixed in the next upload. I'm currently running an > unofficial 4.8.0 package, and I cannot duplicate the problem there. When > we upload 4.8.1, I'll let you know and you can see if you can still > dup

Bug#1077041: segfault in the style editor

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

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

Bernhard Übelacker writes: > Hello David, hello Axel, > > >> I had hoped the expected behaviour might have been the error message 😉 > > Maybe it is the expected behaviour? > > Following is the output of the last not crashing version 1.13 > and the current version in testing 2.2+10~g7ed88a0 with t

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

Bernhard Übelacker writes: > Am 21.06.24 um 01:57 schrieb Bernhard Übelacker: > >> Especially the third point is puzzling, I could not yet see why this >> pointer-content-mixup happens. > > > Hello David, hello Axel, > I did some further tests and found following location where cli_program > is

Bug#1073287: transition: lrslib

Package: release.debian.org Severity: normal X-Debbugs-Cc: lrs...@packages.debian.org Control: affects -1 + src:lrslib User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There is only one build-rdep, that I also maintain. The Ben fil

Bug#1073173: patch

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

Bug#1073173: patch

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

Bug#1073173: polymake: FTBFS with lrslib 0.73

Package: polymake Version: 4.11-2 Severity: important Tags: upstream ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 polymake 4.11 and 4.12 both fail to build because of (apparently) breaking changes in lrslib 0.73 (or maybe they happened in 0.71). Here is a bit of the log from 4.11; the

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

David Bremner writes: > > Attempt #3 > > swaks -t brem...@debian.org --pipe 'valgrind /usr/lib/sendmail -bs' > > This also runs without errors, so I'm out of ideas for the moment. Attempt #4: Rebuild with asan make clean make CXXFLAGS="-g -O1 -fsanitiz

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

Axel Beckert writes: > Hi David, > > David Bremner wrote: >> swaks -t brem...@debian.org --pipe 'gdb -batch -ex run -ex bt --args >> /usr/lib/sendmail -bs' >> >> This actually runs without segfaulting, which made me think it might be >>

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

Control: tag -1 confirmed Axel Beckert writes: > Package: nullmailer > Version: 1:2.2+10~g7ed88a0-5 > Severity: important > Control: found -1 1:2.2-3 > > Dear David, > > I managed to reproducibly crash nullmailer-smtpd with a "general > protection fault" by calling the following command: > >

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

John David Anglin writes: > Source: racket > Version: 8.13+dfsg1-2 > Severity: normal > Tags: ftbfs > > Dear Maintainer, > > Racket build fails here: > running cs/c/ChezScheme/pb/bin/pb/scheme to build > cs/c/ChezScheme/xc-tpb32b/s/cmacros.so > illegal pb instruction > failed > in build-one >

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

In [1], Jakub Wilk observes that the current behaviour is confusing since it looks like there are two mailboxes in From, while in fact there is only one. It seems to me that notmuch should at least quote the display-name part of a mailbox if it has "funny" characters in it, and perhaps always quot

Bug#1071948: nmu: polymake_4.11-2

Package: release.debian.org Severity: normal X-Debbugs-Cc: polym...@packages.debian.org Control: affects -1 + src:polymake User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 nmu polymake_4.11-2 . ANY . unstable . -m "rebuild against libsi

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

Package: janus Version: 1.1.2-1+b4 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The systemd service for janus currently runs janus as root. Does it need to? Upstream seems a bit ambiguous on that point. Both examples I could find (in main.dox) use root, but one has the comment

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

Package: libsingular4m3n0t64 Version: 1:4.4.0+ds-1 Severity: serious Justification: Policy 8.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to policy 8.1 "The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes."

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

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

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

Package: janus-demos Version: 1.1.2-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have janus running on the same host as the the browser running the demos. (and the same host as serving the static files) After some struggle, I finally diagnosed the reason none of the demos

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

Jeremy Bícha writes: > Source: darktable > Version: 4.6.1-2 > > Please drop Build-Depends: libsoup2.4-dev . It isn't used at all and > we would eventually like to remove libsoup2.4 from Debian. > > Thank you, > Jeremy Bícha How can I verify that it is not used? d

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

Control: severity -1 important > Source: racket > Version: 8.12+dfsg1-7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel OK, I figured out why this doesn't show up on the buildd's: they don't bui

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

Control: tag -1 confirmed Lucas Nussbaum writes: > Source: racket > Version: 8.12+dfsg1-7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel > > Hi, > > During a rebuild of all packages in sid, yo

Bug#1068370: elpa-dpkg-dev-el: Comp warnings due to XEmacs compatible code

Xiyue Deng writes: > > Will re-evaluate if XEmacs compatibility would be dropped. > > [1] > https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b > Does the package currently work (somehow?) with XEmacs? At least dh-elpa byte compilation does not su

Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

Sebastian Ramacher writes: > Control: affects -1 src:polymake > [...] > Let's make sure that it is visible for polymake then. Otherwise I'll > file it a third time ;) Thanks, I thought to myself at some point this morning it should have affects, and then, well, I didn't do it. many hands make l

Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

Control: reassign -1 flint Sebastian Ramacher writes: > Source: polymake > Version: 4.11-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=po

Bug#1067363: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)

Control: reassign -1 flint Lucas Nussbaum writes: > Source: polymake > Version: 4.11-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed t

Bug#1067663: org-mode: Org mode 9.6.23 that fixes several critical

Package: org-mode Version: 9.6.10+dfsg-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: debian-emac...@lists.debian.org, Debian Security Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In https://list.orgmode.org/87o7b3eczr@bzg.fr/T/#t, Ihor Rad

Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"

Source: emacs Version: 29.2+1-2 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team , debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to the 29.3 release notes * Changes in Emacs 29.3 Emacs 29.3

Bug#1067539: 4.11-2.1~exp1 does not fix it

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.

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

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 m

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

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

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

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 rel

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

Paul Gevers writes: > Source: racket-mode > Version: 20231222git0-1 > Severity: serious > Control: close -1 20240129git0-1 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > In principle the autopkgtest failure should be fixed with 20240129git0-2 just upl

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

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

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

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 f

Bug#682397: darktable: recommend opencl package

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 alw

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

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

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

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

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

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

Bug#1057881: Please drop Felix from Uploaders

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

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

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

Bug#1057732: utfcpp: please update to 4.0.1

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 Re

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

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

Bug#1057313: racket: Please build and install Zuo

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

Bug#1057313: racket: Please build and install Zuo

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

Bug#1056193: is actually a bug, sorry

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

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

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

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

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 link

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

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

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

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

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

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 off

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

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

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

"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

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

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 res

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

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 seg

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

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

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

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 polym

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

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

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

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

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

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 c

Bug#1053661: darktable: no longer detects libavif

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 upstrea

  1   2   3   4   5   6   7   8   9   10   >