Bug#1065301: Please stop hijacking mailto: by default
Eduard Bloch writes: > I have recently experienced a little discomfort, when my regular click > on some mailto: link in a browser started opening Emacs (which I have > not configured for this purpose and never wanted to use it for Mail). > Instead of my regular mutt-in-terminal. I spoke to someone who was more knowledgeable about the current state of affairs, and they said that applications can't control the priorities with desktop files the way they could with mailcap. So emacs can only say that it provides mailto support (which it does via notmuch, gnus, rmail, etc.), but it can't set itself at a "lower" priority. However, you can specify your own priorities either via your browser's mechanism (settings > general > applications in firefox), or possibly (it sounds like) via overrides provided by a desktop like gnome (if you use it). i.e. while I haven't used gnome in a while, it sounds like they have a "default applications" option under settings. Hope this helps. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1064437: filename on command line gets mangled
Zefram writes: > If it cannot be made to handle arbitrary filenames correctly, then > guile-3.0(1) must at least detect that it can't handle the specified > filename. It must signal an error on any filename it can't handle, and > not use any mangled form of the filename for any purpose. Furthermore, > this limitation must be documented. Hmm, if I don't misunderstand, this doesn't sound like a Debian-specific issue. So if you're comfortable with it, I'd recommend pursuing issues like this upstream at either bug-gu...@gnu.org or guile-de...@gnu.org, since that's where the changes would need to be made. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1050953: emacslient fails to start when -n is specified
Wang Yizhen writes: > I recently noticed a bug for the emacs package in sid. > > > After upgraded to emacs 29.1+1-5, I found that the emacsclient command > is not working. More specifically, the following command hangs emacs in > daemon forever and no emacs frame pops up: Thanks for the report. I just hit the same thing, and figured it out. I think we'll probably have it fixed soon. For reference, it looks like we should be providing flavor-specific emacsclients. Currently the one in emacs-bin-common (the only one) comes from the pgtk build, and when I tried a lucid-built emacsclient with my lucid emacs daemon, the problem went away. So I'm in the process of moving emacsclient from emacs-bin-common to the flavor-specific packages, i.e. emacs-pgtk, emacs-gtk, emacs-lucid, etc. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1050945: guile-3.0: make guile-2.0 guile-2.2 and guile-3.0 installable parallel
Ilari Jääskeläinen writes: > Package: guile-3.0 > Version: 3.0.8-2 > Severity: wishlist Hmm, I think they 2.2 and 3.0 already are, and anything older is no longer supported? Here I have: $ dpkg --status guile-2.2 guile-3.0 | grep Version Version: 2.2.7+1-9 Version: 3.0.8-2 $ guile-2.2 GNU Guile 2.2.7 Copyright (C) 1995-2019 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> $ guile-3.0 GNU Guile 3.0.8 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> Thanks -- Rob Browning
Bug#1040690: emacsen-common analysis for cruft files from elpa-foo packages during apt upgrade
Richard Lewis writes: > the latter - new emacsen-common is present but in state 'unpacked' before > new dh-* is unpackaged I think I may understand what's going on now, and if so, the issue rests on a misunderstanding in emacsen-common about how the maintainerscript states work. We've been discussing some improvements, some more dramatic than others on #debian-emacs, and I've been toying with some of the possibilities. > ( i suspect dpkg triggers should be the answer- should the question be > understood better --- eg it looks like jed does something similar with .sl > files, at least i think it does -- i didnt find any documentation on that > either) Hah, that's one of the approaches I've been toying with for the past few days. If it pans out, I'll likely make a proposal along with changes to debian-emacs-policy in a while. I'd considered triggers a few times in the past, but only recently thought of a way that addresses the issues I'd previously been concerned about. If this does work out, we're also likely to add recompilation of rdepends during add-on package upgrades (i.e. in case "public" macros have changed in incompatible ways). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1050577: emacs: please limit number of native-compilation workers
Sean Whitton writes: > I would be in favour of patching in setting it to 1. It's not a problem > for people to increase it, after all. No objection, fwiw. I could also see adding some DEBIAN_EMACS_DEFAULT_COMPILE_CONCURRENCY variable, or somehthing, if that would be helpful. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1039089: [PATCH 1/1] correct_posix1e_v1_delimiters: provide path for error messages
a...@alum.mit.edu (Aaron M. Ucko) writes: > FWIW, I ran into it too, but reported it downstream, as > https://bugs.debian.org/1039089; the patch LGTM offhand, though I > haven't tested it and presumably no longer have an "organic" test case. > > Thanks for the fix! Oh, overlooked that -- and thanks for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1037030: posix_spawn_file_actions_init(3) missing?
Package: manpages-dev Version: 6.03-2 posix_spawn(3) mentions it, but it doesn't appear to be in manpages-dev. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1036037: unblock: emacs/1:28.2+1-15
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: em...@packages.debian.org Control: affects -1 + src:emacs Please unblock package emacs The only changes are two bug fixes, one for a file conflict with bullseye emacs-bin-common and one for a conflict with older elpa-cider: https://bugs.debian.org/1034941 https://bugs.debian.org/1035781 diff -Nru emacs-28.2+1/debian/changelog emacs-28.2+1/debian/changelog --- emacs-28.2+1/debian/changelog 2023-04-01 22:38:56.0 -0500 +++ emacs-28.2+1/debian/changelog 2023-05-13 15:17:27.0 -0500 @@ -1,3 +1,16 @@ +emacs (1:28.2+1-15) unstable; urgency=medium + + * emacs-common: add breaks/replaces emacs-bin-common (<< 1:28) since the +emacs.service file moved from emacs-bin-common to emacs-common. +Thanks to Helmut Grohne for reporting the problem and Andreas Beckmann +for providing and testing the fix. (Closes: 1034941) + + * emacs-common: add breaks elpa-cider (<< 0.19.0+dfsg-4~). Thanks to +Andreas Beckmann for reporting the problem and providing and testing +the fix. (Closes: 1035781) + + -- Rob Browning Sat, 13 May 2023 15:17:27 -0500 + emacs (1:28.2+1-14) unstable; urgency=medium * Fix gnus nnml crash on some invalid headers. Add diff -Nru emacs-28.2+1/debian/control emacs-28.2+1/debian/control --- emacs-28.2+1/debian/control 2023-03-31 13:22:31.0 -0500 +++ emacs-28.2+1/debian/control 2023-05-13 14:31:35.0 -0500 @@ -142,7 +142,9 @@ apel (<< 10.8+0.20120427-4), edb (<< 1.32), egg (<< 4.2.0-2), + elpa-cider (<< 0.19.0+dfsg-4~), emacs (<< 1:25), + emacs-bin-common (<< 1:28), emacs-gtk (<< 1:25), emacs-lucid (<< 1:25), emacs-nox (<< 1:25), @@ -159,7 +161,9 @@ emacs24-nox, emacs25, emacs25-lucid, - emacs25-nox, + emacs25-nox +Replaces: + emacs-bin-common (<< 1:28) Description: GNU Emacs editor's shared, architecture independent infrastructure GNU Emacs is the extensible self-documenting text editor. This package contains the architecture independent infrastructure Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1035781: emacs-common: needs Breaks against incompatible elpa packages from bullseye
Rob Browning writes: > Right, I'm actually working on a release for this. I think I should be > able to upload today or tomorrow, and not sure if we need to wait for > preapproval aince we'd want this in any other future migrations from > unstable to testing/bullseye. Oh, and possibly cf. https://bugs.debian.org/1034941 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1035781: emacs-common: needs Breaks against incompatible elpa packages from bullseye
Rob Browning writes: > Rob Browning writes: > >> Right, I'm actually working on a release for this. I think I should be >> able to upload today or tomorrow, and not sure if we need to wait for >> preapproval aince we'd want this in any other future migrations from >> unstable to testing/bullseye. > > Oh, and possibly cf. https://bugs.debian.org/1034941 To clarify, I was planning to try to fix that one, and would of course like to make sure whatever the fix is, it covers the cases you've found too. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1035781: emacs-common: needs Breaks against incompatible elpa packages from bullseye
Andreas Beckmann writes: > There are some elpa packages from bullseye that won't be in bookworm and > that are incompatible with emacs 28, i.e. upgrading emacs will fail if > these packages are still installed. > Therefore emacs-common needs to add Breaks against them s.t. they get > removed during the upgrade to bookworm. Right, I'm actually working on a release for this. I think I should be able to upload today or tomorrow, and not sure if we need to wait for preapproval aince we'd want this in any other future migrations from unstable to testing/bullseye. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1033844: unblock: emacs/1:28.2+1-13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: em...@packages.debian.org Control: affects -1 + src:emacs Please unblock package emacs The only changes are two bug fixes, one for the Org Mode CVE. The patches added are the cherry-picked upstream changes, as indicated in the patch headers. https://bugs.debian.org/1033342 https://bugs.debian.org/1033397 unblock emacs/1:28.2+1-14 (Package hasn't been uploaded yet; this is a preapproval request.) diff -Nru emacs-28.2+1/debian/.git-dpm emacs-28.2+1/debian/.git-dpm --- emacs-28.2+1/debian/.git-dpm 2023-03-14 15:30:28.0 -0500 +++ emacs-28.2+1/debian/.git-dpm 2023-03-31 13:22:32.0 -0500 @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -4e6971c25c27c9a3f34cc69b51db894105362d08 -4e6971c25c27c9a3f34cc69b51db894105362d08 +023ac1eff558f6fb387fea1629b084c8929de18d +023ac1eff558f6fb387fea1629b084c8929de18d 279b82e64e15b5e2df3cb522636c6db85a8ee659 279b82e64e15b5e2df3cb522636c6db85a8ee659 emacs_28.2+1.orig.tar.xz diff -Nru emacs-28.2+1/debian/changelog emacs-28.2+1/debian/changelog --- emacs-28.2+1/debian/changelog 2023-03-14 15:30:28.0 -0500 +++ emacs-28.2+1/debian/changelog 2023-04-01 22:38:56.0 -0500 @@ -1,7 +1,20 @@ +emacs (1:28.2+1-14) unstable; urgency=medium + + * Fix gnus nnml crash on some invalid headers. Add +0026-Gnus-nnml-should-avoid-crashing-on-some-invalid-head.patch to +address the issue. (Closes: 1033397) + + * Fix Org Mode command injection vulnerability CVE-2023-28617. Add +0027-Org-Mode-vulnerability-CVE-2023-28617-is-fixed-1-2.patch and +0028-Org-Mode-vulnerability-CVE-2023-28617-is-fixed-2-2.patch to +address the issue. (Closes: 1033342) + + -- Rob Browning Sat, 01 Apr 2023 22:38:56 -0500 + emacs (1:28.2+1-13) unstable; urgency=high * Cherry-pick upstream fixes for command injection vulnerabilities -(CVE-2023-27984, CVE-2023-27986) (Closes: #1032538). +(CVE-2023-27985, CVE-2023-27986) (Closes: #1032538). -- Sean Whitton Tue, 14 Mar 2023 13:30:28 -0700 diff -Nru emacs-28.2+1/debian/patches/0026-Gnus-nnml-should-avoid-crashing-on-some-invalid-head.patch emacs-28.2+1/debian/patches/0026-Gnus-nnml-should-avoid-crashing-on-some-invalid-head.patch --- emacs-28.2+1/debian/patches/0026-Gnus-nnml-should-avoid-crashing-on-some-invalid-head.patch 1969-12-31 18:00:00.0 -0600 +++ emacs-28.2+1/debian/patches/0026-Gnus-nnml-should-avoid-crashing-on-some-invalid-head.patch 2023-03-31 13:22:31.0 -0500 @@ -0,0 +1,52 @@ +From cf3c2037c3531b756fbb443b8ab2f6873f10930e Mon Sep 17 00:00:00 2001 +From: Eli Zaretskii +Date: Mon, 19 Dec 2022 19:01:04 +0200 +Subject: Gnus nnml should avoid crashing on some invalid headers + +This upstream patch has been incorporated to fix the problem: + + Fix storing email into nnmail by Gnus + + * lisp/gnus/nnml.el (nnml--encode-headers): Wrap + 'rfc2047-encode-string' calls with 'ignore-errors', to avoid + disrupting email workflows due to possibly-invalid headers. + Reported by Florian Weimer . + +Origin: upstream, commit: 23f7c9c2a92e4619b7c4d2286d4249f812cd695d +Bug-Debian: https://bugs.debian.org/1033397 +Forwarded: not-needed +--- + lisp/gnus/nnml.el | 13 + + 1 file changed, 9 insertions(+), 4 deletions(-) + +diff --git a/lisp/gnus/nnml.el b/lisp/gnus/nnml.el +index afdb0c780a5..258c5efc79f 100644 +--- a/lisp/gnus/nnml.el b/lisp/gnus/nnml.el +@@ -775,17 +775,22 @@ nnml-parse-head + (nnml--encode-headers headers) + headers + ++;; RFC2047-encode Subject and From, but leave invalid headers unencoded. + (defun nnml--encode-headers (headers) + (let ((subject (mail-header-subject headers)) + (rfc2047-encoding-type 'mime)) + (unless (string-match "\\`[[:ascii:]]*\\'" subject) +- (setf (mail-header-subject headers) +- (mail-encode-encoded-word-string subject t ++ (let ((encoded-subject ++ (ignore-errors (mail-encode-encoded-word-string subject t ++(if encoded-subject ++(setf (mail-header-subject headers) encoded-subject) + (let ((from (mail-header-from headers)) + (rfc2047-encoding-type 'address-mime)) + (unless (string-match "\\`[[:ascii:]]*\\'" from) +- (setf (mail-header-from headers) +- (rfc2047-encode-string from t) ++ (let ((encoded-from ++ (ignore-errors (rfc2047-encode-string from t ++(if encoded-from ++(setf (mail-header-from headers) encoded-from)) + + (defun nnml-get-nov-buffer (group incrementalp) + (let ((buffer (gnus-get-buffer-create diff -Nru emacs-28.2+1/debian/patches/0027-Org-Mode-vulnerability-CVE-2023-28617-is-fixed-1-2.patch emacs-28.2+1/debian/patches/0027-Org-Mode-vulnerability-CVE-2023-28617-is-fixed-1-2.patch --- emacs-28.2+1/debian/patches/0027-Org-Mode-vulnerability-CVE-2023-28617-is-fixed-1-2.patch 1969-12-31 18:00:00.0 -0600 +++ emacs-28.2+1
Bug#1033397: Gnus cannot store some incoming mail into nnml
Florian Weimer writes: > Please backport the commit below; it fixes the issue and is supposed > not to break the .overview file encoded. Thanks. I've added the fix to the salsa repo, so it should be in the next upload. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1029825: emacs: reduce libgccjit0 related dependencies to optional?
David Bremner writes: > OK, but two weeks before the soft freeze is IMHO not a good time for > this kind of experiment. We just went through literally months of > debugging to get native compilation mostly working in emacs and hundreds > of associated packages. I suspect your proposed change will yield a > whole bunch of new bugs from people who don't install recommends, and > then don't understand what is broken. > > With that said, I'm not the emacs maintainer, so I will bow out of the > discussion. I think you're right. Even if we decide we want to, there's no time left for this release, and some of the work might not even be wrt the emacs packages, proper. That said, and as you mentioned, we could also consider other/additional flavors of emacs, but of course those have their own costs. In any case, happy to discuss adjustments for unstable after the release. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1026200: Please package LilyPond 2.24.0 if possible
Anthony Fok writes: > Thank you so much for Cc'ing Rob regarding Guile-2.2. > > Rob, as you can see, there is a real need for Guile 2.2 for LilyPond > 2.24.0 (December 2022), this coming from LilyPond's Core Developer > Jonas Hahnfeld and "Factotum" and Jean Abou Samra. If it is OK with > you, Rob, I would be more than happy to adopt guile-2.2 and maintain > it for the entire lifetime of Debian 12 (bookworm), and hopefully by > Debian 13 (trixie), LilyPond will be ready for guile-3.0. :-)\ > Many thanks for your understanding! I'd be very hesitant to include Guile 2.2 in bookworm since I believe it's explicitly not supported upstream and hasn't had a single commit in over two years. If there's any chance LilyPond will support something newer in a reasonable time-frame, I might suggest just waiting, and then introducing the new version via backports. But I don't really understand the situation and constraints. That said, I won't oppose reintroducing 2.2, as long as I'm not responsible for it, and you're willing to herd all the cats to get it removed again as soon as possible. That was a good bit of work I'd prefer not to repeat. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1025720: emacs: systemd user unit runs automatically, even when disabled
Ross Vandegrift writes: > Should the systemd user unit be started by default? The changelog indicates > no > (see 1:28.1+1-4) and dh_installsystemduser is invoked with > --no-enable. That's correct, i.e. it shouldn't. > But it starts on my system without (as far as I recall) me enabling > it. > > > What's the appropriate way to disable it? `systemctl --user disable --now > emacs.server` only lasts until I reboot. Masking it works. > > I've noticed that even after disabling, status shows it's enabled: > $ systemctl --user disable --now emacs.service > $ systemctl --user status emacs.service | head -n 3 > ○ emacs.service - Emacs text editor >Loaded: loaded (/usr/lib/systemd/user/emacs.service; enabled; preset: > enabled) >Active: inactive (dead) since Wed 2022-12-07 15:03:03 PST; 4s ago > > I don't really understand how systemd user stuff works - > ~/.config/systemd/user > is empty (until masking), but I don't know if that's informative. I suspect you're having the same problem I was, which I believe is caused by the fact that earlier versions of the package (in untable) didn't have --no-enable, and the auto-run behavior seems to be sticky. I "fixed" it here by purging and reinstalling emacs-common, but I'd hope there's a better way. If so, I'd be happy to consider adding some notes to a suitable /usr/share/doc file, and/or trying to automate a fix. Though if the fix isn't simple, I might hesitate attempting to automate it, since the problem (I hope) only existed somewhat briefly in unstable. Thanks for the report, and sorry for the trouble. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1023560: RM: guile-2.2 -- ROM; replaced by guile-3.0
Package: ftp.debian.org User: release.debian@packages.debian.org Usertags: rm I think guile-2.2 has already been removed from testing (which is *great*), and now I'd like to finally remove it from unstable if that's feasible. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1023297: src:emacs: fails to migrate to testing for too long: unresolved RC issues
Paul Gevers writes: > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. I think the current situation might be expressed as "we're working on it". Emacs 28 introduced native compilation, which we're trying to support for bookworm, but it's been a fairly bumpy ride so far. We still expect to have things under control in the next month or so (maybe sooner), but if that doesn't pan out, then we'll likely just back off and start with an Emacs 28 without native compilation. Hope that helps, and thanks. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1017739: emacs-lucid cannot start after upgrade
Stefan Monnier writes: >>> emacs -e '(message "%S" comp-native-load-path)' > > Sorry, that should have been: > > emacs --eval '(message "%S" comp-native-load-path)' > > (which you can then try with `-q` and friends if needed). > >> I'm a bit mystified as to why everyone else on Debian isn't seeing this. >> I would have assumed it must be something in my startup files that is >> incompatible with the latest release of Emacs, except I thought -q >> --no-site-file should completely disable loading anything from my local >> configuration. > > My crystal ball suggests maybe your ~/.emacs.d is marked as read-only? I don't know if this helps, but in addition to the recent issue we've identified where not having emacs-el installed can cause emacs from the current 28 packages to segfault on startup, people just figured out that if you try to install emacs via "su apt install emacs" (note the lack of a "-" argument to su) from a non-root account, emacs can end up failing for that account because the install ends up creating root-only directories (for I think the eln files, etc.) in ~. I'm not sure whether that's something that we'd expect to support (i.e. apt installs via sudo without -i or su without -), but I wanted to mention it since it's been reported (I think) more than once, and in case it indicates something that emacs might want to change (use of USER vs HOME, etc.). No personal position there right now either way. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1017739: emacs-lucid cannot start after upgrade
Russ Allbery writes: > For what it's worth, this is the first package that I recall having > trouble with during installation, and I've been using Debian for quite a > while. :) > > That doesn't mean you're wrong -- you've got a good point and I should get > in the habit of using -. Oh, I don't know whether I'm right or wrong there either, just describing my defensive behavior :) > But I do wonder if there's a bug or at least some surprising behavior > here in Emacs. Blindly using USER when HOME is set correctly is > pretty unusual (and, for whatever it's worth, contrary to the BaseDir > specification, not that Emacs is currently following that). Generally > HOME should override USER when used to locate the current user's home > directory. Ahh, yeah, speaking more generally, I fully expect we may hit and have to (help) fix a relatively large number of edge cases as a result of the addition of native compilation. Lots of new moving parts, and the arrangement in Debian is likely different from what upstream typically tests in important ways. (cf. the other problem right now where installs segfault in some cases if you don't already have emacs-el installed. That's likely an upstream bug of some kind.) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1017739: emacs-lucid cannot start after upgrade
Russ Allbery writes: > Oh, good catch! The same thing was true of mine. > > I think the dates were when I upgraded Emacs. Let me take a guess: are > you also old-school and use su from a regular user account when installing > new packages? HOME gets overridden by su, but LOGNAME and USER do not, > and I suspect something in Emacs is deciding where to write files based on > USER, and the installation process of emacs-lucid creates the eln-cache > directory for some reason. Agreed, nice catch, very glad y'all found this. And not sure it'd be appropriate in your case, and you may well know, but adding the "-" argument to su may avoid the issue for you. > I'm downgrading the severity of this bug because I suspect the average > user using sudo may not run into it (although the maintainer should feel > free to raise the severity again if they disagree). If I'm right, the > best place to solve the problem may be in the Debian maintainer scripts, > overwriting USER (and possibly LOGNAME, not sure if it matters) to some > safe value like root while performing the installation. This may also be > necessary to do when installing Emacs add-on packges; I'm not sure. Possibly, but I'd assumed the installation processs should expect a "normal" root environment, and if so, "su" without the dash wouldn't qualify. Otherwise, random user .bashrc changes (that su doesn't reset) could affect the install. > I've removed the directory with the wrong ownership and upgraded again > with USER and LOGNAME set to root, and now everything works fine. (Well, > my laptop gets extremely hot the first time I start the new Emacs, but I > assume that's expected for the new compilation system.) Yes, I believe that should only happen once per .el file, per user[1], but it's not cheap. [1] ...until/unless we decide to ship NATIVE_FULL_AOT packages (all upstream files precompiled). But if nothing else, that's not ready for broad use yet. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
Linas Vepstas writes: > Wow! Well, I feel kind of dumb to not actually have tried that; I have been > trained that SIGSEGV is a full stop, and it's pointless to try to > continue. Thank you! Of course, and I might well not have assumed otherwise either -- but yeah, I have the impression that libgc does some "interesting" things. > I can't imagine I will be the first and only one to be surprised by this > change of behavior, but I can't think of a good solution to propose, just > right now. Agreed, I suppose we could consider adding it to a README.Debian, but not sure people (including me) would notice it in the relvant circumstances. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1016630: guile-3.0: gdb guile results in SIGSEGV before guile even starts!
Linas Vepstas writes: > Package: guile-3.0 > Version: 3.0.8-2 > Severity: normal > X-Debbugs-Cc: linasveps...@gmail.com > > Dear Maintainer, > > To debug large complex programs that use guile extensions, I run `gdb > guile` regularly. This does not work w/ current version in testing. I > get this: > ``` > $ gdb guile > GNU gdb (Debian 12.1-3) 12.1 > ... etc ... > Reading symbols from guile... > (No debugging symbols found in guile) > (gdb) r > Starting program: /usr/bin/guile > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. According (and thanks) to mwette, this is actually expected behavior: https://hboehm.info/gc/debugging.html And just continuing via "c" should work. It looks like guile's source tree gdbinit has the handlers for SIGPWR and SIGXCPU, but not SIGBUS or SIGSEGV. Hope this helps (I've marked this bug as done, but please feel free to re-open it if that doesn't sound reasonable to you yet.) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1009169: please package new emacs version 28.1
Xiyue Deng writes: > Thanks for maintaining Emacs in Debian! I've been a long time Emacs > user and would like to help in anyway you prefer. I had some > experiences in Debian packaging a few years ago and have been > relearning everything from the docs like [1] and [2]. If there's > anything that I can help with (e.g. testing, bug triaging, etc.) > please let me know. Thanks. I've finally been working on the packaging more substantially, and it's coming along. Took a while for the review, copyright updates, dfsg-split, merge, etc. But it's getting closer. We've been discussing it off an on on #debian-emacs (OFTC), and I'm hoping to have packages to upload for evaluation/testing and then migration within the next week or so. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#1009169: Any ETA?
Eugen Dedu writes: > Do you have an ETA? Will it be packaged in one week, one month, several > months? I would guess "weeks". I've finally gotten started on it, but am a good bit slower than usual at the moment. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#990250: guile-2.2 FTBFS on musl: dh_missing complains about charset.alias
[If possible, please preserve at least the -forwarded address in any replies.] It looks like a file might be missing from installs when building for linux-musl: Helmut Grohne writes: > Source: guile-2.2 > Version: 2.2.7+1-6 > > guile-2.2 fails to build from source on musl-linux-any, because the > build generates a charset.alias that is never installed and thus > dh_missing complains: > > | dh_missing: warning: usr/lib//charset.alias exists in debian/tmp > but is not installed to anywhere > | dh_missing: error: missing files, aborting > > It turns out, that this file actually contains only comments for musl, > so it can be skipped like it is skipped for glibc. Please consider > applying the attached patch. > > Helmut > --- a/lib/Makefile.am > +++ b/lib/Makefile.am > @@ -1043,7 +1043,7 @@ install-exec-localcharset: all-local > case '$(host_os)' in \ > darwin[56]*) \ > need_charset_alias=true ;; \ > - darwin* | cygwin* | mingw* | pw32* | cegcc*) \ > + darwin* | cygwin* | mingw* | pw32* | cegcc* | linux-musl*) \ > need_charset_alias=false ;; \ > *) \ > need_charset_alias=true ;; \ Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#990250: guile-2.2 FTBFS on musl: dh_missing complains about charset.alias
Helmut Grohne writes: > --- a/lib/Makefile.am > +++ b/lib/Makefile.am > @@ -1043,7 +1043,7 @@ install-exec-localcharset: all-local > case '$(host_os)' in \ > darwin[56]*) \ > need_charset_alias=true ;; \ > - darwin* | cygwin* | mingw* | pw32* | cegcc*) \ > + darwin* | cygwin* | mingw* | pw32* | cegcc* | linux-musl*) \ > need_charset_alias=false ;; \ > *) \ > need_charset_alias=true ;; \ Hmm, it looks like this may have changed in more recent 3.0 releases (i.e. need_charset_alias is no longer mentioned anywhere in the tree). I wonder if that means we need a different patch, or perhaps the problem has been resolved. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults
John Paul Adrian Glaubitz writes:
> Could you include this patch or a possible better version in the next
> guile-3.0 upload?
As mentioned, I'm working on 3.0.8, and the bootstrap process has
changed somewhat to support reproducible builds. So I went ahead and
uploaded 3.0.8-1 without this patch, and then I hoped, if you have time,
you might be able to test that and see if we need to make adjustments to
the fix. In particular, guile now has
{bootstrap,stage0,stage1,stage2}/Makefile.am.
It may be that we only need to adjust a subset of these (say bootstrap
and/or stage0)...
Oh, and I'm not sure it's working exactly right yet, but I'd been toying
with a more selective approach that works with automake's if/then
restrictions via an AM_CONDITIONAL. Of course we'll still need to
figure out which Makefiles we need to adjust.
commit 6c1173b3a96d65159062b2ba82afb7264a01591e
Author: Rob Browning
Date: Sun Feb 27 12:55:42 2022 -0600
Adjust GUILE_OPTIMIZATION to avoid 32-bit BE build crashes
diff --git a/bootstrap/Makefile.am b/bootstrap/Makefile.am
index a4634c447..0aa548c26 100644
--- a/bootstrap/Makefile.am
+++ b/bootstrap/Makefile.am
@@ -22,7 +22,14 @@
GUILE_WARNINGS = -W0
-GUILE_OPTIMIZATIONS = -O1
+
+if !DEB_GUILE_32_BIT_BIG_ENDIAN
+ $(info Note: not adjusting GUILE_OPTIMIZATIONS for 32-bit big-endian architecture)
+ GUILE_OPTIMIZATIONS = -O1
+else
+ $(info Note: adjusting GUILE_OPTIMIZATIONS for 32-bit big-endian architecture)
+ GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives -Ocps
+endif
include $(top_srcdir)/am/bootstrap.am
diff --git a/configure.ac b/configure.ac
index 827e1c09d..dec060414 100644
--- a/configure.ac
+++ b/configure.ac
@@ -369,6 +369,9 @@ else
fi
AC_SUBST([SCM_I_GSC_T_PTRDIFF])
+AM_CONDITIONAL([DEB_GUILE_32_BIT_BIG_ENDIAN],
+ [test "$ac_cv_words_bigendian" && test "$ac_cv_sizeof_void_p" -lt 8])
+
AC_CHECK_HEADERS([stdatomic.h])
AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])
diff --git a/stage0/Makefile.am b/stage0/Makefile.am
index 12029fb45..4228f607d 100644
--- a/stage0/Makefile.am
+++ b/stage0/Makefile.am
@@ -22,7 +22,15 @@
GUILE_WARNINGS = -W0
-GUILE_OPTIMIZATIONS = -O1
+
+if !DEB_GUILE_32_BIT_BIG_ENDIAN
+ $(info Note: not adjusting GUILE_OPTIMIZATIONS for 32-bit big-endian architecture)
+ GUILE_OPTIMIZATIONS = -O1
+else
+ $(info Note: adjusting GUILE_OPTIMIZATIONS for 32-bit big-endian architecture)
+ GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives -Ocps
+endif
+
GUILE_BOOTSTRAP_STAGE = stage0
include $(top_srcdir)/am/bootstrap.am
Oh, and you should be able to see those $(info ...) messages in the
build output, so we'll be able to see if it's picking the right setting.
(I just verified that it picks the right one for amd64, at least.)
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults
John Paul Adrian Glaubitz writes: > Any chance this patch could be included for the next upload? > > This bug is currently blocking package builds on powerpc. I'm working on 3.0.8, and I'll see about including it there, either in the initial upload, or subsequently. I also plan to add the other "disable threads" fix for the relevant architectures. Thanks, and apologies for the delay. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
John Paul Adrian Glaubitz writes: > But again, we're doing this all the time and this affects a non-release > architecture. I never said this flag should be passed for amd64 or arm64. Understood. I was specifically thinking about any existing alpha deployments and what the constraints might be. I discussed it a bit on #debian-devel, and it sounded like breaking the ABI in this case, while not ideal of course, wouldn't be unacceptable. So if no other options present themselves before I get a chance to work on it, I'll plan to make this change. Then, once that's uploaded were you planning to handle the reverse dep rebuilds, and/or what coordination might we need there? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
John Paul Adrian Glaubitz writes: > The alpha architecture is not part of any distribution which is why this > argument is moot. I was not asking for this option to be set to an release > architecture. > > Also, *if* we break the ABI, we can just rebuild all affected packages. We > do that with binNMUs for various reverse dependencies all the time. > > Finally, without this change, guile will not work on alpha at all. So, we > cannot break the ABI in the first place, because we didn't have a properly > working guile package on alpha yet. To be clear, I'm not taking any position yet on what I think we can/should do. I'm just describing what I've found and what I think the constraints are. And while we can, of course, rebuild all the reverse deps (presumably only acceptable for testing/sid), doing so may still break things for anyone outside debian who's been relying on our packages (if we'd ever had any in testing -- sounds like maybe we haven't for 3.0 for alpha). Maybe that ends up being the best of bad choices, but I just wanted to make sure we included that concern in our deliberations. i.e. I suspect it'd be better not to break testing like that if we could avoid it, even if technically acceptable. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
Rob Browning writes: > Given that, I think we may have at least these constraints: Oh, and I haven't figured out what the current situation is wrt the affected architectures on this front yet -- was just describing the constraints. If we've never had a 3.0 viable for alpha, for example, then we can of course do whatever we like, with the realization that if we disable threads there now, we may be stuck with that choice until 3.2. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
John Paul Adrian Glaubitz writes: > Without --without-threads, guile would not build on SMP systems and even > the built package would crash on SMP systems. > > If disabling threads would break the ABI, we could just rebuild the affected > reverse dependencies on the builds using the normal binNMU method. I've checked with upstream, and while they were not certain that changing the --with-threads setting still breaks the library API, they thought it probably did, which I believe means we have to assume that it does (or could in the future), i.e. upstream makes no guarantees that you can ever change that option without breaking the ABI. Given that, I think we may have at least these constraints: - For any guile X.Y version (for a given arch) that's in a stable distribution (buster, bullseye, etc.) we cannot change the setting because it would break the contract and could crash existing debian and non-debian applications linked to the relevant guile-X.Y-libs. - For any X.Y version (for a given arch) that's only ever been in unstable/testing, we *could* break the ABI, but I think the bar should be reasonably high there, and I suspect we may want to discuss any plan along those lines a bit more broadly before deciding to pursue it (do we typically allow breaking SONAME compatibility in testing?), since plenty of people (including me) use the testing libs for real work. In addition, as you say this would require rebuilding every reverse dependency. Of course the best option, if it were feasbile, would be to just figure out what's wrong and fix it. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS
John Paul Adrian Glaubitz writes: > Both guile-2.2 and guile-3.0 FTBFS on alpha when built with thread > support. Passing --without-threads to configure disables thread > support and fixes the build. Hmm, I'm not certain we can do this unless we've never had a successful build on the relevant platforms. At least in the past, disabling threads changed the library ABI in a backward incompatible way. I'll see if I can find out if that's still the case. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#993960: emacs: Please build with '--with-dumping=unexec' on m68k
John Paul Adrian Glaubitz writes: > Source: emacs > Severity: normal > Tags: upstream patch > User: debian-...@lists.debian.org > Usertags: m68k > X-Debbugs-Cc: debian-...@lists.debian.org > > Hello! > > The new dumper "pdumper" enabled on Emacs 27 by default currently causes > issues on m68k: > > Dumping under the name bootstrap-emacs.pdmp > dumping fingerprint: > acbddcb917b565f0afbdbaae4aadae8255f8a8030d1b0f932e89d1696b21246a > dump relocation out of range > > This issue can be worked around by building emacs on m68k with > --with-dumping=unexec > which is what the attached patch does. > > Could you apply the patch for the time being until the issue has been fixed > upstream? [1] Thanks, I'll plan to include that in the next upload. If you don't see it soon enough, feel free to ping me. Take care -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#987177: lockfile-progs: lockfile creation failing on cifs mounts
Nils writes: > lockfile creation fails on a cifs mounted drive with "lockfile > creation failed: Value too large for defined data type" Hmm, lockfile-create is really a very simple wrapper around a call to lockfile_create(1), and offhand, I don't see any obvious way the arguments being passed could be causing an EOVERFLOW. Offhand, I wonder if it's the liblockfile version difference. From a quick glance I see some upstream commits involving EOVERFLOW. If you can still reproduce the problem, you might be able to verify that by testing with dotlock instead of lockfile-create. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#964284: guile-gnutls: update to use guile 3.0
Andreas Metzler writes: > I just made a test-upload to experimental. I just found out I may have been wrong about 3.0.7's defaults, and so this problem might not be fixed yet. I'll investigate soon, and likely have another upload by this weekend, if we do end up needing one. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#990078: unblock: guile-2.2/2.2.7+1-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock unblock guile-2.2/2.2.7+1-6 Please unblock package guile-2.2 The test-out-of-memory test is known to fail intermittently, and has done so again https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966301#46 We've previously disabled it in guile-3.0, and this release just cherry-picks that change to guile-2.2. https://salsa.debian.org/rlb/deb-guile/-/commit/e9341779527efccf736a2a3c737371a10bc8ec63 guile-2.2_2.2.7+1-5.4-to-6.debdiff Description: guile-2.2_2.2.7+1-5.4-to-6.debdiff -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#990049: unblock: guile-3.0/3.0.5-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock unblock guile-3.0/3.0.5-4 Please unblock package guile-3.0. [ Reason ] The (only) changes between -2 and -4 fix a significant bug that can cause packages that depend on libguile to crash unpredictably: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982217 See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964284#33 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964284#58 I'd thought that -4 had migrated a while ago, I was clearly mistaken. [ Impact ] Programs in packages that link against libguile can crash unpredictably. [ Tests ] I don't know of any tests that exercise this problem directly, but the problem was reproducible (see the links above) and the changes between -2 and -4 were added to fix it. guile-3.0_3.0.5-2-to-4.debdiff Description: guile-3.0_3.0.5-2-to-4.debdiff Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#966301: guile oom test fails (but currently not on buildds)
Dylan Aïssi writes: > It looks like we have to ignore test failures on all arches. > Should we do a NMU for bullseye? See attached debdiff. I think I may have misread what was said in the past. I thought the earlier NMU was disabling one of the specific memory-related tests that was crashing, not all tests. I'm fairly uneasy with disabling them all, if that's what we're currently doing. I'll plan to take a look and/or talk to upstream soon, though I might not get to it in depth until the weekend. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
[When possible/appropriate, please preserve the 988581-forwarded address in replies.] Recently reported, and I can reproduce it locally with -Q (and with the lucid flavor) too. Thomas Lundqvist writes: > Package: emacs-gtk > Version: 1:27.1+1-3.1 > Severity: normal > > Dear Maintainer, > > My emacs get stuck with 100% cpu when started from a directory ending with > ".tar". > > For example, the following commands trigger the error: > - mkdir test.tar > - cd test.tar > - emacs -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#982762: radicale: perhaps chown/chmod /var/lib/radicale/...
Package: radicale Version: 3.0.6-2 I noticed that /var/lib/radicale and /var/lib/radicale/collections are root:root, and wondered if it might be preferable to change them to radicale:radicale, and/or restrict world access as suggested upstream (and expected by the included service file, if nothing else): https://radicale.org/3.0.html#tutorials/running-as-a-service i.e. maybe chmod 750 /var/lib/radicale/collections chown radicale:radicale /var/lib/radicale/collections or 770, and possibly something similar for /var/lib/radicale. Thanks for maintaing the package. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#981959: emacs-common-non-dfsg: please update to version 27
Francesco Potortì writes: > Package: emacs-common-non-dfsg > Version: 1:26.3+1-1 > Severity: normal > X-Debbugs-Cc: none, Francesco Potortì > > The documentation for Emacs lags behind: it is at 26 while Emacs is at 27 Oops - David also pointed this out, and I forgot. I'll plan to work on it soon, likely this weekend. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#980498: guile-3.0 FTBFS on amd64: check-guile fails
forwarded 980498 bug-gu...@gnu.org thanks Helmut Grohne writes: > guile-3.0 failed to build from source on the buildd on amd64. It is hard > to pin down the actual failure. It happens during unit tests. > https://buildd.debian.org/status/fetch.php?pkg=guile-3.0=amd64=3.0.5-1=1610521112=0 > is a link to a failing build log. Right, I brought this up on #guile, but no further information yet, and just a bit ago filed an upstream bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46001 > The armel build failed differently. It timed out via not producing any > output in 5 minutes. kfreebsd-amd64 and kfreebsd-i396 seem to have > failed in the same way as amd64. I wonder if this might be time-limit related (again). cf. https://salsa.debian.org/rlb/deb-guile/-/blob/deb/guile-3.0/d/sid/master/debian/rules#L187-195 Though 3.0 is much better on that front than 2.2 was. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#979749: buster-pu: package emacs/1:26.1+1-3.2+deb10u1
"Adam D. Barratt" writes: > The metadata for that bug implies that it still affects the package in > unstable (hence the lack of any green on the version graph). I suspect > this is simply because the "fixed" version doesn't correspond to an > actual Debian package version. Please could you add a fixed version > that indicates the earliest upload to Debian that included the fix. Done, I think. > Also, while it's possibly slightly picky: > > +emacs (1:26.1+1-3.2+deb10u2~1.gbp7c5887) UNRELEASED; urgency=medium > + > + ** SNAPSHOT build @7c5887c8ae064398fafa38b8fea4c5d500830d5f ** > + > + * UNRELEASED > + > + -- Rob Browning Sun, 10 Jan 2021 19:22:48 -0600 > > could we have a finalised version of that, please? :-) Oh, no, certainly. I just submitted the UNRELEASED version for the pre-approval. I'll of course finalize that before the actual upload. If that all sounds fine, I'll proceed with a real upload. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#979749: buster-pu: package emacs/1:26.1+1-3.2+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu dkg has requested that we consider fixing this bug in buster: Debian: https://bugs.debian.org/919642 Upstream: https://debbugs.gnu.org/34121 which is fairly straightforward (just the new patch at the end, cherry-picked directly from the upstream fix): diff -Nru emacs-26.1+1/debian/.git-dpm emacs-26.1+1/debian/.git-dpm --- emacs-26.1+1/debian/.git-dpm 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/.git-dpm 2021-01-10 19:22:48.0 -0600 @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -face2676a9d5a13b40eaeecfb09a16e81364e916 -face2676a9d5a13b40eaeecfb09a16e81364e916 +7812b00398e73156c07be2ea2abe1dbf0153ccfe +7812b00398e73156c07be2ea2abe1dbf0153ccfe 511a2cebd6df0f71ec24b5939564fb58726ead84 511a2cebd6df0f71ec24b5939564fb58726ead84 emacs_26.1+1.orig.tar.xz diff -Nru emacs-26.1+1/debian/changelog emacs-26.1+1/debian/changelog --- emacs-26.1+1/debian/changelog 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/changelog 2021-01-10 19:22:48.0 -0600 @@ -1,3 +1,11 @@ +emacs (1:26.1+1-3.2+deb10u2~1.gbp7c5887) UNRELEASED; urgency=medium + + ** SNAPSHOT build @7c5887c8ae064398fafa38b8fea4c5d500830d5f ** + + * UNRELEASED + + -- Rob Browning Sun, 10 Jan 2021 19:22:48 -0600 + emacs (1:26.1+1-3.2+deb10u1) buster; urgency=high * Update the EPLA packaging key (previous key expires 2019-09-23) via diff -Nru emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch --- emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch 2021-01-10 19:22:48.0 -0600 @@ -15,7 +15,7 @@ index 8743b449976..14d62f7f1cb 100644 --- a/lisp/info.el +++ b/lisp/info.el -@@ -213,7 +213,8 @@ A header-line does not scroll with the rest of the buffer." +@@ -213,7 +213,8 @@ Info-default-directory-list (nconc standard-info-dirs (list config-dir)) (cons config-dir standard-info-dirs (if (not (eq system-type 'windows-nt)) diff -Nru emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch --- emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch 2021-01-10 19:22:48.0 -0600 @@ -19,7 +19,7 @@ index 9d16b59defd..d20431492a7 100644 --- a/lisp/startup.el +++ b/lisp/startup.el -@@ -434,6 +434,10 @@ Warning Warning!!! Pure space overflow!!!Warning Warning +@@ -434,6 +434,10 @@ tutorial-directory :type 'directory :initialize #'custom-initialize-delay) @@ -30,7 +30,7 @@ (defun normal-top-level-add-subdirs-to-load-path () "Recursively add all subdirectories of `default-directory' to `load-path'. More precisely, this uses only the subdirectories whose names -@@ -1121,8 +1125,21 @@ please check its value") +@@ -1121,8 +1125,21 @@ command-line ;; be loaded from site-run-file and wants to test if -q was given ;; should check init-file-user instead, since that is already set. ;; See cus-edit.el for an example. diff -Nru emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch --- emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch 2021-01-10 19:22:48.0 -0600 @@ -253,7 +253,7 @@ index 77e32848318..22516310692 100644 --- a/lisp/help.el +++ b/lisp/help.el -@@ -292,6 +292,14 @@ If that doesn't give a function, return nil." +@@ -292,6 +292,14 @@ view-help-file (goto-address-mode 1) (goto-char (point-min))) diff -Nru emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch --- emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch 2021-01-10 19:22:48.0 -0600 @@ -15,7 +15,7 @@ index 3a38b1d83c8..5d1248ac581 100644 --- a/lisp/version.el +++ b/lisp/version.el -@@ -62,7 +62,7 @@ Don't use this function in programs to choose actions according +@@ -62,7 +62,7 @@ emacs-version to the system configuration; look at `system-configuration' instead." (interactive "P") (let ((version-string diff -Nru emacs-
Bug#976050: mailutils: FTBFS on amd64 with current unstable
Andreas Henriksson writes: > Thanks for this info, it made it much easier to know where to look for > the problem which is caused by having emacs installed in the build > environment (which it isn't in a clean buildd chroot). Ahh, sorry, clearly forgot to mention that I'd also run "apt install emacs-nox" to do some editing. Glad you figured it out. > I see these potential theoretical solutions: No strong opinion, fwiw -- I was originally just concerned about the build failure. > 2. just `rm -rf debian/tmp/usr/share/emacs` before dh_missing is ran. ...or maybe a dh_missing debian/not-installed override or -X if that'll work. > 4. Try to convince configure to enable emacs/lispdir without having >emacs necessarily installed (possibly by passing --with-lispdir) >and install the emacs/site-lisp files. >(Probably a better idea than 3 if possible.) Seems like in the short run, we didn't have those bits before, so perhaps fine to leave it that way for now. And in the longer run, if we decide we do want those files, and if there's much elisp code, it might ought to be compiled at install time as with dh-elpa or other emacsen-related packages, which might or might not suggest a mailutils-el package or something. If you do decide to head that route, I'd highly recommend #debian-emacs on oftc. Plenty of expertise there. Thanks again -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#976050: mailutils: FTBFS on amd64 with current unstable
Andreas Henriksson writes: > Could you please try using `dpkg-buildpackage -uc -us`, rather than > directly invoking debian/rules, and see if it helps you detect any > misconfigurations in your build environment? Just tried again in a new debian/testing64 VM (via vagrant). It still fails in the same way with "debian/rules binary", and fails in a new way (dh_missing error) with "dpkg-buildpackage -uc -us". Exact commands (suspect a current testing schroot would behave similarly, but haven't tested that yet): $ mkdir tmp-mailutils-test $ cd tmp-mailutils-test $ vagrant init debian/testing64 $ vagrant up $ vagrant ssh $ sudo -i # apt update # apt dist-upgrade # apt build-dep mailutils # apt source mailutils # cd mailutils-3.10 # dpkg-buildpackage -uc -us ... make[1]: Entering directory '/root/mailutils-3.10' dh_fixperms -Xdotlock.mailutils make[1]: Leaving directory '/root/mailutils-3.10' dh_missing dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.el exists in debian/tmp but is not installed to anywhere (related file: "debian/tmp/usr/share/mailutils/mh/mailutils-mh.el") dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.elc exists in debian/tmp but is not installed to anywhere While detecting missing files, dh_missing noted some files with a similar name to those that were missing. This error /might/ be resolved by replacing references to the missing files with the similarly named ones that dh_missing found - assuming the content is identical. As an example, you might want to replace: * debian/tmp/usr/share/mailutils/mh/mailutils-mh.el with: * usr/share/emacs/site-lisp/mailutils-mh.el in a file in debian/ or as argument to one of the dh_* tools called from debian/rules. (Note it is possible the paths are not used verbatim but instead directories containing or globs matching them are used instead) Alternatively, add the missing file to debian/not-installed if it cannot and should not be used. The following debhelper tools have reported what they installed (with files per package) * dh_install: libmailutils-dev (115), libmailutils7 (36), libmu-dbm7 (2), mailutils (10), mailutils-common (14), mailutils-comsatd (1), mailutils-doc (1), mailutils-guile (2), mailutils-imap4d (1), mailutils-mda (3), mailutils-mh (46), mailutils-pop3d (2), python3-mailutils (23) * dh_installdocs: libmailutils-dev (0), libmailutils7 (0), libmu-dbm7 (0), mailutils (0), mailutils-common (0), mailutils-comsatd (0), mailutils-doc (6), mailutils-guile (0), mailutils-imap4d (0), mailutils-mda (0), mailutils-mh (1), mailutils-pop3d (0), python3-mailutils (0) * dh_installexamples: libmailutils-dev (0), libmailutils7 (0), libmu-dbm7 (0), mailutils (1), mailutils-common (0), mailutils-comsatd (1), mailutils-doc (0), mailutils-guile (1), mailutils-imap4d (1), mailutils-mda (0), mailutils-mh (0), mailutils-pop3d (1), python3-mailutils (0) * dh_installman: libmailutils-dev (2), libmailutils7 (0), libmu-dbm7 (0), mailutils (10), mailutils-common (0), mailutils-comsatd (1), mailutils-doc (0), mailutils-guile (0), mailutils-imap4d (1), mailutils-mda (3), mailutils-mh (0), mailutils-pop3d (2), python3-mailutils (0) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. dh_missing: error: missing files, aborting make: *** [debian/rules:4: binary] Error 255 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 It's trivial to reproduce with those commands, so happy to gather any addiitonal information you might like. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#964284: guile-gnutls: update to use guile 3.0
Ludovic Courtès writes: > It looks as though the public or private key were corrupt, but nothing > obvious. > > Unfortunately, there doesn’t seem to be a similar test case in C. The > closest one is ‘tls12-rehandshake-cert-auto’, but it uses anonymous > certificates and different priority strings. > > Ideas for further debugging would be welcome! Hmm, I know almost nothing about gnutls (or even, yet, this particular test), but I wondered (in general) how hard it might be to create a C level test that does the same thing. If it's easy, might be worth a try. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#964284: guile-gnutls: update to use guile 3.0
Ludovic Courtès writes: > On the ‘gnutls_3_6_X’ branch, I can run the following loop for a while > without experiencing the issue (on x86_64-linux-gnu): > > while make check TESTS=tests/reauth.scm ; do : ; done I was just able reproduce it again in a bullseye (testing) amd64 VM while building both debian's 3.6.15-5 and 3.7.0-2 packages, though it seemed a bit harder to trigger this time, at least with 3.7.0-2. And it seems like redirecting stdin from /dev/null may make it more likely. In any case, ihe command that worked, fom a build in an "apt source" unpacked tree in /dev/tmp/gnutls28 (which is symlinked to /dev/shm/gnutls28) as described by Andreas in https://bugs.debian.org/969672 was the command that's also described there, i.e. if the initial "debian/rules build < /dev/null" didn't hang, I could re-run this afterward and eventually get it to block: env GUILE_AUTO_COMPILE=0 make -C b4deb/guile/ \ check TESTS="tests/reauth.scm" VERBOSE=1 < /dev/null I'm still not certain that /dev/shm is critical (or maybe that just makes things run fast enough to hit trouble), but I haven't reproduced it in any arrangment other than the one Andreas describes yet. Of course it's also possible that the debian build flags or debian tools/libs are relevant. I did manage to capture the reauth.scm.log this time when it hung: throw to `gnutls-error' with args (# read_from_session_record_port) 15 (primitive-load "/dev/shm/gnutls28/gnutls28-3.7.0/b4deb…") In ice-9/eval.scm: 155:9 14 (_ _) In ice-9/boot-9.scm: 1731:15 13 (with-exception-handler # …) 1736:10 12 (with-exception-handler _ _ #:unwind? _ # _) 142:2 11 (dynamic-wind _ _ #) In ice-9/eval.scm: 155:9 10 (_ _) 279:15 9 (_ #(#(# …))) 619:8 8 (_ #(#(#(# # …)) …)) 293:34 7 (_ #(#(#(# # …)) …)) In unknown file: 6 (read #) In ice-9/boot-9.scm: 1669:16 5 (raise-exception _ #:continuable? _) 1764:13 4 (_ #< components: (#<> #<…>) In ice-9/eval.scm: 619:8 3 (_ #(#(#) …)) In ice-9/boot-9.scm: 142:2 2 (dynamic-wind # …) In ice-9/eval.scm: 159:9 1 (_ #(#(# …))) In unknown file: 0 (make-stack #t) When I get a bit more time, I can try to attach gdb as you suggested. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969675: mailutils: please upgrade to guile-3.0 soon, if feasible
severity 969675 normal
thanks
Rob Browning writes:
> Please migrate to guile-3.0 as soon as it's feasible. If we can, I'd
> like to have the option to drop guile-2.2 from bullseye, so that we
> won't have to maintain two versions throughout that release.
I can't be sure this will work, given the other FTBS, but it might be
a start:
diff --git a/.pc/set_mu_sieve_moddir.patch/configure.ac
b/.pc/set_mu_sieve_moddir.patch/configure.ac
index fa5baa0..4c7ed7f 100644
--- a/.pc/set_mu_sieve_moddir.patch/configure.ac
+++ b/.pc/set_mu_sieve_moddir.patch/configure.ac
@@ -1162,7 +1162,7 @@ AC_SUBST([GUILE_BINDIR])
AC_SUBST([LIBMU_SCM])
AC_SUBST([LIBMU_SCM_DEPS])
AC_SUBST([MU_GUILE_SIEVE_MOD_DIR])
-GINT_INIT([gint],[2.2.0 with-guile],
+GINT_INIT([gint],[3.0 with-guile],
[useguile=yes
AC_DEFINE([WITH_GUILE],1,[Enable Guile support])
GUILE_BINDIR=`guile-config info bindir`
diff --git a/configure.ac b/configure.ac
index 174ee01..74774fe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1169,7 +1169,7 @@ AC_SUBST([GUILE_BINDIR])
AC_SUBST([LIBMU_SCM])
AC_SUBST([LIBMU_SCM_DEPS])
AC_SUBST([MU_GUILE_SIEVE_MOD_DIR])
-GINT_INIT([gint],[2.2.0 with-guile],
+GINT_INIT([gint],[3.0 with-guile],
[useguile=yes
AC_DEFINE([WITH_GUILE],1,[Enable Guile support])
GUILE_BINDIR=`guile-config info bindir`
diff --git a/debian/control b/debian/control
index 7e61ef3..f137928 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: bison,
flex,
gawk,
gettext,
- guile-2.2-dev,
+ guile-3.0-dev,
help2man,
libfribidi-dev,
libgnutls28-dev,
@@ -220,7 +220,7 @@ Package: mailutils-guile
Architecture: any
Depends: mailutils-common (= ${source:Version}),
libmailutils-dev,
- guile-2.2 | guile,
+ guile-3.0 | guile,
${misc:Depends},
${shlibs:Depends}
Description: GNU mailutils Guile interpreter and modules
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#976050: mailutils: FTBFS on amd64 with current unstable
Package: mailutils Version: 1:3.10-3 Severity: serious After an "apt-get source mailutils/sid" with current unstable, "debian/rules binary" fails here like this: Creating popauth.1... /home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth: error while loading shared libraries: libmu_dbm.so.7: cannot open shared object file: No such file or directory help2man: can't get `--help' info from /home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth Try `--no-discard-stderr' if option outputs to stderr make[1]: *** [debian/rules:52: override_dh_auto_install] Error 127 make[1]: Leaving directory '/home/vagrant/mailutils/mailutils-3.10' make: *** [debian/rules:4: binary] Error 2 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969672: gnutls28: please upgrade to guile-3.0 soon, if feasible
Andreas Metzler writes: > Abovementioned reproducer works on amd64. I can reproduce it now, but before I spend too much time trying to track it down, is it a requirement that debian packages be able to build and test in /dev/shm? I'll be a little surprised if that's feasible for all our packages, and my current guess is that maybe /dev/shm doesn't behave the way either gnutls or guile expects. I also wonder if it could be something we're setting in the debian/rules environment, since the tests work fine if I run: make -C b4deb check after the debian/rules build hangs and I C-c it. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969672: gnutls28: please upgrade to guile-3.0 soon, if feasible
Andreas Metzler writes: > I think I have described how to reproduce this on amd64 in the other > bugreport: > > (sid)ametzler@argenau:/$ rm -rf /tmp/GNUTLS/ /dev/shm/GNUTLS > (sid)ametzler@argenau:/$ mkdir /tmp/GNUTLS/ /dev/shm/GNUTLS > (sid)ametzler@argenau:/$ cd /dev/shm/GNUTLS > (sid)ametzler@argenau:/dev/shm/GNUTLS$ apt source gnutls28 ; ln -s > /dev/shm/GNUTLS/gnutls28-3.6.15 /tmp/GNUTLS/ ; cd /tmp/GNUTLS/gnutls28-3.6.15 > (sid)ametzler@argenau:/tmp/GNUTLS/gnutls28-3.6.15$ dpkg-buildpackage -uc -us > -j1 -B Does it happen if you build in a more typical filesystem? It just built fine on amdahl (arm64 porterbox), with a current sid chroot, and the -5 package from experimental, via "fakeroot debian/rules binary". I can't do what you describe above there because /dev/shm is 64M in the porterbox chroots. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969672: gnutls28: please upgrade to guile-3.0 soon, if feasible
Hmm, didn't see this until now (don't think I received a mail from the bug tracker). > Andreas Metzler writes: > a full build fails reproducibly for me when building in /dev/shm. Building in /dev/shm? And on what architecture, etc. > I did a test upload to experimental yesterday, it also failed on > arm64, since a guile test did hang. If we think it's arm64 specific, I can try that on one of the porterboxes -- think a a sid chroot should suffice? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969684: trackballs: please upgrade to guile-3.0 soon, if feasible
Here with current bullseye, the three patches above allow the package to at least build against guile-3.0. Please consider upgrading soon. We're still planning to try to remove guile-2.2 before the freeze. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969684: [PATCH 1/3] Add headers for memset, strncpy, etc.
---
src/animatedCollection.cc | 1 +
src/flag.cc | 2 ++
src/fountain.cc | 2 ++
src/goal.cc | 2 ++
src/guile.cc | 1 +
src/highScore.cc | 1 +
src/settings.cc | 1 +
src/weather.cc| 2 ++
8 files changed, 12 insertions(+)
diff --git a/src/animatedCollection.cc b/src/animatedCollection.cc
index 2b90be0..cff826c 100644
--- a/src/animatedCollection.cc
+++ b/src/animatedCollection.cc
@@ -23,6 +23,7 @@
/* For std::sort, std::nth_element */
#include
+#include
#include
static int AC_DEBUG = 0;
diff --git a/src/flag.cc b/src/flag.cc
index 74b4161..bbedb0b 100644
--- a/src/flag.cc
+++ b/src/flag.cc
@@ -24,6 +24,8 @@
#include "player.h"
#include "sound.h"
+#include
+
Flag::Flag(Real x, Real y, int points, int visible, Real radius)
: Animated(Role_OtherAnimated, 1) {
scoreOnDeath = points;
diff --git a/src/fountain.cc b/src/fountain.cc
index 85a7f7c..68e7973 100644
--- a/src/fountain.cc
+++ b/src/fountain.cc
@@ -23,6 +23,8 @@
#include "player.h"
#include "settings.h"
+#include
+
Fountain::Fountain(const Coord3d , double randomSpeed, double radius,
double strength)
: Animated(Role_OtherAnimated, 1),
randomSpeed(randomSpeed),
diff --git a/src/goal.cc b/src/goal.cc
index b55e1e5..0070c0b 100644
--- a/src/goal.cc
+++ b/src/goal.cc
@@ -24,6 +24,8 @@
#include "map.h"
#include "player.h"
+#include
+
Goal::Goal(Real x, Real y, int rotate, char *nextLevel) : Flag(x, y, 1000, 1,
0.2) {
strncpy(this->nextLevel, nextLevel, sizeof(this->nextLevel));
this->rotate = rotate;
diff --git a/src/guile.cc b/src/guile.cc
index ade906b..655cf65 100644
--- a/src/guile.cc
+++ b/src/guile.cc
@@ -55,6 +55,7 @@
#include
#include
+#include
/* Object coordinates are shifted by DX/DY relative to map coordinates in the
API
* Thus, a flag, ball, etc. placed at (222,225) will appear at (222+DX,225+DY)
diff --git a/src/highScore.cc b/src/highScore.cc
index 2b6da98..a1d05cc 100644
--- a/src/highScore.cc
+++ b/src/highScore.cc
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
static char highScorePath[256];
diff --git a/src/settings.cc b/src/settings.cc
index e9c2a1a..4e6478b 100644
--- a/src/settings.cc
+++ b/src/settings.cc
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
extern double timeDilationFactor;
diff --git a/src/weather.cc b/src/weather.cc
index a72de8b..1fd340a 100644
--- a/src/weather.cc
+++ b/src/weather.cc
@@ -24,6 +24,8 @@
#include "player.h"
#include "settings.h"
+#include
+
Weather::Weather() {
if (Settings::settings->gfx_details <= 2) max_weather_particles = 500;
if (Settings::settings->gfx_details == 3) max_weather_particles = 1000;
--
2.29.2
Bug#969684: [PATCH 2/3] Support Guile 3.0
---
cmake/FindGuile.cmake | 13 -
src/guile.h | 2 +-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/cmake/FindGuile.cmake b/cmake/FindGuile.cmake
index 8b93daa..3dd670b 100644
--- a/cmake/FindGuile.cmake
+++ b/cmake/FindGuile.cmake
@@ -2,15 +2,18 @@
# Note: `guile-config` ultimately calls pkg-config anyway
# Nothing gets marked `advanced` since there aren't that many variables
-find_program(GUILE_SNARF NAMES guile-snarf guile-snarf2.2 guile-snarf2.0)
+find_program(GUILE_SNARF NAMES guile-snarf guile-snarf-3.0 guile-snarf2.2
guile-snarf2.0)
# PkgConfig is only there to provide hints
find_package(PkgConfig)
pkg_check_modules(PC_GUILE QUIET guile)
if (NOT PC_GUILE_FOUND)
- pkg_check_modules(PC_GUILE QUIET guile-2.2)
+ pkg_check_modules(PC_GUILE QUIET guile-3.0)
if (NOT PC_GUILE_FOUND)
-pkg_check_modules(PC_GUILE QUIET guile-2.0)
+pkg_check_modules(PC_GUILE QUIET guile-2.2)
+if (NOT PC_GUILE_FOUND)
+ pkg_check_modules(PC_GUILE QUIET guile-2.0)
+endif(NOT PC_GUILE_FOUND)
endif(NOT PC_GUILE_FOUND)
endif(NOT PC_GUILE_FOUND)
@@ -19,9 +22,9 @@ set(GUILE_DEFINITIONS ${PC_GUILE_CFLAGS_OTHER})
find_path(GUILE_INCLUDE_DIR libguile.h
HINTS ${PC_GUILE_INCLUDEDIR} ${PC_GUILE_INCLUDE_DIRS}
- PATH_SUFFIXES guile guile/2.2 guile/2.0)
+ PATH_SUFFIXES guile guile/3.0 guile/2.2 guile/2.0)
-find_library(GUILE_LIBRARY NAMES guile guile-2.2 guile-2.0
+find_library(GUILE_LIBRARY NAMES guile guile-3.0 guile-2.2 guile-2.0
HINTS ${PC_GUILE_LIBDIR} ${PC_GUILE_LIBRARY_DIRS} )
include(FindPackageHandleStandardArgs)
diff --git a/src/guile.h b/src/guile.h
index 26484fb..d1ec12d 100644
--- a/src/guile.h
+++ b/src/guile.h
@@ -21,7 +21,7 @@
#ifndef GUILE_H
#define GUILE_H
-#include
+#include
void initGuileInterface();
SCM smobAnimated_make(class Animated* a);
--
2.29.2
Bug#969684: [PATCH 3/3] Update debian/control for guile-3.0
--- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index c84c21c..4348162 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,7 @@ Build-Depends: cmake, debhelper (>= 11), gettext, - guile-2.2-dev, + guile-3.0-dev, libsdl2-dev, libsdl2-image-dev, libsdl2-mixer-dev, -- 2.29.2
Bug#972861: emacs: please make the generated .el files reproducible
"Chris Lamb" writes: > Hi Emacs maintainers, > >> emacs: please make the generated .el files reproducible > > Would it be possible to apply this patch or otherwise address this > issue? Since filing this bug I can count 160+ packages that are now > unreproducible in unstable due to this. Thanks for considering. Apologies for the slow response, and I'll try to take a look this weekend. Happy to help sort it out. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#973572: emacs: man page timeout resets page
Bob Proulx writes: > emacs -Q# no configuration > M-x man RET # look at a man page > ls RET # something a few pages long > C-x o # go there > M-> # jump to the bottom > C-x o # return to original buffer > > Wait about 2 seconds and the man page buffer jumps back to the top of > the man page buffer!? Of course that makes it hard to read the passage > I was wanting to review! Hmm, I don't see that here. That is, after the final C-x o, the manpage buffer continues to show the ls "SEE ALSO" section. I wonder if "something else" could be interfering. If it's easy, I suppose you might try creating a new user account, and see if still happens there too. And you could probably eliminate more variables by testing in a minimal debian VM, particularly if you also see the problem via the console (i.e. emacs -nw). One option: $ mkdir test-emacs $ cd test-emacs $ vagrant init debian/testing64 $ vagrant up $ vagrant ssh $ sudo -i # apt install emacs ... test # shutdown -h now $ vagrant destroy $ cd .. $ rm -rf test-emacs For reference, I ran emacs from a terminal from within sway. Oh wait, do you have emacs-gtk or emacs-lucid installed? I only use the latter[1], so maybe that matters, if you're using the former... [1] https://gitlab.gnome.org/GNOME/gtk/issues/221 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#972885: emacs: Bundled Gnus unable to enter any group
Florent Rougon writes: > The problem can be solved either by me not using the above configuration > bit anymore (which is of course a regression), or by making the > `article' variable use dynamic binding before the failing `funcall' in > `gnus-summary-highlight-line' (see the attached patch; the change could > probably be done earlier in the function, along with the other similar > defvar's, but I've only tested the attached patch). > > Regards Nice catch. Have you, or are you already planning to post this upstream? -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#972846: github-backup: always says "Run again later"
Package: github-backup Version: 1.20200721-2 I might well be doing something wrong, but I haven't been able to back up a repository, e.g.: $ git clone https://github.com/bup/bup.git $ cd bup $ github-backup Retrying 7 requests that failed last time... Gathering metadata for https://github.com/bup/bup.git ... Backup may be incomplete; 7 requests failed: 1 forks 1 issues 1 milestones 1 pullrequests 1 stargazers 1 userrepo 1 watchers Run again later. And I get that same result every time, even after waiting a while and trying again. If it matters, that repository has issues disabled, but not pull requests. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#972845: github-backup: control homepage link is no longer reachable
Package: github-backup Perhaps here here now: https://github-backup.branchable.com/ As indicated by: https://joeyh.name/code/github-backup/ Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969672: gnutls28: please upgrade to guile-3.0 soon, if feasible
Andreas Metzler writes: > I would love to, but guile-3.0 >= 3.0.4-1+b1 seems to be broken. See > 969640. Assuming I did it right (guile-3.0-dev was installed along with all the other build deps, and guile-2.2-dev wasn't), a "fakeroot debian/rules binary" just built without trouble here using the current 3.6.15-4 package. I wonder if the problem has been resolved, or maybe it's intermittent, arch dependent, or something else. And was the failure local, or on the buildds? I can double-check in a sid sbuild chroot later. (When it succeeded, I was just using the system I had handy, which is somewhere between bullseye and sid (x86_64).) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#969752: lists.debian.org: Request for a new list: debian-scheme
Looks like my email address might have been slightly off, but for the record, I'd have been fine with it too. (Thanks to Vagrant for pointing this out to me.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#968403: numbers.test fails on i386
[When possible/appropriate, please preserve the 968403-forwarded address in replies.] This was recently discovered by the Debian buildds in the unstable distribution, and I can reliably reproduce it on an i386 porterbox in an unstable i386 chroot. Please let me know if I can assist with any further diagnostics. Matthias Klose writes: > Package: src:guile-3.0 > Version: 3.0.4-1 > Severity: serious > Tags: sid bullseye > > only seen on i386, not on other architectures. > > [...] > Running numbers.test > FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: > (130.0 10/7) > FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: (130.0 > -10/7) > FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (130.0 > 10/7) > FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (-130.0 > -10/7) > FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (130.0 > -10/7) > FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (-130.0 > 10/7) > FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 > 10/7) > FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 > -10/7) > FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: > (-130.0 10/7) > FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (-130.0 > -10/7) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#968955: dictionaries-common: crashes emacs 27.1 at startup
Package: dictionaries-common
Version: 1.28.1
Looks like dictionaries-common might need a bit of adjusttment for emacs
27.1 (now in experimental). At startup it crashes like this:
Debugger entered--Lisp error: (void-variable ispell-menu-map-needed)
debian-ispell-build-startup-menu(("american" "british" "canadian"
"castellano8" "english"))
debian-ispell-set-startup-menu()
run-hooks(after-init-hook delayed-warnings-hook)
command-line()
normal-top-level()
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#968439: Please package emacs 27
Nicholas D Steeves writes: > Hi Thomas, > > Thomas Koch writes: > >> Package: emacs >> Severity: wishlist >> X-Debbugs-CC: debian-emac...@lists.debian.org >> >> Thank you! Any help needed? >> >> https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.27.1 > > :-) Rob is working on it. Maybe join #debian-emacs for up-to-the-minute > updates? Ahh, right, sorry -- meant to reply here, and was going to add this bug to the "Closes" when we finish. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#851639: ITP: alacritty -- A cross-platform, GPU-accelerated terminal emulator
While I don't know much about alacritty, I just happended to notice that the underlying issue might have been resolved a couple of days ago: https://github.com/alacritty/alacritty/issues/357 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#966301: guile oom test fails on ppc64el
Matthias Klose writes: > https://buildd.debian.org/status/fetch.php?pkg=guile-2.2=ppc64el=2.2.7%2B1-5.1=1595497537=0 > > Apparently this is known, and already reported by Debian: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=+29464 > but no update since 2017. > > For some reason the test succeeds on the Ubuntu buildds. I believe we originally avoided this via # https://debbugs.gnu.org/29464 export DEB_CFLAGS_MAINT_APPEND += -fno-stack-protector in debian/rules. I wonder if that doesn't avoid the problem anymore, or somehow the option's no longer making it all the way through. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#966160: github-backup: please consider updating to 1.20200721
Package: github-backup Severity: wishlist Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
Bdale Garbee writes: > However, I see little chance of geda-gaf upstream working on the things > needed to keep it viable in Debian any time soon, and with lepton-eda in > my mind a complete replacement that still works with the same file > formats, etc, I see no reason to go nuts trying to make geda-gaf better. > > I'll file a removal request for geda-gaf. OK, thanks for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#961230: guile-2.2 FTBFS with make-dfsg/4.3-1: ERROR: alternatives priority expects min version < 1000.
Helmut Grohne writes: > It is surprising that this didn't fail with earlier versions of make. > The shell substitution is clearly wrong. It is unclear what it is > supposed to achieve. In any case, deleting these lines makes the build > proceed. > Hah, I just hit and fixed this last night when I was updating us to 3.0.4 (see 3.0.4-1). And yeah, that was wrong. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
Bdale Garbee writes: > I'm not interested in maintaining pcb any more. Does that mean geda-gaf etc? If so might it make sense for you (or who?) to file a removal request, i.e. ROM or similar? (I can of course, but I suspect it'll be more quickly accepted if one of the existing maintainers does.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#965054: guile-2.0 ftbfs on unstable (test failure)
Matthias Klose writes:
> After fixing the build with make 4.3, the build then fails with a test
> failure.
> Only seen on amd64, not on other architectures.
>
> [...]
> make check-TESTS
> make[4]: Entering directory '/<>/guile-2.0-2.0.13+1'
> Testing /<>/guile-2.0-2.0.13+1/meta/guile ...
> with GUILE_LOAD_PATH=/<>/guile-2.0-2.0.13+1/test-suite
> Running 00-initial-env.test
> Running 00-repl-server.test
> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack -
> arguments:
> ((system-error "fport_write" "~A" ("Broken pipe") (32)))
I'll try to remember to look in a bit, but that rings a vague bell -- we
may have added some patches (debian, and/or later upstream) for issues
there.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2
ES = .x snarf_cpp_opts = $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ $(libgeda_la_CPPFLAGS) $(AM_CFLAGS) $(libgeda_la_CFLAGS) .c.x: - CPP="$(CPP)" $(GUILE_SNARF) -o $@ $< $(snarf_cpp_opts) + CPP="$(CPP)" guile-snarf-$(GUILE_EFFECTIVE_VERSION) -o $@ $< $(snarf_cpp_opts) MOSTLYCLEANFILES = *.log core FILE *~ CLEANFILES = *.log core FILE *~ $(BUILT_SOURCES) diff --git a/missing.h b/missing.h index 1d4666a..e69de29 100644 --- a/missing.h +++ b/missing.h @@ -1,39 +0,0 @@ - -/* This file contains preprocessor macros which provide substitutes - * for missing functions or other definitions based on the results of - * configure. */ - -/* We need to be able to pass UTF-8 strings to and from libguile. The - * most forward-compatible way to do this is to explicitly use the - * "utf8" API for doing so, but this API is only available from Guile - * 2.0 onwards. - * - * In Guile 2.0 there is a similar "locale" API which encodes/decodes - * strings differently based on the locale, so we need to avoid it in - * case the user decides to set a non-UTF-8 locale. However, the - * "locale" API *is* present in Guile 1.8, in which it doesn't attempt - * to encode/decode the strings its passed, so we can use it as a - * direct replacement for the "utf8" API. - * - * Confused yet? - */ - -#ifndef HAVE_SCM_FROM_UTF8_STRINGN -# define scm_from_utf8_stringn scm_from_locale_stringn -#endif -#ifndef HAVE_SCM_FROM_UTF8_STRING -# define scm_from_utf8_string(x) scm_from_utf8_stringn ((x), -1) -#endif -#ifndef HAVE_SCM_TO_UTF8_STRINGN -# define scm_to_utf8_stringn scm_to_locale_stringn -#endif -#ifndef HAVE_SCM_TO_UTF8_STRING -# define scm_to_utf8_string(x) scm_to_utf8_stringn ((x), NULL) -#endif - -#ifndef HAVE_SCM_FROM_UTF8_SYMBOLN -# define scm_from_utf8_symboln scm_from_locale_symboln -#endif -#ifndef HAVE_SCM_FROM_UTF8_SYMBOL -# define scm_from_utf8_symbol scm_from_locale_symbol -#endif Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#963222: readline: manpage has , but pc -I requires
Package: libreadline-dev Version: 8.0-4 The manpage indicates the correct #include is #include , but pkg-config produces a -I line for #include . I'd guess one of them is incorrect, and since the upstream info pages also mention the former, I'd guess the pkg-config specification is incorrect, i.e. perhaps it should output -I/usr/include instead. >From "man readline" SYNOPSIS #include #include #include >From "pkg-config readline --cflags": $ pkg-config readline --cflags -I/usr/include/readline -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 And we have: $ find /usr/include/readline* /usr/include/readline /usr/include/readline/rltypedefs.h /usr/include/readline/rlstdc.h /usr/include/readline/chardefs.h /usr/include/readline/tilde.h /usr/include/readline/keymaps.h /usr/include/readline/readline.h /usr/include/readline/history.h /usr/include/readline/rlconf.h Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#961459: linux-signed-arm64: option that might support raspberry pi 4 usb
Package: linux-signed-arm64 Version: 5.7~rc5-1~exp1 At least from this comment, https://github.com/lategoodbye/rpi-zero/issues/43#issuecomment-611780458 it looks like we might need CONFIG_PCIE_BRCMSTB=m to allow USB to work on the pi 4. I can verify that 5.7~rc5-1~exp1 boots fine on one, all the way to a tt1 login, but there appears to be no USB power, i.e. a keyboard or mouse plugged in does not respond, and the normal power leds on the keboard and mouse don't light. If I get a chance and figure out how, I can try to build a local kernel with that option and test it, or I could fairly quickly test any version uploaded somewhere like experimental. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#961447: bup: 0.30.1 released, fixing notable bugs
Package: bup Version: 0.29.3 Just released 0.30.1, including some notable bug fixes. I'd recommend replacing the version in sid if feasible: https://github.com/bup/bup/blob/0.30.x/note/0.30.1-from-0.30.md Perhaps worth mentioning that 0.30.* still doesn't support python 3. We're finishing up python 3 support for the next non-Z version (likely 0.31, hopefully "soon"). Thanks much -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885195: geda-gaf: please migrate to guile-2.2
Please try to migrate soon, and at this point, to guile-3.0 if possible. Otherwise we might need to consider removing the package from Debian. Sometimes it's sufficient to just update the build dependency from say guile-2.0-dev to guile-3.0-dev and adjust some of the related versions in configure.ac (or configure.in). I may investigate further myself if I have time, but please don't rely on that. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885188: freehdl: please migrate to guile-2.2
Please try to update this soon, or we'll need to consider removing freehdl from Debian, and if possible please attempt to move to guile-3.0 instead of guile-2.2 now, if possible. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885212: libmatheval: please migrate to guile-2.2
I think we probaly either need to address this soon, or consider removing libmatheval from Debian. Sometimes it's sufficient to just update the build dependency from say guile-2.0-dev to guile-3.0-dev and adjust some of the related versions in configure.ac (or configure.in), but in this case it looks like more might be required. When I make those adjutments to 3.0 with the current package I see some SCM related type errors which I suspect are problems with the types/prototypes in the library, i.e. int is (and was) not (transparently) interchangable with SCM. I may investigate further myself if I have time, but please don't rely on that. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885198: graphviz: please migrate to guile-2.2
It appears that this hasn't actually been resolved. i.e. after grabbing the current sid source (and an ldd on the current libgv-guile .so also indicates it's still built against 2.0): $ rgrep guile | grep -F 2.0 debian/control: guile-2.0-dev, debian/control: This package contains the guile (2.0) bindings. debian/changelog: * Build using guile-2.0. Closes: #746012. debian/changelog:- Build using guile-2.0. debian/changelog: * Build using guile-2.0. configure.ac: [guile-2.0 >= "$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"], .pc/build_with_libann.patch/configure.ac: [guile-2.0 >= "$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"], .pc/versioned-plugin-config-file.diff/configure.ac: [guile-2.0 >= "$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"], .pc/50_remove_changelog_in/configure.ac:[guile-2.0 >= "$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"], .pc/ruby-config.diff/configure.ac: [guile-2.0 >= "$GUILE_VERSION_MAJOR.$GUILE_VERSION_MINOR"], Oh, and if feasible, please consider migrating directly to guile-3.0 instead. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885215: mcron: please migrate to guile-2.2 (NMU diff 1.0.8-1.1)
---
configure.ac | 2 +-
debian/changelog | 14 ++
debian/control| 4 +-
debian/patches/migrate-to-guile-3.0 | 13 ++
debian/patches/series | 1 +
debian/rules | 2 +-
create mode 100644 debian/patches/migrate-to-guile-3.0
diff --git a/configure.ac b/configure.ac
index 764ea03..881d8d3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -48,7 +48,7 @@ AC_PROG_AWK
AC_PROG_EGREP
AM_PROG_CC_C_O
-PKG_CHECK_MODULES(GUILE, guile-2.0)
+PKG_CHECK_MODULES(GUILE, guile-3.0)
# Checks for programs.
diff --git a/debian/changelog b/debian/changelog
index 9b46497..1a40b55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+mcron (1.0.8-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ * configure.ac: migrate to guile-3.0.
+
+ * debian/control: migrate to guile-3.0. (Closes: 885215)
+
+ * debian/control: build-depend on texinfo for makeinfo.
+
+ * debian/rules: request autoreconf to fix gcc invocations.
+
+ -- Rob Browning Sat, 25 Apr 2020 18:03:00 -0500
+
mcron (1.0.8-1) unstable; urgency=low
* New upstream release.
diff --git a/debian/control b/debian/control
index 255fb63..e376c18 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: mcron
Section: utils
Priority: optional
Maintainer: Dale Mellor
-Build-Depends: debhelper (>= 9), guile-2.0-dev, ed, help2man
+Build-Depends: debhelper (>= 10), guile-3.0-dev, ed, help2man, texinfo
Standards-Version: 3.9.5
Homepage: http://www.gnu.org/software/mcron
@@ -11,7 +11,7 @@ Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
dpkg (>= 1.15.4)|install-info,
- guile-2.0,
+ guile-3.0,
sendmail|mail-transport-agent
Description: Guile-based program for running jobs at regular times
The GNU package mcron (Mellor's cron) can be a 100% compatible replacement for
diff --git a/debian/patches/migrate-to-guile-3.0
b/debian/patches/migrate-to-guile-3.0
new file mode 100644
index 000..83f5ead
--- /dev/null
+++ b/debian/patches/migrate-to-guile-3.0
@@ -0,0 +1,13 @@
+Index: main/configure.ac
+===
+--- main.orig/configure.ac
main/configure.ac
+@@ -48,7 +48,7 @@ AC_PROG_AWK
+ AC_PROG_EGREP
+ AM_PROG_CC_C_O
+
+-PKG_CHECK_MODULES(GUILE, guile-2.0)
++PKG_CHECK_MODULES(GUILE, guile-3.0)
+
+ # Checks for programs.
+
diff --git a/debian/patches/series b/debian/patches/series
index eeb6f6b..5949e95 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
disable-maintainer-mode.patch
make-clean.patch
+migrate-to-guile-3.0
diff --git a/debian/rules b/debian/rules
index f11d5f0..e319d13 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@
#export DH_VERBOSE=1
%:
- dh $@
+ dh $@ --with autoreconf
override_dh_auto_configure:
dh_auto_configure -- --enable-no-vixie-clobber
--
2.26.1
Bug#885213: make-dfsg: please migrate to guile-2.2
Closes: 885213 --- This is the 4.2.1-1.3 NMU diff against 4.2.1-1.2. The source of the 4.2.1-1.2 code was master at https://salsa.debian.org/benh/make-dfsg The source of this NMU is debian/master at https://salsa.debian.org/rlb/make-dfsg Thanks configure.ac | 4 ++-- debian/changelog | 6 ++ debian/control | 2 +- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 02481ec..eeac949 100644 --- a/configure.ac +++ b/configure.ac @@ -168,8 +168,8 @@ AC_ARG_WITH([guile], [AS_HELP_STRING([--with-guile], # comes with it's own PC file so we have to specify them as individual # packages. Ugh. AS_IF([test "x$with_guile" != xno], -[ PKG_CHECK_MODULES([GUILE], [guile-2.0], [have_guile=yes], - [PKG_CHECK_MODULES([GUILE], [guile-1.8], [have_guile=yes], +[ PKG_CHECK_MODULES([GUILE], [guile-3.0], [have_guile=yes], + [PKG_CHECK_MODULES([GUILE], [guile-2.2], [have_guile=yes], [have_guile=no])]) ]) diff --git a/debian/changelog b/debian/changelog index ad02528..9f194ba 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +make-dfsg (4.2.1-1.3) unstable; urgency=medium + + * Build against guile-3.0; drop 1.8 and 2.0. (Closes: 885213) + + -- Rob Browning Fri, 24 Apr 2020 19:36:46 -0500 + make-dfsg (4.2.1-1.2) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/control b/debian/control index e251b40..3588b46 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,7 @@ Standards-Version: 4.1.3 Homepage: https://www.gnu.org/software/make/ Build-Depends: gettext, po-debconf, debhelper (>= 9.0.0), dh-autoreconf, autoconf, automake | automaken, autopoint, file, pkg-config, - guile-2.0-dev, procps, libbsd-resource-perl + guile-3.0-dev, procps, libbsd-resource-perl Package: make Suggests: make-doc -- 2.26.1
Bug#944616:
Nick Gasson writes: > I had a look at this. It's possible to reproduce the failure inside > qemu-mipsel-static. The test set-process-filter-t is fundamentally racy: > it reads output from a sub-process and compares that to an expected > value. But on a slow machine it's possible to get a partial read from > the child process which causes the test to fail. I don't think it's > anything related to MIPS per se. > > This has already been fixed upstream. See here: > > https://git.savannah.gnu.org/cgit/emacs.git/commit?id=aa49aa884053d0e8b33efe265f2aade19d1f3f3d > > Maybe we can import the above patch or mark this test as unstable? Thanks much for he investigation. I'll see about doing something like that in the next upload. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885215: mcron: please migrate to guile-2.2
This patch appears to at least allow mcron to build against guile-3.0-dev.
diff --git a/configure.ac b/configure.ac
index 764ea03..881d8d3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -48,7 +48,7 @@ AC_PROG_AWK
AC_PROG_EGREP
AM_PROG_CC_C_O
-PKG_CHECK_MODULES(GUILE, guile-2.0)
+PKG_CHECK_MODULES(GUILE, guile-3.0)
# Checks for programs.
diff --git a/debian/control b/debian/control
index 255fb63..ef7c794 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: mcron
Section: utils
Priority: optional
Maintainer: Dale Mellor
-Build-Depends: debhelper (>= 9), guile-2.0-dev, ed, help2man
+Build-Depends: debhelper (>= 9), guile-3.0-dev, ed, help2man
Standards-Version: 3.9.5
Homepage: http://www.gnu.org/software/mcron
@@ -11,7 +11,7 @@ Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
dpkg (>= 1.15.4)|install-info,
- guile-2.0,
+ guile-3.0,
sendmail|mail-transport-agent
Description: Guile-based program for running jobs at regular times
The GNU package mcron (Mellor's cron) can be a 100% compatible replacement for
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885213: make-dfsg: please migrate to guile-2.2
Rob Browning writes: > Actually now that guile-3.0 is in sid (though it's not yet building on > all the release architectures), I suppose we might just side-step 2.2 > entirely, but either would be much appreciated. > > Here this at least builds via "fakeroot debian/rules binary", but > regardless, I'd really like to resolve this soon. I'm happy to make an > NMU if that's preferable. I'm planning to make an nmu soon -- in particular because some changes I'm making to guile-2.2 and guile-3.0 may force 2.0 out of unstable. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#885213: make-dfsg: please migrate to guile-2.2
Actually now that guile-3.0 is in sid (though it's not yet building on all the release architectures), I suppose we might just side-step 2.2 entirely, but either would be much appreciated. Here this at least builds via "fakeroot debian/rules binary", but regardless, I'd really like to resolve this soon. I'm happy to make an NMU if that's preferable. Thanks $ git diff diff --git a/configure.ac b/configure.ac index 02481ec..476f549 100644 --- a/configure.ac +++ b/configure.ac @@ -168,7 +168,7 @@ AC_ARG_WITH([guile], [AS_HELP_STRING([--with-guile], # comes with it's own PC file so we have to specify them as individual # packages. Ugh. AS_IF([test "x$with_guile" != xno], -[ PKG_CHECK_MODULES([GUILE], [guile-2.0], [have_guile=yes], +[ PKG_CHECK_MODULES([GUILE], [guile-3.0], [have_guile=yes], [PKG_CHECK_MODULES([GUILE], [guile-1.8], [have_guile=yes], [have_guile=no])]) ]) diff --git a/debian/control b/debian/control index e251b40..3588b46 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,7 @@ Standards-Version: 4.1.3 Homepage: https://www.gnu.org/software/make/ Build-Depends: gettext, po-debconf, debhelper (>= 9.0.0), dh-autoreconf, autoconf, automake | automaken, autopoint, file, pkg-config, - guile-2.0-dev, procps, libbsd-resource-perl + guile-3.0-dev, procps, libbsd-resource-perl Package: make Suggests: make-doc -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#949984: sway: noticed 1.4 release (which may fix some issues I've had)
Rob Browning writes: > Package: sway > Severity: wishlist > > Looks like 1.4 has been released (1.3 was apparently skipped), and I > suspect it might address some of the repeated crashes I've experienced > when switching monitor inputs and/or plugging/unplugging a thunderbolt > connection. > > Thanks much for the packaging work. Oh, just happened to notice wlroots in NEW -- suspect you're well underway. Thanks again -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#949984: sway: noticed 1.4 release (which may fix some issues I've had)
Package: sway Severity: wishlist Looks like 1.4 has been released (1.3 was apparently skipped), and I suspect it might address some of the repeated crashes I've experienced when switching monitor inputs and/or plugging/unplugging a thunderbolt connection. Thanks much for the packaging work. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#949400: RM: guile-2.0 -- ROM; replaced by guile-2.2
Package: ftp.debian.org User: release.debian@packages.debian.org Usertags: rm Since guile-3.0 is incoming, I'd like to finally remove guile-2.0. I believe "please upgrade" bugs have been standing against the reverse dependencies for over two years. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#930774: any idea when guile-2.2 will be fixed ?
shirish शिरीष writes: > Ah, thank you fixing any python 3 messes as well. Well aware of the > transition happening. Haven't hit any major road-blocks yet, so all is > good :) OK, 2.2.4+1-2+deb10u1 uploaded to buster (if I did it right), and will hopefully fix the problem. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#930774: any idea when guile-2.2 will be fixed ?
shirish शिरीष writes: > Just saw this, any idea when this FTFBS will be fixed. Somebody even > shared a patch, maybe that fixes the issue. I'll plan to investigate this weekend. (I've been unfortunately preoccupied with python 3 related messes for a while.) Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#946691: emacs25-common: expired GNU ELPA gpg key
Thomas Sanders writes: > Package: emacs25-common > Version: 25.1+1-4+deb9u1 > Severity: normal > File: /usr/share/emacs/25.1/etc/package-keyring.gpg > > Dear Maintainer (Rob Browning?), > > This problem in emacs 25 (in Debian old-stable) is the same as the > problem that was fixed in Debian current stable (buster) emacs 26 > with this changelog message: > https://metadata.ftp-master.debian.org/changelogs//main/e/emacs/emacs_26.1+1-3.2+deb10u1_changelog > [START-QUOTATON] > emacs (1:26.1+1-3.2+deb10u1) buster; urgency=high > > * Update the EPLA packaging key (previous key expires 2019-09-23) via > the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911. Add the > old and new keyrings to debian/ and debian/source/include-binaries > since debian/patches/ can't handle git binary diffs. Thanks to Stefan > Monnier for reporting the problem and providing the patch. > > -- Rob Browning Wed, 04 Sep 2019 21:35:24 -0500 > [END-QUOTATION] Ahh, so it sounds like it we might want to try to fix this in LTS too. Assuming so, and if no one else handles it before I get to it, I'll try to see how that process works, and if the change would be acceptable. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#942413: [emacs] Installation of packages from GNU ELPA fails due to expired key
Michael Kesper writes: > Dear maintainers, > > I don't think this is an adequate solution as that version does not get > installed > by default, even if buster-updates are enabled. > The version in buster is just broken without this patch. Sure, until the buster-updates make it in to buster proper (unless the default priorities are changed in /etc/apt/preferences -- apt-preferences(5))? Assuming I don't misunderstand the situation. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#942413: [emacs] Installation of packages from GNU ELPA fails due to expired key
Michael Kesper writes: > Please update the included keyring (or use a newer upstream where it's > included). I believe the fixes should be in buster-updates and bullseye: https://packages.debian.org/emacs https://metadata.ftp-master.debian.org/changelogs//main/e/emacs/emacs_26.1+1-3.2+deb10u1_changelog https://metadata.ftp-master.debian.org/changelogs//main/e/emacs/emacs_26.1+1-4_changelog but please feel free to re-open the bug if if you don't feel that adequately addresses the problem. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#940862: closed by Birger Schacht (Bug#940862: fixed in sway 1.2-1)
"Debian Bug Tracking System" writes: > Source: sway > Architecture: source > Version: 1.2-1 > Distribution: experimental > Urgency: medium > Maintainer: Sway and related packages team > Changed-By: Birger Schacht > Closes: 940862 > Changes: > sway (1.2-1) experimental; urgency=medium > . >* New upstream version (Closes: #940862) Thanks much! -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
