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,

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

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

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

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

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

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

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

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 >

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

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

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 imple

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

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

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

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

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'

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

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

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

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

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,

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

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

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:

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

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

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

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

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 build

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

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

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

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

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

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

Gianfranco Costamagna writes: > Source: darktable > Version: 4.4.2-1 > Severity: serious > forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 > tags: ftbfs > Do you think maybe there should be a debian gcc bug? after all, the distinction you point to is a difference of debian

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

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

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

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

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

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

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

Bug#1013436: autopkgtest: Building of qemu images fails

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

"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',

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

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

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

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

Control: severity -1 important David Bremner writes: > Andreas Beckmann writes: > >> Package: compat-el >> Version: 29.1.4.1-2 >> Severity: serious >> >> elpa-hl-todo/sid is currently uninstallable since it depends on >> elpa-compat (>= 29.1.4.2).

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

Andreas Beckmann writes: > Package: compat-el > Version: 29.1.4.1-2 > Severity: serious > > elpa-hl-todo/sid is currently uninstallable since it depends on > elpa-compat (>= 29.1.4.2). > > > Andreas Maybe it doesn't matter, but I don't think this is a serious bug in compat.el. It's not like a

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

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 o

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

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

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

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

Bug#699001: elpa-notmuch should depend on notmuch

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

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

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

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

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)

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

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

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,

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

6L6gXERCF0ZCLRQWgk7p6sXZzSHqxb4DiigtElITDXpstOUO4XhVfFNl5hGHxXY9 GB3AuLhpJ1724GbbzKB4U9CfHGjJfuiO5wlBKVDHBuG5AHXd6v+GepWZIGonyth1 M0GzXvG7whpqsCnPXnX8PK9E9Wi7dsTOVx/32wGn95xPc76V0kaFYdDz/ShWDF9O sSOKCB9+6a7T6tT/rVxTBseWxshoAeXlt5t4AXGlOxMFMlb46tY= =1/bp -END PGP SIGNATURE- From: David Bremner Date: Wed

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

Source: flycheck Severity: serious Justification: Team decision X-Debbugs-Cc: debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nobody has stepped up to take care of flycheck, and it currently blocks the transition of emacs 29 to testing. - -- System Information:

Bug#1050349: libimath-dev: CMake fails because of missing python bindings

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

Bug#1043242: highlight: new upstream version

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

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

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

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]

Bug#1024695: also debian-ispell

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:

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

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

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

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.

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

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

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

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

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

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 "

Bug#929265: me too!

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

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

Bug#1040690: reproducer(s)

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

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

"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

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

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 pro

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

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/

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

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

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

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

Bug#923908: new upstream version available (9.2)

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

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

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

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

Package: maildir-utils Version: 1.8.14-2 Severity: serious Justification: violates policy 8.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think that libguile-mu.* need to be either moved to a private directory or to their own packages. I don't know enough about guile to say which is

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

Matthias Klose writes: > Package: src:maildir-utils > Version: 1.8.14-1 > Severity: normal > Tags: sid trixie > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-13 > > [This bug is targeted to the upcoming trixie release] > > Please keep this issue open in the bug tracker for the package

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

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

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

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

Bug#1040689: Workaround without init and site file

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

Bug#1040689: List of emacs related packages installed

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

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

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

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

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

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

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

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

Control: reopen -1 Control: found -1 racket-mode/20230425git0-1 > The release team has announced [1] that failing autopkgtest on amd64 and > arm64 are considered RC in testing. [Release Team member hat on] Because > we're currently in the hard freeze for bookworm, I have marked this bug > as

Bug#1039119: darktable: use packaged lua

roucaries bastien writes: > > Yes in your case i cheched by grepping thé build log. Lua ils compiléd what > why i set rc severity. I suspect that you saw a different package with Lua in the name, namely LuaAutoC. The embedding of that library is a bug, but I'm not sure there's any practical

Bug#1039119: darktable: use packaged lua

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

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

Paul Gevers writes: > Source: racket-mode > Version: 20210916git0-2 > Severity: serious > Control: tags -1 bookworm-ignore > User: debian...@lists.debian.org > Usertags: regression This bug should be fixed in testing as soon as the just-uploaded 20230425git0-2 migrates to testing (a few days?).

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

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

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

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

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

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

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

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

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

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

  1   2   3   4   5   6   7   8   9   10   >