Bug#1031888: Bug#1069943: bullseye-pu: package emacs/27.1+1-3.1+deb11u3
control: tag -1 - moreinfo Hello Jonathan, On Sun 12 May 2024 at 09:00pm +01, Jonathan Wiltshire wrote: > The security release hasn't been accepted into bullseye yet because > there were reports of it being broken on mips64el. There was a bug but > I'm afraid I don't have a reference to it. I believe this was #1031888. > Do you know if your version solves the issue? Upstream addressed the memory leak that Adrian thought might be causing #1031888. I prepared a deb11u4 in git which includes that fix. Unfortunately, however, #1031888 is no longer reproducible. Adam took a look at my deb11u4 (thank you), but the buildds which were previously showing the problem are no longer running bullseye. I just tried preparing a mips64el qemu image and booting that, but the problem is not reproducible there: deb11u2 installs fine. How should we proceed? -- Sean Whitton signature.asc Description: PGP signature
Bug#1031888: emacs-nox: bullseye-security update fails to install on mips64el
control: reopen 1031888 Hello Adam, On Fri 21 Apr 2023 at 10:19am +01, Adam D. Barratt wrote: > On Fri, 2023-04-21 at 12:08 +0300, Adrian Bunk wrote: >> On Tue, Mar 14, 2023 at 02:04:19PM -0700, Sean Whitton wrote: >> > Version: 1:28.2+1-11 >> > >> > Hello, >> > >> > On Sun 26 Feb 2023 at 09:41PM +02, Adrian Bunk wrote: >> > >> > > While I suspect they are the same, there is no proof that this >> > > leak is >> > > actually the same as the mips64el installation issue. >> > >> > Looks like it was. >> >> If this was confirmed, could the fix go into the next point release, >> which would require a -pu request+upload today (or early tomorrow)? >> > > With my DSA hat on, I'm not aware of it having been confirmed to fix > the issue on bullseye. I'm happy to test an updated package in the > meantime. (FWIW the update isn't in p-u currently because of this > issue.) I have prepared an update for bullseye incorporating upstream's fix for the memory leak. I would be grateful if you could test whether the mips64el installation is still reproducible. As deb11u3 is already in p-u and tagged, I've versioned this deb11u4. I've pushed it to the fix-1031888 branch of salsa:rlb/deb-emacs.git. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067630: various uploads made
fixed 1067630 1:26.1+1-3.2+deb10u5 fixed 1067663 9.1.14+dfsg-3+deb10u2 thanks I've uploaded to Emacs and Org-mode to buster-security and bullseye-proposed-updates, and Emacs to bookworm-proposed-updates. -- Sean Whitton
Bug#1069520: sbcl: FTBFS on armhf: make[1]: *** [debian/rules:53: override_dh_auto_build] Error 1
Hello, Thanks Peter. Looks like upstream might be able to commit a fix. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Mon 08 Apr 2024 at 07:15pm +02, Salvatore Bonaccorso wrote: > Hi Sebastian, > > On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote: >> control: tags -1 patch >> control: reassign -1 yapet 2.6-1 >> >> On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote: >> > There might be a related change that doesn't allow restarting the >> > operation with the same context without setting things up again. >> >> Yapet is broken and the openssl update revealed the problem. I >> reassigned it to yapet 2.6 but probably affects earlier versions. >> But then the 1.1.1 series is no longer maintained so… >> >> Patches attached and they hold the details of why and such. >> >> This needs to be applied to unstable and Bookworm. >> The testsuite passes and I can open Sean's test file. >> Further testing is welcome by actual users ;) > > Thanks for the investigation and bringing the fixes to upstream > already: https://github.com/RafaelOstertag/yapet/pull/29 >> >> I can NMU if needed just yell. > > No need for that, will take it with my maintainers hat on from here. Many thanks both. -- Sean Whitton
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 06 Apr 2024 at 03:24pm +02, Salvatore Bonaccorso wrote: > As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is > it reassigned to yapet? (the regression is as well present in > unstable). I was just thinking that it may be a flaw in how YAPET calls into openssl, and we don't have evidence either way atm. > That said: You are right, opening 1.0 format databases should still > work that said, but is regressing with the openssl update. And as per > manpage: YAPET 2.0 will read and write pre YAPET 2.0 files. Pre YAPET > 2.0 files are converted to YAPET 2.0 files when changing the master > password. Once converted, the files can no longer be read by pre YAPET > 2.0 versions. > > I can ask upstream, but currently yapet will FTBFS with problems in > the testsuite anyway, and the problems are related. > > And yapet FTBFS with the new openssl in bookworm-pu in same way as in > unstable (but not with the old version). > > Thus I believe #1068045 and #1064724 are actually related. Thanks for the info. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 06 Apr 2024 at 09:30pm +02, Sebastian Andrzej Siewior wrote: > On 2024-04-06 17:17:45 [+0800], Sean Whitton wrote: >> Hello, > Hi, > >> It looks like the problem is opening YAPET1.0-format databases, which >> the manpage explicitly says is meant to work. >> >> I've made a sample YAPET1.0 database using a stretch VM. Using the >> attached: >> >> - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it. >> - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't. > > Thank you for the testcase. It asks for a password, what is it? Sorry! It's 'asdf'. -- Sean Whitton
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: > On 30 March 2024 13:14:37 CET, Sean Whitton wrote: > >>I downgraded, changed the password for my database to 'asdf', >>changed it back to the password it had before, upgraded libssl3, >>and the bug did not appear. >> >>I reverted to my original db, downgraded again, deleted an entry without >>changing the password, upgraded, and the bug appeared. >> >>I can't really say more without compromising my opsec. But does the >>above give any clues / further debugging ideas? > > I would look at the function yapet is using from openssl and compare the > results. > Could create a database from scratch an use similar patterns in terms number > of entries and password (length, special characters) until you have something > that you can share with me. I don't mind if throw it in my inbox without Cc: > the bug. It looks like the problem is opening YAPET1.0-format databases, which the manpage explicitly says is meant to work. I've made a sample YAPET1.0 database using a stretch VM. Using the attached: - On bookworm, invoke 'yapet yapet1.0.pet', and you can decrypt it. - On stable or on bookworm with libssl3/3.0.13-1~deb12u1, you can't. Thanks again. -- Sean Whitton yapet1.0.pet Description: Binary data signature.asc Description: PGP signature
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
control: reassign -1 libssl3,yapet control: found -1 libssl3/3.1.5-1 control: found -1 yapet/2.6-1 control: retitle -1 libssl3,yapet: YAPET cannot decrypt YAPET1.0-format DB Hello, On Sat 30 Mar 2024 at 03:01pm +01, Sebastian Andrzej Siewior wrote: >> >>> Also, yapet is unchanged in unstable. Is the problem there, too? >> I have now confirmed that the problem is in unstable too. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
control: tag -1 + pending Hello, On Sat 06 Apr 2024 at 01:23am -04, Daniel Kahn Gillmor wrote: > On Sat 2024-04-06 11:40:14 +0800, Sean Whitton wrote: >> On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote: >> >>> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote: >>>> Thanks, but can you sign this off? Ty! >>> >>> Sure, attached. Let me know if you need anything different. >> >> Thanks. Unfortunately, it doesn't seem to fix the FTBFS, on sid. > > Here is a replacement patch, tested now against mypy 1.9.0-4. It also > updates the typechecking for imap-dl for the same version of mypy. Thanks! Just to note that I also had to add python3-gssapi as a b-d. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
Hello, On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote: > On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote: >> Thanks, but can you sign this off? Ty! > > Sure, attached. Let me know if you need anything different. Thanks. Unfortunately, it doesn't seem to fix the FTBFS, on sid. -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
Thanks, but can you sign this off? Ty! -- Sean Whitton
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET
Hello, On Sat 30 Mar 2024 at 09:29am +01, Sebastian Andrzej Siewior wrote: > On 2024-03-30 09:25:27 [+0800], Sean Whitton wrote: >> Package: libssl3 >> Version: 3.0.13-1~deb12u1 >> Severity: grave >> Justification: renders package unusable >> X-Debbugs-Cc: t...@security.debian.org >> Control: affects -1 + yapet >> >> Dear maintainer, >> >> This version of libssl3 from bookworm-proposed-updates breaks YAPET. >> When I try to open my passwords database, it claims the master password I >> type >> is incorrect. But downgrading libssl3 fixes the problem. > > Can you give me more to go on? I installed yapet created a database, > updated and it remains to work. > Maybe supply a test database which works with the old but not with the > new library. I downgraded, changed the password for my database to 'asdf', changed it back to the password it had before, upgraded libssl3, and the bug did not appear. I reverted to my original db, downgraded again, deleted an entry without changing the password, upgraded, and the bug appeared. I can't really say more without compromising my opsec. But does the above give any clues / further debugging ideas? > Also, yapet is unchanged in unstable. Is the problem there, too? Unfortunately I do not have an unstable machine to hand right now, and until we know more about the xz-utils situation I would want to set up something air-gapped before copying my password db in there -- but can do that if we can't otherwise make progress. Thanks for looking! -- Sean Whitton signature.asc Description: PGP signature
Bug#1068045: libssl3: breaks YAPET
Package: libssl3 Version: 3.0.13-1~deb12u1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: t...@security.debian.org Control: affects -1 + yapet Dear maintainer, This version of libssl3 from bookworm-proposed-updates breaks YAPET. When I try to open my passwords database, it claims the master password I type is incorrect. But downgrading libssl3 fixes the problem. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libssl3 depends on: ii libc6 2.36-9+deb12u5 libssl3 recommends no packages. libssl3 suggests no packages. -- no debconf information -- Sean Whitton signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
types in assignment > (expression has type "Message | str | list[Message | str] | Any", variable > has type "list[Message] | str | bytes | None") [assignment] > email-print-mime-structure:109: error: Incompatible types in assignment > (expression has type "Message | bytes | Any", variable has type > "list[Message] | str | bytes | None") [assignment] > email-print-mime-structure:121: error: Incompatible types in assignment > (expression has type "Message | bytes | Any", variable has type > "list[Message] | str | bytes | None") [assignment] > email-print-mime-structure:181: error: Incompatible types in assignment > (expression has type "Message | str | list[Message | str] | Any", variable > has type "list[Message] | str | bytes | None") [assignment] > Found 6 errors in 1 file (checked 1 source file) > make[1]: *** [Makefile:15: check] Error 1 > make[1]: Leaving directory '/<>' > dh_auto_test: error: make -j2 check returned exit code 2 > make: *** [debian/rules:4: build] Error 25 > dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > > > The above is just how the build ends and not necessarily the most relevant > part. > If required, the full build log is available here: > > https://people.debian.org/~sanvila/build-logs/202403/ > > About the archive rebuild: The build was made on virtual machines > of type m6a.large from AWS, using sbuild and a reduced chroot > with only build-essential packages. > > If you could not reproduce the bug please contact me privately, as I > am willing to provide ssh access to a virtual machine where the bug is > fully reproducible. > > If this is really a bug in one of the build-depends, please use > reassign and affects, so that this is still visible in the BTS web > page for this package. > > Thanks. > -- Sean Whitton
Bug#1066967: Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hello,
On Fri 22 Mar 2024 at 06:46pm +03, Dmitry Shachnev wrote:
> Actually, I would move ${sphinxdoc:Depends} from Recommends to
> Depends, because the documentation is mostly unusable without the
> static files.
I think it's in Recommends because we ship other formats that don't need
it, and to ensure installability on stable, or something similar.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1067630: fixed in emacs 1:29.3+1-1
Hello, On Mon 25 Mar 2024 at 04:58pm +07, Max Nikulin wrote: > On 25/03/2024 15:47, Sean Whitton wrote: >> On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote: >> >>> On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote: >>>> Source: emacs >>>> Source-Version: 1:29.3+1-1 >>>> Done: Rob Browning >>> >>> Should this issue be reopened or be cloned to backport fixes to Emacs-28 in >>> Debian stable? >> Neither are necessary. > > Do you mean that somebody is working on backporting changes to 28.2 in > bookworm already? This bug is closed. Have I missed other ones for elpa-org in > unstable and for emacs in stable? No, I just mean that the bug metadata is correct. Closed does not mean resolved in all suites. -- Sean Whitton
Bug#1067630: fixed in emacs 1:29.3+1-1
Hello, On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote: > On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote: >> Source: emacs >> Source-Version: 1:29.3+1-1 >> Done: Rob Browning > > Should this issue be reopened or be cloned to backport fixes to Emacs-28 in > Debian stable? Neither are necessary. -- Sean Whitton signature.asc Description: PGP signature
Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs
control: tag -1 - moreinfo + pending Hello, On Tue 27 Feb 2024 at 09:17am +08, Sean Whitton wrote: > Hmm, I added Breaks/Replaces, and piuparts is happy. Requesting manual > review. Thank you. Ah, my relations were missing the 1: epoch. Uploading shortly. -- Sean Whitton signature.asc Description: PGP signature
Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs
control: tag -1 + moreinfo Hello, On Mon 26 Feb 2024 at 06:26pm +01, Helmut Grohne wrote: > 4 packages from emacs have an undeclared file conflict. This may result > in an unpack error from dpkg. > > The file /usr/bin/emacsclient.emacs is contained in the packages > * emacs-bin-common >* 1:27.1+1-3.1+deb11u1 as present in bullseye >* 1:27.1+1-3.1+deb11u2 as present in bullseye-security >* 1:28.2+1-15 as present in bookworm >* 1:29.1+1-5 as present in trixie >* 1:29.1+1-5~bpo12+1 as present in bookworm-backports > * emacs-gtk/1:29.2+1-1 as present in unstable > * emacs-lucid/1:29.2+1-1 as present in unstable > * emacs-nox/1:29.2+1-1 as present in unstable > * emacs-pgtk/1:29.2+1-1 as present in unstable > > These packages can be unpacked concurrently, because there is no > relevant Replaces or Conflicts relation. Attempting to unpack these > packages concurrently results in an unpack error from dpkg, because none > of the packages installs a diversion for the affected file. Hmm, I added Breaks/Replaces, and piuparts is happy. Requesting manual review. Thank you. -- Sean Whitton signature.asc Description: PGP signature
Bug#1052967: emacsql-sqlite3: FTBFS: make: *** [debian/rules:4: build] Error 25
Hello, On Mon 09 Oct 2023 at 08:18pm +02, Aymeric Agon-Rambosson wrote: > No. In fact, I think we should not be packaging emacsql-sqlite3 anymore, and > we should use the occasion to remove it. > > The upstream maintainers themselves contend that package developers should not > use it, and rely on emacsql instead : > https://github.com/cireu/emacsql-sqlite3#important-note. > > It has no reverse dependencies, and I fail to see how it could be useful to > anyone if not as a dependency for another package. > > The next release of emacsql will not support it, and will make it obsolete, a > point of view the upstream maintainers of emacsql-sqlite3 themselves seem to > accept : https://github.com/cireu/emacsql-sqlite3/issues/38. > > It was removed from MELPA last April for this reason. Cool, would you like to file the RM bug? -- Sean Whitton signature.asc Description: PGP signature
Bug#1052967: emacsql-sqlite3: FTBFS: make: *** [debian/rules:4: build] Error 25
Hello Aymeric, On Tue 26 Sep 2023 at 03:44pm +02, Lucas Nussbaum wrote: > Source: emacsql-sqlite3 > Version: 1.0.2+git20220304.1.2113618-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230925 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Given that you maintain emacsql, would you be interested in taking over emacsql-sqlite3 as well? -- Sean Whitton signature.asc Description: PGP signature
Bug#1042889: vm: autopkgtest fails against Emacs 29.1
Hello,
On Mon 14 Aug 2023 at 10:47am +01, Ian Jackson wrote:
> Sean Whitton writes ("Bug#1042889: vm: autopkgtest fails against Emacs 29.1"):
>> vm's autopkgtest fails with Emacs 29.1, which latter is now in sid.
>>
>> https://ci.debian.net/packages/v/vm/testing/amd64/
>
> The regression was indeed caused solely by upstream renaming the
> variable that disables byte compilation, from
> native-comp-deferred-compilation-deny-list
> to
> native-comp-jit-compilation-deny-list
>
> ISTM that making that change without also honouring the old setting
> was an obviously bad idea. Upstream set us up for this failure.
> Anyway, I have fixed this issue in vm, by handling both variables.
> I expect the new vm package to migrate quickly.
Usually there's an alias added when variable names are obsoleted.
Thank you for the fix.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1050404: flycheck: keep flycheck out of testing
Source: flycheck Severity: serious flycheck is unmaintained and its fragile autopkgtest keeps stopping more important things from migrating to testing. Let's keep it out of testing for now. -- Sean Whitton signature.asc Description: PGP signature
Bug#1042889: vm: autopkgtest fails against Emacs 29.1
Hello,
On Wed 02 Aug 2023 at 02:49pm +01, Ian Jackson wrote:
> Sean Whitton writes ("Bug#1042889: vm: autopkgtest fails against Emacs 29.1"):
>> vm's autopkgtest fails with Emacs 29.1, which latter is now in sid.
>
> Hi, Sean, as you see we're looking into this.
> I have some questions for you as an Emacs expert:
>
> Is byte-compilation known to be sometimes broken? Is there a
> recommended approach to problems caused by byte-compilation ?
The bytecompiler tends to get fussier with each Emacs release.
Usually it's worth fixing the problems with the code it identifies.
It's unlikely to be actually broken in a stable release of Emacs.
> We recently did an update to vm in Debian stable, to work around a
> critical problem with Emacs 28 (#1039105). The autopkgtest which is
> now failing is new - I introduced it to detect future bugs, which it
> seems to have done.
>
> The previous bug was related to byte-compilation and we "fixed" it by
> turning off byte-compilation for at least some of vm's files (in what
> I feel was rather an ad-hoc way, albeit an effective one).
>
> Or to put it another way, is it possible that this is a bug in emacs
> 29.1 and if so what is the best workaround ?
Before disabling anything, it seems worth looking at the code and seeing
if you can figure out why there's a void-variable error being emitted at
all.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1042890: haskell-mode: bytecompilation fails against Emacs 29.1
Source: haskell-mode Version: 17.2-5 Severity: serious Dear maintainer, haskell-mode fails to bytecompile against Emacs 29.1, which latter is now in sid. In toplevel form: haskell.el:30:2: Error: Eager macro-expansion failure: (error "Misplaced t or ‘otherwise’ clause") -- Sean Whitton signature.asc Description: PGP signature
Bug#1042889: vm: autopkgtest fails against Emacs 29.1
Source: vm Version: 8.2.0b-10 Severity: serious Dear maintainer, vm's autopkgtest fails with Emacs 29.1, which latter is now in sid. https://ci.debian.net/packages/v/vm/testing/amd64/ Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035650: elpa-org version older than built-in Org in bookworm
Hello, On Mon 08 May 2023 at 06:00PM -04, Nicholas D Steeves wrote: > tldr: Dear team, are there any objections to making a team upload using > the dummy package approach? It's what at least two users want, and it > guards against harming relations with upstream Emacs. The existing > state of things is between useless, embarrassing, and harmful, so let's > fix this. We need pre-approval. I've requested it in #1035757. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035650: elpa-org version older than built-in Org in bookworm
Hello, On Sun 07 May 2023 at 04:42PM -04, Nicholas D Steeves wrote: > Is there a practical argument against adding versioned Provides to > either emacs-common or emacs-el (as appropriate)? Something like > > Provides: elpa-org (= 9.5.5) > > The idea is that emacs-common (or -el) would replace elpa-org > 9.4.0+dfsg-1 from bullseye during the upgrade to bookworm, but that a > future bookworm-backport (or the future trixie package) of standalone > org-mode would replace the versioned semivirtual "elpa-org" package. I believe that changes of this nature are not appropriate at this stage of the freeze. I wish we had done something about this sooner, but elpa-org is undermaintained. I don't think we should kick it out, because having a slightly older Org seems less bad than also kicking out the rdeps, on balance. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020192: Remove cycle-quotes from Debian?
Hello, On Fri 24 Feb 2023 at 07:51AM -04, David Bremner wrote: > Sergio Durigan Junior writes: > >> Agreed. I'm thinking about filing an RM bug against cycle-quotes; its >> last release happened 4 years ago (although there are some non-useful >> new commits on https://github.com/emacsmirror/cycle-quotes), it fails to >> build with Emacs 28, has been blocked for 790 days, and doesn't have any >> reverse-dependencies. >> > > I would say that compared to some contexts, 4 years is not that long for > an emacs package to be static. On the other hand, cycle-quotes is not in > melpa, and it has pretty low popcon numbers, so it isn't hugely popular. It's in GNU ELPA. The fix for compatibility with recent Emacs is likely trivial. > I guess I would be inclined to just let it get removed > semi-automatically when the release team notices it has been out of > testing for a while. I think that we should leave it so that if someone wants it later, they don't have to go through NEW. It is doing no harm. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017906: Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
Hello, On Sun 01 Jan 2023 at 05:15PM +01, Paul Gevers wrote: > Hi Sean, > > On Mon, 22 Aug 2022 14:29:56 -0700 Sean Whitton > wrote: >> control: severity 1017906 wishlist > >> > Is there ftp team consensus that either or both of these issues are RC? >> #1017892 is wishlist or not a bug. [...] > >> #1017906 *might* be a problem. [...] > > It seems like you mixed up the bugs in your control message? I'm currently > staring at #1017892 (vendored copies) because it's RC, but I agree with you it > looks much less severe. Given that, do you think #1017906 (no source) should > be raised again until somebody has figured out if there's *no* RC problem? Yes. #1017892 should be wishlist, #1017906 possibly serious, depending on the details. My apologies! -- Sean Whitton signature.asc Description: PGP signature
Bug#1026561: mailscripts: FTBFS: AttributeError: module 'cryptography.utils' has no attribute 'register_interface'. Did you mean: 'verify_interface'?
Hello, dkg, could you take a look? Thank you. On Tue 20 Dec 2022 at 06:22PM +01, Lucas Nussbaum wrote: > Source: mailscripts > Version: 27-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): >> make[1]: Entering directory '/<>' >> ./tests/email-print-mime-structure.sh >> Testing alternative.eml >> Traceback (most recent call last): >> File "/<>/./email-print-mime-structure", line 46, in >> import pgpy #type: ignore >> File "/usr/lib/python3/dist-packages/pgpy/__init__.py", line 4, in >> from .pgp import PGPKey >> File "/usr/lib/python3/dist-packages/pgpy/pgp.py", line 27, in >> from .constants import CompressionAlgorithm >> File "/usr/lib/python3/dist-packages/pgpy/constants.py", line 23, in >> >> from ._curves import BrainpoolP256R1, BrainpoolP384R1, BrainpoolP512R1, >> X25519, Ed25519 >> File "/usr/lib/python3/dist-packages/pgpy/_curves.py", line 37, in >> @utils.register_interface(ec.EllipticCurve) >> AttributeError: module 'cryptography.utils' has no attribute >> 'register_interface'. Did you mean: 'verify_interface'? >> --- tests/email-print-mime-structure/alternative.out 2022-06-24 >> 21:52:21.0 + >> +++ /dev/fd/63 2022-12-20 09:49:43.674063951 + >> @@ -1,3 +0,0 @@ >> -└┬╴multipart/alternative 414 bytes >> - ├─╴text/plain 26 bytes >> - └─╴text/html 72 bytes >> make[1]: *** [Makefile:14: check] Error 1 >> make[1]: Leaving directory '/<>' >> dh_auto_test: error: make -j8 check returned exit code 2 > > > The full build log is available from: > http://qa-logs.debian.net/2022/12/20/mailscripts_27-1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221220;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221220=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. -- Sean Whitton
Bug#1023297: src:emacs: fails to migrate to testing for too long: unresolved RC issues
Hello Paul, On Tue 01 Nov 2022 at 09:47PM +01, Paul Gevers wrote: > 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. Alright, all the RC bugs are closed. Of the four autopkgtest failures, emacs-deferred and flycheck we need to wait and see when they are re-run, but the evil-el and haskell-mode failures are due to bugs in those packages. evil-el is orphaned and haskell-mode is unmaintained. Could they both be hinted out of testing, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#1025812: elpa-haskell-mode: Tests fail against Emacs 28.2
Package: elpa-haskell-mode Version: 17.2-3 Severity: serious Hello, Dear maintainer, Test haskell-generate-tags condition: (file-missing "Searching for program" "No such file or directory" "git") FAILED 100/538 haskell-generate-tags (0.048838 sec) See: https://ci.debian.net/data/autopkgtest/testing/amd64/h/haskell-mode/29137490/log.gz -- Sean Whitton signature.asc Description: PGP signature
Bug#1024431: gcc-12: diff for NMU version 12.2.0-9.1
Control: tags 1024431 + patch
Control: tags 1024431 + pending
Dear maintainer,
I've prepared an NMU for gcc-12 (versioned as 12.2.0-9.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
Sean Whitton
diff -Nru gcc-12-12.2.0/debian/changelog gcc-12-12.2.0/debian/changelog
--- gcc-12-12.2.0/debian/changelog 2022-11-03 01:40:42.0 -0700
+++ gcc-12-12.2.0/debian/changelog 2022-12-02 18:28:07.0 -0700
@@ -1,3 +1,10 @@
+gcc-12 (12.2.0-9.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * libgccjit0: Depend on libc6-dev (Closes: #1024431).
+
+ -- Sean Whitton Fri, 02 Dec 2022 18:28:07 -0700
+
gcc-12 (12.2.0-9) unstable; urgency=medium
* Update to git 20221103 from the gcc-12 branch.
diff -Nru gcc-12-12.2.0/debian/control gcc-12-12.2.0/debian/control
--- gcc-12-12.2.0/debian/control2022-11-02 09:19:52.0 -0700
+++ gcc-12-12.2.0/debian/control2022-12-02 18:28:07.0 -0700
@@ -783,7 +783,7 @@
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Priority: optional
-Depends: gcc-12-base (= ${gcc:Version}), libgcc-12-dev, binutils,
${shlibs:Depends}, ${misc:Depends}
+Depends: gcc-12-base (= ${gcc:Version}), libgcc-12-dev, binutils,
${dep:libcdev}, ${shlibs:Depends}, ${misc:Depends}
Breaks: python-gccjit (<< 0.4-4), python3-gccjit (<< 0.4-4)
Description: GCC just-in-time compilation (shared library)
libgccjit provides an embeddable shared library with an API for adding
diff -Nru gcc-12-12.2.0/debian/control.m4 gcc-12-12.2.0/debian/control.m4
--- gcc-12-12.2.0/debian/control.m4 2022-11-02 09:19:37.0 -0700
+++ gcc-12-12.2.0/debian/control.m4 2022-12-02 18:28:07.0 -0700
@@ -3263,7 +3263,7 @@
Pre-Depends: ${misc:Pre-Depends}
')`'dnl
Priority: optional
-Depends: BASEDEP, libgcc`'PV-dev, binutils, ${shlibs:Depends}, ${misc:Depends}
+Depends: BASEDEP, libgcc`'PV-dev, binutils, ${dep:libcdev}, ${shlibs:Depends},
${misc:Depends}
Breaks: python-gccjit (<< 0.4-4), python3-gccjit (<< 0.4-4)
BUILT_USING`'dnl
Description: GCC just-in-time compilation (shared library)
signature.asc
Description: PGP signature
Bug#1020851: elpa-ement: fails to install along emacs
Hello, On Fri 25 Nov 2022 at 09:47PM +01, Aymeric Agon-Rambosson wrote: > Hello, > > Le vendredi 25 novembre 2022 à 10:31, Sean Whitton > a écrit : > >> It would? The highest version is meant to take precedence. That's a >> feature of package.el. > > I run some version of emacs 28.1, which ships xref 1.3.0. > > I installed elpa-eglot, which depends on elpa-xref version 1.0.2. > > Since then, I have had the following : > > (find-library-name "xref") > "/usr/share/emacs/site-lisp/elpa-src/xref-1.0.2/xref.el" > > (locate-library "xref") > "/usr/share/emacs/site-lisp/elpa/xref-1.0.2/xref.el" > > I do have /usr/share/emacs/28.1/lisp/progmodes in my load-path, which is the > directory containing xref.el.gz. > > From what I can see, it would seem that /usr/share/emacs/site-lisp takes > precedence over /usr/share/emacs/, rather than the highest > library version. > > I'm not sure whether that is intended or not. My understanding is that this is an upstream bug in Emacs, but ICBW. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020851: elpa-ement: fails to install along emacs
Hello, On Wed 23 Nov 2022 at 11:26PM +01, Aymeric Agon-Rambosson wrote: > However, this packaged version of elpa-transient would also shadow the > transient shipped with emacs, regardless of their respective versions. It would? The highest version is meant to take precedence. That's a feature of package.el. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020851: elpa-ement: fails to install along emacs
Hello, On Wed 23 Nov 2022 at 01:17PM +01, Andreas Beckmann wrote: > On 23/11/2022 01.11, Sean Whitton wrote: >> Hello, >> On Tue 22 Nov 2022 at 05:39PM +01, Andreas Beckmann wrote: >> >>> On 28/09/2022 16.55, Sean Whitton wrote: >>>> transient is included in Emacs 28 so I'm inclined to leave this to fix >>>> itself when Emacs 28 migrates. >>> >>> Can't this be expressed as a package relationship? >>> e.g. Depends: emacs-el (>= 1:28) >> It's against the Emacsen Team policy to have a hard dependency on Emacs >> -- instead, it's in Recommends. So I'd prefer not to add a dependency >> that I'm only going to have to remove in a few weeks when Emacs >> migrates. But if you think this bug is getting in the way then I can >> add it. > > There is another occurrence of this bug in elpa-snakemake, #1024648. > Diane made me aware that there is currently a elpa-transient package ... > > Quoting myself what I wrote there: > >> But if emacs-el (or -common?) bundles extensions (or however you call them), >> especially ones that were previously packaged separately, it should probably >> have versioned Provides (and maybe versioned Breaks, too) for >> them. (Cf. perl, perl-base which does the same.) >> Not sure whether these should be in -el or -common ... >> If these Provides were available, elpa-snakemake wouldn't need to know about >> the packaging details of other packages and could just use >> Depends: elpa-transient > > There are a few other packages currently using Depends: elpa-transient elpa-transient isn't a transitional package -- we'll keep it in Debian even after Emacs 28 is the only Emacs we have. This is because we might need a newer version of transient available for another package. So far our strategy has been to handle this in the code in dh_elpa that generates dependencies, and also not worry about it too much, unless we get a combination that results in something not having its dependency available. I don't think we should be adding Provides/Breaks anywhere without considering corresponding changes in dh_elpa. -- Sean Whitton
Bug#1020851: elpa-ement: fails to install along emacs
Hello, On Tue 22 Nov 2022 at 05:39PM +01, Andreas Beckmann wrote: > On 28/09/2022 16.55, Sean Whitton wrote: >> transient is included in Emacs 28 so I'm inclined to leave this to fix >> itself when Emacs 28 migrates. > > Can't this be expressed as a package relationship? > e.g. Depends: emacs-el (>= 1:28) It's against the Emacsen Team policy to have a hard dependency on Emacs -- instead, it's in Recommends. So I'd prefer not to add a dependency that I'm only going to have to remove in a few weeks when Emacs migrates. But if you think this bug is getting in the way then I can add it. -- Sean Whitton
Bug#1022681: clientsession
Hello Joey, Would it be possible to replace git-annex's usage of clientsession, do you think, or alternatively for you to start maintaining a fork, or similar? The Debian Haskell Team would like to remove clientsession as unmaintained. Ilias points out that the last upstream commit is from 2016, and there are PRs sitting there seemingly ignored. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1024431: libgccjit0: missing Depends: libc6-dev
Hello gcc maintainers, I believe that you won't have seen any messages to this bug yet, if I recall correctly how reassignment works with the BTS. On Sat 19 Nov 2022 at 12:16PM +01, Andreas Beckmann wrote: > The Dependency chain is emacs-gtk -> libgccjit0 -> libgcc-12-dev > libgcc-12-dev has a Recommends: libc6-dev but that seems to be insufficient > for libgccjit0. > (one of the errors was 'libgccjit.so: error: error invoking gcc driver' so > that seems to be out of the realm of emacs. > > IMO, the real bug seems to be "libgccjit0: missing Depends: libc6-dev" > Cloning/reassigning/blocking accordingly. > > The only other user of libgccjit0 is python3-gccjit which may or may not have > the same problem. libgccjit0 already transitively recommends libc6-dev, and it looks like this needs to be upgraded to a hard dependency. This is the last remaining known RC bug before Emacs 28 can finally migrate. Could you make the change, please? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1020258: elpa-*: fails to install: libgccjit.so: error: error invoking gcc driver
Hello,
On Sat 19 Nov 2022 at 06:50AM +09, Tatsuya Kinoshita wrote:
> On 2022-11-18 at 11:44 -0700, Sean Whitton wrote:
>> I can't reproduce this locally, and looking at the package tracker for a
>> few of those packages you've listed, piuparts is now passing
>
> The piuparts tests with the listed pacakges may succeed when emacs
> (or emacs{-gtk,-lucid,-nox}) isn't installed. To reproduce, use
> `piuparts elpa-elscreen_*.deb` because it brings emacs-nox|emacs.
>
>> ld: cannot find crti.o: No such file or directory
>
> It seems native compilation requires crti.o provided by libc6-dev,
> so adding libc6-dev to the Depends line of emacs{-gtk,-lucid,-nox}
> may prevent this problem, though I don't know whether it should be
> fixed in libgccjit0.
It's a pretty heavy dependency, and as you say, it might not be
src:emacs that has the bug.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#1020258: elpa-*: fails to install: libgccjit.so: error: error invoking gcc driver
control: reopen -1 control: notfixed -1 1:28.2+1-5 Hello, On Fri 18 Nov 2022 at 11:44AM -07, Sean Whitton wrote: >> elpa-treemacs-magit=2.8-2 >> elpa-use-package-chords=2.4.1-1 >> elpa-weechat=0.5.0-5 >> >> I cannot reproduce this in testing (which still has emacs 1.27), >> so this seems to stem from emacs 1.28 (and not gcc 12). > > I can't reproduce this locally, and looking at the package tracker for a > few of those packages you've listed, piuparts is now passing if it's > been re-run recently. So I believe this one is fixed. ... except that it's still showing up in failing autopkgtests, e.g. for emacs-deferred. -- Sean Whitton signature.asc Description: PGP signature
Bug#1024060: emacs: FTBFS for architecture all: test-undo-region fails / unexpected lisp/simple-tests.log
control: tag -1 + pending Hello, On Tue 15 Nov 2022 at 06:24PM +01, Andreas Beckmann wrote: > Control: severity -1 serious > > On Mon, 14 Nov 2022 12:50:53 -0700 Sean Whitton > wrote: >> There are a number of flaky tests atm. Ideally we'd patch them out, but >> it's not RC. > > -5 so far has failed 8 times on arch:all. > Feel free to downgrade the severity again once the build succeeded. Thanks. Next upload will disable the test. -- Sean Whitton signature.asc Description: PGP signature
Bug#1024060: emacs: FTBFS for architecture all: test-undo-region fails / unexpected lisp/simple-tests.log
control: severity -1 important Hello, There are a number of flaky tests atm. Ideally we'd patch them out, but it's not RC. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: bug#58956: mark_object, mark_objects(?) crash
Hello, On Sat 12 Nov 2022 at 02:55AM +01, Vincent Lefevre wrote: > Hi, > > On 2022-11-11 11:32:33 -0700, Sean Whitton wrote: >> On Thu 10 Nov 2022 at 11:23AM +01, Vincent Lefevre wrote: >> > On 2022-11-08 12:44:08 -0700, Sean Whitton wrote: >> >> Are you able to test the patch? Let me know if you need help getting an >> >> installable .deb. Thanks. >> > >> > Sorry, I couldn't test it yet, first because of an uninstallable >> > package needed for the build because I couldn't upgrade libc6 yet >> > and I couldn't get the previous version from snapshot.debian.org >> > (bug 1023540). Now that I could upgrade libc6, I'll be able to >> > test when I have some time, but perhaps not before the week-end. >> >> Okay, do let me know if I can help -- this is blocking Emacs from migrating. > > I've rebuilt the packages with the patch and couldn't reproduce > the bug yet. So it may be the correct fix. Many thanks for testing, and Eli and Paul for the patch. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: bug#58956: mark_object, mark_objects(?) crash
Hello, On Thu 10 Nov 2022 at 11:23AM +01, Vincent Lefevre wrote: > On 2022-11-08 12:44:08 -0700, Sean Whitton wrote: >> Are you able to test the patch? Let me know if you need help getting an >> installable .deb. Thanks. > > Sorry, I couldn't test it yet, first because of an uninstallable > package needed for the build because I couldn't upgrade libc6 yet > and I couldn't get the previous version from snapshot.debian.org > (bug 1023540). Now that I could upgrade libc6, I'll be able to > test when I have some time, but perhaps not before the week-end. Okay, do let me know if I can help -- this is blocking Emacs from migrating. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: bug#58956: mark_object, mark_objects(?) crash
Hello Vincent, Are you able to test the patch? Let me know if you need help getting an installable .deb. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump
Hello Vincent, Upstream says there isn't enough information in the backtrace to say anything helpful about this. Could you take a look at <https://debbugs.gnu.org/58956> and consider supplying more information over there, please? Also, are you able to reproduce this with 'emacs -q' (not -Q)? Currently we have no way to reproduce this, and you're the only person who's seen anything like this, so we'll probably have to move the severity back down to 'important'. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump
Hello, On Tue 01 Nov 2022 at 11:17PM +01, Vincent Lefevre wrote: > On 2022-10-31 15:59:17 +0100, Vincent Lefevre wrote: >> Hi, >> >> On 2022-10-30 06:31:27 -0700, Sean Whitton wrote: >> > I've backported a couple of patches from upstream related to native >> > compilation, now, so would you be able to test again with the latest >> > upload? Thanks. >> >> If you mean 1:28.2+1-3, I still got the same issue. But it seems >> that after a reboot, the problem no longer occurs (after removing >> the .emacs.d directory). Was a reboot needed? > > Unfortunately, it has just occurred again (with emacs run by > Subversion to enter a commit message). > > Core was generated by `/usr/bin/emacs -no-comp-spawn --batch -l > /tmp/emacs-async-comp-url.el-FGov4z.el'. > Program terminated with signal SIGABRT, Aborted. > #0 __pthread_kill_implementation (threadid=, > signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 > 44 ./nptl/pthread_kill.c: No such file or directory. > > I've attached the backtrace. Seems too many recursive calls to > mark_object and mark_objects. > > Worse, not just a background emacs process, the UI also crashes > (IIRC, this didn't happen before). Thanks for following up. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump
Hello, On Fri 14 Oct 2022 at 12:53PM +02, Vincent Lefevre wrote: > Control: found -1 1:28.2+1-1 > > Hi, > > On 2022-10-13 22:28:24 -0700, Sean Whitton wrote: >> Can you reproduce this with what's in sid now? > > Yes, this still occurs: > > zira% ls -lh > total 41M > -rw--- 1 vinc17 vinc17 43M 2022-10-14 12:49:40 core > > Core was generated by `/usr/bin/emacs --batch -l > /tmp/emacs-async-comp-url-cookie.el-A86dRV.el'. > Program terminated with signal SIGABRT, Aborted. > #0 0x7f59efe8957c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 I've backported a couple of patches from upstream related to native compilation, now, so would you be able to test again with the latest upload? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017845: New upload should resolve native compilation fork bomb problem
Hello, On Thu 27 Oct 2022 at 12:47AM +02, Axel Beckert wrote: > Control: found -1 1:28.2+1-2 > > Hi Sean, > > Axel Beckert wrote: >> Sean Whitton wrote: >> > Could you see if the upload I just made, 28.2+1-2, still shows the >> > problem, please? It includes a backported upstream fix. Thanks. >> >> Would like to, but can't as "emacs-common (= 1:28.2+1-2)" is >> unavailable due to a FTBFS: >> https://buildd.debian.org/status/package.php?p=emacs > > Ok, someone gave back emacs:all and it built now. Yeah, there's a flaky test. > Unfortunately the issue still shows up for me: Thank you for testing so promptly. There's an additional patch that just made it to upstream master that tries to address the trampoline problem. I've just uploaded that to sid. Could you let me know whether it helps, please? Thanks. -- Sean Whitton
Bug#1017817: New upload should resolve native compilation fork bomb problem
Hello, Could you see if the upload I just made, 28.2+1-2, still shows the problem, please? It includes a backported upstream fix. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump
Hello, On Mon 22 Aug 2022 at 02:55AM +02, Vincent Lefevre wrote: > Control: found -1 1:28.1+1-2 > Control: severity -1 serious > > On 2022-08-19 12:10:31 +0200, Vincent Lefevre wrote: >> I have noticed that Emacs left a 137 MB coredump. > > This has occurred again (this time a 54 MB coredump). > This is going to use much disk space... > >> gdb says: >> >> Reading symbols from /usr/bin/emacs... >> Reading symbols from >> /usr/lib/debug/.build-id/d0/b7c40dc33110b0623ea2ca797a6d3f3eb166b5.debug... >> [New LWP 1483812] >> [New LWP 1483816] >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> Core was generated by `/usr/bin/emacs --batch -l >> /tmp/emacs-async-comp-cc-engine.el-2UV1nf.el'. > > This time, > > Core was generated by `/usr/bin/emacs --batch -l > /tmp/emacs-async-comp-auth-source.el-84YT0a.el'. > Program terminated with signal SIGABRT, Aborted. > > I'm wondering whether this is related to bug 1017845, as a > "/usr/bin/emacs --batch -l /tmp/emacs-async-..." is also involved. Can you reproduce this with what's in sid now? It may have been fixed by adding the emacs-el dependency. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el
Hello, On Sun 21 Aug 2022 at 02:46PM +02, Axel Beckert wrote: > Package: emacs-common > Version: 1:28.1+1-2 > Severity: serious > X-Debbugs-Cc: a...@debian.org > Control: affects -1 elpa-folding elpa-org elpa-git-timemachine > elpa-password-store > > Hi, > > upgrading emacs respectively emacs-gtk from 27.1 to 28.1 causes an > endless fork loops during package configuration time: Are you able to reproduce this with what's in sid at present? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
control: severity -1 important Hello, On Tue 11 Oct 2022 at 05:05PM -07, Sean Whitton wrote: > control: reassign -1 cl-ironclad > control: retitle -1 cl-ironclad: fails to compile against recent SBCL on > 32-bit ARM architectures > > I intend to resolve this bug by disabling the failing compilation. > SBCL upstream do not think there is evidence of a serious SBCL bug. This reduces the severity of this bug, rather than resolving it. SBCL is not the only CL implementation in Debian. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
control: reassign -1 cl-ironclad control: retitle -1 cl-ironclad: fails to compile against recent SBCL on 32-bit ARM architectures I intend to resolve this bug by disabling the failing compilation. SBCL upstream do not think there is evidence of a serious SBCL bug. -- Sean Whitton
Bug#1020851: elpa-ement: fails to install along emacs
Hello, On Tue 27 Sep 2022 at 05:09PM +02, Andreas Beckmann wrote: > Package: elpa-ement > Version: 0.1.4-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed to install. As > per definition of the release team this makes the package too buggy for > a release, thus the severity. > > This is the failure when installing the package along emacs 27 in bookworm. > (In sid there is currently a different error that is likely caused by > emacs 28 and hides this problem.) transient is included in Emacs 28 so I'm inclined to leave this to fix itself when Emacs 28 migrates. -- Sean Whitton signature.asc Description: PGP signature
Bug#1019694: pikepdf: FTBFS with qpdf 11.0.0
Hello, On Sun 25 Sep 2022 at 10:32PM -07, James Barlow wrote: > Upgrading to pikepdf 6.0.2 will resolve this issue. pikepdf 5 is not > compatible > with qpdf 11. Thanks for confirming. I prepared the update in git some weeks ago, but I'm blocked on uploading on someone packaging python3-sphinx-design. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Sat 27 Aug 2022 at 03:15PM -04, Douglas Katzman wrote: > I suspect that the heap exhaustion is corrected for this release. > Also I think this particular GC invariant failure is not of the utmost > importance. It seems > directly related to the heap exhaustion which leaves things in an > inconsistent state such > that 'gc_gen_report_to_file' does not work. It's unfortunate that such is the > case, but it is > what it is. I would have far been more worried about a GC failure on its > own. Let's see > how things go after you pull in newer source. Just to report back, it still fails with 2.2.8. I'll proceed to disable the test. https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/26219482/log.gz -- Sean Whitton signature.asc Description: PGP signature
Bug#1014628: src:git-annex: fails to migrate to testing for too long: FTBFS on armel and armhf
Hello, Some time ago Joey suggested uploading something like the attached to try to debug the build failures of 8.20211123 on the 32-bit ARM archs. However, it has not been possible to do this for some months because the Haskell transition is stalled on those architectures. I'm sending this mail primarily in order to store this work somewhere public. However, we don't know whether the bug still exists, with so much of the Haskell ecosystem having been updated recently, including git-annex. My plan is to ask ftpmaster to remove git-annex on armel and armhf and then downgrade the severity of this bug. For the time being, we don't know whether Debian can support git-annex on armel & armhf for bookworm. -- Sean Whitton From 51e38d17b0f8914f78c3e5f27819016d9bfe1750 Mon Sep 17 00:00:00 2001 From: Sean Whitton Date: Mon, 18 Jul 2022 15:19:36 -0700 Subject: [PATCH] Add 'ghc -e' command to override_dh_auto_build --- debian/changelog | 7 +++ debian/rules | 1 + 2 files changed, 8 insertions(+) diff --git a/debian/changelog b/debian/changelog index 37b6401af..ee0a9ce9a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +git-annex (10.20220724-1+exp1) experimental; urgency=medium + + * Add 'ghc -e' command to override_dh_auto_build. +Suggestion from upstream for solving an apparently buildd-specific bug. + + -- Sean Whitton Sun, 21 Aug 2022 15:23:50 -0700 + git-annex (10.20220724-1) unstable; urgency=medium * New upstream release. diff --git a/debian/rules b/debian/rules index a9c5aff8d..06af0db93 100755 --- a/debian/rules +++ b/debian/rules @@ -35,6 +35,7 @@ export ZSH_COMPLETIONS_PATH=/usr/share/zsh/vendor-completions ifeq ($(STANDALONE_BUILD),1) override_dh_auto_build: + ghc -e 'import DBus.Client' -e 'print DBus.Client.addMatch' || true make linuxstandalone GIT_ANNEX_PACKAGE_INSTALL=1 override_dh_auto_install: -- 2.30.2 signature.asc Description: PGP signature
Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Sat 27 Aug 2022 at 03:15PM -04, Douglas Katzman wrote: > > I suspect that the heap exhaustion is corrected for this release. You have in mind an upcoming 2.2.8 release, right? 2.2.7 is still showing the test failure. > Also I think this particular GC invariant failure is not of the utmost > importance. It seems > directly related to the heap exhaustion which leaves things in an > inconsistent state such > that 'gc_gen_report_to_file' does not work. It's unfortunate that such is the > case, but it is > what it is. I would have far been more worried about a GC failure on > its own. Thank you for this analysis. It would seem that disabling the test is an acceptable workaround. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017892: Ships copies of libraries that are in Debian and autogenerated files that can't be renegerated with the code in Debian main
control: severity 1017906 wishlist Hello, On Mon 22 Aug 2022 at 10:05AM +01, Simon McVittie wrote: > > Control: clone -1 -2 > Control: retitle -1 librsvg: Has vendored copies of Rust libraries that are > in Debian > Control: retitle -2 librsvg: Contains generated files whose source is not > necessarily the same version that's in main > Control: tags -1 + help > Control: tags -2 + help > > On Mon, 22 Aug 2022 at 10:19:01 +0300, Sebastian Dröge wrote: >> The vendor subdirectory in the librsvg source package contains copies of >> various Rust libraries in specific versions. Some of them are packaged in >> Debian (i.e. the version from Debian should be used), others contain >> autogenerated files for which the original source is not in Debian. > > This seems like two separate issues, so I'm cloning it. > > Is there ftp team consensus that either or both of these issues are RC? #1017892 is wishlist or not a bug. Certainly not a DFSG issue. #1017906 *might* be a problem. If there is generated Rust code without the source code used to generate it, or the tool used to transform the sources into the generated Rust code, then there is source code missing. I have not looked into the package to see whether this is actually the case. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017890: Ships autogenerated files that can't be renegerated with the code in Debian main
Hello, On Mon 22 Aug 2022 at 10:00AM +01, Simon McVittie wrote: > Before we go adding a complete copy of GLib to GObject-Introspection, > is there ftp team consensus that the issue described in #1017890 is a > serious bug? The basic idea in these cases is that it must be possible to regenerate anything not in its preferred form for modification using the contents of the archive, such that main is self-contained. But whether something is in its preferred form for modification is case-by-case and a matter of judgement, so there's no whole team consensus to be had, really. > The reason that the inputs used to generate the GIR descriptions > for GLib are shipped by GObject-Introspection rather than GLib is to > resolve a circular dependency. Normally each library generates its own > GObject-Introspection metadata, but GObject-Introspection is a GLib-based > library, so it needs GLib for compilation. > > Rather than directly shipping pregenerated GIR XML, GObject-Introspection > ships files containing the doc-comments from GLib. These are a subset > of GLib's source code, created by removing the actual C code (which is > redundant with the information that can be introspected from the actual > libraries and headers) and leaving only the comments. Sounds like a subset of the preferred form for modification is still the preferred form for modification, so, without having thought about this as carefully as I would were I reviewing the package in NEW, it sounds like this package is okay. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Tue 09 Aug 2022 at 02:53PM -04, Douglas Katzman wrote: > > https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/24441370/log.gz > shows a GC invariant failure, not a heap exhaustion. > How do I identify the exact git revision of SBCL you're using? I can only > guess at what > line# failed an assertion in my current tree. I've just updated SBCL in Debian to 2.2.7 and dropped two patches included in that release, which simplifies things a bit. ci.debian.net will re-run the cl-ironclad test suite soon. Let me know if it would be useful for me to file a Launchpad bug gathering the various links together. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: [Sbcl-bugs] Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, On Tue 09 Aug 2022 at 02:53PM -04, Douglas Katzman wrote: > https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/24441370/log.gz > shows a GC invariant failure, not a heap exhaustion. Hmm okay, sounds like it's a bug in sbcl rather than cl-ironclad, then. > How do I identify the exact git revision of SBCL you're using? I can only > guess > at what line# failed an assertion in my current tree. We currently use the release tarballs from URIs matching: <https://sf.net/sbcl/sbcl-*-source.tar.bz2> plus these patches: <https://salsa.debian.org/common-lisp-team/sbcl/-/tree/master/debian/patches> a couple of which are backported from git. (If I continue to be the only person working on sbcl packaging in Debian, I'll probably switch to packaging git revisions not tarballs, and patches in git not in a directory like this, which'll mean that you can work with our git repo directly.) Thanks. -- Sean Whitton
Bug#1016750: Heap exhaustion problem with SBCL 2.2.6 on armel, armhf
Hello, When I updated SBCL in Debian from 2.2.3 to 2.2.6, our ci infrastructure detected that the test suite for the cl-ironclad package consistently runs out of memory on armhf and armel. This didn't happen before. https://ci.debian.net/packages/c/cl-ironclad/testing/armhf/ https://ci.debian.net/packages/c/cl-ironclad/testing/armel/ Based on your understanding of the changes between SBCL 2.2.3 and 2.2.6, does it seem likely that this is an SBCL bug, or rather that changes in SBCL have uncovered a bug or limitation in the ironclad test suite, e.g. that it tries to use more memory than a 32-bit address space can accommodate? Also asked about here: <https://github.com/sharplispers/ironclad/issues/53>. Would be grateful for any input. Thanks. -- Sean Whitton
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
Hello, On Tue 09 Aug 2022 at 07:46AM +02, Paul Gevers wrote: > Hi Sean, > > On 09-08-2022 05:08, Sean Whitton wrote: >> It looks like Lisp just ran out of memory. > > Yes, but it does so systematically. > >> Indeed, I can't see this >> failure on debci.debian.org at present, > > Huh? Did you check https://ci.debian.net/packages/c/cl-ironclad/testing/armhf/ > or https://ci.debian.net/packages/c/cl-ironclad/testing/armel/ You'll see > there that cl-ironclad was retried with sbcl about 11 + 10 times and every > time it failed (and never succeeded). > >> which makes sense if it's a >> random OOM problem on weaker architectures like armhf -- so, not the >> fault of the new sbcl upload. > > This isn't random. And, our armhf box has 255 GB of RAM (and armel VM has 26 > GB), so running out of memory isn't likely. What can happen is that threads > use too much resources for the address space, but that's something under > control of the packages in question if I'm correct (but please correct me if I > misunderstand). I'm not saying it's (easily) fixable, just that it > systematically runs out of reachable memory during the particular test. Right, it's not random. I was looking at the page for unstable. I first looked at <https://ci.debian.net/packages/c/cl-ironclad/> and the failure doesn't show up there -- do you know what that would be? Then I clicked on unstable but not testing, it would seem. I'll write to upstream about this. -- Sean Whitton signature.asc Description: PGP signature
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
Hello Paul, On Sat 06 Aug 2022 at 04:19PM +02, Paul Gevers wrote: > With a recent upload of sbcl the autopkgtest of cl-ironclad fails in testing > when that autopkgtest is run with the binary packages of sbcl from > unstable. It passes when run with only packages from testing. > > ; wrote > > /tmp/autopkgtest-lxc.d2c27h4h/downtmp/autopkgtest_tmp/usr/share/common-lisp/source/ironclad/src/ciphers/tea-tmp93OFNPHA.fasl > ; compilation finished in 0:00:00.160 > ; compiling file > "/usr/share/common-lisp/source/ironclad/src/ciphers/threefish.lisp" (written > 18 FEB 2022 01:39:10 PM): > Heap exhausted during garbage collection: 16 bytes available, 48 requested. > Immobile Object Counts > Gen GF type fdefn symbol code Boxed ConsRaw Code SmMix Mixed > LgRaw LgCode LgMix Waste% AllocTrig Dirty GCs Mem-age > 1 00 0 0 0 7121939 9668 5273 827 > 0 0 17 19.96186748032499253 18850 1 1.1503 > 2 00 0 0 0 19865 2766 12586 848361681 > 10 34127 11.7 137430448 5368709 23089 0 0.9496 > 3 00 0 0 0 45116 7190 7447604 35521673 > 2394673311.0 270091288 2007806 0 0.4559 > 4 00 0 0 0 0 0 0 0 0 0 > 0 0 00.0 0 200 0 0 0. > 5 00 0 0 0 0 0 0 0 0 0 > 0 0 00.0 0 200 0 0 0. > 6 00 0 0 0 1370471 1242 3507314 40 > 2551342811.930584464 200 251 0 0. > Tot 00 0 0 0 73472 11366 30943 4200 4975 4221 > 5046357566.9 499973680 [93.1% of 536870912 max] > GC control variables: >*GC-INHIBIT* = true >*GC-PENDING* = true > fatal error encountered in SBCL pid 1357: > Heap exhausted, game over. It looks like Lisp just ran out of memory. Indeed, I can't see this failure on debci.debian.org at present, which makes sense if it's a random OOM problem on weaker architectures like armhf -- so, not the fault of the new sbcl upload. Is it possible to label the tests as flaky on only a single architecture? -- Sean Whitton
Bug#1009433: tried but got stuck with dgit and git-debrebase
Hello, On Sat 23 Apr 2022 at 09:10PM +03, Thomas Koch wrote: > I think I believe how to fix the FTBFS: > > --- a/debian/patches/0005-configure-mkdocs-for-Debian.patch > +++ b/debian/patches/0005-configure-mkdocs-for-Debian.patch > @@ -23,7 +23,8 @@ index 1302441..05ada85 100644 > +site_dir: html > copyright: "Copyright (C) 2011-2020 Bozhidar Batsov and Projectile > contributors" > docs_dir: doc > - pages: > +-pages: > ++nav: > - Home: index.md > -- Installation: installation.md > - Usage: usage.md > > But I'm stuck since I need to finally learn dgit and apparently > git-debrebase. I'll start with the manpages. dgit-maint-debrebase(7) should be in a "How do I ..." format; let me know if there are parts that are unclear. -- Sean Whitton signature.asc Description: PGP signature
Bug#1009680: ghostscript breaks ocrmypdf autopkgtest: seemingly multiple issues
control: reassign -1 ghostscript control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=705187 control: retitle -1 Ghostscript 9.56 removes hidden (e.g. OCR) text layers when refrying with NEWPDF=true Hello, On Thu 14 Apr 2022 at 11:13AM +02, Paul Gevers wrote: > With a recent upload of ghostscript the autopkgtest of ocrmypdf fails in > testing when that autopkgtest is run with the binary packages of > ghostscript from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > ghostscriptfrom testing9.56.0~dfsg-1 > ocrmypdf from testing13.4.0+dfsg-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of ghostscript to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation It's a regression in Ghostscript. OCRmyPDF has made a release including a workaround but the test suite for that fails, so I can't upload it yet. But in any case this bug is not one in OCRmyPDF. -- Sean Whitton signature.asc Description: PGP signature
Bug#1006739: python-unicodedata2: Needs Built-Using on unicode-data
Source: python-unicodedata2 Version: 14.0.0+ds-5 Severity: serious Justification: DFSG source inclusion requirements Hello, I think the package needs a Built-Using on unicode-data as the build incorporates part of that package into the binaries of this package. -- Sean Whitton signature.asc Description: PGP signature
Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1
Hello, On Tue 04 Jan 2022 at 03:13PM +01, Gregory Mounie wrote: > Package: elpa-org > Version: 9.5.2+dfsh-3 > Followup-For: Bug #1002982 > > Dear Maintainer, > > Thanks for fast modifications. I still have a problem. > > The org-version string in org-version.el is not compatible with > version-to-list standard function (emacs source, lisp/subr.el line 6137 in > current master). > > The syntax seems limited to the extension listed in > version-regexp-alist variable a single letter or > (alpha,beta,pre,rc,unknown,git,svn,hg,bzr,darcs). Each of these > extensions has fixed translation to a number (-1 to -4) > > I would say that the goal is to be able to sort the version (-4 is > bottom, alpha is -3, beta -2, rc is -1) > > Thus it would be possible to put '9.5.2' or '9.5.2+unknown' or '9.5.2+d' but > not > '9.5.2+dfsh'. > > (I would select '9.5.2+d' translated in (9 5 2 4) as I guess that > +dfsh is patching on top of the standard release) > > With current '9.5.2+dfsh', at the install elpa-org, I got 30 times: Thanks for this. Someone else reported this on IRC and I made another upload to fix it. -- Sean Whitton signature.asc Description: PGP signature
Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1
control: reopen -1 Hello Gregory, On Mon 03 Jan 2022 at 10:09pm +01, Gregory Mounie wrote: > Thanks for the addition of org-version.el but I suspect another bug > still exist in the auto-generation of the file: > > The org-version and org-git-version strings in > /usr/share/emacs/site-lisp/elpa-src/org-9.5.2/org-version.el are both > "N/A". > > It should probably be respectively something like "9.5.2" and > "9.5.2-gfbff08" (values taken from a local user install of the package > from elpa) I don't know why piuparts on my system isn't finding these bugs. Thanks for the report. I think I know how to fix it. -- Sean Whitton
Bug#997381: python-pgpy: FTBFS: AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'
Hello,
On Sat 23 Oct 2021 at 09:50PM +02, Lucas Nussbaum wrote:
>> make[2]: Entering directory '/<>/docs'
>> sphinx-build -b html -d build/doctrees source build/html
>> Running Sphinx v4.2.0
>>
>> Exception occurred:
>> File "/<>/docs/source/_ext/progress.py", line 147, in setup
>> app.add_stylesheet('progress.css')
>> AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'
>> The full traceback has been saved in /tmp/sphinx-err-olciwe_g.log, if you
>> want to report the issue to the developers.
>> Please also report this if it was a user error, so that a better error
>> message can be provided next time.
>> A bug report can be filed in the tracker at
>> <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
>> make[2]: *** [Makefile:53: html] Error 2
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2021/10/23/python-pgpy_0.5.3-3_unstable.log
I've looked at upstream's docs and add_stylesheet has simply been
renamed to add_css_file, so the fix for this bug is simple.
I haven't done an NMU because the test suite is failing for other
reasons.
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#997959: RM: git-annex [armel armhf] -- ROM; enduring issues building on 32-bit ARM architectures
reassign -1 ftp.debian.org retitle -1 RM: git-annex [armel armhf] -- ROM; enduring issues building on 32-bit ARM architectures severity -1 normal thanks Recent releases of git-annex fail to build on 32-bit ARM architectures and no-one has been able to figure out why, including upstream. As this situation has persisted for some weeks, I'd like to request removal on those architectures for now. -- Sean Whitton signature.asc Description: PGP signature
Bug#997959: git-annex: FTBFS on 32-bit ARM architectures, but built successfully before
Hello, On Wed 24 Nov 2021 at 02:21AM +0530, Nilesh Patra wrote: > Hi Sean, Richard, > > On Wed, 27 Oct 2021 12:20:04 -0700 Sean Whitton > wrote: >> Source: git-annex >> Version: 8.20210223-2 >> Severity: serious >> git-annex recently began to FTBFS on 32-bit ARM architectures, and I am >> not really in a position atm to dig deeply into the problem. >> [.. log ..] > > This bug is now triggering removals of its reverse-dependencies. > Would you (or any list member) have some bandwidth to take a deeper look into > this? I don't, I'm afraid. -- Sean Whitton signature.asc Description: PGP signature
Bug#997959: git-annex: FTBFS on 32-bit ARM architectures, but built successfully before
Source: git-annex Version: 8.20210223-2 Severity: serious Tags: help X-debbugs-cc: debian-hask...@lists.debian.org Hello, git-annex recently began to FTBFS on 32-bit ARM architectures, and I am not really in a position atm to dig deeply into the problem. armel failure: ghc: panic! (the 'impossible' happened) (GHC version 8.8.4 for arm-unknown-linux): tyThingTyCon Identifier ‘cMaxLen’ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/main/HscTypes.hs:2182:28 in ghc:HscTypes Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[1]: *** [Makefile:58: git-annex] Error 1 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j8 "INSTALL=install --strip-program=true" returned exit code 2 make: *** [debian/rules:31: build-arch] Error 25 armhf failure: ghc: panic! (the 'impossible' happened) (GHC version 8.8.4 for arm-unknown-linux): tyThingTyCon Identifier ‘==.’ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/main/HscTypes.hs:2182:28 in ghc:HscTypes Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[1]: *** [Makefile:58: git-annex] Error 1 make[1]: Leaving directory '/<>' dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" returned exit code 2 make: *** [debian/rules:31: build-arch] Error 25 -- Sean Whitton signature.asc Description: PGP signature
Bug#996795: silversearcher-ag-el: diff for NMU version 0.48-1.1
Control: tags 996795 + patch
Control: tags 996795 + pending
Dear maintainer,
I've prepared an NMU for silversearcher-ag-el (versioned as 0.48-1.1)
and uploaded it to DELAYED/5. Please feel free to tell me if I should
delay it longer.
Regards.
--
Sean Whitton
diff -Nru silversearcher-ag-el-0.48/debian/changelog
silversearcher-ag-el-0.48/debian/changelog
--- silversearcher-ag-el-0.48/debian/changelog 2020-05-13 23:34:22.0
-0700
+++ silversearcher-ag-el-0.48/debian/changelog 2021-10-18 13:43:54.0
-0700
@@ -1,3 +1,13 @@
+silversearcher-ag-el (0.48-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop build-dep on elpa-dash-functional & require elpa-dash >= 2.18.0
+(Closes: #996795).
+ * Set autopkgtest_keep in debian/elpa-test.
+Otherwise, the ert_eval generates an error and the autopkgtest fails.
+
+ -- Sean Whitton Mon, 18 Oct 2021 13:43:54 -0700
+
silversearcher-ag-el (0.48-1) unstable; urgency=medium
* new upstream release (Closes: #960560)
diff -Nru silversearcher-ag-el-0.48/debian/control
silversearcher-ag-el-0.48/debian/control
--- silversearcher-ag-el-0.48/debian/control2020-05-13 23:34:22.0
-0700
+++ silversearcher-ag-el-0.48/debian/control2021-10-18 13:43:54.0
-0700
@@ -10,7 +10,7 @@
Package: elpa-ag
Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, emacsen-common (>= 2.0.8),
silversearcher-ag, elpa-s, elpa-dash, elpa-dash-functional
+Depends: ${shlibs:Depends}, ${misc:Depends}, emacsen-common (>= 2.0.8),
silversearcher-ag, elpa-s, elpa-dash
Built-Using: ${misc:Built-Using}
Recommends: emacs (>= 46.0)
Enhances: emacs, emacs24, emacs25
diff -Nru silversearcher-ag-el-0.48/debian/elpa-test
silversearcher-ag-el-0.48/debian/elpa-test
--- silversearcher-ag-el-0.48/debian/elpa-test 2020-05-13 23:34:22.0
-0700
+++ silversearcher-ag-el-0.48/debian/elpa-test 2021-10-18 13:43:54.0
-0700
@@ -1 +1,2 @@
+autopkgtest_keep = test/test-helper.el
ert_eval = (load-file "test/test-helper.el")
diff -Nru
silversearcher-ag-el-0.48/debian/patches/drop-build-dep-on-elpa-dash-functional--.patch
silversearcher-ag-el-0.48/debian/patches/drop-build-dep-on-elpa-dash-functional--.patch
---
silversearcher-ag-el-0.48/debian/patches/drop-build-dep-on-elpa-dash-functional--.patch
1969-12-31 17:00:00.0 -0700
+++
silversearcher-ag-el-0.48/debian/patches/drop-build-dep-on-elpa-dash-functional--.patch
2021-10-18 13:43:54.0 -0700
@@ -0,0 +1,19 @@
+From: Sean Whitton
+Date: Mon, 18 Oct 2021 12:53:15 -0700
+X-Dgit-Generated: 0.48-1.1 fae27ab8924d4521197de32a98c6972f2fe57b91
+Subject: Drop build-dep on elpa-dash-functional & require elpa-dash >= 2.18.0
+
+
+---
+
+--- silversearcher-ag-el-0.48.orig/ag.el
silversearcher-ag-el-0.48/ag.el
+@@ -5,7 +5,7 @@
+ ;; Author: Wilfred Hughes
+ ;; Created: 11 January 2013
+ ;; Version: 0.48
+-;; Package-Requires: ((dash "2.8.0") (s "1.9.0") (cl-lib "0.5"))
++;; Package-Requires: ((dash "2.18.0") (s "1.9.0") (cl-lib "0.5"))
+ ;;; Commentary:
+
+ ;; Please see README.md for documentation, or read it online at
diff -Nru silversearcher-ag-el-0.48/debian/patches/series
silversearcher-ag-el-0.48/debian/patches/series
--- silversearcher-ag-el-0.48/debian/patches/series 1969-12-31
17:00:00.0 -0700
+++ silversearcher-ag-el-0.48/debian/patches/series 2021-10-18
13:43:54.0 -0700
@@ -0,0 +1 @@
+drop-build-dep-on-elpa-dash-functional--.patch
signature.asc
Description: PGP signature
Bug#996795: silversearcher-ag-el: should drop dependencies on elpa-dash-functional
Package: elpa-ag Version: 0.48-1 Severity: serious Justification: not installable in sid due to package removal Hello, Per [1] dash-functional.el is obsolete and elpa-dash-functional has been removed from unstable. It should be sufficient simply to patch out any `require' calls or similar and require dash.el 2.18.0 or newer. [1] https://github.com/magnars/dash.el/wiki/Obsoletion-of-dash-functional.el -- Sean Whitton signature.asc Description: PGP signature
Bug#994697: libgit-annex-perl: Test failure - autopkgtest and build
control: tag -1 + confirmed Hello, On Sun 19 Sep 2021 at 05:30PM +02, gregor herrmann wrote: > Package: libgit-annex-perl > Version: 0.007-1 > Severity: serious > Tags: ftbfs sid bookworm > Justification: fails to build from source (but built successfully in the past) > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > As first seen at ci.debian.net [0], libgit-annex-perl recently > started to fail its testsuite. I note that this started to happen > after the last git-annex upload (8.20210903-1). > > The same test failure also happens at buildtime: > > # Failed test 'other is reinjected' > # at t/23_annex-to-annex-reinject.t line 33. > # Looks like you failed 1 test of 2. > t/23_annex-to-annex-reinject.t > ok 1 - other is initially present > not ok 2 - other is reinjected > 1..2 > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/2 subtests Bisection has determined that git-annex commit 4bf7940d6b912fbf692b268f621ebd41ed871125 is responsible for this bug. Haven't come up with a minimal test case yet. -- Sean Whitton signature.asc Description: PGP signature
Bug#990622: bitlbee-plugin-facebook: The plugin does not start
control: severity -1 important control: notforwarded -1 Hello Adrian, others, On Mon 12 Jul 2021 at 01:37PM +03, Adrian Bunk wrote: > On Sun, Jul 11, 2021 at 11:03:14PM -0700, Sean Whitton wrote: >> Hello Adrian, > > Hi Sean, > >> Thanks for looking into this, but are you sure that [1] is this bug? >> The original reporter saw the error ERROR_QUEUE_UNDERFLOW but [1] is >> about ERROR_QUEUE-OVERFLOW. >>... > > I might be wrong on that. > > I was searching the BTS for bugs that should be RC but weren't. > While looking at upstream for this bug, I saw this upstream issue. > > If the package is not generally broken and works for you, > feel free to lower the severity again. > > If my guess on what upstream issue matches the problem was wrong, > please ignore it. Thank you for your reply. I can't verify whether or not the plugin is actually broken because my ordinary bitlbee server, and one I just set up on my laptop, are both hitting this bug: https://github.com/bitlbee/bitlbee-facebook/issues/105 https://github.com/bitlbee/bitlbee-facebook/issues/108 I'm downgrading the severity and dropping the 'forwarded' until someone is able to confirm that the plugin is unusable and it is indeed the upstream _OVERFLOW bug. -- Sean Whitton signature.asc Description: PGP signature
Bug#990622: bitlbee-plugin-facebook: The plugin does not start
Hello Adrian, Thanks for looking into this, but are you sure that [1] is this bug? The original reporter saw the error ERROR_QUEUE_UNDERFLOW but [1] is about ERROR_QUEUE-OVERFLOW. [1] https://github.com/bitlbee/bitlbee-facebook/issues/207 -- Sean Whitton signature.asc Description: PGP signature
Bug#985245: src:ppmd: reintroduced with lower version number, different project?
Hello, On Mon 15 Mar 2021 at 08:47PM -04, Sandro Tosi wrote: > alright, i've uploaded src:python-ppmd right now, which is just a > rename of the src:ppmd package. > > Sean, do you need me to file a RM for src:ppmd or will dak > automagically take care of it? I don't believe it will happen automatically. -- Sean Whitton signature.asc Description: PGP signature
Bug#985245: src:ppmd: reintroduced with lower version number, different project?
Hello, On Sun 14 Mar 2021 at 09:39PM -04, Sandro Tosi wrote: >> Per Policy 3.2.2 this is actually RC, and there is no length of time >> after which it's Policy-compliant to reuse package name--version pairs: >> "the version numbers which a binary package must not reuse includes the >> version numbers of any versions of the binary package ever accepted into >> the archive". >> >> Please take a look at that section of Policy. Unfortunately, I think >> you're going to have to introduce an epoch. > > meh, at this point i'd rather do a one-time only operation: remove > src:ppdm and reintroduce it as src:python-ppdm. > > is there anything that i need to other than file a RM bug for src:ppdm > and then upload a new src:python-ppdm for making this transition > complete? I haven't worked through all the details, but I don't believe there is anything else. -- Sean Whitton signature.asc Description: PGP signature
Bug#984546: cpl-plugin-hawki-calib: move downloader package to contrib
Hello, On Mon 08 Mar 2021 at 04:55PM -07, Sean Whitton wrote: > On Thu 04 Mar 2021 at 09:00PM +01, Andreas Beckmann wrote: > >> cpl-plugin-hawki-calib is a downloader package and needs to be moved to >> contrib. All other cpl-plugin-*-calib packages are already in contrib. > > I just reached this package during NEW processing. Could we get a > release team ACK on letting this into unstable at the current stage of > the freeze, please? ACKed by ivodd in #debian-release. -- Sean Whitton signature.asc Description: PGP signature
Bug#984546: cpl-plugin-hawki-calib: move downloader package to contrib
Hello, On Thu 04 Mar 2021 at 09:00PM +01, Andreas Beckmann wrote: > cpl-plugin-hawki-calib is a downloader package and needs to be moved to > contrib. All other cpl-plugin-*-calib packages are already in contrib. I just reached this package during NEW processing. Could we get a release team ACK on letting this into unstable at the current stage of the freeze, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#973634: mpich: d/copyright does not mention vis.js
Source: mpich Version: 3.4~a2+really3.3.2-2 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, d/copyright does not mention debian/missing-sources/vis.js, which has a different license and copyright. Same goes for the minified copies of vis.js in the source. -- Sean Whitton signature.asc Description: PGP signature
Bug#973507: libsis-jhdf5-java: incorrect license text for source/c/jni/
Source: libsis-jhdf5-java Version: 19.04.0+dfsg-1 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, The file source/c/jni/COPYING is a different HDF license to that which applies to source/java/hdf/hdf5lib. The version in NEW has the same problem as what's currently in the archive. -- Sean Whitton signature.asc Description: PGP signature
Bug#969621: propellor: Propellor fails to find location of built propellor binary
Hello, On Sat 05 Sep 2020 at 09:22PM -07, Diane Trout wrote: > I tried to just build 5.11, but export CABAL=./Setup breaks the build, the > makefile assumes ./Setup sdist -o - will output a compressed stream, but the > Setup file built in an unstable schroot doesn't support that feature. Just uploaded a version which should be fixed to sid; would be grateful if you could test. -- Sean Whitton signature.asc Description: PGP signature
Bug#969103: [Pkg-emacsen-addons] Bug#969103: seq.el: requesting an update to the version in GNU ELPA
Hello, On Fri 04 Sep 2020 at 11:57AM GMT, Stefan Kangas wrote: > Lev Lamberov writes: > >> I've applied your patch to seq from the ELPA git repository and tested >> it both in GNU Emacs 24 and GNU Emacs 25 from the Debian archive >> (stretch release). Here is the output: > > Thanks for testing! > > I've now pushed the patch to the GNU ELPA repository. Please allow for > at least 24 hours for the new package to get automatically uploaded on > elpa.gnu.org. Thanks for your help with this. Debian has been updated. -- Sean Whitton signature.asc Description: PGP signature
Bug#969103: [Pkg-emacsen-addons] Bug#969103: elpa-flycheck: causes leak in GNU Emacs 27.1
Hello Lev, Thanks for the report and testing. New version uploaded. -- Sean Whitton signature.asc Description: PGP signature
Bug#968731: netgen: copyright and licensing issues
Source: netgen Version: 6.2.2006+dfsg-1 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, During review in NEW I discovered the following problems with this package's copyright file: cmake\cmake_modules\FindMETIS.cmake is BSD licensed. Also the autogen files do not have their licenses given in d/copyright. libsrc/core/concurrentqueue.h has a different license, not in d/copyright. Looks like general/mystring.*pp might have a different copyright holder. libsrc/general/gzstream.* and libsrc/occ have different copyright holders and maybe licenses; situation is unclear. mkinstalldirs missing copyright & license. ng/fonts.hpp -- is this really the source code for the font? ng/ngappinit.cpp says it's a modification from a different package; what is its copyright and license? -- Sean Whitton signature.asc Description: PGP signature
Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does
Hello Gunnar, others, On Wed 19 Aug 2020 at 12:31PM -05, Gunnar Wolf wrote: > Maybe we could improve on the problem putting it upside down: What if > systemd stated "Provides:" for their main interfaces? While not every > provided binary would qualify as a "main interface", I think a line > such as: > > Provides: journalctl, loginctl, systemctl > > would make sense for systemd. Other scripts could depend on the > specific functionality they make use of. > > Probably, the systemctl package would require a rename to > 'docker-systemctl' or something like that (the upstream name is > 'docker systemctl replacement'). > > What is the systemd maintainers view of this idea? And the > systemctl's? If this solution was thought acceptable I think we'd want to register these new virtual packages in Policy, since they wouldn't be used purely among a "co-operating group of packages". -- Sean Whitton signature.asc Description: PGP signature
Bug#968635: dgit-mirror-ssh-wrapper broke (again) due to rsync update
Hello, On Wed 19 Aug 2020 at 11:16AM +01, Ian Jackson wrote: > I think Sean has been under the impression that the meaning of the > flags that follow --server can be found by reading the manual. > Certainly I was under that impression. > >> Now, it's interesting to note that the 'u' here does not reflect the >> client's '-u' option. > > This is the key thing I was missing. Er, yes, me too. >> I don't know how the inclusion of "uid/gid 0 in the id map" can break >> things, but maybe I'm overlooking something. However, if we indeed >> agree that things can break here, then it seems to me that a new bug >> should be filed against rsync, IMO. > > Sean was probably thinking -u here meant "skip files that are newer on > the receiver". That's what I was thinking. > > I think we can have two general approaches to these undocumented > command line options: > > (1) UTSL to find out what each flag means, and decide if we like it. > I certainly didn't do that right at the beginning. If we do this we > should really review all the existing ones. > > (2) Trust rsync upstream not to get this wrong, and assume that if > the rsync client contrives to pass these options as part of --server, > that they aren't dangerous. > > I'm in favour of (2), which would imply immediately applying Sergio's > patch. Sean, what do you think ? Agreed. -- Sean Whitton signature.asc Description: PGP signature
Bug#968635: dgit-mirror-ssh-wrapper broke (again) due to rsync update
Hello,
On Tue 18 Aug 2020 at 04:51PM -04, Sergio Durigan Junior wrote:
> diff -Nru dgit-9.11/infra/dgit-mirror-ssh-wrap
> dgit-9.12~/infra/dgit-mirror-ssh-wrap
> --- dgit-9.11/infra/dgit-mirror-ssh-wrap 2020-06-22 14:09:17.0
> -0400
> +++ dgit-9.12~/infra/dgit-mirror-ssh-wrap 2020-08-18 16:19:08.0
> -0400
> @@ -29,6 +29,8 @@
> m{^rsync --server -lHtre\.iLsfxC --timeout=\d+ --delete --safe-links \. $d$}
> ||
> m{^rsync --server -lHtre\.iLsfxCIv --timeout=\d+ --delete --safe-links \.
> $d$}
> +||
> +m{^rsync --server -lHtre\.iLsfxCIvu --timeout=\d+ --delete --safe-links \.
> $d$}
>
> # To add a new command pattern, add || m{^ ... $} above.
> # The pattern should contain $d where the per-package destination
Hmm, unlike the -I and -v options, the -u option seems like it could
break things. Could you explain why you think it won't, please?
--
Sean Whitton
signature.asc
Description: PGP signature
Bug#902901: FTBFS: Tests fail
Hello, On Tue 16 Jun 2020 at 07:53PM +03, Ilias Tsitsimpis wrote: > This package is still unbuildable after 2 years, with no response from > upstream. Since there are no rev dependencies for this package, I intend > to remove it from Debian. Please go ahead, since secret-sharing no longer depends on it. Thank you for your efforts! -- Sean Whitton signature.asc Description: PGP signature
Bug#963489: dgit mirror ssh wrapper breaks due to rsync update
Hello, On Thu 25 Jun 2020 at 08:25PM +01, Samuel Henrique wrote: > It is odd indeed, but I'm aware of the issue already, what happened > was that I had introduced rsync-udeb on 3.1.3-9 but then it stayed > long enough in the NEW queue that a new release happened (3.2.0) and > with this new release it came new dependencies for which there is no > udeb, I decided to revert the udeb for now so 3.2.0-1 went directly to > unstable. Sorry, please ignore my other mail. Do you want me to REJECT it from NEW? -- Sean Whitton
Bug#963489: dgit mirror ssh wrapper breaks due to rsync update
Hello, On Wed 24 Jun 2020 at 11:10PM +01, Ian Jackson wrote: > BTW I looked at > https://tracker.debian.org/pkg/rsync > and it says under "versions" >NEW/unstable: 3.1.3-9 > which is rather odd. I thought you should be told. It just means that rsync is in binary-NEW. -- Sean Whitton
Bug#962973: haskell-readline: Removal notice: broken and unmaintained
Hello, On Wed 17 Jun 2020 at 05:17PM -04, Joey Hess wrote: > It could be converted to haskeline or raw IO, but gnu readline is the > kind of library I think it makes sense to have language bindings to, and > to use the bindings. > > This patch seems to fix the build problem: Gratefully applying this patch and marking the upload as closing this bug, but if Ilias thinks we should still consider dropping this library for the reason that it's unmaintained, he should reopen the bug. -- Sean Whitton
